1. Touseef Tahir Touseeftahir@ciitlahore.edu.pk Lecturer CS COMSATS Institute of Information Technology, Lahore USE CASES BY

2. 6/4/2016 2 Use Cases Business Use case System use case

3. 6/4/2016 3 Use Case – Ivar Jacobson, 1994 Modeling technique used to describe what a new system should do or what an existing system already does. Captures a discussion process between the system developer and the customer Comparatively easy to understand intuitively – even without knowing the notation. Can be easily discussed with the customer who may not be familiar with UML. Leads to a requirement specification on which all agree

4. 6/4/2016 4 Use Case Model Use Case Boundaries of the system are defined by functionality that is handled by the system. Each use case specifies a complete functionality (from its initiation by an actor until it has performed the requested functionality). Actor An entity that has an interest in interacting with the system – a human or some other device or system.

5. 6/4/2016 5 Use Case Principles Describes required functionality in terms of the user – system Identifies external actors Identifies system boundary Describes scenarios of use Describes pre/post conditions Describes variants/exceptions

6. USE CASE MODELING

7. 6/4/2016 7 Use Case Notation (Basic) Use Case Actor “Participates-In” Association System Boundary (often implied)

8. 6/4/2016 8 Use Diagram for a Library System Library System Book Borrower Reserve Book Borrow Book Return Books Extend loan Browser Browse Librarian Update Catalog Journal Borrower Borrow Journal Return Journal

9. 6/4/2016 9 Use Case Model Represents a use case view of the system – how the system is going to be used System is treated as a black box Aid to the user – decide and describe the functional requirements of the system Aid to the developer – give a clear and consistent description of what the system should do – model is used throughout the development process. Aid to the tester – Provide a basis for performing system tests that verify the system Traceability – Provide the ability to trace functional requirements into actual classes and operations in the system

10. 6/4/2016 10 Creating the Use Case Model In an iterative cycle Finding the actors Finding the use cases Defining the system Defining the relationship between use cases Validating the model

11. 6/4/2016 11 Relationship in Use Cases Extends Uses

12. 6/4/2016 12 Use Cases (Advanced) Special Actor Special Actor Base Use Case Extending Use Case > Base Use Case Included Use Case >

13. 6/4/2016 13 CustomerIndividual Customer Corporate Customer Perform Card Transaction Credit Card Validation System Retail Institution Sponsoring Financial Institution Process Customer Bill Reconcile Transactions Manage Customer Acct Extended User

14. 6/4/2016 14 inheritance versus include/Extend Inheritance versus Function Call

15. 6/4/2016 15 Use Case (Advanced) Example CustomerCommercial Customer Residential Customer Validate User Place Order > Set delivery priority >

16. 6/4/2016 16 Use Case Descriptions Sequence of Activities Place Order 1. Validate User (included) 2. Collect user’s order items 3. Set Delivery priority (extend) 4. Submit order for processing

17. 6/4/2016 17 Use Case Descriptions Pre and Post Conditions Preconditions: True Postconditions: If customer fails validation: customer exits system If customer passes validation: customer order processed

18. 6/4/2016 18 Use Case Descriptions Exceptions 1.User fails validation 2.User cancels order 3.User orders invalid item 4.User requests invalid quantity 5.User order exceeds available credit

19. 6/4/2016 19 Use Case Hints Use language of user Avoid implementation Get good scenarios Single, identifiable and reasonably atomic behavior Describes flow of events clearly enough so outsider can follow

20. 6/4/2016 20 Use Case Hints Show only use cases that are important to understand system Show only actors that relate to use cases Develop use cases in iterative

21. 6/4/2016 21 Use Case Hints Specify actor names by specific roles Use top level diagram to show context Decompose top-level use cases to show requirements Group common use cases into packages

22. 6/4/2016 22 Components Of An Elaborated Use Case Priority Actor Summary Precondition Post-Condition Extend Include Normal Course of Events Alternative Path Exception Assumption

23. 6/4/2016 23 Delete Information Priority: 3 Actors: User Summary: Deleting information allows the user to permanently remove information from the system. Deleting information is only possible when the information has not been used in the system. Preconditions: Information was previously saved to the system and a user needs to permanently delete the information. Post-Conditions: The information is no longer available anywhere in the system. Includes: Cancel Action Extends: None

24. 6/4/2016 24 Delete Information – Cont. Normal Course of Events: 1. The use case starts when the user wants to get delete an entire set of information such as a user, commission plan, or group. 2. The user selects the set of information that they would like to delete and directs the system to delete the information. 3. Exception 1, 2 4. The system responds by asking the user to confirm deleting the information. 5. The user confirms deletion. 6. Alternative Path: Cancel Action 7. A system responds by deleting the information and notifying the user that the information was deleted from the system. 8. This use case ends.

25. 6/4/2016 25 Delete Information – Cont. Alternative Path - The user does not confirm Deletion 1. If the user does not confirm deletion, the information does not delete. 2. Include: Cancel Action Exceptions: 1. The system will not allow a user to delete information that is being used in the system. 2. The system will not allow a user to delete another user If he/she does not have privilege. Assumptions: 1. Deleted information is not retained in the system. 2. Deleting information covers a permanent deletion of an entire set of data such as a commission plan, user, group etc. Deleting a portion of an entire set constitutes modifying the set of data.

26. 6/4/2016 26 Elaborated Use Cases Different formats Two-column format user action software reaction

27. 6/4/2016 27 Limitations of Use Cases Use cases alone are not sufficient. There are kinds of requirements (mostly non-functional) that need to be understood. Domain (Business) Rules are not documented Legal Issues

28. 6/4/2016 28 Limitations of Use Cases There are kinds of requirements that need to be understood. Usability  Color blind people should not have any difficulty in using the system – color coding should take care of common forms of color blindness. Reliability  The system needs to support 7 x 24 operation Performance  Authorization should be completed within 1 minute 90% of the time.  Average authorization confirmation time should not exceed 30 seconds. Portability  The system should run on Windows 98 and above as well as Sun Solaris 7.0 and above. Access  System should be accessible over the internet – hidden requirement – security

29. 6/4/2016 29 Requirement Verification Sources Sinks

30. 6/4/2016 30 Sources of Requirements The sources who initiated the information

31. 6/4/2016 31 Sinks of Requirements The consumer of the information.

32. 6/4/2016 32 Requirements Document Structure (1) SECTION 1: Introduction purpose (including audience) Scope (what the product does/does not), benefits, obectives definitions, acronyms References Overview of Document SECTION 2: Overall Description Product Perspective - How product relates to other systems Product Functions – high level description of each function User Characteristics Constraints. E.g. Hardware, safety, standards etc Assumptions

33. 6/4/2016 33 Requirements Document Structure (2) SECTION 3: Specific Requirements – Minimum Inputs Outputs All functions performed in response to inputs and outputs – Complete List External Interfaces (Names, description, source, valid range, unit, Functions – actions that take place – “The system shall…” – Specific detail of each function – see form based requirements specification Performance Requirements Database Requirements Design Constraints e.g. standards Non-functional requirements (more about these later)

34. 6/4/2016 34 Requirements Document Structure (3) SECTION 3 continued Organisation of the SECTION 3  By system mode  Training, normal, emergency  By user class By objects By feature By stimulus (Especially real-time systems e.g. pressure change) By response (everything to do with a certain output e.g. producing invoices) APPENDICES E.g. sample inputs, cost analyses, user surveys, background information INDEX

35. Thank You Questions!!! 6/4/2016 35