The 5 - Step Plan to Eliciting Accurate Requirements

/

I'll start by sharing a joke you may have come across on requirements. Here it goes:

This popular joke is a clear reflection of the kind of problems that occur when eliciting requirements. It's certainly one most business analysts can relate to. Requirements aren't just there for the picking. In the real world, business analysts often have to go the extra mile to elicit requirements, regardless of the circumstances. Despite the difficulty of identifying these elusive requirements, business analysts are expected to rise up to the challenge - every single time.

This post outlines some of the steps that can be taken to ensure that accurate requirements are elicited:

1. Use a Scribe - Elicitation Sessions require interviewing and facilitation skills. The business analyst is expected to listen to what stakeholders are saying as well as what they’re not saying and engage with them. Business Analysts are not scribes or passive observers who simply record discussions. Adrian Reed likens a BA scribing to an audience member standing on the side and recording the band music instead of enjoying the music. Bringing in a scribe allows the BA to focus on the task of eliciting requirements. If a BA were to act as facilitator as well as scribe, there’s every possibility he or she would miss out on verbal cues from the stakeholders and opportunities to ask relevant questions. This is not to say that the BA can’t take notes during discussions; more emphasis should be placed on engaging with stakeholders and taking note of only the key points.

2. Be curious – “Millions saw the apple fall, but Newton asked why.” - Bernard Baruch.

Curiosity is the hunger to explore and discover facts by approaching the world with the child-like nature of poking and prodding. Instead of going into elicitation sessions with a set agenda or answers, the BA should ask open-ended questions to see where the answers lead. Being curious can open up fresh ideas and perspectives. A genuinely curious mind is necessary for effective listening and is the foundation of a critical mind. Analysts should not take anything at face value; they should always ask why.

3. Confirm the output of elicitation sessions – This should be done as quickly as possible after meeting with stakeholders to ensure that the conversation is still fresh on everyone’s minds. Stakeholders can easily get caught up in the tide of work and time. Striking while the iron is still hot will ensure that they provide feedback promptly to clarify any conflicting requirements, risks, assumptions and constraints.

4. Use Prototypes – Some people only know what they want when they see what they don’t want. Show stakeholders a working system (even if it's not fully functional) as soon as possible. Prototypes or wireframes are a great way to stimulate discussions especially around possible improvements, missing features and conflicting requirements. The use of an evolutionary prototype (A prototype that is continuously modified and updated in response to user feedback) ensures that users are able to explore the system as often and as early as possible. Requirements tend to evolve when users see a working version of the system.

5. Trace Requirements – Make sure every requested feature or requirement links back to a specific business objective. A key aspect of requirements management is managing traceability. If a requirement does not link back to a business objective, there’s no point developing it or assigning a high priority to it. Stakeholders often propose requirements that directly increase the convenience of their work without any link to business value. BAs should sift through all requirements carefully to identify only those with the potential of contributing real value to the business.