1

Requirement Analysis
and Specification
UNIT – 4
 2
Requirements Analysis and
Specification

▶Goals of requirements analysis and

specification phase:
▶Fully understand the
user requirements.
▶Remove inconsistencies, anomalies, etc.
from requirements.
▶Document requirements properly in an
SRS document.
 3
Requirements Analysis and
Specification

▶Consists oftwo distinct activities:

▶Requirements Gathering and
Analysis
▶Specification
 Who C arries Out Requirements 4
Analysis and Specification?

▶ The person who undertakes requirements

analysis and specification:
▶Known as Systems Analyst:
▶Collects data pertaining to the product
▶Analyses collected data:
▶To understand what exactly needs to be done.
▶Writes the Software Requirements
Specification (SRS) document.
 5
Requirements Analysis and
Specification

▶Final output of this phase:

▶Software
Requirements Specification (SRS)
Document.
▶The SRS document is reviewed by the
customer.
▶Reviewed SRS document forms the basis of
all future development activities.
 6
Requirements Analysis

▶Requirements analysis consists of

two main activities:
▶Requirements gathering
▶Analysis of the gathered
requirements
 7
Requirements Analysis

▶Analyst gathers requirements through:

▶Observation of existing systems,
▶Studying existing procedures,
▶Discussion with the customer and end-
users,
▶Analysis of what needs to be done, etc.
 8
Requirements Gathering

▶ Also known as requirements elic itation.

▶ If the project is to automate some existing procedures
▶ e.g., automating existing manual accounting
activities,
▶ The task of the system analyst is a little easier
▶ Analyst can immediately obtain:
▶ input and output formats
▶ accurate details of the operational procedures
 9
Requirements Gathering Activities

▶ Studying the existing documentation

▶ Interview
▶ Task analysis
▶ Scenario analysis
▶ Form analysis
 10
Requirements Gathering (CONT.)

▶ In theabsence of a working system,

▶Lot of imagination and creativity are
required.
▶ Interacting with the customer to gather
relevant data:
▶Requires a lot of experience.
 12
Analysis of the Gathered
Requirements
▶ Main purpose of requirements analysis:
▶Clearly understand the user requirements,
▶Detect inconsistencies, ambiguities, and
incompleteness.
▶ Incompleteness and inconsistencies:
▶ Resolved through further discussions with the end-
users and the customers.
 13
Inconsistent Requirement

▶ Some part of the requirement:

▶ contradicts with some other part.
▶ Example:
▶ One customer says turn off heater and open
water shower when temperature >100 C
▶ Another customer says turn off heater and turn
ON cooler when temperature >100 C
 14
Incomplete Requirement

▶ Some requirements have been omitted:

▶ Possibly due to oversight.
▶ Example:

▶ The analyst has not recorded:

when temperature falls below 90 C

▶heater should be turned ON

▶water shower turned OFF.
 Analysis of the Gathered 15
Requirements (CONT.)

▶ Requirements analysis involves:

▶ Obtaining a clear, in-depth understanding of the
product to be developed,
▶ Remove all ambiguities and inconsistencies from
the initial customer perception of the problem.
 Analysis of the Gathered 18
Requirements (CONT.)

▶ Experienced systems analysts know -

often as a result of painful experiences ---
▶ Without a clear understanding of the problem, it is
impossible to develop a satisfactory system.
 Analysis of the Gathered 19
Requirements (CONT.)

▶ Several things about the project should be clearly

understood by the analyst:
▶ What is the problem?
▶ Why is it important to solve the problem?
▶ What are the possible solutions to the problem?
▶ What c omplexities might arise while solving the
problem?
 23
Requirement Engineering
 24
Requirement Engineering
 25
Requirement Engineering
 26
Requirement Engineering
 27
Requirement Engineering
 28
Requirements Engineering-I

▶ Inception—ask a set of questions that establish …

▶ basic understanding of the problem
▶ the people who want a solution
▶ the nature of the solution that is desired, and
▶ the effectiveness of preliminary communica tion and
collaboration between the customer and the developer
▶ Elicitation—elicit requirements from all stakeholders
▶ Elaboration—create an analysis model that identifies data,
function and behavioral requirements
▶ Negotiation—agree on a deliverable system that is realistic
for developers and customers
 29
Requirements Engineering-II

▶ Specification—can be any one (or more) of the following:

▶ A written document
▶ A set of models
▶ A formal mathematical
▶ A collection of user scenarios (use-cases)
▶ A prototype
▶ Validation—a review mechanism that looks for
▶ errors in content or interpretation
▶ areas where clarification may be required
▶ missing information
▶ inconsistencies (a major problem when large products or systems are
engineered)
▶ conflicting or unrealistic (unachievable) requirements.
▶ Requirements management
 36
Quality Function Deployment

▶ Function deployment determines the “value” (as

perceived by the customer) of each function
required of the system
▶ Information deployment identifies data objects and
events
▶ Task deployment examines the behavior of the
system
▶ Value analysis determines the relative priority of
requirements
 37
Quality Function Deployment
 38
Requirement Analysis Model
 39
Building the Analysis Model

▶ Elements of the analysis model

▶ Scenario-based elements
▶ Functional—processing narratives for software functions
▶ Use-case—descriptions of the interaction between an “actor”
and the system
▶ Class-based elements
▶ Implied by scenarios
▶ Behavioral elements
▶ State diagram
▶ Flow-oriented elements
▶ Data flow diagram
 40
Elements of the analysis model
 41
Elements of the analysis model
 42
Elements of the analysis model
 43
Analysis rule of Thumb
 44
Analysis Modelling Approaches
 45
Use-Cases

▶ A collection of user scenarios that describe the thread of usage of a system

▶ Each scenario is described from the point-of-view of an “actor”—a person or device
that interacts with the software in some way
▶ Each scenario answers the following questions:
▶ Who is the primary a ctor, the secondary a ctor (s)?

▶ What are the a ctor’s goals?

▶ What preconditions should exist before the story begins?
▶ What main tasks or functions are performed by the actor?
▶ What extensions might be considered as the story is described?
▶ What variations in the a ctor’s interaction are possible?
▶ What system information will the actor acquire, produce, or change?
▶ Will the actor have to inform the system about changes in the external
environment?
▶ What information does the a ctor desire from the system?
▶ Does the actor wish to be informed about unexpected changes?
 46
Use-Case Diagram
 47
Class Diagram for Sensor

From the SafeHome system …

 48
State Diagram
 49
Activity Diagram
 50
Analysis Patterns

Pattern name: A descriptor that captures the essence of the pattern.

Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address
the problem.
Forces and context: A description of external issues (forces) that can affect
how the pattern is used and also the external issues that will be resolved when
the pattern is applied.
Solution: A description of how the pattern is applied to solve the problem with
an emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what
trade-offs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use
of known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is
 51
Negotiating Requirements

▶ Identify the key stakeholders

▶ These are the people who will be involved in the negotiation
▶ Determine each of the stakeholders “win conditions”
▶ Win conditions are not always obvious
▶ Negotiate
▶ Work toward a set of requirements that lead to “win-win”
 52
Validating Requirements - I

▶ Is each requirement consistent with the overall objective for the

system/product?
▶ Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
▶ Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
 53
Validating Requirements - II

▶ Is each requirement achievable in the technical environment that

will house the system or product?
▶ Is each requirement testable, once implemented?
▶ Does the requirements model properly reflect the information,
function and behavior of the system to be built.
▶ Has the requirements model been “partitioned” in a way that
exposes progressively more detailed information about the system.
▶ Have requirements patterns been used to simplify the requirements
model. Have all patterns been properly validated? Are all patterns
consistent with customer requirements?
 54
Software Requirement Specification
 55
Software Requirement Specification

▶ Main aim of requirements specification:

▶ Systematically organize the requirements arrived
during requirements analysis.
▶ Document requirements properly.
▶ The SRS document is useful in various contexts:
▶ Statement of user needs
▶ Contract document
▶ Reference document
▶ Definition for implementation
 56
Software Requirement Specification
– A Contract Document
▶ Requirements document is a reference document.
▶ SRS document is a contract between the development team
and the customer.
▶ Once the SRS document is approved by the customer,
▶ Any subsequent c ontroversies are settled by referring the
SRS document.
▶ Once customer agrees to the SRS document:
▶ Development team starts to develop the product according
to the requirements recorded in the SRS document.
▶ The final product will be acceptable to the customer:
▶ As long as it satisfies all the requirements recorded in the SRS
document.
 57
Software Requirement Specification
 58
Software Requirement Specification
 59
Software Requirement Specification
 61
Problems without SRS