Other
Nov
15
Why Use Use Cases?
November 15, 2005 | |
Use Cases have been around for quite awhile now and are considered by many to be best practices in software development. I continue to be surprised at how few organizations actually use them though. Why is this? Too difficult, lacking in the right skill set, perceived to be too much work for not enough benefit, or just plain organizational inertia? Not sure myself, but I do know that if you’re not using Use Cases, you should be.
I’m working on polishing up a Use Case template and will publish it soon - of course you can get a zillion off the web yourself. I’d suggest starting at the Wikipedia entry and going from there. If you haven’t already, you should really own a copy of Bruce Cockburn’s Writing Effective Use Cases, the only book on the subject you’re going to need, unless you’re doing some really in-depth stuff.
If you need some ammo within your organization on why you should be working with Use Cases, here you go:
Functional Requirements Presented in Text Form
Use Cases are a great way to present functional requirements in an easy-to-understand text form. End users and sponsors in particular appreciate having requirements in a format they can quickly interpret. Process flow diagrams are often used to capture business processes, but they are not as easy to understand by those not trained in diagramming processes.
A Common Language and Understanding
It’s easy for everyone involved on the project to refer to Use Cases as a common understanding about the project. Sponsors can easily view the range of functionality and comment on things left out, or items that don’t need to be present. Developers can refer to Use Cases for a quick way to come up-to-speed on how the business operates and how the various functional requirements fit together. Use Cases tell end users exactly how they will interact with the finished application.
Get Your Requirements Reviewed
Because Use Cases are in straight-forward text, they are much easier to review. This will greatly improve the odds that at least some of the project’s documentation is reviewed and commented upon. You always want to prevent hearing sponsors or end users say “That’s not what we wanted” at the end of the project!
Who Does What - The Actors
Use Cases have actors - which are the stakeholders of the system. Actors can be primary end users, secondary users, organizations, or other systems. By listing out the actors, you get a clear picture of everyone involved in the system.
And Why - The Goals
Each actor within the system has a goal, or something that they need to achieve. Documenting what you need the system to do seems like a simple thing to do, but you’d be amazed at how it focuses the project on the things that really matter.
Goals Fail
If you’re writing Use Cases properly, you’re thinking about failure scenarios. What happens when a particular goal is not met? Documenting failure scenarios and conditions early in the process helps create a more robust and complete design.
Scope
Take all of your Use Cases together and you have your total system scope. Use Cases help you form the boundary between what the project is doing, and what it’s not doing.
Test Scenarios
Use Cases make a great starting point for test scenario and test cases. They define users, roles, responsibilities, goals, steps, and error conditions - a large chunk of what you need for your test scenarios and test cases.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.
Comments
4 Comments so far
Great points about why use cases are important. I’m running a series of articles about the different ways that people manage use cases on their projects here (http://tynerblain.wordpress.com/2005/12/18/use-cases-series-introduction/), and I’ve referenced your post in this article(http://tynerblain.wordpress.com/2005/12/19/use-case-series-formal-use-case/).
You’re spot-on about users having goals - great post.
Scott
[…] Why use use cases? from the Carnegie Quality blog […]
We moved our site to tynerblain.com/blog. The introduction to use cases is now at Use case series: Introduction
[…] Why use use cases? from the Carnegie Quality blog […]