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.
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.
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.
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:
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.
