Image source: Getty Images

Requirements gathering is vital to understanding what’s required of a project. In this guide, we discuss how to gather requirements and share some examples of questions to ask.

Imagine this: You’re a graphic designer. After spending hours designing three different logos for a client, you excitedly submit your work. An hour later, the client tells you they all look good but none matches the idea inside her head. Ouch.

Maybe she’s being difficult. Maybe she simply doesn’t know what she wants. Or maybe you misunderstood what she was looking for.

You can, of course, try and justify your designs, but if you made the mistake of designing without first going through a requirements gathering or “discovery” phase with the client, then you may have to start all over again.

Overview: What is the requirements gathering process?

Requirements are conditions or capabilities stakeholders require a project to deliver. Conditions can mean the terms of a contract, budgets, time frames, compliance requirements, or any other policy you need to observe.

Capabilities refer to the features, functions, or characteristics the project’s outcome must possess, such as “the ability to run at certain speeds,” “must be orange,” or “10 feet high.”

Project requirements are divided into three major categories:

• Business requirements: The company’s overall goals for the project. For example, in a software implementation project, a productivity increase of 25% within the next 12 months is a business requirement.
• Stakeholder requirements: The needs of a specific stakeholder or a group of stakeholders. For instance, the finance department may request accounts payable, accounts receivable, and tax management features added to the company’s ERP system.
• Solution requirements: The characteristics a solution — the project’s outcome — must possess to satisfy both business and stakeholder requirements. Solution requirements are further classified into:
  • Functional requirements: Features or functions explicitly asked for and integrated into the final product. An example are the accounting features the finance team requires.
  • Nonfunctional requirements: Also known as quality attributes, they specify how the system should work rather than what it should do. For example, each page of an e-commerce website should load within three seconds.

The requirements gathering process, also known as requirements elicitation, is a project management basic practice that uncovers, verifies, documents, and manages the various needs and requirements of a project’s stakeholders.

Why is requirements gathering important for project management?

As you probably realized from our logo design example above, a solid grasp of the project’s requirements is critical to project success. When you take the time to gather requirements prior to execution, which is one of the five phases of the project life cycle, you’re able to:

1. Nail what the customer wants

Capture and translate the project’s requirements into tangible deliverables that match stakeholder expectations.

2. Create better estimates

A clear understanding of what you’re delivering results in better estimates — an accurately defined project scope, a budget that works, and a realistic timeline.

3. Measure the project’s progress

How do you know your project is on the right track? By ensuring approved stakeholder requirements are met. Does the product have the required features? Does it satisfy the project’s objectives? Does it deliver business value?

4. Increase user adoption

A software system that fails to solve pain points obstructs, rather than drives, productivity. Consulting users to figure out what they need is essential to getting organizational tools right, whether you’re rolling out an off-the-shelf solution or building one from scratch.

How to effectively gather requirements for your project

Without requirements gathering, producing deliverables customers actually want is next to impossible. To make sure your project outcomes are aligned with stakeholder expectations, follow the steps below.

Step 1: Identify the stakeholders

Who has interest in the project? Which stakeholder groups have the most impact on the project? Meet with team members, project sponsors, and other relevant groups to identify both key and secondary stakeholders.

Step 2: Identify the best tools and techniques for gathering requirements

Some of the most commonly used requirement-gathering techniques include:

• Focus groups: Use focus groups to obtain feedback on a product or service.
• Interviews: Interview key stakeholders to understand their goals, needs, and expectations.
• Document analysis: Review the documentation of an existing system, especially if the project requires you to make changes to it.
• Brainstorming: Meet with a group of people to acquire as many ideas as possible.
• Benchmarking: Particularly useful for process improvement initiatives, benchmarking involves comparing your organization’s performance metrics and processes with the best in the industry.
• Questionnaires and surveys: Use surveys to collect information from many people, especially when there are too many of them to interview, you’re pressed for time, and you have limited funds.
• Workshops: Requirements workshops are structured, facilitated events in which a meticulously selected group of people congregate to discover, validate, and prioritize requirements.
• Prototyping: Build a prototype or an early sample of a product to test a process or concept.
• Mind mapping: This information-gathering technique helps you visually organize information, spot correlations, and refine ideas.
• Observation: Observe users to understand how a process flows, identify user pain points, and locate areas for improvement. Ask questions if you have to.

Each of the above has strengths and weaknesses, and some are best suited for certain project types. Use a combination of tools and techniques to explore the project’s requirements from several angles.

Step 3: Ask the right questions and take notes

We’re stating the obvious here, but it’s worth emphasizing that to get the answers you need, you have to ask the right questions. Some stakeholders may not know right away what they want, and you may have to ask probing questions to help them uncover what they’re looking for.

Also, when in a meeting, whether with a client or the project team, take notes. Capture items for clarification, research, or further discussion.

Step 4: Document the requirements

A requirements document is one of many documents project managers — or someone else on the team — may have to maintain throughout the different project phases, primarily because project requirements may evolve over time.

Here’s a sample requirements template for a website-building project. Image source: Author

Make the document shareable and available on demand using project management software, so the project team can refer to it at any time.

Step 5: Analyze and verify the results

Now that you’ve collected and documented your requirements, it’s time to take a close look at them. Ensure they’re complete, accurate, and achievable.

Then, prioritize them based on significance. Once done, get the project’s stakeholders to verify the results and sign off on them. Doing so will save you a lot of stress and increase your team’s chances of achieving the project’s goals.

Requirements gathering example questions

Let’s say you’re building a house, and your client wants it to be big and beautiful. “Big and beautiful” isn’t necessarily helpful, right? Before you head over to your computer to put your project planning tools to work, sit down with the client to discuss several things.

• Where will the house be built? How many bedrooms do they want? How many bathrooms? What kind of kitchen are they looking for? Who will live in the house? Will there be kids or elderly occupants?
• Will there be tenants? Do they entertain a lot? What do they want their backyard to look like? Do they want their house to be sustainable?
• Diving in further, what kind of materials do they want used? What’s their preferred architectural style? Are there specific design considerations you need to know about? What are their storage needs?
• Do they want a second floor? Or a loft, perhaps? Do they have any landscaping requirements? How soon do they want the house completed? What’s their budget?

Once you have the answers you need, you can start building a design prototype.

Architects use rendering software and other relevant tools to turn their designs into reality — at least virtually. Image source: Author

If you’re offered a logo design project, questions to ask may include:

• Do you have an existing logo? What do you like or not like about this logo? Why do you want to change it? Are there any elements you want to keep?
• What’s your company’s name? Which words do you want emphasized? Should the logo include a tagline?
• What’s your field of business? What are your products or services? Which customer age groups are you targeting?
• What characteristics or attributes do you want your target audience to think of when they see your new logo?
• What are your company’s strengths and weaknesses?
• Describe your business in one word. Why this particular word?
• Who are your competitors? How is your company different from them?
• Which colors do you want included in — or excluded from — the logo? What’s your preferred layout (e.g., fully text-based, with some graphic in the text, or text with a separate graphic)?
• Which logos do you like and why? Which ones do you dislike?
• Do you have any logo ideas of your own?

You may also want to ask about budgets and timelines, and if there are other people involved in the project, such as decision-makers other than the client.

Get the requirements right, get the project right

Requirements are the foundation of any project. And if the foundation is not solid enough, the project is doomed to fail. So whether you work in project management for a small business, construction, or software design, don’t make the mistake of skipping requirements gathering.

Only once you fully understand what’s expected of a project, you can deliver what clients (and other stakeholders) want.