Trawling and Business Use Cases

Business use cases are so fundamental to the requirements activity that we urge you, whatever your situation or project type, to consider doing your requirements trawling one business use case at a time. If you have not already read Chapter 4, Event-Driven Use Cases, we encourage you to do so now.

When trawling, you have to understand the work currently being done, and determine the work that stakeholders desire to do in the future. Once you understand the work, you can help the stakeholders reach a consensus on how much of that work should be automated. You then write the requirements for the automated product.

The trawling activity uses outputs from the project blastoff activity. The blastoff determines the scope of the work, the goals of the project, and the constraints that apply to any solution. It also identifies the stakeholders involved in the project and the potential users. Naturally, you need to know whom to interview and study to get an understanding of the work.

From the work context diagram, you determine the business events and the resulting business use cases. In Chapter 4, we discussed business events, exploring how happenings outside the work cause a response inside the work. This response is a business use case, and we suggest that you do your requirements analysis one business use case at a time.

The business use case is what the work does in response to a business event. Note that we remain concerned with the work for now, so we are not thinking about the product yet. From the moment the triggering data flow enters the work, the functionality within the work starts to process it. If the triggering data flow arrives via a telephone call, then a person might be there to answer it. Alternatively, an automated telephone system might prompt the caller to identify the nature of the call. But it doesn't matter what or who does it; what matters is what is done. This functionality is what you study when trawling, as is illustrated in Figure 5.2.

Figure 5.2.

Business events are determined using the flows from the adjacent systems on the context diagram. The business use cases are the work's responses to the business events. These are studied until the analyst understands the desired functionality of the work and the part of that functionality to be performed by the product.

The trawling activity entails both a study of the work and improvements to that work. Reflecting this dual nature, you write the requirements for the product once you have achieved a consensus on what the product is to do. Let's look at the trawling techniques available to the requirements analyst.