What is Requirements Gathering: Definition & Tools | Complete Guide

What are Requirement and Requirement Engineering?

There are two terms here, “Requirement” and “Requirements Engineering”. A requirement is precisely defined as a condition or a capability that a user needs to solve a problem or achieve a goal. In other words, requirements are conditions or capabilities that must be met or possessed by a system in order to satisfy a contract, standards, specifications, and other formal documentation. 

Requirements Engineering is defined as the process of defining, documenting, and maintaining the requirements. The discipline includes all the techniques, methods, and procedures related to the definition and management of users’ needs related to the system being studied. 

All-in-all, Requirements Engineering is a set of activities that are concerned with identifying and communicating the purpose of a system or software and the context in which it will be used. 

Therefore, Requirements Management acts as a bridge between the real-world needs of the users, customers, and other constituencies that are affected by software or system and the capabilities and opportunities afforded by the software-intensive technologies. 

Activities During Requirements Engineering

There are a few activities that we face when working with the requirements. In the Requirements Engineering cycle, there are four main activities, namely,

1. Requirements Elicitation – this is the process of gathering, reviewing, documenting, and understanding the stakeholders and user needs and constraints for the season. Users need domain information, existing system information, regulations, standards, etc. Based on this information, we elicitate the requirements. After this, we move to requirements analysis and negotiation. 
2. Requirements Analysis and Negotiation – analysis is the process of refining the user needs and constraints on the basis of gathered and elicitated information. Then, we move to the documentation activity. 
3. Requirements Documentation – after getting the requirement specifications, we move to the documentation part. We document the user needs and constraints clearly and precisely. 
4. Requirements Validation – finally, in the validation activity, we insert that the season requirements are complete, concise, and clear. 

When we finalize these four activities, we repeat them time and again until we get a set of agreed requirement documents that are formal specifications. 

What is Requirements Gathering?

Requirements Gathering, as the name suggests, is a process of researching, understanding, and documenting the exact requirements that a project needs from the beginning to the end. 

As part of the elicitation process, it is critical that we ask the right questions. When I hear someone say “The customer doesn’t know what they want,” I tend to cringe. I think the customer knows what they want. They may not know how to express that to us. Our job is to ask the right questions so we can help them explain to us what it is that they want. Sounds simple, right??  

What are the Steps During Elicitation?

The following are the steps of requirement elicitation:

1. Identify the source of information and requirements. This also includes identifying the stakeholders. 
2. Now, set the project scope, and define the system boundaries. 

These two activities are performed at the beginning of the elicitation process. Also, they don’t have to be in a particular order either. 

3. Now, we state or select the appropriate techniques to be used for each source of information for extracting the requirements. 
4. Finally, we are ready to prepare our document.

STEP – 1 

Sources of Requirements

There are various sources from which we can gather our requirements. Some of them include:

• Stakeholders
• Existing systems
• Existing documents
• Competitors and other similar systems
• Interfaces with the systems
• Laws and standards
• Company Policies

What are Stakeholders?

Users are one of the most important stakeholders, but they are not the only stakeholders. For example, if we are building a nightclub then only considering the potential customers will not do it. We will have to include other people like staff, waiters, DJs, security guards, and more about how they’re going to work. According to that, we will gather the requirements from both users and employees. But later, we forgot to consider the neighborhood. Neighbors may not be the users of the club, but they are affected by it. Hence, their opinions and requirements must also be taken into consideration. 

So, we can define the stakeholders as the individuals or organizations who stand to gain or lose from the success or failure of a system. Henceforth, identifying the stakeholders in the project is basic for requirements elicitation success. 

Who are the Stakeholders?

1. Client – people who pay for the development of the system. They are the people who have the final word on what the product will be. For an internal product, they are the ones who stand to be the product manager. Also, for the consumer market, the consumer may act as the marketing department.
2. Users – the user of the current and future products/systems are also important stakeholders for an organization. They are the true experts of the current as well as competitor systems. They are the best indicators for improvements in the existing systems. Their needs are what the organization must put at high priority and must not neglect their ideas and suggestions. We must also select our users carefully. 
3. Domain Experts – They are the experts who know what work is involved. They are the ones to be familiar with the problems that the software or system must solve. Also, they know the environment in which the product will be used. 
4. Inspectors – They are the experts in governmental rules and regulations and the safety required by the project. 
5. Lawyers – They are the experts when it comes to law and legalities and the standards to be kept in mind while developing the product/system. 
6. System Experts – the system experts, are the ones who interact with the system in order to build it. They are very well familiar with the interfaces of the system.  
7. …

STEP – 2

Set the Project Scope

The following steps can be followed in order to set up the scope of the project:

1. Find out why the project is initiated 
2. Property defines the key objectives to be achieved through the project 
3. Draw out a statement of work for the project that will help you appropriately breakdown the work among the team members
4. List up the items to be delivered at the end of the project
5. Select the key milestones to be achieved
6. Identify the major constraints and limitations the team can possibly face during the development of the project
7.  Create a list of items that are excluded from the list of scope items
8. Get the stakeholders to sign the scope document as it provides a confirmation that they are informed about the project and its contents. 

STEP – 3

Requirements Gathering Tasks

Planning:

1. Why should this particular requirement be implemented and the benefits it will provide? – Objectives of the project 
2. Who will be responsible for creating it? – Professionals for elicitation efforts
3. When will be the best time to implement it? – Schedule an estimate sources 
4. How will it be implemented? – Strategies and Procedures
5. And the risks 

During:

1. Confirm the viability of the project. Find out if the project is really worth it or not
2. Understand the problems and issues from a stakeholder’s perspective
3. Extract the essence of the requirements stated by the stakeholders
4. Find out better ways to do the work for the users
5. Innovation is the key to victory

Following:

1. Analyze the results in order to properly understand the gathered information
2. Negotiate a coherent set of requirements acceptable to the stakeholders. Establish the priorities as well
3. Record the results in the specifications of the requirements

Requirements gathering is an incremental process. You must repeat this step as much as required. 

Now, select an appropriate set of techniques for each source of requirements. Determine this technique based on the source, the system to be developed, and so on. Remember that not all techniques can be used in every situation. 

STEP – 4

Documentation of the Requirements

The last step in this process is to finalize all the requirements in the form of a document. This document mainly contains the notes and user requirements. And these requirements are going to be incomplete, inconsistent, and unorganized. But this is just the starting point. The document can be edited every now and then, and things can be added or altered.

Some Techniques Used for Gathering Requirements

• Interviews – They are about exploring ideas. They work mostly when qualitative data. Interviews can guide the interviewees and thus, encourage contact between developers and users. Furthermore, it is a time-consuming process. 
• Questionnaires – they answer specific questions. They are helpful in providing quantitative and qualitative data. Also, it has a broader reach. But it must be designed carefully as the response rate is low, and they must not be what you need.  
• Brainstorming – The generation of new ideas and finding a solution for the issues are the aims of this technique. Normally people like domain experts and subject matter experts are included in this technique. 
• Prototyping – This technique is majorly used when looking for unspecified or missing requirements. Frequent demos are conducted with the clients so that they can get a clearer idea of what the product would look like. 
• Study the Existing Documents – they help when we want to learn about procedures, regulations, and standards. They work only in the case of quantitative data. No time from users is required though the daily work will be from documented procedures. 
• Analyze the Existing Documents – Through this technique, information is gathered by analyzing the existing and available documents, reports, and other material. It is a highly useful technique for migration-related projects. 
• Use Cases – This technique usually involves a combination of text and graphics for enhancing the understanding of the requirements. Use cases are used for describing the ‘what’ part of the project more and focusing less on the ‘how’ part.

What are the Benefits of Requirement Gathering?

There are several benefits of requirement gathering. They include:

• Requirement gathering helps in establishing a precise scope of work and budget. With the help of this, you can provide the client with realistic budgets and release dates. 
• Correct requirement gathering ensures reduced confusion during development. It also helps in avoiding numerous meetings and time wastage. 
• A productive requirement gathering helps in developing a product that will be suitable for customers’ business activities and add value to the business.
• Precise requirement gathering helps in revealing requirements that remain hidden because they are too obvious. 
• Productive requirement gathering allows you to develop the relevant functionalities and choose the best technologies. 

What are the Problems with Requirement gathering?

There are various problems people face during the stage of requirement gathering. They include:

• Sometimes it is possible that the stakeholders do not themselves know what exactly they want and expect. So, it becomes quite difficult to state the requirements properly.
• Stakeholders explain the requirements in their own words. Hence, understanding them becomes a bit difficult.
• Different stakeholders may have different and sometimes conflicting requirements.
• System requirements can be affected by organizational and political factors.
• Requirements may change during the analysis stage. It is highly possible that new stakeholders may emerge, which radically changes the business environment. 

6 Tips for Perfect Requirements Gathering

1. Keep an inventory of “Great Questions” I believe that successful requirements elicitation interviews begin with preparation. Many analysts think they can just go sit with a user and figure out what they want. That is not the case. Analysts need to research the problem domain and think about the questions they need to ask. The primary difference between expert analysts and novice analysts lies in the ability to recognize situations and apply the proper tools (i.e. questions) that are appropriate for the situation. Experienced analysts tend to ask similar types of questions – they know they get the best results. When conducting an interview watch for instances where a particular question or specific phrasing of a question works well in getting you the information you need. When that happens write it down. Add to the list as you become more experienced. Having these questions available makes preparing for interviews quicker. These questions, or versions of them, will serve you well for nearly any project. Put them in your “toolbox” of questions.

2. What “points of pain” are we trying to solve? This is a great question for getting to the real business problem. We often get into projects assuming we all understand why we’re doing it. Let’s make sure. Let the user describe the pain he is hoping will be alleviated by this project. I asked a user this one time to have them respond that they had no idea what pain this project was supposed to alleviate. Not a good scenario. An alternative to this question is to ask what user this project needs will fill.
3. What would happen if we did not implement this project? This kind of question can help get a feel for the criticality of the project. If the users do not feel it is critical, maybe we should rethink why we are using precious resources at this point in time for this effort.
4. What does success look like to you? This helps you understand the stakeholder’s vision for this project. What is the most important result of this project to you? Consider creating a checklist for success factors and order them in order of importance.
5. Who will benefit most from this project? This will help identify key stakeholders and users. This can provide a starting point for identifying actors for high-level use cases or user stories.
6. Close every interview by asking if there is anything else that should be covered. This gives the interviewee an opportunity to express other thoughts or opinions that are important to them. This almost always uncovers a couple of new items of value.

Visure Requirements ALM Platform

The Visure Requirements ALM platform is a flexible requirements management tool that can be adapted to the specific needs of your organization, project, and processes.  The platform helps you manage requirements throughout the entire development lifecycle, from gathering and analyzing requirements to tracking changes and keeping all stakeholders up-to-date. Not only can Visure integrate with popular Microsoft programs, but it also offers compliance templates for different international safety standards. In other words, it covers all your bases and then some.

With the Visure Requirements ALM platform, you can:

• Gather requirements from multiple sources and stakeholders using different methods (e.g., interviews, workshops, existing documents)
• Capture requirements from Microsoft Word or Excel and other legacy tools as well like IBM DOORS through ReqIF data exchange
• Analyze requirements via Visure’s Quality Analyzer to ensure the requirements are clear, complete, consistent, traceable, and feasible
• Write top-quality requirements in your desired format like EARS or ITEMS.
• Prioritize and sequence requirements to ensure the right features are implemented first
• Generate reports and presentations to keep all stakeholders informed about the status of requirements
• Track changes to requirements and automatically generate reports showing who changed what and when
• Configure the tool to match the specific needs of your organization, project, and processes.

Conclusion

Requirements engineering is a process of understanding and documenting the needs of a business or organization in order to generate system requirements. The purpose of requirements gathering is to collect information about those needs from stakeholders, who are typically people within the business or organization. The steps involved in requirements gathering can vary depending on the project, but typically include identifying stakeholders, defining the scope of the project, and collecting data through interviews, surveys, or other means. In this article, we’ve shared 6 tips for effective requirements gathering that will help you get started on your next project. If you want to learn more about how Visure Requirements can help you manage your projects and gather accurate requirements, request a free 30-day trial today.