Author: Ligia Groza

Borrowing from the terminology used in the complexity science field, in which systems are classified as Simple, Complicated or Complex, this article provides a short description of these characteristics, and suggests using the same terms, in a different interpretation, in the context of documenting Business Requirements.

In the book “Getting to Maybe: How the World Is Changed: Westley, Frances, Zimmerman, Brenda, Patton, Michael” the following meaning is given to the three types of systems:

<<Simple>> systems are based on a small set of rules or steps to function. They are robust, in the sense that the same input will generate the same output, with little variance. An example would be baking a cake by following a recipe.

<<Complicated>> system have a high number of rules and laws, even thousands, like the project to launch a spaceship to reach the Space Station. These systems can be managed by computers, are considered predictable, but they are not necessarily robust: an error in an input parameter can lead to a different outcome than desired (the spaceship ending up on another place instead of the Space Station).

<<Complex>> systems are those in which the component agents interact amongst themselves and adapt to the new conditions. For example, raising a teenager is complex because teenagers change their moods, they interact with their peers and the environment, and they adapt to the new context. Such systems are emergent, and other examples include languages, a pandemic spread, or the car traffic.

 

We can adapt this complexity systems terminology to the situation of a Business Analyst who is part of an on-going project to enhance an ERP application (Enterprise Resource Planning) in a specific organization.

In this framework the starting point are the business users who face the real world and have <<Complex>> problems. The role of the Business Analyst is to translate that complexity into a form that is <<Complicated>> but fully described. The final form of this translation is the Business Requirements Document, aligning the understanding of the requirements among the team members, with sections detailing <<Simple>> logical components.

 

From this perspective regarding the Business Analysts’ work, the categories are:

<<Complex>> problems known by the business users. These problems may touch several areas of the ERP, have unclear or vague rules, or the granularity of the logic and desired actions is not fully explained.

<<Complicated>> requirements with a high number of rules, parameters, procedures, algorithms. With the huge computing power available nowadays, ERP applications are able to handle such complicated systems, and they routinely process huge number of transactions run very fast on large databases.

 

Advertisement

 

Using the complexity lens to look at requirements provides benefits such as:

First, this perspective can reduce the frustration within the project team around requirements, by emphasizing the complex and changing nature of the business user’s problems.

Second, it increases the appreciation for the Business Analysts’ role in the team, since their talent and ability to translate <<Complex>> problems into <<Complicated>> requirements are key in this framework.

Lastly, untangling complex problems requires judgment, intuition, and context sensing – all characteristics that are unique to the human mind. In the current environment dominated by Artificial Intelligence applications, a Business Analyst with this view in mind would have less to worry about a being replaced by a robot and losing their job, if they see themselves from the position of contributing to the translation of complex problems into complicated requirements.

 

Equipped with the tools and techniques recommended by the BABOK, Business Analysts are in a unique position in the process of documenting the business requirements.

The following components of a Business Analyst’s toolkit are particularly useful in the requirements elicitation and documentation described in this framework:

• Offering mock-ups and diagrams: Visual representations of the requirements can be highly effective in helping stakeholders understand the proposed solution.
• Setting up test cases in the ERP application, to assess how well the information currently provided by the ERP system can support the proposed changes.
• Performing a gap analysis between current and future state. This technique helps ensure that the requirements align with the overall business objectives and can serve as a basis for defining the scope and priorities of the project.
• Organizing walkthrough sessions to gather feedback and ensure that the requirements are accurately captured. Business Analysts can generate and present iterations of the BRD with revision points, and address follow-up questions from stakeholders.
• Asking open-ended questions to encourage stakeholders to share their insights, perspectives, and concerns, which can help uncover hidden requirements and potential issues that may not be captured through closed-ended questions.
• Nudging the discussion towards “what” is the ultimate need, instead of the “how” to meet that need. This approach encourages stakeholders to articulate their true requirements and avoid premature solutioning. This approach allows for more creativity and flexibility in exploring different options and arriving at the most appropriate solution.
• Being flexible in case the requirements change in time as the project progresses. and appreciate that the scenarios might be unchartered territory for the users themselves.