Requirements Documentation
This is the way of representing requirements in a
consistent format
SRS serves many purpose depending upon who is writing
it.
-- written by customer
-- written by developer
Serves as contract between customer & developer.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 101
Requirements Documentation
Nature of SRS
Basic Issues
• Functionality
• External Interfaces
• Performance
• Attributes
• Design constraints imposed on an Implementation
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 102
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 103
Requirements Documentation
Ranked for important and/or stability
Verifiable
Modifiable
Traceable
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 104
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 105
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 106
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 107
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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 108
Requirements Documentation
2. 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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 109
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.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 110
