Mastering Requirements Elicitation

Requirements elicitation is a critical step in any project, as it involves gathering the information necessary to define what stakeholders need from a system, process, or solution. Effective elicitation ensures that the final deliverable aligns with business goals and stakeholder expectations.

Photo by Techivation on Unsplash

Why is Elicitation Important?

• Aligns Goals: Ensures the project delivers value by addressing real stakeholder needs.
• Reduces Risks: Prevents scope creep and misunderstandings by clarifying expectations.
• Guides Development: Serves as a foundation for design, development, and testing.

Core Principles of Elicitation

1. Engagement: Actively involve stakeholders to gather diverse perspectives.
2. Clarity: Aim for unambiguous and actionable requirements.
3. Iteration: Revisit and refine requirements as the project evolves.
4. Collaboration: Foster open communication among stakeholders.

Elicitation Planning Concepts

Proper planning is essential to ensure elicitation activities are efficient and effective.

1. Define Objectives

• Identify what you need to achieve during elicitation.
• Example Objective: Understand the challenges sales teams face in accessing customer data.

2. Identify Stakeholders

• Determine who has input, influence, or is affected by the project.
• Example Stakeholders: Managers, end-users, IT staff, and external partners.

3. Select Elicitation Techniques

Choose techniques based on the project’s complexity, stakeholders, and available resources.

Common Techniques:

• Interviews: Best for in-depth understanding of individual perspectives.
• Workshops: Useful for collaborative brainstorming and consensus-building.
• Document Analysis: Ideal for understanding existing processes and identifying gaps.
• Prototyping: Helps stakeholders visualize potential solutions.
• Observation: Reveals actual workflows and identifies hidden needs.

4. Define Scope and Boundaries

• Clearly outline what the elicitation process will and will not cover.
• Example Scope: Focus on CRM features for customer data management, excluding marketing automation.

5. Develop an Elicitation Plan

A structured plan ensures elicitation activities are organized and productive.

Key Components:

• Activities: List of elicitation tasks (e.g., interviews, surveys).
• Timeline: Schedule for completing activities.
• Resources: Tools, documents, or personnel needed.
• Stakeholder Roles: Define each stakeholder’s involvement.

6. Manage Logistics

• Schedule sessions at convenient times for stakeholders.
• Ensure required tools (e.g., collaboration software, recording devices) are available.

Elicitation Best Practices

Prepare Thoroughly:

• Understand the business context before engaging stakeholders.
• Develop questions or discussion points in advance.

Communicate Clearly:

• Use language that stakeholders understand.
• Avoid jargon or overly technical terms unless the audience is technical.

Be Flexible:

• Adapt to stakeholder availability and feedback.
• Be prepared to switch techniques if the chosen method isn’t effective.

Document Immediately:

• Record insights promptly to avoid losing critical details.
• Use templates or tools to standardize documentation.

Validate Findings:

• Share documented requirements with stakeholders to confirm accuracy.
• Address discrepancies or ambiguities early.

Example: Elicitation Planning for a CRM System

Objective: Identify features needed to improve customer engagement tracking.

Stakeholders: Sales team, customer support, marketing, IT department.

Techniques:

• Interviews with sales representatives to understand daily challenges.
• Workshops to prioritize must-have CRM functionalities.
• Analysis of current customer data management workflows.

Plan:

• Conduct five stakeholder interviews over two weeks.
• Schedule a two-day workshop for requirement prioritization.
• Document findings and validate with all stakeholders.

Sample Interview Questions for Requirements Elicitation

Interviews are a fundamental tool for gathering detailed and nuanced insights from stakeholders. Below are categories of interview questions and examples to help uncover specific requirements and challenges.

Understanding Current Processes

• “What are other ways you accomplish this goal?”
• “What purpose is accomplished by using the product or process?”
• “Tell me about your frustrations with this process.”
• “What equipment, tools, templates, and inputs do people need to use it?”

Exploring Pain Points and Challenges

• “What makes a good day? A bad day?”
• “What failures cause the organization the most pain?”
• “If you could wave your magic wand and make it different, what would the process look like?”
• “What didn’t I ask that I should have?”

Identifying Improvements

• “If we could only change one thing in the process, what should it be?”
• “What standards or regulations should we be aware of?”
• “What information do you wish you had to make better decisions?”

Determining Requirements and Constraints

• “What purpose does this tool/process fulfill?”
• “What people do you share information with?”
• “How long should tasks take?”
• “What are the minimum capabilities the system must have?”

Long-Term Vision and Expectations

• “Where do you see the organization heading, and how can this product/process support that?”
• “What trends or future needs should we plan for?”

Validating Assumptions

• “Does this solution align with how you work now?”
• “What are the risks of not addressing these challenges?”
• “Can you confirm if this requirement is critical or a nice-to-have?”

Tips for Using Interview Questions

1. Start Broad, Then Go Deep: Begin with general questions to build rapport, then ask more specific questions.
2. Listen Actively: Take notes and ask follow-up questions to clarify or expand on responses.
3. Tailor Questions to Roles: Customize the questions based on the stakeholder’s role and perspective.
4. Use Open-Ended Questions: Encourage detailed responses and avoid yes/no answers.
5. End with Reflection: Allow the interviewee to add anything they feel is important by asking, “What didn’t I ask that I should have?”

These questions can uncover critical insights, allowing business analysts to document meaningful requirements and deliver solutions that address real stakeholder needs.

Surveys: Best Practices for Requirements Elicitation

Surveys are a powerful tool for gathering requirements, especially when dealing with large or dispersed groups of stakeholders. When designed and executed correctly, surveys can provide valuable insights that inform project decisions.

Why Use Surveys for Elicitation?

• Efficiency: Quickly gather input from a large group.
• Standardization: Collect consistent data across stakeholders.
• Anonymity: Encourage honest feedback, especially for sensitive topics.
• Scalability: Reach stakeholders regardless of location.

Best Practices for Conducting Effective Surveys

Define Objectives Clearly

• Be specific about what you want to learn from the survey.
• Align survey questions with project goals and stakeholder needs.
  Example Objective: Identify the most requested features for a new CRM system.

Know Your Audience

• Understand the demographics, roles, and familiarity of the respondents with the project.
  Tip: Tailor the language and focus of the survey to match your audience. Avoid jargon if respondents are non-technical.

Use a Mix of Question Types

Close-ended Questions: Provide specific choices to quantify data.

• Example: Rate the importance of automated reporting in the CRM (1 = Not important, 5 = Very important).

Open-ended Questions: Allow respondents to elaborate or share unique insights.

• Example: What is your biggest frustration with the current CRM system?

Ranked Questions: Ask participants to rank features or priorities.

• Example: Rank the following CRM features in order of importance: 1. Reporting, 2. Customer Data Integration, 3. Mobile Accessibility.

Keep It Short and Focused

• Limit surveys to 10–15 questions to respect respondents’ time.
• Focus only on questions that will directly inform project decisions.
  Tip: Use branching logic to show follow-up questions based on prior answers.

Use Clear and Neutral Language

• Avoid leading questions that could bias responses.
  Bad: “Don’t you think CRM automation is essential?”
  Good: “How important is CRM automation for your workflow?”
• Ensure questions are unambiguous and easy to understand.

Pilot Test the Survey

• Share the survey with a small, representative group to identify confusing or unnecessary questions.
• Use feedback to refine questions and structure.

Choose the Right Delivery Method

• Email: Best for internal stakeholders or existing contacts.
• Online Platforms: Tools like Google Forms, SurveyMonkey, or Typeform make distribution and analysis easier.
• In-app Surveys: Useful for collecting feedback from active system users.

Provide Context

Include an introduction explaining:

• The purpose of the survey.
• How the data will be used.
• The estimated time to complete the survey.

Ensure anonymity if appropriate to encourage honest feedback.

Incentivize Participation

• Offer a small reward (e.g., gift cards or recognition) to increase response rates.
• Emphasize how respondents’ feedback will directly influence project outcomes.

Analyze and Act on Results

• Aggregate and summarize data to identify trends, outliers, and key insights.
• Share a summary of the findings with stakeholders to show their input is valued.
• Use the results to prioritize requirements or validate assumptions.

Common Mistakes to Avoid

• Overloading with Questions: Too many questions reduce completion rates.
• Complex Question Formats: Avoid confusing scales or ambiguous response options.
• Ignoring Non-Responders: Follow up politely with reminders to increase participation.
• Failure to Validate: Validate survey findings through other elicitation techniques (e.g., interviews, workshops).

Example: CRM Survey Questions

Close-ended:
On a scale of 1–5, how satisfied are you with the current CRM system?

Open-ended:
What additional features would you like to see in the new CRM?

Ranked:
Rank these CRM benefits in order of importance: Improved Reporting, Faster Data Access, Mobile Integration.

Multiple Choice:
Which of the following CRM integrations are most important to your role? (Select all that apply.)

Surveys, when designed thoughtfully and used as part of a broader elicitation strategy, can uncover valuable insights that align solutions with stakeholder needs.

Documentation Review: What Is It?

Documentation review is a requirements elicitation technique used to analyze and evaluate existing documentation to gather relevant information for a project. This method helps identify useful insights, requirements, or constraints that may already be recorded in various forms, such as policies, contracts, user manuals, or technical specifications.

Purpose of Documentation Review

• Uncover Existing Requirements: Find requirements that have already been documented in previous projects or organizational records.
• Identify Gaps: Determine missing or outdated information to refine or validate requirements.
• Understand Context: Gain insights into the business processes, systems, and regulations affecting the project.
• Ensure Consistency: Verify that new requirements align with existing policies, procedures, or standards.

When to Use Documentation Review

• At the start of a project to gather baseline information.
• When formal documentation is available and relevant to the project.
• To understand historical context or lessons learned from previous initiatives.
• When verifying compliance with regulations, contracts, or standards.

Steps in Conducting a Documentation Review

1. Define Objectives

Determine what you want to achieve from the review (e.g., identify constraints, validate requirements, uncover gaps).

2. Identify Relevant Documentation

Examples of documents to review:

• Business plans
• Process workflows
• System architecture diagrams
• Regulatory or compliance standards
• User guides or training materials
• Meeting minutes
• Policies and procedures

3. Gather and Organize Documents

• Collect all relevant documents from stakeholders, systems, or repositories.
• Ensure you have the most recent versions of the documents.

4. Review Content Thoroughly

Look for:

• Explicit requirements or constraints.
• Assumptions or dependencies.
• Business rules or objectives.
• Technical specifications or system limitations.
• Lessons learned or known issues from past projects.

5. Summarize Findings

• Extract and organize key information relevant to the current project.
• Highlight inconsistencies, conflicts, or gaps in the documentation.

6. Validate Findings with Stakeholders

• Discuss your findings with relevant stakeholders to confirm accuracy and relevance.
• Use the feedback to refine the extracted requirements or assumptions.

Benefits of Documentation Review

• Time-Efficient: Leverages existing information, reducing the need to start from scratch.
• Cost-Effective: Saves resources by reusing documented knowledge.
• Thorough: Helps ensure no critical information is overlooked.
• Supports Compliance: Ensures adherence to regulations, standards, or contractual obligations.
• Contextual Understanding: Provides a foundation for more informed discussions with stakeholders.

Challenges of Documentation Review

• Outdated Information: Documents may not reflect current practices or needs.
• Incomplete Records: Information might be missing or insufficiently detailed.
• Ambiguity: Written requirements may lack clarity or be open to interpretation.
• Overload: Large volumes of documents can be overwhelming without clear focus.

Best Practices for Documentation Review

• Prioritize Key Documents: Focus on those most relevant to the project goals and stakeholders.
• Collaborate with SMEs: Engage subject matter experts to clarify ambiguous or technical content.
• Use a Checklist: Ensure no critical areas are overlooked during the review.
• Document Findings Clearly: Summarize insights in a format that’s easy to reference.
• Validate Regularly: Confirm the relevance and accuracy of findings with stakeholders to avoid relying on incorrect assumptions.

Examples of Documentation Review Scenarios

1. CRM Implementation: Reviewing existing process maps, customer feedback reports, and legacy system documentation to identify feature gaps.
2. Government Project: Analyzing regulatory guidelines and past project reports to ensure compliance and alignment with public policies.
3. IT System Upgrade: Reviewing system architecture diagrams and vendor contracts to identify dependencies and constraints.

Documentation review is an essential step in eliciting and validating requirements, especially when existing records hold valuable insights. It sets a solid foundation for more focused and effective stakeholder interactions.

How to Conduct Effective Elicitation

Requirements elicitation: a brief overview

Watch Your Step! Getting Right: A Practical Guide For Requirements Elicitation and Analysis

If you found this article insightful and want to explore how these technologies can benefit your specific case, don’t hesitate to seek expert advice. Whether you need consultation or hands-on solutions, taking the right approach can make all the difference. You can support the author by clapping below 👏🏻 Thanks for reading!

Oleh Dubetsky|Linkedin