We’ve seen before that you will need to take some vague specifications from the client, and turn them into complete, measurable, traceable and unambiguous requirement specifications. No need to panic; you can make your life easier at this point with a use case report.
A use case is used to define a series of interactions between external actors (the users or another system) and the system in question (your piece of software). The use case always focuses on a goal, and it ends when this goal is completed. Besides the main series of interactions, it can also include alternative versions (other series of interactions that will fulfill the goal) and versions that will cause failure. In the end, it will give you a very clear sequence, written in natural language, easy to understand. You can move on by taking a “snapshot” of a use case, called a scenario – which is one specific instance of the use case – one single path that takes you from the beginning to the end, selected from the various paths and combinations available to fulfill the goal.
Use cases are the basis for creating patterns, or you can organize them into diagrams – in many cases, a better alternative to long text in natural language, or use them in connection with UML – we’ll cover all versions later. They are a good tool to help you keep track of each requirement and its current status.
Once you have a use case, you need to make sure that it is indeed important, not one of the useless conditions that crowd your project, even if nobody can remember where they originated. A very simple and effective method, called Quality Function Deployment (QFD) will help you identify which are the most important options for the client, and which can be eliminated. Give users (or user surrogates) a list of the use cases and a certain number of points (or a sum of cash, to make it even easier to understand) to assign to the use cases, in order of the importance.
Make sure you include all the types of users (every group of actors involved), otherwise it’s not relevant. In some cases, you may need to organize a hierarchy of the groups of actors – for instance, give more points (or cash) to the group that is likely to use the program more often than the rest. Balance the number of points obtained by each function against the costs of developing it. After that, the results are pretty obvious and easy to interpret.
Because the use cases are so focused on the client, they are often turned into help files later on. In fact, this is one of the key aspects of working with them – you actually write the help files and the user documentation before you even started work on the program. It may seem a bit backwards, but it is a great method of insuring the client’s satisfaction, which is, after all, the whole point.
While you are having fun with points and evaluation, don’t lose sight of a major issue: the use cases have to remain testable and traceable, otherwise they are useless.
Pay attention when you write the use cases, and don’t make them too abstract. The client should be able to understand them at all time. If you find yourself using the passive voice, you made a mistake – you need to describe what the user does, and what the reaction of the system is. Do not write from the point of view of the system, but make sure to include its response.
Also, you need to know when to stop – you can’t possibly model all the situations, and you don’t need to, since you can include them, in a form or other, in a use case.
(No Ratings Yet)