8 Powerful Methods for Better Requirements Elicitation

Document a clear project vision

Central to the software requirements elicitation process, is a clear project vision. It is important for a business to have a clear understanding of the goals for the software development process in order to achieve a realistic and attainable set of requirements. Without a clear project vision from the product leader or business analyst, the team may face difficulties in understanding the desired outcome and the overall purpose of the project. This can lead to misaligned expectations, poor communication, and wasted resources as team members work towards different goals or pursue tasks that do not contribute to the project's success.

To define your vision, utilize a template that outlines the vision statement, target user groups, users’ needs, the product description, and relevant business goals.

Compiling this information into a single document will allow you to easily communicate and align stakeholders around the vision. Use it to engage stakeholders from various departments, such as product management, development, design, and business, to ensure a comprehensive understanding of the project's goals.

Survey or interview existing users

Surveys and interviews with existing users can be an effective tool for requirements elicitation because they provide direct input from the people who actually use the product or system. By gathering feedback from users, teams can better understand their needs, preferences, and pain points, leading to more accurate and useful requirements elicitation techniques.

To conduct live user interviews:

• Identify a diverse group of users who represent various perspectives, roles, and levels of expertise with the software.
• Prepare a list of open-ended questions that focus on users' experiences, needs, pain points, and expectations. Be sure to also ask about any workarounds they may have developed to deal with existing issues.
• Schedule interviews, ensuring that participants have ample time to share their insights and feedback.
• Record and analyze the information collected during the interviews, identifying common themes and trends that can help inform the project's requirements.

Alternatively, the team can develop a survey for users to complete in their own time.

To conduct user surveys:

• Develop a survey that includes questions related to users' satisfaction with the current software, any challenges they face, and their suggestions for improvement.
• Distribute the survey to a large sample of users to ensure diverse feedback.
• Collect and analyze survey responses, looking for patterns and trends that can help the team understand users' needs and preferences, as well as any areas where the existing software may fall short.

Observe users in a focus group

Observing users, also known as user observation or contextual inquiry, can be a valuable requirements elicitation technique. In comparison to user interviews or surveys, user observation relies on uninterrupted observation of users interacting with the software.

Typically, user observation falls into one of two categories:

1. Live observation
2. Screen-recorded observation

Whether the observation is done live in focus groups or a user’s interactions are recorded and observed later, this process can provide a unique window into the user’s natural (or pseudo-natural) environment, shedding light on their needs, pain points, and usage patterns.

To conduct user observations:

• Identify the user groups and contexts: Work with your business analysts or product leaders to determine which user groups are relevant to the project and the different contexts in which they use the product or system. This may include various roles, environments, or tasks.
• Plan the observation sessions: Develop a plan for observing users, including the selection of participants, the scheduling of sessions, and the methods for documenting observations.
• Conduct the observation sessions: Observe users as they perform tasks and interact with the product or system in their natural environment. Avoid interrupting or influencing their actions, as the goal is to capture authentic user behavior.
• Take detailed notes: Document the observation sessions by taking manual notes, using a screen recording software, or by using audio/visual equipment. Pay attention to users' actions, the sequence of steps they take, any difficulties they encounter, and their overall satisfaction or frustration with the product or system.

Use the insights to guide discussions, crystalize acceptance criteria, and prioritize business requirements.

PRO TIP: Use a user observation tool like Heap to gather user observation data systematically. Heap is particularly successful at providing a simple, easy-to-use experience for users, while allowing project leaders to track user behavior quickly and easily with integrated session replay.

Using a tool like this will help to:

• Streamline the data collection process
• Enable user observation at scale
• Allow team members to replay user sessions as many times as needed
• Reduce the influence on users of a live observer watching over their shoulder

Brainstorm with stakeholders

Brainstorming doesn’t have a good reputation, but, when done effectively, it can be a great way to collaborate and gather meaningful input from users, management, business stakeholders, and technology teams.

To host a brainstorming session:

• Decide who to focus on: While you could, theoretically invite a mix of different groups, it’s best to narrow your focus on one set of key stakeholders at a time. This will help people to feel more comfortable and confident sharing their input, and allow you to have more success with eliciting requirements from your group.
• Set clear objectives: Define the goals of the brainstorming session, such as identifying user needs, defining the technical aspect of the project, or prioritizing features. Make sure you have aligned your business objectives appropriately to your audience.
• Encourage open communication: Create an environment where everyone feels comfortable sharing their ideas and opinions, even if they differ from the majority. When in doubt, go round-robin and ask each team member for input directly.
• Use facilitation techniques: Employ techniques such as mind mapping, affinity grouping, or dot voting to organize ideas and identify common themes.
• Review the ideas: Work with the project team to compare the ideas generated from the brainstorming session with the product backlog and existing functional and technical requirements.

Conduct an interface analysis

Interface analysis can be used to examine the interactions between a system and its various interfaces, such as user interfaces, system-to-system interfaces, and interactions with 3rd-party solutions. The goal of interface analysis is to identify the detailed requirements and design considerations for each interface to ensure a seamless, efficient, and user-friendly experience.

Interface analysis generally requires the input of the development team or others who have technical knowledge of the system and a deep understanding of how it interfaces with other systems.

To conduct an interface analysis:

• Identify interfaces: List all the interfaces that the system will have, including user interfaces, system-to-system interfaces, and interactions with external entities. Include contact with APIs and databases.
• Understand users and use cases: Determine who will be using each interface and investigate the tasks they need to perform or the information they need to access.
• Analyze functionality: Investigate the features and functions required for each interface to support the identified use case or user story. This may include the layout, navigation, controls, input fields, and other UI elements, as well as data exchanges between the system and other components. Use requirements management tools like ClickUp or Jira to systematically document the requirements.
• Determine data requirements: Identify the data that each interface needs to exchange with the system, such as input data from users or data sent to other systems. Be specific when defining the requirements and acceptance criteria scenarios, so that the developers understand exactly what is required.

Create user stories

One of the more traditional methods of requirements engineering is by writing user stories. It can be used at all stages of development to focus on the user's perspective and what they aim to achieve with the system. User stories are concise and written in plain language, making them accessible to all the stakeholders - both technical and business. They’re really a great way to capture user requirements in a consistent, easy to understand way.

To create user stories:

• Identify users: Determine the different user types or roles that will interact with the system. Work with the product owners to narrow in on specific categories of users, so you can more easily draft stories to match.
• Understand user needs: For each user type, identify their goals, objectives, and the tasks they want to accomplish using the system.
• Write user stories: Create user stories using a simple, non-technical language, typically following the format: "As a [user role], I want to [action], so that [benefit]."
• Break down complex stories: Split larger user stories into smaller, more manageable parts, also known as "epics" and "subtasks."

Reverse engineer processes

One of the most effective requirements elicitation techniques is reverse engineering processes. This is a great way to uncover hidden requirements, ensure valuable existing processes are not lost, and identify potential process redundancies. This method involves analyzing and deconstructing existing processes to understand their underlying structure, functionality, and purpose.

To reverse engineer processes:

• Identify processes: Review existing documentation to determine the processes within the current system that need to be analyzed and understood. Focus on processes that are critical to the system's operation or have a significant impact on user experience.
• Document processes: Thoroughly document the current processes, capturing their sequence, inputs, outputs, and involved actors. Use visual aids like flow charts or diagrams to represent the flow of data and actions within the processes.
• Identify unknown requirements: Examine the processes you have documented to identify requirements that may not have been mentioned by stakeholders or users during other requirements gathering techniques.
• Preserve valuable processes: Ensure that valuable and well-functioning processes are not lost during the development of new systems or improvements.

Conduct document analysis

Teams can conduct document analysis during the requirements elicitation process to gain a comprehensive understanding of the existing system, processes, and user needs. This method involves reviewing various forms of documentation to identify requirements, constraints, and opportunities for improvement.

Key documentation to analyze includes:

• Training manuals: Guides used to train users on the existing system or software, providing insights into how the current system operates and the tasks users need to perform.
• Standard Operating Procedures (SOPs): Detailed instructions on how to carry out specific tasks or processes, highlighting the current workflow and any potential areas of improvement.
• System or technical documentation: Information on the current system's architecture, data structures, algorithms, and technologies, providing an understanding of the underlying infrastructure and design constraints.
• User guides or help documents: Resources that assist users in navigating and using the existing system, offering insights into common user challenges and potential usability improvements.
• Project management documentation: Records of previous project requirements, scope, timelines, and constraints, which can help identify lessons learned and prevent the same issues from arising in the new project.
• Meeting minutes or stakeholder communications: Documentation of previous discussions, decisions, and agreements related to the project, providing context and rationale for certain requirements or constraints.

Requirements elicitation challenges

Conducting a successful requirements elicitation process can prove to be a complex and time consuming process as it requires skillful business analysis and the ability to effectively translate the needs of both the business and end-users into clear and actionable requirements. Businesses should be prepared for many challenges, including:

• Poorly defined project: It’s very common for a team to have a general project idea but for it to not be fully developed at the time requirements elicitation begins. This can prove challenging if the scope of the project drastically changes during development.
• Conflicting requirements: Stakeholders may have imprecise or conflicting requirements, making it challenging to determine which requirements (or requests) should be prioritized.
• Changing requirements: As software development progresses, requirements can evolve due to shifting business environment needs, market conditions, or advancements in technology. Some of this is unavoidable, but it can certainly create difficulties for the project team to manage.
• Technical complexity: The more technically complex the project is, the more challenging it will be to appropriately scope out the project, define user needs, and elicit requirements. Teams may require additional technical (rather than just business-side) support for more complex projects.