It’s so fortunate that you’re starting your project and you came across this blog post. Well, let us take you on a rather interesting journey of requirements elicitation. Even though the name suggests something complex, if approached correctly, it can be the best building block for the software development process. 
We all know that each project should start with well-written requirements. The only issue is that a lot of time, stakeholders can’t draw a line between what they think it’s integral with what the users find important to them. There is also the issue of domain knowledge. Various industries foster various complexities and let’s face it, you can’t be an expert in each one. Hence the term requirements elicitation.

If you are not familiar with requirements elicitation, let us introduce you to it

Requirements elicitation is probably one of the most complex, challenging, and error-prone stages of software development. It’s heavily dependent on the right, clear, and consistent communication. It is the process of identifying business needs, project scope, risks, and domain insights from key stakeholders or subject matter experts. 

Why is it complex and challenging? Well, if requirements are not defined correctly, all subsequent steps will not be right either. By misdefining software features or users’ needs, you are setting yourself up for sure failure. 

Requirements elicitation is what determines the budget, time frame, and whole project scope. Without it, business analysts, project managers, and product owners will have issues with planning and setting up the initial organization with the development team. And it isn’t only about gathering and researching the product’s requirements. It’s about structuring and clarifying them as well. This is where project goals are aligned with the client’s goals. 
In agile project development, new requirements may come in iterations, and later on, yes. But this initial phase will be done when stakeholders have listed everything and all use cases they could’ve thought of at that moment. Agile allows for new future features that are not necessarily a part of the discovery phase.

So, how is it done?

The process of requirements elicitation is usually made of these stages: preparation for elicitation and requirements gathering, identifying key subjects and stakeholders, eliciting requirements, documenting requirements, confirming the findings, and finalizing elicitation. It may seem pretty straightforward, but each step has its underlying specificities. 

Brace yourself, it’s not going to be easy. 

One of the main things that a business analyst will do is research and collect documentation. It’s where they try to delve deep into the domain and business itself. They have to cover each aspect of the business, industry, and existing systems. This is where the subject matter expert comes in with deep insight and industry knowledge. A subject matter expert knows things others might not even consider or label as important. They both identify key stakeholders that have to be included in discovery and are important for elicitation. Some usually use the RACI matrix for this and to determine the demand of all stakeholders.

But don’t mistake requirements gathering with elicitation. Elicitation is about drawing out insights from key stakeholders and validating research and gathered information. 

Let’s get down to it

After the initial setup, this is where the fun begins. It’s time for requirement eliciting. In this phase, business analysts go over gathered requirements with key stakeholders and try to determine what is important to them and what is not. Proper organization and management come into focus here. Previous findings get validated and new ones are added through a series of methods of requirement eliciting. Pro tip here, try not to get overrun by stakeholders or let them omit certain things. What they think is common knowledge, might not be known to all and it could lead to some issues later on.

Some of the most used techniques for requirement elicitations are:

As a business analyst, you won’t use them all. It will all depend on the industry, project type, and stakeholders. You will adapt each method to its best so that it serves you and your objectives. 

After a promising start and proper requirement elicitation, you can document, verify or confirm, and finalize elicitation. But you probably already know this, right? Covered all the steps and did it by the rules. But, like we said, businesses all drive on a different course, and having a unified approach just won’t do. 

Be careful of all the bear traps

Like with anything in life, requirement elicitations hide some traps and obstacles you can trip on. Some common mistakes here range from misunderstanding the domain and approaching all projects the same, to skipping certain steps. 

The number one mistake will always be not understanding the business environment and having too narrow of an outlook on the business itself. You cannot apply the “all the above” method and have the same approach toward everyone. Businesses differ even in the same industry. Two businesses door to door can be extremely different. That’s why there is the term “specialization”. Same industry, but diverse segments. Whether you’re a business analyst or even a product owner, face the facts – you are about to learn a lot about some markets and their users. 

Beware of scope creep

Another mistake that can happen easily is not recognizing all the stakeholders involved in the project. That means that you can easily skip someone who has some deep insights or someone who will be affected by the product, or software in this case. By not recognizing all that are affected by business needs, you might encounter scope creep later on. Essentially, make friends with those who matter. Sounds a bit like a high school clique (insert any teen high school movie reference here), but recognizing the right people is the road to having complete requirements. 

Also, one huge thing here. Ask everything and go as deep as you can with questioning. If you find a detail important, investigate it. As it is with life, that one small thing you thought nothing of, ends up being the thing that interferes with or kills your project. You know those kids that have billions of questions? Be them. But filter the questions you realize won’t make a change or are focusing on the wrong things. You don’t want to end up with too wide a project scope.

Elicitation is not just a phase you have to get through

Treat elicitation as a fine-tuning process. Because it essentially is. It’s not a one-and-done deal. After discovering requirements you will most certainly interact with stakeholders continuously. In agile project development, new requirements will pop up. Yes, elicitation does come before planning but it will bleed into other phases of an SDLC. 

Just be careful of those stakeholders as well. They might try to force requirements based on their wishes and wants which may not be integral or important for the software. It’s a fine balance between certain expectations and reality. You also have to be wary of constraints and assumptions. Don’t forget to account for those. What if assumptions prove to be wrong later on in the project? This is where disaster strikes. 

Often, in requirements eliciting we limit ourselves and the process to just some of the elicitation methods, whether we feel more comfortable with certain ones or we want to get things done faster. This approach is completely wrong since it can limit and skew our findings. Each project will ask for a different set of techniques and will be based on what type of stakeholders are there. 

Get a hold of the situation

Collaboration is key to everything. Without it, requirement elicitation loses its meaning and point. But it’s not only about going back and forth just to set up the project. It’s about learning and adapting. It’s a business case whose wide breadth is challenging but necessary to create software just right. You’ll have to consolidate various stakeholders’ requirements to build those reached with consensus. 

Getting the requirements right means that you can, later on, communicate properly with the development team. Ensuring a smooth collaboration flow and one source of truth is integral in connecting value from step one to the end product. 

You also need to control the situation. This process can’t be done superficially. Don’t just scratch the surface and be done. Here, you’ll work with a lot of people who differ in opinions and a business analyst will have to coordinate everyone and keep on track. Don’t veer off the path or your setup. Be a lion tamer that is controlling the environment, but is always on the lookout.

Go for the gold

In the end, there isn’t one unified advice on how to handle one of the most complex steps in software development. Sorry, but the diversity of industries and businesses will make this a bit harder. Basic concepts and domain knowledge will remain the same, but software rarely is. Especially if someone is striving for uniqueness and innovation. 

This is not where you’ll blindly reach out and hope to grab onto something useful. Requirement elicitation is a precise process that requires specific approaches and documentation. As much as preparation is key, so is organization and structured systematic handling.

Besides the technical side of requirement elicitation, we can sum up some personal tips for this process:

• Identify the “why, what, how, when, and who”
• Don’t leave anything to chance
• Leave your ego and bias at the door
• Patience is a virtue
• Be an active listener
• Approach with due diligence
• Think ahead

So, when you find yourself in another requirement elicitation phase, cover all points. Assess the situation properly and expect the unexpected.