A Use Case Primer 1

The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers to think through the design of a system from the perspective of a user.  Use cases engage the users in the requirements process, helping them to understand the proposed system and giving them a way to communicate their needs.  Use cases give context for the requirements of the system.  Use cases provide an ordering mechanism for requirements; they show the ordering of things. 2

The Benefits of Use Cases (Cont’d)  In most cases, developers write use cases. That shows they understand the requirements and accept responsibility for them.  Use cases are a critical tool in the analysis process, helping to understand what the system needs to do.  Use cases are a critical tool in the design and implementation process, reducing the risk of inconsistencies when moving from requirement to design to implementation.  Use cases carry over directly into the testing process.  Use cases serve as inputs to the user documentation. 3

What is a Use Case? A use case describes sequences of actions a system performs that yield an observable result of value to a particular actor. (In UML, a use case is represented by an oval.) 4

Use Case Basics  Sequences of actions: The sequences of actions describe a set of functions performed, an algorithmic procedure, or any other internal process that produces a result. The set is invoked when the actor initiates the use case by providing some input to the system. An action is atomic; that is, it is performed entirely or not at all. 5

Use Case Basics (Cont’d)  System performs: The system works for the actor. It exhibits the functionality described in the use case and takes its orders from the actor as to when to do what.  An observable result of value: The use case must be “of value” to a user. The system must do something for the user. 6

Use Case Basics (Cont’d)  A particular actor: The particular actor is the individual or device that initiates the action. 7

What is an Actor? An actor is someone or something that interacts with the system. (In UML an actor is represented as a simple stick figure.) 8

Types of Actors  Users: Users act on the system and this is the most common type of actors.  Other Systems or Applications: Most software systems interact with other systems or applications. These are also actors.  A Device: Input and output devices can also be actors. 9

Mandatory Elements of a Use Case 1. Name: Each use case has a name which describes what is accomplished by interaction with the actor. It must be unique for each use case. 2. Brief Description: The purpose of the use case should be described in one or two sentences. 3. Actors: Since a use case has no meaning outside its use by an actor, each actor that participates in the use case must be listed. 10

Mandatory Elements of a Use Case (Cont’d) 4. Flow of Events: The heart of the use case is the event flow, usually expressed as a textual description of the interactions between the system and the actor. The flow of events can consist of both the basic flow, or main path through the use case and alternate flows which are executed only under certain circumstances. 11

Optional Use Case Elements  Pre-conditions: Those conditions that must be true before a use case can start.  Post-conditions: Conditions that describe the state of the system after a use case has completed.  System or Subsystem: In a system comprised of many subsystems, it must be specified whether a use case is a system- level use case or which subsystem it is identified with. 12

Optional Use Case Elements (Cont’d)  Other Stakeholders: It may be useful to identify other stakeholders who are affected by the use case.  Special Requirements: There may be special requirements (e.g., performance or throughput) that may be related to a use case that should be specified. 13

Optional Use Case Elements (Cont’d)  Other Stakeholders: It may be useful to identify other stakeholders who are affected by the use case.  Special Requirements: There may be special requirements (e.g., performance or throughput) that may be related to a use case that should be specified. 14

Building the Use Case Model  It is a top down process that depends on first building a context model of the system.  That model is successively refined until the detailed behaviors are understood.  It is an iterative process in which the various steps are revisited over time. 15

Steps in Building the Use- Case Model 1. Identify and Describe the Actors: Identify all actors that interact with the system. Who uses the system? Who gets information from the system? Who provides information to the system? Where in the organization is the system used? Who supports and maintains the system? What other systems use the system? 16

Steps in Building the Use- Case Model (Cont’d) 2. Identify the Use Cases and Write a Brief Description: Identify what actors need to do to accomplish their tasks. What will the actor use the system for? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about external events or changes? Will the actor need to be informed about certain occurrences in the system? 17

Steps in Building the Use- Case Model (Cont’d)  Choose Use-Case names carefully – a few words beginning with a verb is usually a good idea, e.g., “Change Password”.  Consider the following template: Use-Case Name Actor(s): Description: 18

Steps in Building the Use- Case Model (Cont’d) 3. Identify the Actor and Use-Case Relationship: Although only one actor can initiate a use-case, many use-cases involve the participation of multiple actors. Each use-case must be analyzed to see what actors interact with it. 19

Steps in Building the Use- Case Model (Cont’d) 4. Outline the Individual Use Cases: Before developing detailed use-cases for the system, outlines of each should be developed. Of particular interest at this point is the flow of events, including the basic and alternate flows. 20

Steps in Building the Use- Case Model (Cont’d)  Basic flow:  What event starts the use case?  How does the use case end?  How does the use case repeat some behavior?  Alternate flow:  Are there optional situations in the use case?  What odd cases might happen?  What variants might happen?  What may go wrong?  What may not happen?  What kind of resources can be blocked? 21

Steps in Building the Use- Case Model (Cont’d) 5. Refine the Use Cases: At some point later in the project lifecycle, the time will be right to refine the use cases developed. At that time there are a number of additional factors to be considered. 22

Steps in Building the Use- Case Model (Cont’d)  All alternate flows, including exception conditions: Identifying primary alternate flows is straightforward, but flows due to exception conditions may not be clear initially.  Pre- and Post-conditions: The refinement process will start to identify state information that controls the behavior of the system 23

Use Cases and User Interfaces  The world of use-case specification and user interface design tend to lead parallel lives.  The development team must decide what choices the user makes given the screens, dialog boxes, and so on that we have presented to the user, what the system does based on those selections, and what screens, choices, and so on the system presents to the user. 24

The Use Cases and User Interfaces Conundrum  How can a use case be specified if the user interface hasn’t been designed yet?  How can the user interface be designed to implement use case that have yet to be specified? 25

Use Cases and Storyboarding  A Storyboard Defines:  Who the players are  What happens to them  How it happens  If the player is a specific user and the interaction is between that user and the user interface, then storyboarding can help us describe how we are approaching the interaction.  We can use iterative and incremental techniques to converge on the user interface and the use case at the same time. 26

Use Case Storyboard Example Use Case Sequence: Inserting Online Clip Art (This series of steps within a larger use case allows the user to access an online clip art repository and select and insert a new clip art item.) 1. The user puts the cursor at the desired clip art location and selects the function for inserting clip art. 2. The system displays the clip art source locations. 3. The user selects the “Clip Online” choice. 4. The system launches the browser and automatically navigates to the online library. 5. The user navigates to the selected art item