The case for use cases

Subject: The case for use cases
From: "Michael West" <mbwest -at- bigpond -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 1 Sep 2000 23:51:17 +1100



I've just been to the techwhirl website and read the
summary of tech-whirlers comments on use cases
provided by Jean Hollis Weber at
http://www.raycomm.com/techwhirl/usecases.html

Unfortunately, I missed the original thread, but I wanted to
add something to it, so I'll do that here.

I'm an old warhorse in the user doc racket, and I'd never
heard of use cases until fairly recently. Here's what I think
of them.

Done properly, they're the best thing since canned beer.

No, wait, -- I don't like canned beer. But I do like
use cases. They are like a Requirements Specification
Without Tears. The programmers don't have to write
(ewwwww!) anything. All they have to do is draw simple
little diagrams and labels. Done!! That's it!!

And here's what it gives me --stuff that in the past I
have had to BEG for and, even then, seldom received:

1. Who are the users?
2. What to they put into the system, and when?
3. What do they get back?

Tech writers!! Do you realize how great this is?

If you have a properly executed use case document.
you can blueprint the entire user doc suite before the
first line of code is written. Think about it.

What the use cases tell you is exactly what
each user/system interaction consists of.
With that information, you can draft a user
guide that covers every human interaction.
After that, it's just a matter of filling in the blanks.
Like, what buttons do they push? For those
details you may have to wait awhile.

But still, that's much better than the old way,
where you never even knew what the interactions
were until the code was nearly complete. In fact, how
many of you have ever had a complete Requirements
Specification BEFORE the coding started? If you did,
you're in the lucky few. In my experience, the
Requirements Specification was seldom if ever
usable because it was abandoned in the early
stages of the project. Why? Because what project
manager wants to "waste" time and resources
on something like that when he's got code
deadlines to meet?

So here's my advice. If the developers in your
shop start talking "use cases" -- go for it! But try
to get in on the ground floor and make sure they
execute them properly. Give them examples and
templates. Lull them into thinking that YOU'RE
helping THEM. The information you get from good
use cases is exactly the information you need to
map out your entire end-user documentation suite.

You'll be able to do all the sweat work up front, then
kick back and let the piddling details roll in. As they
say down here, you'll be laughin', mate. You'll be happy
as Larry. (Don't ask. I'm still lookin' for 'im.)


For more information, see:

the http://www.rational.com site in general, and particularly:

http://www.rational.com/products/whitepapers/293.jsp#Definition Use Cases

http://www.cs.rit.edu/usr/local/together/help/UserGuide/Chapter3.html

http://www.threesl.com/use_case_diagrams.htm#pucd

http://cui.unige.ch/~queloz/TogetherJ/help/DevGuide/Chapter3.html

And if these links don't satisfy your curiosity (good sign!),
then do a Google search on 'Use Case Diagrams" and
spend the rest of the afternoon getting an education.


--
Michael West
Melbourne, Australia







Previous by Author: RE: The world's most frequently read instructions
Next by Author: Re: the world's most frequently read instructions
Previous by Thread: Font size? (Odd vs. even)
Next by Thread: RE: The case for use cases


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads