1. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 1 Requirements Engineering Processes The goal of the requirements engineering process is to create and maintain a system requirements document

2. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 2 Objectives l To describe the principal requirements engineering activities and their relationships l To introduce techniques for requirements elicitation and analysis l To describe requirements validation and the role of requirements reviews l To discuss the role of requirements management in support of other requirements engineering processes

3. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 3 Topics covered (1/2) The overall requirements engineering process includes four high-level requirements engineering sub-process: 1. Feasibility studies 2. Requirements elicitation and analysis 3. Requirements validation 4. Requirements management l P.S.: Specification and Documentation are covered in chapter 6.

4. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 4 Topics covered (2/2) Requirements engineering activities: l Feasibility studies: (Is the system useful to the business?) l Requirements elicitation and analysis (The activity of discovering requirements) l Requirements validation (Checking that the requirements actually define the system that the customer wants) l Requirements management (The activity of managing changing requirements) l Specification and Documentation (are covered in chapter 6 and concern the conversion of the requirements into some standard form)

5. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 5 Requirements engineering processes l The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. l However, there are a number of generic activities common to all processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management.

6. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 6 The requirements engineering process

7. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 7 An alternative to the requirements engineering process: an iterative process around a spiral Three-stage activity; Around the spiral the requirements are developed to different level of detail. For example, if the prototyping activity, shown under the requirements validation is extended to iterative development, this model allows the requirements and the implementation to be developed together.

8. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 8 Feasibility studies l A feasibility study decides whether or not the proposed system is worthwhile. l A short focused study that checks If the system contributes to organisational objectives; If the system can be engineered using current technology and within budget; If the system can be integrated with other systems that are already used.

9. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 9 Feasibility study implementation l Based on information assessment (what is required), information collection and report writing. l Questions for people in the organisation 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?

10. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 10 Elicitation and analysis l Sometimes called requirements elicitation or requirements discovery. 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 May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

11. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 11 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 Organisational and political factors may influence the system requirements. l The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

12. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 12 The requirements spiral for elicitation and analysis process See next slide … This iterative process starts from requirements discovery and ends with requirements documentation.

13. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 13 Process activities l Requirements discovery Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage. l Requirements classification and organisation Groups related requirements and organises them into coherent clusters. For example, it is possible to use model of the system architecture to identify subsystem and grouping related requirements. l Prioritisation and negotiation Prioritising requirements and resolving requirements conflicts. For example it is possible to organize stakeholders negotiations so that compromises can be reached. l Requirements documentation Requirements are documented and input into the next round of the spiral. The documentation can be formal or informal. For example, extreme programming uses formal documents and cards and it is very easy for stakeholders to handle, change and organise requirements.

14. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 14 Requirements discovery l The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information. l Sources of information include documentation, system stakeholders and the specifications of similar systems.

15. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 15 ATM stakeholders, Domain and interacting System Stakeholders: l Bank customers l Representatives of other banks l Bank managers l Counter staff l Database administrators l Security managers l Marketing department l Hardware and software maintenance engineers l Banking regulators Moreover, we have already seen that requirements may come from the application Domain and from other System that interact with the application being specified.

16. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 16 Requirements discovery and viewpoints l All the previous requirements sources can be represented as system viewpoints. l Viewpoints are a way of structuring the requirements to represent the perspectives of different stakeholders. Stakeholders and other sources may be classified under different viewpoints. l This multi-perspective analysis is important as there is no single correct way to analyse system requirements.

17. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 17 Types of viewpoint l Interactor viewpoints People or other systems that interact directly with the system. In an ATM, the customer’s and the account database are interactor VPs. l Indirect viewpoints Stakeholders who do not use the system themselves but who influence the requirements. In an ATM, management and security staff are indirect viewpoints. l Domain viewpoints Domain characteristics and constraints that influence the requirements. In an ATM, an example would be standards for inter-bank communications.

18. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 18 Viewpoint identification l Since it may be difficult the identification of the viewpoint ….. It could be helpfully identify viewpoints using: Providers and receivers of system services; Systems that interact directly with the system being specified; Regulations and standards; Sources of business and non-functional requirements. Engineers who have to develop and maintain the system; Marketing and other business viewpoints.

19. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 19 LIBSYS viewpoint hierarchy

20. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 20 Requirements discovery and interviewing l In formal or informal interviewing, the RE team puts questions to stakeholders about the system that they use and the system to be developed. l There are two types of interview Closed interviews where a pre-defined set of questions are answered. Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.

21. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 21 Interviews in practice l Normally a mix of closed and open-ended interviewing. l Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system. l Interviews are not good for understanding domain requirements for two reasons: Requirements engineers cannot understand specific domain terminology; Some domain knowledge is so familiar that people find it hard to articulate or think that it isn’t worth articulating.

22. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 22 Effective interviewers l Interviewers should be open-minded, willing to listen to stakeholders and should not have pre-conceived ideas about the requirements. l They should prompt the interviewee with a question or a proposal and should not simply expect them to respond to a question such as ‘what do you want’. Most people find it much easier to talk in a defined context rather than in general terms.

23. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 23 Requirements discovery and scenarios (1/2) l People usually find it easier to relate to real-life examples than to abstract description. l They can understand and critique a scenario of how they can interact with the system. l That is, scenario can be particularly useful for adding detail to an outline requirements description: they are description of example interaction sessions; each scenario covers one or more possible interaction; Several forms of scenarios have been developed, each of which provides different types of information at different level of detail about the system.

24. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 24 Requirements discovery and scenarios (2/2) l Scenarios are real-life examples of how a system can be used. l They should include A description of the starting situation; A description of the normal flow of events; A description of what can go wrong; Information about other concurrent activities; A description of the state when the scenario finishes.

25. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 25 LIBSYS scenario (1/2) Scenario may be informal and may be written as text.

26. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 26 LIBSYS scenario (2/2)

27. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 27 Scenarios l Scenarios described as text might be supplemented by some kind of diagrams, screen-shot and so on. l Alternatively, a more structured approach such as event scenarios and/or use-case may be adopted.

28. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 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 Actors are represented as stick figures. l Each class of interaction is represented as a named ellipse.

29. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 29 Use cases l A set of use-cases may be used to represent all of the possible interactions in the system. l Avoiding confusion between use-cases and scenarios: Use-cases identify the interactions with the system and they can be documented with text or linked to UML models. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

30. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 30 Scenarios l Scenarios show: The actors involved in the interaction; The objects they interact with; The operations associated with these objects. l It is worthwhile noticing that the terms object it is used to indicate an instance of a class or an instance of a general system component.

31. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 31 Article printing use-case

32. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 32 LIBSYS use cases

33. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 33 Print article sequence

34. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 34 Use-cases and scenarios (1/2) l Scenarios and use-cases are effective technique for eliciting requirements for interactor viewpoints. In fact each interaction can be represented as a use- case supplemented by scenarios. l They may also be used for indirect viewpoint when these viewpoint receive some result. For example consider the Library Manager of our example.

35. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 35 Use-cases and scenarios (2/2) l Due to their “low-level nature” in this context (requirements engineering process), scenarios and use-cases are not so effective for discovering constraints and/or high- level non-functional requirements; for discovering domain requirements.

36. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 36 Social and organisational factors l Software systems are used in a social and organisational context. This can influence or even dominate the system requirements. l Social and organisational factors are not a single viewpoint but are influences on all viewpoints. l Good analysts should immerse him or herself in the working environment where the system will be used and must be sensitive to these factors l Currently no systematic way to tackle their analysis.

37. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 37 Ethnography l An expert in social branch spends a considerable time observing and analysing how people actually work. l In this way it is possible to discover implicit system requirements. l People do not have to explain or articulate detail about their work. In fact people often find it difficult to detail their works because it is second nature to them. l An unbiased observer may be suitable to find out social and important organisational factors (that are not obvious to individuals). l Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.

38. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 38 Focused ethnography l Developed in a project studying the air traffic control process l Combines ethnography with prototyping l Prototype development results in unanswered questions which focus the ethnographic analysis. l The problem with ethnography is that it studies existing practices which may have some historical basis which is no longer relevant.

39. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 39 Focused ethnography l As showed in the next figure, ethnography may be combined with prototyping. l Combines ethnography with prototyping, the former communicates with the development of the prototype so fewer prototype refinement cycles are required. l In fact often prototype development results in unanswered questions which focus the ethnographic analysis.

40. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 40 Ethnography and prototyping

41. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 41 Scope of ethnography To summarize the discussion, we can say that ethnography is particularly effective at discovering two type of requirement: 1.Requirements that are derived from the way that people actually work rather than the way I which process definitions suggest that they ought to work. 2.Requirements that are derived from cooperation and awareness of other people’s activities.

42. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 42 Requirements validation l Concerned with demonstrating that the requirements define the system that the customer really wants. l Requirements validation covers a part of analysis in that it is concerned with finding problems with requirements. 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. In fact, a change to the requirements usually means that the system design and the implementation must also be changed and the testing has to be performed again.

43. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 43 Checks required during the requirements validation process l Validity checks. Does the system provide the functions which best support the customer’s needs? ( Other functions maybe identified by a further analysis ) l Consistency checks. Are there any requirements conflicts? l Completeness checks. Are all the requirements needed to define all functions required by the customer sufficiently specified? l Realism checks. Can the requirements be implemented given available budget, technology and schedule? l Verifiability. Can the requirements be checked?

44. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 44 Requirements validation techniques The following techniques can be used individually or in conjunction. l Requirements reviews Systematic manual analysis of the requirements performed by a team of reviewers ( see next slides ). l Prototyping Using an executable model of the system to check requirements. Covered in Chapter 17. l Test-case generation Developing tests for requirements to check testability. If the test is difficult to design, usually the related requirements are difficult to implement.

45. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 45 Requirements reviews l A requirements review is a manual process that involves both client and contractor staff should be involved in reviews. l In other words these people should discuss. l Regular reviews should be held while the requirements definition is being formulated. l Reviews may be formal (with completed documents) or informal. Good communications between developers, customers and users can resolve problems at an early stage.

46. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 46 Formal and informal reviews l Informal reviews simply involve contractors discussing requirements with as many system stakeholders as possible; l Formal reviews the development team should “take” the client through the system requirements and explaining the implications of each requirements.

47. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 47 Checks that should be performed by reviews l Verifiability. Is the requirement realistically testable? l Comprehensibility. Is the requirement properly understood? l Traceability. Is the origin of the requirement clearly stated? It might be necessary to go back to the source of a requirement to assess the impact of the change. l Adaptability. Can the requirement be changed without a large impact on other requirements?

48. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 48 Requirements validation outputs l The requirements validation process should be output a report which point out potentially conflicts, contradictions, errors and omissions. l Then it is up to the user, the contractor stuff, the developers to negotiate a solution to the reported problems.

49. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 49 Requirements management l The requirements for large systems are frequently changing. l In fact, during the software process, the stakeholders’ understanding of the problem is constantly changing. l Requirements management is the process of managing changing requirements during the requirements engineering process and system development. l Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better understanding of the system is developed; Different viewpoints have different requirements and these are often contradictory.

50. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 50 Requirements management l It is hard for the users and customers to anticipate what effects the new system will have on the organization. l Often, only when the system has been deployed, new requirements inevitably emerge. l This is mainly due to the fact that, when the end- users have experience of the new system, they discover new needs and priority.

51. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 51 Requirements change 1. The priority of requirements from different viewpoints changes during the development process. Conflicts have to inevitably converge in a compromise. 2. System customers may specify requirements from a business perspective that conflict with end- user requirements. 3. The business and technical environment of the system changes during its development. 4. New hardware, new interface, business priority, new regulations, etc.

52. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 52 Requirement changes and the requirements management The requirements management is the process of identifying, understanding and controlling changes to system requirements. l It might be useful to keep track of individual requirements and maintain links between dependent requirements so that you can asset the impact of requirements changes. l The process of requirements management should start as soon as a draft a version of the requirement document is available.

53. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 53 Requirements evolution

54. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 54 Enduring and volatile requirements l From an evolution perspective, requirements fall into two classes: l Enduring requirements. Stable requirements derived from the core activity of the customer organisation and relate directly to the domain of the system. E.g., In a hospital, requirements will always relate to doctors, nurses, etc. These requirements may be derived from a domain conceptual models that show entities and relations between them. l Volatile requirements. Requirements which change during development or when the system is in use. E.g., In a hospital, requirements derived from healthcare policy;

55. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 55 A possible classification of volatile requirements

56. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 56 Requirements management planning l Since the RE process is very expensive, it might be useful to establish a planning. l In fact, during the requirements engineering process, you have to plan: Requirements identification How requirements are individually identified; they should be uniquely identified in order to keep a better traceability. A change management process The process followed when requirements change: the set of activities that estimate the impact and cost of changes. Traceability policies The policy for managing the amount of information about relationships between requirements and between system design and requirements that should be maintained (e.g., in a Data Base) CASE tool support The tool support required to help manage requirements change; tolls can range from specialist requirements management systems to simple data base systems.

57. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 57 Traceability l Traceability is concerned with the relationships between requirements, their sources and the system design. l There are three type of traceability information that should be maintained: 1. Source traceability Links from requirements to stakeholders who proposed these requirements; Links from requirements to rationale of the requirements themselves; 2. Requirements traceability Links between dependent requirements; a change to a requirement may propagate to its dependent requirements. 3. Design traceability Links from the requirements to the design; these links are used to assess the impact of a requirements change to system design and implementation.

58. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 58 A traceability matrix l A traceability matrix may be maintained to keep traceability information which relate requirements to sources, each other and design module

59. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 59 CASE tool support l Traceability matrix may be used for a small number of requirements but it might become too expensive to maintain, so often automated support is needed (e.g., DOORS, RequisitePro). These tool are needed for: l Requirements storage Requirements should be managed in a secure data store. l Change management The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated ( see next slides ). l Traceability management Automated retrieval of the links between requirements.

60. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 60 Requirements change management l Formal process for change management should apply to all proposed changes to the requirements in order to treat consistently them. l Principal stages Problem analysis and change specification. Identify and discuss requirements problem, propose change and provide feedback to the change requestor; Change analysis and costing. Assess effects of change on other requirements by traceability and estimate the cost in term of modifications to the requirements document and to the system design and implementation; Change implementation. Modify requirements document and, if necessary, system design and implementation. For that reason the requirement document should be modular and should minimize external references.

61. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 61 Change management

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

63. ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 7 Slide 63 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.