How Use Case 2.0 Works
What does Use Case 2.0 entail, what advantages does the concept offer and how can it be used in practice?
A Use Case describes the visible behaviour of a system from the user’s view point.
Every Use Case has a basic flow. Use Case 2.0 follows a sequence of steps that lead directly to the conclusion.
There are always alternatives if the straight path doesn’t work out. Use Case 2.0 refers to these as alternative flows.
There is no limit to the number of alternatives possible. Every alternative that stretches from start to finish is described as a Use Case story.
During the slicing process several Use Case stories gets summarized into one unit – a Use Case slice.
The slicing takes place along a vertical axis from the first to the last step - not horizontally across Use Cases.
The Idea behind Use Case 2.0
In 1987 Ivar Jacobson introduced the Use Case 2.0 concept. He defined use cases as „a special sequence of transactions, performed by a user and a system in a dialogue“. In other words, a use case describes a system’s visible behaviour as seen from the point of view of the user.
The power of use cases lies in their ability to provide a general overview of the system’s behaviour. They give you the big picture of a system to be developed and provide orientation, and they help you to understand a system. Without this understanding, decisions regarding the scope as well as regarding costs and benefits of the system are impossible to make.
Very often use cases are too extensive to be realized in a two or three week sprint, as commonly found in agile environments. How, then, is it possible to combine an agile approach with use cases? Jacobson and his co-authors Spencer and Bittner provided the answer in 2001: Use Case 2.0.
This technique is based on the “slicing” of use cases into manageable units which then can be realized within a single sprint. How exactly a use case is sliced is determined by the interactions between actor and system. Realizing use cases in smaller units has another advantage over other approaches: Stakeholder feedback can be gathered earlier. This, in turn, guarantees that an important goals is achieved: creating value for the stakeholder.
How to Apply the Use Case 2.0 Concept in Practice.
Learn more about requirements modeling
with objectiF RPM or objectiF RM »
The Basic Principles of Use Case 2.0:
Describe things as simple as possible
Understand the big picture
Focus on the benefits
Build the system in slices
Deliver the system in increments
Adjust to the Needs of the team
Defining Use Case Slices
There are some general rules regarding the slicing of a use case:
- The first slice to be realized is always the basic flow.
- Additional slices are based on a single use case story or created by merging multiple use case stories.
- A use case slice must also contain a test case, just as a user story needs acceptance criteria.
- Two use case slices may be based on the same use case story and only differ in the test cases assigned.
Slicing the Slice
What should you do if a use case slice is too big to be realized in a sprint? Well, just slice the slice. If a slice needs to be sliced the following rules should be adhered to:
- Each part of a system, once implemented, is fully-functional.
- Each part, once implemented, creates value for the user.
- Each part, once implemented, makes user feedback possible.
How to Combine Use Cases and Agile Planning
First, the project stakeholders, e.g. users and actors working with the system, need to be identified. Their goals must be understood because the aim of a use case is to help users achieve their goals. This is the basis for determining use cases, for example in stakeholder workshops. A great way to find use cases are narratives. The development of use cases can be done by applying either a top-down approach (finding individual steps and alternatives based on the use case) or a bottom-up approach (determining all possible alternatives and combining them in one use case) – or a combination of the two.
As soon as you have created a number of stable use cases, storytelling by users helps to gain a deeper understanding these use cases, to detail flows and to create use case stories. It is also very helpful to keep in mind the possible test cases that may come with a flow and a use case story. Once the use case story has been cretaed the slicing can begin. The first slice should always be based on the basic flow.
Use Case 2.0 does not require all use cases to be completely defined before realization begins. A few, essential use cases can be used as a basis for the creation of some initial backlog items. Similarly, use case ned not be completely sliced; it is sufficient to create initial slices to begin realization in sprints. Additional slices can then be added if need may be.
Take advantage of Use Case 2.0 and an agile approach to project planning!
Keep an eye on the big picture and all the details. Take an agile approach to your projects and guarantee full traceability. Create use cases and slices – and realize them directly from your product backlog.