Requirements
Specification and
Analysis I
1
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)
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!
Activities in Requirements Analysis and
Specification
Requirements Gathering
Requirements Analysis
Requirements Specification
SRS Document
Requirements Engineering Process
Feasibility
Study Requirements
gathering
Requirements
analysis
Feasibility Requirements
report specification
SRS Document
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.
• Good SRS reduces development cost:
– Req. errors are expensive to fix later Need for SRS…
– Req. changes cost a lot (typically 40% of requirements
change later)
– Good SRS can minimize changes and errors
– Substantial savings --- effort spent during req. saves
multiple times that effort
• An Example:
Cost
– Cost of fixing errors in req. , design , coding , acceptance
testing and operation increases exponentially
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
• 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..
• Specification
Gathering
and review may
Analysis
lead to further
Specification
gathering and
analysis.
Review
SRS Document
How to Gather Requirements?
needs
• Observe existing (manual) systems,
• Study existing procedures,
Gathering
Analysis
• Discuss with customer and end-users,
Specification
• Input and Output analysis
Review
• Analyze what needs to be done SRS
Document
Requirements Gathering Activities
• 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
to be automated. Interview
• 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 ofForm
forms that
Analysis
were being used.
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
• Main purpose of req. analysis: needs
Gathering
• Clearly understand user requirements, Analysis
• Detect inconsistencies, ambiguities, and
Specification
Review
incompleteness.
SRS
• Incompleteness and inconsistencies:
Document
– 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 and open
water shower when temperature > 100°C
– Another customer says turn off heater and turn
ON cooler when temperature > 100°C
• Some requirements not included:
– Possibly due to oversight.
Incomplete
• Example: Requirement
– 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
• After collecting all data regarding the system
(CONT.)
to be developed,
– Remove all inconsistencies and anomalies from
the requirements,
– Systematically organize requirements into a
Software Requirements Specification (SRS)
document.
Software Requirements Specification
• Main aim:
needs
Gathering
– Systematically organize the Analysis
requirements arrived during Specification
requirements analysis. Review
– Document requirements properly.
SRS
Document
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: Input
Data S Output
Data
– 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.
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.
• 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 design are different areas of expertise
Thank You!!