Chapter 1 Requirements Engineering Processes

1. Chapter 1Requirements Engineering Processes Lab 01 (Software Engineering 8th Ed., Chapter 7)

2. Objectives • To describe the principal requirements engineering activities and their relationships • To introduce techniques for requirements elicitation and analysis • To describe requirements validation and the role of requirements reviews • To discuss the role of requirements management in support of other requirements engineering processes

3. Principle requirements engineering activities Feasibility studies Requirements elicitation and analysis Requirements validation Requirements management Figure 7.2 Spiral model of requirements engineering processes

4. Techniques for requirements elicitation and analysis Requirements discovery Requirements classification and organisation Requirements prioritisation and negotiation Requirements documentation Figure 7.3 The requirements elicitation and analysis process

5. Techniques for requirements elicitation and analysis (cont’d) • Stakeholders • Any person or group who will be affected by the system, directly or indirectly • End-users • Managers • Engineers involved in development or maintenance • Domain experts • Trade union reps

6. Question 1 • Suggest who might be stakeholders in a university student records system? Explain why it is almost inevitable that the requirements of the different stakeholders will conflict in some way

7. Techniques for requirements elicitation and analysis (cont’d) • Requirements discovery • Viewpoints • A way of structuring the requirements to represent the perspectives of different stakeholders • Interactorviewpoints • People or other systems that interact directly with the system • Indirect viewpoints • Stakeholders who do not use the system themselves but who influence the requirements • Domain viewpoints • Domain characteristics and constraints that influence the requirements • Interviewing • The RE team puts questions to stakeholders about the system that they use and the system to be developed • Closed interviews • A pre-defined set of questions are answered • Open interviews • No pre-defined agenda and a range of issues are explored with stakeholders

8. Question 2 • A software system is to be developed to manage the records of patients who enter a clinic for treatment. The records include records of the all regular patient monitoring (temperature, blood pressure, etc) treatments given, patient reactions and so on. After treatment, the records of their stay are sent to the patient’s doctor who maintains their complete medical record. Identify the principal viewpoints which might be taken into account in the specification of this system and organize these using a viewpoint hierarchy diagram.

9. Question 3 • For the “Library manager”, “Users” and “System managers” viewpoints identified in the library system, LIBSYS (Figure 7.4), suggest three requirements that could be suggested by the stakeholders associated with that viewpoint. • The LIBSYS system has to include support for cataloguing new documents where the system catalog may be distributed across several machines. What are likely to be the most important types of non-functional requirements associated with the cataloguing facilities?

10. Question 3 (cont’d) Figure 7.4 Viewpoints in LIBSYS

11. Techniques for requirements elicitation and analysis (cont’d) • Requirements discovery • Scenarios • Real-life examples of how a system can be used • 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 • Use-cases • Scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself • Ethnography • Observation of the day-to-day work and notes made of the actual task in which participants are involved

12. Question 4 • Discuss how social and political factors influence the system requirements of a system to manage the costs of public healthcare.

13. Requirements validation and requirements reviews • Checks • Validity • Does the system provide the functions which best support the customer’s needs? • Consistency • Are there any requirements conflicts? • Completeness • Are all functions required by the customer included? • Realism • Can the requirements be implemented given available budget and technology? • Verifiability • Can the requirements be checked?

14. Requirements validation and requirements reviews (cont’d) • Techniques • Reviews • Systematic manual analysis of the requirements • Verifiability • Is the requirement realistically testable? • Comprehensibility • Is the requirement properly understood? • Traceability • Is the origin of the requirement clearly stated? • Adaptability • Can the requirement be changed without a large impact on other requirements? • Prototyping • Using an executable model of the system to check requirements • Test-case generation • Developing tests for requirements to check testability

15. Requirements management • Change • Evolution • Enduring requirements • Stable requirements derived from the core activity of the customer organisation • Volatile requirements • Requirements which change during development or when the system is in use • Mutable requirements • Requirements that change due to the system’s environment • Emergent requirements • Requirements that emerge as understanding of the system develops • Consequential requirements • Requirements that result from the introduction of the computer system (change of working processes) • Compatibility requirements • Requirements that depend on other systems or organisational processes

16. Requirements management (cont’d) • Management planning • Requirements identification • How requirements are individually identified • A change management process • The process followed when analysing a requirements change • Traceability policies • The amount of information about requirements relationships that is maintained • CASE tool support • The tool support required to help manage requirements change • Requirements storage • Requirements should be managed in a secure, managed data store • Change management • The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated • Traceability management • Automated retrieval of the links between requirements

17. Requirements management (cont’d) • Change management • Problem analysis • Discuss requirements problem and propose change • Change analysis and costing • Assess effects of change on other requirements • Change implementation • Modify requirements document and other documents to reflect change