Chapter 6 USE CASES Objectives Identify and write use cases Use the brief, casual and fully dressed formats Apply tests to identify suitable use cases

Chapter 6USE CASES

Objectives•Identify and write use cases•Use the brief, casual and fully dressed formats•Apply tests to identify suitable use cases•Relate use case analysis to iterative development

“The indispensable first step to getting the things you want out of life: decide what you want.”

- Ben Stein

Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 2

Feature Lists vs. Use Cases

• Older methods of detailing requirements tended to have many pages of detailed feature lists. Usually the details could not be seen in context.

• Current philosophy is to use a higher level of detail with use cases instead of a list.

• Use cases focus on who the key actors are, their goals, and common tasks.

(High level System Feature Lists are still acceptable when they can give a succict summary of the system and ‘n some feature-driven applications, such asapplication servers, database products, middleware or back-end systems.)

ID Feature

FEAT1.9 The system shall accept entry of item identifiers.

. . . . . .

FEAT2.4 The system shall log credit payments to the accounts receivable system.


Use Cases

• Writing Use Cases is not a specifically OO artifact – they are simply written stories: they are stories of using a system

• However, they are a best practice for elaborating and understanding requirements.– Simple and familiar storytelling makes it easier,

especially for customers, to contribute and review goals.

– Use cases keep it simple (KISS)– They emphasize goals and the user perspective.– …


Example

• Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment info, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items.


Use Case Relationships

• Use cases, in turn, influence many other analysis, design, implementation, project management and test artifacts.

Domain Model

Use Case Model

Interaction DiagramsDesign

Requirements

Business Model

VISION

GLOSSARY

SUPPLEMENTARYSPECIFICATION


Fig. 6.1 Sample UP

artifact influence

?

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...


Definitions

• An actor is something with behavior, such as a person (identified by role), computer system, or organization.– Ex. Cashier

• A scenario (use case instance) is a specific sequence of actions and interactions bw actors and the system.– It is one particular story of using a system or one path

through the use case.

• A use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.

• A Use Case Model is the set of all written use cases.– It is a model of the system functionality and environment.


Three Types of Actors

• Primary Actor– Has goals to be fulfilled by system– Emphasis is on the primary actor for the use case.– Ex. Cashier

• Supporting Actor– Provides service to the system.– Other actors are listed as stakeholders.– Ex. Automated Payment Authorization Service.

• Offstage Actor– Interested in the behavior, but no contribution– Ex. Government Tax Agency.

In diagrams, Primary actors go on the left and others on the right.


Use Cases are not diagrams !

– Use Cases may have a diagram associated with them, and a use case diagram is an easy way for an analyst to discuss a process with a subject matter expert (SME).

– But use cases are primarily text. The text is important. The diagram is optional.

– Use case modeling is primarily an act of writing text, not drawing diagrams.

• Capture the specific ways of using the system as dialogues between an actor and the system.


Use-Case Driven Development

• Requirements are primarily recorded in the Use Case model.

• Iterations are planned around implementing particular Use Cases.

• Use Case Realizations drive design.– The team designs collaborating objects and subsystems in

order to perform or realize the use cases.

• Use Case often influence the way user manuals are organized.

• Functional or system testing corresponds to the scenarios of use cases.


Working with Use Cases

• Determine the actors that will interact with the system.– We cannot understand a system until we know who

will use it• Direct users• Users responsible to operate and maintain it• External systems used by the system• External systems that interact with the system

• Examine the actors and document their needs.

• For each separate need, create a use case.

• During Analysis, extend use cases with interaction diagrams.


Actors or Use Cases First?

• Because you have to understand each part of Use Cases, the parts are presented separately. But those who create use cases switch back and forth.

• The text describes use cases substantially before paying attention to actors. – Each specification must be testable– Write from actor’s perspective, in actor’s vocabulary

• Typically, both actors and use cases are identified early and then examined to see if more use cases can be found from the actors, or more actors found by examining the use cases.


Guideline: Emphasize Goals

• Seeing requirements as identifying tasks to be done has a strong bias toward reproducing the existing system, even when it is being replaced because it is seriously defective.

• Investigating goals rather than tasks and procedures improves information gathering by focusing on the essence of requirements—the intent behind them.


Fig. 6.2 Primary actors and goals at different system boundaries.

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collect taxes on sales Sales Activity

System

Goal: Analyze sales and performance data


Naming Use Cases

• Appropriate use case names are very important. Because they are selected early, they tend to set the direction for the entire project. – Must be a complete process from the viewpoint of the end

user.

– Usually in verb-object form, like Buy Pizza

– Use enough detail to make it specific

– Use active voice, not passive

– From viewpoint of the actor, not the system

Golden Rule: Each use case should have a name that indicates what value (or goal) is achieved by the actor's interaction with the system.


Quick Test: Use Case Name Examples

• Purchase Concert Ticket

• Purchase Concert Tickets

• Purchase Ticket

• Ticket Purchase

• Ticket Order

• Pay for Ticket

Naming Use-Cases


Use Case Name Examples

• Excellent - Purchase Concert Ticket

• Very Good - Purchase Concert Tickets

• Good - Purchase Ticket (insufficient detail)

• Fair - Ticket Purchase (passive)

• Poor - Ticket Order (system view, not user)

• Unacceptable - Pay for Ticket (procedure, not process)

Naming Use-Cases


CRUD

• Examples of bad use case names with the acronym CRUD. (All are procedural and reveal nothing about the actor’s intentions.)– C - actor Creates data– R - actor Retrieves data– U - actor Updates data– D - actor Deletes data

• Collapse CRUD into one CRUD use case, idiomatically called Manage <X>.– Ex. Manage Users use case.

Naming Use-Cases


Singular or Plural

• This is usually determined by context.

• There is a preference for the simplest form, but most common form can be better.– In the example of concert tickets, most people buy

more than one, but a significant number buy only one.

– At a supermarket, Buy Items would be best.– At a vending machine, it would be Buy Item.

Naming Use-Cases


Use Case Template

• Name• Primary Actor• Scope• Level: user-goal or subfunction• Stakeholders and Interests• Preconditions• Success Guarantee

• Main Success Scenario• Extensions

• Special Requirements• Technology and Data Variations List• Frequency of Occurrence• Miscellaneous (such as open items)

This is the basic format used in the text and in Alistair Cockburn’s Writing Effective Use Cases (Addison Wesley, 2000, ISBN 0201702258).

See also www.usecases.org

Optional items

Preface

http://www.amazon.com/exec/obidos/tg/stores/detail/-/books/0201702258/reader/2/002-3439525-6842407


User-goal level A complete process from the view point of a user to meet a goal of the user, roughly corresponding to an elementary business process.

Subfunction levelDetails steps to support a user goal.


Define Actors

• Actors should not be analyzed or described in detail unless the application domain demands it.– Template for definition:

• Name• Definition

• Example for an ATM application: Customer: Owner of an account who manages account by depositing and withdrawing funds


Preconditions and Postconditions

• Preconditions are anything that must always be true before beginning a scenario is a precondition.– Preconditions are assumed to be true, not tested

within the Use Case itself.– Ignore obvious preconditions such as the power being

turned on. Only document items necessary to understand the Use Case.

• Success Guarantees (or Postconditions) state what must be true if the Use Case is completed successfully. This may include the main success scenario and some alternative paths. – For example, if the happy path is a cash sale, a credit

sale might also be regarded a success.– Stakeholders should agree on the guarantee.




Scenarios

• The Main Success Scenario, or “happy path” is the expected primary use of the system, without problems or exceptions.

• Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.


Documenting the Happy Path

• The Success Scenario (or basic course) gives the best understanding of the use case

• Each step contains the activities and inputs of the actor and the system response

• If there are three or more items, create a list• Label steps for configuration management and

requirements traceability• Use present tense and active voice• Remember that User Interface designers will use this

specification

Note: Do not use the term “happy path” in formal documents.






Extensions (Alternative Flows)

• Extensions or Alternative Flow Use Cases allow the specification of– Different ways of handling transactions– Error processes

• Sections are convenient way to handle alternative courses of action– Sections are a segment of a use case

executed out of sequence


Two Parts for Extensions

• Condition– Describe the reason for the alternative flow

as a condition that the user can detect

• Handling– Describe the flow of processing in the same

manner as the happy path, using a numbering system consistent with the original section.

3A. Condition: If [actor] performs [action] the system …


Documenting Extensions

• Use same format as Happy Path• Document actions that vary from ideal path• Include error conditions

• Number each alternate, and start with the condition:3A. Condition: If [actor] performs [action] the system …

• If subsequent steps are the same as the happy path, identify and label as (same)

• Steps not included in alternate course are assumed not to be performed.



Special Requirements

• If a non-functional requirement , quality attribute, or constraint affects a use case directly, describe it as a special requirement.


Technology and Data Variations List

• Often there are technical differences in how things are done even though what is done is the same. These things can be described in the Technology and Data Variations List.

– For example, if a card reader cannot read the magnetic stripe on a credit card, the cashier might be able to enter it on the keyboard.


Types of Use Cases

• High Level Use Case (Brief)– Name, Actors, Purpose, Overview

• Expanded Use Case (Fully Dressed)– Add System Events and System Responses

• Essential Use Case (Black Box)– Leave out technological implications– Ex. The system records the sale. (no mention of database

etc.)

• Concrete Use Case (White Box)– Specify technology


Guideline: Defer Decisions

• By using essential use cases as long as possible, and only using real use cases during module design, you allow time to understand the problem before you create a solution. Premature use of real use cases often confirms existing technology when a better technology might be available.

• Define the problem fully before you start to define a solution. Any work that you do on the problem domain tends to increase the range of possible solutions, while work in the solution domain limits your choices. – You want to be certain that the problem domain is large

enough to hold some good solutions and hopefully an ideal solution before you start to narrow your choices.


Contrasting Examples

• Essential Style:...1. Administrator identifies self.2. Systems authenticates identity.…

• Concrete Style:...1. Administrator enters ID and passsword in dialog box

(See Picture 3).2. System authenticates Administrator.3. System displays the “edit users” window. (See

Picture 4)...


Technology

• The distinction between an essential (black box) use case that leaves out technology and a real (white box) use case that includes technology is fundamental.

– For example, in an Automated Teller Machine, an essential use case can mention identification or validation, but only a real use case can mention a key pad or card reader.

Types of Use Cases


Expanded Essential Use Cases(Fully Dressed Use Cases)

• Purpose:– to allow the system designer and client to visualize the

flow of actor actions and system responses. From this the client will understand how users will use the system, and the designer will be able to write pseudocode for each function. In addition, it is possible to use this document to anticipate opportunities for user error, which must be accounted for in the final system.

• Definitions:– What it is: an analysis document which describes in detail

the elements of functions identified in a High Level Use Case.

– What is is not: Expanded Essential Use Cases are not graphical drawings. They do not include stick figures, boxes representing the system, or any other icons found in a High Level Use Case although they may be associated with one.

Types of Use Cases


Expanded EssentialUse Cases

• How to make one:– Step 1: Name the Use Case (system function, e.g. “enter

timesheet information”).– Step 2: Identify the Actor(s) involved.– Step 3: Describe the Intent of the Use Case in language

the client will understand.– Step 4: Identify the Assumptions and Limitations relevant

to this Use Case and other Use Cases which the current one might extend or build upon.

– Step 5: Specify the ideal flow of actions (using two columns, if you like) labeled “Actor Actions” and “System Responses.” Number each step. This constitutes the Happy Path for this Use Case.

– Step 6: Identify opportunities for user error and create an Alternative Path to handle each.

Types of Use Cases


Note (from page 68 of text)

• The example on pages 68-72 of the text of a fully dressed use case is very detailed and contains just about everything you could put into a use case. It is that detailed mainly for instructional purposes.

• Almost all use cases are much smaller, usually a page or two.

Types of Use Cases


Segmentation

• When a use case is repeated, you don’t want to repeat the contents.– For example, an alarm clock might show the same

display when you are setting the current time and when you are setting the wake-up time

– Separate out the “Display Time” use case and refer to it in both use cases


Extension Use Cases

• Users appreciate simplicity, so most use cases leave out alternate courses

• You can do this by extending the use case while leaving the original use case alone


Warning

• Use cases should not be misused to imitate function specification by successive iteration

• Don’t refine them until the program is fully specified

• The uses relation should only be used when the same scenario is encountered more than once


Use Cases are always wrong!

• Written documentation gives the illusion of authority and correctness, but it is an illusion.

• Use cases give a preliminary understanding that users and developers can discuss and agree on.

• But there should be constant feedback from customers in the development process to correct missing information and misinformation before it jeopardizes the functionality of the program.


Fig. 6.3 Partial use case context diagram

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns


NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Fig. 6.4 Notation suggestions AND Alternate actor notation

Payment

Authorization

Service

OR


Fig. 6.6 Use case diagram (“context diagram”) for Monopoly system.


Use Case UC1: Play Monopoly GameScope : Monopoly applicationLevel : user goalPrimary actor : ObserverStakeholder and Interests:

Observer: wants to easily observe the output of the game simulation.

Main Success Scenario:1. Observer requests new game initialization, enters number of players.2. Observer starts play.

3. System displays game trace for next player moveRepeat Step 3 until a winner or Observer cancels.

Extensions:*a. At any time, System fails:

1. Observer restarts System.2. System detects prior failure, reconstructs state, and prompts to continue.3. Observer chooses to continue.

Special Requirements:Provide both graphical and text trace modes.


January February

Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

WhenOnce during inception. Short; do not try to define or polish all requirements.

Several times during elaboration iterations.

WhereAt a requirements workshop.

WhoMany, including end users and developers, will play the role of requirements specifier, helping to write use cases.

Led by system analyst who is responsible for requirements definition.

How: ToolsSoftware: For use case text, use a web-enabled requirements tool

that integrates with a popular word processor.For use case diagrams, a UML CASE tool.Hyperlink the use cases; present them on the project website.

Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows .

Developer

CustomerSystemAnalyst

End User

Two adjacent projections.

SoftwareArchitect

Fig. 6.7 Process and setting context for

writing use cases.


Association Relationship

• An association is the communication path between an actor and the use case that it participates in– It is shown as a solid line– It does not have an

arrow, and is normally read from left to right

– Here, the association is between a Modeler and the Create Model use case


Relationships in Use Cases

• There are several Use Case relationships:– Association– Extend– Generalization– Uses– Include

Most Use Cases have only associations. Use other relationships sparingly.


Extend Relationship

• Extend puts additional behavior in a use case that does not know about it.

• It is shown as a dotted line with an arrow point and labeled <<extend>>

• In this case, a customer can request a catalog when placing an order.


Uses Relationship

• When a use case uses another process, the relationship can be shown with the uses relationship

• This is shown as a solid line with a closed arrow point and the <<uses>> keyword

• Here different system processes can use the logon use case


Include Relationship

• Include relationships insert additional behavior into a base use case.

• They are shown as a dotted line with an open arrow and the key word <<include>>

• Shown is a process that I observed in an earlier career.


Use Case Example: Alarm Clock

This is a contrivedexample, to showmany relations.Your diagrams

should be simpler.

Chapter 7OTHER REQUIREMENTS

Objectives•Show Supplementary Specification, Glossary, Vision & Business Rules•Compare and contrast system features with use cases•Define quality attributes

“Fast, Cheap, Good: Choose any two.” - anonymous


Introduction

• While the primary requirements of a computer system tend to be the functional requirements,– i.e.,the list of activities that the system must perform,

• it is also necessary to capture an number of other requirements to build a system, called non-functional requirements.– in a Vision Statement, Glossary, Business (Domain)

Rules and Supplementary Specification.

Produce only the required (or enough) documentation to produce the desired results efficiently and effectively.

• Documentation costs money and takes time.


Other Requirement Artifacts

• Supplementary Specification– Captures and identifies other kinds of attributes, such

as reports, documentation, packaging, supportability, licensing, and so forth.

• Glossary– Captures terms and definitions; it can also play the

role of a data dictionary.

• Vision– Summarizes the `vision` of the project – an executive

summary.

• Business Rules (or Domain Rules)– Capture long-living and spanning rules or policies,

such as tax laws, that transcend one particular application.


Vision

• When someone joins the project, it is useful to be able to say :– “Welcome! Please go read the 7-page Vision at the

project web site.”

• It is also useful to have an executive summary that briefly describes the project, as a context for the major players to establish a common vision of the project.


The Vision

• The Vision serves to communicate to project sponsors and key stakeholders – the reasons for the project, – the problems to be solved, – a description of the stakeholders and their needs, – Root problems and goals,– along with a description of the proposed solution.

• It includes the core requirements and becomes the contractual basis to develop further requirements.


Topics for a Vision

• Introduction• Positioning

– Business Opportunity– Problem Statement– Product Position– Alternatives and

Competition• Stakeholder Descriptions

– Market Demographics– Non-user Interests– User Interests– Key high-level goals and

problems for stakeholders

– User-Level Goals– User Environment

• Product Overview– Product Perspective– Summary of Benefits– Assumptions and

Dependencies– Cost and Pricing– Licensing and

Installation

• System Features• Other requirements and

constraints

See Section 7.6 NexGen Example


Why system features in Vision?

• Use cases are not the only way to describe functional requirements.

• Sometimes a succinct list of key functional requirements, called system features, will give a better immediate grasp of the problem and proposed solution.– A system feature is an externally observable service

provided by the system which directly fulfills a stakeholder need.

– Features are behavioral functions a system can do. They should pass the linguistic test:

• The system does <feature X>.





Glossary

• The Glossary captures terms and their definitions in the business domain supported by the system.

– Be careful. Even simple terms may mean different things to different stakeholders and need to be defined.

• The Glossary can also perform the role of a Data Dictionary, or be supplemented by one.– Data Dictionary records data about the data, that is

metadata.• Aliases - relationships to other

elements• Description - range of values• Format (type, length, unit) - validation rules




Supplementary Specification

• The Supplementary Specification captures such requirements as documentation, supportability, packaging, licensing and many of the “-ilities” of systems.


Supplementary Specifications

• Common Functionality– Logging– Error Handling– Pluggable Business

Rules– Security

• Usability– Human factors

• Reliability– Recoverability– Performance

• Supportability– Adaptability– Configurability

• Implementation Constraints

• Purchased Components• Free Open Source

Components• Interfaces

– Noteworthy hw and interfaces

– Software interfaces

• Application-specific Domain Rules

• Legal Issues• Info in Domains of Interest

– Pricing– Credit and Debit Payment

Handling– Sales Tax– Item Identifiers



More Specifications

• Reports• Operating Systems• Networking Systems

• Process Tools• Development Tools• Design Constraints• Internationalization• Standards• Physical Environment• Operation Rules





Domain Rules

• Domain or Business Rules are not functional requirements. – Domain Rules tell how the business works, while

functional requirements tell how the system works. – Company policies, the laws of physics, and

government regulations are examples of Domain Rules.


Industry Domains

• Most computer consulting firms organize their staff by industry, so that they can develop application specific knowledge that will be useful to the companies hiring them.

– In New Jersey, most consulting companies have at least a Telecommunications Practice and a Pharmaceutical Practice.

– Other areas might include Retail, Insurance, Wholesaling, Light Manufacturing, and Electric Utilities.


Knowledge Domains

• In addition to Industry specific knowledge, there are many areas of knowledge that apply across a number of industries.

– The most thoroughly specified of these knowledge domains is accounting.

– Others might include inventory, scheduling, and queuing.

– Each has a body of specific knowledge that specialists know well.


Guidelines

• Should we analyze these thoroughly during inception?

• Reliable Specifications: An Oxymoron?

• Should these artifacts be at the project web site?


Requirements Reliability

• Never assume that requirements are completely understood, adequately captured, effectively described, or reasonably complete.

• Requirements discovery and scope creep tend to occur throughout the software development process and even after the system is put into production.


UML Diagrams in Inception

• Aside from the possible inclusion of a few high level use case diagrams, the inception phase is almost all text.

• Most diagramming occurs in the Elaboration Phase.


Process: Evolutionary Requirements in Iterative Methods

Discipline Artifact Inception Elaboration Construction TransitionIteration-> I1 E1…En C1…Cn T1..T2

Business Modeling

Domain Model

s r

Requirements

Use-Case Model

s r

Vision s rSupplementaty Specification

s r

Glossary s rBusiness Rules

s r

Design Design Model

s r

Sw Arch Model

s

Data Model s r

Documents

Chapter 6 USE CASES Objectives Identify and write use cases Use the brief, casual and fully dressed formats Apply tests to identify suitable use cases