Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Requirements Engineering Lecture 4 Requirements Engineering Lecture 4

J. Nawrocki, Requirements Eng. (4) Plan of the lecture Introduction Good practices in describing requirements Requirements document

J. Nawrocki, Requirements Eng. (4) Computer-based systems Software Hardware People Database Documentation Procedures

J. Nawrocki, Requirements Eng. (4) Restraining factors Assumptions Simplifications Limitations Constraints Preferences

J. Nawrocki, Requirements Eng. (4) 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 SRS Ver. n Ver. n+1

J. Nawrocki, Requirements Eng. (4) SD4R: Source document for requirements Types of SD4R: Video File Audio Hard(copy)... Advice: Try to keep all the SD4Rs as text files Advice: Try to keep all the SD4Rs as text files Source Documents for Requir’s

J. Nawrocki, Requirements Eng. (4) 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 Stakeholders Users Domain 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 Requirement Introduction Viewpoint and source(s) Firmness and importance Verifiability and clarity Inputs Processing Outputs

J. Nawrocki, Requirements Eng. (4) Requirements document (4) Requirement External interface requirements User interfaces Hardware interfaces Software interfaces Communication interfaces 3.3 Performance requirements

J. Nawrocki, Requirements Eng. (4) Requirements document (5) 3.4 Design constraints Standards compliance Hardware limitations Attributes Security Maintainability...

J. Nawrocki, Requirements Eng. (4) Requirements document (6) 3.6 Other requirements Database Operations Site adaptation Training Non-technical requirements Appendixes Index

J. Nawrocki, Requirements Eng. (4) Further readings  IEEE Guide to Software Requirements specification, ANSI/IEEE Standard I. Sommerville, P. Sawyer, Requirements Engineering, John Wiley & Sons, Chichester, 1997

J. Nawrocki, Requirements Eng. (4) HomeworkHomework Write SRS for a personal library system.

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?