Touseef Tahir Lecturer CS COMSATS Institute of Information Technology, Lahore USE CASES BY

6/4/ Use Cases Business Use case System use case

6/4/ 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

6/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.

6/4/ 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

USE CASE MODELING

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

6/4/ 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

6/4/ 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

6/4/ 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

6/4/ Relationship in Use Cases Extends Uses

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

6/4/ 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

6/4/ inheritance versus include/Extend Inheritance versus Function Call

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

6/4/ 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

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

6/4/ 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

6/4/ 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

6/4/ 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

6/4/ 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

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

6/4/ 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

6/4/ 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.

6/4/ 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.

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

6/4/ 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

6/4/ 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

6/4/ Requirement Verification Sources Sinks

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

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

6/4/ 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

6/4/ 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)

6/4/ 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

Thank You Questions!!! 6/4/