Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Tuesday, August 04, 2009

A Better Way to Write a Use Case: Plain English

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.




Labels: , ,

Requirements Defined Newsletter Bookmark and Share

2 Comments:

Blogger Unknown said...

Yes, you could write it like that and it is perfectly fine for an informal use case, but there are some caveats.

In my experience, there is nothing that goes without saying. What is obvious to you, might not be so to someone else.

The format makes it harder to handle alternate paths and exceptions. These are not typically spelled out in an informal use case, but can be tremendously important.

The longer format is more useful as a source when creating test cases. Whatever the user does goes into the description of the step and whatever the system does goes into the expected result column.

--
Aleksander

8/05/2009 2:19 AM  
Blogger Joy said...

Thanks for the comment! I don't disagree with your points, however the trick is if you write too much, people won't read it! For better or worse - and I agree they should - they just won't.

Your point about alternatives I totally agree with. I like to supplement such stories with process flows or decision trees to make these paths visually clear too.

8/07/2009 2:33 PM  

Post a Comment

<< Home