Use Case Problems?
Three Fundamental Concepts
Explain Many of Them

Overview

Use cases have so much promise and yet cause so many problems that some people have given up on them. We have learned what is at the root of these two divergent viewpoints - three fundamental concepts.

First we should define what they are. The Building Requirements Consensus™ definition follows standard UML with a twist. A very important twist! Please note that while there is a twist, this definition does in fact comply with the UML Specification.

The Building Requirements Consensus™ Use Case Definition

A use case is a set of interactions with a system
that provides a perceivable benefit of value
to someone or something (the user)
playing the use case's role (or part)
from the perspective of the user.

Three Fundamental Concepts

The three fundamental concepts are:
1. use case
2. system
3. role - yes, role and not actor - this is the twist!

Let's look at each fundamental concept individually.

Link to a podcast if you would like to hear a description of these concepts. Brian Cook, President, was interviewed by Requirements.net for its "Maximize IT Value" podcast series on February 9, 2009.

1) Use Case

Industry wide this concept is fairly well understood. It represents functionality that produces a benefit that is perceivable by the user. It describes how a user and a system behave to accomplish the defined goal. There are four parts:
A. a name - in active verb / noun format
B. a goal - in one or two concise sentences
C. a graphical representation – an oval with the name inside or below the oval
D. a textual conversation consisting of perceivable events between a user and the functionality

2) System

The concept of system is more problematic. The most serious problem is that system is a synonym for "the thing we are building." There are several issues here.

System - A Hijacked Term

Somehow the term system was hijacked by the IT community. For example, there are "business requirements" and "system requirements." The implication is that if it is not in code it cannot be a system. That is a false assumption!
• The universe itself is a very large system! It contains many other systems like the Milky Way, our solar system, weather systems, the skeletal system in our bodies, ... Most of those systems will never be coded!
• The business has systems that existed long before automation. Examples include: accounting systems, inventory systems, production systems and delivery systems.

A System Is Rarely Simple

It is a problem that a system is thought of as a simple thing.
• In our careers, we have never worked on a simple single system. Every project has been a system of systems.
• When system boundaries are not explicitly identified, use cases become confusing. Consider the overused ATM System example.
• A single element can be part of multiple systems. E.g., a computer can be part of a local system (run MS Word), be part of an intranet (edit a doc on a shared drive) and be part of the internet (verify vendor info for inclusion in the doc). The behavior of the computer varies depending on which system is active at a given moment.

No Definition in the UML Specification

The UML Specification does not give a useful definition of system. It says “A top-level subsystem in a model” which is not very helpful. A system is a subsystem!

A later version adds “An organized array of elements functioning as a unit” which helps but uses the IT centric term “array.”

We have to go outside of the UML Specification to get a definition that applies to both business and IT. The best I’ve found is “a system is a set or group of elements that exhibit behavior collectively.” Note the emphasis on producing behavior. Without behavior, there is no system!

3) Role

Role? Not actor? What’s up with this?

Using roles and not actors is the twist, the biggest conceptual change that the Building Requirements Consensus™ Methodology introduces. It is hard to know that roles even exist from many of the books that are available. However, the concept of role has been in the UML Specification all along.

Here is one excerpt. An actor is a “coherent set of roles ... An actor has one role for each use case with which it communicates.” See more excerpts from the UML Specification. However, the concept of role has usually been ignored – with dire consequences.

Diagrams like this example are all too common. How are readers supposed to interpret what these actors mean?

Roles applied properly follow the UML specification. The resulting logic is that there is a one-to-one mapping between a use case and a role!

This turns out to be quite good for architectural reasons. Roles used this way are analogous to the concept of object-oriented interfaces. Requirements documented from this perspective directly support service-oriented architecture (SOA). It becomes much simpler when you document using roles instead of actors. It helps everyone involved think from a service oriented perspective whether they understand the implications of what that means or not.

See Sean Connery Roles for a nontechnical example of the difference between roles and actor.

Blueprint has recognized the importance of the role concept. They have modified Requirements Center to directly support the use of roles as opposed to actors by making the terminology user configurable.

Your Benefit

Apply these three fundamental concepts to your use cases and you will see problems reduce in frequency and severity. You will be moving closer to the upper third group, See point #2.

The Building Requirements Consensus™ Methodology will improve your skills and result in better projects that satisfy, and maybe even delight, your customers.

From Use Case Basics 101 to Building Requirements Consensus™ Home