Follow
EmailA 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.
An Example
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.
Don’t be fooled. If these are use cases, then I’m Brad Pitt – i.e. not even close! 🙂
As Cockburn says in his book (emphasis his):
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 mostly a giant waste of time and of very little practical use to many of the important stakeholders such as end users, engineers, and business executives – most of them don’t know how to read UML diagrams. The only possible use I can imagine is as “Table of Contents” for text-based use case documents – but even for that, there’s a far better text-based approach that all stakeholders can understand. But that’s a topic for another day and another post.
FYI: Teams at more than 100 companies (Fortune 500s to growing startups) use Accompa Requirements Management Software to create, manage and collaborate on their use cases. To find out whether Accompa can help your team too, check out the product tour or request free trial.
Like This Post? Get More by Email
3) Do not read this blog one sentence per day during your lunch break, while eating a 