Transcript for:
Developing Questions for Requirements Elicitation

Do you struggle with finding the right questions  to ask during requirements elicitation? If so,   I’ll be sharing the framework I use to  develop questions for requirements activities. Hi, everyone Dr. White here. The founder of  The Business Analysis Doctor. Today we’ll be   discussing how to know what questions to ask  during requirements gathering and elicitation.   But before we get started in be sure to subscribe  and like this video if you find it helpful!!!! So, I got a recent request to discuss the  questions to ask during requirements elicitation.  The truth is, there’s no magic list of questions  to ask because every situation is different;   however, there is a framework I learned  several years ago that has proved to be   effective. And that framework is the 5 Ws and  an H method. I originally learned this from the   book The Quest for Software Requirements but  I’ve adjusted the framework a bit to derive   a richer set of questions. I’ll include a  link to the book in the description. Now,   while 5 Ws and an H may seem like a pretty  basic approach to requirements elicitation,   the key to optimizing this method is to adjust  the focus of the framework based on the category   of requirements you are eliciting. The  components in the framework include: Who What Where When Why AND How Now the 3 key Requirement categories to  consider when eliciting requirements include   business requirements, stakeholder  requirements, and solution requirements. Business requirements – Identify “why” we  are making the change. These are generally   presented in the form of goals,  objectives, and expected outcomes.  Stakeholder Requirements – What  stakeholders need in order to   meet the objectives. In Agile environments,  these may take on the form of user stories.  Solution Requirements (Functional  and nonfunctional requirements) –   What the system needs to do and how it  needs to behave in order to support the   stakeholder requirements. In Agile these might  be presented in the form of acceptance criteria. So, let’s dig into this further. Level 1 – Business Requirements Category When you’re eliciting Business Requirements the  framework should be applied to help you understand   why we need to make a change. For business requirements,   you might ask the following types of questions. Why does a change need to be made?  Business problem or opportunity – For this   W, it may also be useful to incorporate  the 5 Whys method to ensure that you are   discovering the true problem or opportunity. What are we trying to achieve? Business value in   terms of goals, objectives, and outcomes? Who are the stakeholders? This may   include organizations, business areas,  customers, external stakeholders impacted   by the change. Also, who is the sponsor? Where will the initiative be executed? This   question may be more or less complicated depending  on the structure of the organizations, and the   geographic locations of the stakeholders involved. When does the chance need to happen by?   Allows for timebound objectives. How do we measure success? Allows   us to determine whether or not the needs were  met once the initiative has been completed. After you’ve used to questions above  to build your business requirements.   Use the information to gather any applicable  documents such as process maps, procedures,   organization charts to get some additional  context to help you prepare the questions   for the next round of elicitation activities. Use the documents to prepare questions related   to the current state based on the information  available to you. Once you start reviewing   the documentation, this will naturally  stimulate curiosity that will allow you   to ask more rich and relevant questions  during the next round of elicitation. Level 2 – Stakeholder Requirements Category Now you will use the 5 Ws and an H framework  to flesh out the stakeholder requirements.   Again. Here we are trying to further refine  the list of stakeholders, determine what each   stakeholder group needs to do in order to meet  the business requirements for the initiative. You will use this framework to analyze the current  state during an activity such as an observation,   shadowing, or operational walkthrough  to gain more context. Then you will ask   these questions again as you are  defining the ideal future state. For stakeholder requirements  you might ask the following: What processed or systems are involved or impacted  by the initiative? What data or information   is required. What applications are involved? Why are these processes or systems performed?  Who are the contributors to these processes  and systems? Who receives the deliverables   or outputs from these processes and systems? Where do these processed and systems take place?   Where are does the information live or come from? When do these processed and systems happen, when   do they occur, when does the information expire How are these processes and systems executed   (exact step and activities) – How is  are the deliverable or outputs used It’s usually best to prepare  these questions in advance   and send them to the stakeholder prior to  the elicitation session so that they are   prepared to think through these types of  questions and have the answers available. You want to give the stakeholders as much  time as possible to prepare so they can   provide the best quality information  possible during the session. If feasible,   you may ask the stakeholders  to provide the responses prior   to the session, so that the meeting can be used  where further elaboration or probing is needed. Level 3 – Solution Requirements Category Once the stakeholder requirements or user stories  have been defined and verified. They will need to   be decomposed into solution requirements. Solution  requirements communicate what the system needs to   do functionally and how it needs to perform in  order to enable the stakeholder requirements. For solution requirements, you might  ask the following types of questions. What does the system need to do,   what does the system need to display? What  is the sequence of functional activities?  Why is this functionality needed? Helps  determine the value of the requirement.  Who needs or is impacted by this functionality? Where does this functionality occur?  When does this functionality occur,  when is it triggered, when does it end  How is the functionality initiated? How do we  know when this functionality has been completed? The framework is used to decompose each  functional and nonfunction requirement   down to the most atomic level to ensure  that it fully understood and represented. Well there you have it folks, this  is the Framework I use to Asking the   right questions during requirements elicitation. If you have any questions or  comments on this topic be sure   to leave a note below and I’ll get back to you! Also, don’t forget to check out the resources  available on my website thebadoc.com. I hope you have a productive and prosperous week   and I wish you the very best on your  BA journey, until next time!!! Bye now!