USE CASES BY Touseef Tahir Touseeftahirciitlahore edu pk

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

Use Cases Business Use case System use case 2 2/5/2022

Use Case – Ivar Jacobson, 1994 • Modeling technique used to describe what a new • • 3 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 2/5/2022

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. 4 2/5/2022

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 5 2/5/2022

USE CASE MODELING

Use Case Notation (Basic) System Boundary (often implied) Use Case Actor “Participates-In” Association 7 2/5/2022

Use Diagram for a Library System Reserve Book Browse Borrow Book Borrower Browser Return Books Borrow Journal Extend loan Return Journal Update Catalog Librarian 8 Journal Borrower Library System 2/5/2022

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 9 2/5/2022

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 10 2/5/2022

Relationship in Use Cases Extends Uses 11 2/5/2022

Use Cases (Advanced) Base Use Case <<extend>> Actor Extending Use Case Base Use Case Special Actor 12 Special Actor <<include>> Included Use Case 2/5/2022

Credit Card Validation System Perform Card Transaction Customer Retail Institution Process Customer Bill Reconcile Transactions Individual Customer Corporate Customer Manage Customer Acct Sponsoring Financial Institution Extended User 13 2/5/2022

inheritance versus include/Extend Inheritance versus Function Call 14 2/5/2022

Use Case (Advanced) Example Place Order Customer <<extend>> <<include>> Validate User Set delivery priority Commercial Customer 15 Residential Customer 2/5/2022

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 16 2/5/2022

Use Case Descriptions Pre and Post Conditions Preconditions: True Postconditions: If customer fails validation: customer exits system If customer passes validation: customer order processed 17 2/5/2022

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

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 19 2/5/2022

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 20 2/5/2022

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 21 2/5/2022

Components Of An Elaborated Use Case Priority Actor Summary Precondition Post-Condition 22 • Extend • Include • Normal Course of Events • Alternative Path • Exception • Assumption 2/5/2022

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 23 2/5/2022

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

Delete Information – Cont. • 1. 2. Alternative Path - The user does not confirm Deletion If the user does not confirm deletion, the information does not delete. Include: Cancel Action Exceptions: The system will not allow a user to delete information that is being used in the system. The system will not allow a user to delete another user If he/she does not have privilege. Assumptions: Deleted information is not retained in the system. 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. 25 2/5/2022

Elaborated Use Cases Different formats Two-column format user action software reaction 26 2/5/2022

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 27 2/5/2022

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 28 2/5/2022

Requirement Verification Sources Sinks 29 2/5/2022

Sources of Requirements The sources who initiated the information 30 2/5/2022

Sinks of Requirements The consumer of the information. 31 2/5/2022

Requirements Document Structure (1) 32 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 2/5/2022

Requirements Document Structure (2) • 33 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) 2/5/2022

Requirements Document Structure (3) 34 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 2/5/2022

Thank You Questions!!! 2/5/2022 35