Another new addition to our arsenal of templates! The use case description!
What is a use case description?
I'm glad you asked!
What is a Use Case Description
The use case description template was created to provide a written version of a typical workflow. The individuals we worked with were struggling with implementing workflows using Visio, as many of the recipients of these documents didn't understand UML, and didn't care to learn it.
Now, now, before you ask what dumb fuck can't understand UML, since it's literally just like, boxes and shit, let the man explain:
"Hey guys, so, I work closely with managers who are all in their late 50s to mid-60s. They embody the stereotypical "technology is dark magic" boomer you would expect to see in a shitty WB sitcom. I tried using Visio for our workflows, which our dev team loves, but we can't get sign-off from the managers, because they can't figure out what they are looking at. It's created a choke point early on in development. I started using Excel to create a step-by-step workflow document, but it's becoming more difficult to ensure that everything is included since they still have a ton of stupid questions when looking at my template. Do you have any suggestions? Sincerely, What's the use-case."
Ok, we added the "sincerely" portion, to make it sound more like Dear Abby.
We had our dear reader send us over some of the questions they had, looked into what other organizations are doing, read more than our fair share of journal articles, and decided that this document would best serve the purpose of the request.
While there are many reasons you might use this, it does become very text heavy, so we don't recommend it for use by developers, but those on the business side, as well as testers, can probably benefit from this document.
Let's dive into it.
The Use Case Description Template
Unlike a typical UML workflow that many would use, the description is a lot more informative. In the header, we are capturing significantly more detail that any other template we've offered up. Key fields that should be called out include the use case ID, end objective, version number, user/actor, trigger, and frequency of use.
Use Case ID
Let's talk about the use case ID. When we developed this, we suggested to our reader that he use a combination of a unique identifier, paired with the project ID number. So, if the project ID was "PD-0123," you could tack on a unique ID to the end of it like "UC-01," giving you a final use case ID of "PD-0123-UC01." The reason for this is evident in the "Includes or Extension Points" section, as well as part of the flow tables.
End Objective
Your end objective describes what the end state should be, once the user has followed the use case/workflow. Not the end goal of the project. That is if you were to follow the workflow laid out, what should the system look like/its status?
Version Number
Because you will be getting sign-off on this work from the management, it is important to keep a running version number, so you are aware of the most updated version. Pretty straightforward, yeah?
User/Actor
This is where you would document who would be following this particular workflow.
Trigger
This field covers what happens that actually kickstarts this particular workflow. This could be another use case ID document or a preexisting condition that would not be documented in a workflow, like an incoming call.
Frequency of Use
Why is this important? Well, it allows the reader to be able to ascertain if this is a typical workflow, or if it only occurs under extremely specific circumstances.
The Closing Sections
We will skip over the workflow tables to quickly cover the sections at the end of the document. In it, you will find a quick explanation of what we are looking to capture.
There are things to consider when filling in this information. If your use cases include multiple documents (ie, multiple use case descriptions) you should include those here as well. IDs that should be marked as "Included" should be those that are called as part of this current document. That is, if you split your created a unique use case document that covered signing in (so that it could be used for multiple projects) then that use case ID should be added as included.
Extension points, by contrast, are when there are specific conditions that would add a new or updated goal and steps of the use case.
Workflows
We're all professionals here, I don't need to tell you how to create a workflow, so I won't go into a ton of detail, other than to explore quickly what each flow represents.
Basic Flow
The basic flow covers your "happy path." Basically, how should this actually work.
Alternate Flow
This should cover any flows that might occur as a result of following the basic flow, e.g., sometimes the client gets possessed by the spirit of Carmen Miranda, kicking off alternate flow one. Note there can be multiple alternate flows.
Exception Flow
Think of this as what happens if the basic flow fails. When something goes wrong at any step of the process, what workflow should happen?
Should You Use a Use Case Description
It's really up to you to decide. As with all of the documents we provide as templates, we would like to stress that nothing we say absolutely 100% must be followed verbatim. Change it up and make it work for you. If you download the document and feel that it is a lot more detailed than you would need in your organization, then don't use it... simple.
What is the most important thing to identify is what you need and why. You might find this document, or a variation of it, would greatly benefit a single stakeholder, and that is reason enough to use it. Or you might decide that it would be cheaper to have a UML training session and just stick with Visio.
Comments