Requirements Gathering & Elicitation
A fundamental part of software development and any good project management framework, requirements gathering is critical for the long-term success of projects. Not only this, but it’s an important piece of making sure that projects stay on track and on time. But what actually defines this process and its techniques? Keep reading to learn more.
What is Requirements Gathering?
Requirements gathering (also known as requirements elicitation or capture) is the process of generating a list of requirements (functional, system, technical, etc.) from the various stakeholders (customers, users, vendors, IT staff, etc.) that will be used as the basis for the formal requirements definition document.
However, the process is not as straightforward as just asking the stakeholders what they want the system to do. In many cases, they aren’t aware of all the possibilities that exist and may be limited by their immersion in the current state. For example, asking people in the 19th Century for their requirements for a better vehicle would have just resulted in the specification for a faster horse-drawn carriage rather than an automobile. Beware the old adage, "It's everything I asked for, but not what I need"!
Requirements Gathering Techniques
So with this complication, what are the different methods of gathering requirements for a comprehensive view of the upcoming project?
Interviews
These are an invaluable tool at the beginning of the process for getting background information on the business problems and understanding a current-world perspective of what the system being proposed needs to do. You need to make sure that your interviews cover a diverse cross-section of different stakeholders so that the requirements are not skewed toward one particular function or area.
Questionnaires
One of the challenges with interviews is that you typically only get information that someone is consciously aware of. However, there are sometimes requirements and features that are better obtained through active questioning. By using carefully chosen, probing questions (based on the information captured in prior interviews), you can focus on specific areas that the stakeholders might not think of as important, but can be critical to the eventual design of the system.
User Observation
One of the best ways to determine the features of a system to avoid "paving the cowpath" (i.e. building a slightly improved version of the current state) is to observe users actually performing their daily tasks — and ideally record the actions and activities that take place. By understanding the holistic context of how they perform the tasks, you can write requirements that will reinvent the processes rather than just automating them, ensuring that usability is paramount.
Workshops
Once you have the broad set of potential requirements defined, you need to reconcile divergent opinions and contrasting views so the system will meet the needs of all users and not just the most vocal group. Workshops are a crucial tool that can be used to validate the initial requirements, generate additional detail, gain consensus, and capture the constraining assumptions.
Brainstorming
This is a powerful activity, which can be performed either in the context of a workshop or on its own. By considering different parts of the system and considering 'what-if' scenarios or 'blue-sky' ideas, you can break out of the context of the current state and consider visionary ideas for the future. Tools such as whiteboards or mind mapping software (more on this later) can be very helpful in this phase.
Role Playing
In situations where the requirements depend heavily on different types of users, formal role-playing can be helpful. Different people take on the roles of different users in the system/process to understand how the different parts of the system need to work to support the integrated processes (such as in an ERP system).
Use Cases & Scenarios
Once you have the high-level functional requirements defined, it’s useful to develop different use cases and scenarios. These can be used to validate the functionality in different situations and to discover any special exceptions or boundary cases that need to be considered.
Prototyping/Reverse Engineering
There is truth to the saying "I don't know what I want, but I know that I don't want that!". Often stakeholders won't have a clear idea about what the specific requirements are, but if you put together several different prototypes of what the future could be, they will have a better idea of which parts they actually like. You can then synthesize the different favored parts of the prototypes to reverse-engineer the requirements.
Requirements Gathering Process
Now that we understand the fundamental concepts, here's a breakdown of the core steps of this process:
1. Identify the Relevant Stakeholders
The first step is identifying everyone invested in the project's success. This includes end-users, business analysts, subject matter experts, and anyone else impacted by the software. Understanding their roles and perspectives is crucial for gathering well-rounded requirement coverage.
2. Establish Project Goals and Objectives
Once you've identified the stakeholders, collaboratively define the project's goals and objectives. What problem are you solving? What opportunities are you capitalizing on? Clearly defined goals provide direction and ensure everyone's working towards the same vision.
3. Elicit Requirements from Stakeholders
Now comes the heart of requirements gathering. Through various techniques like the ones we discussed above, you extract information from stakeholders. The goal is to unearth both functional requirements (what the software needs to do) and non-functional requirements (how the software should perform). Active listening is key here, so ask open-ended questions, listen attentively to stakeholder concerns, and avoid making assumptions.
4. Document the Requirements
As you gather requirements, meticulously document them in a clear, concise manner. Use logical categorization (such as by feature or user type) for easy organization. Popular tools include spreadsheets, wikis, or dedicated requirements management software.
5. Confirm the Requirements
With the requirements documented, present them back to stakeholders for review and validation. This ensures everyone is on the same page and avoids misunderstandings down the line. Address any concerns and achieve consensus before moving forward.
6. Prioritize the Requirements
Not all requirements are created equal — work with stakeholders to prioritize them based on importance and feasibility. This ensures the development team focuses on the most critical functionalities first, while considering future iterations for additional features.
How Should the Information Be Captured?
There are many different ways to capture the information, from a simple Word document, spreadsheet, or presentation to sophisticated modeling diagrams. We recommend that the initial high-level brainstorming and requirements discovery be done on a whiteboard for simplicity and to foster collaboration.
Once the initial ideas have started to form, it’s helpful to use a formal Requirements Management System. This allows you to record the information from the whiteboard and drill down the functional requirements in smaller focus groups to arrive at the final use cases and system requirements.
Mind Maps
We alluded to this earlier but one useful method for capturing the requirements is a mind map. In this type of diagram, you start with the main concept and draw lines to smaller and smaller items as you break down each idea and concept into smaller parts.
The nice thing with a mind map is that you can initially create it on a whiteboard, then once there is consensus, recreate it in a mind mapping tool.
Pitfalls to Avoid
The biggest risk is that by asking existing users or stakeholders to help define the requirements, you might get a requirements specification that is disproportionately influenced by the current ways of doing business. Because of this, we’d suggest ensuring that sufficient third-party research into industry-wide trends and usability research is done so the requirements take into account future opportunities in addition to current problems.
Enhance Your Requirements Gathering, Traceability, & More with SpiraTeam
It can be unnecessarily complicated to integrate a separate Requirements Management System with your current tools and processes. On the other hand, the benefits and positive impact that these functionalities have on your work can’t be understated.
This is where a tool like SpiraTeam comes in — not only does it cover your bases with requirements gathering, but it has a host of powerful out-of-the-box features to enhance your release planning, source code management, bug tracking, automated testing, collaboration, reporting, and much more. Even better, it seamlessly integrates with your existing ecosystem, from xUnit test frameworks to help desk tools.
See why our partners love SpiraTeam by getting started with a free 30-day trial!