Producing Use Cases

Introduction

The foundation of a good application begins with a good design and the foundation of a good design begins with good use cases. Of all the artifacts produced from a software design, use cases are the most important. Use cases capture the business process and, collectively, describe the software application’s functionality from the user’s perspective.

This article overviews use cases and the challenges associated with them, offers tips in their creation and suggests a structured approach to produce them.

What are Use cases?

Use cases are a necessary artifact of object-oriented application system design and development. Actually, more than that, they provide the foundation for the design of the entire application since application classes and their relationships emerge from the use cases.

At its simplest, a use case is simply a structured narrative of a domain process that describes the requirements of a software system. Dr. Alistair Cockburn, one of the industry's use case Gurus describes use cases as “sequences of interactions between the system and its external actors, related to a particular goal.” The idea is that users (and systems) have domain goals that need the help of computer systems to achieve them. Examples of goals are registering students, recording sales, and determining baselines. The point is to express the requirement in a way that is simple and understandable to anyone within the problem domain.

The vocabulary of the use case must be expressed in the terminology of the business domain.

Strictly speaking, use cases are not object-oriented artifacts and can be used with any software development paradigm. However, they are typically associated with UML Use Case Diagrams that depict associations (or relationships) between the actors of a system, their responsibilities (or goals) and their boundaries. The use case diagrams provide a visual table of contents, an overview, of the system's actors and use cases.

While UML Use Case diagrams graphically depict use cases, they do not define them.

The real value of a use case lies in its textual description, or its scenario. A scenario is a sequence of action steps the use case takes in order to achieve its goal including any pre and post conditions. A goal can either be successful or it can fail. The use case contains scenarios that describe the goal’s successes and failures. A success scenario is one in which the goal is achieved, a failure scenario is one in which the goal fails but still protects the interests of the stakeholders.

The main success scenario is the typical or normal success path.

Think of the scenario as the execution model (the object instance) of the use case. Use case scenarios, then, provide the foundation for test cases. Additionally, scenarios provide the basis for system documentation and User Manuals.

Use cases, are strategic goals that consist of scenarios that provide value to a business domain.

Stakeholders

A stakeholder is someone of some "thing" with a vested interest in the behavior of the system. Not all of the stakeholders are present while the system is executing but the system must protect and satisfy the stakeholders interests at all times. Examples of the stakeholders include company shareholders, customers, vendors, and government regulatory and reporting agencies.

A use case describes the behavior that protects and satisfies the stakeholder’s interests.

Actors

An actor is anyone or any "thing" that interacts with the system to achieve the system’s goals: individuals, organizations, and other computer systems. Actors are stakeholders who interact with the system. Typically, Actors have behavior and are represented by the roles they play in the use cases; ex: Student, Instructor, Software Developer, etc.. However, Actors are not job descriptions - ex: Programmer I, Manager II - unless the business domain requires it.

Actors have goals that are achieved by use cases.

An Actor stimulates the system by providing input or receiving something from it. The primary actor is the stakeholder that initiates or triggers an interaction with the system to achieve a goal. The primary actor will be the user sitting at a computer or another computer system.

The primary actor is the one that initiates the use case's main success scenario.

Supporting actors are actors that assist the primary actor to achieve the goal. They interact with the use case but do not trigger it. They are often external systems or third party components.

An actor can be the primary actor for one use case and the secondary actor for another.

Use case identification

Identifying use cases is not as simple as it might initially seem. Several issues need to be considered that can be tricky and crucial to the successful modeling of the business domain. In no particular order, some of them are:

• Finding the boundaries of the system.
• Searching for actors and their responsibilities, or goals.
• Establishing the scope and level of the use case.
• Searching for exceptional and failure situations
• Linking use cases (one use case's post-condition is another's pre-condition).

Moreover, different types of use cases exist and are described by different people in different ways. However, most begin with high level use cases - call them System or Essential use cases - and proceed from there to define more detailed types of use cases.

Use cases can be identified using several methods:

• Identify all the actors in the system and define their roles and responsibilities.
• Identify and partition the system into major areas of functionality.
• Identify and relate all the events in which the system needs to respond.

Regardless of the method used (or combination), the process usually starts with a brainstorming session, at the high level, and, iteratively, drills down to the details - in other words, breadth-first. Iterations encourage focus. Each iteration focuses on one aspect of the use case. Working too quickly and attempting to capture too much can quickly lead to unrealistic use cases with too much complexity that don't reflect the actual needs of the domain users.

Breadth-First approach

Using the breadth-first approach insures the entire system is covered, if only at a high level. At a minimum, the breadth-first approach identifies all the features of the system from the requirements.

Some of the benefits are:

• Complexity is gradually developed and better understood.
• Initial use cases are developed quickly.
• Tight schedules can produce as much as needed.
• Works well with all development methodologies; eXtreme Programming, Agile, etc..
• Design is reusable and extensible; later releases will increase depth; each level is a new iteration (or series of iterations).

So, for example, a typical iteration might look like the following:

• Iteration 1: Identify the stakeholders, the primary actors and their goals.
• Iteration 2: For each goal identified in iteration 1, define the main success scenario.
• Iteration 3: For each success scenario identified in iteration 2, define the alternate scenarios.
• Iteration 4: For each scenario identified in iteration 3, define the exception conditions.

In Figure 1, the iterations proceed from the right and move down. As they do, problems will surface that provide the motivation to forming new use cases, linking existing use cases, and discarding and combining use cases. In this sense, use cases are refactored during each iteration.

Problems in the early iterations are good and to be expected, but, as the iterations continue, beware of the becoming too focused on the implementation. Use case names that begin with, "Perform..." or "Process..." indicate the use case was written from an implementation perspective rather than from a domain user Perspective.

Use cases are not function calls.

Domain charts

As the use cases are identified, related use cases will emerge. In the Model Driven Architecture approach, related use cases are grouped together into application domains from which a Domain Chart is developed. Domains are autonomous entities logically grouped by their function. Domain charts depict the system as distinct, independent domains that work together to provide the application’s functionality.

In Figure 2, related use cases for a Book store have been grouped together that shows, at a glance, the major domains in the application. Each domain contains subsystems that implement the domains functionality.

Domain Charts encourage parallel design and development.

Validation

Validation determines the credibility of the use cases and it critical to capture the business process. As the use cases are refactored, ask the following questions:

• Does the use case capture the business process?
• Are there any details that need to be added?
• Will the actor's goal be met?
• Can the use case be simplified?
• Are there any additional goals that are not addressed?
• Are there any additional actors that are not represented (directly or indirectly)?

Use Case formats

Many use case formats exist and some provide more content than others. There is no single use case format that exists for all projects. Some projects follow a lightweight development methodology that requires less documentation, perhaps because of a tight schedule, other projects are heavyweight and require more documentation, perhaps for mission critical projects.

In Writing Effective Use Cases, Dr. Cockburn describes the following formats:

• Fully Dressed: The most elaborate. This template describes the actors, stakeholders, protection of stakeholder’s interests, performance issues, pre- and post conditions, exceptions, notes and annotations. Used when formal and complete documentation is required.
• Casual: Written in paragraph style, a few paragraphs at most. Less formal and contains less content than the fully dressed format.
• Brief: One paragraph that summarizes the business process. It mentions only the significant steps in the main success and failure scenarios.

Additionally, two other formats can be considered:

• Normal: This would be the normal methodology that specifies and defines the design model in more detail than the casual format, but still less than the fully dressed format. Design reviews would be tighter and less forgiving than the Agile approach (below) and more precision and rigor would be applied.
• Agile: Projects using this format would practice an Agile Modeling and Development methodology to produce the software very quickly but still contain an acceptable design. The UML artifacts, while complete, would contain less detail than for the normal development methodology and would be oriented more towards the higher level perspective. Smaller projects or projects with tight deadlines might fall within this scenario.

Choose the format that best fits the project.

Modeling Create, Read, Update, Delete (CRUD)

Ideally, CRUD functionality is expressed in terms of a business process - the action the user performs. The semantics in use cases are extremely important and should be expressed in the language of the user – not in the language of the developer, the functionality of the system or in database modeling terms. Good design perceives the system from the user perspective.

The problem with CRUD use cases is that they describe the technical implementation without explaining how this is valuable to the user. At best, it is a low level goal that is fulfilled within the context of the use case scenario.

Consider the use cases for a Word Processor. Which states the business case best: Create Style, Update Style, Import Style, Delete Style, or Insure Consistent Formatting within a Document? The latter expresses the goal of the user best. While Create Style, Update Style, Import Style, and Delete Style reflect the functions that occur within the business domain, they don’t express the user’s goal to format her document. Instead the goal has been decomposed into discrete functionality.

Resist the tendency to decompose use cases into functions.

Or, consider another example. For security purposes, its typical for users to login to an application. However, logging in is not a business goal of the user. In other words, the user of say, an inventory system, doesn’t say to herself, “Today, my goal is to login and logout of the inventory system in the most efficient manner possible.” Moreover, the user isn’t evaluated by how well she logs into the system. She won’t get a raise for logging in 45 times in a single day.

Rather than including CRUD and ancillary functionality (like Login) with the business use cases, separate them into system use cases that separately exist at a level of detail lower than the business use cases.

State the system process in technical terms.

Its natural for developers to think in terms of implementation. Yet, this tendency needs to be resisted and continually guarded against for the business use cases. Moreover, developers should not force users to adopt implementation language. Its the developers who need to adopt the user’s language, not the other way around.

State the business process in terms of the user.

Producing Use Cases

The following steps suggest a structured outline to produce use cases. They are meant to be followed in a group session and attended by the members of the development team - and customer representatives, if possible. The design session atmosphere is open and relaxed and discussion, even vigorous, is encouraged. Ideally, the session facilitator is experienced in summarizing and clarifying the ideas presented by the group into coherent statements.

Materials needed: Markers, whiteboard (for brainstorming), flipcharts

Note: The steps assume the requirements have already been collected.

1. Produce an initial Actor-Goal list from the requirements.

   The Actor-Goal list describes the behavior of the application at the highest level. Still, each primary actor has been identified and associated with its goals. The goals will eventually result in use cases.

   • Identify the stakeholders and their interests.
   • From the stakeholders, identify and list primary actors. If necessary, begin with brief narrative to identity initial actors and goals.
   • For each actor, identify goals, refactoring as necessary.
2. Verify Actor-Goal list and produce project narrative.
   • In group discussion, slowly step through a narrative, capturing the essential steps in written form on a whiteboard.
   • Referring to the narrative, insure that the Actor-Goal list captures the narrative’s. All of the actors and their goals should be evident in the narrative. If not, refactor the Actor-Goal list as necessary.
   • When finished, each team member should understand and be able to repeat the narrative

   This step will produce two artifacts:

   • A verified Actor-Goal list that captures the behavior of the system and protects the interests of the stakeholders.
   • A detailed project narrative that identifies all the project stakeholders and their interests. The narrative serves as great project documentation and helps to insure the use cases will protect the interests of the stakeholders. It also insures that all developers share a common understanding of the project since all developers participated in the narrative.

   Note: If the narrative has already been produced prior to step 2, revisit it with the entire group. Undoubtedly, it will change and improve as questions and critiques arise.

3. Iteratively, produce the initial Use case briefs.

   Focus on the primary actors and their main success scenarios in the first iteration. In later iterations, add the detail necessary for the desired use case format.

   • Select the Actor-Goal from the verified Actor-Goal list that significantly influences the core architecture.
   • Express the goal in terms of the business process; address the user's need, not the implementation of it.
   • Avoid CRUD terminology. The use case must be expressed in the business vocabulary - it should make sense to the business user. For example, instead of "Create Student", perhaps, "Register Student to a Class" is more appropriate. CRUD Use case are more appropriate as "system" Use Cases...not "user" use cases.
   • Avoid determining Use cases by functionality.
4. Produce Domain chart
   • Partition Use cases into related, autonomous domains.
   • Consider that each domain can be designed and even implemented independently.

Conclusion

Use cases are the first step towards designing and ultimately delivering quality software that works the way the user desires. Since use cases capture the business requirements from the user perspective, no other design activity has a larger return on investment. Similar to the specifications for a house, use cases provide the specifications for software applications. From these specifications, design artifacts are produced that are used in the construction of the system. Ultimately, application design, construction and user acceptance of the software rests on solid use cases. Don’t neglect this essential step in the lifecycle of the software application.

Additional links

• Scott Ambler offers great tips for drawing use case diagrams.
• Structuring Use Cases with Goals from Alistair Cockburn.
• Use-Case Model: Writing Requirements in Context by Craig Larman.
• Top Ten Use Case Mistakes.