Software Engineering

Software Requirements

© 2024 Dr. Omar Janeh

University of Technology | Computer Engineering Department
“business requirements should come from the person who is ultimately
accountable for the business value expected from the product. User
requirements should come from people who will press the keys, touch the
screen, or receive the outputs.”

― Karl E. Wiegers, Software Requirements

What are Requirements?
● The goal of the requirements phase is to elicit the requirements from the user.
This is usually achieved by the development of diagrams and the requirement
specification after discussions with the user. The user then reviews the
diagrams and specification to determine if the software developer has
understood the requirements.
● Thus, it is essential that the diagrams and specifications communicate back to
the user the essential aspects required of the software to be produced.
● According to IEEE standard 729, a requirement is defined as follows:
○ A condition or capability needed by a user to solve a problem or achieve an objective
○ A condition or capability that must be met or possessed by a system or system component to
satisfy a contract, standard, specification or other formally imposed documents
○ A documented representation of a condition or capability as in 1 and 2.
Requirements Engineering Process
● Requirement Engineering is the process of defining, documenting and
maintaining the requirements.
● It is a process of gathering and defining service provided by the system.
Requirements Engineering Process consists of the following main
activities:
○ Requirements elicitation
○ Requirements specification
○ Requirements verification and validation
○ Requirements management
(1) Requirements Elicitation
● 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 includes the subsequent activities:
○ Knowledge of the overall area where the systems is applied.
○ The details of the precise customer problem where the system are 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
● Several requirements elicitation methods are listed below:
○ Interviews
○ Brainstorming Sessions
○ Facilitated Application Specification Technique (FAST)
○ Quality Function Deployment (QFD)
○ Use Case Approach
● The success of an elicitation technique used depends on the maturity of
the analyst, developers, users, and the customer involved.
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.
○ In open-ended interviews there is no pre-set agenda. Context free questions may be
asked to understand the problem.
○ In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.
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.
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:
○ Part of the environment that surrounds the system
○ Produced by the system
○ 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.
Quality Function Deployment (1/2)
● This technique emphasizes on the 3 types of requirements which are
valuable to the customer:
○ 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.
○ E.g.,: 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.
Quality Function Deployment (2/2)
● The major steps involved in this procedure are:
○ Identify all the stakeholders, e.g., Users, developers, customers etc.
○ List out all requirements from customer.
○ A value indicating degree of importance is assigned to each requirement.
○ 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.
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: an external agent that lies outside the
system but interacts with it somehow. An actor,
maybe a person, a machine, etc.
○ Use cases: describes the sequence of interactions
between the system and actors.
○ Use case diagram: represents what happens
when an actor graphically interacts with a system.
Challenges in Eliciting Requirements (1/3)
1. Understanding large and complex system requirements is difficult, which
represents 2 aspects:
○ Large constraints in terms of security, etc. due to a large number of users.
○ 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.
Challenges in Eliciting Requirements (2/3)
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.
Challenges in Eliciting Requirements (3/3)
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.
(2) Requirements Specification
● This activity is used to produce formal software
requirement models. All the requirements
including the functional as well as the
non-functional requirements and the constraints
are specified by these models in totality.
● During specification, more knowledge about the
problem may be required which can again trigger
the elicitation process.
● The models used at this stage include
entity-relationship diagram (ERD), data flow
diagram (DFD), function decomposition diagram
(FDD), data dictionaries, etc.

[Link]
What is SRS?
● A software requirements specification (SRS) is a description of a
software system to be developed.
● The SRS is a specification for the specific software product, program, or
application set that performs particular functions within a particular
environment.
● It lays out functional and non-functional requirements and may include a
set of use cases that describe user interactions that the software must
provide.
●
Why SRS?
● In order to fully understand one’s project, it is very important that they
produce an SRS listing out their requirements, how are they going to meet
them and how will they complete the project.
● An SRS diminishes the time and effort required by developers to achieve
desired goals and reduces the development cost.
● A good SRS defines application interaction with system hardware, other
programs, and human users in a wide variety of real-world situations.
Quality Characteristics of an SRS (1/4)
1. Correctness: User review is used to ensure the correctness of
requirements stated in the SRS. SRS is said to be correct if it covers all the
requirements that are expected from the system.
2. Completeness: Completeness of SRS indicates every sense of completion
including the numbering of all the pages, resolving the to be determined
parts to as much extent as possible as well as covering all the functional
and non-functional requirements properly.
3. Consistency: Requirements in SRS are said to be consistent if there are
no conflicts between any set of requirements. Examples of conflict include
differences in terminologies used at separate places, logical conflicts like
time period of report generation, etc.
Quality Characteristics of an SRS (1/4)
4. Unambiguousness: An SRS is said to be unambiguous if all the
requirements stated have only 1 interpretation. Some of the ways to
prevent unambiguousness include the use of modelling techniques like ER
diagrams, proper reviews and buddy checks, etc.
5. Ranking for importance and stability: There should a criterion to
classify the requirements as less or more important or more specifically
as desirable or essential. An identifier mark can be used with every
requirement to indicate its rank or stability.
6. Modifiability: SRS should be made as modifiable as possible and should
be capable of easily accepting changes to the system to some extent.
Modifications should be properly indexed and cross-referenced.
Quality Characteristics of an SRS (1/4)
7. Verifiability: An SRS is verifiable if there exists a specific technique to
quantifiably measure the extent to which every requirement is met by the
system. For example, a requirement starting that the system must be
user-friendly is not verifiable and listing such requirements should be
avoided.
8. Traceability: One should be able to trace a requirement to design
component and then to code segment in the program. Similarly, one
should be able to trace a requirement to the corresponding test cases.
9. Design Independence: There should be an option to choose from
multiple design alternatives for the final system. More specifically, the SRS
should not include any implementation details.
Quality Characteristics of an SRS (1/4)
10. Testability: An SRS should be written in such a way that it is easy to
generate test cases and test plans from the document.
11. Understandable by the customer: An end user maybe an expert in
his/her specific domain but might not be an expert in computer science.
Hence, the use of formal notations and symbols should be avoided to as
much extent as possible. The language should be kept easy and clear.
12. Right level of abstraction: If the SRS is written for the requirements
phase, the details should be explained explicitly. Whereas, for a 000 study,
fewer details can be used. Hence, the level of abstraction varies according
to the purpose of the SRS.
(3) Requirements Verification & Validation (1/2)
● Verification comes first, followed by validation. Verification tests ensure the program is
built according to the stated requirements. Verification is the process of checking whether
a software achieves its goal without any bugs.
● The verification process includes the following :
○ Inspections
○ Reviewing the code
○ Walkthroughs
○ Desk Checking
● Invalid (or missing) requirements can be discovered during this phase, which can also
minimize the risk of rework(extra work) and the cost associated with overruns. It's far more
effective to fix a small bug upfront than in the future when you have to identify the bug in
hundreds of lines of code, and it needs to be corrected.
● Let's take an example of verification, imagine that you are driving to a new destination from
your car. You might mark your destination into your GPS, which helps you to provide
directions and the freeway exit number. If you're looking for exit 10 and just passed exit 1,
you quickly know you have nine more exits to go. Using the GPS, you can check your
existing path against the directions, similar to the verification phase.
[Link]
(3) Requirements Verification & Validation (2/2)
● Validation is a process of checking whether the software product is up to the mark. Validation
ensures that the requirements have met the needs of any relevant stakeholders and achieved the
business objectives, and are clearly understood by developers.
● Software validation addresses the following:
○ It correctly fulfills the user’s requirements.
○ Validation is the process of evaluating software during or at the end of the development
process
○ It can be modified as per requirements.
○ It is easily linked to system requirements like designs, codes, and tests.
● Validation is the dynamic process, or we can say that it is dynamic testing.
● Let's take an example to understand requirement validation; suppose a man is traveling in his car
and tracking the landmarks, such as exit numbers. Let's say his goal is to arrive at a hiking trail.
The following is the list of questions that can be asked after your arrival:
○ Does the hiking trail look as expected?
○ Does the location meet my expectations?
○ Can I see a marked trail or any trailhead sign?
○ Validation is the dynamic process, or we can say that it is dynamic testing.

[Link]
(4) Requirements Management
● Requirement management is the process of analyzing, documenting,
tracking, prioritizing and agreeing on the requirement and controlling the
communication to relevant stakeholders.
● This stage takes care of the changing nature of requirements.
● It should be ensured that the SRS is as modifiable as possible to
incorporate changes in requirements specified by the end users at later
stages too.
● Being able to modify the software as per requirements in a systematic
and controlled manner is an extremely important part of the
requirements engineering process.
[Link]
Software Requirements Classification
● There are three types of software requirements as follows:
○ Functional requirements
○ Non-functional requirements
○ Domain 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.
● For example, in a hospital management system, a doctor should be able to
retrieve the information of his patients. Each high-level functional requirement
may involve several interactions or dialogues between the system and the outside
world. In order to accurately describe the functional requirements, all scenarios
must be enumerated.
● Functional requirements can be incorporated into the system in many ways as:
○ Natural language
○ A structured or formatted language with no rigorous syntax and formal specification language
with proper syntax.
Non-functional Requirements (1/2)
● 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-behavioral requirements.
● They basically deal with issues like:
○ Portability
○ Security
○ Maintainability
○ Reliability
○ Scalability
○ Performance
○ Reusability
○ Flexibility
Non-functional Requirements (2/2)
● NFRs are classified into following types:
○ Interface constraints
○ Performance constraints: response time, security, storage space, etc.
○ Operating constraints
○ Life cycle constraints: maintainability, portability, etc.
○ Economic constraints
● The process of specifying non-functional requirements requires the
knowledge of the functionality of the system, as well as the knowledge of
the context within which the system will operate.
Domain Requirements
● Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.
● The basic functions that a system of a specific domain must necessarily
exhibit come under this category.
● For instance, in an academic software that maintains records of a school
or college, the functionality of being able to access the list of faculty and
list of students of each grade is a domain requirement.
● These requirements are therefore identified from that domain model and
are not user specific.