Software Engineering

UNIT II
REQUIREMENTS ANALYSIS AND
SPECIFICATION

Prof. Om Prakash Suman

Department : School of
Technology
Woxsen University, Hyderabad
[email protected]
.in
+91-9155661919
 Table of Content:
 Software Requirements: Functional and non-
functional requirements, user requirements,
system requirements, interface specification, the
software requirements document.
 Requirements engineering process: Feasibility
studies, requirements elicitation and analysis,
requirements validation, requirements
management. System models: Context models,
behavioral models, data models, object models,
structured methods.
 Software Requirements

Requirement- A requirement is something that’s

mandatory or necessary—it’s
something you need to have or need to
do.
What is Software Requirements?
According to IEEE standard 729, a requirement is defined as
follows:
1. A condition or capability needed by a user to solve a
problem or achieve an objective.
2. A condition or capability that must be met or possessed by
a system or system component to satisfy a standard,
specification or other formally imposed documents
 Software Requirements
Requirement - Types:
► User Requirements

► System Requirements

► Domain Requirements
 Software Requirements
Requirement - User Requirements:

► These requirements describe what the end-user

wants from the software system.

►Should describe functional and non-functional

requirements so that they are understandable by
system users who don't have detailed technical
knowledge.
 Software Requirements
Requirement - User Requirements:

► User requirements are defined using

natural language, tables, and diagrams.

►Typically gathered through communication, interviews,

surveys, or user feedback.
 Software Requirements

Requirement- User Requirements:

► Problems with natural language

► Precision vs. understandability

►Functional vs. non- requirements

functional confusion
► Requirements mixture
 Software Requirements
► Requirement - User Requirements:

► Guidelines:
► Prepare a standard format and use it for all requirements.

► Apply consistency in tbe language:

'shall' - mandatory requirements,
'should' - desirable requirements.
► Avoid the use of computer terminologies. It
should be written in simple language.
 Software Requirements

Requirement - System Requirements:

► These requirements specify the technical characteristics
of the software system, such as its architecture,
hardware requirements, software components, and
interfaces.

► More detailed specifications of user requirements

►Serve as a basis for designing the system.

► The requirements specify what the system

does and design specifies how it does.
 Software Requirements
Requirement - System Requirements:
► Structured Language Specification:
► requirements are written in a standard way.

►The requirement become understandable

and expressive.

► Uniformity must be maintained.

► Graphical model: Sequence Diagram.
 Software Requirements
Requirement - Domain Requirements:
► Requirements that come from the
application domain of the system and
that reflect characteristics of that domain.
►Domain requirements can be functional or
nonfunctional.
► These requirements m ake use of
domain terminologies specific to the existing
domain concept.
 Software Requirements
Requirement - Domain Requirements:
► These are the specialized requirernents and
hence software engineers find it difficult to co-
relate the domain requiren1ents with the
system requirements.

► It is important to specify the domain

requirements otherwise the system will not work
properly.
Functional and non-functional requirements
Functional requirements
► FR describe what the software should do.

► They define the functions or features that the system must

have. Examples:

► Examples: User Authentication: The system must allow

users to log in using a username and password.

► Search Functionality: The software should enable users to

search for products by name or category.

► Report Generation: The system should be able to generate

sales reports for a specified date range.
 Functional and non-functional
requirements

Functional requirements
► Statements of services the system should
provide,

1. how the system should react to particular

inputs

2. how the system should behave in

particular situations.
 Functional and non-functional
requirements
Functional requirements
►It is heavily dependent upon the type of software,
expected users and type of system where the
software is used.

►Functional user requirements may be high-level

statements of what the system should do.

► Functional system requirements should describe

the software/system service in detail.
 Functional and non-functional
requirements

Functional requirements - Problems:

► Requirements imprecision:

► Problems arise when functional

requirements are not well stated.

► Ambiguous requirements may be

interpreted in different ways by developers
and users
 Functional and non-functional
requirements
Functional requirements - Problems:
► Requirements completeness and consistency:
► Complete : They should include
descriptions of all facilities required.
►Consistent: There should be no conflicts or
contradictions in the descriptions of the
system facilities
Functional and non-functional requirements
Non - Functional requirements:
 NFR describe how the software performs a task rather than
what it should do.

 Examples: IRCTC
 Performance: The system should process 1 lakhs transactions
per second.
 Usability: The software should be easy to use and have a
user-friendly interface.
 Reliability: The system must have 99.9% uptime.
 Security: Data must be encrypted during transmission and
storage.
Functional and non-functional requirements

Non - Functional requirements:

► These define system properties and constraints.

► Process requirements also

may mandating a be specified
particular or development method.
language IDE,

► Non-functional programming
requirements may be more
critical than functional requirements. If these are
not met, the system may be useless
Non-functional requirements Types
► Product requirements:
► Requirements which specify that the delivered product must
behave in a particular way.

► e.g. execution speed, reliability, etc.

► Organizational requiretnents:
► Requirements which m e e t the organizational policies
and procedures.

► e.g. process standards used, implementation requirements, etc.

 Non-functional requirements -
Types
► External requirements:
► Requirements which arise from factors which are external
to the system and its development process.

► e.g. Ethical requirements, legislative requirements, etc.

 Non-functional requirements -
Metrics
► Reliability: Generate all the updated information
in collective order.

► Availability: Any information must be

quickly available from computer to the authorized user.

► Security: The application must be password protected.

► Maintainability: Any change in require1nent

occurs then it should be easily incorporated in an
individual module.
 Non-functional requirements -
Metrics

► Extensibility: Any new requirement occurs then

it should be easily incorporated in an individual
module.

► Portability: Portable on the desired OS.

► Reusability: A segment of source code can be

used again to add new functionalities.

► Resource Utilization: Use of resources to its

maximum capability.
 Non-functional requirements Metrics
Property Measure

Speed Processed transactions/second, User/event response time

Screen refresh time

Size Mbytes, Number of ROM chips

Reliability Mean time to failure, Probability of unavailability

Rate of failure occurrence, Availability

Robustness Time to restart after failure, Percentage of events causing

failure, Probability of data corruption on failure

Portability Percentage of target dependent statements

Number of target systems
Advantages of Classifying Software Requirements:
Better organization:
Improved communication:
Increased quality:
Improved traceability:

Disadvantages of classifying software requirements

Complexity:
Rigid structure:
Misclassification:
 Software Requirements Document

► The specification of the system.

► It should include both a definition and a

specification of requirements.
► It should set of what the system should do a n d
how it should do it.

► The SRS is useful in estimating cost, planning

team activities, performing tasks and tracking the
team's progress.
Software Requirements Documen

Document Title
Author

Affiliation

Address

Date

Document Version
 Software Requirements Document

1. Introduction
►1.1 Purpose of the document
►1.2 Scope of this document
►1.3 Overview
 Software Requirements Document

General Description

► General functionality of the product:

System information, user characteristics, User
objective, general constraints placed on design
team.

► The features of the user community, including

their expected with software systems and the
application domain.
 Software Requirements Document

Functional requirements:
► It describes the possible effects of a
software system, what the system must do.

► Short sentence stating highest ranked functional

requirements.
 Software Requirements Document

Functional requirements:
► Description: A full description of the requirement.

►Criticality: Describes bow essential

this requirement is to the overall system.

►Technical Issues: Describes any

design or implementation
 Software Requirements Document

Functional requirements:
► Risks: Describes the circutnstances under
which this requirement might not able to be
satisfied.

► Dependencies with other requiren1ents:

Describes interactions with other requirements.
 Software Requirements Document

Interface requirements:
►It describes how the software interfaces interact
with other software products or users for input or
output.

► User Interfaces:

►GUI: It should include a set of screen dumps user

interface features.
Software Requirements Document

Interface requirements:
► Hardware interfaces to hardware

interfaces: devices.
► Communication interfaces: Describes
network interfaces.

► Software interfaces: Describes the

application programming interfaces not included
 Software Requirements Document

Non-functional Attributes:
► Security

► Reliability

► Maintainability

► Portability

► Extensibility

► Reusability
 Software Requirements Document

Other Non-functional Attributes:

 Performance requirements
 Design constraints
 Software Requirements Document

Preliminary Schedule:
► It provides an initial version of the project
plan, including the major task, their
interdependencies, and their tentative start/stop
dates.

Preliminary Budget:
► It provides an initial budget for the project.
 Software Requirements Document

Appendices:
► Deftnitions, Acronyms, Abbreviations:
Provides definitions terms and acronyms can be
provided.

► References: It provides complete citations to

all documents.
 Characteristics of SRS

► Correct: The SRS should be made up to date

when requirements are identified.
► Unambiguous - When the requirements are
correctly understood then only it is possible to
write an unambiguous SRS.
► Complete - To make the SRS complete, it should
be specified what a d e v e l o p e r wants to create a
software.
 Characteristics of SRS

► Consistent: It should be with

consistent reference to the functionalities
identified.

► Specific: The requirements should

►beTraceable: mentioned
What isspecifically.
the need for
mentioned requirement? This should be
correctly identified.
Requirement Gathering
Challenges

It refer to the obstacles and difficulties faced

during the process of collecting, documenting, and
understanding the needs and expectations of
stakeholders for a particular project or product.
• Below are the some challenges faced during the
requirement gathering of a software:

Communication Problem
Changing Requirements
Requirement are poorly defined
Stakeholders change their minds
Incomplete Requirements
Lack of User Involvement
Undocumented Process
Solution:
Requirement Engineering Process

►Requirements Engineering is the process of

identifying, eliciting, analyzing, specifying,
validating, and managing the needs and
expectations of stakeholders for a software
system.
 Feasibility
Studies

A feasibility study is a study ,made to

decide whether or not the proposed
system is worthwhile.
 Feasibility
Studies
Focus:
► If the contributes to organizational

system

► objectives;
If the system can be engineered using
current technology and within budget;

►If the system can be integrated with other systems

that are used;
 Feasibility
Studies
Questions for people in the organization
► What if the system wasn’t implemented?

► What are current process problems?

► How will the proposed system help?

► What will be the integration problems?
► Is new technology needed? What skills?
► What facilities must be supported by the
proposed system?
 Feasibility
Types:
Studies
► Technical Feasibility: It is the measure
of technical resources such as
hardware components, software techniques
and skilled persons.

► Economical Feasibility: It is the

measure finances or funds are available for
proposed system.
 Feasibility
Studies
Types:

► Operational feasibility: It is a measure of

how well the solution of
problems
alternative orsolution a will
specific
work In the
.
organization.
 Feasibility
Studies
Types:

► Schedule feasibility: It is the establishment

of time limit for completion of the project.

► It is dependent upon available manpower

and economical support for the project.
Requirements Elicitation and Analysis

► Sometimes called requirements

elicitation, requirements discovery or requirements
gathering.

► Software engineers communicate with

customers to find out about the application
domain, the services that the system should
provide and the system's operational constraints.
Requirements Elicitation and Analysis

► Stakeholders:

► The person(s) who will affected by the system.

► Ex: End-user, Managers, System

maintenance engineers, Domain experts and trade
union.
 Requirements Elicitation and Analysis

Problems of requirements analysis:

► Stakeholders don't know what they really want.

► Stakeholders express requirements in their own terms.

► Different stakeholders may have

conflicting requirements.
► Organisational and political factors may
influence the system requirements.
Requirements Elicitation and Analysis Process

Requirements discovery:
► Interacting with stakeholders to their
discover requirements. Domain also
requirements are discovered at this stage.

Requirements classification and organisation:

► Groups related requirements and organizes
them into coherent clusters.
Requirements Elicitation and Analysis- Process

Prioritisation and negotiation:

► Prioritising requirements and
resolving requirements conflicts.

► If there are some unrealistic requirements

then negotiations are made.

Requirements documentation:
► Requirements are documented well (Standard
format).
Requirements Elicitation and
Analysis- Methods
► Interviewing

► Scenario

► View Point

► Use Cases

► Ethnography
Requirements Elicitation and Analysis- Methods

1. Interviewing:
► The requirement engineering team
communicates the stakeholders by asking them
various questions about the system and its use.

►Closed interviews where pre-defined set of

a questions are answered

..
Requirements Elicitation and Analysis- Methods

► Interviews are good for getting an overall

understanding of what stakeholders do and how they
might interact with the system.

►Interviewing is not always effective for understanding

domain requirements because requirements engineers may
struggle to grasp specific domain terminology.
 Requirements Elicitation and
Analysis- Methods

► Interviewing - Characteristics:
►The interviews should be conducted in a free environment and
they should be conducted with open minded approach.
► The requirement engineers should listen to stakeholders
with patience.
► Interviewee should started the discussion by asking
questions and the requirements should be gathered together.
 Requirements Elicitation and
Analysis- Methods
2. Scenario:
► A scenario is a scene that illustrates some
interaction with a proposed system.

► A scenario is a set of questions used during

requirements analysis to describe a specific use of a
proposed system.

►Scenarios capture the system, as viewed from the

outside, e.g., by a user, using specific examples.
 Requirements Elicitation and
Analysis- Methods
Scenario:
► A description of the starting situation;

►A description of the normal flow of events;

► A description of what can go wrong;

► Information about other concurrent activities;

►A description of the
state when the scenario finishes.
 Requirements Elicitation and
Analysis- Methods
3.View point:
► Viewpoints are a of structuring
way requirements to the the
represent different perspectives

►stakeholders.
Stakeholders of
may be classified under
different viewpoints.
 Requirements Elicitation and
Analysis- Methods
View point - Types:
►Interactor viewpoints: People or other systems that
interact directly with the system. In an ATM, the
customer's and the account database are interactor
VPs.
►Indirect viewpoints: Stakeholders who do not use the
system themselves but who influence the
requirements. Ex: Security Staff
 Requirements Elicitation and
Analysis- Methods
View point - Types:
►Domain viewpoints: Domain characteristics
and constraints that influence the requirements.

Ex: In Library system, the rules that are

to followed for reserving the book.
 Requirements Elicitation and
Analysis- Methods
3.Use cases:
►To identify individual interactions with
the system.

►Use cases are extensively used for requiretnents

elicitation.
 Requirements Elicitation and
Analysis- Methods
Use Case Diagram:
►Use case diagrams describe the functionality of a
system and users of the system.

► it provides a visual representation of how users

interact with a system.

►It serves as a blueprint for understanding the

functional requirements of a system from a user’s
perspective
•Actor: An external entity (like a user or another system)
that interacts with the system.
•Use Case: A specific interaction between an actor and
the system to achieve a goal.
•System Boundary: The line that separates what is
inside the system from what is outside, showing the
system's scope.
 Requirements Elicitation and
Analysis- Methods
► Class Diagram: It describes the static structure of a
system, or how it is structured rather than how it
behaves.
► Compartments: class name, attributes, and methods.

► Lines connecting classes illustrate associations,

showing relationships such as one-to-one or one-to-
many.
Requirements Elicitation and Analysis- Methods
Sequence Diagram: It show the flow of functionality
•A sequence diagram is the most commonly used
interaction diagram.

• A sequence diagram simply represents the

interaction between the objects in a sequential
order i.e. the order in which these interactions
occur.

•Sequence diagrams describe how and in what

order the objects in a system function.
The above sequence diagram depicts the sequence diagram for an emotion based music player:

1. Firstly the application is opened by the user.

2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and
predict the mood.
5. It then requests database for dictionary of possible
moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.
 Requirements Elicitation and
Analysis- Methods
► Activity Diagram:
Activity Diagrams are used to illustrate the flow
of control in a system and refer to the steps
involved in the execution of a use case.

An activity diagram portrays the control flow from

a start point to a finish point showing the various
decision paths that exist while the activity is
being executed.
Activity Diagram
Notations
Requirements Elicitation and Analysis- Methods
5. Ethnography:
► Ethnographic is a research technique, it is a
form of qualitative study that looks to examine
human behavior and cultures.

►The Role of Ethnographic Studies in Empirical

Software Engineering” aims to work through
solutions for adopting ethnography in practical
software engineering applications.
Requirements Verification and Validation
Verification: It refers to the set of tasks that ensures that the
software correctly implements a specific function.

 Verification is the process of checking that software

achieves its goal without any bugs.

 It is the process to ensure whether the product that is

developed is right or not.

 It verifies whether the developed product fulfills the

requirements that we have.

 Verification is simply known as Static Testing.

Requirements Verification and Validation

Validation: It refers to a different set of tasks that

ensures that the software that has been built is traceable
to customer requirements.

 It is the process of checking the validation of the

product i.e.
it checks what we are developing is the right
product.
it is a validation of actual and expected products.

 Validation is simply known as Dynamic Testing.

Requirements Verification and Validation
 Verification and Validation is an iterative process that
occurs throughout the software development life cycle.

 It is important to involve stakeholders and the

development team in the V&V process to ensure that
the requirements are thoroughly reviewed and tested.

 It’s important to note that V&V is not a one-time

process, but it should be integrated and continue
throughout the software development process and even
in the maintenance stage.

 Verification is followed by Validation.

Requirements Verification and Validation

Here are some of the activities that are involved in verification.

1. Inspections
2. Reviews
3. Walkthroughs
4. Desk-checking

Here are some of the activities that are involved in Validation.

5. Black Box Testing
6. White Box Testing
7. Unit Testing
8. Integration Testing
Verification and Validation
 Requirements Management
The requirement management process is the process of
managing changing requirements during the requirements
engineering process and system development.

After the details have been gathered for the Requirement

Management, it’s time to see whether the change needs to
be implemented or not. For this, we use the Requirement
Change Management process. In this, the three basic steps
that we follow are:

1. Problem analysis and change specification

2. Change analysis and costing
3. Change implementation
 Requirements Management

Advantages of the Requirement Management Process:

►Recognizing the need for change in the
requirements.
►Improved team communication.
►It helps to minimize errors at the early stage of the

development cycle.
System Models
 System models

The systems model is a process-oriented

representation that highlights the influences, or
flow, of information between modules.
A systems model describes how processes
interact and what operations these processes
perform, but it does not go into details as to
how these processes are implemented.
 Objectives
 To explain why the context of a system should be
modelled as part of the RE process
 To describe behavioural modelling, data modelling
and object modelling
 To introduce some of the notations used in the
Unified Modeling Language (UML)
Topics covered

 Context models
 Behavioural models
 Data models
 Object models
 Structured Method
 Model types
 Data processing model showing how the data
is processed at different stages
 Composition model showing how entities are
composed of other entities
 Architectural model showing principal sub-
systems
 Classification model showing how entities have
common characteristics
 Stimulus/response model showing the system’s
reaction to events
 Context models

 Context models are simple communication tools

used to illustrate the context of a business, a
system, or a process.
 The context is the environment in which the object
of our interest exists.
 Context models capture how the central object
interacts with its environment, be it exchanging
data, physical objects, or funds.
 These models can be used to confirm project scope,
identify potential impacts of changes, and start
requirements discovery.
 The context of an ATM
system Security
system
Branch
Account
accounting
database
system

Auto-teller
system
Branch
Usage
counter
database
system
Maintenance
system
 Process models
 A process model is a visual representation of a
process that helps organizations understand,
analyze, and improve their operations.
 Process models can be used to model the flow of
work in an organization, or the flow of activities in
a computer system or application.
 Process models are typically used to represent and
analyze, where work/activities occur repeatedly
and on a regular basis.
Elements of a Process Model
 Behavioural models
 Overall behavior of a system can be fully understood by
Behavioral model.
 Behavioral Model is specially designed to make us
understand behavior and factors that influence behavior of
a System.
 Two types of behavioural model are shown here
 Data processing models that show how data is
processed as it moves through the system
 State machine models that show the systems response to
external events
 Data-processing models

 Data flow diagrams are used to model

the system’s data processing
 These show the processing steps as data
flows through a system
 Simple and intuitive notation that
customers can understand
 Show end-to-end processing of data
Symbols Used in DFD are Shown in the
Chart Below
Symbols used in the state diagram are
shown in the chart below:
 Object models
 Object Model encompasses the principles of abstraction,
encapsulation, modularity, hierarchy, typing, concurrency
and persistence.
 Object Model basically highlights on the object and class.
 Main concepts related with Object Model are classes and
their association with attributes.
 Predefined relationships in object model are aggregation
and generalization (multiple inheritance).
 Object Modeling Technique (OMT) is a real-world-
based modeling approach for software modeling and
designing.
 Object models
 Various object models may be produced
 Inheritance models
 Aggregation models
 Interaction models
 Structured methods

 Structured methods are reflection tools.

 They are based on an order of logical thinking, a system
analysis that takes into the SDLC environment.
 Structured methods use a variety of notations such as
data-flow (DFDs) and state diagrams in order to build
models of different system aspects and thus help the
analyst understand the application.
 They also include guidance on how to identify and
model the relevant system and domain entities.
 However, for certain critical applications, they are
leading to the risk that, for example, important
constraints may remain undiscovered.
Structured methods in the
requirements process
Thanks, You