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

In my previous post, I provided a definition of Use Case along with an example. I also explained why you shouldn’t consider UML diagrams as use cases.

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

10 Reasons for Using Use Cases

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.