How to write good use cases

Check references:

• Use Case Modeling by Kurt Bittner and Ian Spence
• Writing Effective Use Cases by Alistair Cockburn

System Use Cases: An Agile Introduction

Taken from: System Use Cases: An Agile Introduction

• “My advice is to keep your models as simple as possible and only document them this thoroughly if it adds actual value.”
• ”. Because your use cases refer to user interface components, and because your user interface is worked on during design, inevitably design issues will creep into your use cases.”
• “Because your user interface will work differently depending on the implementation technology, the logic of your system use cases, which reflect the flow of your user interface, will also be affected.”

Template

Metadata:

• Name

• Identifier

• Actors

• Description

• Preconditions: only when it applies and is not obvious

• Postconditions: only when it applies and is not obvious

• Basic flow

  • Enumerate the steps
  • Links to Alternative flows
  • Links to Extension Use cases: only when it applies
  • Links to Business rules: only when it applies
  • Use case steps are written in the active voice

• Alternative flow

  • Enumerate steps

• Describe actions in terms of “The system …” and “The actor …”

• Writing in the active voice results in concise sentences

• End the basic course of action within a use case with a closing statement. “The use case ends”, “The use case ends when …”

Identifying Use Cases

Identify potential services by asking your stakeholders the following questions from the point of view of the actors:

• What are users in this role trying to accomplish?
• To fulfill this role, what do users need to be able to do?
• What are the main tasks of users in this role?
• What information do users in this role need to examine, create, or change?
• What do users in this role need to be informed of by the system?
• What do users in this role need to inform the system about?

Remaining Agile

• You need to focus on creating artifacts that are just barely good enough, they do not to be perfect.
• Remember AM’s Maximize Stakeholder Investment principle and only do things that add value.

Applying Use Cases: A Practical Guide

Identifying System Boundaries

Identify the boundaries of the system. Finding out what things are inside your system (what we should create) and what are outside your system (what we shouldn’t create, but you have to interact with them).

Identifying actors

• Actors are anything that interfaces with your system: people, other software, hardware devices, data stores, or nerworks.
• Each actor defines a particular role.
• Each entity outside your system may be represented by one or more actors.
• Actors are always external to your system. They are never a part of your system.
• Useful questions to find actors:
  • Who uses the system?
  • Who installs the system?
  • Who starts up the system?
  • Who maintains the system?
  • Who shuts down the system?
  • What other systems use this system?
  • Who gets information form this system?
  • Who provides information to the system?
  • Does anything happen automatically at a preset time?

Identifying use cases

• A use case is a behavior of the system that produces a measurable result of value to an actor.
• Use cases describe the things actors want the system to do.
• A use case should be a complete task from the actor’s perspective.
• Consider startup, shutdown, diagnostics, installation, training, and changing a business process.
• Useful questions:
  • What functions will the actor want from the system?
  • Does the system store information? What actors will create, read, update, or delete that information?
  • Does the system need to notify an actor about changes in its internal state?
  • Are there any external events that the system must know about? What actors informs the system about events?