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):
- 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.
- 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.
- 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.
- 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!
- As Alistair Cockburn points out in his book, use cases provide good scaffolding that connects other requirements details, and help crosslink them.
- 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.
- 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.
- 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.
- 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.
- 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.
Like This Post? Get More by Email
3) Do not read this blog one sentence per day during your lunch break, while eating a
Thanks Dario, fixed!
In 5, the name of the author is Alistair Cockburn, not Cochran.
Michael
U r right. since not only one way to capture the requirement. The key is use the most effective method and practical tools to make sure all the stakeholders understand the requirement points easily.
Philip
SSNiFs sounds good. thanks for your sharing.
ArtyFish – Good comments, thanks. Well-written use cases are very granular & they’re perfect to write test cases against. I’ll make a future post on this.
George – It’s possible that some companies can’t include use cases in their SRS. That said, at most companies I believe SRS can and should include use cases.
Philip – Interesting thoughts. What you refer to as “SSNiF” sounds very much like “use case”. It may be a good way/process to write use cases. A rose by any other name…
I’m so with you on the need for using use cases / user scenarios as requirements.
I have SSNiF scenarios to be even stronger way to express scenarios. A SSNiF is a unit consisting of the whole story of a scenario: a Stakeholder (customers/users/the vendor/a partner) in a Situation, with a resultant Need, which is resolved by one more more proposed Features.
SSNiFs can be collected, tabulated, sorted through and skimmed more easily than the prose of most scenario & use case formats.
What I find powerful about this approach is it forces everyone to
- clearly articulate the problem (Need)
- keep the problem (SSN) separated from the potential solution (Feature), to allow for even better Features to arise
- think through WHY the need comes up to begin with (ie. the Situation that begets the Need), which gives important context and insight
SSNiFs help the clients of the vision and requirements documents (designers, engineers, qa, even marketing) “get” the features because they can see the use case AND why it comes up. Empathy is everything!
SSNiFs cover the product creation lifecycle from primary research through vision to design.
– At the user research phase, turning findings into SSNiFs is a great way to make them actionable, because it connects the insight (stakeholder, situation) to a clear problem (need) and potential solution (feature).
– At the product vision phase (the discipline of selecting which problems to pursue) it’s a matter of selecting which big SSNiFs should be included and when, over a long-term plan.
– With a clear vision defined, the requirements phase becomes a copy and paste job of selecting big and little SSNiFs into the requirements document.
SSNiFs then lay the groundwork for interaction designers. Designers can deconstruct big SSNFs a step further by breaking them into little SSNiFs representing each interaction detail, and make choices as to which little SSNiFs are worth solving. When faced with a blank page and a design to create, thinking through the user’s needs in this way is FAR better than just sketching a UI.
For more information on SSNiFs please see:
http:stealthisidea.com/articles/ssnifs/
and please don’t hesitate to ask for clarification in the comments.
Best regards,
Philip Haine
Product Vision Associates
productvision.com
in our team, we use SRS, QA use them as reference,
actually, SRS is the standard. our customer also can refer them. i do not think all the companies need use case. Different firm has different solution
I can certainly see the benefit of use cases, but I don’t think they can be used as an alternative to granular requirements in a lot of cases.
For example, our QA department uses Quality Center to import requirements, and then write and map tests against them. This system is specifically designed to support granular requirements and provides excellent test to requirement traceability as well as coverage analysis.
I don’t see how use cases with some augmenting requirements can adequately provide the detail required when a QA department is focused on testing specific functionality, and the customer demands visibility of sepcific coverage data.
Perhaps this is more an artifact of the size and complexity of my product… I don’t know.
In any case, a good blog post. Use cases are sadly lacking in our current requirements and I shall endeavour to get them incorporated, but not as a substitute for detailed requirements.