Chapter 3 requirements

Requirements1
Software Requirements Analysis and
Specification

Introduction
Requirements3
Identifying requirements -> critical, they are in people minds
For small scale, understand and specifying requirements is easy
For large problem - very hard; probably the hardest, most
problematic and error prone
Input : user needs in minds of some people
Requirements Phase: translates client ideas (from their minds)
into formal document
Output : precise statement of what the future system will do
Origin of S/w System ---> Need of clients
Creation of S/w system ---> Developers
Completed S/w system ---> used by end users

Software Requirements
Requirements4
Identifying and specifying req. necessarily involves people
interaction
Cannot be automated
Requirement (IEEE): A condition or capability that must be
possessed by a system, condition or capability that must be met
Req. phase ends with a Software Requirements Specification (SRS)
document
Goal: SRS specifies what the proposed system should do,
without describing how the software will do it

Requirements5
Requirements understanding is hard
Visualizing a future system is difficult
Capability of the future system not clear
Requirements change with time
…
Essential to do a proper analysis and specification of
requirements

Need for SRS
Requirements6
SRS establishes basis of agreement between the user
and the supplier.
Users needs have to be satisfied, but user may not understand
software
Developers will develop the system, but may not know about
problem domain
SRS is the medium to bridge the comm. gap and specify user
needs in a manner both can understand

Need for SRS…
Requirements7
SRS helps user understand his needs.
Users do not always know their needs initially
User must analyze and understand the needs
The req. process helps clarify needs
SRS provides a reference for validation of the final
product
SRS states clear understanding about what is expected.
Validation - “ SW satisfies the SRS “
High quality SRS essential for high Quality SW
Requirements defects are not few
Requirement errors get manifested in final s/w
To satisfy the quality objective, must begin with high quality SRS without
errors

Need for SRS…
Requirements8
Good SRS reduces the development cost
SRS errors are expensive to fix later
Req. changes can cost a lot (up to 40%)
Good SRS can minimize changes and errors
Substantial savings; extra effort spent during req. saves multiple
times that effort
Example
Cost of fixing errors in req. , design , coding , acceptance
testing and operation are 2 , 5 , 15 , 50 , 150 person-months

Need for SRS…
Requirements9
Example …
After req. phase 65% req. errs detected in design , 2% in
coding, 30% in Acceptance testing, 3% during operation
If 50 requirement errors are not removed in the req. phase, the
total cost
32.5 *5 + 1*15 + 15*50 + 1.5*150 = 1152 hrs
If 100 person-hours invested additionally in req, to catch these
50 defects , then development cost could be reduced by 1152
person-hours.
Net reduction in cost is 1052 person-hours

Requirements Process
Requirements10
Sequence of steps that need to be performed to convert user
needs into SRS
Process has to elicit needs and requirements and clearly
specifies it
Basic activities
Problem or Requirement Analysis
Requirement Specification
Validation
Analysis involves elicitation and is the hardest

Requirements Process..
Requirements11
Client/
User needs
Analysis
Specification
Validation
Validated SRS

Requirement process..
Requirements12
Process is not linear, it is iterative and parallel
Overlap and feedback between these activities
Specification itself may help analysis
Validation activity reveals problems in the SRS leads to further
analysis and specification
For complex systems – use Divide and conquer strategy
to decompose into small parts, understand each part and relation
between parts

Requirements Process…
Requirements13
Problem Analysis
Starts with high-level problem statement
Model problem domain and environment
Focus: Understanding the desired systems behavior,
constraints, inputs and outputs
Techniques like DFD, Object diagrams etc. used in the
analysis
Methods of Analysis and Design activities are same but:
Analysis deals with Problem Domain (understanding of system)
Design deals with Solution Domain (optimizing the system)

Requirements14
Requirements Specification:
Focus: Clearly specifying the requirements
Analysis structures helps in specification, but the transition is not
final
Transition from analysis to specification is hard
In specs, external behavior are specified
Input: Large amount of information generated via. Analysis
Goal: Properly organizing, removing redundancies, and describing
requirements
Issues like representation, specification languages and tools are
addressed

SRS - Characteristics
Requirements15
Correct
Complete
Unambiguous
Verifiable
Consistent
Ranked for importance and/or stability
Modifiable
Traceable

Characteristics…
Requirements16
Correctness
Each requirement accurately represents some desired feature in the
final system
Completeness
All desired features/characteristics specified
Hardest to satisfy
Completeness and correctness strongly related
Unambiguous
Each req. has exactly one meaning
Without this, errors will creep in
Important as natural languages often used
Verifiability
There must exist a cost effective way of checking if s/w satisfies
requirements

Requirements17
Consistent
two requirements don’t contradict each other
Ranked for importance/stability
Needed for prioritizing in construction
To reduce risks due to changing requirements
Modifiable
Accepts changes easily in structure and style by preserving
completeness and correctness
Traceable
Traceability aids verification and validation
Forward Traceability: Req. should be traceable to some design and
code elements
Backward Traceability: trace design and code elements to the
req. they support

Requirements Validation
Focus: ensures all req. are stated in SRS
Checks for the quality of SRS
Result: Produces the validated SRS at the end
Requirements18

Problem Analysis
Requirements19
Aim: Understand the needs, requirements, and constraints on the
software
Analysis involves:
interviewing client and users
reading manuals
studying current systems
helping client/users understand new possibilities
Like becoming a consultant to help customers understand the
need
Must understand the working of the organization , client and users

Interpersonal issues are important
Communication skills are very important
Basic principle: problem partition
Partition w.r.t what?
Object - OO analysis
Function - Structural analysis
Events in the system – event partitioning
System defined from multiple point of view - Projection
Requirements20

Requirements21
Informal Approach:
No defined methodology
Widely used
Analyst acts as listener, absorbing the information provided
Information is obtained by:
Interacting with clients, end users
Brainstorming
Study of existing documents
Questionnaires,…
Problem in the Analyst minds are directly translated to SRS

Data Flow Modeling
Requirements22
Widely used;
focuses on functions performed in the system
Views a system as a network of data transforms through which the
data flows
Uses data flow diagrams (DFDs) and functional decomposition in
modeling
SSAD methodology uses DFD to organize information, and guide
analysis

Data flow diagrams
Requirements23
It shows flow of data processed within a system based on
inputs and outputs
used as a first step toward redesigning a system
provide a graphical representation of a system at any
level of detail
creating an easy-to-understand picture of what the
system does

Focus on what transformations happen, how they are done is
not important
Usually major inputs/outputs shown, minor are ignored in
this modeling
No loops , conditional thinking , …
DFD is NOT a flow chart, no algorithmic design/thinking
DFD considers only Sink/Source , external files
Requirements24

25
External Entity
(Rectangle)
• Actors,
• Data Source/ Sink,
• Originator/ consumer of data,
• Produce and consume data that flows between
the entity
•They are typically placed at the boundaries of the
diagram
•Indicate a system or subsystem
Process
(Circle or Bubble)
• Data transforms - transform incoming data to
outgoing data
• Changes or transforms data flows.
• Processes are typically oriented from top to
bottom and left to right
Data Store • Data Store - does not generate any operations
•holds data for later access
•consist of files or documents
•Input flows to DS: - change the stored data.
•Output flows: data retrieved from the store.
Data Flow Data Travels
•Movement of data between external entities,
processes and data stores

DFD Conventions
Requirements27
External files shown as labeled straight lines
Need for multiple data flows by a process represented by * (and)
OR relationship represented by +
All processes and arrows should be named
Processes should represent transforms, arrows should represent
some data

Drawing a DFD for a system
Requirements28
Identify inputs, outputs, sources, sinks for the system
Work your way consistently from inputs to outputs
Identify a few high-level transforms to capture full
transformation
If get stuck, reverse direction
When high-level transforms defined, then refine each
transform with more detailed transformations

Drawing a DFD for a system..
Requirements29
Never show control logic; if thinking in terms of
loops/decisions, stop & restart
Label each arrows and bubbles; carefully identify inputs and
outputs of each transform
Make use of + & *
Try drawing alternate DFDs

Drawing a DFD – quick go
through
Requirements30
 If get stuck, reverse direction
 If control logic comes in , stop and restart
 Label each arrows and bubbles
 Make use of + & *
 Try drawing alternate DFDs

Leveled DFDs
Requirements31
DFD of a system may be very large
Can organize it hierarchically
Start with a top level DFD with a few bubbles
then draw DFD for each bubble
Preserve I/O when “exploding” a bubble so consistency preserved
Makes drawing the leveled DFD a top-down refinement process,
and allows modeling of large and complex systems

Level-0 DFD
It is also known as context diagram.
It’s designed to be an abstraction view, showing the system as a
single process with its relationship to external entities.
It represent the entire system as single bubble with input and
output data indicated by incoming/outgoing arrows.
Requirements32

1-Level DFD
In 1-level DFD, context diagram is decomposed into
multiple bubbles/processes.
In this level, we highlight the main functions of the system
Breakdown the high level process of 0-level DFD into
subprocesses.
Requirements34

2-level DFD:
2-level DFD goes one step deeper into parts of 1-level DFD.
It can be used to plan or record the specific/necessary detail
about the system’s functioning.
Requirements36

Data Dictionary
Requirements38
In a DFD, arrows are labeled with data items
Data dictionary defines data flows in a DFD
Shows structure of data; structure becomes more visible
when exploding
Can use regular expressions to express the structure of
data

Data Dictionary Example
Requirements39
For the timesheet DFD
Weekly_timesheet = employee_name + id + [regular_hrs
+ overtime_hrs]*
Pay_rate = [hourly | daily | weekly] + dollar_amt
Employee_name = last + first + middle
Id = digit + digit + digit + digit

DFD drawing – common
errors
Requirements40
Unlabeled data flows
Missing data flows
Extraneous data flows
Consistency not maintained during refinement
Missing processes
Too detailed or too abstract
Contains some control information

Chapter 3 requirements

More Related Content

What's hot

Similar to Chapter 3 requirements

Recently uploaded

In this document

Chapter 3 requirements