Requirements

Specification and
Analysis I

1
Goal of Requirements Analysis &
Specification
The goal of the requirements analysis
and specification phase is to clearly
understand the customer requirements
and to systematically organize the
requirements into a document called the
Software Requirements
Specification(SRS) document.
2
 Requirements Analysis &
Specification
• The engineers who gather and analyze customer
requirements, then write the requirements
specification document are known as system analysts in
the software industry.
• On understanding the precise user requirements, the
analysts analyze the requests to weed out
inconsistencies, anomalies and incompleteness.
• They then proceed to write the SRS.
• The SRS document is the final outcome of the
requirements analysis and specification phase.
3
 Requirements Analysis &
Specification Phases
1)Requirements Gathering &
Analysis:
a)Requirements gathering
b)Requirements analysis
2)Requirements Specification

4
 Requirements Gathering
• Popularly known as requirements elicitation.
• Objective of the requirements gathering task
is to collect the requirements from the
stakeholders.
• A stakeholder is a source of the requirements
and is usually a person, a group of persons
who either directly or indirectly are
concerned with the software.

5
 Analyst Gathering
Requirements Procedure
• Studying existing documents(SOP provided)
• Interview(Delphi Technique used)
• Task Analysis(Service supported by a s/w)
• Scenario Analysis
• Requirements activities such as
questionnaires, surveys, task analysis,
scenario analysis and form analysis.
6
 Requirements Gathering
• The main purpose of this activity is to analyse
the gathered requirements to remove all
ambiguities(anomalies), incompleteness and
inconsistencies from the gathered customer
requirements and to obtain a clear
understanding of the software to be
developed.

7
 Users of SRS Document
 Users, customers, and marketing
personnel
 Software developers
 Test engineers
 User documentation writers
 Project managers
 Maintenance engineers
8
 What are Requirements?
• A Requirement is:

– A capability or condition required from the system.

• What is involved in requirements analysis and

specification?
– Determine what is expected by the client from the
system. (Gather and Analyze)
– Document those in a form that is clear to the client as
well as to the development team members.
(Document)
 Why Spend Time and Resources to
develop an SRS Documentment Analysis
• Forms an agreement between the
customers and the developers
• Reduces future reworks
• Provides a basis for estimating costs and
schedules
• Provides a baseline for validation and
verification
• Facilitates future extensions
10
 Understanding and specifying requirements
For toy problems: understanding and specifying
requirements is rather easy…
For industry-standard problems: Probably the
hardest, most problematic and error prone among
development tasks…
The task of requirements specification :
Input: User needs that are hopefully fully understood by
the users.
Output: Precise statement of what the software will do.
 Requirements for Products

• When a company plans to develop a

generic product:

– Who gives the requirements?

• The sales personnel!

 Requirements Analysis and Specification
• Requirements Gathering:
– Fully understand the user requirements.

• Requirements Analysis:
– Remove inconsistencies, anomalies, etc. from
requirements.
• Requirements Specification:
– Document requirements properly in an SRS document.
 What are the Uses of an SRS Document?
• Establishes the basis for agreement between the
customers and the suppliers
• Forms the starting point for development.
• Provide a basis for estimating costs and
schedules.
• Provide a basis for validation and verification.
• Provide a basis for user manual preparation.
• Serves as a basis for later enhancements.
 Forms A Basis for User Manual
• The SRS serves as the basis for writing User
Manual for the software:

– User Manual: Describes the functionality from

the perspective of a user --- An important
document for users.

– Typically also describes how to carry out the

required tasks with examples.
• SRS intended for a diverse audience:
– Customers and users use it for validation, contract, ...
– Systems (requirements) analysts SRS Document:
Stakeholders
– Developers, programmers to implement the system
– Testers use it to check whether requirements have been met
– Project Managers to measure and control the project
– Maintenance Engineers to understand the functionalities
supported by the system
• Different levels of detail and formality is needed for each
audience
• Different templates for requirements specifications used by
companies:
– Often variations of IEEE 830
User needs Requirement process..

Gathering
• Specification
Analysis and review may
Specification
lead to further
Review
gathering and
analysis.
SRS Document
 How to Gather Requirements?
needs
• Observe existing (manual) systems,
Gathering

• Study existing procedures, Analysis

• Discuss with customer and end-users, Specification

Review
• Input and Output analysis
SRS
• Analyze what needs to be done Docume
nt
 Requirements Gathering Activities
• The important ways in which an experienced
analyst gathers requirements are:

• 1. Study existing documentation

• 2. Interview

• 3. Task analysis

• 4. Scenario analysis

• 5. Form analysis
 Requirements Gathering (CONT.)

• 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.
 Requirements Gathering (CONT.)

• Some desirable attributes of a good

requirements analyst:

– Good interaction skills,

– Imagination and creativity,

– Experience…
 Case Study: Automation of Office Work at CSE Dept.

• The academic, inventory, and financial

information at the CSE department:
– At present carried though manual processing by two
office clerks, a store keeper, and two attendants.

• Considering the low budget he had at his

disposal:
– The HoD entrusted the work to a team of student
volunteers.
 Case Study: Automation of Office Work at CSE
Dept.
• The team was first briefed by the HoD:
– Concerning the specific activities to be automated.

• The analysts first discussed with the two office

clerks:
– Regarding their specific responsibilities (tasks) that were
Intervie
to be automated. w

• The analyst also interviewed student and faculty

representatives who would also use the software.
 Case Study: Automation of Office Work at
CSE Dept.
• For each task that a user needs the software
to perform, they asked: Task and Scenario
Analysis

– The steps through which these are to be performed.

– The various scenarios that might arise for each task.

• Also collected the different types of forms that

were being used. Form
Analysis
Case Study: Automation of Office Work at CSE Dept.
• The analysts understood the requirements for the
system from various user groups: Requirements
Analysis
– Identified inconsistencies, ambiguities, incompleteness.

• Resolved the requirements problems through

discussions with users:
– Resolved a few issues which the users were unable to
resolve through discussion with the HoD.

• Documented the requirements in the form of an

SRS document. Requirements
Specification
 Analysis of Gathered Requirements
needs
• Main purpose of req. analysis: Gathering

• Clearly understand user requirements, Analysis

Specification

• Detect inconsistencies, ambiguities, and Review

incompleteness. SRS
Docume
nt

• Incompleteness and inconsistencies:

– Resolved through further discussions with the
end-users and the customers.
 Ambiguity
“When temperature becomes high, start
cooler”
Do you notice any problems?
• Above what threshold we consider
the temperature to be high?
 Inconsistent Requirement
• Some part of the requirement:
– contradicts some other requirement.
• Example:
– One customer says turn off heater when
temperature > 100°C
– Another customer says turn ON cooler when
temperature > 100°C . It says do not turn off the
heater
• Some requirements not included:
– Possibly due to oversight. Incomplete
Requirement
• Example:
– The analyst has not recorded that when
temperature falls below 90° C :
• heater should be turned ON
• water shower turned OFF.
 Analysis of the Gathered Requirements

• Requirements analysis involves:

– Obtaining a clear, in-depth understanding of
the software to be developed

– Remove all ambiguities and inconsistencies

from the initial customer perception of the
problem.
 Analysis of the Gathered Requirements (CONT.)

• It is quite difficult to obtain:

– A clear, in-depth understanding of the

problem:

• Especially if there is no working model of

the problem.
 Analysis of the Gathered Requirements
(CONT.)

• Experienced analysts take considerable

time:
– Clearly understand the exact requirements
the customer has in his mind.
 Analysis of the Gathered 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 Requirements

• Several things about the project should be

clearly understood:
– What is the problem?

– What are the possible solutions to the

problem?
– What complexities might arise while solving
the problem?
 Analysis of the Gathered Requirements

• Some anomalies and inconsistencies

can be very subtle:
– Escape even most experienced eyes.

– If a formal specification of the system is

constructed,
• Many of the subtle anomalies and
inconsistencies get detected.
 Analysis of the Gathered Requirements (CONT.)

• 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.
 Software Requirements
Specification
needs

• Main aim: Gathering

Analysis

– Systematically organize the Specification

requirements arrived during Review

requirements analysis. SRS

Document

– Document requirements properly.

 SRS Document
• As already pointed out--- useful in
various contexts:
– Statement of user needs

– Contract document

– Reference document

– Definition for implementation

 SRS Document (CONT.)

• 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)

behavior is documented.
The Black box view of a System as
performing a set of functions

40
 SRS Document (CONT.)

• SRS document concentrates on:

– What needs to be done in terms of input-

output behaviour

– Carefully avoids the solution (“how to do”)

aspects.
 SRS Document (CONT.)

• The requirements at this stage:

– Written using end-user terminology.

• If necessary:
– Later a formal requirement specification
may be developed from it.
• It should be concise
– and at the same time should not be ambiguous.
• Implementation Indepenedent: It should
specify what the system must do
Properties of a Good
– and not say how to do it. SRS Document
• Easy to change.,
– i.e. it should be well-structured.
• It should be consistent.
• It should be complete.
 Properties of a Good SRS Document
(cont...)

• It should be traceable
– You should be able to trace which part of
the specification corresponds to which part
of the design, code, etc and vice versa.
• It should be verifiable
– e.g. “system should be user friendly” is not
verifiable
 SRS should not include...
• Project development plans
– E.g. cost, staffing, schedules, methods, tools, etc
• Lifetime of SRS is until the software is made obsolete
• Lifetime of development plans is much shorter

• Product assurance plans

– Configuration Management, Verification & Validation,
test plans, Quality Assurance, etc
• Different audiences
• Different lifetimes

• Designs
– Requirements and designs have different audiences
– Analysis and dessign are different areas of expertise