1

Gathering Requirements !

2
 Background
• Problem of scale is a key issue for SE
• 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 people
• Output : precise statement of what the future
system will do

3
 Background..
• Requirement - A condition or capability that must
be possessed by a system [IEEE]
• Identifying and specifying requirements necessarily
involves people interactions and therefore cannot be
automated!
• Req. phase ends with the Software Requirements
Specification (SRS) document
• SRS specifies what the proposed system should do

4
 Background..
• Requirements understanding is hard
– Visualizing a future system is difficult
– Capability of the future system not clear, hence
needs not clear
– Requirements change with time
–…
• Essential to do a proper analysis and
specification of requirements

5
 RE: What is this Phase For?
• Major misconception
– determining what client wants!
“I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!”
• Must determine client’s & user’s needs!
• Requirements Problems (that needs to be sorted out during RE)
– Incompleteness
– Ambiguity
– Inconsistency
• Outcome – the SRS
6
 7

Need for a Quality SRS …

WHY?
 Need for SRS
1. 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 communication
gap and specify user needs in a manner both can
understand

8
 Need for SRS…
2. Helps user understand his needs
– users usually do not always know their needs
– must analyze and understand the potential
– the goal is not just to automate a manual system,
but also to add value through IT
– The requirement process helps clarify needs of
the user
– Perhaps, the most important preposition for the
success of the software IT solution lies here

9
 Need for SRS…
• 3. SRS provides a reference for validation of
the final product
– Clear understanding about what is expected.
– Validation - “ SW satisfies the SRS “

10
 Need for SRS…
4. High quality SRS is essential for high Quality
Software
– Requirement errors get manifested in final s/w
– Requirements defects are not few
• 25% of all defects in one case; (54% of all defects found
after UT of which 45 % originated from req.)
• 80 defects in A7 that resulted in change requests
• 250-500 defects in previously approved SRSs.

11
 Need for SRS…
5. 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

12
 Need for SRS…
6. Form a basis for more close Effort and Time
Estimation
– Provide a detailed account of requirements

13
 Need for SRS…
7. Serve as a basis for Change Management and
Enhancement (Future Versions)

14
 Need for SRS…
An Example
• Cost of fixing requirement errors in req, design,
coding, acceptance testing and operation are 2, 5, 15,
50, 150 person-months
• After req. phase 65% req errors 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 of handling these errors?

15
 Functional

• A user should be able to browse

through the catalogue
• by selecting a topic in the
drop-down list
• on title or author name by
Types of providing desired string
Requirements
Non-Functional

• The system should be up for

24/7 and 365 days a year
• The system can be accessed
both from Windows and Linux
platforms
16
 Inception (Preparation)

Elicitation (Gathering)

Phases in Elaboration (Analysis)

RE Negotiation

Specification

Validation
17
 Preparing for RE

Framing the set Use suitable

Gather
of questions requirement
knowledge/com Recognize
Identify extracting gathering/Anal
mon wisdom multiple
Stakeholders functional and ysis techniques
about problem viewpoints
non-functional for carrying
domain
requirements out RE

18
 Interviewing

Questionnaires

Forms analyses
Requirements
JAD Meetings
Gathering and
Analysis Scenarios (User stories)
Techniques
Rapid prototyping

Use Case Modeling

W5H2 Analyses
19
 Scenarios (User Stories)
Illustrate the major events/actions to users

20
 Scenarios
• Illustrate the major events/actions to users

21
 Rapid Prototyping
• Allow users to “see” & use proposed solutions
• Develop specification from the prototype/
requirements
– proceed with rest of stages in waterfall model
• Prototype must be constructed & changed quickly
– key functionality
• omits things like scalability, error checking, saving, etc.
– do not spend a lot of time perfecting the code/structure
• it is OK if it hardly works or crashes every few minutes
• plan to throw it away! because you will!
– put in front of customer ASAP & modify in response

22
 5
WH 2 Analyses
• Purpose • Why do it?
• Requirements • What do they want?
• Accountability/Roles • Who is responsible?
• Location • Where will it be done?
• Time table • When will it be done
• Tasks/Steps • How will it be done?
• Resources • How much will it be
cost?

23
 Characteristics of an SRS
• Correct
• Complete
• Unambiguous
• Consistent
• Verifiable
• Traceable
• Modifiable
• Ranked for importance and/or stability

24
 Characteristics of an SRS …
• 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 requirement has exactly one meaning
– Without this, errors will creep in
– Important as natural languages often used

25
 Characteristics of an SRS
• Verifiability
– There must exist a cost effective way of checking if sw satisfies
requirements
• Consistent
– two requirements don’t contradict each other
• Traceable
– The origin of the req, and how the req relates to software elements
can be determined
• Ranked for importance/stability
– Needed for prioritizing in construction
– To reduce risks due to changing requirements

26
 Components of an SRS
• What should an SRS contain ?
– Clarifying this will help ensure completeness
• An SRS must specify requirements on
– Functional Requirements
– Non functional Requirements
– Constraints about problem and solution domains
– External interfaces
– User characteristics

27
 Functional Requirements
• Heart of the SRS document; this forms the bulk of
the specs
• Specifies all the functionality that the system should
support
• Outputs for the given inputs and the relationship
between them
• All operations the system is to do
• Must specify behavior for invalid inputs too

28
 Non Functional Requirements
• All the performance constraints on the software
system
– Generally on response time , throughput etc =>
dynamic
– Capacity requirements => static
– Must be in measurable terms (verifiability)
• Eg response time should be xx 90% of the time
• Reliability, fault tolerance, backup req.
• Security
• Scalability
29
 Other Constraints
• Factors in the client environment that restrict
the choices
• Some such restrictions
– Standard compliance and compatibility with other
systems
– Hardware Limitations
• Client machines, servers, networks, …
– Software platforms
• OS, browsers, databases, …

30
 External Interface
• All interactions of the software with people,
hardware, and s/w
• User interfaces are most important
• These should also be verifiable

31
 Specification Language
• Language should support desired char of the SRS
• Formal languages are precise and unambiguous
but hard to use and limited in scope
– Ex: VDM, B, Z, Larch, Object-Z
• Natural languages mostly used, with some
structure for the document
• Formal languages used for special features or in
highly critical systems

32
 Structure of an SRS
• Introduction
– Purpose , the basic objective of the system
– Scope of what the system is to do , not to do
– Overview
• Overall description
– Product perspective
– Product functions
– User characteristics
– Assumptions
– Constraints

33
 Structure of an SRS…
• Specific requirements
– External interfaces
– Functional requirements
– Non Functional requirements
– Other constraints
• Acceptable criteria
– desirable to specify this up front.
• This standardization of the SRS was done by IEEE.

34
An Example: ATM

35
 Recap (RE)
• Everything can be traced to the requirements
– It ensures that there aren’t any unnecessary
efforts.
– You can get answers for W5H2
– Help in assessing the current status and how to
move forward
– How to handle change management

36
the GOD be the best Software
Developer …

37
 Summary (RE)
• Requirements is about finding out what customer needs
• Process
– Inception (Preparation)
– Elicitation (Gathering)
– Elaboration (Analysis)
– Negotiation
– Specification
– Validation
• Key techniques
– Enquiry (Interviewing/Questionnaires)
– JAD meetings
– Scenarios / storyboards
– Rapid prototyping
– Use case modeling
• Deliverable: Requirement Specification Document (SRS)
38
Requirements Engineering ?

39