An analysis team writes detailed use cases to describe the steps and characteristics of business processes. While use cases are often a central feature of a software requirements specification, business analysts often employ use cases in a broader context. In fact, I've used them to describe the steps and attributes of project management processes.
Was my analysis team writing a software system to automate aspects of project management? No, not at all. However, we were attempting to document our local project management practice standards. With some adaptation of a typical use case template, the idea worked pretty well.
is itself a business process, we might write a detail use case to describe it. Indeed, the bulk of this document (
) is a use case example that describes the steps and characteristics of writing a use case. Perhaps you can adapt this example to capture your project's process requirements — whether for a software project or for a process improvement endeavor.
|Use Case Name
drafts a use case
|Revised on and by:
- 04/20/07 Analysis Team drafted
- 04/22/07 Analysis Team developed Business Rules
- section04/27/07 Business Analyst – clarified language
- based upon Analysis Team recommendations
||Analysis Team ("AT")
|Actor's Goals in Scope's Context:What is the actor
trying to accomplish within the action described by this use case?
- Clearly define the functional requirements of a business process.
- Describe the context of a business process.
- Supplement the project glossary with new terminology and definitions.
- Identify and catalog unresolved issues.
- Support collaboration and effective communication among Analysis Team members.
|Scope:In what part of
the organization or environment is the action done (e.g. department name or
("BA") facilitating the AT through a series of face-to-face
meetings or through electronic means.
|Stakeholders and Their Interests:Who benefits and
how within the context of this use case? How do the stakeholders benefit from
the specific action described by this use case?
- Software Developers want to understand the business and its processes.
- Testers want to determine if software matches functional requirements.
- Project sponsors want a well-defined, cost-effective, and appropriate solution to a
- BA wants to define clear and accurate business requirements.
|Assumptions:What must be true
in order for the action to be possible? Example: Driver has ignition keys in
order to start car engine.
- A collaborative, energetic, and forward-looking environment exists for
improving business processes.
- Customer management authorized several Subject Matter Experts ("SME") to
participate as members of the AT.
- SMEs have adequate time to contribute to the analysis effort.
- The BA or the AT has defined a standard format in which the use cases will be
- A secure and accessible repository exists for storing use case documents.
|Action Preconditions: What workflow-related conditions must be
true for the action to begin? Example: Driver is seated in car in order to
start the car engine.
- Project Sponsor suggested SME candidates for membership in the AT.
- Project scope has been stated (as through a project charter).
- BA organized one or more meetings for the AT.
- A high-level use case was written about the business process being studied.
workflow-related conditions must be true after the successful action? Example:
Driver is ready to engage transmission.
- BA schedules additional AT meetings as needed.
- AT completes the use case document.
- SMEs inside and/or outside the AT review and revise the use case.
- BA makes appropriate adjustments to the use case.
- BA ensures the use case format and content match standards.
- BA stores the use case in a repository with the other use case documents.
- BA creates or updates a use case catalog to include the drafted use case title.
The use case catalog contains a list of use case titles, each with a status
and unique identifier.
|Minimum Guarantees that the System
Ensures:If the actor
cannot complete the action, what does the system minimally guarantee? Example:
Driver knows whether or not the car started.
- The AT meets and discusses the summary-level use case.
|Success Guarantees that the System
Ensures:If the actor is
successful, what goals will be achieved? Example: Car started.
- AT develops a use case that adequately and accurately reflects the core steps
and central attributes of an "as is" or "to be" business
- BA creates or revises the project glossary.3. BA creates or revises the use case catalog.
|Triggers:What causes the
actor to take action?
- BA or AT identifies a high-level use case that should be developed into a detail-level use case.
|Main Course of Events: What are the
best-case steps the actor takes to accomplish his or her goals? Number each
- AT members meet to develop a use case.
- BA facilitates group discussion.
- AT members write the first draft of the core sections of the use case. The BA
uses a medium for recording narrative that all team members may view in
common, such as flip chart paper, overhead projection, or projected
electronic display. The AT interactively drafts these attributes, generally
in the following order:
a. Primary Actor
b. Main Course of Events
c. Actor's Goals in Scope's Context
d. Alternative Paths
e. Exception Paths
f. Stakeholders and Their Interests
i. Action Pre-conditions
j. Action Post-conditions
l. Open Issuesm. Remaining sections
- BA encourages AT members to think comprehensively as they describe the process
and its attributes.
- As AT members identify new terms, the BA records each term and a corresponding
- As AT members identify issues, the BA records each one and gets group confirmation
that the wording is correct.
- AT members review the written text and offer suggestions for improvement to the
BA, repeating steps 3 – 7 until the group feels the narrative is acceptable
as a first draft.
- After the meeting, BA transfers hand-written narrative to the standardized
electronic use case document. BA stores new terminology in a project glossary
document. BA enables the documents' "track changes" feature.
- BA electronically distributes the use case draft and project glossary to AT
members, and solicits suggestions for improvement in the documents. BA sets
an acceptable deadline for AT response.
- AT members submit responses to BA. The "track
changes" feature indicates each member's suggestions for additions and
- BA merges suggested changes into a single
- If available, the BA publishes the use
case in a repository available to AT members.
|Alternative Paths:What are the
uncommon or alternate paths that may occur instead of the each step in the Main
Course of Events? Please number each alternate path to link it to a step in
the Main Course of Events.
- AT members determine that the use case overlaps another one and merges the two documents together. AT members proceed with "Main Course", step 3 for the merged use case.
- AT members determine that the use case is a duplicate and decide to drop it.
a. BA updates the use case catalog to
indicate the use case was discarded.
b. The "Main Course" ends.
- AT discovers a new use case
a. BA adds it to the use case catalog and
notes that it needs to be written.
b. AT continues with "Main Course",
|Exception Paths:If a step of the
main course of action fails, what step does the actor take instead? Please
number each exception path to link it to a step in the Main Course of Events.
- AT determines the use case exceeds the scope of the project and drops the use case.
a. BA updates the use case catalog and
indicates its status is "out of scope".
b. "Main Course" ends.
|Technology and Data Variations List:Include the possible
variations in input or control features related to the Main Course steps of
the Exception paths. Example: Driver has the wrong ignition key.
to the use case catalog may occur. New use cases may be discovered. A use
case may merge with another, or be split in two. AT members may determine
that some use cases fall outside the scope of the project. BA tracks these
changes in the use case catalog.
|Response Time:What does the
actor expect in response time when taking action? Example: Driver expects car
to start in a few seconds.
draft use case may require several group meetings, each followed by an
opportunity for AT members to consider revisions and improvements. It is rare
to complete a use case in a single meeting. Review and revision of a draft
use case over several days often contributes to the best outcome. To reduce
the calendar time to develop use cases, the BA may group the use cases and
ask AT members to revise the whole set. The BA may also form subgroups of AT
members and have each team develop a subset of the use cases.
|Frequency of Use:How often will
the Actor take this action?
|A use case is
most valuable during the discovery or early design phase of a project. The
number and extent of use cases varies directly with the size and scope of the
project. A small software project will typically have 10 to 20 use cases.
|Communication Channel to Primary Actor: How does the
actor learn action needs to be taken?
or BA provides the project charter and background materials to AT members.
|Secondary Actors and Communications to
Them:Who does the
actor communicate with and how?
- BA organizes the AT and guides members'
- An SME may be contacted by an AT member
for clarification or confirmation of details about the use case.
|Business Rules:What business
rules must be enforced regarding this action? Example: Driver must have the
proper ignition key.
- BA formats the use case to:
a. Match local or project-specific standards
for format and content.
b. Contain simple
sentences; the standard
sentence structure uses a subject, verb, and object format.
c. Contain active verbs in the present tense (e.g., "BA
facilitates discussion" instead of "BA is using facilitation
techniques to lead the AT").
d. Contain capitalized terms that designate
an actor or significant entity.
e. Contain abbreviations for commonly used
f. Tell a detailed story from the point of view of an
interested and objective third-party.
g. Be easy to read and understand.
h. Encourage open and collaborative
- BA adds new terms and corresponding
definitions to the project glossary.
- BA denotes references to external
documents such as other use cases or the project glossary.
- BA excludes computer user interface details from
the use case.
- BA ensures the use case completes at least one
positive outcome (and perhaps a negative outcome as well).
- BA encourages AT members to write a "just
good enough" use case.
- BA maintains a log of revisions to the
document in the "Revised on and by" section.
- BA reduces redundant steps in use cases by
separating common "Main Course" steps into a distinct use case
(e.g., writing the redundant steps of logging into a system as a separate use
case called "User logs into system"). The summarized step simply
refers to the separate, fully detailed use case.
- To simplify communication about the use
case, BA assigns the use case a meaningful and unique ID (e.g., AP1 for "accounts
payable" use case #1).
- When writing a
set of use cases, BA strives for breadth first and then depth. Too many
details too early sap creativity and energy.
- BA consolidates
Open Issues from all use cases into a single document for AT members'
consideration and resolution.
|Open Issues: What are the
unresolved issues related to this use case?
- What steps are missing in the Main Course?
- What business rules are missing from that
management responsibility for this action? Example: Car owner