Requirements Elicitation: Reasons, Stages, Techniques, and Challenges

Discussing requirements is one of the first and most important stages of software development. The scope, budget, and time estimation for a project fully depend on how complete, clear, and relevant the requirements are. 

Making requirements clear and complete is a task for a business analyst (BA) — and something that our BAs do extremely well. By forming a shared vision of a project, a BA saves many hours during development. That’s why we insist on involving a business analyst in each project at the earliest stages.

In this article, we discuss what requirements elicitation is, the benefits and challenges it brings, and the workflow and techniques we use to work with software requirements. This text will be useful for managers that want to figure out the role and value of a business analyst in software development.

What is requirement elicitation?

In software development, requirements describe the solution to be developed, including its functions, interfaces, design, and user experience. They’re usually formulated by the client or stakeholders — people who are involved in or affected by the project and therefore are interested in its success.

Requirements elicitation is a complex process that consists of gathering, researching, defining, structuring, and clarifying a product’s requirements. As a result of elicitation, a BA creates a set of project objectives. These objectives have to be understandable for each team member and represent all of the client’s demands and needs. Requirements elicitation is an important step of the discovery phase of a project.

There are four types of requirements BAs usually handle during requirement elicitation:

• Business requirements describe why a project is needed and how the company will benefit from it.
• Stakeholder requirements capture the needs and expectations of stakeholders.
• Solution requirements contain technical demands. They can be functional (describing what the system should do) and non-functional (describing the qualities the system should have).
• Transition requirements define actions to be taken to transfer an organization from its current state to the desired state.

Gathering accurate requirements is an important task carried out by a business analyst. A single missed or unclear requirement may lead to scope creep, budget overruns, the creation of irrelevant functionality, or an increase in the required development hours. To avoid this, a BA starts working on requirements at the very beginning of the project. Once all the requirements are gathered, the business analyst starts eliciting them. Let’s find out why this process is important and how it’s done.

Why do requirements need to be elicited?

What do you see when someone asks you to imagine a car? Which make, model, and color is the car you picture? 

If you want someone else to picture the exact same car you do, the only way you can achieve this is by describing your car in detail. Some details may seem irrelevant or too obvious to you until someone asks about them. That’s exactly how elicitation works in software development.

During requirements elicitation in software engineering, a business analyst works closely with the client and all stakeholders, studying and validating their needs and assumptions as well as project risks. The discussion ends when stakeholders can think of no new use cases or when the use cases they can think of have a low priority and can be implemented during future iterations.

Requirements elicitation has several key benefits:

• Establishes the precise scope of work and the budget. Clear, prioritized, and approved requirements allow a development team to accurately plan and estimate a project. That means we can provide the client with a realistic budget and release dates.
• Avoids confusion during development. A shared understanding of what should be done, when, and how to finish a project greatly speeds up and streamlines communication. Productive elicitation helps to avoid numerous meetings that should have been emails during development.
• Adds business value. To develop a product that will facilitate a customer’s business activities, it’s important to discuss both what should be done by the development team and why. With that understanding, the team can create a solution that meets all the client’s needs.
• Reveals hidden and assumed requirements. Stakeholders always know their market and business needs the best. That’s why stakeholders may find some requirements too obvious to discuss. But developers need to know each aspect of the solution, and a BA helps them figure out and specify such requirements.
• Allows for developing only relevant functionality. When discussing requirements, business analysts use their knowledge of the development team to improve the initial requirements. They help clients cast off inefficient features and choose the best possible technologies.

At Apriorit, we have lots of cases when a BA’s attention to detail has saved hours of development.

For example, one Apriorit BA was working on a reporting system for a logistics company. One of its key features was the ability to download multiple PDF files simultaneously. When our BA asked for more details on this feature, it turned out that the solution had to download more than 500 files at a time. Realizing that this would influence system performance, the business analyst specified a time limit for the downloading process. Such a detail may seem insignificant to the customer, but it’s extremely important for developers.

Eliciting requirements usually happens in three stages. During these stages, a business analyst collects relevant information from the client, conducts elicitation sessions with stakeholders, and gets approval for the requirements before handing them over to developers. Let’s investigate this process in detail.

Stages of requirements elicitation

There are three common stages of the requirements elicitation process:

1. Preparing for elicitation

Preparation starts with business analysts collecting the documentation they need and analyzing the current system (if one exists). Documentation usually includes (but is not limited to):

• a description of the organization: business rules, structure, legal and regulatory requirements
• details of the project: solution analysis results, reports, or requirements prepared by other business analysts, technical and end user documentation of the existing system, manuals, instructions, tutorials for users and employees
• marketing materials: market research, competitor analysis, materials used to promote the solution

This set of information helps a BA understand the client’s business and industry, the practices and solutions used, and the current and desired state of the organization. To speed up the study of complex documents, a BA usually asks the client to provide a subject-matter expert (SME) — someone who knows the organization, project, and technology well.

The next preparatory step is analyzing stakeholder roles. During this analysis, a BA defines all stakeholders affected by the project and decides which of them should be involved in elicitation. This stage is necessary to speed up the elicitation process in software engineering, engage only relevant stakeholders in the discussion, and keep everyone affected by future changes informed.

For effective communication, we usually apply the RACI (Responsible, Accountable, Consult, Inform) matrix to identify the role of each stakeholder. We prepare a table that lists various project tasks and stakeholders. A business analyst then determines whether a particular stakeholder is responsible or accountable for an activity, can consult on it, or should be informed about changes.

For one of our projects, we had to reduce the call handling time in a call center by introducing a new system for taking calls. This system impacted a lot of people: operators, supervisors, the operations department, etc. Our business analysts prepared a RACI matrix that allowed them to quickly assess the needs of stakeholders, determine their responsibilities, and figure out how to work with each of them without causing any issues.

Once stakeholder analysis is completed, the business analyst prepares use case and process flow diagrams to discuss them with stakeholders. A use case diagram is a graphical representation of a relationship between an actor (a user, application, or system) and a solution. User flow diagrams help you visualize all possible interactions with a solution and choose the one that best suits the client’s needs.

For example, in a use case diagram for a system designed to handle calls and schedule rides, an actor is a call center operator, and this operator’s relation to the system is actions they perform: viewing information about callers, verifying caller information, reviewing the history of calls and previous rides. By discussing use cases with stakeholders, we agreed on the swiftest and most comfortable interactions with the system.

A process flow diagram is a chart that visualizes the processes happening inside a solution. It shows participants in the process, steps in the process, decision points, events, and their triggers.

Use case and process flow diagrams allow for improving a stakeholder’s understanding of those scenarios and possible issues.

Besides preparing themselves, business analysts prepare stakeholders for elicitation. At this stage, BAs make sure all participants understand the goal and process of elicitation. Preparation includes:

• choosing the most appropriate means of communication with stakeholders (email, in-person meetings, etc.)
• scheduling periodic meetings if necessary
• defining which information is needed from stakeholders.

These activities form stakeholders’ expectations of elicitation and help to make discussions short and effective.

Only after a BA outlines the list of questions to discuss and the stakeholders to participate in discussions do they start eliciting requirements.

2. Eliciting software requirements

Elicitation happens during a series of meetings with various stakeholders. During these meetings, a business analyst has several tasks:

• Define requirements for the development team and stakeholders. Stakeholders of the same project may understand the requirements differently. It’s up to the BA to help stakeholders articulate their needs and make sure everyone agrees.
• Manage the elicitation. Discussions of requirements may turn in unexpected directions, especially if they involve multiple stakeholders. Business analysts should control and guide these discussions so all questions are answered.
• Document discussions. During elicitation, a BA takes notes of the progress stakeholders make to improve the initial requirements after the meeting.
• Follow up with participants. Follow-ups help to structure the topics discussed and the outcome of each elicitation session.

3. Finalizing the elicitation 

Once elicitation is done, a business analyst goes through the requirements to make sure that each of these questions is answered for each requirement:

• Why? — Why should the requirement be implemented, what problem does it solve, and what benefits does it provide?
• What? — What is the exact meaning of the requirement, what are the business rules, and what are the compliance or other requirements?
• How? — What are the possible ways to implement the requirement and what are the possible obstacles (outdated or insecure technologies, network limitations, etc.)?
• When? — How urgent is the requirement and how should it be prioritized?

Requirements are documented and maintained with a specifications template. Such a specification is important in software engineering and convenient both for developers and stakeholders. After that, stakeholders confirm that everything is documented correctly and the BA hands the requirements over to the development team.

At Apriorit, we have a set of effective techniques for eliciting requirements. Let’s overview them in the next section.

Requirements elicitation techniques

Business analysts choose a technique for requirements elicitation depending on the stakeholders and tasks at hand. The most popular requirements elicitation techniques in software engineering are:

At Apriorit, we usually conduct interviews and surveys, prepare questionnaires, and analyze software and user interfaces as these are the most comfortable and useful techniques for gathering information.

Interview

An interview entails eliciting requirements from a group of stakeholders — or, in rare occasions, from one stakeholder — during a meeting. An interview can be conducted in person, during a video call, via email, or in a messenger.

To conduct an effective interview, it’s important to remember a stakeholder’s cultural background. For example, emails to customers from South Korea or Japan should contain a lot of polite constructions because a simple list of questions might be considered impolite. Americans prefer short and accurate emails.

Interviewing stakeholders has several benefits compared to other techniques:

• It builds trust between the business analyst and stakeholders.
• It allows you to discuss ideas, risks, and the necessity of each requirement.
• It reveals hidden and dubious requirements.

Survey or questionnaire

A survey or questionnaire is a good option in case a BA needs to get information from a large audience all at once. When using this technique, a BA has to:

• define the group of participants
• choose the type of questions and compose them
• distribute questions and collect and analyze answers.

While creating questions, the BA focuses on the target audience. 

We used a questionnaire when we worked on a parental control application. It was important to question parents of all ages and social statuses that could be interested in the app. There was a risk of missing the insights of younger and older parents and focusing on 30- to 40-year-olds. We created a balanced questionnaire that reflected the opinions of all parents.

Interface analysis

Interface analysis refers to research into interfaces that help systems or components interact with each other. During interface analysis, a BA investigates who uses the interface, how it works, and what data it requires. Such analysis can also be performed for competitors’ systems. Interface analysis helps you to identify business rules, possible challenges, and lacking or excessive functionality that needs to be discussed with stakeholders.

For example, one of our clients wanted to add functionality for archiving data to his data backup application because his competitor offered that functionality. After analyzing the competitor’s product and discussing the feature with the development team, however, the BA figured out that this requirement was absolutely redundant for the client’s application. The business analyst explained this to the client, who decided to substitute this feature with a more useful one.

User interface (UI) analysis

User interface (UI) analysis is one of the requirements elicitation methods applied by a BA to explore an existing UI and learn how users interact with it. UI analysis is useful for preparing use cases and understanding user needs. As a result of this technique, the business analyst can detect issues with the UI and figure out ways to resolve them.

UI analysis allowed us to improve the functionality, design, and usability of the SaaS solution for access control and user activity monitoring. The product has a robust feature set and provides the user with lots of data on each screen. As a result, its pages and content tables were overloaded with information. We analyzed the existing solution and improved the interface by reworking the structure of pages, simplifying content tables, and adding alerts on suspicious events.

Each of the techniques of requirement elicitation discussed above helps a BA see eye to eye with the client. That results in efficient meetings, clear estimates, and fast solution development. To make the elicitation process smooth, we’ve tackled a lot of challenges — let’s take a look at them.

Challenges of requirements elicitation

Based on our projects, we can outline these common obstacles in the elicitation process:

New project domain. When working with a new industry or a new type of solution, a business analyst has to quickly become an expert in the field. To do so, they search for any source of information on the subject: colleagues, subject-matter experts on the client’s side, literature, and so on.

Unclear project vision. Usually, stakeholders have a basic set of requirements and a general image of the solution they want. If stakeholders don’t have a clear understanding of what functionality their software needs, BAs and developers create prototypes of product features to help them visualize possibilities and choose the best one.

Fixation on specific features. Stakeholders may insist on designing certain features because they believe they will benefit their business. There are many reasons for a fixation on features: competitors offer similar features, those features use cutting-edge technologies, etc. A BA conducts external research, analyzes the market and competitors, and discusses requirements with developers to verify the need for features. As a result, business analysts often propose simpler and more relevant features.

Contradictory requirements. When a project affects a lot of stakeholders, their requirements may contradict each other. One of our BAs worked on a project with 35 stakeholders. It was a challenging experience, but thanks to it, we now know how to deal with this issue:

1. Limit the number of people invited to elicitation sessions. 
2. Elicit requirements related to one topic with one relevant group of stakeholders that includes several subject-matter experts.
3. Email all participants in an elicitation session after the meeting.

Never-ending requirements. We faced this challenge when one of our clients kept emailing our business analyst with new requirements even after elicitation sessions. To resolve the issue, the BA carefully reviewed and prioritized all additional requirements. Such an approach helped us avoid misunderstanding the value of the requested changes and define the scope of the first phase of development.

Limited access to documentation. Some clients don’t provide all the necessary documentation to a BA because of concerns about disclosing sensitive information, lost or unstructured documents, the time required to prepare the requested information, etc. However, if BAs can’t access documentation, evaluating the current state of the project will take more time. That’s why at Apriorit, we always sign non-disclosure agreements with clients and provide a reason for each information request.

Focus on solutions instead of requirements. During elicitation sessions, stakeholders may start discussing the details of solutions (checkboxes, buttons, etc.) instead of requirements. To keep the focus on requirements, our business analysts often ask themselves during meetings, Are we talking about what to do or how to do it? It’s important to remember that stakeholders should explain what they want to be done; it’s the developer’s job to figure out how to do it.

Conclusion

To be effective, software requirements elicitation requires close collaboration between the client, contractors, and a professional business analyst to manage the process. Requirements elicitation is a vital stage of software development. Unclear or incomplete requirements will inevitably lead to a lengthy development process, a need to rework parts of the solution, and budget overruns.

To avoid these pitfalls, Apriorit has a team of experienced business analysts that enhance our managed development teams or work on projects independently. Their goal is to create a shared understanding of the specifics of a project among stakeholders and developers.

If you’re planning a complex project and need an experienced business analyst to streamline communications and facilitate development, feel free to contact us!