Software Requirements Specification (SRS) Complete description of external behavior Complete description of external behavior
of software systemof software system Partitions universe into two setsPartitions universe into two sets
All systems satisfying user’s real needsAll systems satisfying user’s real needs All system that do not satisfy user’s real All system that do not satisfy user’s real
needsneeds As analysis yields understanding, sections As analysis yields understanding, sections
of SRS are written.of SRS are written.
SRS SRSSRS is a complete yet concise description is a complete yet concise description
of the entire external interface of the system of the entire external interface of the system with its environment including other with its environment including other software, communication ports, hardware, software, communication ports, hardware, and human users. and human users.
Includes:Includes: BehavioralBehavioral Non-behavioralNon-behavioral
Davis, A., Software Requirements
Behavioral
Behavioral: Behavioral: define what the system does; define what the system does; InputsInputs OutputsOutputs transformation of inputs to outputstransformation of inputs to outputs
Davis, A., Software Requirements
Non-behavioral Non-behavioral: Non-behavioral: define the attributes of the define the attributes of the
system as it performs its jobsystem as it performs its job EfficiencyEfficiency ReliabilityReliability SecuritySecurity MaintainabilityMaintainability PortabilityPortability Standards complianceStandards compliance
Davis, A., Software Requirements
Attributes of a Well-Written SRS-1
CorrectCorrect iff every requirement stated therein iff every requirement stated therein accurately represents something required of the accurately represents something required of the system to be built.system to be built.
UnambiguousUnambiguous iff every requirement stated iff every requirement stated therein has only one interpretation.therein has only one interpretation.
Davis, A., Software Requirements
Attributes of a Well-Written SRS-2
CompleteComplete if it possesses the following: if it possesses the following: Everything that the software is suppose to do is included Everything that the software is suppose to do is included
in the SRS;in the SRS; Definitions of responses of software of all realizable Definitions of responses of software of all realizable
classes of input data in all realizable classes of situations classes of input data in all realizable classes of situations is included;is included;
Think of a finite state machine:Think of a finite state machine:• I X S => O X SI X S => O X S• Must have a complete mappingMust have a complete mapping
All terms are defined and units of measures are provided;All terms are defined and units of measures are provided;
Davis, A., Software Requirements
Attributes of a Well-Written SRS-2.1
CompleteComplete if it possesses the following: if it possesses the following:
Davis, A., Software Requirements
Attributes of a Well-Written SRS-2.2
Violation of completeness is difficult to determine: Violation of completeness is difficult to determine: something is missing.something is missing. Prototypes may help.Prototypes may help. Example: If party A calls party B and party B is idle, Example: If party A calls party B and party B is idle,
B’s phone shall ring.B’s phone shall ring. (What if it makes all the phones ring …)(What if it makes all the phones ring …) If party A calls party B and party B is idle, B’s If party A calls party B and party B is idle, B’s
phone shall ring and no other phone shall ring.phone shall ring and no other phone shall ring.
Davis, A., Software Requirements
Attributes of a Well-Written SRS-3 VerifiableVerifiable (SRS) iff every requirement stated therein is (SRS) iff every requirement stated therein is
verifiable. verifiable. A requirement is verifiable iff there exists some finite, A requirement is verifiable iff there exists some finite,
cost-effective process with which a person or machine cost-effective process with which a person or machine can check that an actual, as-built software product can check that an actual, as-built software product meets the requirements. meets the requirements. Examples:Examples:
““The product shall have an easy-to-use interface.”The product shall have an easy-to-use interface.”““The program shall not enter an infinite loop.”The program shall not enter an infinite loop.”
Avoid words such as “usually”, “generally,” or “often”.Avoid words such as “usually”, “generally,” or “often”.
Attributes of a Well-Written SRS-4 ConsistentConsistent iff no requirement stated therein is in iff no requirement stated therein is in
conflict with other preceding documents and no conflict with other preceding documents and no subset of requirements stated therein conflict.subset of requirements stated therein conflict.
Attributes of a Well-Written SRS-5
Traceable Traceable if the SRS is written in a manner if the SRS is written in a manner that facilitates the referencing of each that facilitates the referencing of each individual requirement stated therein.individual requirement stated therein.
Traced Traced ifif origin of requirements is clear.origin of requirements is clear.
SRS is a resource
Organization is critical: Organization is critical: Why organize it like this? Why organize it like this? How do you find things in an SRS?How do you find things in an SRS?
Emphasize the section 3.2 layout:Emphasize the section 3.2 layout: View system from different perspectives View system from different perspectives
to capture requirements: functional is to capture requirements: functional is weakest of the bunch. weakest of the bunch.
Outline of SRS Document
DOCUMENT CONTROL1. INTRODUCTION2. GENERAL DESCRIPTION3. EXTERNAL INTERFACE REQUIREMENTS4. BEHAVIORAL REQUIREMENTS5. NON-BEHAVIORAL REQUIREMENTS6. OTHER REQUIREMENTS7. APPENDIX A: ANALYSIS MODELS8. 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. USER INTERFACES
3.2. HARDWARE INTERFACES
3.3. SOFTWARE INTERFACES
3.4. COMMUNICATIONS INTERFACES
4. BEHAVIORAL REQUIREMENTS4.1. SAME CLASS OF USER
4.2. RELATED REAL-WORLD OBJECTS
4.3. STIMULUS
4.4. RELATED FEATURES
4.5. FUNCTIONAL
5. NON-BEHAVIORAL REQUIREMENTS5.1. PERFORMANCE REQUIREMENTS
5.2. SECURITY
5.3. QUALITATIVE REQUIREMENTS
5.3.1. Availability
5.3.2. Maintainability
5.3.3. Portability
5.3.4. 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 understandingOrganize the SRS for understanding Group requirements related byGroup requirements related by
Same external stimulusSame external stimulus Same system featureSame system feature Same system responseSame system response Same real world objectSame real world object Same class of userSame class of user Same class of functionSame class of function
Same External Stimulus
Put all the requirements related to some Put all the requirements related to some stimulus together. stimulus together.
Example: Microwave oven: Group byExample: Microwave oven: Group by All requirements related to the door openAll requirements related to the door open All requirements related to the start All requirements related to the start
commandcommand All requirements related to timer inputsAll requirements related to timer inputs . . .. . .
Same System Feature
Example: Telephone switching systemExample: Telephone switching system Group byGroup by
All requirements related to local callsAll requirements related to local calls All requirements related to long distance All requirements related to long distance
callscalls All requirements related to call All requirements related to call
forwardingforwarding . . .. . .
Same System Response
Example: payroll systemExample: payroll system All requirements related to generating All requirements related to generating
pay checkspay checks All requirements related to generating All requirements related to generating
employee reportsemployee reports All requirements related to generating All requirements related to generating
labor costslabor costs . . .. . .
Same Real World Object
Example: Library systemExample: Library system All requirements related to booksAll requirements related to books All requirements related to borrowersAll requirements related to borrowers All requirements related to publishersAll requirements related to publishers . . .. . .
Same Class of User
Example: ATMExample: ATM All requirements related to customersAll requirements related to customers All requirements related to maintenance All requirements related to maintenance
personnel personnel All requirements related to repair personnelAll requirements related to repair personnel
Same class of Function
(weakest, corresponds to unguided use of stepwise (weakest, corresponds to unguided use of stepwise decomposition)decomposition)
Example: accounting system: group byExample: accounting system: group by All requirements related to incoming dataAll requirements related to incoming data All requirements related to user interface All requirements related to user interface All requirements related to report generation All requirements related to report generation All requirements related to maintaining data All requirements related to maintaining data
basebase
Best Way?
Multilevel hierarchy where each level corresponds Multilevel hierarchy where each level corresponds to a different criteriato a different criteria X. Detailed RequirementsX. Detailed Requirements
X.1 PassengerX.1 Passenger• X.1.1 calling the elevatorX.1.1 calling the elevator• X.1.2 Requesting a floorX.1.2 Requesting a floor
X.2 maintenance PersonnelX.2 maintenance Personnel• X.2.1 inspecting ShaftX.2.1 inspecting Shaft• . . .. . .