Emerging Tech optimize

Help your analysis team draft an actionable detailed use case

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.

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.

Since writing use cases is itself a business process, we might write a detail use case to describe it. Indeed, the bulk of this document (Table A) 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.

This blog post is also available in PDF form in a TechRepublic download.

Other TechRepublic blog entries from Joe Goss discussing use cases include:

Table A

<Project Name Here>

Analysis Team drafts a use case (<unique ID>)

Use Case Name Analysis Team

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

Primary Actor: 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?

  1. Clearly define the functional requirements of a business process.
  2. Describe the context of a business process.
  3. Supplement the project glossary with new terminology and definitions.
  4. Identify and catalog unresolved issues.
  5. 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

physical location)?

Business Analyst

("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?

  1. Software Developers want to understand the business and its processes.
  2. Testers want to determine if software matches functional requirements.
  3. Project sponsors want a well-defined, cost-effective, and appropriate solution to a business problem.
  4. 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.

  1. A collaborative, energetic, and forward-looking environment exists for improving business processes.
  2. Customer management authorized several Subject Matter Experts ("SME") to participate as members of the AT.
  3. SMEs have adequate time to contribute to the analysis effort.
  4. The BA or the AT has defined a standard format in which the use cases will be written.
  5. 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.

  1. Project Sponsor suggested SME candidates for membership in the AT.
  2. Project scope has been stated (as through a project charter).
  3. BA organized one or more meetings for the AT.
  4. A high-level use case was written about the business process being studied.

Action Post-Conditions:What

workflow-related conditions must be true after the successful action? Example:

Driver is ready to engage transmission.

  1. BA schedules additional AT meetings as needed.
  2. AT completes the use case document.
  3. SMEs inside and/or outside the AT review and revise the use case.
  4. BA makes appropriate adjustments to the use case.
  5. BA ensures the use case format and content match standards.
  6. BA stores the use case in a repository with the other use case documents.
  7. 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.

  1. 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.

  1. AT develops a use case that adequately and accurately reflects the core steps

    and central attributes of an "as is" or "to be" business

    process.
  2. BA creates or revises the project glossary.3. BA creates or revises the use case catalog.

Triggers:What causes the

actor to take action?

  1. 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

step.

  1. AT members meet to develop a use case.
  2. BA facilitates group discussion.
  3. 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

g. Triggers

h. Assumptions

i. Action Pre-conditions

j. Action Post-conditions

k. Scope

l. Open Issuesm. Remaining sections

  1. BA encourages AT members to think comprehensively as they describe the process and its attributes.
  2. As AT members identify new terms, the BA records each term and a corresponding definition.
  3. As AT members identify issues, the BA records each one and gets group confirmation that the wording is correct.
  4. 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.
  5. 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.
  6. 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.
  7. AT members submit responses to BA. The "track

    changes" feature indicates each member's suggestions for additions and

    changes.
  8. BA merges suggested changes into a single document.
  9. 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.

  1. 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.

  1. 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.

  1. 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",

step 7

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.

  1. 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.

Some adjustments

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.

Developing a

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?

Project manager

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?

  1. BA organizes the AT and guides members' effort.
  2. 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.

  1. 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

terms.

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

communication.

  1. BA adds new terms and corresponding definitions to the project glossary.
  2. BA denotes references to external documents such as other use cases or the project glossary.
  3. BA excludes computer user interface details from the use case.
  4. BA ensures the use case completes at least one positive outcome (and perhaps a negative outcome as well).
  5. BA encourages AT members to write a "just good enough" use case.
  6. BA maintains a log of revisions to the document in the "Revised on and by" section.
  7. 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.
  8. 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).
  9. When writing a

    set of use cases, BA strives for breadth first and then depth. Too many

    details too early sap creativity and energy.
  10. 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?

  1. What steps are missing in the Main Course?
  2. What business rules are missing from that section?

Owner:Who has

management responsibility for this action? Example: Car owner

BA

1 comments
jgoss
jgoss

The numbering and formatting in this post is somewhat painful to read. I apologize to the reader. The PDF file is easier on the eyes. It is available from link located just after the third paragraph. Joe