What’s a Use Case
A Use Case is a functional design techniques used by those writing systems requirements documents. The IIBA state that a use case (Business Analysis Body of Knowledge (BABOK) Guide 3rd Ed.) is “A description of the observable interaction between an actor (or actors) and a solution that occurs when the actor uses the system to accomplish a specific goal.” Note, Use Case can be used to describe both high level Business Use Case and lower level system design requirements. At a high level it can be thought of as similar to a User Story in that it helps frame a description around a customer value journey. The focus is on the who and what, happy day (normal and alternative flows) and early terminations of the flow. I have used it many times to aid stakeholders describe a scenario by way of a walkthrough. This helps discover functional expectations and necessary paths the system should support. At the lower level, Use Case can be more of a formal requirement document detailing what system design must achieve, including confirming critical paths and mapping data states before and after the Use Case runs. This level of detail is really useful to system designers and testers. There is also a nice linkage to customer value journeys.
Components of Use Case
- Use Case name and brief description
A unique ID and name [use verb noun name] for the use case and a short description of its purpose - Actors
A person, another system or organisation that will interact with the use case - Pre-conditions
The things or conditions that have to exist or not exist before the use case can be runs - Post Conditions
The things or conditions that will exist or will not exist after the use case has finished executing - Event
The description of the business activity that is taking place (daily sales report, purchase refund, new employee starts) - Trigger or Triggers
The actual triggering activity that initiates the use case (time, action, reaction, condition) - Basic Flow
The normal flow or ‘happy day path’. The steps that are usually taken followed that achieve the process goal or post conditions - Alternative Flow or Flows
The steps that will be followed when the process deviates from the happy day path but still results in achieving the post conditions - Exception Flow or Flows
The process steps that will be followed that will not result in the defined post conditions.
Higher level Use Case are an excellent technique to help with scenario discovery with stakeholders. They are easy to write, easy for stakeholders to follow and easy to change. Lower level Use Case are an excellent way to communicate with system design teams. They are easy manage, track and give clarity to designers.
Tips to writing Use Case
- Identify the right stakeholders
- Ask them to name the major scenarios under investigation
- Use ‘verb noun’ naming convention to placehold use cases
- Work on each Use Case separately to ‘discover’ start points, end points as well as main, alternative and exception flows
- Write with a clear numbering sequence, this will help to make changes easier later
- Expect iterations as the Use Case is passed around between stakeholders (version control and discipline is important)
- Help stakeholders to understand the use of post and pre conditions
- Ask designers for their input and confirmation of their understanding
- Ask quality/ test for their early input
- Don’t be afraid to add attributes like – priority, important non functional attributes, UX considerations, user pain points etc
Recent Comments