Sitemap
Press enter or click to view image in full size
Photo by Emily Morter on Unsplash

Requirements Elicitation and Analysis

9 min readAug 18, 2024

--

In today’s fast-paced and ever-evolving business landscape, the success of any project hinges on a clear and accurate understanding of what stakeholders truly need. Requirement elicitation and analysis are pivotal processes that lay the foundation for effective project planning and execution. Whether you’re developing a cutting-edge software application, launching a new product, or optimizing existing methods, gathering and analyzing requirements accurately is crucial. In this article, I will explore the essential techniques, challenges, and best practices for mastering requirement elicitation and analysis, highlighting their role in driving successful project outcomes.

Requirement elicitation and analysis can be considered both a soft skill and a technical skill, depending on the context in which it’s applied.

  • As a Soft Skill: The process of requirement elicitation involves communication, active listening, empathy, negotiation, and collaboration with stakeholders. These aspects are deeply rooted in interpersonal skills, making it a soft skill.
  • As a Technical Skill: On the other hand, the analysis part often involves more technical competencies. It requires the ability to interpret data, understand technical constraints, and translate stakeholder needs into specific, actionable requirements

Elicitation vs Analysis:

In the dynamic world of project management and product development, requirement elicitation and analysis are far from one-time tasks. Instead, they are incremental and iterative processes that evolve alongside the project’s lifecycle. As businesses and technologies rapidly change, so do the needs and expectations of stakeholders. This demands a flexible approach to requirement gathering — one that allows for continuous refinement, feedback incorporation, and adaptation to emerging insights.

Elicitation:

Set of techniques used in discovery and progressive elaboration of understanding the needs of stakeholders and customers. Progressive Elaboration means guiding the stakeholder through each layer of details. There are mainly four steps:

1- Understand the problem and opportunity

2- Understand the user goals: Who-What-Why?

3- Understand each goal to uncover more details

4- Understand the details needed for each goal

Key Mindsets to be successful:

1- Keep on building the right things for customers

2- Collaboration skills to open stakeholder’s minds → Visual and Conversational way will be better

3- Understand and embrace your role → Business and Technology

Elicitation Techniques:

Requirement elicitation is the systematic process of identifying, gathering, and understanding the needs, expectations, and constraints of stakeholders for a project or system. It involves engaging with various stakeholders — including customers, users, managers, and technical teams — to capture their requirements in a clear, unambiguous, and actionable manner. The goal of requirement elicitation is to ensure that the project team fully comprehends what stakeholders need and expect, enabling the design and development of a solution that meets those requirements.

Get Samet Girgin’s stories in your inbox

Join Medium for free to get updates from this writer.

There are mainly five elicitation techniques:

  • Interviews
  • Observations
  • Experiments
  • Workshops
Press enter or click to view image in full size
Main Requirement Elicitation Techniques used
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
Interview Questions

The observation technique is a method used in requirement elicitation to gather information by directly watching how users interact with a system, process, or environment.

  • Passive Observation: The observer does not interact with the users and simply watches their activities from a distance. This approach minimizes the observer’s influence on user behavior.
  • Active Observation: The observer may ask questions, interact with users, or participate in the process to better understand specific tasks or challenges. This approach provides deeper insights but may also influence user behavior.

Experiment means testing ideas, assumptions, and key theories that drive requirements for the product and system. Unknown, ambiguous, and changing requirements are the right time to use experiments.

  • Isolate what you want to learn

Workshops: Modern requirements workshops are not about gathering and documenting requirements. They’re about eliciting, and strategically drawing out information from stakeholders and customers. Our goal is to develop workshops that include high-impact collaboration, deep dialogue, and learning as well as exploring ideas and details.

  • Define the goals
  • Determine who needs to attend the workshop and what will their role be.
  • Discuss the agenda of the workshop
  • Design the workshop

How to achieve a successful workshop:

  • Be a neutral facilitator
  • Promote divergent thinking
  • Help the team make decisions
  • Keep everyone focused

Analysis Techniques

  • Product analysis resembles a tree with branches of functionality and details, aiming to connect these elements to understand their value for users and systems.
  • Effective analysis involves uncovering both big-picture insights and detailed nuances, ensuring stakeholder alignment and high-quality requirements through diverse techniques like modeling, dialogue, and diagramming.
  • Process modeling is about creating a visual to explain a process or sequence of activities. It takes a lot of good conversations to deliver valuable solutions.
  • You can use process models to ignite dialogue on the team, see where details fit into the big picture, visualize the process, organize requirements information, and analyze various detailed aspects of the product, system, or process.
  • Business requirements work is more about the conversation, and to support good conversations, process models need to be simple. Stakeholders and the team need to be able to read and understand the models intuitively, without a tutorial.
  • Here are my favorite go-to principles when using process models. First, know what you are modeling. Next, the best process models progressively elaborate and are built in layers. Make it action-oriented and be specific.
Press enter or click to view image in full size
Press enter or click to view image in full size
Words to avoid and words to use
  • Context Diagram: Context diagrams are one of my favorite analysis techniques. They show the solution's big picture by providing a view of a system or product in its environment including the people and systems it interacts with.
Press enter or click to view image in full size
Press enter or click to view image in full size
  • User stories and story maps: User stories and story maps are a great technique many Agile teams use, and they can also be used for non-Agile projects, as well, as a powerful requirements technique. User stories are not meant to be a detailed requirements document that gets handed off to the development team. Instead, they are meant to spur meaningful dialog and create shared understanding. A user’s story has three pieces: the who, the what, and the why. Another way to put it, is the role, the goal, and the benefit. As user stories are created and split a story map is a great way to analyze how all of the stories fit together. Organizing user stories in a visual format helps the entire team see the forest through the trees. A story map tells the whole story versus a small part of it. It’s a technique that keeps the team focused on the user experience and results in better dialog and conversation.
Press enter or click to view image in full size
Press enter or click to view image in full size
  • Decision tables: A decision table is a structured way of representing and analyzing the logic and rules that apply to a decision-making process, particularly in requirement analysis. It helps in organizing different scenarios and corresponding actions to be taken, ensuring comprehensive coverage of all possible conditions.
  • Data Flow diagram: Data flow analysis is a critical tool for generating high-quality requirements. Without data flow analysis, customer satisfaction drops and defects rise. Users get frustrated when they don’t see the data they expect and are asked to reenter data they’ve already provided. Defects also increase when the data needed for automated decisions is not where it needs to be. It provides a big picture for the team to discuss and understand their data needs. Let’s look at an online payment example, and think about the primary processes our customers and systems need to complete.
Press enter or click to view image in full size
  • State and Sequence diagram: State diagrams show the different states something can take on. For example, your order online is in the cart, purchased, processed, shipped, or received. A state diagram shows all these states and what causes the state to change. Sequence diagrams show the interaction between people and different parts of a system. It shows the messages that get sent between the parties over time.
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
State diagram vs table and Sequence diagram

Tailoring to the Project and Product Type:

  • Blending elicitation and analysis techniques: Choosing the right requirements technique is sort of like putting together a jigsaw puzzle. But sometimes trial and error is what gets you the right fit. It requires focus, patience, and a commitment that often causes us to lose interest. Blending multiple techniques is the key to better results.
  • Elicitation and analysis are not phases of a project. Elicitation looks to discover information and analysis looks to find areas where there is more to be discovered.
  • 4 Steps: Collaborate, Discuss changes, Create diagrams, Clarify and find gaps
  • The table below will help you blend elicitation and analysis techniques and align them to the appropriate situations.
Press enter or click to view image in full size
Press enter or click to view image in full size
  • New processes, products, and systems: When building a new process, product, or system it’s critical to keep the vision of the solution in mind. It’s easy for the team to start to drift into requirements that are not aligned with the vision. It’s easy to recreate the past when we’re trying to create the future. So make sure the vision is a consistent focus of the team discussions. The team will also need to pay close attention to other requirements aspects. Here are some things to keep in mind: nonfunctional requirements, assumptions, constraints, data relationships, business rules, human-centered design, and user experience. The two biggest risks to this type of project are lack of stakeholder involvement and lack of vision. You need the right stakeholders involved to promote the vision. You also need available stakeholders to spend time with the team to protect the vision as the requirements are evolving.
  • Adding to process, product, and system: Most backlog items and requests that business analysts work on are about adding to, or modifying a solution. Many teams have a backlog of enhancements, defects, and requests associated with existing solutions. Many enhancements are related to other enhancements and defects, so a root cause analysis and patterns are critical to making sure we are not causing even more issues. The trick is figuring out which of these many items is important and worth doing. How do we ensure that what we’re working on is the right stuff? It’s important to analyze the backlog to identify patterns. We analyze this by asking questions such as; Is each item helping us move forward, or keeping us in the past? Are there duplicates, conflicts, or many items related to a particular part of the solution? Is the same issue being reported many times in different ways? What are the root causes of each problem? Which issues limit the value that users get from the solution?
  • Buying and implementing software: First, keep your requirements focused on the user and the activities they need to accomplish with the system. Many organizations that need customizations build extension services, rather than alter the code of the purchase software. Next, make sure to understand the business rules, logic, policies, and decisions you’re looking for the system to perform. Then, make sure that the system allows you to configure and perform these rules with the needed data inputs. The last step is integration. Integrations are critical to most purchase software, as organizations want systems to exchange data to and from the purchased software.
Press enter or click to view image in full size
Press enter or click to view image in full size
Considerations for integration requirements

In conclusion, to define great requirements, it’s not enough to simply ask customers and stakeholders what they want. By leveraging requirements elicitation and analysis techniques, business analysts can come up with more innovative solutions. In this article, explore these techniques, and learn why they’re important, and how to blend them and tailor them to your project. Please comment below the article and keep following Pursuit of Data.

References:

Brainstorming LinkedIn Learning Course

Lucid Meetings: Tools for Online Brainstorming and Decision-Making in Meetings

Mind Tools: Brainstorming

--

--

Samet Girgin
Samet Girgin

Written by Samet Girgin

Data Analyst | Petroleum and Natural Gas Engineer | PMP® | Sustainability & Energy Enthusiast | Entrepreneur