THE TERM USE CASES IS UBIQUITOUS
Ivar Jacobson, the creator of use cases
Wrestling with a big pile of technical stories but struggling to see the big picture?
Never lose sight of the big picture with Use Case 2.0. The key goals of the system can always be seen as use cases on a visual diagram, while use-case narratives organise individual requirements. These small requirements can be expressed directly inside the use-case narrative or even as traditional user stories. Just zoom in to see the level of detail needed.
High number of tiny stories in the backlog and struggling to set priorities?
Use cases collect together related requirements, potentially expressed as user stories, so that whole flows through the system can be understood. Slicing the use cases in ways meaningful to the stakeholders allows you to set priorities at the level you require, broad for longer-term release planning or thin slices for prioritising in the short term.
Finding it difficult to understand and manage a growing set of test assets?
Well-written use cases provide insightful guidelines for the design of tests. The prioritised use-case slices also group together their related test cases which will be prepared before development begins on them. This facilitates test-driven development.
Getting Agile Teams to Work
Requirements requested and expressed by the client are not formulated in a language the development teams can run with?
Users naturally express their requirements by telling stories which are captured within the structure of the use cases. These use cases are then sliced up and directly drive the work of the whole development team, ensuring the same natural expression of requirements is used all the way through.
Struggling to create and maintain easily accessible and lightweight documentation for support and maintenance of requirements for later releases?
Use cases are structured around the real-world usage scenarios of the system so make it easier to relate them to support needs or for writing lightweight documentation. This use-case structure is easy to extend with new usage scenarios as the system evolves while having minimal impact on what has already been written.
Plagued with scope creep and no way to visualize the system boundary?
A simple use-case diagram shows the goals of the system and makes explicit the system boundary with actors representing any users or external systems. Each individual requirement should fit within the scope of this big picture, typically within a use case. If it doesn’t, and it requires a new use case or a new actor, then it is potentially outside of the originally envisaged scope and should be questioned accordingly.
Getting Requirements Right
Your client thinks and requests what they want a system to do by using use cases, but we actual implement from a pile of small requirements items or user stories?
Use cases talk in the same language and structure as the client thinks and are exactly what the system provides. Working with the same language and structure as the client thinks, allows for better communication with less misunderstandings between all groups from beginning to end.
The product is released, but you don’t have something describing what the product can do?
User Stories can often lead to a large number of fragments without the ability to see the overall capability of the released product. A use-case diagram however gives a quick view of the overall capabilities, while the use cases and their narratives describe what the product does.
Using user stories but they are not working as the system, teams or projects scale or become complex?
To deal with issues of scale and complexity it is important to deal with different levels of abstraction. Use cases can be applied at many levels and across systems giving us the important end-to-end flows to focus on and test at all scales. This ensures all the detailed pieces built come together to deliver the overall goals.
Need a formal requirements spec for compliance/regulatory reasons but want to ensure you remain agile?
With Use-Case 2.0 you have an auditable requirements specification throughout and at the end, rather than just a huge pile of story post-it’s in the garbage bin! To remain agile the use cases can be authored and built incrementally, slice by slice, adding detail where it is needed within the well-understood big picture.
Getting the Right Product at the Right Time with the Right Quality