Share This Post

How to Improve Your Curiosity as a Business Analyst, Part 2

As a quick recap, I introduced the necessity of being a more curious Business Analyst in my last post. I explained that the danger of being an “order taker” is that we build a product that meets the customer’s request, but in the end, is a failure because it is not what they truly needed and is left underutilized. The prescription to avoid this catastrophe is to be more curious. I introduced four ways to be more curious during the elicitation process which include:

  • Ask good questions that are open-ended and dig in to exceptions or existing problems.
  • Respectfully challenge key stakeholders to ensure that assumptions are true.
  • Go in with a plan by drafting questions ahead of time, but be willing to go off script as needed.
  • Don’t limit yourself to just interviews but use a variety of techniques to elicit requirements.

Next, I promised to share more about how we use modeling during elicitation to extract requirements from stakeholders.

Models: A Necessity of Elicitation

One common theme that I hear as I talk to BAs across the world is that the use of visual requirements models is deemed a “nice to have” and not a necessity. When I ask if someone has created something as simple as a process flow, the general answer I get is “Well, I’ll do it if I have the time.” I would argue that we have to make the time. Models are key because the requirements alone are insufficient to help us find gaps, things we don’t need, and even to understand the requirements themselves.

Puzzle pieces

Imagine if I were to dump a pile of puzzle pieces on to a table and tell you there are a few missing pieces. If I ask you which pieces are missing from the puzzle, you’ll look at me like I’m crazy. There is no way to know which pieces are missing without first attempting to put the picture together. Once you’ve done that, the missing pieces jump right out at you, don’t they? Requirements models work in the same way. The missing pieces become much more evident once the known pieces are visually displayed in a way we can process and understand.

Missing puzzle piece

Models Generate More Questions

Remember how I said one of the first ways to improve your curiosity is to ask good questions? Well, as I’m creating these various requirement models, I always find more questions that I need to ask. Either something doesn’t look quite right, or I just need more information to ensure that I fully understand. Sometimes, gaining additional information on one model generates questions on other models. For example, as I create process flows, many of the decision boxes contain business rules. And many times, more than one business rule. Thus exploring these decisions, being curious about what all the rules are, helps to ensure I find the information that is needed.

Models Generate Questions

Requirements Modeling Language

One thing I didn’t get talk too much about in my BA World presentation in Chicago is Requirements Modeling Language (RML). So those of you reading this article are getting a bonus here! RML is basically a toolbox of many visual models that are specifically designed for requirements work. They have been tested through years of experience and hundreds of projects. RML provides you with pre-built templates for how to begin creating and using these models on your projects. On each project you will use only a handful of these models, and which models you choose will be dependent on your project. Every project will require more than a single model, but no project should require all models. In general, the more complex your system, the more types of models you should be using.

We classify the models of RML into four main areas Objectives models, People models, System models and Data models. The models in each of these areas work together to create a whole picture of the system. Each area shows one facet of the solution:

Categories of Models

Each model is designed to be the most simple it can be while conveying the necessary information about requirements. This enables all levels of practitioners to create them and all business experts and developers to read them easily. The use of these models helps scale requirements to many expertise levels in the organization.

I hope those of you who couldn’t make it to BA World Chicago benefited from this information. If you are interested in a list of ideas for your elicitation sessions, shoot us a note: info@argondigital.com.

How to Improve Your Curiosity as a Business Analyst, Part 2

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage