Chapter 4 :Software Requirement

Engineering
Software Requirement
Engineering Definition:-
 Software requirements engineering is a process of
discovery, refinement, modeling, and specification. Both
the software engineer and customer take an active role in
software requirements engineering—a set of activities that
is often referred to as analysis.
 The customer attempts to reformulate a sometimes
nebulous system-level description of data, function, and
behavior into concrete detail. The developer acts as
interrogator, consultant, problem solver, and negotiator
Requirement Analysis:-
Requirement analysis is significant and essential activity after
elicitation. We analyze, refine, and scrutinize the gathered
requirements to make consistent and unambiguous
requirements. This activity reviews all requirements and may
provide a graphical view of the entire system. After the
completion of the analysis, it is expected that the
understandability of the project may improve significantly.
Here, we may also use the interaction with the customer to
clarify points of confusion and to understand which
requirements are more important than others.
The various steps of requirement
analysis are shown in fig:
Explanation of steps:-
(i) Draw the context diagram: The context
diagram is a simple model that defines the
boundaries and interfaces of the proposed systems
with the external world. It identifies the entities
outside the proposed system that interact with the
system. The context diagram of student result
management system is given below:
(ii) Development of a Prototype (optional): One effective way to find out
what the customer wants is to construct a prototype, something that looks
and preferably acts as part of the system they say they want.
We can use their feedback to modify the prototype until the customer is
satisfied continuously. Hence, the prototype helps the client to visualize the
proposed system and increase the understanding of the requirements. When
developers and users are not sure about some of the elements, a prototype
may help both the parties to take a final decision.
Some projects are developed for the general market. In such cases, the
prototype should be shown to some representative sample of the population
of potential purchasers. Even though a person who tries out a prototype may
not buy the final system, but their feedback may allow us to make the
product more attractive to others.
(iii) Model the requirements: This process usually consists of various
graphical representations of the functions, data entities, external entities, and
the relationships between them. The graphical view may help to find
incorrect, inconsistent, missing, and superfluous requirements. Such models
include the Data Flow diagram, Entity-Relationship diagram, Data
Dictionaries, State-transition diagrams, etc.
(iv) Finalise the requirements: After modeling the requirements, we will
have a better understanding of the system behavior. The inconsistencies and
ambiguities have been identified and corrected. The flow of data amongst
various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed
requirements, and the next step is to document these requirements in a
prescribed format.
Software Requirement?
According to IEEE standard 729[IEE83] a
requirement is defined as:-
(i)A condition or capability needed by a user to solve
a problem.
(ii)A condition that must be met by a system to satisfy
a contract, standard or other formality imposed
document.
Types of software requirement:
Broadly requirements can be classified
as:-
I.Functional requirements.
II.Non-Functional requirements.
III. Domain requirements
Functional Requirements:
 As the name implies, these focus on the
functionality of the software components that build
the system. As these components would be doing
some kind of transformations on the input,the high
level functional requirements are expresses in
terms of :-
 Inputs
 Outputs
 Processing input data in some way.
 In simple words functional
requirements are the services which
the end users expect the final product
to provide.
 For example: In a hospital
management system a doctor should
be bale to retrieve the information
about his patients.
Example:Retrieve patient
record (Scenario)
R1:Retreive Patient Record
Description:-Once the doctor selects the retrieve
patient record function, he would be asked to enter the
patient record. The system would search the patient in
the database and if found would display the past
history of the patient. The details to be displayed
include: Pateint name, address, contact number,data of
birth,brief description of diagnosis, details of past visit
and treatment prescribed on these visit.
R1.1: Select retrieve patient record option
State: User has logged in using valid user/password
and the system has displayed the main menu.
Input: “Retrieve Patient Record” option
Output: Prompt user to enter the patient code
R 1.2 Select Time
Input: Patient code
Output: Prompt user to enter the start and end date
R1.3 Search and display
Input: Start and end date
Output: (i) Details of the patient whose patient code matches
the code entered by user is displayed. The details to be
displayed include: Pateint name, address, contact number,data
of birth,brief description of diagnosis, details of past visit and
treatment prescribed on these visit.
(ii) In case no match is found for the patient code entered by
the user an error message “Invalid Patient Code” is displayed
on the screen.
Processing: Search the Patient details based on patient code.
Documenting Functional
requirements:-
 Identify the set of services supported by the
system.
 Specify each of the services or functionality by
identifying the input data,output data and
processing done on input in order to get the output.
 Identify all the sub requirements for a high level
requirement corresponding to the different user
interactions.
Non- Functional Requirements
 These are 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
another. They are also called non-behavioral
requirements. They deal with issues like:
• Portability, Security, Maintainability, Reliability,
Scalability, Performance, Reusability, Flexibility
Functional Requirements Non Functional Requirements

A functional requirement defines a system or A non-functional requirement defines the

its component. quality attribute of a software system.
It places constraints on “How should the
It specifies “What should the software system
software system fulfill the functional
do?”
requirements?”
Non-functional requirement is specified by
Functional requirement is specified by User. technical peoples e.g. Architect, Technical
leaders and software developers.
It is mandatory. It is not mandatory.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
Helps you verify the functionality of the Helps you to verify the performance of the
software. software.
Non-Functional Testing like Performance,
Functional Testing like System, Integration,
Stress, Usability, Security testing, etc are
End to End, API testing, etc are done.
done.
Usually easy to define. Usually more difficult to define.
Domain Requirements:-
 These are the requirements that are specific to an
application domain.
 Eg:- banking,hospital etc.
 These requirements are therefore identified from
that domain model and are not user specific.For a
satisfactory working of the system these are
mandatory requirements to be implemented.
Advantages of classifying software requirements include:

1. Better organization: Classifying software requirements helps organize them

into groups that are easier to manage, prioritize, and track throughout the
development process.
2. Improved communication: Clear classification of requirements makes it
easier to communicate them to stakeholders, developers, and other team
members. It also ensures that everyone is on the same page about what is
required.
3. Increased quality: By classifying requirements, potential conflicts or gaps can
be identified early in the development process. This reduces the risk of errors,
omissions, or misunderstandings, leading to higher quality software.
4. Improved traceability: Classifying requirements helps establish traceability,
which is essential for demonstrating compliance with regulatory or quality
standards.
Disadvantages of classifying software
requirements include:
1. Complexity: Classifying software requirements can be complex,
especially if there are many stakeholders with different needs or
requirements. It can also be time-consuming to identify and classify all
the requirements.
2. Rigid structure: A rigid classification structure may limit the ability to
accommodate changes or evolving needs during the development
process. It can also lead to a siloed approach that prevents the
integration of new ideas or insights.
3. Misclassification: Misclassifying requirements can lead to errors or
misunderstandings that can be costly to correct later in the development
proces
Requirement Engineering Process
 The Requirements Engineering process is a critical step in
the software development life cycle as it helps to ensure
that the software system being developed meets the needs
and expectations of stakeholders, and that it is developed on
time, within budget, and to the required quality.
 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. it is the disciplined application of proven principle ,
methods ,tools and notations to describe a proposed
system’s intended behaviour and its associated constraints.
It consists of following main activities/Steps:-
Requirements elicitation
Requirements specification
Requirements verification and validation.
Requirements management
1. Requirements Elicitation

 It is related to the various ways used to gain

knowledge about the project domain and
requirements. The various sources of domain
knowledge include customers, business manuals,
the existing software of same type, standards and
other stakeholders of the project. The techniques
used for requirements elicitation include
interviews, brainstorming, task analysis,
prototyping, etc
 Requirements elicitation is the process of gathering
information about the needs and expectations of
stakeholders for a software system. This is the first
step in the requirements engineering process and it
is critical to the success of the software
development project. The goal of this step is to
understand the problem that the software system is
intended to solve, and the needs and expectations
of the stakeholders who will use the system.
There are several techniques that can be
used to elicit requirements, including:
• Interviews: These are one-on-one conversations with stakeholders to
gather information about their needs and expectations.
• Surveys: These are questionnaires that are distributed to stakeholders
to gather information about their needs and expectations.
• Focus Groups: These are small groups of stakeholders who are
brought together to discuss their needs and expectations for the
software system.
• Observation: This technique involves observing the stakeholders in
their work environment to gather information about their needs and
expectations.
• Prototyping: This technique involves creating a working model of the
software system, which can be used to gather feedback from
stakeholders and to validate requirements.
2. Requirements Specification
 Requirements specification is the process of
documenting the requirements identified in the
analysis step in a clear, consistent, and unambiguous
manner. This step also involves prioritizing and
grouping the requirements into manageable chunks.
 The goal of this step is to create a clear and
comprehensive document that describes the
requirements for the software system. This document
should be understandable by both the development
team and the stakeholders.
 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 ER
diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries, etc.
There are several types of requirements that are
commonly specified in this step, including
1. Functional Requirements: These describe what the software system
should do. They specify the functionality that the system must provide,
such as input validation, data storage, and user interface.
2. Non-Functional Requirements: These describe how well the software
system should do it. They specify the quality attributes of the system,
such as performance, reliability, usability, and security.
3. Constraints: These describe any limitations or restrictions that must be
considered when developing the software system.
4. Acceptance Criteria: These describe the conditions that must be met
for the software system to be considered complete and ready for
release.
3. Requirements Verification and Validation

 Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.
 Validation: It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer requirements. If
requirements are not validated, errors in the requirement definitions
would propagate to the successive stages resulting in a lot of
modification and rework.
 The main steps for this process include:
1. The requirements should be consistent with all the other requirements
i.e no two requirements should conflict with each other.
2. The requirements should be complete in every sense.
3. The requirements should be practically achievable.
1. Verification is the process of checking that the requirements are
complete, consistent, and accurate. It involves reviewing the
requirements to ensure that they are clear, testable, and free of errors
and inconsistencies. This can include reviewing the requirements
document, models, and diagrams, and holding meetings and
walkthroughs with stakeholders.
2. Validation is the process of checking that the requirements meet the
needs and expectations of the stakeholders. It involves testing the
requirements to ensure that they are valid and that the software system
being developed will meet the needs of the stakeholders. This can
include testing the software system through simulation, testing with
prototypes, and testing with the final version of the software.
4. Requirements Management

 Requirements management is the process of

managing the requirements throughout the
software development life cycle, including tracking
and controlling changes, and ensuring that the
requirements are still valid and relevant. The goal
of requirements management is to ensure that the
software system being developed meets the needs
and expectations of the stakeholders and that it is
developed on time, within budget, and to the
required quality.
There are several key activities that are involved in
requirements management, including:
1. Tracking and controlling changes: This involves monitoring and controlling
changes to the requirements throughout the development process, including
identifying the source of the change, assessing the impact of the change, and
approving or rejecting the change.
2. Version control: This involves keeping track of different versions of the
requirements document and other related artifacts.
3. Traceability: This involves linking the requirements to other elements of the
development process, such as design, testing, and validation.
4. Communication: This involves ensuring that the requirements are
communicated effectively to all stakeholders and that any changes or issues are
addressed in a timely manner.
5. Monitoring and reporting: This involves monitoring the progress of the
development process and reporting on the status of the requirements.
Advantages of Requirement Engineering Process

• Helps ensure that the software being developed meets the

needs and expectations of the stakeholders
• Can help identify potential issues or problems early in the
development process, allowing for adjustments to be made
before significant
• Helps ensure that the software is developed in a cost-
effective and efficient manner
• Can improve communication and collaboration between the
development team and stakeholders
• Helps to ensure that the software system meets the needs of
all stakeholders.
• Provides a clear and unambiguous description of the
requirements, which helps to reduce misunderstandings and
errors.
• Helps to identify potential conflicts and contradictions in
the requirements, which can be resolved before the
software development process begins.
• Helps to ensure that the software system is delivered on
time, within budget, and to the required quality standards.
• Provides a solid foundation for the development process,
which helps to reduce the risk of failure.
Drawbacks:-
• Can be time-consuming and costly, particularly if
the requirements gathering process is not well-
managed
• Can be difficult to ensure that all stakeholders’
needs and expectations are taken into account
• Can be challenging to ensure that the requirements
are clear, consistent, and complete
• Changes in requirements can lead to delays and
increased costs in the development process.
• As a best practice, Requirements engineering should be flexible,
adaptable, and should be aligned with the overall project goals.
• It can be time-consuming and expensive, especially if the requirements
are complex.
• It can be difficult to elicit requirements from stakeholders who have
different needs and priorities.
• Requirements may change over time, which can result in delays and
additional costs.
• There may be conflicts between stakeholders, which can be difficult to
resolve.
• It may be challenging to ensure that all stakeholders understand and
agree on the requirements.
Stages in Software Engineering Process

• Elicitation: In this stage, the requirements are gathered from

various stakeholders such as customers, users, and domain
experts. The aim is to identify the features and functionalities
that the software system should provide.
• Analysis: In this stage, the requirements are analyzed to
determine their feasibility, consistency, and completeness. The
aim is to identify any conflicts or contradictions in the
requirements and resolve them.
• Specification: In this stage, the requirements are documented in
a clear, concise, and unambiguous manner. The aim is to
provide a detailed description of the requirements that can be
understood by all stakeholders.
• Validation: In this stage, the requirements are
reviewed and validated to ensure that they meet the
needs of all stakeholders. The aim is to ensure that
the requirements are accurate, complete, and
consistent.
• Management: In this stage, the requirements are
managed throughout the software development
lifecycle. The aim is to ensure that any changes or
updates to the requirements are properly
documented and communicated to all stakeholders
Requirement Elicitation Techniques
 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
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 a structured interview, an 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. Task Analysis: It is a technique of decomposing the problem domain into a
hierarchy of tasks and subtasks performed by the users.For example the task “Donate
Blood” may consists of subtasks.

1.Donate Blood:
1.1 Donor approaches the blood bank.
1.2 Staff takes the sample of the blood.
1.3 Staff checks for any infection in the blood and the blood group.
1.4 If found ok, he takes the blood and stores it.
1.5 Blood bank issue a card to the donor for later use.
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 include 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.
1. Primary actors: It requires assistance from the system to achieve a goal.
2. 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.
3. A stick figure is used to represent an actor.
4. An oval is used to represent a use case.
5. A line is used to represent a relationship between an actor and a use case.
6. Delphi Technique:-In this participants are made to write the
requirements. These requirements are then exchanged among
participants who give their comments to get a revised set of
requirements. This process is repeated till a final consensus is
reached.
7. Form Analysis:- Form plan plays an important role in any
organization and contain lot of meaningful information about data
objects of the domain. Forms are the important source of
information for modeling the static view or data aspect of the
system. For example: In form a number of concept like: ‘employee
id’, ‘employe name’, ‘salary’, ‘address’,’department’ etc cab be
found and can be sued to model entities,relationships or attributes.
8. Prototyping: One of the most important phases of the requirements
elicitation process, prototyping enables business owners and end-users to
visualize realistic models of applications before they are finally developed.
Prototyping helps generate early feedback, and it boosts stakeholder
participation in requirements elicitation.
9. Joint Application Design (JAD):- It is a registered trademark of IBM
and was developed by IBM in 1970.It is also a type of extremely
effective,structured and disciplined session because it is represented by
persons who are well informed and knowledgable.They are
users,customers,system experts of the project.As compared to brainstorming
sessions which normally last for two to three hours JAD session can last
upto three days and can even producehigh level software models like DFD,
use case diagram etc.
Challenges in Eliciting Techniques
 Understanding large system requirements.
 Understanding system boundaries.
 Users not clear about their needs.
 Representing requirements in suitable form.
 Conflicting requirements.
 Validating and tracking requirements.
 Proper documentation of the requirements.
 Identify the critical requirements.
Software Requirements Specification(SRS)
 The output of requirement engineering process id
Requirement Specification Document (RSD) also
called SRS.
 A SRS is a document which contains the complete
description of software without talking much about
implementation details.It is a set of precisely stated
properties and constraints which the final product
must satisfy.
 SRS aims at bridging the communication gap among the
different stake holders of the project and also forms a
contract between the customer and the developing
organization.
 Depending upon the type of project and the person who is
writing it, SRS may be detailed or general. The document is
used as a reference tool for all the successive stages of the
software life cycle and should specify the external system
behavior. SRS can be represented using writing textual
document, a set of models, mathematical tool or prototype.
SRS must address foll issues:
 Functional requirements in terms of input required,outputs
generated and the processing details.
 Non-functional requirements.eg:accuracy,efficiency etc.
 Static requirements.
 Execution constraints.eg:-response times,throughput times.
 Standards to be followed.
 Security requirements.
 Company policies.
 Interfere with other external agents i.e. persons,software or
hardware.
Characteristics of SRS document
 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
actually expected from the system.
 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.
 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.
 Unambiguousness:
A 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.
 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.
 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.
 Verifiability:
A 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.
 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.
 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.
 Testability:
A SRS should be written in such a way that it is easy to generate test
cases and test plans from the document.
 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.
 Right level of abstraction:
If the SRS is written for the requirements phase, the details should be
explained explicitly. Whereas, for a feasibility study, fewer details can
be used. Hence, the level of abstraction varies according to the purpose
of the SRS.
Organization of SRS
 1. Introduction
1.1 Purpose of this document
1.2 Scope of this document
1.3 Overview
1.4 Business Context
 2. General Description
2.1 Product Functions
2.2 Similar System Information
2.3 User Characteristics
2.4 User Problem Statement
2.5 User Objectives
2.6 General Constraints
 3. Functional Requirements
 4. Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Communications Interfaces
4.4 Software Interfaces
 5. Performance Requirements
 6. Other non-functional attributes
6.1 Security
6.2 Reliability
6.3 Maintainability
6.4 Portability
 6.5 Extensibility
6.6 Reusability
7. Operational Scenarios
8. Preliminary Use Case Models and Sequence Diagrams
8.1 Use Case Model
8.2 Sequence Diagrams
9. Updated Schedule
10. Appendices
10.1 Definitions, Acronyms, Abbreviations
10.2 References
Role of System Analyst
 A system analyst is a person with unique skills and
experience who undertakes the job of system
analysts. He/she is the who is responsible for
identifying the business goals and activities and the
strategies for meeting these objectives. Jobs carried
by the analysts are:-
 Identifying and documenting the business goals.
 Identifying and satisfying different stakeholders of
the project.
 To consult the mangers, data processing
professionals and users in order to define the
problem statement clearly.
 To propose a plan to solve the problem and to met
the management objectives.To coordinate the
design and testing activities.
 Resolve conflicts and suggest solutions.
Some imp. Skills required by the
analysts:-
 Ability to communicate.
 Excellent analysts skills.
 Knowledge of latest technology.
 Creative and imaginative mind.
 Well educated.
 Ability to coordinate different team
members activities.