What question to ask during requirement elicitation?

Topic 1:
What question to ask during requirement elicitation?

Requirement Elecitation  is all about obtaining information from stakeholders. In other words, once the business analysis has communicated with stakeholders for understanding their requirements, it is often described as elicitation. It can also be described as a requirement gathering.

Requirements elicitation is  the practice of researching and discovering the wants of a system from users, customers, and other stakeholders. The practice is additionally sometimes mentioned as “requirement gathering”.

We as a Business Analyst are trained to gather  information from Stakeholders. But Stakeholders aren’t trained to provide information to us.
Requirement elicitation are often done by communicating with stakeholders directly or by performing some research and  experiments.

How to Prepare for Questions

A critical  part of preparing for requirements elicitation is identifying a list of questions. You actually want to avoid securing valuable stakeholder time only to be lost about what questions to ask! Some stakeholders will talk your ear off (forcing you to gently interrupt them to keep the meeting on track), but others have to led through a structured conversation.
If the scope of your project isn’t yet defined, you would possibly want to check out “5 questions to ask before starting any technology project” for some generic elicitation questions that work on most of the project.
What is a Requirements Questionnaire?
A requirements questionnaire may be a list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective). Essentially each high-level requirement from your scope document should have an inventory of questions to further refine your understanding.
Investing time during a requirements questionnaire will help ensure you not merely gather up requirements, but also that you simply get to know more about requirements.
And while it  seem like this would take a lot of time, the truth is that a well-thought-out questionnaire helps you run a more effective stakeholder meeting. Various incidents have been  reported where several follow-up meetings is eliminated by using our requirements questionnaire checklists and active listening techniques.

 
What Requirements Questions Should I Ask?
When creating a requirements questionnaire, I run through each feature one at a time. I write down what i do know about that feature (or what I assume to be true about that feature). Then i’m going to drafting questions. Most of the time, the questions evolve naturally as i feel through the implications of a feature. But sometimes i want to spur my thinking a bit. a bit like a good story, requirements will answer all the important questions. give some thought to the how, where, when, who, what, and why.
Here’s some generic questions you’ll use to spur your thinking.

How requirements questions

• How will you employ this feature?
  • Is this feature a process and, if so, what are the steps? Or, what questions am i able to ask to ascertain the steps?
  • How might we meet this business need?
  • How might we expect from this feature a bit differently?
  • How will we all know this is complete?

  
  Where requirements questions

• Where does the method start?
  • Where would the user access this feature?
  • Where would the user be located physically when using this feature?
  • Where would the results be visible?

  When requirements questions
  • When will this feature be used?
  • When does one need to know about…?
  • When will the feature fail?
  • When will we be able to start?

  
  Who requirements questions
  • Who will use this feature?
  • Who will deliver the inputs for the feature?
  • Who will receive the outputs of the feature?
  • Who will study the results of someone using this feature?
  • Who should i  ask to learn more about this?

What requirements question

• What do I know about this feature?
  • Or, what assumptions am I making about this feature
• What does this feature have to do?
  • What is that the end result of doing this?
  • What are the pieces of this feature?
  • What must happen next?
  • What must happen before?
  • What if….? consider all the alternative scenarios and ask questions about what should happen if those scenarios are true.
  • What must be tracked?

  Why requirements questions

Why questions are great wrap-up questions as they assist confirm that the requirements you just elicited map back to a need you identified when you scoped the project.
• Is there the other way to accomplish this?
• Does this feature meet the business need and solve the matter we’re trying to solve?(You’ll notice that we don’t typically ask a why question by using the word “why”. Among other reasons that’s because we don’t want to sound sort of a 2-year-0ld and annoying our stakeholders, rather we apply the 5 Whys Technique.)

You Won’t Ask the Questions One-by-One
The last item you want to do with this list is run down your list of questions one-by-one. which will be a big waste of meeting time and often doesn’t lead to an engaging discussion.
Instead, I typically select some core questions off the list and ask them to get the stakeholder talking. Then, as they’re talking about their vision for the feature, i exploit this questions list to guide the conversation and ensure we’re discussing the feature completely. i might say I typically only ask about half of the questions on the list. the remaining the stakeholder typically answers indirectly through conversation.