Have you ever put the finishing touches on your use case in a word document only to find that the visio diagram you had depicting the process flow is now out of date? If you are lucky, you have both some visual model of your functional flows along with the corresponding text to back it up – and let’s not forget about the corresponding test cases!
Have you ever put the finishing touches on your use case in a word document only to find that the visio diagram you had depicting the process flow is now out of date? If you are lucky, you have both some visual model of your functional flows along with the corresponding text to back it up – and let’s not forget about the corresponding test cases!
In the fast paced world of software development, if you don’t have solid processes in place and have a team that follows it, you might find yourself “out of sync” on a regular basis. The industry numbers such as “30% of all project work is considered to be rework… and 70% of that rework can be attributed to requirements (incorrect, incomplete, changing, etc.)” start to become a reality as you struggle to keep your teams in sync.
The practice of using “Use Cases” in document form through a standard template was a significant improvement in promoting reuse, consistency and best practices. However, a written use case in document form is subject to many potential downfalls.
Let’s look at the following template, courtesy of the International Institute of Business Analysis (IIBA) St. Louis Chapter:
Skip past the cover page, table of contents, revision history, approvals and the list of use cases (already sounds tedious right?) Let’s look at the components of the use case template:
The core structure is based on a feature, the corresponding model (visualization) and the use case (text description). This should be done for every core feature of your application and depending on the size of your project, this document could become quite large.
The use case itself is comprised of a header which has the use case ID, use case name, who created it and when as well as who last modified it and when. As you can see, we haven’t even gotten to the meat of the use case and we already have a lot of implied work to maintain this document so you need to make sure you have a good document repository and a good change management process!
Here is a list of the recommended data that should be captured for each use case:
- Actors
- Description
- Trigger
- Preconditions
- Postconditions
- Normal flow
- Alternative flows
- Exceptions
- Includes
- Frequency of use
- Special requirements
- Assumptions
- Notes and issues
The problem with doing this in textual format is that you lose the context of where you are in the process flow. Surely there must be a better way? By combining a visual approach with the text using the visual model as the focus, you will be able to save time by modeling only to the level of detail necessary, validate that you have covered all the possible regular and alternative flows and most importantly, you will capture key items within the context of the use case steps making it much easier to look at the entire process or individual levels of detail as needed.
If you look through the template example, you can quickly see that it is a manual process that you cannot validate without visual inspection, so it is subject to human error. Also, it is riddled with “rework” since you have to reference previous steps in the different data field boxes to make sense of everything.
Here is a visual depiction of the example provided in the template. I have actually broken the example into two use cases in order to minimize required testing by simply reusing the common features:
Access and Main Menu
ATM Withdraw Cash
I have added some colorful swim lanes to break the activity steps down into logic groupings. If you think the visualizations look complicated you might be right… they say a picture says a thousand words, so what you have done is taken the thousand words from the use case with all of the variations and you have put them into one visual diagram! The good news is, it is surprisingly easy to create these diagrams and to translate all of the required data from the use case template directly into this model. A majority of the complexities of the use case are handled automatically for you. When it comes time for changes, you no longer have to worry about keeping your model in sync with your text details and you certainly no longer have to worry about keeping references to steps and other parts of the use case document in agreement!
In the next blog, we’ll look at how to model the “Normal flow” described in the use case template.
