1. 1 Real-time requirements  Intro to Software Engineering  Software Development Process Models  Formal methods in software specification  Structured Analysis  Object-oriented analysis and the UML Use Cases

2. 2 Object-oriented analysis– Use Case Use Case diagram of inertial measurement system.

3. 3 Context diagram Inertial Measurement System

4. 4 Example: Library Use Case Diagram A computerized library system for a university keeps track of all books and periodicals in the library and their check-out status. Checkout and return are automated through a bar code reader (an external device). The library system also interfaces with an external relational database which stores information about the library users (students, faculty, and staff), including whether they have any library items checked out.. Library users can access the catalog and recall books and periodicals. Library employees have the same access as well as additional capabilities (e.g., listing the status of an item). (Note: the library catalog is part of the library computer system so it is not shown as an actor.)

5. 5 Use Case for Employee Login 1.Employee initiates use case by entering user name 2.System prompts for password 3.If password is valid, employee is logged on and now has access to employee commands Starting and Ending Conditions? Exceptions? e.g., cannot find the employee login

6. 6 Use Case for Check book availability 1.User/Employee initiates use case by selecting the check book availability option 2.System prompts for choice of search by title, author, or call number 3.User makes selection and enters title, author or call number 4.System performs search through the library catalog database 5.If a match is found, system displays item status (not checked out, checked out and due date, overdue) Starting and Ending Conditions? Exceptions?

7. 7 >: Functional Decomposition  Problem: A function in the original problem statement is too complex to be solvable immediately  Solution: Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases CreateDocument Scan OCR Check >

8. 8 >: Reuse of Existing Functionality  Problem: How can we reuse existing functions?  Solution: The include association (“A delegates to B”)  Note: The base case cannot exist alone. It is always called with the supplier use case ViewMap OpenIncident AllocateResources > Base Use Case Supplier Use Case

9. 9 Home Automation example – factor out common functionality

10. 10 Another Home Automation example – factor out common functionality

11. 11 > Association for Use Cases  Problem: The functionality in the original problem statement needs to be extended.  Solution: An extend association: B is an extension of A.  Note: In an extend association, the base use case can be executed without the use case extension ReportEmergency FieldOfficer Help > A B Base Use Case

12. 12 Home Automation example

13. 13 ValidateUser CheckPassword CheckFingerprint Parent Case Child Use Case Generalization association in use cases  Problem: You have common behavior among use cases and want to factor this out.  Solution: The generalization association factors out common behavior.

14. 14 Example using >

15. 15 Simplified with an abstract use case

16. 16 Anesthesia Machine Use Cases

17. 17 Decomposition of the Deliver Anesthesia Use Case

18. 18 Use Case Activity Breakdown

19. 19 Ventilator Use Cases

20. 20 User Interface Use Cases

21. 21 Vaporizer Use Cases

22. 22 SPO2 Monitor Use Cases

23. 23 CO2 Monitor Use Cases

24. 24 Agent Monitor Use Cases

25. 25 Breathing Circuit Use Cases

26. 26 Bad Use Case Modeling

27. 27 Adding a Textural Characterization

28. 28 Use Case Relations

29. 29 Relating Text and Scenarios

30. 30 Use Case Sequence Diagram

31. 31 Deliver Anesthesia Collaboration

32. 32 Elaborated Scenario Part 1

33. 33 Elaborated Scenario Part 2

34. 34 Alarm On Critical Event Statechart

35. 35 Statecharts and Sequence Diagrams

36. 36 Display Waveform Activity Diagram

37. 37 Use Case Timing Diagram

38. 38 Best practices in specifying requirements  Bad: The systems shall be completely reliable. The system shall be modular. The system shall be maintainable. The system will be fast. Errors shall be less than 99%.  Better: Response times for all level one actions will be less than 100 ms. The cyclomatic complexity of each module shall be in the range or 10 to 40. 95% of the transactions shall be processed in less than 1 s. An operator shall not have to wait for the transaction to complete. MTBF shall be 100 hours of continuous operation.