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:
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:
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:
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:
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:
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.
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:
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.
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.
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:
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!
You have an idea. We make it happen. Web and mobile app development for your business.