The Use Case Approach 

| By TMA World

Use cases have grown steadily in popularity among business analysts and solution developers because they facilitate the development of a common understanding of a need based on a user’s perspective.

A use case is a lean and narrative-based description (text/diagrams) of how a user – in a specific environment – will interact with a ‘solution’ (e.g. a website) to obtain a tangible business goal.  The focus of use case work is on the question:

“How can the solution provide observable value to the user, or fulfill their goals.” 

This is different from thinking of the solution as just a set of features or functions.

A use case is expressed in simple, natural language rather than technical jargon.  This enables the use case to be understood by a variety of audiences, e.g. customers, users, executives.

The term originated in software and systems engineering and so the ‘solution’ was typically a technological ‘system’.  It can now refer more broadly to interactions with a product or even a business or business idea (always described from the consumer or user’s point of view).  If you were asked for the use case of your business idea, you would tell the story and typical sequence of events that describes the consumers/user’s involvement with the business in deriving the value they want.

A use case typically describes a sequence of events/actions from goal to goal fulfillment.  The prelude to a use case is often called the User Story, i.e. (As a (role, e.g. business traveler) – I want (goal/desire, e.g. make a hotel reservation) – So that (benefit, e.g. I have somewhere to stay when I arrive).  The user story represents a user problem or concern.  

A use case can be identified by asking stakeholders the following types of questions (to which they must answer 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?

One criticism of use cases is that they don’t pay enough attention to non-functional requirements, e.g. reliability, performance, compliance, frequency, and priority.  If the user’s perspective does drive development of the use case there should be no reason why these requirements are not factored-in.

The Elements of a Use Case

Although there is no universal format for a use case, it will usually combine – to a greater or lesser extent – some common elements.  For example:

Title: simple verb/noun phrase, e.g. Calculate CQ Score, Enroll in Virtual Collaboration Class.  The title should clearly reflect the goal of the use case.

Value: the tangible benefits the use case will produce (from the user’s point of view).

Actor: anyone or anything that performs a behavior.  An actor might be a person, a company/organization, a computer program, or computer system.  An actor is a role (e.g. help desk representative, expat, global virtual team leader).  Actors can be categorized as Primary or Secondary.  A Primary actor is anyone or anything that interacts with the solution to gain direct benefit.  A Secondary actor is anyone or anything that is involved in achieving the desired use case outcome, e.g. someone who assists the Primary actor.

Use cases are sometimes criticized for not considering the motivations or experiences of actors.  There is no reason, however, that the motivations and experiences of the ‘typical’ actor cannot be considered.  They can add a level of richness to the work of solution developers, but shouldn’t add too many layers of complexity and distraction. 

Stakeholder: someone or something with vested interests in the behavior of the system.  All actors are stakeholders, but not all stakeholders are actors (i.e. they don’t interact directly with the system).

Preconditions: what must be true or happen before the use case can be initiated, e.g. the user is logged into the system with authorized access; the user’s profile is in the system.

Triggers: the events causing the use case to be initiated.

Main Flow: (also called Sunny Day, Primary, or Basic use case): the use case in which nothing goes wrong (the intended norm).  The scenario consists of a sequence of steps.  These are the necessary interactions between actors and the solution to achieve the desired goal. 

Alternative Flows: (also called Exceptions, Rainy Day, or Edge use cases) variations from the main flow, i.e. what happens when things do not follow the Sunny Day path, e.g. a user is not eligible, the user decides not to continue?

Post Conditions: conditions that must be met before exciting the use case, e.g. the completed task/transaction is added to a history file for later auditing. 

Non-Functional Requirements: (also called soft goals) e.g. usability, reliability, security, flexibility.

A Use Case Template

A case template is often created to support construction of the case. 






Main Flow

Alternative Flows

Post Conditions

Non-Functional Requirements

A use case can be written in different levels of detail.  For example:

Brief use case: A few sentences summarizing the use case.

Casual use case: A few paragraphs (usually two) of text that is conversational in nature written in terms of a generic user role rather than specific people.  The first paragraph starts with “An X wants to do Y to achieve Z.  They have already done W.”  The second paragraph describes the interactions and information flow, and ends with successful accomplishment of the goal.

Fully dressed use case: A carefully structured and detailed description enabling a deep understanding of the goals, tasks, and requirements.  

Use case diagrams can be embedded at any level.

Simple projects may only need a brief or casual use case.  Complex projects are likely to need a fully dressed use case to define requirements.

The case level may also depend on the progress of the project.  The first use case may be brief, and become more detailed later when solution owners need more specific and detailed guidance.

Let me end with some words of caution:

“Given a template and a few minutes of guidance, anyone can write a use case description.  The problem is that everyone writes them differently, and from different perspectives.  One person may describe what they want a solution to do, while another tries to describe the design of a set of screens, and another tries to explain how an existing system works.  If they all try to collaborate on the same use case, chaos is likely, personalities will take over, and the result will only satisfy the requirements of some of the stakeholders.  Usually the technical solution providers persevere and we lose sight of what business users wanted.”

We must always keep the business user front and center.

Keep in touch with us for the all the latest news and insights on getting results in today’s workplace.