RE: Use Cases - NEED INPUT - PLEASE HELP

["Kathleen" <keamac -at- cox -dot- net>]

Kudos to Dick for taking the time to give an overview of something I've
wondered about for quite a while. I had a general idea, but you've
provided a much better idea, Dick. Thanks

Kathleen

-----Original Message-----
From: Dick Margulis
Sent: Thursday, July 07, 2005 6:24 PM
To: TECHWR-L
Cc: TECHWR-L
Subject: Re: Use Cases - NEED INPUT - PLEASE HELP
Anthony wrote:

> Can anyone explain the authoring and preparation of
> use cases and the process of putting one together?
> 
> This will be done in a software development
> environment for an ERP product.
> 
> Thank you for your input.
> 
> - Tony
> 

Tony,

Here's the basic idea, on which I'm sure others will elaborate. From the

point of view of a software developer, a system consists of features 
that have to be implemented. This widget does this; isn't it cool? That 
widget does this other thing; that's cool, too, right? Developers, left 
to their own devices, will create cool widgets all day long, with no 
clue what the customer is going to use the software for.

But from the point of view of the user, widgets aren't cool at all. 
What's cool is getting the job done quickly and easily. So the basic 
idea behind use cases is to inform the _design_ of the software with the

_uses_ to which it will be put. This very much parallels the distinction

between feature-based user documentation and function-based user 
documentation.

The archetype of feature-based documentation is the original DOS manual,

which listed every DOS command in alphabetical order and laid out the 
syntax but really didn't tell you why you might want to use the command 
(although it was pretty easy to figure that out if you were already a 
programmer). What we've learned over the years is that feature-based 
documentation doesn't really serve the user's needs.

Function-based documentation tells the user, "To accomplish this task," 
adding a new customer to the customer database, for example, "do these 
steps."

What use cases do is push this way of thinking back to the design 
phase--actually back before that to the functional specification phase.

Here is one use case scenario:

Marty is a user. Marty's role in the company is order taker. Marty has 
to access the customer's account information and ensure that the 
customer is not in arrears before proceeding to take the order. Marty 
has to verify that the customer contact information has not changed. 
Marty has to walk through the customer's store, scan a shelf tag for 
each item or scan the item itself if the shelf tag is missing, enter the

quantity remaining for each item scanned, and have a way to indicate 
when all items have been scanned. Then Marty needs the system to 
generate a recommended order, with items grouped according to the way 
the store has its aisles organized and with quantities based on the 
item's disappearance rate in the store, seasonal considerations, 
promotion schedules, availability of new items in the same line, and 
other factors. Marty then needs to review the recommended order with the

manager and change quantities interactively. Finally Marty needs to 
capture the manager's signature on the edited order and submit it to the

warehouse for picking.

Now there may be several other kinds of transactions that Marty has to 
be able to do. And there certainly are many other roles in the company 
that interact with the system. So you can see that there are lots of 
scenarios.

But note that nothing above says what any given software module has to 
be able to do. Instead, the requirements for any given module will 
derive from the totality of use cases.

So your assignment, should you choose to accept it, is to systematically

analyze the roles in the company and the transactions each role is 
involved in, then create a use case for each such role and transaction.

This tape will self-destruct in 30 seconds, before anyone says DFD, I
hope.




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l

Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author 
content and configure Help in MS Word or any HTML editor. No 
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.