When a Use Case in no longer a Use Case

Subject: When a Use Case in no longer a Use Case
From: hannah <to -dot- hannah -at- usa -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 08 Mar 2002 12:21:13 -0500

When I was first hired I was given a task of learning about and creating Use
Cases for our applications. I had never heard of them before, but brought
myself up to speed fairly quickly. About the time I did this I started to
realise that what the client (the government) was calling Use Cases, really
aren't. They started out that way, but have somehow been mutated.

I would like to stop calling them Use Cases. When other developers come onto a
project and they see these "Use Cases" they become completely confused by what
they see. I basically have to go through a process of convincing them to not
think of them as Use Cases. Now the client is looking to bring me onto
different projects and teams because they are very happy with my work. I don't
want the client to bring me onto new teams and tell them I'm going to write
their Use Cases when I'm really writing something a bit different. A major
plus is that they will listen to me if I say "these are not Use Cases they are
XX", so changing the name now (before I get in too deep) will be relatively

Let me describe the docs and perhaps someone can give me a better title. I
haven't been in this too long and appreciate the help.

The documents are all written as if they were written before the project was
even started but never have been. Oh - wait, there was one module that I
actually was able to write them up before the building started. That's a big
exception - it is almost always done after the fact. (Part of this is because
they went so long without any tech writer. Now that they have what they see as
ideal documentation for our projects they want to bring me onto more and more
projects that right now have unacceptable or no documentation, even though the
projects are pretty far along in development. It amazes me how backwards
things sometimes seem to work around here.) Anyway, the documents include
information typically seen in Use Cases (primary actor, frequency,
pre-conditions, success guarantees, super and sub use cases, trigger events,
event flow, exceptions, release information, etc.) They also include a final
section that basically describes the appearance of the section in question.
This part is pretty detailed, including layout, colors, and that sort of
stuff. As the project evolves (because the client is changing needs, requests,
and requirements before even a preliminary review is done), the documents are
updated to reflect the changes. I keep on file a copy of the document as
originally written as well as it is at any of the major milestones.

Suggestions are greatly appreciated,

hannah Bissell
to -dot- hannah -at- usa -dot- net

Check it out! Get some cool freebies when you buy RoboHelp! You'll receive
SnagIt screen capture software and a 10% discount voucher for RoboHelp
Consulting. This special offers expires March 29, 2002.
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.

Previous by Author: Re: [How Much Editing of Graphics Do You Do?]
Next by Author: Re: [Reference books you use the most]
Previous by Thread: Ranges in index entries?
Next by Thread: Re: When a Use Case in no longer a Use Case

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

Sponsored Ads