Whatever it is you are working on, it is almost certainly made up of many, sometimes very many, pieces. Each of the pieces interacts with other pieces to achieve some valuable result. This means that there is a need to organise all the pieces so that you and your colleagues can work on relevant slices of the larger problem, and at the same time keep track of how the smaller pieces work together within each slice. The Business Event is the best tool we have been able to find to help you do this.
What is a Business Event?
A business event is something that happens, and when it happens it causes a pre-planned response by part of the business, or as we shall call it here, “the work”. The work can be carried out by any combination of human procedures and/or automated technology.
One category of business events are the things that happen inside an adjacent system. An adjacent system might be a person, department, piece of technology or anything else that is the source of a business event. When the business event happens, the appropriate piece of the work is made aware because each happening produces a flow of data from the adjacent system to the work. A business event is a significant happening – it is not just a mouse click. It is often a request for a service that your business provides, and the outcome is the provision of the service or product.
For example, Figure 1 illustrates the business event Customer makes an order. The adjacent system, in this case the Customer, is where the event happens. The data flow (caused by the event) is the Customer Order. This flow is usually called the “triggering data flow” because it triggers a response by the work. In this case, if you look inside the work, the response would be something like - fill the customer’s order, create the invoice, record the order and invoice and send the goods and the invoice to the customer. All this would be done according to the work’s business rules. Note that these business rules might be carried out by people, technology or a combination of the two. The business event response helps focus on all the work that the business needs to carry out to respond to the business event. This approach uncovers all the business rules – not just the rules that are implemented with software.
Keeping Track of the Business Events
Whenever a new business event is confirmed to be relevant to the scope of the work, the business analyst keeps track by adding the event to the work context diagram. Figure 1 showed a work context diagram that only includes one Business Event: Customer makes an order. In Figure 2 there is an additional business event, Customer decides to make a payment. You can see the additional flows for this event on the diagram.
Every time you discover a new business event, and it is agreed to be within the scope of the work that you are studying, you add it to the work context diagram. We are using data flow notation as a convenient way of identifying the scope of the work. Each business event represents a bounded chunk of functionality that you can study independently of the other events while keeping track of how the individual events fit into the whole. As the number of business events increases an event list (illustrated in Figure 3) helps you to manage and prioritise your investigation. Naturally enough, your list of events would be considerably longer.
| Event Number | Event Name | Input | Output(s) |
|---|---|---|---|
| 1 | Customer makes an order | Customer Order | Delivered Goods + Invoice |
| 2 | Customer decides to make a payment | Customer Payment | Receipt for Payment |
A business event triggers a significant and independent chunk of functionality that can be prioritised so that you are always working on the events that yield the greatest value. Business events also help to organise your investigation. You can apportion the events among your team, and due to the independence of the events, there is not a lot of need for team members to have excessive interaction.
Working with an agile development team
Business events are highly effective for agile teams. The response to a business event, is a stand-alone chunk of the work with a well-defined outcome. It also has well-defined input and outputs. This makes it not only a convenient unit to study and find its requirements, but also a sensible unit to develop.
Figure 4 illustrates this approach. The scope of the work is determined by the collection of business events - our previous example looked at two business events. For each of your business events, we advocate writing a business event story. This is a story in the conventional sense of role-function-outcome. More on this later.
For each business event story the business analyst, product owner and developers, can define the details of the response to the business event by writing a number of functional stories. These represent a breakdown of the functionality. They can be further broken down by the developers by writing the detailed tasks necessary to implement the functional story.
Figure 5 illustrates the thinking behind a traceable technique for deriving the Business Event Story for a Business Event. Focus on a Business Event from your work context diagram – we have used Event 2; Customer decides to make a payment – and annotated it to show how to derive the Business Event Story.
The resulting Business Story is:
- As a Customer
- I can make a Payment
- So that my Supplier can record my Payment and give me a Receipt
Continuing with this approach, the business analysts, product owner and developers can work together to derive the Functional Stories from the Business Story. They would ask the question: what are the functions that the product we plan to build will need to carry out to support this Business Story? In this example the Functional Stories derived from this Business Story would be something like Locate Customer Account, Record Payment, Issue Receipt.
The developers can now derive all the detailed tasks necessary to implement each Functional Story. If there are changes or questions to either the Business Story or the Functional Stories, business analysts, product owners and developers have a common communication language.
Other sources of information about subjects discussed in the article:
Business Analysis Agility: Delivering Value Not Just Software amzn.to/2CnVhTN Video youtu.be/l_9u5UI12uo
Reviews on many books by authors who continue to enrich the field of requirements and business analysis at volere.org/resources/books
Or on the Volere Requirements LinkedIn group linkedin.com/e/vgh/2491512
Suzanne Robertson and James Robertson are principals and founders of The Atlantic Systems Guild systemsguild.com and joint originators of the Volere requirements process, template, checklists and techniques volere.org
You can contact the authors at
suzanne@systemsguild.net
james@systemsguild.net
Suzanne Robertson is having a stellar career in information technology and systems engineering. Suzanne is a pioneer in adapting ideas from other domains for automated solutions. She has collaborated in workshops using experts from fields as diverse as modern music, visualization, and cookery. Ideas from these domains were adapted to make major breakthroughs in creative ideas for domains ranging from air traffic control to local government. She is co-author of the best-selling Mastering the Requirements Process, among other books and courses. She is co-creator of the Volere requirements techniques. She was the founding editor of the Requirements Column in IEEE Software.
As a principal and founder of The Atlantic Systems Guild, James Robertson is known for his work in implementing systems engineering principles that link business specialists with solution specialists. James is a consultant, lecturer, author, project leader whose area of concern is the requirements for software, and the contribution that good business analysis makes to successful projects. James is co-author of 5 books that have been influential in the business analysis world. His training as an architect has led to his work on good design principles and to his focus on how innovation can be integrated with business analysis.