A good analyst understands the importance of asking insightful, probing, and sometimes difficult questions. He/she helps ensure that implementation decisions are made at the right time, and with sufficient information in hand.
Occasionally, an analyst will encounter a stakeholder who wants to prescribe the detailed solution on day one. What then?
Below are a couple techniques that have served me well over the years.
Restate the request in the form of a capability
When a stakeholder asks, for example, for a specific software module to be added on to the existing system and for several other interesting services, fields, widgets and shiny objects, restating the ask in the form of a capability can be an effective way to bring the conversation back to the desired level for requirements. For example, I might ask:
“If I understood you correctly, customers need to be able to pan and zoom the high-resolution images accompanying product listings so they can see potential product imperfections. Is that right?”
Certifying the need by restating implementation detail as a higher-level capability is a great way to get the discussion back to the appropriate level. Through gentle reminders and consistent use of this technique over time, I’ve found that I’ve been able to coax/train some stakeholders into providing needs and capabilities instead of implementation details.
You might notice the subtle use of the common user story construct “As a [actor/stakeholder] , I need to be able to [capability] so that [objective/goal] . ” in the restatement. This helps the analyst not only to understand the capability, but also the actor and the reason the capability is important.
Find out why
Now, this is a little different from a BA’s beloved “Five Whys” technique to get to the root cause of a problem. In this case, we are trying to learn why a stakeholder seems drawn to a particular implementation. In this case, I might ask:
“Ms. Stakeholder, you seem to have an affinity for this particular way of solving the problem. Generally, we try to stick to higher level requirements – needs and required capabilities – at this stage, but I sense you have reasons why you feel we need to follow this particular path. Could you describe those to me?”
Often, this type of questioning reveals other requirements, constraints, or, at minimum, will uncover concerns the stakeholder has which may be important to understand and document, even if not as requirements.
I like these techniques because they validate the stakeholders’ well-intended and valuable contributions, while gently redirecting the conversation to a level of detail appropriate to requirements discovery. Instead of using negative language, (“No, that’s not what I’m looking for..”) the analyst is able to affirm and frame the subsequent dialog in a positive way.