Functional vs Non-Functional

Requirements
Requirements analysis is very critical process that enables the success of a
system or software project to be assessed. Requirements are generally split
into two types: Functional and Non-functional requirements.
Functional Requirements: These are the requirements that the end user
specifically demands as basic facilities that the system should offer. All
these functionalities need to be necessarily incorporated into the system as
a part of the contract. These are represented or stated in the form of input
to be given to the system, the operation performed and the output
expected. They are basically the requirements stated by the user which one
can see directly in the final product, unlike the non-functional requirements.
Non-functional requirements: These are basically the quality constraints
that the system must satisfy according to the project contract. The priority
or extent to which these factors are implemented varies from one project to
other. They are also called non-behavioural requirements.
They basically deal with issues like:
• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility
Following are the differences between Functional and Non-Functional
Requirements

Non-Functional
Functional Requirements Requirements

A functional requirement A non-functional requirement

defines a system or its defines the quality attribute of a
component. software system.

It places constraints on “How

It specifies “What should the
should the software system fulfil
software system do?”
the functional requirements?”

Functional requirement is Non-functional requirement is

specified by User. specified by technical peoples
 Non-Functional
Functional Requirements Requirements

e.g., Architect, Technical leaders

and software developers.

It is mandatory. It is not mandatory.

It is captured as a quality
It is captured in use case.
attribute.

Defined at a component level. Applied to a system as a whole.

Helps you verify the Helps you to verify the

functionality of the software. performance of the software.

Functional Testing like System, Non-Functional Testing like

Integration, End to End, API Performance, Stress, Usability,
testing, etc are done. Security testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example Example
1) Authentication of user 1) Emails should be sent with a
whenever he/she logs into the latency of no greater than 12
system. hours from such an activity.
2) System shutdown in case of a 2) The processing of each
cyber-attack. request should be done within
3) A Verification email is sent to 10 seconds
user whenever he/she registers 3) The site should load in 3
for the first time on some seconds when the number of
software system. simultaneous users are > 10000
Software Engineering | Requirements
Elicitation
Requirements elicitation is the process of gathering and defining the
requirements for a software system. The goal of requirements elicitation is
to ensure that the software development process is based on a clear and
comprehensive understanding of the customer’s needs and requirements.
Requirements elicitation involves the identification, collection, analysis, and
refinement of the requirements for a software system. It is a critical part of
the software development life cycle and is typically performed at the
beginning of the project. Requirements elicitation involves stakeholders
from different areas of the organization, including business owners, end-
users, and technical experts. The output of the requirements elicitation
process is a set of clear, concise, and well-defined requirements that serve
as the basis for the design and development of the software system.
Requirements elicitation is perhaps the most difficult, most error-prone,
and most communication-intensive software development. It can be
successful only through an effective customer-developer partnership. It is
needed to know what the users really need.
Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are
listed below –
• Knowledge of the overall area where the systems is applied.
• The details of the precise customer problem where the system is
going to be applied must be understood.
• Interaction of system with external requirements.
• Detailed investigation of user needs.
• Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are
listed below –
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the
analyst, developers, users, and the customer involved.
1. Interviews:
Objective of conducting an interview is to understand the customer’s
expectations from the software.
It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
Interviews maybe be open-ended or structured.
1. In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is
prepared. Sometimes a proper questionnaire is designed for the
interview.
2. Brainstorming Sessions:
• It is a group technique
• It is intended to generate lots of new ideas hence providing a
platform to share views
• A highly trained facilitator is required to handle group bias and
group conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification Technique:

Its objective is to bridge the expectation gap – the difference between what
the developers think they are supposed to build and what customers think
they are going to get. A team-oriented approach is developed for
requirements gathering. Each attendee is asked to make a list of objects
that are-
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, team is divided into smaller sub-teams to
develop mini-specifications and finally a draft of specifications is written
down using all the inputs from the meeting.
4. Quality Function Deployment:
In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified –
• Normal requirements –
In this the objective and goals of the proposed software are
discussed with the customer. Example – normal requirements for a
result management system may be entry of marks, calculation of
results, etc
 • Expected requirements –
These requirements are so obvious that the customer need not
explicitly state them. Example – protection from unauthorized
access.
• Exciting requirements –
It includes features that are beyond customer’s expectations and
prove to be very satisfying when present. Example – when
unauthorized access is detected, it should backup and shutdown
all processes.
The major steps involved in this procedure are –
1. Identify all the stakeholders, eg. Users, developers, customers etc
2. List out all requirements from customer.
3. A value indicating degree of importance is assigned to each
requirement.
4. In the end the final list of requirements is categorized as –
• It is possible to achieve
• It should be deferred and the reason for it
• It is impossible to achieve and should be dropped off
5. Use Case Approach:
This technique combines text and pictures to provide a better understanding
of the requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they
only give a functional view of the system.
The components of the use case design includes three major things – Actor,
Use cases, use case diagram.
1. Actor –
It is the external agent that lies outside the system but interacts
with it in some way. An actor maybe a person, machine etc. It is
represented as a stick figure. Actors can be primary actors or
secondary actors.
• Primary actors – It requires assistance from the system to
achieve a goal.
• Secondary actor – It is an actor from which the system
needs assistance.
2. Use cases –
They describe the sequence of interactions between actors and the
system. They capture who(actors) do what(interaction) with the
system. A complete set of use cases specifies all possible ways to
use the system.
3. Use case diagram –
A use case diagram graphically represents what happens when an
actor interacts with a system. It captures the functional aspect of
the system.
 • A stick figure is used to represent an actor.
• An oval is used to represent a use case.
• A line is used to represent a relationship between an
actor and a use case.

Features of requirements elicitation:

1. Stakeholder engagement: Requirements elicitation involves

engaging with stakeholders such as customers, end-users, project
sponsors, and subject matter experts to understand their needs
and requirements.
2. Gathering information: Requirements elicitation involves
gathering information about the system to be developed, the
business processes it will support, and the end-users who will be
using it.
3. Requirement prioritization: Requirements elicitation involves
prioritizing requirements based on their importance to the project’s
success.
4. Requirements documentation: Requirements elicitation involves
documenting the requirements in a clear and concise manner so
that they can be easily understood and communicated to the
development team.
5. Validation and verification: Requirements elicitation involves
validating and verifying the requirements with the stakeholders to
ensure that they accurately represent their needs and
requirements.
6. Iterative process: Requirements elicitation is an iterative process
that involves continuously refining and updating the requirements
based on feedback from stakeholders.
7. Communication and collaboration: Requirements elicitation
involves effective communication and collaboration with
stakeholders, project team members, and other relevant parties to
ensure that the requirements are clearly understood and
implemented.
8. Flexibility: Requirements elicitation requires flexibility to adapt to
changing requirements, stakeholder needs, and project constraints.

Advantages of Requirements Elicitation:

• Helps to clarify and refine customer requirements.
• Improves communication and collaboration between stakeholders.
• Increases the chances of developing a software system that meets
customer needs.
• Avoids misunderstandings and helps to manage expectations.
 • Supports the identification of potential risks and problems early in
the development cycle.
• Facilitates the development of a comprehensive and accurate
project plan.
• Increases user and stakeholder confidence in the software
development process.
• Supports the identification of new business opportunities and
revenue streams.

Disadvantages of Requirements Elicitation:

• Can be time-consuming and expensive.
• Requires specialized skills and expertise.
• May be impacted by changing business needs and requirements.
• Can be impacted by political and organizational factors.
• Can result in a lack of buy-in and commitment from stakeholders.
• Can be impacted by conflicting priorities and competing interests.
• May result in incomplete or inaccurate requirements if not properly
managed.
• Can lead to increased development costs and decreased efficiency
if requirements are not well-defined.

Software Engineering | Challenges in

Eliciting requirements
Eliciting requirements is one of the most challenging aspects of
software engineering. Some common challenges include:

1. Understanding the user’s needs: Requirements are often poorly

defined and may change over time, making it difficult for engineers
to understand the user’s true needs.
2. Managing stakeholders: There may be multiple stakeholders with
different goals and priorities, making it difficult to satisfy
everyone’s requirements.
3. Identifying and mitigating risks: Engineers must identify and
mitigate potential risks associated with the requirements, such as
security vulnerabilities or scalability issues.
4. Handling ambiguity: Requirements may be ambiguous,
inconsistent, or incomplete, making it difficult for engineers to
understand what the system should do.
 5. Keeping up with changing technology: Requirements must be
aligned with the latest technology trends and innovations, which
can be difficult to predict and keep up with.
6. Maintaining a balance between feasibility, cost and time: Engineers
need to balance the feasibility of implementing a requirement, the
cost of implementation, and the time required to implement it.
7. Maintaining traceability: Engineers need to maintain traceability of
requirements throughout the development process to ensure that
all requirements are met and any changes are tracked.
Eliciting requirements is the first step of the Requirement Engineering
process. It helps the analyst to gain knowledge about the problem domain
which in turn is used to produce a formal specification of the software.
There are a number of issues and challenges encountered during this
process.
Some of them are as follows:
1. Understanding large and complex system requirements is
difficult: The word ‘large’ represents 2 aspects:
• (i) Large constraints in terms of security, etc. due to a
large number of users.
• (ii) a Large number of functions to be implemented.
2. Undefined system boundaries: There might be no defined set of
implementation requirements. The customer may go on to include
several unrelated and unnecessary functions besides the important
ones, resulting in an extremely large implementation cost that may
exceed the decided budget.
3. Customers/Stakeholders are not clear about their
needs: Sometimes, the customers themselves may be unsure
about the exhaustive list of functionalities they wish to see in the
software. This might happen when they have a very basic idea
about their needs but haven’t planned much about the
implementation part.
4. Conflicting requirements are there: There is a possibility that two
different stakeholders of the project express demands which
contradict each other’s implementation. Also, a single stakeholder
might also sometimes express two incompatible requirements.
5. Changing requirements is another issue: In the case of successive
interviews or reviews from the customer, there is a possibility that
the customer expresses a change in the initial set of specified
requirements. While it is easy to accommodate some of the
requirements, it is often difficult to deal with such changing
requirements.
 6. Partitioning the system suitably to reduce complexity: The
projects can sometimes be broken down into small modules or
functionalities which are then handled by separate teams. Often,
more complex and large projects require more partitioning. It
needs to be ensured that the partitions are non-overlapping and
independent of each other.
7. Validating and Tracing requirements: Cross-checking the listed
requirements before starting the implementation part is very
important. Also, there should be forward as well as backward
traceability. For eg, all the entity names should be the same
everywhere, i.e., there shouldn’t be a case where ‘STUDENT’ and
‘STUDENTS’ are used at separate places to refer to the same
entity.
8. Identifying critical requirements: Identifying the set of
requirements that have to be implemented at any cost is very
important. The requirements should be prioritized so that crucial
ones can be implemented first with the highest priority.
9. Resolving the “to be determined” part of the requirements: The
TBD set of requirements include those requirements which are yet
to be resolved in the future. The number of such requirements
should be kept as low as possible.
10. Proper documentation, proper meeting time, and budget
constraints –
Ensuring proper documentation is an inherent challenge, especially
in the case of changing requirements. The time and budget
constraints too need to be handled carefully and systematically.
Solutions to Overcome Challenges in Eliciting Requirements:
1. Maintaining proper documentation.
2. Trying to understand from a stakeholder’s perspective.
3. Establishing proper communication with stakeholders.
4. Identifying conflicting requirements from the stakeholder side.
5. Establishing structured and insightful discussions with end-users.
6. Performing proper market research and competitor analysis.

Advantages or Disadvantages:

Advantages of eliciting requirements in software engineering

include:

1. Improved communication: Eliciting requirements helps to improve

communication between stakeholders, developers, and users,
 which can result in a better understanding of the user’s needs and
a more successful end product.
2. Reduced rework: By identifying and addressing requirements early
on in the development process, engineers can reduce the likelihood
of costly rework later on.
3. Increased user satisfaction: By thoroughly understanding and
addressing the user’s needs, engineers can create software that is
more likely to meet the user’s expectations and result in increased
satisfaction.
4. Improved system quality: By identifying and mitigating risks
associated with the requirements, engineers can improve the
overall quality of the system.
5. Better alignment with business goals: By aligning the
requirements with the business goals, engineers can ensure that
the software is developed in a way that supports the overall
objectives of the organization.

Disadvantages of eliciting requirements in software engineering

include:

1. Time-consuming: Eliciting requirements can be a time-consuming

process, which can slow down the development process.
2. Costly: Gathering requirements can be costly, especially when
involving multiple stakeholders.
3. Risk of changing requirements: Requirements may change over
time, which can lead to confusion and require additional work to
keep the project aligned with the updated requirements.
4. Difficulty in identifying all the requirements: It can be difficult to
identify all the requirements, especially when dealing with
complex systems or new technologies.
5. Difficulty in predicting future requirements: It can be difficult to
predict future requirements, which can result in the software
becoming outdated or needing to be redesigned.
6. Difficulty in handling user’s changing needs: As the users start
using the system, they might realize that they need something that
was not anticipated during the requirements gathering phase.