02-09-2015 Door: Suzanne Robertson & James Robertson

From Business Event to BUC

Deel dit bericht

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).


Event Name




Borrower chooses book

- Chosen Book

- Book Loan Agreement


Borrower wants to extend loan

- Loan Extension Request

- Loan Extension Approval

- Refused Loan Extension


Publisher has new book available

- New Book Availability

- New Book Order


Publisher delivers new book

- New Book Delivery

- New Book Details

- New Book Enquiry


Time to pay for new books

- None

- New Book Payment

- New Book Payment Confirmation

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

Business Event 2: Borrower wants to extend loan

Business Use Case: Decide on loan extension

Trigger: Loan Extension Request

Preconditions: The Borrower must have an existing loan for the book in question

Interested Stakeholders: Chief Librarian, Other Libraries, Auditors

Active Stakeholders: Duty Librarian, Borrower

- The Borrower gives the Loan Extension Request to the duty librarian.

- The librarian finds the book loan agreement for the requested extension.

- The librarian finds any other books that are currently loaned to the borrower.

- If the due return date on each of the books is later than today’s date


  the librarian tells the borrower there is a loan extension approval

  the librarian records the loan extension


  the librarian tells the borrower there is a refused loan extension

  the librarian records the refused extension

  the librarian asks the borrower to return the overdue books

Outcome: The decision on book loan extension is made and the borrower is informed.

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:

Loan Extension Request

Request from borrower to extend an existing loan

Borrower Id + Book Id + Extension Request Date


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.





Suzanne Robertson & James Robertson

Suzanne Robertson en James Robertson zijn oprichters van The Atlantic Systems Guild, een denktank die bekend staat om zijn vernieuwende technieken op het gebied van systems engineering, en zijn gezamenlijk de grondleggers van de Volere requirements methode, template, checklists en technieken. James verzorgde jaren lang verscheidene trainingen bij Adept Events op gebied van business analyse en requirements engineering.

Alle blogs van deze auteur