1. Chapter 4 – Requirements Engineering Lecture 3 1Chapter 4 Requirements engineering

2. Topics covered  Functional and non-functional requirements  The software requirements document  Requirements specification  Requirements engineering processes  Requirements elicitation and analysis  Requirements validation  Requirements management 2Chapter 4 Requirements engineering

3. Requirements elicitation and analysis  Called requirements elicitation or requirements discovery.  technical staff work with customers to find out about  the application domain,  the services that the system should provide and  the system’s operational constraints.  Involves stakeholders  end-users,  managers,  engineers involved in maintenance,  domain experts  etc. 3Chapter 4 Requirements engineering

4. Problems of requirements 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 may change. 4Chapter 4 Requirements engineering

5. Requirements elicitation and analysis  Stages in formal elicitation:  Requirements discovery,  Requirements classification and organization,  Requirements prioritization and negotiation,  Requirements specification. Chapter 4 Requirements engineering5

6. The requirements elicitation and analysis process 6Chapter 4 Requirements engineering

7. Process activities  Requirements discovery  Interacting with stakeholders to discover their requirements. Domain requirements are also discovered at this stage.  Requirements classification and organisation  Groups related requirements and organises them into coherent clusters.  Prioritisation and negotiation  Prioritising requirements and resolving requirements conflicts.  Requirements specification  Requirements are documented and input into the next round of the spiral.

8. Requirements discovery  The process of gathering information about the required and existing systems and distilling the user and system requirements from this information.  Interaction is with system stakeholders from managers to external regulators.  Systems normally have a range of stakeholders. Chapter 4 Requirements engineering8

9. Stakeholders in the MHC-PMS  Patients whose information is recorded in the system.  Doctors who are responsible for assessing and treating patients.  Nurses who coordinate the consultations with doctors and administer some treatments.  Medical receptionists who manage patients’ appointments.  IT staff who are responsible for installing and maintaining the system. Chapter 4 Requirements engineering9

10. Stakeholders in the MHC-PMS  A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care.  Health care managers who obtain management information from the system.  Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and that record keeping procedures have been properly implemented. Chapter 4 Requirements engineering10

11. Interviewing  Formal or informal interviews with stakeholders are part of most RE processes.  Types of interview  Closed interviews based on pre-determined list of questions  Open interviews where various issues are explored with stakeholders.  Effective interviewing  Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.  Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system. Chapter 4 Requirements engineering11

12. Interviews in practice  Normally a mix of closed and open-ended interviewing.  Interviews are good for  an overall understanding of what stakeholders do and how they might interact with the system.  Interviews are not good for  understanding domain requirements  Requirements engineers cannot understand specific domain terminology;  Some domain knowledge is so familiar that people find it hard to articulate.

13. Scenarios (user stories)  Scenarios are real-life examples of how a system can be used.  Users don’t know what the use cases will be  only know how to do their work  can describe what they do  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.

14. Scenario for collecting medical history in MHC- PMS 14Chapter 4 Requirements engineering

15. Scenario for collecting medical history in MHC- PMS 15Chapter 4 Requirements engineering

16. Scenarios  Example: designing a music app  Possible scenarios. In each describe what you do.  I want to go running and take my phone.  I want to listen to music as I ride the bus to school  I want to listen to the newest album from X while doing my homework. Chapter 4 Requirements engineering16

17. Use cases  Use-cases are a scenario based technique  done in UML  identify the actors in an interaction  describe the interaction itself.  A set of use cases should describe all possible interactions with the system.  Extract these from the scenarios  use cases will be the same across many scenarios  the purpose of the scenarios is to tease out as many use cases as possible 17Chapter 4 Requirements engineering

18. Use cases  Format  High-level graphical model  supplemented by more detailed tabular description  At the very least, the description should include:  The name of the use case, which should summarize its purpose  The actor or actors  The flow of events  Assumptions about entry conditions 18Chapter 4 Requirements engineering

19. Use Cases  An actor is a user of a system in a particular role.  An actor can be human or an external system.  A usecase is a task that an actor needs to perform with the help of the system. Chapter 4 Requirements engineering19 BookBorrower PressureSensor Borrow Book Record Pressure

20. Use Cases  Actor is role, not an individual  librarian can have many roles  Actor must be a beneficiary of the use case  not librarian who processes book when borrowed  In naming actors, choose names that describe the role, not generic names, such as "user" or "client". Chapter 4 Requirements engineering20

21. Use Cases Chapter 4 Requirements engineering21 Visitor Borrow Book Return Book Search for Book Three separate use cases

22. Transfer-data use case  A use case in the MHC-PMS 22Chapter 5 System modeling

23. Tabular description of the ‘Transfer data’ use- case MHC-PMS: Transfer data ActorsMedical receptionist, patient records system (PRS) DescriptionA receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority. The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment. DataPatient’s personal information, treatment summary StimulusUser command issued by medical receptionist ResponseConfirmation that PRS has been updated CommentsThe receptionist must have appropriate security permissions to access the patient information and the PRS. 23Chapter 5 System modeling

24. Use cases  Sequence diagrams  used to add detail to use-cases  show the sequence of event processing in the system. Chapter 4 Requirements engineering24

25. Use cases for the MHC-PMS 25Chapter 4 Requirements engineering

26. Sequence diagram Chapter 4 Requirements engineering26

27. Key points  You can use a range of techniques for requirements elicitation including interviews, scenarios, use-cases and ethnography.  Requirements validation is the process of checking the requirements for validity, consistency, completeness, realism and verifiability.  Business, organizational and technical changes inevitably lead to changes to the requirements for a software system. Requirements management is the process of managing and controlling these changes. Chapter 4 Requirements engineering27