Chapter 3

Software
requirements analysis

1/36
Garbage in, garbage out ！

2/55
Review ： Waterfall model

Why to do?
What to do ？
How to do?

3/55
Requirements
 A requirement is an expression of desired behaviour
 Requirements focus on the customer needs, not on the
solution or implementation
 designate what behavior, without saying how that behavior
will be realized

4/55
Why Are Requirements Important?
 Top factors that caused project to fail
 incomplete requirements (13.1%)

 lack of user involvement (12.4%)

 lack of resources (10.6%)

 unrealistic expectations (9.9%)

 lack of executive support (9.3%)

 changing requirements and specifications (8.7%)

 lack of planning (8.1%)

 system no longer needed (7.5%)

 Requirements error can be expensive if not detected early

5/55
 Stage:
Requirements time
.1-.2

.5 Design

Coding
1

2 Unit test

5 Acceptance test

20 Maintenance

The relative cost of repairing

defects at
different stages of the life
cycle
6/55
Benefits of a high quality Consequences of low quality
requirements requirements

7/55
Benefits of a high quality
requirements
 Rework in the late development and maintenance phases is
greatly reduced.
 Enabling users to actively participate in the requirements
gathering process can make the product more attractive and
establish more loyal customer relationships.
 User participation can bridge the gap between user
expectations and developers' actual development.
 Writing requirements into clear and unambiguous documents
will greatly benefit system testing and ensure product quality.

8/55
Consequences of low quality
requirements
 Rewrite Software Requirements Specification (SRS)
document
 Redesign
 Re encoding
 Retest
 A developed software may be discarded
 Recall defective software products and related user
manuals
 Cost of product compensation or warranty
 The cost of reinstalling the new version
 The cost of re filing

9/55
Objectives
 Eliciting requirements from the customers
 Modeling requirements

 Reviewing requirements to ensure their quality

 Documenting requirements for use by the design and test

teams

10/55
 Process of requirement analysis

Requirement engineering

Requirement development Requirement management

Collecting Modeling Writing SRS validating

requirements
requirements

11/55
Process for Capturing Requirements
 Performed by the req. analyst or system analyst
 The final outcome is a Software Requirements
Specification (SRS) document

12/55
Requirements Elicitation
 Customers do not always understand what their needs
and problems are
 It is important to discuss the requirements with everyone
who has a stake in the system
 Come up with agreement on what the requirements are
 If we can not agree on what the requirements are, then the
project is doomed to fail

13/55
Stakeholders
 Clients: pay for the software to be developed
 Customers: buy the software after it is developed

 Users: use the system

 Domain experts: familiar with the software problem

 Market Researchers: conduct surveys to determine

future trends and potential customers
 Lawyers or auditors: familiar with government, safety,
or legal requirements
 Software engineers or other technology experts

14/55
Means of Eliciting Requirements
 Interviewing stake holders
 Reviewing available documentations

 Observing the current system (if one exists)

 learn about user's task in more details

 Interviewing user or stakeholders in groups

 Brainstorming with current and potential users

 ……

15/55
Types of Requirements
 Functional requirement: describes required behavior in
terms of required activities
 Quality requirement or nonfunctional requirement:
describes some quality characteristic that the software
must posses
 Design constraint: a design decision such as choice of
platform or interface components
 Process constraint: a restriction on the techniques or
resources that can be used to build the system

16/55
 Process of requirement analysis

Requirement engineering

Requirement development Requirement management

Collecting Modeling Writing SRS validating

requirements
requirements

17/55
 Requirements analysis / modeling

Structural analysis method

Object oriented analysis method
Prototyping method

18/55
Structural analysis method
   Structured Analysis, abbr. SA

19/55
Structured Analysis Modeling

Functionality model
Data model

E-R
diagram DFD
diagram
DD

STD

Behavior model

20/55
Functionality modeling——DFD
 DFD ： data flow diagram
A data-flow diagram (DFD) models functionality and the flow of data from
one function to another

actor input output actor

Software output
system actor

actor input output actor

21/55
 Graphic symbols in DFD ：

actor/external entity

process

data flow

data store

A bubble represents a process

An arrow represents data flow
A data store: a formal repository or database of
information
Rectangles represent actors: entities that provide input
data or receive the output result
22/55
 Equivalent graphic symbols

or actor

or or process

data flow

or or data store

23/55
Common actors
 The organization that obtains or provides data from the
system, such as the supplier, the seller, etc.
 Individuals who need to interact with the system, such as
customers, clerks.
 Other software systems that need to exchange data with
the system to be built.

24/55
Process
 Each process must:
 Has at least one input data flow;
 Has at least one output data flow;
 Input data flow and output data flow should be different.

25/55
Data flow
 From process to process
 From actor to process
 From process to actor
 From process to data store
 From data store to process

26/55
Without Without output
input
actor process 
process actor

actor

actor
data store Data flow
Data flow
actor must start
start
data store
actor
 must
or end
or end at
process
at
process
data store data store
27/55
 Hierarchical data flow diagram

F S F
DFD/L0

F 1 3 F
2
DFD/L1
F 1.1
2.1 2.3 3.1
1.2 1.3
2.2 2.4 3.2 3.3 F
DFD/L2.1 DFD/L2.2 DFD/L2.3
28/55
Video Rental System Example
 L0 DFD:

29/55
 L1 DFD:

30/55
 Data modeling——E-R diagram

 Entity-Relationship Diagrams
 A popular graphical notational paradigm for representing
conceptual models
 Has three core constructs
 An entity: depicted as a rectangle, represents a collection of
real-world objects that have common properties and
behaviours
 A relationship: depicted as an edge between two entities,
with diamond in the middle of the edge specifying the type of
relationship
 An attribute: an annotation on an entity that describes data or
properties associated with the entity

31/55
 E-R diagram

⑴ Entities eg ：Student Instructor, Class

,

32/55
 E-R diagram

⑵ Relations eg ： Enrolled in Teach

1 1 1 N M N

33/55
 E-R diagram

⑶ Attributes eg ： Name I D#
,

34/55
 E-R diagram
Example ：
sex speciality name sex

name ID ID grade
teacher student

1 N
teach study score
N M
course

ID name class hour

35/55
 Behavior modeling——STD diagram

 State transition diagram (STD)

 Equivalent to state transition matrix

t4 S1 S1 S2 S3
t1
t1 S1
t2 S2

S2 t3 S3 t3 S3
t4 S1
t2

36/55
 Requirements analysis / modeling

Structural analysis method

Object oriented analysis method
Prototyping method

37/55
Requirement analysis and modeling
 Structured analysis method
modeling: functionality model DFD
data model E-R diagram
behavior model STD

 Object oriented analysis method

modeling: functionality model
data model
dynamic model

38/55
Using UML for Object oriented modeling
 Review: 9 kinds of diagrams
 Modeling

 functionality model ——use case diagram

 data model——class diagram

 dynamic model——state diagram, sequence diagram,

collaboration diagram, and activity diagram

39/55
Example of —— use case diagram of library
management system

40/55
41/55
42/55
 Requirements analysis / modeling

Structural analysis method

Object oriented analysis method
Prototyping method

43/55
Prototyping method
 To elicit the details of proposed system
 To get feedback from potential users about
 what aspects they would like to see improve
 which features are not so useful
 what functionality is missing

 Determine whether the customer's problem has a

feasible solution

44/55
Prototyping Example
 Prototype for building a tool to track how much a user
exercises each day
 Graphical representation of the first prototype, in which
the user must key in the day, month and year

45/55
 The second prototype shows a more interesting and
sophisticated interface involving a calendar
 User uses a mouse to select the month and year
 The system displays the chart for that month, and the user
selects the appropriate date in the chart

46/55
 The third prototype shows that instead of calendar, the
user is presented with three slide bars
 User uses the mouse to slide each bar left or right
 The box at the bottom of the screen changes to show the
selected day, month, and year

47/55
Approaches to Prototyping
 Throwaway approach
 Developed to learn more about a problem or a proposed
solution, and that is never intended to be part of the
delivered software
 Allow us to write “quick-and-dirty”
 Evolutionary approach
 Developed not only to help us answer questions but also
to be incorporated into the final product
 Prototype has to eventually exhibit the quality
requirements of the final product
 Both techniques are sometimes called rapid
prototyping

48/55
 Process of requirement analysis

Requirement engineering

Requirement development Requirement management

Collecting Modeling Writing SRS validating

requirements
requirements

49/55
IEEE Standard for SRS
1. Intodruction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
2. General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
4. Appendices
50/55
 Process of requirement analysis

Requirement engineering

Requirement development Requirement management

Collecting Modeling Writing SRS validating

requirements
requirements

51/55
Validation SRS
 Check that the requirements-specification document
corresponds to the requirements-definition
 Make sure that if we implement a system that meets the
specification, then the system will satisfy the customer's
requirements
 Ensure that each requirement in the definition document
is traceable to the specification

52/55
 Process of requirement analysis

Requirement engineering

Requirement development Requirement management

Collecting Modeling Writing SRS validating

requirements
requirements

53/55
Requirement management
 Requirement management should track
 the requirements that define what the system should do
 the design modules that are generated from the
requirement
 the program code that implements the design
 the tests that verify the functionality of the system
 the documents that describe the system

 It provides the threads that tie the system parts

together

54/55
Requirement tracking
 Horizontal threads show the coordination between
development activities

55/55