Use Cases
I’ve just finished reading Writing Effectiv eUse Cases by Cockburn. What a tome for what I think should be a fairly intuative process. A Use Case is simply a process which is fleshed out in step for with some possible alternatives and what to do if exceptions happen.
Of course, that’s a fairly simplistic view but most BA’s will have written their share of Use Cases as part of their job. They are important documents and there can be many encased between the covers of a requirement document.
I think the trick is to keep in mind the target audience. There are now hard rules for writing a use case, probably the only important ones are that they reflect accurately what should happen in the process and they can be understood by the implementation team.
The basic components of a use case are usually the same;
- Description
- Actors (The people or tings which are involved)
- A starting state
- An ending state
- A step by step list outlining the normal events
- Any alternatives are also show as a step by step
- And what to do if there is an exception which is not covered by the normal or alternative list of events or flow.
Checl my version of the hello world of Use Cases, mailing something;
This is a fairly simple case and you can point out any of a number of deficiencies, and that’s ok, use cases should be iterative.
Here we go;
Description
- Mail an item from Sydney to Perth
Intial state
- The item is in Sydney
End state
- The item is in Perth
Actors
- The mailboy
- The deliveryman
Normal Flow
- The mailpoy weighs the item.
- The item weighs less than or is equal to 200 grams
- The mailboy puts a stamp on the item
- The mailboy puts the item in the mailbox
- The deliverymangets the item
- The deliverymanchecks the stamp
- The deliveryman flys to Perth
- The deliveryman drops the item off
Alternative flow 1
- The mailpoy weighs the item.
- The items weighgs more than 200 grams
- The mailboy puts two stamps on the item
- The mailboy puts the item in the mailbox
- The deliverymangets the item
- The deliverymanchecks the stamp
- The deliveryman flys to Perth
- The deliveryman drops the item off
We could add more alternative flows here but you get the idea
Exception
- The deliveryman checks the item and there is no stamp – Return the item
Again, we could add plenty of exceptions here but you get the idea.
The point is that a use case can be simple or complex for the same task. The use case above clearly doesn’t cover every scenario but it does convey te case in a simple easy to understand language. That language may change. The case might be written by a technical BA for a Scrum team and may be geared mor towards making an easy transition to a user story.
