Requirements Inc BA Training Module 2.1 Use Case Modeling v9.01 ©2009 www.RequirementsInc.com

In this session.. We will Understand about modeling functional requirements using use cases Study the elements of a use case diagram – Semantics of entities and relationships <<Include>> and <<extend>> constructs Introduce use case text format, types of use cases

What is a use case? A use case is a particular example (a case) of how a system is used, literally a “case of system use”. A use case describes a sequence of interactions between an user and a system to achieve a significant goal, prompted by some triggering event. is a unit of business functionality represented as horizontal ellipse Online Banking System - Example use cases [Verb + Object] View Statement, Check Balance, etc. Formal Definition [Alistair Cockburn] Use Cases record a contract between system stakeholders about the behaviors of the system under discussion under various circumstances, organized by goals of selected actors”. Formal Definition [OMG] “The Use Case construct is used to define the behavior of a system or other semantic entity without revealing the entity’s internal structure. Each U`se Case specifies a sequence of actions, including variants, that the entity can perform, interacting with actors of the entity”.

Use Case Models and Use Cases pictorially depicts the functionalities of the system, the people and external systems (actors) interacting with the system drawn at the system level representing multiple use cases, use case – use case relationship, actor – use case relationship visualizes functional requirements Use case (textual) textually describes the interaction between the system and an actor is a sequence of related transactions performed by an actor and the system in a dialogue documents functional requirements

Use Case Model Use case model Is the starting point when designing a new system using the UML Provides a high level overview of a system Tells us what the system will do when interacting with actors Depicts the functionalities of the system as users perceive it ‘Sets context’ easily for conversations about requirements and system development Works well with Objects

Use Case Model Is focal to / binds all activities within a project A set of Use Cases can be developed to tell “stories” of how a system will be used, from the differing points of view of each of the actors. Use cases must be traceable to design and testing Use cases model will evolve! A Use Case describes a sequence of actions a system performs that yield an observable result of value to a particular actor An actor is someone or something outside of the system that interacts with the system

What is an actor? An actor is a person, organization, service or another system that plays a role in one or more interactions with your system. is external to the system, but is not a part of the system represented as a stick figure Time is an actor! Primary Actors Secondary Actors Initiate use cases Provide inputs Act as an on-demand service Receive messages E.g., Customer making payment E.g., Equifax used in a credit card company’s system to gather credit score - Customer receiving a funds deficit email alert End User Actors Organizational Actors Customer / client users Users within the organization E.g., Credit card customers in a credit card system E.g., Customer support reps within a credit card company, managers viewing monthly reports

What is an actor? Examine actors’ needs to determine use cases Actors should reflect the entire system lifecycle including: set up users, support users, client users, etc. “What’s my goal?”

Use Case Model Notation Actor An Actor is a user of the system / someone or something that interacts with the system. The role of the user is written beneath the icon. Use Case A Use Case is functionality provided by the system (e.g., Register Car, Delete User). System boundary Marks the bounds of the system. Distinguish functionalities “in scope” and “out of scope”. Package Logical folders to group related use cases together. Typically used then the use case diagram is too large. May used to represent different releases. Directed Association Associations are used to interactions. Directed associations are depicted by an arrow with the direction originating from the trigger. Often misread as information flow, hence avoided.

Use Case Model Notation Association Associations are used to indicate interactions. (Undirected) associations are depicted by a plain line, does not indicate trigger. Primary actors on the left and secondary actors on the right if using plain association Generaliza-tion Inheritance relationship (generalization in UML) is indicated by a block arrow pointing to the parent. <<Include>> stereotype A base use case executes an <<include>> use case as part of its flow to complete its business functionality. E.g., Transfer Balance <<includes>> Check Balance <<Extend>> stereotype A base use case may be extended by an <<extend>> use case based on a certain condition. E.g., Buy extended warranty <<Extends>> Buy laptop

Examples

Examples System Student Maintain schedule Billing System Professor Registrar Billing System Student Maintain schedule Maintain curriculum Request course roster

Examples

Examples

Use Case Diagram

Use Case Scenarios Use cases are scenario or flow based – ‘what if’ Success or Main or Primary scenarios – all goes well, happy path Alternative success scenarios – not typical but leading to success Failure or Exception scenarios What are the possible scenarios for a login use case?

Use Case Representation Basic Use Case representation Extending Use Case representations Purchase Book Purchase Book Add one day shipping <<extend>>

Use Case – Actor interaction Ecommerce System Reception is usually on the right Initiation is usually on the left View catalog Actor with custom icon Add to Cart Purchase Book <<extend>> Order Management System Customer Add 1 day shipping

Actor Generalization DB Admin Backup Admin Deployment Admin Op. Data System Replicate DB DB Admin Backup User Data Startup Backup Admin Shutdown Deploy Web App Deployment Admin

Actor Generalization Sys Admin DB Admin Backup Admin Deployment Admin Op. Data System Startup Sys Admin Shutdown DB Admin Replicate DB Backup User Data Backup Admin Deploy Web App Deployment Admin

Use Case Generalization Perform search Search by author Search by ISBN Search by title

Preconditions Preconditions are statements / use cases that must be true before another use case is executed E.g., “Register for an account” is a precondition to “Login” “Login” is a precondition to “Pay fees”

<<Include>> Construct A Base use case B Included use case <<include>> Signifies that the base use case calls the included use case (also <<uses>> or <<includes>>) Eg., A includes B A is the base (calling) use case, B is the included (called) use case During A’s execution, B will be called one or more times and then control comes back to A A cannot produce success outcome without running B Nothing precludes B from being executed directly by the user/another use case without <<include>> relationship Mimics subroutines to reuse a frequently accessed functionality (called by different use cases)

<<Include>> Construct When to <<include>> Reusability: To pull out use cases that may be called (included) by many use cases (behavior that is common to one or more use cases) Modularity: To keep different business goals separate 19

Is this correct?

<<Extend>> Construct A Base use case B Extending use case <<extend>> Signifies that the extending use case extends the functionality of the base use case Eg., B extends A A is the base use case, B extends the functionality of A B may or may not be executed (when a certain condition is satisfied during A’s execution) A can run (produce success outcome) without running B Nothing precludes B from being executed directly by the user/another use case without <<extend>> relationship Usually used to keep special / specific business cases separate from a basic flow

<<Extend>> Construct When to <<extend>> Pull out optional steps out of a use case so the use case outcomes can be distinct and unconditional Apply discount code Purchase item Add maintenance <<extend>>

Is this correct? Pay by check <<extend>> Pay for dinner Pay by credit card <<extend>> Pay by cash

Include and Extend - Usage

<<Include>> and <<Extend>> What’s missing in this diagram? Buy lunch <<include>> Make payment <<include>> Buy theme park ticket Theme park tourist <<extend>> Buy speedpass ticket

Use Case Guidelines All use cases must provide significant value to one or more actors (exception – included and extension use cases) Use cases must be meaningful independently. E.g., Enter PIN may not be executed by itself. Doesn’t satisfy a goal either (exception – included and extension use cases) Use cases must be completed in one sitting Separating use cases Flow occurs in more than one use case? Consider include Flow occurs optionally? Consider extend Across RUP Same use case may be iteratively built New use cases may be part of a new iteration

Use Case Format Title – must start with a verb – Make payment Description and purpose Diagrams and documents Pre-conditions Post-conditions Included / extending use cases Glossary Primary Actors Secondary Actors Main flow Alternate flow(s) Exception flow(s)

Use Case Types Business Use Case (BUC) Application Use Case (AUC) Supports business policy and operations, independent of implementation Generic, rule book Transfer funds – process is independent of mode of operation Application Use Case (AUC) Supports BUC but dependent on the implementation of an application, eg., online system Specific, triggered by a user and documents interaction Transfer funds – process is specific to the mode (online) System Use Case (SUC) Similar to AUC but no user interaction Triggered by AUC / system Run Payroll

Review Course Website For additional reference materials, instructions for the next session, assignments, tests, review the course website at http://ba.requirementsinc.com

` Srinivas, 703-468-1921 Sri@RequirementsInc.com RequirementsInc.com