Requirements Gathering: Meaning, Types, and Steps to Identify Requirements

The term requirements gathering speaks for itself. Requirements elicitation (practically a synonymous term) is an initial stage of the project. All involved parties (customer, developers, managers, vendors, sales executives, designers) decide how they see the outcome of their scrupulous work and identify all the components to achieve that. 

So why does a project requirements stage a is such a non-exclusive topic? There are several answers to that question:

• The customer often does not know what they want. Thus, identifying a scope without a mutual vision of the final result is quite challenging.
• Often scoping or gathering requirements for a project is seen as a secondary, even purely nominal task. Budgeting and scheduling discussions may seem to some stakeholders much more urgent. It is a big mistake, as scoping negligence can genuinely hurt a project. 
• Sometimes, the project leader is responsible for neglecting this stage. A 2015 global research showed that almost 50% of software projects failed due to insufficient or unstable requirements. Some managers (not very successful or amateur ones) genuinely do not believe gathering requirements is essential. But most of the time, even a good manager does not have enough resources and time for it. 
• Some project managers unite scoping and requirements gathering. It is not a good practice, as requirements define scoping. 

We at DataXDev know a thing or two about project requirements. For 16 years, we have been turning clients' ideas into fully functional business machines. We are here to help you in your idea’s journey. This article will be an ode to the requirements gathering process. 

We will explain what role scoping plays in the project's errorless flow, present different approaches, and break down the stages of requirements elicitation.

A 2012 article reported that almost 70% of project issues are directly connected to requirements gathering failures. When a customer is inspired by idealistic ideas about the final result and is only interested in the budget discussion, a vital question of how to gather requirements is pushed to the end of a meeting or even forgotten. 

An experienced manager knows about the juxtaposition of the stakeholders' dreamy vision of the project and the inability to understand the set of features needed to achieve this dreamy vision. These misunderstandings bring some headaches but are expected in our industry.

That is why any experienced manager understands the value of efficient communication at early stages. A goal of requirement gathering steps is for a project manager to make sure that not only do clients state their “wants”, but also that everyone (customer, developers, managers, vendors, sales executives, designers) agrees on their “hows”.

The requirements gathering sets the solid basis for the project. There are numerous types, techniques, and classifications of how to organize this initial stage. Let's use the metaphor of the fortress. Scoping is both the architectural plan and the foundation of the fortress. Why so? An admirable project requirements stage predicts both planning and practical issues. 

These are called functional and non-functional requirements. This simple binary classification allows a transparent understanding of roles distribution:

• Functional requirements overlook business ideas or customers' vision — what features they want to see in the product and what users need the product should satisfy. Functional requirements have to be discussed in great detail so that both the stakeholder and team executive can agree on the final products.
• Non-functional requirements designate technical elements such as performance, usability, security, scalability, and maintenance. They explain how the specific functional requirements will work in the given platform.
• Domain requirements. Sometimes a third type of gathering requirements for software development needs to be discussed: domain requirements which designate features of a concrete category or domain of projects. Their primary purpose is to ensure that a concrete domain includes needed categorical features.

How to gather requirements for a project? Being as specific as possible is the best strategy. We introduced you to the classification of functional, non-functional, and domain requirements. To communicate the aims of the project in a much more detailed way, you can choose a more detailed approach to categorizing the requirements gathering process. Along with functional, non-functional, and domain requirements, a project manager can single out the following requirements:

• Business – dictate the mission statement, organization's aims, and general goals. 
• Solution – include features or functions of a product itself. They facilitate and specify how business or stakeholder requirements will be achieved. Solution requirements contain functional and non-functional requirements we already discussed.
• Market – this requirement document should explain the target customer and their needs and solutions on how to cater to the target audience.
• User Interface – is a type of requirement discussed with a design team. These documents should specify all the features of User Interface (UI): navigation, color codes, shortcuts.
• Software Requirements Specification – outlines general features and requirements of the system/software/platform. It should be compiled together with an engineer and also cover design and security specifications.

We presented various types and classifications of how to gather requirements for a project. Yet, there is no template for this task: product cycles in different industries differ drastically. We tried to be as rigorous as possible in order to demonstrate all the cases when you need to collect requirements.

Now when you are familiar with the types of product requirements a manager needs to gather, let’s move on to the requirements gathering techniques. Depending on the budget, the volume of the information, number of specialists involved, one can choose between the following techniques:

• Interview
• Survey
• Shadowing or participant observation
• JAD Sessions
• Brainstorming sessions
• Prototyping
• Document Analysis
• Interface Analysis
• Collaborative Workshop

All these techniques are familiar to the experienced project manager — their names speak for themselves. Yet, it is not always clear which approach will work best in the specific situation. We would like to highlight the basic techniques from which other methods originated: interviewing and surveys.

There is no more straightforward and proven method of requirements elicitation than a face-to-face interview. There are many options of how to conduct an interview. The first thing to decide is the number of people you are interviewing: 

1. One-to-one interview

One-to-one interviews can be facilitated both with a user and an expert. This option may be beneficial for projects with niche products or needy stakeholders. When interviewing a user, a personal touch can create a fruitful environment for delicate insights, which would be lost in a group discussion or a more standardized survey.

1. Group interview

Group interviews or focus groups may be more time-efficient than one-to-one interviews. Yet, sometimes it is hard to gather needed specialists and stakeholders in the same place simultaneously.

How to conduct an interview? This topic certainly deserves its own article. But, in short, while conducting an interview, remember:

• To establish rapport to making sure your interviewee feels comfortable
• You can have a script, but try to use as many open-ended questions as possible

You are not the one who is talking: in order to unveil valuable insights, let the conversation flow. Yet, remember to keep the interviewee on the needed path.

It is a less personal and insightful technology, however, much more tangible when large groups are involved. Questionnaires, compared to the interview, can significantly speed up the process. Yet, developing good survey material is not a fast task. A productive questionnaire has to be sound, questions have to be clear and not ambiguous, targeted to the specific group, easy and fast both to complete and analyze.

We introduced you to an extensive array of types of requirements and approaches of how to collect them. It is time to structure all this new information by placing each element to create a structure or a plan of project requirements. We present to you a basic requirement gathering example plan. 

• Work Plan Development
• Identification and Elicitation
• Prioritization and Assessment
• Wrap Up
• Requirement Management

So what is requirement gathering in practice? Here is the standard plan you can use as a template and modify according to the chosen techniques and project specifications.

At this stage, your task is to evaluate the number of specialists involved, the workflow, and the budget. Based on that, you can choose appropriate techniques and guidelines (what type of requirements do you need?). Keep in mind the schedule of team members and how much time they can give to this. Choose your weapon wisely!

You can finally proceed with surveys, brainstorming sessions, and interviews. If everything goes well, you have a detailed and rigorous data set of requirements. PMI offers a productive and efficient 3-step forward-backward pass methodology. 

• Step one: forward. List (as simple as it gets: in two columns) the process and the person/team responsible. You should have a concrete list with “Who” and “Action” columns. 
• Step two: backward. In reverse from the final result, you identify the relationships between only two steps at a time, discovering timeframes, possible concerns, and problems.
• Step three: a review. As a final result, you have a solid, tangible list of project components. It will allow stakeholders to see a clear picture as well as possible issues that may occur.

This method is just one of the ways how can you gather requirements in software engineering. There are numerous approaches to this step: you have to proceed from time, budget, and product complicity nuances.

If you conducted truly rigorous and extensive research, you probably have too much data for the final documentation. It is how it should be (not the other way around). Yet, your task is to filter and prioritize the gathered data so that the work undertaken can actually be useful for everyone involved in the project. Here are some guidelines on how you should process the elicited info: 

• Keep in mind the main product goal. Of course, it may shift and shape after the requirement gathering (that is why we are doing it). Constantly check if the requirements you are selecting are satisfying the established aim of the product. Also, during the open-question interviews, focus groups, or brainstorming sessions, it is good to keep a team grounded and not be distracted from the main goal. 
• This tip may be relevant already at stages one and two: talk to the right people. Distributing your attention and giving a say to everyone will probably only confuse you. This advice is also relevant when you are using the JAD sessions technique. For instance, a facilitator in a JAD session has to be a neutral manager. However, they need to be fluent in the discipline. The scribe (a team member who records key outcomes) must also be an expert in the field discussed. Yet, in terms of participation, scribes have to listen and register rather than contribute.
• Be mindful of time: sometimes, new questions occur after talking to more people, you might want to make the second round of clarifications. Also, do not forget to mention that your respondents are free to get back to you if they think of something else: it is better to let it out at the planning stage)

A final stage of gathering requirements for a project would be the completion of a requirement document for the stakeholder. Again, depending on the project scope and complexity of the project, this document can range from a few pages to a heavy manual-like manuscript. It is your time to shine and create a solid basis for the entire project cycle. 

Remember, the devil is in the details. Yet, make a document comprehensible to everyone involved: it is not only a list of requirements. It is a document that will help you to manage the product effectively.

After you approve the requirements with a stakeholder, you apply them to the project. You have to choose an appropriate method for tracking progress and identifying risks. Moreover, a requirement document can serve as an excellent asset for reporting progress or determining what is wrong. 

Remember that requirements can change: monitoring why and how requirements vary is part of the product management process. This does not signify a failure or proves the importance of the requirement gathering.

A requirements gathering process can take up to 25% of the project's time, so this activity's result must be efficient in a tangible way. It has to involve customers, stakeholders, and team specialists, be detailed yet analyzed, and not excessive. Everyone involved in the project has to see their role and how responsibilities overlap within a team. 

We at DataXDev are always in the coding mode. But our diverse, almost two-decade experience showed that it is essential to plan and identify requirements before diving in. We value cooperation, trust, and partnership: 88% of returning customers speak for themselves. Make my idea happen!