I was talking to a colleague recently about use cases and it got me thinking about my evolution as a use-case-writer. I used to do formal use cases exclusively – where they very clearly denoted system and user steps (whether in one list or 2 columns), preconditions, triggers, Postconditions, etc. etc. etc.
After years of writing and teaching about formal use cases, I have to confess, I rarely write them now. Sometimes I still teach about them, I think it’s important to know how to write good ones. But the reality is that as we move towards shorter-iterations on our projects, the less formal we need them to be in the use case itself. What I’m finding works really well are these use cases written more like user stories. They may still have a linear set of steps, but the big difference is they are written in a more readable language of plain English with slightly less structure.
I’m oversimplifying but to make my point, instead of:
1. System displays shipping fields
2. User enters shipping info
3. System displays payment options
4. User enters payment options
I could simply say:
User enters shipping and then enters payment information.
I’ve conveyed the same information without stating the literally obvious points. You have to be careful here though, don’t assume the obvious incorrectly! Now, before you agile non-documenters jump up and down and say “I told you so!”, I want to be clear – you still need to write something down. This is the part that many projects neglect to tackle is the next level of detail. You still need to capture specific functional requirements for this use case/user story – there are our typical RML™ – with people, systems, data models to be created that describe those requirements, So I use the user stories, just like I used a formal use case – stepping through each “step” and determining what details need to be specified for building the software. Oh and one more thing, I do still use preconditions, triggers, and actors in the header – just makes it cleaner to call those out up top.
