From Business Event to BUC

Volere contains a structure for discovering and tracking requirements at several different levels. The previous article in this series “Work Scope and Product Scope – Why Both?” covers the difference between the Work/Business/Problem Scope and the Product/Solution/System Scope. This article covers the connection between the Work and the next level of detail: The Business Events and the Business Use Cases.

Where do Business Use Cases Come From?

When something happens and it places a demand on a piece of work, the happening is referred to as a Business Event. The pre-planned response of the work to the business event is called a business use case or (BUC). We will use the library loans case study (introduced in the second article in this series) to illustrate the tracing from the Work Scope to the Business Events to the BUCs.

Work Scope to Business Events

The following (Figure 1) is a diagram identifying the Work Scope for The Work of Managing Library Loans. 

Figure 1: This diagram defines the scope of the Work/Business/Problem

The diagram identifies the sources and destinations of the input and output data that is relevant to the business being studied. It is important to remember that this is the scope of a work/business/problem study. Inside the work there are people, machines, computers, departments and so on. These carry out the processes necessary to respond to the inputs, accessing and storing information and producing the outputs. Note that most of the inputs and outputs are composed of data. They might also contain material (as in the case of New Book Delivery that contain a physical book along with information about the book.

Even in a small example, such as the one we are using here, the complexity inside the work makes it difficult to investigate and define all the business processes and requirements simultaneously. There is a need for a consistent way of partitioning the work into business-related pieces. That is the purpose of the Business Event as illustrated in the following Business Event List (Figure 2).

Figure 2: The Business Event List partitions the Work/Business/Problem into functionally cohesive pieces.

Business Events to BUCs

Each of the Business Events is bounded by its related input and/or outputs. For example whenever Business Event 2 Borrower wants to extend loan happens then a Loan Extension Request comes from the Borrower to the Work of Managing Library Loans. The relevant people/machines/software inside the work carry out the pre-planned response and the relevant outputs Loan Extension Approval, Refused Loan Extension are communicated to the Borrower.

How do we know the details of what goes on inside the work and when and under what conditions the outputs are produced? This next level of detail is defined in the BUC.

Note, to ensure traceability, the names of the inputs and outputs on the event list are exactly the same as those on the Work Scope diagram (Figure 1). The pre-planned response to a business event is called the Business Use Case or BUC. There is a BUC for each one of the business events and each of the inputs and outputs on the Work Scope diagram is related to a business event.

Defining the BUC details

Provided, as you go into detail, you deal with the declared scope (defined by the inputs and outputs) you can use a variety of techniques to specify the details of the Business Use Case. Some common ways of specifying BUCs are business process models, activity diagrams, sequence diagrams, dataflow diagrams and scenarios.

The way you decide to specify a BUC is driven by the characteristics of stakeholders from whom you need input. For example if your business stakeholders are engineers then they will likely respond well to some kind of model. If your business stakeholders are administrative or clerical workers then a scenario written in their everyday language is likely to be a better way of communicating.

BUC Scenario for Business Event 2: Borrower wants to extend loan

Figure 3: is an example of a scenario for BUC 2: Decide on loan extension.

Note that BUC 2:Decide on loan extension is the response to Business Event 2: Borrower wants to extend loan.  Consistent numbering along with consistent data naming provides the traceability from the BUC to the Business Event back to the Work Scope.

The names used on the Work Scope on the Business Event List and on the BUCs are eventually defined in the data dictionary, for example:

Summary

This third article in the series illustrates how to take the highest level of the requirements, the Work Scope, and how to go down to the next level of detail using Business Events and Business Use Cases (BUCs). In future articles in this series we will look at how Business Use Cases (BUCs) and Product Use Cases (PUCs) are linked to each other and how both are linked to the atomic detailed functional and non-functional requirements.

Note that the Volere Requirements Template provides more guidance for structuring all levels of requirements-related knowledge.