Questionnaires are a very useful tool for gathering requirements.

We’ve written other blog posts about this before here.

Questionnaires are usually associated with getting information from large groups of distributed users. They work very well when other means of eliciting requirements are not very practical. However, of late, I have been using them a lot to gather requirements from individuals or small groups whom I am meeting in person or via telephone. The results have been very good and it is this experience that I wish to share with you.

In order for questionnaires to work effectively in a small group setting, they should be used at the end of the process. I conduct all the preliminary sessions in person or via telephone. I try and understand exactly what the requirements are through these sessions. This is usually an iterative exercise for me as I get a better understanding with each interaction with the user. When I believe I have fully understood the requirements, I use the questionnaire to close out the discovery process and cement my understanding of the problem space.

The questionnaire is constructed as a series of statements that I ask the user to validate with a “Yes” or “No” response. If I have understood the requirements correctly, I usually end up with “Yes” responses to all my statements. “No” responses mean that a quick follow up email or phone call is necessary to clarify my understanding and correct my mistake. A whole bunch of “No” responses would mean that I am way off the mark and probably need to do a full blown session again.

Let me give you an example to illustrate how I frame the statements on the questionnaire. Let us say I am writing requirements for a tax calculation. After I have conducted sessions with the user to understand how the taxes are calculated, I will send out a questionnaire worded like this.

Please validate each of the statements below by answering “Yes” or “No”.
1. Customers with a classification of “REV” are NOT charged any Federal Taxes.
2. Customers with a classification of “REV” are ALWAYS required to pay Local Municipality Service Taxes.
3. The tax rate charged for Local Municipality Service Taxes for Customers with a classification of “REV” is ALWAYS the same as the rate charged for ALL other Customers.
4. Etc., etc.

When you see the example, the following become clear right away.
1. The statements in the questionnaire should be unambiguous and not subject to interpretation. Else it becomes difficult for the user to give a “Yes” or “No” response.
2. They should be focused and precise.
3. They should be complete. In the example above, I would have attempted to cover all the conditions for a Customer with a Classification of “REV”. Else, the user could have answered “Yes” or “No” and still left not knowing whether the other conditions were covered or not.
4. There are no “questions” in this questionnaire. There are just statements that the user is validating as right or wrong.

I have found that the method is very effective in actual usage. With 20 / 20 hindsight, I postulate the following reasons for its effectiveness.
1. It is not time consuming for the users. I normally restrict myself to about 5 or 6 statements in a questionnaire. Most users can read and respond in 5 minutes or less.
2. It is easy on the users. The exercise is very straight forward and concerns subject matter they are very familiar with. Processing the content and responding is very simple for them.
3. It focuses on the tricky portions of the subject matter. I typically use questionnaires only to validate the complex portions and not across the board. This is usually the part that worries users the most and they are happy to spend a few minutes to ensure we get it right.

So what are the caveats?
1. If you have missed something altogether and it is not on the questionnaire there is only a 50 – 50 chance the user will catch it. They may assume that you know the answer and not point out your omission. This is not a tool to be used to catch what you missed. It is only to validate what you know or think you know.
2. It is not a formal review and approval of requirements. Do not attempt to send out 10 “questionnaires” which are actually all the requirements and get the approval done this way. Users will see through this and it will likely backfire.

Try using questionnaires in one on one or small group settings as described here and let me know if it works for you.

Here are a few other articles about gathering business requirements and  more techniques for gathering software requirements.