5 things to remember when collecting requirements 

Industry Insights
Chris Freeman July 2, 2024

Whether you’re a product manager, project manager or business analyst, you know that collecting requirements is daunting.

Your mind immediately wanders to: 

  • What do I collect? 
  • What does a well defined scope look like? 
  • Where do I start? 
  • How am I going to get everyone on board for this?

Every project is different, but near limitless scopes and various wants can be hard to juggle, resulting in products that ultimately fail.

But regardless of how you go about gathering requirements, there are a few key points that you should keep in mind that will help you get better results long after your requirements are delivered.  

Read on for our top 5 things to keep in mind when you go about collecting requirements. 

1. Not all requirement gathering processes are the same 

Requirement gathering isn’t the same for every company. Waterfall, agile and other product development methodologies all result in their own benefits and drawbacks. 

 

Collecting Requirements: Waterfall

Waterfall projects have the highest all-in-one time spend on requirements gathering due to the need to gather all information in one go prior to work commencing. 

This has benefit of:

  • Allowing teams to plan the next phases of work with confidence knowing the detailed requirements you’re working with from the off.
  • Being structured in a way that can more easily determine timescales for delivery.
  • If done right, harnessing stakeholder and customer information that’s vital for building the right end product early.

The flaws however being that:

  • By collecting requirements early, you run the risk of things changing during the course of the project and having to row back on features, designs and more in your original specification.
  • Mistakes made at the start have a cascading effect on the rest of the project, being more costly to amend later on.   
  • Any errors that occur won’t be caught until far later in the process.
  • It’s a big time expense upfront.

 

Collecting Requirements: Agile

Agile takes a sprint based approach, consistently iterating on a hypothesis to gather more information that can be used to inform the product that’s finally built.

The pros of an agile approach to gathering requirements, like the exercises used in a design sprint, is that:

  • The team-based approach creates a framework for gathering information from experts in your organisation easier.
  • Agile is designed to be fast, leading to teams gathering requirements faster.
  • The iterative approach means that if requirements change, they can be adapted early and at lower cost.

There are cons however.

  • Fully fleshed out requirements usually aren’t available immediately. That’s because iteration and research may end up taking the project in a few directions before settling on one.
  • This means that it’s hard to establish a firm plan and deadlines.

 

As a result, teams should be mindful of pros and cons of their product development methodology when gathering requirements to keep possible issues in check.

2. Engage with stakeholders and internal experts 

Requirements shouldn’t be gathered in isolation or be based on assumptions.  

Talking to stakeholders and experts can help company’s discover goals and challenges teams and their customers have. A lot of the time, this includes points that teams wouldn’t have considered unless you talked to them, making communication the ultimate discovery tool. 

For product teams though this can be difficult, with 49% saying stakeholder management is their biggest challenge, the result of needing to manage multiple expectations, balance goals with customer needs and achieve buy in. 

By building in times where your team can share any data related to the challenge can make all the difference. 

"What helps a product manager to do good work is they need that full perspective from working with the engineers, designers and the customers and the stakeholders."
Marty Cagan

3. Always be taking notes 

Seeing as requirements gathering is considered the identification of a project’s exact requirements from start to finish, it’s mission critical to have all the details to hand to inform your next big decision.  

Whether it’s in team activities, stakeholder interviews or findings from customer research, the resulting requirements will be a product of your broad findings. 

When you’re collecting requirements, it can help to:

  • Structure team interviews in a way that allows for noting down the highlights.
  • Use activities that encourage team members to write down their thoughts on sticky notes so documentation after the fact can be done easier.
  • Take advantage of recordings for virtual meetings to transcribe and pull meaningful points.
  • Harness project management tools like Jira, Asana and more to document and keep an audit log of changes as they happen.

4. Don’t leave design to chance 

Design is the cornerstone of products that users love and hit corporate targets. And there are plenty of reasons to take design seriously: 

When teams ignore or don’t appreciate the value a design phase brings in favour of focusing solely on technical requirements, errors creep in that inflate costs and you risk ending up building something that doesn’t truly have your end user in mind. 

That’s why when teams are collecting requirements, design should be something that’s always in the conversation.

Leaving design to developers or non-UX specialists results in adhoc decision making that usually doesn’t have usability or the users goals in mind.  

We recommend using internal or external designers to help map out how the product will work in practice. Embedding exercises like user journey mapping and wireframe/prototyping (see the types here) can be a low effort but high impact way of ensuring UX carries into development.

5. Have review time built into your process 

Collecting requirements shouldn’t be a one-time thing.  

Things don’t remain static when it comes to product requirements. Competitors make changes, new technology can come into play and user behaviours evolve.  

When that happens, fixed requirements gathered can be a liability, preventing teams being able to pivot and adapt when the product may otherwise fall flat.  

Agile processes come with this time built in, using sprints and constant iteration to make tweaks to the requirements via design and prototyping, making the stakes far lower. 

For waterfall though, it’s trickier, as requirements are gathered upfront and don’t offer a lot of time to adapt if going straight to engineering. However, regardless of methodology, scheduling times where reviews can be made is an invaluable tool for stepping back and looking at if there are any points missed and if strategically you need to make a change. 

Continue Learning…