By: Joe Goss
Requirements take many forms. The International Institute of Business Analysis’ (IIBA), Business Analysis Body of Knowledge (BABOK), describes a requirement as a “usable representation of a need.”1 There are numerous business analysis models that can be used to represent requirements.2
In practice, business analysts and project managers often represent requirements as a set of unary, declarative statements. Think of sentences starting with the words, “The system shall…” Each of these requirement statements becomes a single, fixed point on a large canvas meant to represent functional and non-functional needs. Unfortunately, this narrow practice leaves a significant gap in a requirements specification. I like to think of these requirement statements as dots of paint on a landscape created by an Impressionist painter – “Haystacks” by Claude Monet, for example.
Process flow or swim lane diagrams give a critical context to the set of declarative requirements. We might think of the haystack in this picture as a collection of unary, declarative requirements about an IT system – its structure and its data. Such requirements are often static – they do not describe how data in the system was collected, stored, or retrieved, or who was involved. Declarative requirements do not tell us what caused the data to be gathered, how it’s utilized, or why it’s important.
Where Process Modeling Comes In
Process modeling can help close these gaps. BABOK describes a functional requirement as a “capability that a solution must have in terms of the behavior and information the solution will manage.” While declarative requirement statements may capture the “information the solution will manage,” they don’t capture the behavior.
Process Modeling in Action
Some years ago, I was asked to assist with an implementation project for an enterprise-scale customer relationship management (CRM) system. A vendor product had been chosen based upon summary-level, declarative requirements. Unfortunately, there was no consideration for the organization’s current operation processes – the behavior the target system must manage.
Process flow diagrams helped them understand current business operations – who did what and in what sequence. The process flows also identified the flow of data to and from homegrown IT systems, file cabinets, and desk drawers. With direct involvement of the organization’s operations staff, I developed roughly 100 “current state” process flows. This documentation was vital to the implementation team, as they worked to understand precisely how the new enterprise CRM system would affect the business. They could see how roles and responsibilities might change, how the new technology would affect current processes, and how to eliminate wasteful work and information silos.
For many years now I have been capturing operational requirements using process flow diagrams in every project I lead. I use Business Process Modeling and Notation (BPMN), standardized by the Object Management Group. Stakeholders appreciate seeing each complex operational process documented on a single letter-size page. Using a half-dozen basic symbols, complex processes are readily understood by everyone, including upper management.
I particularly value BPMN because the nomenclature makes clear:
- Process triggers
- Actors and their activities
- Alternative and exception paths
- Handoffs between roles
- Errors, delays, and interventions
- Interactions with technology
- Process outcomes
These BPMN features can be combined to produce high value by:
- Helping stakeholders reach agreement on process steps
- Improving understanding of a complex process
- Documenting “current state” processes
- Designing “future state” processes
- Understanding who is responsible for what
- Revealing process waste, as well as unneeded handoffs and non-value-add activities
- Highlighting the “critical path”
- Defining the business rules that constrain behavior
Business Process Modeling and Notation is a significant addition to my toolkit for business analysis and project management work. While the nomenclature is fairly easy to learn, in-person training with hands-on activities, interactive labs, and instructor guidance brings many benefits. With support from an expert who shares his experience, short cuts, and tips, you too can quickly become fluent and productive with this powerful modeling tool.
1Business Analysis Body of Knowledge®, version 3.0, p. 450; International Institute of Business Analysis
2See Visual Models for Software Requirements by Joy Beatty and Anthony Chen
About the Instructor: Joe Goss
Joe is a senior business analyst and project manager at the University of Wisconsin–Madison Division of Information Technology (DoIT). Joe’s background includes significant work in providing solutions to public and private organizations in sectors including agriculture, accounting, education, manufacturing, retail, public housing, law enforcement, judicial courts, public health, and natural resources. Over a 35-year career, he served clients while employed at several software development companies, a regional accounting and consulting firm, and an international computer vendor, in addition to his work as an independent consultant.