1. Copyright © Jerzy R. Nawrocki Requirements Review Jerzy.Nawrocki@put.poznan.pl www.cs.put.poznan.pl/jnawrocki/require Requirements Engineering & Project Management Lecture 5

2. J.Nawrocki, Requirements Review Introduction Roger S. Pressman 1 3-6 times 10 times 15-40 times 30-70 times 40-1000 times

3. J.Nawrocki, Requirements Review Quality-supporting activities RefactoringTesting Configuration manag. Reviews Software Quality

4. J.Nawrocki, Requirements Review Quality-supporting activities RefactoringTesting Configuration manag. Reviews Software Quality

5. J.Nawrocki, Requirements Review Agenda Requirements Analysis & Negotiation Requirements Validation Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

6. J.Nawrocki, Requirements Review Requirements Analysis and Negotiation The requirements document Requirements elicitation Reqs analysis & negotiation Describing requirements System modelling Requirements validation Requirements management RE for critical systems BasicIntermAdv 8 6 5 4 3 4 4 2 36 - 6 2 1 3 3 3 3 21 - 1 1 - - 1 2 4 9

7. J.Nawrocki, Requirements Review Basic guidelines Analysis and negotiation Define system boundaries System Person 1 Person 2 Institution Device Process requirements System requirements Software requirements

8. J.Nawrocki, Requirements Review Basic guidelines Analysis and negotiation Define system boundaries Use checklists for requirements analysis

9. J.Nawrocki, Requirements Review A Checklist Example Does a requirement imply the need for some decision- making based on incomplete or unreliable information? Will the implementation of a requirement need information which is outside the defined database for the system? Is a requirement concerned with the core functionality of the system? Is a requirement concerned with the functionality or performance of equipment which is external to the system? Analysing system’s boundaries

10. J.Nawrocki, Requirements Review Another Checklist Example a) Correct; b) Unambiguous; c) Complete; d) Consistent; e) Ranked for importance and/or stability; f) Verifiable; g) Modifiable; h) Traceable. IEEE Std 830-1998

11. J.Nawrocki, Requirements Review A Checklist for Use Cases Is there a shared clear vision? Are there visible boundaries? Is there clear cast of characters describing end-users? Are all user-level use-cases user-valued transactions? Does each use case have a complete single goal? Is its naming clear and depicting the goal? Are the alternatives an exhaustive set? Are use cases describing just behaviour? Are adornments properly used? Are the conditions detectable?

12. J.Nawrocki, Requirements Review Basic guidelines Analysis and negotiation Define system boundaries Use checklists for requirements analysis Provide software to support negotiations Plan for conflicts and conflict resolution Prioritise requirements

13. J.Nawrocki, Requirements Review Intermediate guidelines Analysis and negotiation Classify requirements using a multidimensional approach System, User interface, Database, Communications, Security

14. J.Nawrocki, Requirements Review Intermediate guidelines Analysis and negotiation Classify requirements using a multidimensional approach Use interaction matrices to find conflicts and overlaps System, User interface, Database, Communications, Security

15. J.Nawrocki, Requirements Review Advanced guidelines Analysis and negotiation Assess requirements risks

16. J.Nawrocki, Requirements Review Agenda Requirements Analysis & Negotiation Requirements Validation Introduction XPrince Team Project Lifecycle The Analyst Role The Architect Role The Project Manager Role Scaling up Conclusions

17. J.Nawrocki, Requirements Review Requirements Validation The requirements document Requirements elicitation Reqs analysis & negotiation Describing requirements System modelling Requirements validation Requirements management RE for critical systems BasicIntermAdv 8 6 5 4 3 4 4 2 36 - 6 2 1 3 3 3 3 21 - 1 1 - - 1 2 4 9

18. J.Nawrocki, Requirements Review Basic guidelines Requirements validation Check that the requirements document meets your standard Organise formal requirements inspections 

19. J.Nawrocki, Requirements Review Artefact Reviews and Inspection Review = Analysis of an artefact (e.g. code, document) done by 1 or more people. Goals of review : Quality assurance Knowledge dissemination Review

20. J.Nawrocki, Requirements Review FTR Procedure Casting Producer (author) Project Manager Facilitator Reviewer(s) Recorder FTR = Formal Technical Review

21. J.Nawrocki, Requirements Review FTR Meeting Decision Acceptance. No modifications are necessary. Conditional acceptance. There are some defects but additional inspection is not necessary (the Project Manager will check the final version). Rejection. There are serious defects and an additional inspection is necessary.

22. J.Nawrocki, Requirements Review Basic guidelines Requirements validation Check that the requirements document meets your standard Organise formal requirements inspections Use multidisciplinary teams to review requirements Define validation checklists 

23. J.Nawrocki, Requirements Review Intermediate guidelines Requirements validation Use prototyping to animate requirements Write a draft user manual Propose requirements test cases 

24. J.Nawrocki, Requirements Review Advanced guidelines Requirements validation Paraphrase system models 

25. J.Nawrocki, Requirements Review Summary Requirements analysis: Checklists Requirements negotiation Requirements validation: Reviews & FTR (1028)

26. J.Nawrocki, Requirements Review Questions?