Use cases are becoming more mainstream as a method for capturing requirements, as evidenced by the endorsement of big companies and methodologists such as Booch, Rumbaugh, and Coad. One benefit of use cases is that each one encapsulates a set of requirements. This encapsulation lets you easily manage and track the use cases individually and provides a better alternative to prose requirements.
There is more to effectively using use cases than just capturing them and putting them into diagrams. As you implement use cases, you need to validate them, determine their size, and establish a plan for implementation. Then, you need to incorporate the use cases into your system design and turn them into code and documentation. Throughout this process, you must also be aware of the status of each use case. This article will discuss ways to do all these things.
Validating Requirements with Use Cases
Once you’ve captured a use case, you need to confirm whether it accurately describes the system and is truly needed by the system’s users. Sometimes, in the course of development, you realize some of the requirements you’ve created are unnecessary or peripheral to the main purpose of the system. You must identify these as soon as possible, so you can work on the functionality that is the most valuable to the customer. But how do you determine which use cases are most important to your users? You use a method called Quality Function Deployment (QFD).
QFD helps you weigh use cases to determine which ones are important and which can be discarded. To use QFD, users representing each group in the actor catalog are given a list of the abstract use cases and $100 in virtual cash to spend on the ones they think are the most important. The amounts are then tallied to determine which features are the most desired.
When using QFD, it’s important to keep one caveat in mind: make sure you include on the list all the obvious features the users will expect in the system, because it’s very likely these features will not come up while you’re gathering use cases. For example, in the banking program, users would obviously require a “transfer funds” use case. However, because they expect this feature to exist, they might not consider it important and not allocate funds for it. It’s important to allow for this and include the basic functions of the system into the QFD.
Because use cases describe functionality from the user’s point of view, they can be directly converted to function points. Assigning function points to use cases helps us understand how large a use case is and the associ