1. Software Requirements and the Requirements Engineering Process Chapters 5 and 6

2. References Software Engineering. Ian Sommerville. 6th edition. Pearson. Code Complete. Steve McConnell. (CC) The art of requirements triage. Alan M. Davis. Computer. IEEE. March 2003. Testing whether requirements are right. Robin F. Goldsmith, JD. Go Pro Management Inc. NYC Spin Meeting. December 2004. (RG) Software Requirements. Karl E. Wieger. Windows Press. Dr. Gotel’s research web page Dr. Barrett slides, NYU

3. Requirements elicitation and analysis Stakeholder: Person or group of persons who will be affected by the system (directly or indirectly) All stakeholders should be involved in requirements elicitation and analysis Stakeholders don’t know what they really want Stakeholders express requirements in their own terms Different stakeholders may have conflicting requirements Organisational and political factors may influence the system requirements The requirements change during the analysis process. New stakeholders may emerge and the business environment change

4. Different techniques for requirements elicitation and analysis Different techniques for elicitation: Brainstorming Stories Prototyping Questionnaires Interviewing Viewpoint Scenarios Use cases

5. Requirements analysis Read the paper ‘The Art of Requirements Triage’, Alan Davis, IEEE computer, March 2003 Prioritization, estimation of the resources to satisfy the requirements, subset of requirements that optimizes the probability of the system’s success MoSCoW Criteria for requirements triage: M – Must have – mandatory requirements that are fundamental to the system S – Should have – important requirements that could be omitted C – Could have – optional requirements W – Want to have – the requirements really can wait

6. Interviewing and questionnaires Interviewing: synchronous elicitation technique Questionnaires: asynchronous elicitation technique Based on: Ask questions and listening/reading the answers Be prepared to ask follow-up questions Ask for documents you need Log the answers (to support, complete or contradict what was said/written) Involve all the stakeholders

7. Viewpoints Viewpoints permits us to classify stakeholders and other sources of requirements Multi-perspective analysis / diversity of source of information are important 3 categories of viewpoints Interactor viewpoints: People or other systems that interact with the system Indirect viewpoints: Stakeholders who do not use the system directly but who influence the requirements in some ways Domain viewpoints: Domain characteristics and constraints

8. Viewpoints More specific viewpoints: Providers and receivers of system services Systems interfacing with the new system Regulations and standards applying to the system Sources of business and non-functional requirements Engineering viewpoints: developing, managing, maintaining the system Marketing viewpoints

9. The VORD method This method implements a viewpoint-oriented approach for requirements elicitation VORD = Viewpoint Oriented Requirements Definition It is based on: Viewpoint identification Discovering the viewpoints, services and constraints Viewpoint structuring Allocating services to viewpoints Viewpoint data/control Group the viewpoints into a hierarchy Viewpoint documentation Refine the description of the viewpoints, services and constraints Use of a template Viewpoint system mapping Transform the analysis to an object-oriented design

10. VORD template

11. Example: ATM Viewpoint identification

12. Example: ATM Viewpoint structuring: Allocating services to viewpoints

13. Example: ATM Viewpoint structuring: Viewpoint data/control

14. Example: ATM Viewpoint structuring: Viewpoint hierarchy

15. Example: ATM Viewpoint documentation

16. Scenarios If it often easier for people to relate on real-life example rather than abstract statements Scenarios are descriptions – sequences of events - of how the system is used in practice. Scenarios are composed of: A description of the initial state of the system A description of the normal flow of events in the scenario A description of what can go wrong and how it is handled Information on other activities that might be going on concurrency A description of the final state of the system

17. Use cases Use cases are a scenario-based technique for describing requirements Use cases identify the users of the system (actors) Use cases identify the tasks (use cases) Use cases relate the users and the tasks Use cases are typically illustrated with UML as stick figures or similar diagrams A set of use cases should describe all possible interactions with the system Use cases are more effective in capturing functional requirements

18. Example: Flights reservation system

19. Use-cases relationships Use cases have relationships Inclusions: A use case contain the behavior from another use case (unconditional) Can be seen as a factorization Introduced by the > keyword Extensions: A use case conditionally interrupts the execution of another use case to augment its functionality An extension point may specify a precondition for the extending behavior Introduced by the > keyword Inheritance

20. Flights reservation system

21. Requirements specification Examples of templates (Available in the Blackboard): Microsoft template. Karl E. Wiegers. Software Requirements. Windows Press. Volere template http://www.volere.co.uk

22. Textual descriptions of a use- cases The textual description of a use case includes: Use case ID Use case name Actors Description Pre-condition Post-condition Normal course Alternative course Exceptions Includes Priority See also template of Karl E. Wiegers, Microsoft

23. Requirements validation Requirements must be checked for: Validity, comprehensibility, traceability (source, dependency between requirements) consistency, completeness, realism and verifiability Validation techniques: Requirements reviews Expert review, two independent reviews Formal/informal Involvement of the stakeholders necessary Test-case generation Tests are developed for the requirements Prototyping Mini-definitions of the requirements A team redefine the requirements and compare them with the list of produced requirements There are lots of validation techniques (more than 21). Dr. Goldsmith’s presentation.

24. Requirements management Requirements management deals with the process of managing changes in the requirements during the requirements engineering process and system development Requirements traceability is concerned with the relationships between requirements (dependencies), their sources and the system design CASE tools are necessary for the requirements storage and management

25. Traceability matrix A traceability matrix permits us to see the relationships/dependencies between requirements U: Uses W: Weak relationshi p