Requirements Analysis

Requirements Analysis and

Specification
• Many projects fail:
• because they start implementing the
system:
• without determining whether they are
building what the customer really wants.
Requirements
 System
Study/understanding
Software
Requirements
Analysis

Software
Design
 Problem study User response
User requests

Problem Analysis

A relatively good understanding of user’s

requirements

System Description

Software Requirements Specification

SW Requirements Analysis
• A study of user needs, for a problem to arrive at a
definition of WHAT the software will do without
describing how it will do it.

• A Software Requirements Specification (SRS) is a

document containing software requirements
specification for a system.
Requirements Analysis Activities
• Study System Specification & SW Project plan/feasibility
• Problem Recognition
• Evaluation & understanding
• Modeling
• Specification
• Review
Requirement Objectives
Feasibility Study
Types of Requirements
Types of Requirements
Requirements Validation Criteria
 Analysis Principles
Information Domain

• Information contents & relationships (Data Model

• Information Flow : data + control changes
• Information structure : internal organization
 Analysis Principles
• Information domain must be represented thoroughly
• Functions to perform, must be defined
• Behavior as consequence of external events must be
represented
• Models depicting information/data, function & behavior
must be partitioned to uncover detail in layered fashion
( i.e. step by step)
• Analysis process should move from essential information
(i.e. most abstract level) to implementation level details
 Analysis Principles
• Understand the problem clearly before creating analysis
model
• Develop prototypes
• Record the origin & the reason for every requirement
• Use multiple views of requirements
• Rank requirements
• Work to eliminate ambiguity
 Requirement Elicitation
Fact Gathering Techniques
• Interviews
• Questionnaires
• Analyzing documents
• Observation
• study...
 Requirement Elicitation contd.

Facilitated Application Specification Technique

• Meeting at neutral site
• Rules for preparation & participation
• Agenda – formal + informal
• Facilitator controls meeting
• Definition mechanism
• Identify problem, propose solution, negotiate
approaches, specify set of solution requirements
 Requirement Elicitation contd.
Quality Function Deployment - quality management technique

• Normal requirements
• Expected requirements
• Other requirements

 Function Deployment : function values

 Information Deployment : data objects + events
 Task deployment : system behavior
 Value Analysis : requirement priorities
 Requirement Elicitation contd.
Use Cases(usage scenario)
<<uses>>
Approves Validates
leave leave

Manages
Projects

Manager
Approves
vouchers
 Requirement Elicitation contd.

• Scenarios perceived differently by different actors

• Use U_C Modeling : Priority value assigned for each use case
• System functionality priorities
Requirement Elicitation contd.
Requirement Elicitation contd.
Requirement Elicitation contd.
Requirement Elicitation contd.
Use Cases
User Profiles in Use Cases
User Profiles in Use Cases
User Profiles in Use Cases
Requirements Validation
Software Requirements Specification: A Contract
Document
• Requirements document is a reference document.
• SRS document is a contract between the
development team and the customer.
• Once the SRS document is approved by the customer,
• any subsequent controversies are settled by
referring the SRS document.
 SW Requirements Specification
• Purpose of SRS
• communication between the Customer, Analyst, system developers,
maintainers, ...
• contract between Purchaser and Supplier
• firm foundation for the design phase
• support system testing activities
• support project management and control
• controlling the evolution of the system
 SRS Document (CONT.)
• The 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.

Input Data Output Data

S
 SRS Document (CONT.)
• SRS document concentrates on:
• what needs to be done
• carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• between development team and the customer.
• Should be carefully written
 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.
Software Requirements Specification (SRS)

• Defines the customer’s requirements in terms of :

• Function
• Performance
• External interfaces
• Design constraints
• The SRS is the basis of contract between the
purchaser and supplier
 Specification Principles
• Separate functionality from implementation
• Develop model of desired behavior of the system
• Establish the context in which s/w operates
• Define the environment in which system operates
• Specifications must be tolerant of incompleteness
• Content & structure of a specifications should be
amenable to change
What is not included in an SRS ?
 Project requirements
• cost, delivery schedules, staffing, reporting procedures
 Design solutions
• partitioning of SW into modules, choosing data structures
 Product assurance plans
• Quality Assurance procedures, Configuration
Management procedures, Verification & Validation
procedures
Benefits of SRS
• Forces the users to consider their specific
requirements carefully
• Enhances communication between the Purchaser
and System developers
• Provides a firm foundation for the system design
phase
• Enables planning of validation, verification, and
acceptance procedures
• Enables project planning eg. estimates of cost and
time, resource scheduling
• Usable during maintenance phase
Types of Requirements
• Functional requirements
• Non functional requirements
• Performance requirements
• Interface requirements
• Design constraints
• Other requirements
 Functional Requirements
• Transformations (inputs, processing, outputs)
• Requirements for sequencing and parallelism (dynamic
requirements)
• Data
• Inputs and Outputs
• Stored data
• Exception handling
• Nature of function: Mandatory/ Desirable/ Optional /
Volatile / Stable
Performance Requirements
• Capacity
• no. of simultaneous users, processing requirements for
normal and peak loads, static storage capacity, spare
capacity. (eg bandwidth, os etc)
• Response time
• System priorities for users and functions
• System efficiency
• Availability and Fault recovery
 All these requirements should be stated in
measurable terms so that they can be verified.
Verifiable
• A requirement is verifiable if and only if there exists some finite cost
effective process with which a person can check that the SW meets
that requirement.
External Interface Requirements
• User interfaces
• eg. if display terminal used, specify required screen
formats, menus, report layouts, function keys
• Hardware interfaces
• characteristics of the interface between the SW
product and HW components of the system
• Software interfaces
• specify the use of other SW products eg. OS, DBMS,
other SW packages
Other Requirements
• Security
• Safety
• Environmental
• Reusability
• Training
• ...
SRS Standards
• ANSI/IEEE SRS Standard 830-1984
• BS 6719: 1986
• European Space Agency Standards
(ESA PSS-05-0, Jan 1987)
• US DoD-Std-7935A
• ...
 SRS Prototype Outline
[ IEEE SRS Standard ]

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Overview
 SRS - Introduction Section
• Purpose
• define the purpose of the particular SRS
• specify the intended audience for the SRS
• Scope
• identify the SW products to be produced by name
• explain what the SW product will do, and if necessary, what it
will not do
• describe the application of the SW being specified. ie.
benefits, objectives, goals as precisely as possible
• Overview
• describe what the rest of the SRS contains
• how the SRS is organized
 SRS Prototype Outline
[ IEEE SRS Standard ]

2. General description
2.1 Product perspective
2.2 Product function summary
2.3 User characteristics
2.4 General constraints
2.5 Any Assumptions and
dependencies
 Product Perspective
• State whether the product is independent and totally
self contained
• If the product is component of a larger system then:
• describe the functions of each component of the larger
system and identify interfaces
• overview of the principal external interfaces of this product
• overview of HW and peripheral equipment to be used
• Give a block diagram showing the major components
of the product, interconnections, and external
interfaces.
Product Functions
• Provide a summary of functions the SW will
perform
• The functions should be organized in such a way
that they are understandable by the user

User Characteristics
• Describe the general characteristics of the
eventual users of the product. (such as
educational level, experience and technical
expertise )
General Constraints
• Regulatory policies
• HW limitations
• Interfaces to other applications
• Parallel operation
• Audit functions
• Control functions
• Criticality of the application
• Safety and security considerations
 SRS Prototype Outline
[ IEEE SRS Standard ]

3. Specific Requirements
- Functional requirements
- External interface requirements
- Performance requirements
- Design constraints
- Attributes eg. security, availability,
maintainability, transferability/conversion
- Other requirements
Appendices
Index
Characteristics of a Good SRS
• Unambiguous
• Complete
• Verifiable
• Consistent
• Modifiable
• Traceable
• Usable during the Operation and
Maintenance phase
Complete

• All significant requirements are included

• Definition of responses of the SW to all realizable
classes of input data in all situations.
• Conformity to a standard
• Full labeling and referencing of all figures, tables etc.
and definition of all terms and units of measure
Verifiable
• A requirement is verifiable if and only if there exists some finite cost
effective process with which a person or machine can check that the
SW meets the requirement.

Consistent
• No two requirements are in conflict
Modifiable
• Structure and style of SRS is such that changes to requirements can
be made easily, completely and consistently.
• SRS organisation -- table of contents, index, explicit cross-referencing
• no redundancy
Traceable
• An SRS is traceable if the origin of each
requirement is clear and it facilitates the
referencing of each requirement in future.
• Backward traceability
• requirement explicitly referencing its source in
previous documents
• Forward traceability
• each requirement has a unique name or reference
number and it can be traced to design documents,
program implementation.
SRS Review
• Formal Review done by Users, Developers,
Managers, Operations personnel

• To verify that SRS confirms to the actual user

requirements

• To detect defects early and correct them.

• Review typically done using checklists.