The Business Use Case

Use cases are an indispensible tool for capturing the behavioral requirements of a software product and many analysts employ them exclusively for that purpose. But use cases can also help describe the interaction between external entities and a business. And, there are some very good reasons to develop the business use cases that describe the business to be supported by your product.

The actors for business use cases are the suppliers and customers of the business. Money flows from the customers to the business and from the business to the suppliers. Customers exchange money for the ‘result of value’ that is the outcome of a business use case. For suppliers the result of value is the money they receive for delivering materials or services to the business.

One way to identify business use cases is to look for ‘business events’. The business reacts to things that happen in its external environment. One of the most obvious and important events is when a customer signals an intention to buy. Other events include: a customer submitting a payment or a supplier delivering a shipment. The business use case describes the step by step interaction between the actor and the business in much the same way a ‘product’ use case describes the interaction between an actor and the software product.

The real value of a business use case is that it allows (or forces) you to step back from your focus on the product and ask questions about what is happening from a business perspective when an event takes place. Software development projects are commonly initiated after a decision has been made to implement a software product. That makes sense. But, it can be a mistake to just accept a list of desired features or other artifacts as given. If you limit your focus to identifying the requirements of the product you eliminate the possibility of finding innovative ways to change the business.

Your project may be strictly defined by a project charter that does not allow for much business process innovation but if possible, spend some time upfront writing business use cases for the business process area your product will support. Think about the real problem to be solved or the opportunity to be captured. Document the business event that triggers each use case and the goal of the actor. Look for innovative ways for technology to deliver the desired result of value. Then, derive the product use cases and requirements from the business use cases.

Here’s an example of how this can work: One of the features desired for an accounts payable system was the ability to automatically match purchase orders with invoices before making payments to suppliers. Rather than write a product use case for invoice matching, the product team explored the business events and the goals of the actors. They were able to show that the supplier’s goal of getting paid and the business’s goal of paying only for what was ordered and received could be met by issuing payments to suppliers based on matching what was received with what was ordered. The business was able to negotiate cost savings with suppliers and no longer need to process invoices.