1. Standard SRS Copyright, 2001 © Jerzy R. Nawrocki Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/mse/require/ Requirements Engineering Lecture 4 Requirements Engineering Lecture 4

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

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

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

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

6. J. Nawrocki, Requirements Eng. (4) Source Documents for Requir’s.doc Manual SRS SRS Ver. n Ver. n+1

7. J. Nawrocki, Requirements Eng. (4) SD4R: Source document for requirements Types of SD4R: Email 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

8. 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

9. 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

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

11. 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

12. 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

13. 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

14. 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

15. 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...

16. 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

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

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

19. 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?