Requirements Documentation

Nature of SRS

Basic Issues

• Functionality
• External Interfaces
• Performance
• Attributes
• Design constraints imposed on an Implementation

1
Requirements Documentation
SRS Should
-- Correctly define all requirements
-- not describe any design details
-- not impose any additional constraints
Characteristics of a good SRS
An SRS Should be
 Correct
 Unambiguous
 Complete
 Consistent

2
Requirements Documentation

 Ranked for important and/or stability

 Verifiable
 Modifiable
 Traceable

3
Requirements Documentation
Correct
An SRS is correct if and only if every requirement stated therein is
one that the software shall meet.

Unambiguous
An SRS is unambiguous if and only if, every requirement stated
therein has only one interpretation.

Complete
An SRS is complete if and only if, it includes the following elements

(i) All significant requirements, whether related to

functionality, performance, design constraints, attributes or
external interfaces.

4
Requirements Documentation
(ii) Responses to both valid & invalid inputs.

(iii) Full Label and references to all figures, tables and diagrams in the
SRS and definition of all terms and units of measure.

Consistent

An SRS is consistent if and only if, no subset of individual

requirements described in it conflict.

Ranked for importance and/or Stability

If an identifier is attached to every requirement to indicate either the

importance or stability of that particular requirement.

5
Requirements Documentation
Verifiable
An SRS is verifiable, if and only if, every requirement stated therein is
verifiable.

Modifiable
An SRS is modifiable, if and only if, its structure and style are such that
any changes to the requirements can be made easily, completely, and
consistently while retaining structure and style.

Traceable
An SRS is traceable, if the origin of each of the requirements is clear
and if it facilitates the referencing of each requirement in future
development or enhancement documentation.

6
Requirements Documentation
Organization of the SRS

IEEE has published guidelines and standards to organize an SRS.

First two sections are same. The specific tailoring occurs in section-
3.

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definition, Acronyms and abbreviations
1.4 References
1.5 Overview

7
Requirements Documentation

1. The Overall Description

2.1 Product Perspective

2.1.1 System Interfaces
2.1.2 Interfaces
2.1.3 Hardware Interfaces
2.1.4 Software Interfaces
2.1.5 Communication Interfaces
2.1.6 Memory Constraints
2.1.7 Operations
2.1.8 Site Adaptation Requirements

8
Requirements Documentation
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions for dependencies
2.6 Apportioning of requirements

3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design Constraints
3.6 Software System attributes
3.7 Organization of specific requirements
3.8 Additional Comments.
9
Requirements Validation
Check the document for:

 Completeness & consistency

 Conformance to standards
 Requirements conflicts
 Technical errors
 Ambiguous requirements

10
Requirements Validation

SRS document
List of problems

Validatio
Organizational n
standards process

Organizational Approved actions

knowledge

11
Requirements Review Process
Distribut
e Read
Plan SRS
review docum
docume ents
nts

Organiz
e
review

Revise
Follow
up
docum
actions
ent
12
Requirements Validation
Problem actions
• Requirements clarification
• Missing information
• find this information from stakeholders
• Requirements conflicts
• Stakeholders must negotiate to resolve this conflict
• Unrealistic requirements
• Stakeholders must be consulted
• Security issues
• Review the system in accordance to security standards

13
Review Checklists

 Redundancy
 Completeness
 Ambiguity
 Consistency
 Organization
 Conformance
 Traceability

14