What is a requirements gathering process?

An essential first step in acquiring an information system is requirements gathering. Requirements gathering is an exploratory process that involves researching and documenting a project’s requirements from start to finish.

When you are gathering requirements, make sure you’re really focusing on and listening to your stakeholders’ needs, not what your system-of-choice happens to do best. Even if you know you are going to be using a certain system, you need to adapt the system to the user, not the other way around. Listen and gather first, then determine where the gaps are between your stakeholder’s needs and any existing product you may have in mind. Remember: requirements are about the what, not the how.

The importance of requirements gathering

• Scope creep is a major risk in most projects. A clear and defined scope is going to save headaches in the long run for everyone involved. 
• Rework leads to wasted time: if you’re midway through the system development and you discover hitherto-overlooked requirements, you’ll need to go back, perhaps even start over, undoing a lot of good work. This can impact your project timeline, budget and staff attitude, so it’s best to identify all requirements at the beginning. 
• Stakeholder frustration occurs when projects keep missing the mark due to poorly written and tracked requirements. 

The requirements gathering process

Gathering requirements can be overwhelming, but it doesn’t need to be overly complicated — particularly if you break it down into four steps.

Step 1. Preliminary analysis

Working with the key stakeholders, formulate responses to the following questions:

• What is your vision or goal for the project?
• What do you want from the system that hasn’t been possible previously?
• Why do you/we need this new system? 
• What is your/our current state? 
• What are your/our areas of improvements? 
• What is in scope, what is out of scope? 
• Is there funding for this? 
• Is there any timeline for this? 
• Who are your/our important people in relation to this system acquisition (project stakeholders)? 
  • internal stakeholders
  • external stakeholders
  • project sponsor (e.g. leadership or board member)
  • project/user teams

A cross-section of staff from the program side, operations and the executive should be involved. Don’t forget to consult with entry-level staff. They are more likely to use your current information system regularly and understand its strengths and weaknesses. They’ll apply that understanding to the selection of the system that will replace the current system and can potentially contribute the best ideas.

Step 2. Identify the techniques to capture requirements

Capturing requirements is not as straightforward as just asking stakeholders what they think the system should do. In many cases, they won’t be aware of a system’s potential and may be limited by their immersion in the current state. There are various techniques you can use to capture requirements. You can apply one or more approaches based on the type of project.

• Interview: interviews build background information on the business problems and develop your understanding of the current state of the system and future opportunities. The interviews need to cover a diverse cross-section of different stakeholders, so that the requirements are not skewed towards one particular function or area.
• Survey: surveys can be valuable because an interview will only get the information that the interviewee is consciously aware of. Sometimes there are underlying requirements and functions that are better understood by way of a survey. By using carefully chosen, probing questions (based on the information captured in prior interviews), you can drill down on particular functions that the stakeholders don't know are important, but can be critical to the final design of the system.
• Observation: another way to capture requirements and understand strengths and weakness of current system is to observe users going about their their daily tasks and recording their actions and activities. 
• Workshop: after capturing initial requirements by interview, survey, and/or observation, you will need to reconcile divergent opinions and contrasting views to ensure that the system will meet the needs of all stakeholders and not just the most vocal group. Depending on the number of stakeholders, this part of the process can take between a couple of days for very small organisations to a month for medium and larger organisations. Workshopping is an important approach to the initial requirements, generating additional detail, building consensus and probing beyond assumptions and preconceptions.

Step 3. Document the requirements

There are many ways to document the requirements you’re gathering, from a simple Word document, spreadsheet or presentation to sophisticated modelling diagrams. 

Download our requirements analysis spreadsheet.

You can use this template in your requirement capturing process. This template identifies the general requirements of any system and will help you organise your team’s thoughts. Remove anything that is out of scope so that your team can focus only on the necessary areas.  

Prioritising is the key in gathering requirements. It’s easy for requirements gathering sessions to turn into wishlist workshops. The point isn’t to ignore that information but rather to clearly prioritise what you’re hearing by delineating what is in scope for your initial launch and what is not. You definitely want to track wish-list items, “nice-to-haves,” etc. but prioritising helps you focus your efforts and helps you make decisions if time gets short and something has to go.

Step 4. Validate the requirements

Once your requirements are documented, don’t assume that everybody is now on the same page. Distribute and confirm final requirements with all stakeholders. If additions are made, this needs to be confirmed by the project sponsor and the project team to reduce scope creep or increasing costs. If anything was overlooked or misunderstood, it’s better to know now.