Software Requirements
Specification (SRS)
0810
Software Requirements
Specification (SRS)
Complete description of external behavior
of software system
 Partitions universe into two sets
 All systems satisfying user’s real needs
 All system that do not satisfy user’s real
needs
 As analysis yields understanding, sections
of SRS are written.

Why write an SRS?
SRS
Davis, A., Software Requirements
SRS is a complete yet concise description
of the entire external interface of the system
with its environment including other
software, communication ports, hardware,
and human users.
 Includes:
 Behavioral
 Non-behavioral

Behavioral
Davis, A., Software Requirements

Behavioral: define what the system does;
 Inputs
 Outputs
 transformation of inputs to outputs
Non-behavioral
Davis, A., Software Requirements

Non-behavioral: define the attributes of the
system as it performs its job
 Efficiency
 Reliability
 Security
 Maintainability
 Portability
 Standards compliance
Attributes of a Well-Written SRS-1
Davis, A., Software Requirements
Correct iff every requirement stated therein
accurately represents something required of the
system to be built.
 Unambiguous iff every requirement stated
therein has only one interpretation.

Attributes of a Well-Written SRS-2
Davis, A., Software Requirements

Complete if it possesses the following:
 Everything that the software is suppose to do is
included in the SRS;
 Definitions of responses of software of all realizable
classes of input data in all realizable classes of
situations is included;
 Think of a finite state machine:
• I X S => O X S
• Must have a complete mapping
 All terms are defined and units of measures are
provided;
Attributes of a Well-Written SRS-2.1
Davis, A., Software Requirements

Complete if it possesses the following:
Attributes of a Well-Written SRS-2.2
Davis, A., Software Requirements

Violation of completeness is difficult to determine:
something is missing.
 Prototypes may help.
 Example: If party A calls party B and party B is idle,
B’s phone shall ring.
 (What if it makes all the phones ring …)
 If party A calls party B and party B is idle, B’s
phone shall ring and no other phone shall ring.
Attributes of a Well-Written SRS-3



Verifiable (SRS) iff every requirement stated
therein is verifiable.
A requirement is verifiable iff there exists some
finite, cost-effective process with which a person
or machine can check that an actual, as-built
software product meets the requirements.
 Examples:
 “The product shall have an easy-to-use
interface.”
 “The program shall not enter an infinite
loop.”
Avoid words such as “usually”, “generally,” or
“often”.
Attributes of a Well-Written SRS-4

Consistent iff no requirement stated therein is in
conflict with other preceding documents and no
subset of requirements stated therein conflict.
Attributes of a Well-Written SRS-5
Traceable if the SRS is written in a manner
that facilitates the referencing of each
individual requirement stated therein.
 Traced if origin of requirements is clear.

SRS is a resource
Organization is critical:
 Why organize it like this?
 How do you find things in an SRS?
 Emphasize the section 3.2 layout:
 View system from different perspectives
to capture requirements: functional is
weakest of the bunch.

Outline of SRS Document
DOCUMENT CONTROL
1. INTRODUCTION
2. GENERAL DESCRIPTION
3. EXTERNAL INTERFACE REQUIREMENTS
4. BEHAVIORAL REQUIREMENTS
5. NON-BEHAVIORAL REQUIREMENTS
6. OTHER REQUIREMENTS
7. APPENDIX A: ANALYSIS MODELS
8. APPENDIX B: ISSUES LIST
Introduction
1.1. PURPOSE AND SCOPE OF PRODUCT
1.2. INTENDED AUDIENCE
1.3. OVERVIEW
1.4. DEFINITIONS, ACRONYMS, AND
ABBREVIATIONS
1.4.1. Definitions
1.4.2. Acronyms and Abbreviations
1.5. REFERENCES
General Description
2.1. PRODUCT PERSPECTIVE
2.2. PRODUCT FEATURES
2.3. USER CHARACTERISTICS
2.4. OPERATING ENVIRONMENT
2.5. GENERAL CONSTRAINTS
2.6. ASSUMPTIONS AND
DEPENDENCIES
3. External Interface
3.1.
3.2.
3.3.
3.4.
USER INTERFACES
HARDWARE INTERFACES
SOFTWARE INTERFACES
COMMUNICATIONS INTERFACES
4. BEHAVIORAL
REQUIREMENTS
4.1.
4.2.
4.3.
4.4.
4.5.
SAME CLASS OF USER
RELATED REAL-WORLD OBJECTS
STIMULUS
RELATED FEATURES
FUNCTIONAL
5. NON-BEHAVIORAL
REQUIREMENTS
5.1.
5.2.
5.3.
5.3.1.
5.3.2.
5.3.3.
5.3.4.
PERFORMANCE REQUIREMENTS
SECURITY
QUALITATIVE REQUIREMENTS
Availability
Maintainability
Portability
Design and Implementation Constraints
The rest …
6.OTHER REQUIREMENTS
6.1. DATABASE
6.2. OPERATIONS
6.3. SITE ADAPTATION
7.APPENDIX A: ANALYSIS MODELS
8.APPENDIX B: ISSUES LIST
Groupings of requirements


Organize the SRS for understanding
Group requirements related by
 Same external stimulus
 Same system feature
 Same system response
 Same real world object
 Same class of user
 Same class of function
Same External Stimulus
Put all the requirements related to some
stimulus together.
 Example: Microwave oven: Group by
 All requirements related to the door open
 All requirements related to the start
command
 All requirements related to timer inputs
. . .

Same System Feature
Example: Telephone switching system
 Group by
 All requirements related to local calls
 All requirements related to long distance
calls
 All requirements related to call
forwarding
. . .

Same System Response

Example: payroll system
 All requirements related to generating
pay checks
 All requirements related to generating
employee reports
 All requirements related to generating
labor costs
. . .
Same Real World Object

Example: Library system
 All requirements related to books
 All requirements related to borrowers
 All requirements related to publishers
. . .
Same Class of User
Example: ATM
 All requirements related to customers
 All requirements related to maintenance
personnel
 All requirements related to repair personnel

Same class of Function


(weakest, corresponds to unguided use of stepwise
decomposition)
Example: accounting system: group by
 All requirements related to incoming data
 All requirements related to user interface
 All requirements related to report generation
 All requirements related to maintaining data
base
Best Way?

Multilevel hierarchy where each level corresponds
to a different criteria
 X. Detailed Requirements
 X.1 Passenger
• X.1.1 calling the elevator
• X.1.2 Requesting a floor
 X.2 maintenance Personnel
• X.2.1 inspecting Shaft
•...