2.4 Use Cases Apply Here

Use cases apply to a wide range of activities and not only to requirements gathering. In this section we look at the application of use cases in a couple of areas that you might not have thought of. Also, in Chapter 8 we show how use cases apply to other activities in the lifecycle.

2.4.1 Use Cases for Inquiry-Only Systems

Use cases make sense for any system that has interactions with the outside world. It is not outrageous to say that any computer system should interact with the outside world. The most common application of use cases occurs in transaction-processing systems. However, inquiry-only systems, such as data warehouses, are also good candidates for use case requirements gathering.

There are a few caveats. Inquiry-only use cases are usually more abstract than transaction-processing use cases. Data warehouses are built to offer users flexible interfaces that can provide multiple views of volumes of data. This flexibility means that the users' actual interactions may not be well known at the time of requirements gathering. However, at an abstract level, the interactions are quite clear. As with transaction processing, documenting the actors for a use case for inquiry-only systems is very useful. You always need to know your audience!

2.4.2 Use Cases for Requests for Proposals

Requests for proposals (RFPs) are often used between a customer and a contractor. The customer issues an RFP to multiple contractors, the contractors bid to win the business by submitting proposals, and the customer picks a winner based on the compliance of the responses to the RFP.

RFPs can be tricky business for the customer and for the contractors. Especially with government work, the RFP for a computer system must be complete and unambiguous because the requirements that are itemized in it become the foundation for the creation of the system. Requirements lists are often used in RFPs, and because everyone is worried about legality and wants to avoid missing anything, these requirements lists can sometimes run hundreds of pages.

We suggest that you employ use cases for RFPs. If the customer were to create a set of use cases and scenarios in the RFP, the contractors could respond more easily and the solution would more likely reflect the business needs. Use cases can simplify RFPs and proposal responses in the same way that use cases simplify requirements for other types of systems requirements specifications.

2.4.3 Use Cases for Software Package Evaluation

Use cases have special applicability to software package evaluation efforts. Use cases can help clarify the "gap analysis" by comparing package functionality to business requirements. We have used this approach and have seen it used elsewhere with great success.

2.4.4 Use Cases for Non-Object-Oriented Systems

There is a predisposition in our industry to associate use cases with object-oriented systems. We believe that use cases can be used easily for non-object-oriented systems, and our experiences bear this out. Our use cases have been used to document requirements for a number of non-object-oriented systems.

The fact that use cases are part of the UML encourages the viewpoint that use cases are exclusively for object-oriented systems. However, we view use cases as a great way to document requirements for any system. In fact, we use them not only for system development efforts but also for evaluations and package implementation. Use cases are a good way to boil down the essential requirements of the required interactions, whether they are used for a new system being built or to help someone make a choice between packages that already exist.