Lecture 3-2
From Elicitation To Specification
CS 300 Lecture 3-2
Bart Massey
Difference between elicit and specify
Elicit: Get the requirements from the user
- Usually fairly unorganized
- Looking for a big picture
- Looking for an agreement: Acceptance Tests
Specify: Organize the requirements for design
- Check the requirements for soundness, completeness
- Validate the requirements
- Identify design constraints
- Identify infeasible requirements; prepare for design
System Tests
Software Requirements vs System Requirements
SRS vs SRS: Obviously need both; similar on smaller projects
IEEE STD 29148:2011 (paywalled, thanks IEEE)
IEEE 29148: SRS Outline
- Introduction
1.1 Purpose
1.2 Scope
1.3 Product overview
1.3.1 Product perspective
1.3.2 Product functions
1.3.3 User characteristics
1.3.4 Limitations
1.4 Definitions - References
- Specific requirements
3.1 External interfaces
3.2 Functions
3.3 Usability Requirements
3.4 Performance requirements
3.5 Logical database requirements
3.6 Design constraints
3.7 Software system attributes
3.8 Supporting information - Verification
4.1-4.8 see 3.1-3.8 Appendices
5.1 Assumptions and dependencies
5.2 Acronyms and abbreviations
English vs Formal Specifications
English is messy
- Ambiguous
- Verbose
- Hard to manage
Formal is hard
Whole pile of semi-successful compromises, e.g. graphical
- UML Use Case Models
SADT et al
Use Cases and Scenarios
Use Case: How will the software / system be used?
- ATM: Withdraw money, deposit money, empty machine
Scenario: Walk through an interaction in detail
- ATM: Describe every button press and timing
Both are useful:
- Use cases for every expected use
- Scenarios to clarify use cases
Scenarios for corner cases
Example SRS
For a toy classroom assignment
Heavy on the UML
Overformal for our purposes
Last modified: Tuesday, 13 October 2015, 9:29 PM