Login
Requirements Chaos
Business Systems Analysis in many organizations is time consuming, resource intensive and fraught with disconnects and misconceptions that typically propagate through subsequent phases of a project.
Business end users, subject matter experts and other stakeholders have differing and often conflicting definitions of requirements within the same business space. Analysts are under pressure to "get" the requirements quickly and "get it right".
Frequently, the hand-off to the solutions team is a vague set of ambiguous text based requirements that are subject to a wide range of interpretation. Solutions architects and developers are under pressure to "get" the solution configured (for vendor products) and/or "get" the requirements coded and into production quickly.
The result is that solution architects and developers, because of time pressure, often interpret vague and ambiguous requirements from the perspective of minimizing configuration, development and implementation time.
The chaos associated with identifying, analyzing and specifying requirements often results in missed opportunities for improving business processes, costly systems (internally developed or vendor solutions) that often do not adequately support business and user requirements - and require substantial and costly on-going maintenance.
Model Driven Analysis – Shifting from Analog to Digital Analysis
Getting the requirements right is tough. I've been doing this work for many years, and organizations have been struggling with requirements for as long as I can remember. There are some core problems related to analysis that have been persistent for years. One of these core problems is what I refer to as “superficial analysis.”
Superficial analysis is analysis that just scratches the surface of the business domain space being analyzed. Unfortunately, a lot of business and systems analysis efforts live at the level of superficial analysis. Superficial analysis manifests in not asking the right kinds of business questions at deep enough levels of precision to obtain the right kind of detail necessary to identify, analyze and specify the requirements of the business space - it's just that simple.
In far too many analysis initiatives, analysts ask very superficial questions. Even experienced analysts can fall into this trap if the right kinds of business questions are not being asked at the levels of precision that we need in order to hold end users accountable. This results in end users not being fully engaged, so analysts are not extracting deep business information.
Far too often, analysts ask superficial questions and receive superficial answers that result in superficial requirements, usually captured and presented in the form of a text-based bullet list, an indented outline (the 1.2a.1 type of list), or some type of verbose narrative tome. I refer to these text based capture and presentation approaches as “analog requirements.”
If you give a bullet list, indented outline or even a short narrative paragraph to 10 business end-users, 10 business systems analysts and 10 developers, the result will be 30 different interpretations. Text-based “analog” requirements cannot convey the depth and clarity to support deep business analysis. In many cases, production rollout is the first time that deep discovery and analysis occurs, which is clearly the wrong time to be doing deep discovery and analysis.
Model driven “digital” analysis (my term) is a shift from engaging in analysis using bullet lists, indented outlines and narrative tomes to engaging in analysis using clear, consistent business end-user friendly diagrams/models.
From a business systems analyst perspective, the minute you shift from analog to digital analysis, you take the subjectivity and interpretation out of analysis. Users, subject matter experts and other stakeholders start engaging at a much deeper level. The result is thorough, accurate and unambiguous requirements!
Business Systems Analysis Tools
I use the term “tool” in this post from the perspective of a toolbox of visual diagrams that support and enable model driven business systems analysis, not from the perspective of vendor specific products.
There are four core “tools” that support model driven analysis. I divide these four tools into two types of business rules and requirements:
- Transactional business rules and requirements. Business process maps and activity diagrams are the tools that enable analysts to identify, analyze and specify what users and systems need to do in an organization and how the users and systems need to do it.
- Data oriented business rules and requirements. Entity relationship diagrams (ERDs) and state transition diagrams are the tools that enable analysts to identify, analyze and specify what users and systems need to know in order to do what they need to do.
That’s it, there are only two types of business rules and requirements - transactional business rules and requirements and data oriented business rules and requirements. And, each of these two types of business rules and requirements have two supporting analysis tools.
Business Process Maps and Activity Diagrams
A business process map is a visual diagram that depicts the work activities (the things that a business does, or needs to do) and the sequence in which the work activities are performed. Simply defined, a business process is a sequence of work activities.
A process map depicts “what” an organization does (or needs to do). However, a process map does not depict “how” the work activities are performed. To understand and analyze “how” work activities are performed, we need to drill down to the next level of detail via an activity diagram.
An activity diagram utilizes the same notational symbols as a process map, but the frame of reference is at the work activity procedure level. Each box depicted on an activity diagram represents a manual or automated step/task that is performed in the execution of the work activity.
For example, as part of process mapping we identified the activity “Take Reservation.” During business systems analysis process we decided that “Take Reservation” should be supported as a functional requirement as part of our new Restaurant Management System (RMS). Accordingly, as part of systems analysis, a business systems analyst will analyze and define in detail how a staff member (the Host) interacts with the system (RMS) to enter/create a reservation.
The key distinction is that a process map depicts what the business does and an activity diagram depicts how the business does it.
Entity Relationships Diagrams and State Transition Diagrams
Process maps, together with associated activity diagrams, clearly represent what the business does and how it operates. However, there is another, equally important component of business and business systems analysis that defines what the organization needs to know to do what it needs to do.
An entity relationship diagram identifies business terms and concepts (aka business entity types) and how these terms and concepts are related one to another. In other words, when we, as business systems analysts, look at business processes, we also ask ourselves, what are the kinds of things we need to know about? In connection with the restaurant example above, we need to know about the concept of Customers, Reservations, Tables, Orders, Payments, etc.
We also ask ourselves how these things are related to each other. For example, when a reservation is created can (or must) the Reservation be assigned to a Table? Can a Reservation be assigned to multiple Tables? How are Servers assigned to Reservation Parties – at the party level, table level, room, or zone? Can the same item appear on multiple menus such as a lunch menu and a dinner menu? If so, can the price vary for the same item based on the menu?
An entity relationship diagram is not technical. An entity relationship diagram is a business systems analysis tool. It depicts the business terms and concepts (e.g. Customer, Reservation, Table, etc.) that are relevant to our analysis, and the business rules regarding how the various business terms and concepts are associated.
Think about an entity relationship diagram as a glossary of terms and concepts that clearly defines each term or concept and relates them one to the other as appropriate. We can analyze a glossary of terms and concepts from another perspective – the state transition perspective.
A state transition diagram takes one of our terms or concepts (entity types) and depicts the various states/statuses that an entity type can go through. For example, some of the states of a reservation could include: “Pending Arrival,” “Arrived,” “Seated,” “Finished,” “Cancelled,” etc. A state transition diagram enables us to analyze the data that is relevant to each state, the business rules that apply in each state, and the interactions that move the entity type in and out of each state.
The key take-aways from this post are:
- Business systems analysis is complicated, complex and, in many organizations, chaotic;
- Requirements are often ambiguous and superficial;
- There are two types of business rules and requirements - transactional business rules and requirements and data oriented business rules and requirements;
- Process maps and activity diagrams support the analysis of transactional business rules and requirements;
- Entity relationship diagrams and state transitions diagrams support the analysis of data oriented business rules and requirements.
- Shifting from analog to digital analysis using model driven analysis tools is essential to increasing the speed, quality and depth of analysis.
For a more detailed discussion of the concepts in this post, please see my white paper The Five Essential Business Analysis Questions.
Today’s rapidly changing business environment favors high-performing agile organizations capable of delivering extraordinary customer and business value.
Meeting this challenge often requires transformative change - and sustainable on-going improvement in business processes, organizational culture and supporting technologies.
Subscribe to my blog | Visit our Knowledge Hub
Visit my YouTube channel | Connect with me on LinkedIn
Check out our Business Analysis Training Courses and Consulting Services
