What are uses cases? Wikipedia defines use cases as a list of steps, typically defining interactions between a role/actor and a system, to achieve a goal. The actor can be a human, an external system, or time. Often a use case is presented as a diagram to depict these interactions as a means to identify, clarify and organize requirements.
A use case can have several elements with the most common being:
- Actor – anyone or anything that performs a behavior or action
- Stakeholder – someone or something with vested interests in the behavior or action
- Primary Actor – stakeholder who initiates an interaction to achieve a goal
- Preconditions – something that must be true or occur before the use case can happen
- Triggers – an event that causes the use case to begin
- Main success scenarios – basic use case flow where all conditions are ideal and nothing unexpected occurs
- Alternate paths– alternate flows where there is a deviation from the basic flow; these paths are when something unexpected occurs and several of these alternate paths can be identified for each basic flow
There are several reasons to incorporate use cases into your project, such as:
- Improving communication among team members
- Encourage common agreement about requirements between the business and the development teams, who are often speaking different ‘languages’
- Identifying process alternatives, process exceptions and outstanding issues
- Identifying out of scope items
- Automation of manual processes
- Assisting developers to understand business processes
- Aiding in the recognize of patterns and contexts in functional requirements
- Prioritization of development work
- Assisting testers to identify gaps between the requirements and what has been delivered
While use cases have many benefits, there are also a few limitations to be aware of:
- They are not ideal for capturing requirements in non-interaction based situations
- Skilled writers are required to write quality use cases
- Depending on the complexity of the situation, this technique may not be the most appropriate to use
- They should not be used as a standalone technique to communicate requirements
To write a quality use case, it is imperative to write the use cases in language that is easy to understand by both the business and development teams. Guidelines to follow when writing use cases are:
- Identify who the users will be
- Pick the first user to start with
- Define what the user will want to do or what their goals are
- Determine what the basic path will be for each goal
- Document each step that will be required to accomplish each of the users goals
- When documenting each step, describe the steps in terms of what the user does and what the expected result or response should be
- When the basic path is described, consider alternate situations and add those to alternate flows of the use case.
- Look for similarities in the use cases and any that may be related, and note the relationship
Here is a simplistic example of a use case diagram, compliments of Wikipedia:
Do you use use cases on your projects? If so, what are the benefits and limitations you have found?