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

2. 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 engineering2

3. 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 engineering3

4. 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 engineering4

5. Interviews in practice Normally a mix of closed and open-ended interviewing. Interviews are good for getting 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 or think that it isn’t worth articulating.

6. Scenarios Scenarios are real-life examples of how a system can be used. 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.

7. Scenario for collecting medical history in MHC- PMS Mental Health Care-Patient Management System 7Chapter 4 Requirements engineering

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

9. Use cases Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system. 9Chapter 4 Requirements engineering

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

11. 11 Goals of Analysis Modeling Provides the first technical representation of a system Is easy to understand and maintain Deals with the problem of size by partitioning the system Uses graphics whenever possible Differentiates between essential information versus implementation information Helps in the tracking and evaluation of interfaces Provides tools other than narrative text to describe software logic and policy

12. Requirements Analysis

13. 13 Overall Objectives Three primary objectives – To describe what the customer requires – To establish a basis for the creation of a software design – To define a set of requirements that can be validated once the software is built

14. 14 Analysis Modeling Approaches Structured analysis – Considers data and the processes that transform the data as separate entities – Data is modeled in terms of only attributes and relationships (but no operations) – Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data Object-oriented analysis – Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements

15. 15 A Set of Models Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions Scenario-based modeling – represents the system from the user's point of view Class-based modeling – defines objects, attributes, and relationships Behavioral modeling – depicts the states of the classes and the impact of events on these states

16. 16 Elements of the Analysis Model Use case text Use case diagrams Activity diagrams Swim lane diagrams Scenario-based modeling Class diagrams Analysis packages CRC models Collaboration diagrams Class-based modeling Data structure diagrams Data flow diagrams Control-flow diagrams Processing narratives Flow-oriented modeling State diagrams Sequence diagrams Behavioral modeling Structured AnalysisObject-oriented Analysis

17. Flow-oriented Modeling

18. 18 Data Modeling Identify the following items – Data objects (Entities) – Data attributes – Relationships – Cardinality (number of occurrences)

19. 19 Data Flow and Control Flow Data Flow Diagram – Depicts how input is transformed into output as data objects move through a system Process Specification – Describes data flow processing at the lowest level of refinement in the data flow diagrams Control Flow Diagram – Illustrates how events affect the behavior of a system through the use of state diagrams

20. 20 Diagram Layering and Process Refinement Context-level diagram Level 1 diagram Process Specification

21. Scenario-based Modeling

22. 22 Writing Use Cases Writing of use cases was previously described in Chapter 7 – Requirements Engineering It is effective to use the first person “I” to describe how the actor interacts with the software Format of the text part of a use case (See examples in Pressman textbook on pp. 188-189) Use-case title: Actor: Description: I …

23. 23 Example Use Case Diagram Make automated menu selections Order food and drink Pay for food and drink Notify customer that food and drink are ready Customer Cook Payment System Expert Menu System

24. 24 Activity Diagrams Creation of activity diagrams was previously described in Chapter 7 – Requirements Engineering Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario Uses flowchart-like symbols – Rounded rectangle - represent a specific system function/action – Arrow - represents the flow of control from one function/action to another – Diamond - represents a branching decision – Solid bar – represents the fork and join of parallel activities

25. 25 Example Activity Diagram

26. Class-based Modeling

27. 27 Example Class Box Component + componentID - telephoneNumber - componentStatus - delayTime - masterPassword - numberOfTries + program() + display() + reset() + query() - modify() + call() Class Name Attributes Operations

28. UML Class Diagrams and Examples

29. Behavioral Modeling

30. Hotel Reservation State Transition Diagram