LECTURE -6

SOFTWARE ENGINEERING
REQUIREMENT ANALYSIS AND SPECIFICATION

1
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.
Consists of two distinct activities:
 Requirements Gathering and Analysis
 Specification
The person who undertakes requirements analysis and specification:
 Known as systems analyst::
 Collects data pertaining to the product
 Analyzes collected data:
 To understand what exactly needs to be done.
 Writes the Software Requirements Specification (SRS) document.

2
REQUIREMENTS ANALYSIS

The SRS document is reviewed by the customer.

 Reviewed SRS document forms the basis of all future development activities.
Requirements analysis consists of two main activities:
 Requirements gathering
 Analysis of the gathered requirements
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

3
REQUIREMENTS GATHERING

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
Requirement Gathering is also known as requirements elicitation.
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

4
REQUIREMENTS GATHERING ACTIVITIES
1. Studying the existing documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis
In the absence of a working system,
 Lot of imagination and creativity are required.
Interacting with the customer to gather relevant data:
 Requires a lot of experience.
Some desirable attributes of a good system analyst:
 Good interaction skills,
 Imagination and creativity,
 Experience.

5
ANALYSIS OF 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
Inconsistent Requirements
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
Incomplete requirements (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. 6
ANALYSIS OF GATHERED REQUIREMENTS
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 complexities might arise while solving the problem?
Some anomalies and inconsistencies can be very subtle:
 Escape even most experienced eyes.
 If a formal model of the system is constructed,
 Many of the subtle anomalies and inconsistencies get detected.
After collecting all data regarding the system to be developed,
 Remove all inconsistencies and anomalies from the requirements,
 Systematically organize requirements into a Software Requirements
Specification (SRS) document.

7
SOFTWARE REQUIREMENT SPECIFICATIONS
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
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 controversies are settled by referring the SRS document.

8
 SRS DOCUMENT

Software Requirements Specification: A Contract 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.
The SRS document is known as black-box specification:
 The system is considered as a black box whose internal details are not known.
 Only its visible external (i.e. input/output) behaviour is documented.

Output
Input Data S Data

9
 REQUIREMENT ENGINEERING

Inception—ask a set of questions that establish …

o basic understanding of the problem
o the people who want a solution
o the nature of the solution that is desired, and
o the effectiveness of preliminary communication 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

10
 REQUIREMENT ENGINEERING

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

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

11
 ELICITING REQUIREMENTS
UML ACTIVITY DIAGRAM FOR ELICITING REQUIREMENT

Co n d u c t FA ST
m e e t in g s

Ma k e lis t s o f
f u n c t io n s , c la s s e s

Ma k e lis t s o f
c o n s t r a in t s , e t c .

f o r m a l p r io rit iz a t io n ?
El i c i t re q u i re m e n t s
y es no

Us e Q FD t o in f o r m a lly d e f in e a c t o r s
p r io r it iz e p r io r it iz e
r e q u ir e m e n t s r e q u ir e m e n t s

draw us e-c as e
w r it e s c e n a r io
d ia g r a m

Cr e a t e Us e -c a s e s
c o m p le t e t e m p la t e

12
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

Models for Analysis

o Scenario-based elements
o Functional—processing narratives for software functions
o Use-case—descriptions of the interaction between an “actor” and the
system
o Class-based elements
o Implied by scenarios
o Behavioral elements
o State diagram
o Flow-oriented elements
o Data flow diagram
13
USE-CASE DIAGRAM
(SAFE HOME SYSTEM)

A r m s / d is a r m s
system

A ccesses system sensors

v i a In t e r n e t

hom eow ner

Re s p o n d s t o
a la r m e v e n t

En c o u n t e r s a n
e r r o r c o n d it io n

system Re c o n f i g u r e s s e n s o r s
a d m in is t r a t o r a n d r e la t e d
system features

14
CLASS DIAGRAM
(SAFE HOME SYSTEM)

Sensor

name/id
type
location
area
characteristics

identify()
enable()
disable()
reconfigure()

15
STATE DIAGRAM
(SAFE HOME SYSTEM)

Reading
Commands State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables

Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

16
17