TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
simple.
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.
www.ehelp.com/techwr
---
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.
