© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Use Cases Descriptions and Use Case Models

1© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley

Use Cases Use Cases Descriptions and Use Descriptions and Use Case ModelsCase Models


ObjectivesObjectives

To explain what use case descriptions are To specify the contents of use case descriptions To present a use case description writing

process To present heuristics for use case descriptions To explain the relationship between use cases

and requirements To explain what use case models are To explain how to design with use case models To outline how to use use cases in iterative

development


TopicsTopics

Use case descriptions, their formats, and their contents

Writing use case descriptions Use case description heuristics Use case descriptions and

requirements Use case models Designing with use case models Use-case-driven iterative development


Use Case DescriptionsUse Case Descriptions

A use case description is a specification of the interaction

between a product and the actors in a use case.

A use case description is a specification of the interaction

between a product and the actors in a use case.

What each party does The order in which each party acts All possible courses of interaction:

complex activity flows


Use Case Description Use Case Description Contents 1Contents 1

Use case name and number Actors Stakeholders and their needs Preconditions—A precondition is an assertion

that must be true when an activity or operation begins.

• Not checked by the use case

Postconditions—A postcondition is an assertion of what must be true when an activity or operation ends.

• Must satisfy stakeholder needs


Use Case Description Use Case Description Contents 2Contents 2

Trigger—A trigger is an event that causes a use case to begin.

• May be the first step in the use case

Basic flow• An action flow: a list of steps

• Documents a standard, successful interaction

• Begins at the trigger, continues until the use case ends

Extensions• Alternative action flows

• May begin and end anywhere

• Extensions may have extensions


Car Wash Example – Car Wash Example – Part 1Part 1

Use Case 2: Activate/DeactivateActors: Soap sensorStakeholders and needs:

Customers—Need their cars washed with soap, and

want a complete washOperations—Want the carwash to operate

without constant attentionPreconditions: NonePostconditions:

The carwash is active if and only if the soap sensor indicates that there is soap.

No wash currently in progress is interrupted.



Trigger: One minute has passed since the last time the soap sensor was checked.

Basic Flow:1. The carwash queries the soap sensor.2. The soap sensor indicates that there is soap.3. If the carwash is active, it continues its

operation and the use case ends.Extensions:1a: The carwash is unable to query the soap

sensor:1a1. The controller logs the problem and the use case ends.



Extensions (continued):2a: The soap sensor indicates that there is no more soap:

2a1. If the carwash is inactive, the use case ends.2a2. If the carwash is active, the controller displays an

out-of- order message and becomes inactive; the use case ends.2b: The soap sensor does not respond:

2b1. The controller logs the problem.2b2. If the carwash is inactive, the use case ends.2b3. If the carwash is active, the controller displays an

out-of- order message and becomes inactive; the use case ends.2a2, 2b3: A wash is in progress:

2a21. The carwash completes the current wash, then displays an out-of-order message; the use case ends.3a: The carwash is inactive:

3a1. The carwash becomes active and displays a ready message.


Use Case Description Use Case Description FormatsFormats

Many alternatives “Fully-dressed” format Underlined text refers to another use case. Extensions use a special numbering

scheme:• Numbers are for action step sequencing;• Letters are for extension triggers;• Extension identifiers have interleaved numbers

and letters;• An asterisk refers to all action steps;• A dash is used for ranges of action steps;• A comma separates action steps in a list.


Use Case Description Use Case Description TemplateTemplate

Use Case number: nameActors: actorListStakeholders and Needs:

stakeholder—needsList.…stakeholder—needsList.

Preconditions: what is assumed at the start.Postconditions: what is guaranteed at the end.Trigger: the event that starts the use case.Basic Flow:

# stepDescription…

Extensions:extensionIdentifier condition: extensionIdentifier # stepDescription …

…


Description Writing Description Writing ProcessProcess

Fill in the Initial Fields

Write Extensions

Write a Use Case Descriptiondiagram : Use Case Diagramgoals : Stakeholders-Goals Listneeds : Needs Listscenarios : Collection of Scenariosdescription : Use Case Description

Write Basic Flow

Brainstorm Branch Points and Conditions

Rationalize Branch Points and Conditions

goals

diagram

needs

description

scenarios


Filling in the Initial Filling in the Initial FieldsFields

Stakeholders are human use case actors or anyone with an interest to protect.

Only state things that really matter as use case preconditions.

Postconditions must be true when the use case ends whether it is successful or not.

The trigger is often the first step in the use case (but not always).


Writing the Basic Flow Writing the Basic Flow 11

Choose a common, simple activity flow.

Trace it from the trigger through use case completion.

Scenarios are often good resources.


Writing the Basic Flow Writing the Basic Flow 22

Steps may assume the preconditions and should achieve the postconditions.

Each step should state an action of a single agent (the product or an actor).

Supplemental directions about conditions, iteration, or currency are allowed.


Brainstorming Branch Brainstorming Branch PointsPoints

A branch point is a place where the action flow may diverge.

Brainstorm a list of branch points and failure conditions.

• Look at scenarios for failed or alternative interactions.

• Consider errors, faults, and alternatives at every step.

• Don’t forget an actor’s failure to act.


Rationalizing Branch Rationalizing Branch PointsPoints

Remove from further considerations any conditions that the product

• Cannot detect• Cannot do anything about

Rewrite poorly stated conditions


Writing ExtensionsWriting Extensions

Treat an extension as if it were a separate use case:

• The condition is the trigger;• Extension steps are the basic flow;• Completing the use case or returning to

the branch point are the goals. Scenarios are a good resource. Repeat the extension writing process

for the extension (extensions may have extensions).


Use Case Description Use Case Description Heuristics 1Heuristics 1

Fill in the use case template from top to bottom.

Obtain use case and actor names from the use case diagram.

Make human actors stakeholders whose needs include completion of the task done by the use case.

Write simple declarative sentences in the active voice.


Use Case Description Use Case Description Heuristics 2Heuristics 2

Make actors or the the product the subject of each step description.

Write a basic flow with three to nine steps.

Avoid sequences of steps by actors or the product.

Don’t specify physical details. Impose minimal order on activities. Proofread the description.


Use Case ModelsUse Case Models

The diagram is a static model cataloging product interactions.

The descriptions are dynamic models detailing the interactions.

A use case model is a use case diagram together with use case

descriptions for each use case in the diagram.

A use case model is a use case diagram together with use case

descriptions for each use case in the diagram.


Designing with Use Case Designing with Use Case DiagramsDiagrams

Models a design alternative for the interactions that a product will support

Generate several design alternatives Alternative can be evaluated in terms

of• Unmet needs• Extraneous features or capabilities• Development costs• Time and risk• Conformance to constraints• Feasibility, simplicity, beauty


Designing with Use Case Designing with Use Case DescriptionsDescriptions

Use case descriptions refine the user-level specification in a use case diagram into operational-level specifications.

Design alternatives are specified in different descriptions.

Alternatives can be evaluated as already described.


Requirements and Requirements and Use Case ModelsUse Case Models

Use case models do not provide atomized requirements statements.

• They are not traceable;• Some product functions may not appear;• Data and non-functional requirements are

not explicit. Use case models sometime serve as

surrogates for requirements.


Extracting Extracting RequirementsRequirements

Extracting requirements from use case models

• Helps designers understand their designs better;

• Helps find errors and improve designs;• Produces a useful artifact for engineering

design. Additional requirements are also

needed.• Data and non-functional requirements• Physical-level requirements


Use-Case-Driven Use-Case-Driven Iterative DevelopmentIterative Development

In an iterative development project• Choose several use cases for

implementation in an iteration;• Furnish product design details;• Do engineering design, code, test, and

(perhaps) deploy;• Evaluate the result for the next iteration;• Repeat these steps.


Process GuidelinesProcess Guidelines

Start with a complete use case diagram.

Choose use cases for each iteration according the the following criteria:

• Important to stakeholders• Requires a core system function• Requires the essentials of the system

architecture• The implementation is technically

challenging


SummarySummary

A use cases description is structured text that specifies the details of a use case.

Templates, processes, and heuristics guide use case description writers.

Use case descriptions, though not requirements, can be a source for them.

Use case diagrams and descriptions together form use case models.

These models are a powerful product design tool.

Use cases can drive iterative development.