Use Cases – Top-10 Reasons for Using Them to Document Your Requirements

Follow

Email

In my previous post, I provided a definition of Use Case along with an example. I also took a strong stance against considering UML diagrams as use cases.

Matt Klein made a good observation on Twitter today on how use cases are often not used well when documenting requirements:

Use Cases are important and very often not captured or documented correctly…

In this post, I’d like to share with you 10 reasons why you should use Use Cases while documenting your requirements.

Top-10 Reasons for Using Use Cases

Here are my Top-10 reasons (unordered list):

1. Use cases tell coherent stories about how your product will behave in actual use. Readers get to easily understand the big picture of what your product will do and what it’s for.
2. Use cases help you document scenarios for success & failure well. The thinking that goes into writing good use cases helps you capture many failure conditions that often go undetected.
3. Use cases fit any development methodology well. If your team follows extreme Agile methodologies, you can just write use cases in the form of brief user stories or usage narratives. If your team follows more structured development, you can write more detailed use cases.
4. Use cases are interesting to read as they tell readers about context, not just what needs to be done. This means the engineers are much more likely to actually read your requirements document! 😉
5. As Alistair Cockburn points out in his book, use cases provide good scaffolding that connects other requirements details, and help crosslink them.
6. Use cases are perhaps the best way to document functional requirements, rather than gobs of text often used to do so. While use cases may not be sufficient to document all functional requirements, I believe they’re the best way to document the core of each functional requirement.
7. Use cases are a great way to elicit requirements from users – you can engage in dialogue with users about the goals they’d like to accomplish with your product, then document them as use cases and review them with users.
8. Use cases are written from user’s point of view – which I believe is the best point-of-view to use when writing requirements. Focusing on users is much better than focusing on product features or the latest cool technology.
9. Use cases can be understood by many stakeholders – such as business users, engineers, executives, et al. This means you can get much better feedback during reviews to ensure your requirements are accurate.
10. Use cases are requirements in themselves. While you can use requirements to augment use cases and provide missing details (I recommend it), there is no need to rewrite use cases into requirements. Well written use cases describe accurately what the product must do.

Editor’s Note:
Interested in an affordable, enterprise-quality software to help you manage requirements in a better way? Check out FREE 30-Day trial of Accompa or Sign Up for a Demo.

Follow

Email

Michael Shrivathsan

I'm your author, Michael Shrivathsan, an expert in product management with successful experience at several innovative companies in Silicon Valley, USA over the past two decades. I'm also a USPTO patent recipient. For my day job, I'm the VP of Product Management at Accompa, we make the popular requirements management software used by Product Management, Business Analysis, and related teams.

More Posts - Twitter - LinkedIn