The right way of Requirements Gathering Process

Some project leaders (those who do not learn from their own mistakes) keep ignoring preparatory stages, like requirement gathering or scoping. What’s the use of it if the plan will be changed through the project, right? Yet, almost 70% of projects fail precisely because of the lack of planning and clearly defined requirements. How you gathered requirements of your project can define your success. So, to plan or not to plan?

In this article, we’ll talk about the requirement gathering process as a way out of this seemingly inescapable circle. In a minute, we will explore the intricacies of the requirement gathering, techniques, and why it should be an essential part of every software development project. Let’s go!

What is Requirements Gathering

Requirement gathering is basically giving the shape to your idea. Some skip it at all (which can put the whole project in danger due to uncertainty). Others invest too much time into it (which is not efficient as well since it slows down the work).

So, how to do it properly? One of the ways to categorize requirements is by functional/non-functional.

• Functional requirements are all about the client’s vision.
• Non-functional requirements are all about the technical and concrete features: performance, security, and maintenance. Research of non-functional requirements — it’s where the most resources should be targeted to get the best outcome.

What is requirements gathering’s result? Its aim is to establish value, goals and define scope.

How to gather requirements? Oh, where to even begin. There are myriads of techniques and methodologies both for individual and group sessions. Here are some of them:

• Interviews
• Focus groups
• Prototyping
• Questionnaires
• Interface Analysis
• Shadowing
• JAD sessions
• Brainstorming

… and many more. Make sure you’ve hired an experienced team that knows what to do and leave worries aside: let the project manager take care of the project requirements gathering.

Why Requirements Gathering is Important

Before moving on to requirement gathering techniques, let’s get one thing straight: you always need a project requirements gathering stage.

Not convinced? Tired of talking and want to finally see your idea in the making? Imagine the requirements gathering stage as a map drawing phase for your journey. You set the departure and the destination points. That is, you tell the developers what you want to get in the end. Surely, on the road your initial ideas may evolve. Nevertheless, you can always adjust them with the engineering team and get everything they way you envision.

Here’s how requirements gathering helps you:

• It reduces the gap between idea and result.
• It ensures that you and your developers have the same vision and direction.
• It defines the functionality, risks, and possible pitfalls to give more room for adjustments and flexibility.
• It makes the process much more efficient and, well, fun (and we, developers, love fun).

5 Major Steps of Project Requirements Gathering

The beauty of the requirement gathering stage is in its flexibility. Project gathering is not about planning. It’s about setting your product’s meaning. It defines the tangible features that will translate your ideas. So, this stage is a time to explore and brainstorm. The goal here is to define the vision, and the software development team will adjust to the changes along the way.

Are you getting worried? Don’t be; there are no strings attached:there are some templates, methodologies, or techniques to gather requirements. However, they are not one-size-fits-all–they may not work well for your case. Typically, the sales team briefs the client and gathers requirements. The project manager’s job is to tailor this exploratory stage to your needs and possibilities. Thus, the goal here is to exchange insights between sales and project managers.

Keep calm — we won’t burden you with complicated schemes. Here’s a simple yet hit-the-spot 5-step plan that we use as a guide to design a requirement-gathering stage for your impressive project.

1. Identify Business Goals, Expectations, and Requirements

The software cannot exist for its own sake – it should align with your business goals and relieve some of the company’s pains. The customer’s input is essential to set the goals, values, target audience, and expectations at this stage.

Alright, let’s get to the point: how do you gather requirements? Answers to some questions are crucial, for instance:

• Who is your target audience, and what matters most for it?
• What problem does your product/website solve?
• What does the solution look like? Could you please show several references of products/websites/styles you like and dislike?

Keep in mind that the worst questions are the ones not asked. The interview or questionnaire should engage the respondents and cover key issues: 100 questions for a tiny website may look excessive, but for a large-scale solution it may not even be enough.

Yet, requirement gathering is a eureka phase, so there are no taboo questions. For instance, if it’s hard for you as a customer to identify product value, take a step back and think about how you came up with the idea or what inspired you.

The goal here is to push your imagination to the extreme at the earliest stage and set a clear vision to determine the final product. Communication between the customer and the team is vital to discuss the technological challenges and choose the right approach for a cost-efficient and productive outcome.

2. Analyze

Sounds boring? Trust us, it isn’t! This stage’s all about separating the wheat from the chaff. The project manager throws off a big chunk of the gathered information, putting aside requirements that do not match the project’s values and objectives. If one still has an excessive list, it’s best to get back to the stakeholders and review if the requirements they had in mind are actually relevant.

When everyone’s finally on board with key requirements, the project manager can finally operationalize the results. Here is the agile approach to do it:

• Estimate requirements for three months and define 1-2 week sprints
• Why three months? Our experience shows this time is enough to create an MVP for basically any product. Surely, there are exceptions. However, three months are a good default setting. And more on sprints:
• opt for a 1-week sprint if you need flexibility in planning. This option allows for changing priorities and redeploying your resources swiftly.
• 2-week ones set a more steady pace when the general idea is clear and the flow is mostly uninterrupted. A pleasant bonus: you don’t spend extra time on additional planning and demos.
• Specify requirements for the first sprint
• In the middle of the sprint, the project manager gets more input for the next sprint’s tasks and plan it. Otherwise, the engineering team has to spend a couple of each sprint’s days merely on figuring out what to do.

3. Prioritize and Verify

You can’t cook something just randomly following the steps from a recipe. The same goes for software development. Here is where prioritization matters. Why is organizing work in sprints cool?

• Sprints enable a more manageable and productive workflow
• Developers get more creative freedom.
• Clients can be an active part of every stage, providing comments and feedback without interrupting workflow.

It would be wise to change priorities (if needed) between sprints, not in the middle of one. Thus, the project will run more smoothly and efficiently. Doing otherwise would be an example of seagull management.

An experienced manager will create a space for change, adjustment, and mistakes following the agile methodology. Every project manager knows about the power of black swans that could arrogantly mess with a project’s pristine schedule.

4. Document and Approve

All the creative and bold insights that project and sales managers carefully assemble have to be put down in black and white. Requirements aren’t set in stone. Still, having a concrete document helps both you and a team to speak the same language.

How to do requirements gathering with documents?

• Document general ones: goal, timeline, business, and technical requirements
• Document research insights, including available options and solutions
• Approved requirements transform into tasks in a backlog
• Compose concrete task for the first sprint

...and action! Your idea is cooking. Through the project lifecycle, project managers will launch new sprints and make adjustments by ear. What’s next?

5. Follow up and update

Detailed and ample scope — that’s what enables the successful Agile approach. The customer’s job is to envision the product. Meanwhile, the development team determines tangible solutions, always leaving room for necessary alterations.

Regular communication and feedback sessions are more than requirement gathering steps: productive dialog nurtures the project at all stages. It’s a win-win case! A customer is aware of what’s going on, and the engineering team never loses its way.

Let’s get those requirements cooking

We hope this article sheds some light on gathering requirements for a project. We discussed what are the five stages of requirement gathering and guided you through the key points.

In short: the project requirements stage is important, but don’t get stuck on it. If we were to think about the most crucial takeaway, here’s what your mantra should be:

"Communication is key."

Expectation, frustrations, plans, critique — this is what helps a project to strive. We at Halo Lab believe that open communication with clients and within a team is what allows us to stand out and deliver immersive design-driven products. No worries if you are still confused about how to gather requirements for a project. And ultimately, the requirements gathering stage can be the beginning of a beautiful friendship — who knows?