Prepping Your Requirements for Primetime: Confirming Elicitation Results

We should always ensure the requirements we develop can pass through three quality gates before we consider them complete and ready for the rest of the project team to act on. They have to be confirmed, verified, and validated – in that order. In my three part-series on preparing requirements for primetime, we’ll explore what this means and how these checkpoints, or gates, relate to each other. In this segment, we will look closely at the first gate, confirming your elicitation results. In parts two and three, we’ll look at the subsequent quality benchmarks.

Let’s say you have been talking to stakeholders and reading system documentation around approving change orders for a construction project. Sprinkled in with all of this information you have collected are nuggets that may feel like requirements, like when a stakeholder says, “I don’t want to have to log in at two different places in the system just so I can authorize a change order. That is really annoying.” But it’s not really actionable yet, and you can’t be sure how it fits in with the rest of the information you collected. You can’t even be sure if that particular pain point is in scope for your project to fix, but you note it and move on.

At some point, though, you should notice you’ve stopped getting new information. When you return to the same stakeholder, no matter how you reframe your questions, you hear the same answer. Moreover, you may be hearing something very similar from other stakeholders. There’s a term that data analysts and researchers use for this phenomenon. It’s called data saturation. They use this benchmark to help them know when they can stop collecting data and start analyzing it. As business analysts we can do the same to determine when it’s time to pause our elicitation and take stock of what we have learned. Once we have documented all our elicitation results, the first step, or gate, is to confirm them.

According to the IIBA BABOK, confirming elicitation results is the process of checking the information you gleaned through your BA activities, with a focus on ensuring the information is both accurate and consistent with the rest of your elicitation results. We also want it to be complete information, without gaps in our understanding of the problem.

Let’s use the login example from above. Stakeholder A complained about having to log in twice to complete a change order. On the other hand, the system manual you read specifies only one login point during the approval process. The information from the two sources is inconsistent. Before you move on, you need to resolve where that inconsistency is coming from. How it gets resolved may determine whether you have identified a requirement. If the documentation is out of date, the stakeholder could be right, and it is a detail worth exploring further. If the stakeholder is logging in incorrectly, fixing that pain point might just be a matter of 5 minutes worth of training for that person to show them the correct login path.

The final step in confirming your elicitation results is building a shared understanding between all your stakeholders. Through your elicitation, you have fully defined the dimensions and nature of the problem, and have a solid sense of what conditions must be true to fix it. One way to help build this consensus is by gathering your stakeholders together and sharing all your results, comparing and contrasting their different perspectives as you go. Another benefit of using a formal review like this is that you demonstrate that you really heard your stakeholders. When they feel heard and understood, it helps you earn their trust. One way you could do this is by reviewing everything you learned with the key stakeholders. Formal reviews are not the only technique you could use, but they are a powerful tool in your toolbelt.

However, the BABOK notes, “Confirming the elicitation results is a much less rigorous and formal review than occurs during analysis.” In other words, you’re not done yet. Your confirmed elicitation results go through more vetting in the requirements analysis phase, which is where requirements verification and validation happen.

Learn more in part two and three of this blog series!