What And How Of Requirement Gathering - Part One

This time, instead of writing on some technology or solution, I thought to write on one of the important phases of SDLC, i.e., requirement gathering. To be more specific, this article will be more about collecting information about business requirement. We will explore various sources to get and understand most of the portions of any business requirement.

It’s very important to understand that the information can be gathered from many standpoints. It can be from the Business front, Application front, Operations front, Technology front, and maybe many more. So, while gathering information, one should have a clear vision of what kind of information they are looking for. Let’s have a look at a few of the well-known categories.

  • Business – Goal of business, Service offerings, Products, Financial Structure, etc.
  • Application – Productivity tools, interaction with the business application system, Code Modules, etc.
  • Operations – Identify the information’s origin, information’s consumption, information’s ownership, Data warehousing, Data models, Data Management policies, etc.
  • Technology-Technical Services, i.e. Development Environment, Topologies, Network Services, Security, DBMS, Technical Specifications, Hardware, Software etc.

The next biggest question would be how to gather all this information. If you search on the internet about how to gather information, you will get many ways. But most of these tactics, more or less, fall into one of the below categories:


In this technique, one will observe a user performing the tasks in an actual real-world environment and ask the user any questions related to the task. It is basically like following the user as he or she performs daily tasks. In other words, more the questions, more the information.


This technique is effective only for frequently performed activities or tasks because if the task is performed occasionally, then it would be difficult to shadow someone.

Some common questions which can be asked during shadowing can be,
  • What decisions do users make when starting or completing a task?
  • What modifications must be made over time to make it easier to complete the task?
  • Which related tasks may affect the design of the solution?
  • Are there any performance criteria?
  • How many people does a user interact during a given task?
  • Are there any variations in the steps to complete the task?
  • How often does system or management interfere with their job?
  • What do users like/dislike about the system?
  • Characteristics and preferences of user.
  • Concepts and terminology used by users?
  • What trainings do users need?
  • How can training and support costs can be reduced?
  • Have users been through the training or they are self-taught?
  • What information about the user is not documented?
In essence, one has to observe and question both the management and the users. If there are any external stakeholders involved with the task then they should also be part of this observation.


While on one hand shadowing provides an effective means to discover what is currently being done in the business, on the other hand, it does not provide all the necessary information. Another flaw of shadowing would be, it is not suitable for getting the information about long-term activities that extend weeks or months along with the processes that require very less or no human intervention. Hence, we can look for other techniques like interviewing.

Interviewing someone is the one-on-one meeting between project team and the user.

Here, quality of the information totally depends upon interviewee and the interviewer. The interviewer can ask a wide range of questions as compared to shadowing mechanism. These questions can be from basic information to difficulties to limitations of the system. During the interview process, the interviewee can give some ideas to improvise the solution, but one should avoid assuming that those ideas are the correct solution.

The success of this technique totally depends on how the questions are structured or framed. The interviewer should be in a position to get more and more questions out of the answers given by the interviewee. One should always avoid asking misleading questions.
Few of the standard questions that can be asked during this process can be,
  • Is there any documentation available to help you in performing your job?
  • Is there any third party, that affect your work – i.e. support specialists, external suppliers/system, etc.?
  • Does any business policy hinder you in performing your job?
  • Do you need any assistance or help when you work remotely? If yes, then what?

Surveys are the other means of gathering information. It consists of a collection of questions. A very good example of surveys is the customer feedback form.

One of the best parts of surveys is that they keep the identity of the user hidden as they can be given anonymously, which in turn promotes confidentiality. Such kind of information gathering technique is useful when one is more concerned about the responses rather than which individual has responded.

The most difficult part of surveys is its preparation. Everyone cannot come up with surveys as is requires a trained professional for choosing questions and then analyzing the responses.


Surveys can be affected by user attitude or mood. Here are a few common examples of information that can be collected via surveys,
  • Organizational structure
  • Policies
  • Training material and instructor feedback
  • Customer satisfaction surveys, etc.
Hope you got an idea about shadowing, interviewing, and surveying techniques and when to use what. There are a few more techniques that can be considered in order to get the required information for starting any project. But being a completely theoretical write-up, I would like to end this article here itself and will write about more techniques in my next one.

Until then, keep reading.


MSDN, CDE, BH Project Management