Some think there is no need to learn about the different types of questions used to gather information. Most think all are born with the ability to ask questions. To some extent this is true. However, when defining a business solution; the only way to successfully design a business system is to extract all of the necessary information from the stakeholders and subject matter experts (SMEs). Keep in mind that stakeholders are people who are impacted by a software project's success or failure. And, stakeholders can be anyone ranging from end users to the end users' managers or even the executives that the managers report to. The primary stakeholder is usually the person whose department owns the system. For example, an HR system may be owned by the HR Department and the HR Director may be the primary, internal stakeholder and system owner. SMEs, on the other hand, are people who are considered experts in a business area. The SMEs may or may not be a stakeholder. But analysts may go to an SME to learn more about a business area (i.e., asset management, project management, staffing, etc).
This post discusses the importance of designing questions; it tells how questions assist the systems analyst in designing a system; and, it describes some of the questioning techniques that can be used when meeting with stakeholders and SMEs.
Designing and defining a business solution is a costly process. It is imperative that the customer receive the product that is both needed and expected. The job of a Business Systems Analyst can, to some degree, be compared to that of a person who investigates crimes. For example, the U.S. Department of Justice Office of Justice Programs, National Institute of Justice produced a document title, "Eyewitness Evidence, A Guide for Law Enforcement Research." The Guide includes the questioning procedure followed by Department of Justice investigators who interview witnesses. The Guide directs investigators to encourage the witness to volunteer information without prompting; ask open-ended questions (types of questions is discussed later in this post); augment the open-ended questions with closed-ended, specific questions; avoid leading questions, avoid interrupting the witness, etc.
Notice the procedure specifically identifies the types of questions to ask first and then the types of questions that should follow the initial screening. This is done because it has been determined that questions can be phrased a certain way to obtain a certain type of results. For example, leading questions are not used because they often result in the respondent providing answers the interviewee wants the respondent to provide. Outside of question types, the procedure also mentions investigators should "avoid interrupting the witness" so the respondent does not loose his/her train of thought and leave out important details. So, as can be seen by the information gained from the Department of Justice guide; using a procedure to strategically design question types; and, determine when to ask specific questions is very useful.
Much like an investigator, a systems analyst must ask questions to uncover the unknowns related to business problems, needs and wants associated with a system. The unknowns are discovered by asking stakeholders & SMEs questions and documenting Their responses. In addition, the systems analyst does the following:
It may surprise some to learn that there are different types of questions used; based on the type of desired response. Following is a list of the type of questions (please note that the list is not all inclusive) used; and, descriptions and examples for each question type is also included:
Hypothetical Questions
When asking a Hypothetical question, the question should be phrased to paint a picture of a scenario. The respondent then provides feedback based on the scenario painted by the individual asking the question.
Example: "If we automate the invoicing component of the CAI system, could you then processes 1 application each day?" Or, "let's say we add 2 more people to your team, how many applications could you process in 1 day?". Notice in each example the stakeholder or SME is expected to respond to the specific scenario provided. This approach does not leave room for them to provide additional information. Instead, the question is asked in such a way that the answer will either be yes or no.
Hypothetical questions should only be using in systems analysis when a stakeholder conveys a business problem; and, research results provide insight on possible solutions. Possible solutions can be posed as hypothetical questions directed to the stakeholder. These hypothetical questions would be used to solicit the individual's opinion on whether or not the solution would yield the desired results in the stakeholder's business environment.
Open-Ended Questions
Responses to open-ended questions solicits a broad statement from the stakeholder. This approach results in obtaining a vast amount of relevant information. With open-ended questions; no information is provided to lead the stakeholder or SME down a path. For example, "tell me about the process you use to approve applications." Notice the question is general and only limits the stakeholder or SME to discuss information relevant to approving applications. However, the respondent can discuss any area that pertains to approving applications including business problems, business process steps, employees, etc. Investigators typically use this line of questioning when asking a witness about something he or she saw. The witness then provides the details in his/her own words without coaching from the investigator.
Closed-Ended Questions
Closed-ended questions should be used to confirm facts stated by the stakeholder or SME when open-ended questions were asked. Typically, close-ended questions are phrased in a way such that only a yes or no answer is required. An example of a close-ended question might be, "you stated one business problem is that applications are never completed in time for customers to take advantage of the Red-tag sale. Is this correct?" The respondent would then answer yes or no.
Probing Questions
Probing questions provide SMEs an opportunity to provide greater details about one or more topics previously discussed. For example, a systems analyst may have a list of use cases along with the related actors and descriptions. However, a series of probing questions may be needed to gain steps for the normal and alternate flows and functional requirements. For example, "earlier you mentioned all students must enroll for the Fall semester to receive a discount. What process should a student use to enroll for classes?" Probing questions are used to gain additional insight in areas where the responses already received resulted in information gaps.
Leading Questions
Leading questions are used to obtain the desired answer to a question. For example, "since you stated Red-tag employees rarely perform well; you think it's best to automate that component don't you?" This line of questioning forces the respondent into providing the desired answer, which is yes. Leading questions should never be used by a Systems Analyst because they lead to documenting requirements that will change when the stakeholder changes his/her mind and wants to reword a statement to provide a different answer. It's best to let stakeholders provide the answers they want to provide based on their business needs or problems.
Before you host a requirements gathering session; take time to formulate a list of questions. Be sure to reference the various question types that should be used. And, make sure you phrase each question type appropriately. Lastly, it's a good idea to stay away from leading questions that will result in poorly defined or inaccurate requirements. Inaccurate requirements result in increase project costs since stakeholders usually will not accept an incorrectly implemented business system.
This post discusses the importance of designing questions; it tells how questions assist the systems analyst in designing a system; and, it describes some of the questioning techniques that can be used when meeting with stakeholders and SMEs.
Designing Questions for Requirements Gathering
Designing and defining a business solution is a costly process. It is imperative that the customer receive the product that is both needed and expected. The job of a Business Systems Analyst can, to some degree, be compared to that of a person who investigates crimes. For example, the U.S. Department of Justice Office of Justice Programs, National Institute of Justice produced a document title, "Eyewitness Evidence, A Guide for Law Enforcement Research." The Guide includes the questioning procedure followed by Department of Justice investigators who interview witnesses. The Guide directs investigators to encourage the witness to volunteer information without prompting; ask open-ended questions (types of questions is discussed later in this post); augment the open-ended questions with closed-ended, specific questions; avoid leading questions, avoid interrupting the witness, etc.
Notice the procedure specifically identifies the types of questions to ask first and then the types of questions that should follow the initial screening. This is done because it has been determined that questions can be phrased a certain way to obtain a certain type of results. For example, leading questions are not used because they often result in the respondent providing answers the interviewee wants the respondent to provide. Outside of question types, the procedure also mentions investigators should "avoid interrupting the witness" so the respondent does not loose his/her train of thought and leave out important details. So, as can be seen by the information gained from the Department of Justice guide; using a procedure to strategically design question types; and, determine when to ask specific questions is very useful.
Questions Help Gain Insight Into Stakeholders & SME Needs;
Much like an investigator, a systems analyst must ask questions to uncover the unknowns related to business problems, needs and wants associated with a system. The unknowns are discovered by asking stakeholders & SMEs questions and documenting Their responses. In addition, the systems analyst does the following:
- Draws conclusions from stated facts;
- Identifies gaps in information provided; and
- Pursues answers to close identified gaps.
Types of Questions
It may surprise some to learn that there are different types of questions used; based on the type of desired response. Following is a list of the type of questions (please note that the list is not all inclusive) used; and, descriptions and examples for each question type is also included:
- Hypothetical
- Open-Ended
- Closed-Ended
- Probing
- Leading
- Reflective
When asking a Hypothetical question, the question should be phrased to paint a picture of a scenario. The respondent then provides feedback based on the scenario painted by the individual asking the question.
Example: "If we automate the invoicing component of the CAI system, could you then processes 1 application each day?" Or, "let's say we add 2 more people to your team, how many applications could you process in 1 day?". Notice in each example the stakeholder or SME is expected to respond to the specific scenario provided. This approach does not leave room for them to provide additional information. Instead, the question is asked in such a way that the answer will either be yes or no.
Hypothetical questions should only be using in systems analysis when a stakeholder conveys a business problem; and, research results provide insight on possible solutions. Possible solutions can be posed as hypothetical questions directed to the stakeholder. These hypothetical questions would be used to solicit the individual's opinion on whether or not the solution would yield the desired results in the stakeholder's business environment.
Open-Ended Questions
Responses to open-ended questions solicits a broad statement from the stakeholder. This approach results in obtaining a vast amount of relevant information. With open-ended questions; no information is provided to lead the stakeholder or SME down a path. For example, "tell me about the process you use to approve applications." Notice the question is general and only limits the stakeholder or SME to discuss information relevant to approving applications. However, the respondent can discuss any area that pertains to approving applications including business problems, business process steps, employees, etc. Investigators typically use this line of questioning when asking a witness about something he or she saw. The witness then provides the details in his/her own words without coaching from the investigator.
Closed-Ended Questions
Closed-ended questions should be used to confirm facts stated by the stakeholder or SME when open-ended questions were asked. Typically, close-ended questions are phrased in a way such that only a yes or no answer is required. An example of a close-ended question might be, "you stated one business problem is that applications are never completed in time for customers to take advantage of the Red-tag sale. Is this correct?" The respondent would then answer yes or no.
Probing Questions
Probing questions provide SMEs an opportunity to provide greater details about one or more topics previously discussed. For example, a systems analyst may have a list of use cases along with the related actors and descriptions. However, a series of probing questions may be needed to gain steps for the normal and alternate flows and functional requirements. For example, "earlier you mentioned all students must enroll for the Fall semester to receive a discount. What process should a student use to enroll for classes?" Probing questions are used to gain additional insight in areas where the responses already received resulted in information gaps.
Leading Questions
Leading questions are used to obtain the desired answer to a question. For example, "since you stated Red-tag employees rarely perform well; you think it's best to automate that component don't you?" This line of questioning forces the respondent into providing the desired answer, which is yes. Leading questions should never be used by a Systems Analyst because they lead to documenting requirements that will change when the stakeholder changes his/her mind and wants to reword a statement to provide a different answer. It's best to let stakeholders provide the answers they want to provide based on their business needs or problems.
Summary
Before you host a requirements gathering session; take time to formulate a list of questions. Be sure to reference the various question types that should be used. And, make sure you phrase each question type appropriately. Lastly, it's a good idea to stay away from leading questions that will result in poorly defined or inaccurate requirements. Inaccurate requirements result in increase project costs since stakeholders usually will not accept an incorrectly implemented business system.
