A Step-by-Step Guide to the Requirements Gathering Process

---

In the quest for a successful product development process, there are any number of steps that could go wrong or lead to release delays or cost overruns. Few, however, are as vital to a good outcome as the requirements gathering process.

The requirements gathering process is central to a timely and efficient release of a product that fulfills expected deliverables. Unfortunately, this important step is too often rushed, condensed, or truncated. When all of the relevant stakeholders aren’t consulted for input, the requirements document won’t include everything necessary for a successful product, and the process may be doomed to failure before design even begins.

To help you gather the right requirements from the right people, Jama has assembled this step-by-step guide to the requirements gathering process.

A Step-By-Step Guide to the Requirements Gathering Process

If you’ve waited until project kick-off to start gathering requirements, you may have already waited too long. Requirements gathering should begin as soon as possible—even before the official beginning of the project, if possible.

---

RELATED POST:What is Requirements Gathering?

---

And requirements gathering should be an ongoing process. Obviously, there’s a point where the real design work must begin, but you should always have an ear and eye open to catch additional requirements as they arise. The earlier you can catch new or revised requirements, the easier it will be to integrate them and avoid delays or cost overruns.

With that somewhat fluid and holistic perspective in mind, there is still value in defining a more linear process that can give a framework for ongoing requirements gathering. Here is a good starting point for gathering requirements for your next project, broken down into three phases:

Phase One: Requirements Elicitation

The initial phase of requirements gathering is elicitation, which is just a process of collecting all of the top-requirements from all relevant stakeholders through a series of sessions, meetings, surveys, interviews, or other means. The elicitation process can be broken down into four steps:

1: Establish stakeholders.The very first step in requirements gathering is figuring out whose input to include in the process. You can split stakeholders into three basic groups:

• • Internal stakeholders:These are the people inside the company or on the development team who have a direct interest in positive outcomes. Internal stakeholders can include the project sponsor, managers, SMEs, and others.
  • Technical stakeholders:Technical stakeholders are the teams and leaders responsible for developing and implementing the project or product. This group may include developers, testers, solution architects, and other support teams.
  • External stakeholders:This group will have an interest in the outcome of the project, but will not necessarily be directly involved in development. External stakeholders may include compliance and regulatory groups, business analysts, or customers and end users.

2: Define initial scope of the project.Defining project scope is key to avoiding scope creep along the way. While it’s important to recognize that the scope may change after requirements gathering sessions, defining the initial scope can help keep the project from getting out of control early on.

3: Set up requirements gathering sessions.Once you’ve established the various stakeholders, start holding sessions to gather requirements. These meetings could include internal or external stakeholders or even a combination of both. For a successful session, follow these guidelines:

• • Establish a clear agenda ahead of time.Write out the main points to be covered in the meeting, including any specific questions or development items for which you need to write requirements.
  • Take notes.Never assume that someone else is taking notes! Write your notes under each agenda item so that you start grouping requirements. For example, if you know that a particular integration will be necessary, make notes under that heading on your agenda to keep those requirements together. Review your notes immediately after your meetings and send to internal teams to make sure everything is captured in one place. Save your notes to a shared folder for the entire team.
  • Start creating tasks.After notes are completed, use them to start creating tasks and action items and defining deliverables. Set up future meetings as needed to capture additional action items and requirements.

4: Get creative.Initial requirements gathering sessions may be focused more around technical stakeholders or business analysts, but be sure to include time to gather input from creative team members—marketing, design, and others. It’s also good to include sessions with end users, sales team members, and others who can offer input on what features and benefits the final product should include.

---

For a deep dive into requirements gathering techniques, visit:11 Requirements Gathering Techniques for Agile Product Teams

---

Phase Two: Requirements Documentation

In the documentation phase, the development team organizes input in the form of user stories, functional decompositions, feature descriptions, and the like. We break this phase into three steps:

1. Write the Marketing Requirement Document (MRD).The MRD is the document that expresses a customer’s needs or wants in a final product from the development team. This document will help define customers and their pain points, identify competitors, and establish business needs and desired business outcomes.
2. Revise scope, if necessary.This isn’t an opportunity to completely redefine the project concept or scope, but rather a modification step that takes into consideration all of the requirements gathering sessions. The point of this step is simply to make sure the scope is defined as completely as possible to avoid future scope creep.
3. Write the Product Requirement Document (PRD).Or collect the requirements in some other format that your team or organization has agreed to use—a spreadsheet, a database, or a requirements management tool likeJama Connect. This document should include relevant insights from the MRD and other supporting early notes. It should also integrate user stories, feature descriptions,functional and non-functional requirements, etc. It should have four main components: purpose, features, release criteria, and timeline.

Phase Three: Submit for Review

Once you’ve conducted multiple requirements gathering sessions and completed the initial documentation, it’s time for review.

1. Confirm requirements with stakeholders.Involve as many of the original stakeholders as possible. Ask them to review the requirements as defined in documentation. Are the requirements clear to all parties? Did the product development team miss any important requirements? Revise any requirements that are unclear to all parties. Be sure to get sign-off on individual requirements by relevant stakeholders.
2. Conduct prototyping and testing.Wherever possible, conduct initial prototyping and testing on a working model of your specification. Perform feasibility, usability, and product concept testing. This step should be conducted at the same time as the previous step so that results can be shared with stakeholders.
3. Prioritize requirements.Once requirements are clarified and signed off, the team should prioritize them with as specificity as possible. More than just noting whether a requirement is a “must have” or “nice to have,” prioritization should also involve ranking each requirement within the higher categories.

There is much room for overlap between these phases and steps, and it may feel overwhelming to undertake the entire requirement gathering process before any design or development begins. However, spending the time to conduct a thorough requirements gathering process can save time and money and create a much higher probability of success for your project.

Common Pitfalls of Requirement Gathering

Even when a thorough process is undertaken, teams can encounter challenges and pitfalls along the way that risk introducing delays into the project development process.

• Making assumptions or not clarifying requirements.When faced with a long list of stakeholders or requirements gathering sessions, it’s tempting to make assumptions. Take the time to clarify, ask more specific questions, and get as much detail as possible. And be sure to be as specific as possible in your confirmation process!
• Focusing on HOW instead of WHAT.需求应该处理一个产品必须做什么开云足球app下载官网最新版(the functional requirements) and WHAT constraints it will have on how it achieves that functionality (the non-functional requirements). Don’t let assumptions about tools, features, techniques, implementation, or other development concerns influence how you gather and write requirements. Just listen to the needs of stakeholders and write the requirements to those needs.
• Failing to adequately consult stakeholders.This pitfall could take several forms. It may mean not conducting enough sessions at the beginning of the process, or it could mean not adequately confirming requirements before beginning design and development. Be sure to get a thorough review and sign-off of all requirements before moving on to the next phase. One way to do this is with a good requirement management (RM) tool such as Jama Connect. With a requirements management tool, everyone has access to the same information, and notes and other feedback can be attached directly to requirements for traceability purposes.

Requirements Gathering for Agile Development

While the requirements gathering process outlined above is ideal for many projects, Agile teams have different needs, and an extensive requirement gathering process could interfere with their results. Agile teams expect to work fast, and scrums and sprints are typically just a few weeks, at most.

For Agile teams, a robust requirement management tool can streamline requirements gathering and management without sacrificing results. With a tool like Jama Connect, teams have transparency and access to requirements at all times, allowing easy annotation and clear traceability. Requirements management products encourage collaboration throughout the ALM product development process and offer clear advantages over static tools such as spreadsheets or simple documents.

Comprehensive requirements gathering is the key to a successful product development process. By clearly defining requirements and scope up front and getting sign-off from all stakeholders before full design begins, teams will have a much clearer path to product development success. While it’s no replacement for a requirements management solution like Jama Connect, which automates Live Traceability, download thisproject requirements templateto make things simpler.

---