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.
I'm just starting to write use cases where I work so I don't have a real "success story" yet (check back in a couple of months <g>).
I am using the book "Writing Effective Use Cases" by Alistair Cockburn as a guide (http://www.usecases.org). I think the greatest value in use cases comes from the extensions, that is, what happens when things go wrong. For example, in the well-worn example of the ATM, the extensions cover such things as the user putting in the wrong access code, the user not having enough funds for the selected transaction, the machine jamming when dispensing money, etc. The use case describes how the system handles each extension to help the user to a successful conclusion. In the case of the money dispenser jamming, a successful conclusion might be a message informing the user of the situation and giving instructions on what to do (i.e. see the branch manager, or whatever). That message would be followed by another message that would indicate that the system was out of service. In the ATM example, a "successful conclusion" does not always mean that the user gets the money. It simply means that if the user cannot accomplish the desired task, that the system gives clear notification of the reasons why and informs the user what to do.
Use cases also serve as a starting point for test cases and for end-user documentation. A good set of use cases for software would include all the scenarios that can happen depending on the user request and the conditions under which the request is made. By writing use cases as part of the requirements gathering process, decisions on how the system will handle all the contingencies are thought our in advance and not left to the programmers to decide on the fly or to miss entirely.
Your programmer is correct in saying that mention of specific screen elements and the wording of the error messages should not be in the use cases.
Sarah
-----Original Message-----
From: Kelly Williamson [mailto:kwcwtech -at- iwaynet -dot- net]
Sent: Monday, October 22, 2001 5:34 PM
To: TECHWR-L
Subject: Use Cases
<<Can anyone provide me with an example of a use case that has actually WORKED
(read: was useful) in Real Life? We have some use cases that were developed
for us, and I, as well as the programmer, am just not finding them useful
whatsoever. The programmer is saying that there is info. in there that
shouldn't be (such as "the user clicks the "Submit" button to submit the
information"--he's saying that's going into the screen design. The use cases
are also spelling out exactly what the error messages should say and he
doesn't like that either.)>>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Announcing new options for IPCC 01, October 24-27 in Santa Fe,
New Mexico: attend the entire event or select a single day.
For details and online registration, visit http://ieeepcs.org/2001
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
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.
