Effective Use Cases

Use Cases

  • A Use Case is a particular way of using the system.

    • A sequence of interactions between the system and one or more actors.

  • They are represented by UML Interaction diagrams (also called scenarios in domain analysis).

  • A Use Case is a text: writing good Use Cases is a question of style.

The System as a Set of Services

The compilation of all Use Cases describes informally the services provides by the System.
  • They provide a description of the functional requirements.

  • They can drive the progression of an iterative development model.

Identifying Use Cases

  • Use Cases are complex operations.

  • They are described by several scenarios.

  • Typically CRUDS are bad choices: simple operations, realized by the same actor to reach a single goal within the same security level.

crud

Avoid CRUD Synonyms

  • Differentiate Use Case from Operations.

  • An Use Case is a set of Operations.

  • An operation can be seen as an instance of an Use Case (Class/Object analogy).

crud2

Use Cases should be named using the domain terminology

crud3

Informal Descriptions

  • Use Cases are essentially text.

  • They can follow different templates:

    • Rational Unified Process.

    • Cockburn.

Use Case Template (Cockburn)

ItemDescription

Use Case

"# - the name should be the goal as a short active verb phrase"

Goal in Context

a longer statement of the goal, if needed

Scope

what system is being considered black-box under design

Level

one of: Summary, Primary task, Subfunction

Success End Condition

Failed End Condition

Primary Actor

a role name for the primary actor, or description

Trigger

Priority

how critical to the system / organization

Frequency

how often it is expected to happen

Pre-conditions

Post-conditions

Main success scenario

  1. Description of Initial Action

  2. Description of Action 2

  3. (…)

  4. Description of Last Action"

Extensions

  1. <#> : <condition> : <action or use-case>

  2. <#> : <condition> : <action or use-case>"

Variations

  1. <#> : <action or use-case>

  2. <#> : <action or use-case>

Superordinate Use Case

optional, name of use case that includes this one

Subordinate Use Cases

optional, depending on tools, links to sub.use cases

Performance Target

the amount of time this use case should take

Open Issues

Schedule

Constraints

Annexes

Template Example

#

5

Use Case

Buy Goods

Goal in Context

Buyer issues request directly to our company, expects goods shipped and to be billed.

Scope

Company

Level

Summary

Success End Condition

Buyer has goods, we have money for the goods.

Failed End Condition

We have not sent the goods, Buyer has not spent the money.

Primary Actor

Buyer, any agent (or computer) acting for the customer.

Trigger

Purchase request comes in.

Priority

top

Frequency

"200/day"

Pre-conditions

We know Buyer, his address, etc.

Post-conditions

Main Success Scenario

  1. Buyer calls in with a purchase request.

  2. Company captures buyer’s name, address, requested goods, etc.

  3. Company gives buyer information on goods, prices, delivery dates, etc.

  4. Buyer signs for order.

  5. Company creates order, ships order to buyer.

  6. Company ships invoice to buyer.

  7. Buyers pays invoice."

Extensions

  • 3a. Company is out of one of the ordered items:

  • 3a1. Renegotiate order.

  • 4a. Buyer pays directly with credit card:

  • 4a1. Take payment by credit card (use case 44)

  • 7a. Buyer returns goods:

  • 7a. Handle returned goods (use case 105)"

Variations

  1. Buyer may use phone in, fax in, use web order form, electronic interchange

  2. Buyer may pay by cash or money order check"

Superordinate Use Case

Manage customer relationship (use case 2)

Subordinate Use Cases

  • Create order (use case 15)

  • Take payment by credit card (use case 44)

  • Handle returned goods (use case 105)"

Performance Target

5 minutes for order, 45 days until paid.

Channel to primary actor

May be phone, file or interactive.

Secondary Actors

Credit card company, bank, shipping service

Open Issues

  • What happens if we have part of the order?

  • What happens if credit card is stolen?"

Schedule Due Date:

release 1.0

Constraints

Annexes

Conclusion

Use Cases and User Interface Modeling

Use Cases and User Interfaces (UI) should be different, independent things.
  • Use storyboards (or other techniques) to model UI.

  • Avoid UI related actions. For instance: “The user chooses in the List Box and clicks on the Validate button.

Iterate

  • Good Use Cases need several iterations.

    • It is virtually impossible to write a complete Use Case at once.

    • Use first versions as a base for discussions and improvements. Compare models.

    • Use Cases and Conceptual Classes should evolve together.

  • Stop before reaching perfection.

    • Aim quality targets: costs, deadlines, etc.

Cockburn’s Writing Reminders

  1. Start from the top and create a coherent story line.

  2. Name the use cases with short verb phrases that announce the goal to be achieved.

  3. Focus on the main scenario.

  4. Be concise yet pertinent (avoid long documents).

  5. Write full sentences with active verb phrases, in the present tense.

  1. Make sure the actor is visible in each step.

  2. Put alternative behaviors in the extensions, rather than in if statements in the main body.

  3. Identify the correct goal.

  4. Include sub use cases, use UML «include» relationships to represent them.

  5. Start from the trigger, continue until the goal is delivered or abandoned.

  6. Keep the GUI out.