Requirements Engineering
Lecture 4
Standard SRS
Jerzy.Nawrocki@put.poznan.pl
www.cs.put.poznan.pl/jnawrocki/mse/require/
Copyright, 2001 © Jerzy R. Nawrocki
Plan of the lecture
Introduction
Good practices in describing
requirements
Requirements document
J. Nawrocki, Requirements Eng. (4)
Computer-based systems
•
•
•
•
•
•
J. Nawrocki, Requirements Eng. (4)
Software
Hardware
People
Database
Documentation
Procedures
Restraining factors
•
•
•
•
•
J. Nawrocki, Requirements Eng. (4)
Assumptions
Simplifications
Limitations
Constraints
Preferences
Plan of the lecture
Introduction
Good practices in
describing requirements
Requirements document
J. Nawrocki, Requirements Eng. (4)
Source Documents for Requir’s
.doc
Manual
SRS
Ver. n
J. Nawrocki, Requirements Eng. (4)
SRS
Ver. n+1
Source Documents for Requir’s
List of SD4Rs
# Type Title From Since Place Comments
1 Email SRS Nowak 9.11.99 SDS/ Ambiguous
2
SD4R: Source document for requirements
Types of SD4R:
Email
Video
File
Audio
Hard(copy)
J. Nawrocki, Requirements Eng. (4)
...
Advice:
Try to keep all the
SD4Rs as text files
A good SRS
•
•
•
•
•
•
•
Unambiguous (one interpretation)
Verifiable (one can check that req. are met)
Complete (responses to invalid input)
Consistent (no conflicts between req.)
Modifiable (changes are not a big problem)
Traceable (origin of each req. is clear)
Usable during the Operation and Maintenance
Phase
J. Nawrocki, Requirements Eng. (4)
Davis’ Principles for RE
• Understand the problem before you begin
to create the analysis model
• Develop prototypes showing how the
human-machine interaction will occur
• Record the origin of and the reason for
every requirement
• Use multiple views of requirements (data,
functional, and behavioural)
• Prioritise requirements
• Work to eliminate ambiguity
J. Nawrocki, Requirements Eng. (4)
Plan of the lecture
Introduction
Good practices in describing
requirements
Requirements document
J. Nawrocki, Requirements Eng. (4)
Requirements document (1)
1. Introduction
1.1 Purpose of the document
1.2 Scope of the product
1.3 Definitions, acronyms and
abbreviations
1.4 References
1.5 Overview of the document
J. Nawrocki, Requirements Eng. (4)
Requirements document (2)
2. General description
2.1 Product perspective
2.2 Viewpoints
2.2.1 Stakeholders
2.2.2 Users
2.2.3 Domain
2.2.4 Components
2.3 System architecture and use cases in UML
2.4 General constraints
2.5 Assumptions and dependencies
J. Nawrocki, Requirements Eng. (4)
Requirements document (3)
3. Technical requirements
3.1 Functional requirements
3.1.1 Requirement 1
3.1.1.1 Introduction
Viewpoint and source(s)
Firmness and importance
Verifiability and clarity
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
J. Nawrocki, Requirements Eng. (4)
Requirements document (4)
3.1.2 Requirement 2
..
3.2 External interface requirements
3.2.1 User interfaces
3.2.2 Hardware interfaces
3.2.3 Software interfaces
3.2.4 Communication interfaces
3.3 Performance requirements
J. Nawrocki, Requirements Eng. (4)
Requirements document (5)
3.4 Design constraints
3.4.1 Standards compliance
3.4.2 Hardware limitations
...
3.5 Attributes
3.5.1 Security
3.5.2 Maintainability
...
J. Nawrocki, Requirements Eng. (4)
Requirements document (6)
3.6 Other requirements
3.6.1 Database
3.6.2 Operations
3.6.3 Site adaptation
3.6.4 Training
...
3.7 Non-technical requirements
Appendixes
Index
J. Nawrocki, Requirements Eng. (4)
Further readings

IEEE Guide to Software
Requirements specification,
ANSI/IEEE Standard 8301984
I. Sommerville, P. Sawyer,
Requirements Engineering,
John Wiley & Sons,
Chichester, 1997
J. Nawrocki, Requirements Eng. (4)
Quality assessment
1. What is your general
impression? (1 - 6)
2. Was it too slow or too fast?
3. What important did you learn
during the lecture?
4. What to improve and how?
J. Nawrocki, Requirements Eng. (4)