1. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Chapter 6 Requirements Engineering Process

2. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 2 Requirements Engineering Processes l Processes used to discover, analyze and validate system requirements

3. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3 Objectives l To describe the principal requirements engineering activities l To introduce techniques for requirements elicitation and analysis l To describe requirements validation l To discuss requirements management

4. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 4 Requirements engineering process

5. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 5 Topics covered l Feasibility studies l Requirements elicitation and analysis l Requirements validation

6. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 6 Feasibility studies l A feasibility study decides whether or not the proposed system is worthwhile. The study checks if the system contributes to organizational objectives if the system can be engineered using current technology and within budget if the system can be integrated with other systems that are used

7. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7 Feasibility study implementation l Based on information collection, information assessment and report writing l Questions for people in the organization What if the system wasn’t implemented? What are current process problems? How will the proposed system help? What will be the integration problems? Is new technology needed? What skills? What facilities must be supported by the proposed system?

8. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8 Topics covered l Feasibility studies l Requirements elicitation and analysis l Requirements validation

9. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 9 Requirement elicitation and analysis l Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints l Involves many stakeholders, such as end-users, managers, engineers, domain experts, trade unions, etc.

10. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10 Problems of requirements analysis l Stakeholders don’t know what they really want l Stakeholders express requirements in their own terms l Different stakeholders may have conflicting requirements l Organizational and political factors may influence the system requirements l The requirements change during the analysis process, because new stakeholders may emerge and the business environment may change

11. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11 The requirements analysis process

12. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12 Techniques for requirements elicitation and analysis l Viewpoint-oriented elicitation l Scenarios l Ethnography l State models l Prototyping

13. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13 Banking ATM system – An example l Services include cash and check deposit, cash withdrawal, message passing (send a message to request a service), ordering a statement and transferring funds

14. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14 ATM viewpoint resources l Bank customers l Representatives of other banks l Hardware and software maintenance engineers l Marketing department l Bank managers and counter staff l Database administrators and security staff l Communications engineers l Personnel department

15. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15 Viewpoint-oriented elicitation l Stakeholders represent different ways of looking at a problem or problem viewpoints l This multi-perspective analysis is important as there is no single correct way to analyze system requirements

16. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 16 Types of viewpoint l Receivers of services Viewpoints are external to the system and receive services from the system. Most suited to interactive systems l Data sources or sinks Viewpoints are responsible for producing or consuming data. l Representation frameworks Viewpoints represent particular types of system model.

17. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 17 The VORD method l View Point-Oriented Requirement Definition

18. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18 VORD process model l Viewpoint identification Discover viewpoints which receive system services and identify the services provided to each viewpoint l Viewpoint structuring Group related viewpoints into a hierarchy. Common services are provided at higher-levels in the hierarchy l Viewpoint documentation Refine the description of the identified viewpoints and services l Viewpoint-system mapping Transform the analysis to an object-oriented design

19. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 19 Viewpoint identification

20. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20 Viewpoint service information

21. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 21 Viewpoint data/control

22. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 22 Viewpoint hierarchy

23. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 23 Scenarios l Scenarios are descriptions of how a system is used in practice (the interaction) l They are helpful in requirements elicitation as people can relate to these more readily than abstract statement of what they require from a system l Scenarios are particularly useful for adding detail to an outline requirements description

24. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 24 Scenario descriptions Including l System state description at the beginning of the scenario l Normal flow of events in the scenario l What can go wrong and how this is handled l Other concurrent activities l System state on completion of the scenario

25. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 25 Structured approach for scenarios l Event Scenarios l Use-cases

26. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 26 Event scenarios l An event is an occurrence of something important l Event scenarios are used to describe how a system responds to the occurrence of some particular event such as ‘start transaction’

27. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27 Event scenario - start transaction

28. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28 Use cases l Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself l A set of use cases should describe all possible interactions with the system l Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system

29. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29 Lending use-case

30. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 30 Library use-cases

31. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31 Catalogue management

32. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32 Ethnography l A social scientists spends a considerable time observing and analysing how people actually work l People do not have to explain or articulate their work l Social and organizational factors of importance may be observed l Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models

33. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 33 Scope of ethnography l Requirements that are derived from the way that people actually work rather than the way in which process definitions suggest that they ought to work l Requirements that are derived from cooperation and awareness of other people’s activities

34. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 34 Topics covered l Feasibility studies l Requirements elicitation and analysis l Requirements validation

35. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 35 Requirements validation l Concerned with demonstrating that the requirements define the system that the customer really wants l Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

36. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 36 Requirements checking l Validity. Does the system provide the functions which best support the customer’s needs? l Consistency. Are there any requirements conflicts? l Completeness. Are all functions required by the customer included? l Realism. Can the requirements be implemented given available budget and technology l Verifiability. Can the requirements be checked?

37. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37 Requirements validation techniques l Requirements reviews Systematic manual analysis of the requirements l Prototyping Using an executable model of the system to check requirements. Covered in Chapter 8 l Test-case generation Developing tests for requirements to check testability l Automated consistency analysis Checking the consistency of a structured requirements description

38. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 38 Requirements reviews l Regular reviews should be held while the requirements definition is being formulated l Both client and contractor staff should be involved in reviews l Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage

39. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 39 Automated consistency checking

40. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40 Key points l The requirements engineering process includes a feasibility study, requirements elicitation and analysis, requirements specification and requirements management l Requirements analysis is iterative involving domain understanding, requirements collection, classification, structuring, prioritisation and validation l Systems have multiple stakeholders with different requirements

41. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 41 Key points l Social and organisation factors influence system requirements l Requirements validation is concerned with checks for validity, consistency, completeness, realism and verifiability l Business changes inevitably lead to changing requirements l Requirements management includes planning and change management