Requirements & Requirements Management

A Guide to Requirements Elicitation for Product Teams

By |

a-guide-to-requirements-elicitation-for-product-teams

 

The success of a development project relies on understanding the business need and defining the correct list of requirements. Requirement elicitation is the process of communicating and collaborating with key stakeholders to assemble the insight and identify the project’s needs.

This article will provide an overview of why requirements elicitation is important for product teams, discuss different elicitation techniques, and outline the steps involved in eliciting requirements.

What is requirements elicitation?

Business analysts conduct requirements elicitation to identify the business need, scope, assumptions, and risks of a project based on data from key stakeholders. It’s an imperative part of requirements management as the outcome impacts the fundamental understanding of the project’s goal. Failure to clearly define business needs can lead to catastrophic results such as expensive mistakes or system failure.

The importance of requirements elicitation for product teams

Requirements elicitation is important for product teams because it is the main way product requirements are identified. The elicitation process unearths requirements insights from key stakeholders. By expertly asking the right questions of subject matter experts, enabling deep conversations, and recording findings, business analysts discover the true business needs to drive the project.

In the absence of properly identified business needs and requirements, development costs will be over budget due to rework, users/customers will not get what they want, and projects will be unsuccessful.

The requirement elicitation process

An effective elicitation process is important for product teams to realize the following benefits:

  • Lower project costs by catching requirements problems before development begins.
  • Increase the likelihood that users and customers get what they want.
  • Reduce the risk of project failure.

RELATED POST: Requirements Management Maturity Model – Empirical vs Theory

There are five main steps to the requirements elicitation process:

  1. Gathering requirements

You may be thinking, “How is requirements elicitation different from requirements gathering?” especially when the two terms are often used interchangeably. It is a good question, and it is acceptable to casually interchange them. However, there is a slight difference between gathering requirements and requirements elicitation that is worth pointing out when discussing the specifics of the requirements elicitation process.

By definition, “gathering” is the act of collecting from scattered sources, while “eliciting” is the act of drawing out information from a source. Both acts are essential to the overall process of requirements elicitation and take expertise to execute properly.

An effective way to prepare for requirements elicitation is for business analysts to gather all available requirements and study them for insights. A few techniques for requirements gathering include:

  • Document analysis, such as studying process models or researching regulations.
  • Analyzing system interfaces and business rules.
  • Reading available user feedback.

The findings from requirements gathering can help identify key stakeholders and inform which requirements elicitation techniques might best suit the project. Business analysts can then begin the work of drawing out the enlightening experiences that fill in the missing requirements. Therefore, requirements gathering is the perfect first step in the process of requirements elicitation.

  1. Identifying key stakeholders

As noted, requirements gathering can provide insight on relevant stakeholders. It is important to identify the right people up front so everyone can begin on the same page. Doing so eliminates the need to fill in missing requirements later that could potentially change the course of the project.

  1. Eliciting requirements from key stakeholders

In this part of the process, business analysts need to determine which requirement elicitation techniques will provide the best results given the project at hand and appropriate stakeholders.

There are a variety of requirement elicitation techniques, here are some of the most popular methods.

Brainstorming –

Use case: Current solutions may not be innovative enough to meet the project’s goal.

Designed to: Uncover new, innovative ideas and solutions.

How to: Assemble a mix of key stakeholders for an open conversation on innovative ideas and solutions. As facilitator, the business analyst ensures that the conversation stays on topic and records ideas discussed.

Focus groups –

Use case: Business analysts need more information about specific aspects of the project. Time is short.

Designed to: Help stakeholders be more forthcoming and articulate solutions. Get a lot of information at once.

How to: Gather representatives from stakeholder groups. The facilitator asks questions to get team members to discuss specific areas of interest and records ideas discussed.

Interviews –

Use case: Get an in-depth perspective from a specific subject matter expert (SME).

Designed to: Obtain a stakeholder’s one-on-one insight on the business need or viability of given solutions.

How to: Create questions that will allow the SME to be open about the issues on the table. Questions can be shared in advance or be conducted as a conversation. The interviewer should take notes and share them with the SME to ensure he or she correctly understood the SME’s point of view.

Observation –

Use case: When the development project is an augmentation of a current work process.

Designed to: Provide a direct view of how a stakeholder performs a particular process.

How to: Observation can be conducted passively—the facilitator watches the stakeholder work without interrupting—or actively—the facilitator asks questions about the work as it is being performed. In both cases, the facilitator should take notes and get feedback from the stakeholder on the information collected.

Prototyping –

Use case: When stakeholders do not understand written technical requirements and would benefit from seeing a version of the product.

Designed to: Collect feedback from non-technical stakeholders by showing them an example with which they can physically interact.

How to: At first prototyping can be executed via storyboard, interactive screen, virtual mock-up, navigation flow, etc. The exact method depends on the project, but it is usually an iterative process that is improved based on input. As more requirements come forward, more detailed prototypes are created to ensure they meet the expectations as recorded.

Requirements workshops –

Use case: When time is short, and the business need is not clear.

Designed to: Get the stakeholders together in a structured, time-based setting to elicit, refine, and edit requirements. Stakeholders can discuss and provide immediate input on identified business needs.

How to: Set a specific timeframe and agenda for the workshop. Include brainstorming, focus group, and prototyping (if applicable) opportunities within the schedule. Use these to guide the discussion and record input.

Surveys –

Use case: When business analysts need data from large groups of participants.

Designed to: Obtain objective feedback from large groups of customers or end-users.

How to: Choose participants wisely based on desired criteria. Create clear questions that do not lead the respondents. Questions can have a number of finite choices or be open-ended—for best results consider the goal of the question, as well as the number of respondents, to determine the best structure for proper analysis.

As is often the case, a variety of requirements elicitation methods can be employed to unearth the business needs of a project. For example, a business analyst may ask specific requirements questions in a focus group, in a brainstorming session, or during observation. A business analyst may also conduct surveys before a requirements workshop, or create a prototype to be used during observation. Knowing which elicitation techniques to use for a given project comes with experience.

  1. Documenting requirements

The next step in the requirement elicitation process is documenting the requirements elicited thus far. There are a variety of formats for documenting requirements: a home-grown product requirements document (PRD), a government-mandated system requirements specification, a requirements management tool like Jama Connect, a spreadsheet, etc. The best tool for documenting requirements depends on the project.

If the project has many stakeholders, complex development, or compliance or functional safety standards, it’s a best practice to choose a requirements management tool like Jama Connect. These are purpose-built to mitigate risks associated with complex systems and regulatory compliance. Assessing needs and researching functionality will help determine the best option for the project

  1. Confirming the findings

Once business analysts document the requirements, it is time to make sure they are recorded correctly. Requirements are sent to all stakeholders to review so there is a collective understanding of what’s being developed. Stakeholders are likely to make refinements. It is also possible that this step elicits further requirements, which will necessitate revisions before approval can take place.

RELATED POST: Requirements Management – Living NOT Static

Business analysts conduct the process of requirements elicitation at the beginning of a project, and the process is ongoing throughout the development process. This is because change is always occurring and it’s never possible to know all the questions to ask or have all the correct answers upfront.

Challenges of successful requirement elicitation

The elicitation process may seem easy: ask the stakeholders what they want. However, it’s a much more rigorous endeavor. Here are some of the most common challenges of the requirements elicitation process.

Finding the right stakeholders – Identifying the correct subject matter experts isn’t always easy. Hunt down “hidden” stakeholders who can be excellent sources of knowledge. Examples include customer-facing personnel like sales/support reps and maintenance techs.

Uncovering the best insights – Unfortunately, stakeholders don’t always know what they want. In the practice of requirements elicitation, multiple elicitation methods can be used concurrently to identify the business need and an optimal list of requirements. The expertise is in realizing the best combination of techniques to yield success for that development project.

Documenting the requirements – Using the wrong documentation tool for the job can be detrimental. Issues can arise with everything from reviews and approvals to managing change. Spreadsheets or home-grown PRDs may work for smaller, non-regulated projects. Complex products or those in regulated industries, on the other hand, greatly benefit from requirements management software that can streamline requirements elicitation and the overall process with features like live traceability and compliance management.

Planning for change – Priorities shift and problems arise—it’s best to plan for changes up front. Be sure to have a process in place that allows time to address problems, document changes, and add new requirements, and conduct additional reviews.

Again, in projects with fewer requirements, it won’t be so grueling to scour spreadsheets or PDRs to manage change. However, this kind of manual change management can still eat up many work hours and push projects off schedule and off budget. With complex and regulated products, however, the potential for waste of time and money is much larger. In these cases, a tool like Jama Connect can save precious time and budget in the face of change. Having the right tool for the job is critical.

Streamlining the requirements elicitation process

Requirements elicitation is a mixture of art and science for business analysts. They need to be adept at knowing which questions to ask and how to ask them. Additionally, business analysts must be able to clearly communicate and collaborate with key stakeholders during all phases of the elicitation process.

Business analysts working on complex or highly regulated projects cannot rely on home-grown PRDs or spreadsheets to document requirements. The level of sophistication in which they are working demands that they have the best requirements elicitation tools at their fingertips.

Jama Connect is a requirements management tool that can transform how business analysts perform requirement elicitation for complex projects. See how Jama can streamline requirements elicitation and management.


Jama Software
Latest posts by Jama Software (see all)