A question that frequently comes up in my conversations nowadays is:
What exactly is a Use Case?
Let me try and explain it in this short blog post.
What is a Use Case?
Based on a couple of my favorite books on requirements, “Software Requirements,” by Karl Wiegers and “Writing Effective Use Cases,” by Alistair Cockburn – I’d define it as follows:
A use case is a series of related interactions between a user (or more generally, an “actor”) and a system that enables the user to achieve a goal.
To phrase this definition in another way, a use case describes the system’s behavior as it responds to a series of related requests from an actor.
Use cases are perhaps the best way to capture functional requirements of a system.
Here’s an example to help you get a more tangible feel. Let’s say you’re designing a Human Resources software used to keep track of employee information at your company.
For such a project, here’s a simplified example of a use case titled “Add an employee”:
| Add an employee:
As you can see above, each of the steps is sequentially numbered. Each sentence begins with a noun – such as “user” or “system”. This noun is followed by a verb – such as “selects”, “displays”, “enters”, etc.
As well, note how the title of the use case is written as a short, active verb phrase that defines the goal of the use case.
There is much more to the art & science of writing effective use cases – I’ll cover them in future posts.
What is NOT a Use Case?
Sometimes you may hear people refer to UML Diagrams as use cases – these are the diagrams composed of cute stick figures and ellipses as shown below.
For reasons that remain a mystery to me, many people have focused on the stick figures and ellipses in use case writing…and have neglected to notice that use cases are fundamentally a text form…
Whatever the reasons, we now have a situation in which many people think that the ellipses are the use cases, even though they convey very little information…
The UML diagram… is not a notation for capturing use cases.
I think UML diagrams are of little practical use to many important stakeholders such as end users, engineers, and business executives – as most of them don’t know how to read UML diagrams.