7 Elicitation & Engagement

7.1 Elicitation & Stakeholder Engagement

Once the problem is defined, we must gather detailed information about needs, constraints, and context. In business analysis, this is Elicitation. In public health, it is Stakeholder Engagement or Community-Based Participatory Research. Both involve systematic approaches to learning from people who will use, be affected by, or govern the solution.

7.1.1 The Dual Framework

BA Perspective	PH Perspective
Elicitation Techniques	Community Engagement Methods
Requirements Workshops	Focus Groups, Town Halls
User Interviews	Key Informant Interviews
Document Analysis	Literature Review, Policy Analysis
Observation	Ethnography, Site Visits
Prototyping	Pilot Testing, Formative Research

7.1.2 Elicitation Techniques Mapped

7.1.2.1 Interviews

Both domains rely heavily on one-on-one conversations with knowledgeable individuals:

BA User Interviews:

Focus on workflow, pain points, desired features
Structured around use cases or process steps
Document functional and non-functional requirements

PH Key Informant Interviews:

Focus on community needs, barriers, facilitators
May explore cultural context, health beliefs
Inform intervention design and implementation strategy

CancerSurv Example

BA Interview with Registrar:

“Walk me through your typical day. What tasks take the most time? Where do you encounter errors? What features would make your work easier?”

PH Interview with Oncologist:

“How do you currently receive staging information? What data quality issues affect your treatment decisions? How could better surveillance data support tumor board discussions?”

Both interviews inform CancerSurv requirements, but from different perspectives.

7.1.3 Workshops and Focus Groups

Group sessions enable collaborative discovery:

BA Requirements Workshop:

Facilitated session with defined agenda
Uses techniques like brainstorming, affinity mapping
Produces prioritized requirement lists
Resolves conflicts through negotiation

PH Focus Group:

Semi-structured group discussion
Explores shared experiences and diverse perspectives
May surface unanticipated needs or concerns
Emphasizes inclusive participation

7.1.3.1 Document Analysis

Existing documentation provides essential context:

BA Documents	PH Documents
System specifications	Clinical protocols
Process manuals	CDC guidelines
Vendor contracts	Grant requirements
Training materials	Health education materials
Audit reports	Program evaluations

7.1.3.2 Observation

Watching work happen reveals what interviews miss:

BA Observation (Job Shadowing):

Watch users perform tasks
Note workarounds and inefficiencies
Identify undocumented processes
Time critical workflows

PH Observation (Site Visits, Ethnography):

Visit clinics, community settings
Understand context and constraints
Observe patient-provider interactions
Identify environmental factors

Gemba Walks

The Lean concept of “Gemba” (going to the actual place where work happens) applies to both domains. For CancerSurv, this means spending time in the registry office watching abstractors work, not just interviewing them in a conference room.

However, Gemba walks often fall short when designers and programmers only observe a single point in the workflow. A critical gap in many software projects is the failure to understand the complete data and document flow across all users and use cases.

7.1.3.3 Understanding the Full Workflow

A frequent and costly mistake is that software designers speak primarily with decision-makers and budget holders—often located far from the actual work. These gatekeepers may not themselves use the system daily, and they may not see the entire operational flow. The result: software that fails to support the messy, multi-stage reality of work.

The Complete Workflow Includes:

Data Generation & Collection (field operations)
- How data originates: inspections, tests, patient encounters
- Who collects it and what constraints they face
Data Intake & System Processing (data entry, administration)
- How raw data enters the system
- What validation, coding, and quality checks occur
- Who performs these tasks and their priorities
Data Preparation for External Use (records, reporting)
- How data is processed for public requests, legal discovery, or external reporting
- Admin support and customer service functions
- Regulatory and compliance requirements
Data Use by Multiple Stakeholders (analysis, management, operations)
- How frontline workers (field inspectors, registrars) use data for daily decisions
- How managers use the same data for productivity metrics, resource allocation, and accountability
- These uses often conflict—what serves operational efficiency may not serve field worker needs

Why This Matters:

Each stage has different outcomes, different focuses, and different definitions of success. Data collected by one stakeholder is processed by another and used by a third—each with distinct priorities. A system designed to satisfy the decision-maker but not these three operational groups will fail in practice.

CancerSurv Example

The Problem:

A software vendor designs CancerSurv by consulting the State Cancer Registry Director (the budget holder). The director prioritizes:

NPCR reporting compliance
Cost efficiency
Centralized system control

But the director rarely enters data or manages daily workflows. The actual system involves:

Data Generation: Hospital pathologists and surgical oncologists generate reports (often outside the system, in hospital EHRs)
Data Intake: Registrars abstract cases from hospital records into CancerSurv—manually reviewing pathology, staging, treatment
Data Processing: Admin staff validate data, perform quality checks, request missing information, deduplicate records, and prepare annual reports for CDC
Data Use (Inspection/Operations): Registrars use the system to identify missing follow-up information and flag data quality issues
Data Use (Management): The director uses dashboards to track incidence trends and ensure grant milestones are met; registry managers use the same data to evaluate registrar productivity and workload

The Disconnect:

If programmers and designers only shadow the director or attend leadership meetings, they miss critical needs:

Registrars need efficient batch workflows for large case imports (not addressed in director-focused design)
Admin staff need audit trails and error logs (not a director priority)
Registrars’ productivity data goes to managers for performance reviews—creating tension between doing quality work and doing work fast
Hospital pathologists need interoperability to send structured reports directly into CancerSurv (if this step is never observed, a manual workaround becomes permanent)

The Solution:

Before programming begins, the development team—including programmers and architects—must shadow all four phases:

Spend time in the hospital observing how pathology reports are generated and accessed by registrars
Sit with registrars as they abstract cases and manage quality issues
Work with admin staff processing data for CDC submission and responding to records requests
Interview both field registrars and managers to understand how the same data supports different decisions

Only then can the team design a system that truly serves the work, not just the budget narrative.

A Critical Principle for Both Domains:

Whether in public health or IT, the programmer or analyst who designs the system must see the complete workflow before design begins. This is not optional; it is the foundation of requirements elicitation. Skipping this step guarantees expensive redesigns, user dissatisfaction, and workarounds that undermine system integrity.

7.1.4 Engaging Diverse Voices

7.1.4.1 The Equity Imperative

Public health emphasizes inclusive engagement, ensuring marginalized voices are heard. This principle benefits IT projects as well:

Questions to Ask:

Who is missing from our stakeholder list?
Whose needs might be overlooked by “typical” users?
What barriers prevent participation (language, location, schedule)?
How do we ensure power imbalances do not silence important perspectives?

7.1.4.2 Community-Based Participatory Research (CBPR)

CBPR principles can strengthen BA elicitation:

CBPR Principle	BA Application
Community as equal partner	Users co-design, not just provide input
Build on community strengths	Leverage existing workflows that work
Balance research and action	Deliver incremental value during elicitation
Long-term commitment	Maintain relationships beyond project end

7.1.5 Translating What You Hear

7.1.5.1 From Needs to Requirements

Elicitation produces raw material that must be translated into actionable requirements:

flowchart LR
    A[Interviews<br/>Observations] --> B[Elicitation Notes]
    B --> C[Analysis &<br/>Synthesis]
    C --> D[Requirements<br/>Documentation]
    D --> E[Validation with<br/>Stakeholders]
    E --> F[Approved<br/>Requirements]

Figure 7.1: From Elicitation to Requirements

7.1.5.2 Common Translation Challenges

What Stakeholders Say	What They Might Mean	Requirement Implication
“It should be easy to use”	Current system requires too many clicks	Reduce clicks per task by 50%
“We need real-time data”	Current reports are weeks old	Dashboard updates within 24 hours
“Make it like Excel”	Users are comfortable with Excel	Familiar grid-based interface
“We need better reports”	Current reports lack specific metrics	Add [specific metric] to [report]

CancerSurv Example

Stakeholder statement: “We need the system to be faster.”

Probing questions:

Which specific tasks feel slow?
How long do those tasks take now?
What would be an acceptable time?
What happens when the system is slow?

Refined requirement: “The case search function shall return results within 3 seconds for queries returning up to 1,000 records, to support efficient case lookup during abstraction.”

7.1.6 Documentation Approaches

7.1.6.1 BA Requirements Documentation

User Stories (Agile)
Use Cases (UML)
Requirements Specifications (Waterfall)
Acceptance Criteria

7.1.6.2 PH Program Documentation

Logic Models
Intervention Protocols
Evaluation Plans
Implementation Guides

7.1.6.3 Bridging the Formats

For hybrid projects, consider dual documentation:

Audience	Format	Content
Development team	User Stories	Functional requirements in Agile format
Clinical stakeholders	Service-User Scenarios	Narrative descriptions of clinical workflows
Funders (CDC, grants)	Logic Model	Inputs, activities, outputs, outcomes
Governance	Requirements Traceability Matrix	Links requirements to objectives

7.1.6.4 When Standard User Stories Fall Short

The standard Agile user story format (“As a [user], I want [feature], so that [benefit]”) works well for many software contexts. However, it often fails to capture the nuances of clinical workflows, regulatory requirements, and public health scenarios.

Why standard user stories may not fit clinical contexts:

Clinical workflows involve conditional logic (“if this lab result, then that action”)
Regulatory requirements mandate specific timeframes and actions
Patient safety considerations require explicit protocols, not just user preferences
Public health surveillance involves system-initiated actions, not just user-initiated features

Alternative formats worth considering:

Given-Person-Should (GPS) Format:

This format emphasizes context and obligation rather than desire:

“Given [clinical/situational context], the [health worker role] should [specific action] to [health outcome].”

Example:

“Given a positive TB test result, the contact tracer should initiate household investigation within 48 hours to prevent secondary transmission.”

Situational Protocol Format:

This format ties system behavior to clinical guidelines or regulatory requirements:

“When [triggering event], the system shall [required action] within [timeframe].”

Example:

“When a laboratory reports a confirmed measles case, the system shall generate a contact list and notify the assigned epidemiologist within 4 hours.”

Service-User Scenario Format:

This narrative format describes a patient or client journey through the system:

“Maria, a 45-year-old farmworker, visits a mobile clinic for diabetes screening. She speaks primarily Spanish and has no regular primary care provider. The system must support her preferred language, connect her to follow-up care, and track her screening results for population health reporting.”

CancerSurv Example

Standard user story:

“As a registrar, I want to search for existing cases, so that I can avoid creating duplicates.”

GPS format (adding clinical context):

“Given a new pathology report for a patient who may already be in the registry, the registrar should be able to search by name, SSN, and diagnosis within 3 seconds to prevent duplicate case creation and ensure accurate incidence counts.”

Situational protocol (system-initiated):

“When a new case is entered, the system shall automatically search for potential duplicates using probabilistic matching and present candidates to the registrar for review before saving.”

Choose the format that best communicates intent to your audience. Development teams may still translate these into standard user stories for sprint planning, but starting with clinical context ensures nothing gets lost in translation.

7.1.7 Validation and Confirmation

7.1.7.1 Ensuring Accuracy

Elicitation is iterative. Validate what you heard:

BA Validation Techniques:

Requirements reviews
Prototype walkthroughs
Structured walkthroughs
Sign-off meetings

PH Validation Techniques:

Member checking (returning findings to participants)
Community review sessions
Pilot testing
Expert review panels

7.1.8 Managing Conflicting Needs

7.1.8.1 When Stakeholders Disagree

Conflicts are inevitable. Resolution approaches include:

Approach	When to Use
Prioritization	When resources are limited; use MoSCoW or weighted scoring
Negotiation	When compromise is possible without losing value
Escalation	When authority must resolve; use governance structure
Phasing	When both needs are valid; address in different releases
Alternatives Analysis	When creative solutions can satisfy both parties

CancerSurv Example

Conflict: Registrars want a simple, streamlined interface. Epidemiologists want comprehensive data fields for analysis.

Resolution: Implement a tiered interface:

Core fields (required): Streamlined view for registrars
Extended fields (optional): Available when needed
Analytics fields: Populated from other sources, not requiring registrar entry

7.1.9 Deliverables from This Phase

BA Deliverable	PH Deliverable	Purpose
Elicitation Results	Engagement Summary	Raw findings documentation
Requirements Document	Program Protocol	Detailed specifications
User Stories / Use Cases	Service-User Scenarios	Actionable descriptions
Stakeholder Feedback Log	Community Input Register	Track all input received

7.1.10 Moving Forward

With needs elicited and documented, the next phase focuses on Requirements Analysis: organizing, prioritizing, and specifying the detailed requirements that will guide solution design.

--- title: "Elicitation & Engagement" --- ## Elicitation & Stakeholder Engagement Once the problem is defined, we must gather detailed information about needs, constraints, and context. In business analysis, this is **Elicitation**. In public health, it is **Stakeholder Engagement** or **Community-Based Participatory Research**. Both involve systematic approaches to learning from people who will use, be affected by, or govern the solution. ### The Dual Framework | BA Perspective | PH Perspective | |:---------------|:---------------| | Elicitation Techniques | Community Engagement Methods | | Requirements Workshops | Focus Groups, Town Halls | | User Interviews | Key Informant Interviews | | Document Analysis | Literature Review, Policy Analysis | | Observation | Ethnography, Site Visits | | Prototyping | Pilot Testing, Formative Research | ### Elicitation Techniques Mapped #### Interviews Both domains rely heavily on one-on-one conversations with knowledgeable individuals: **BA User Interviews:** - Focus on workflow, pain points, desired features - Structured around use cases or process steps - Document functional and non-functional requirements **PH Key Informant Interviews:** - Focus on community needs, barriers, facilitators - May explore cultural context, health beliefs - Inform intervention design and implementation strategy ::: {.callout-note title="CancerSurv Example"} **BA Interview with Registrar:** "Walk me through your typical day. What tasks take the most time? Where do you encounter errors? What features would make your work easier?" **PH Interview with Oncologist:** "How do you currently receive staging information? What data quality issues affect your treatment decisions? How could better surveillance data support tumor board discussions?" Both interviews inform CancerSurv requirements, but from different perspectives. ::: ### Workshops and Focus Groups Group sessions enable collaborative discovery: **BA Requirements Workshop:** - Facilitated session with defined agenda - Uses techniques like brainstorming, affinity mapping - Produces prioritized requirement lists - Resolves conflicts through negotiation **PH Focus Group:** - Semi-structured group discussion - Explores shared experiences and diverse perspectives - May surface unanticipated needs or concerns - Emphasizes inclusive participation #### Document Analysis Existing documentation provides essential context: | BA Documents | PH Documents | |:-------------|:-------------| | System specifications | Clinical protocols | | Process manuals | CDC guidelines | | Vendor contracts | Grant requirements | | Training materials | Health education materials | | Audit reports | Program evaluations | #### Observation Watching work happen reveals what interviews miss: **BA Observation (Job Shadowing):** - Watch users perform tasks - Note workarounds and inefficiencies - Identify undocumented processes - Time critical workflows **PH Observation (Site Visits, Ethnography):** - Visit clinics, community settings - Understand context and constraints - Observe patient-provider interactions - Identify environmental factors ::: {.callout-tip title="Gemba Walks"} The Lean concept of "Gemba" (going to the actual place where work happens) applies to both domains. For CancerSurv, this means spending time in the registry office watching abstractors work, not just interviewing them in a conference room. However, Gemba walks often fall short when designers and programmers only observe a single point in the workflow. A critical gap in many software projects is the failure to understand the **complete data and document flow** across all users and use cases. ::: #### Understanding the Full Workflow A frequent and costly mistake is that software designers speak primarily with **decision-makers and budget holders**—often located far from the actual work. These gatekeepers may not themselves use the system daily, and they may not see the entire operational flow. The result: software that fails to support the messy, multi-stage reality of work. **The Complete Workflow Includes:** 1. **Data Generation & Collection** (field operations) - How data originates: inspections, tests, patient encounters - Who collects it and what constraints they face 2. **Data Intake & System Processing** (data entry, administration) - How raw data enters the system - What validation, coding, and quality checks occur - Who performs these tasks and their priorities 3. **Data Preparation for External Use** (records, reporting) - How data is processed for public requests, legal discovery, or external reporting - Admin support and customer service functions - Regulatory and compliance requirements 4. **Data Use by Multiple Stakeholders** (analysis, management, operations) - How frontline workers (field inspectors, registrars) use data for daily decisions - How managers use the same data for productivity metrics, resource allocation, and accountability - These uses often conflict—what serves operational efficiency may not serve field worker needs **Why This Matters:** Each stage has **different outcomes, different focuses, and different definitions of success**. Data collected by one stakeholder is processed by another and used by a third—each with distinct priorities. A system designed to satisfy the decision-maker but not these three operational groups will fail in practice. ::: {.callout-note title="CancerSurv Example"} **The Problem:** A software vendor designs CancerSurv by consulting the State Cancer Registry **Director** (the budget holder). The director prioritizes: - NPCR reporting compliance - Cost efficiency - Centralized system control But the director rarely enters data or manages daily workflows. The actual system involves: 1. **Data Generation:** Hospital pathologists and surgical oncologists generate reports (often outside the system, in hospital EHRs) 2. **Data Intake:** Registrars abstract cases from hospital records into CancerSurv—manually reviewing pathology, staging, treatment 3. **Data Processing:** Admin staff validate data, perform quality checks, request missing information, deduplicate records, and prepare annual reports for CDC 4. **Data Use (Inspection/Operations):** Registrars use the system to identify missing follow-up information and flag data quality issues 5. **Data Use (Management):** The director uses dashboards to track incidence trends and ensure grant milestones are met; registry managers use the same data to evaluate registrar productivity and workload **The Disconnect:** If programmers and designers only shadow the director or attend leadership meetings, they miss critical needs: - Registrars need efficient batch workflows for large case imports (not addressed in director-focused design) - Admin staff need audit trails and error logs (not a director priority) - Registrars' productivity data goes to managers for performance reviews—creating tension between doing quality work and doing work fast - Hospital pathologists need interoperability to send structured reports directly into CancerSurv (if this step is never observed, a manual workaround becomes permanent) **The Solution:** Before programming begins, the development team—including programmers and architects—must shadow all four phases: - Spend time in the hospital observing how pathology reports are generated and accessed by registrars - Sit with registrars as they abstract cases and manage quality issues - Work with admin staff processing data for CDC submission and responding to records requests - Interview both field registrars and managers to understand how the same data supports different decisions Only then can the team design a system that truly serves the work, not just the budget narrative. ::: **A Critical Principle for Both Domains:** Whether in public health or IT, the programmer or analyst who designs the system must see the complete workflow before design begins. This is not optional; it is the foundation of requirements elicitation. Skipping this step guarantees expensive redesigns, user dissatisfaction, and workarounds that undermine system integrity. ### Engaging Diverse Voices #### The Equity Imperative Public health emphasizes inclusive engagement, ensuring marginalized voices are heard. This principle benefits IT projects as well: **Questions to Ask:** - Who is missing from our stakeholder list? - Whose needs might be overlooked by "typical" users? - What barriers prevent participation (language, location, schedule)? - How do we ensure power imbalances do not silence important perspectives? #### Community-Based Participatory Research (CBPR) CBPR principles can strengthen BA elicitation: | CBPR Principle | BA Application | |:---------------|:---------------| | Community as equal partner | Users co-design, not just provide input | | Build on community strengths | Leverage existing workflows that work | | Balance research and action | Deliver incremental value during elicitation | | Long-term commitment | Maintain relationships beyond project end | ### Translating What You Hear #### From Needs to Requirements Elicitation produces raw material that must be translated into actionable requirements: ```{mermaid} %%| label: fig-elicitation-flow %%| fig-cap: "From Elicitation to Requirements" flowchart LR A[Interviews Observations] --> B[Elicitation Notes] B --> C[Analysis & Synthesis] C --> D[Requirements Documentation] D --> E[Validation with Stakeholders] E --> F[Approved Requirements] ``` #### Common Translation Challenges | What Stakeholders Say | What They Might Mean | Requirement Implication | |:----------------------|:---------------------|:------------------------| | "It should be easy to use" | Current system requires too many clicks | Reduce clicks per task by 50% | | "We need real-time data" | Current reports are weeks old | Dashboard updates within 24 hours | | "Make it like Excel" | Users are comfortable with Excel | Familiar grid-based interface | | "We need better reports" | Current reports lack specific metrics | Add [specific metric] to [report] | ::: {.callout-note title="CancerSurv Example"} **Stakeholder statement:** "We need the system to be faster." **Probing questions:** - Which specific tasks feel slow? - How long do those tasks take now? - What would be an acceptable time? - What happens when the system is slow? **Refined requirement:** "The case search function shall return results within 3 seconds for queries returning up to 1,000 records, to support efficient case lookup during abstraction." ::: ### Documentation Approaches #### BA Requirements Documentation - User Stories (Agile) - Use Cases (UML) - Requirements Specifications (Waterfall) - Acceptance Criteria #### PH Program Documentation - Logic Models - Intervention Protocols - Evaluation Plans - Implementation Guides #### Bridging the Formats For hybrid projects, consider dual documentation: | Audience | Format | Content | |:---------|:-------|:--------| | Development team | User Stories | Functional requirements in Agile format | | Clinical stakeholders | Service-User Scenarios | Narrative descriptions of clinical workflows | | Funders (CDC, grants) | Logic Model | Inputs, activities, outputs, outcomes | | Governance | Requirements Traceability Matrix | Links requirements to objectives | #### When Standard User Stories Fall Short {#sec-when-standard-user-stories-fall-short} The standard Agile user story format ("As a [user], I want [feature], so that [benefit]") works well for many software contexts. However, it often fails to capture the nuances of clinical workflows, regulatory requirements, and public health scenarios. **Why standard user stories may not fit clinical contexts:** - Clinical workflows involve conditional logic ("if this lab result, then that action") - Regulatory requirements mandate specific timeframes and actions - Patient safety considerations require explicit protocols, not just user preferences - Public health surveillance involves system-initiated actions, not just user-initiated features **Alternative formats worth considering:** **Given-Person-Should (GPS) Format:** This format emphasizes context and obligation rather than desire: > "Given [clinical/situational context], the [health worker role] should [specific action] to [health outcome]." *Example:* > "Given a positive TB test result, the contact tracer should initiate household investigation within 48 hours to prevent secondary transmission." **Situational Protocol Format:** This format ties system behavior to clinical guidelines or regulatory requirements: > "When [triggering event], the system shall [required action] within [timeframe]." *Example:* > "When a laboratory reports a confirmed measles case, the system shall generate a contact list and notify the assigned epidemiologist within 4 hours." **Service-User Scenario Format:** This narrative format describes a patient or client journey through the system: > "Maria, a 45-year-old farmworker, visits a mobile clinic for diabetes screening. She speaks primarily Spanish and has no regular primary care provider. The system must support her preferred language, connect her to follow-up care, and track her screening results for population health reporting." ::: {.callout-note title="CancerSurv Example"} **Standard user story:** "As a registrar, I want to search for existing cases, so that I can avoid creating duplicates." **GPS format (adding clinical context):** "Given a new pathology report for a patient who may already be in the registry, the registrar should be able to search by name, SSN, and diagnosis within 3 seconds to prevent duplicate case creation and ensure accurate incidence counts." **Situational protocol (system-initiated):** "When a new case is entered, the system shall automatically search for potential duplicates using probabilistic matching and present candidates to the registrar for review before saving." ::: Choose the format that best communicates intent to your audience. Development teams may still translate these into standard user stories for sprint planning, but starting with clinical context ensures nothing gets lost in translation. ### Validation and Confirmation #### Ensuring Accuracy Elicitation is iterative. Validate what you heard: **BA Validation Techniques:** - Requirements reviews - Prototype walkthroughs - Structured walkthroughs - Sign-off meetings **PH Validation Techniques:** - Member checking (returning findings to participants) - Community review sessions - Pilot testing - Expert review panels ### Managing Conflicting Needs #### When Stakeholders Disagree Conflicts are inevitable. Resolution approaches include: | Approach | When to Use | |:---------|:------------| | **Prioritization** | When resources are limited; use MoSCoW or weighted scoring | | **Negotiation** | When compromise is possible without losing value | | **Escalation** | When authority must resolve; use governance structure | | **Phasing** | When both needs are valid; address in different releases | | **Alternatives Analysis** | When creative solutions can satisfy both parties | ::: {.callout-note title="CancerSurv Example"} **Conflict:** Registrars want a simple, streamlined interface. Epidemiologists want comprehensive data fields for analysis. **Resolution:** Implement a tiered interface: - Core fields (required): Streamlined view for registrars - Extended fields (optional): Available when needed - Analytics fields: Populated from other sources, not requiring registrar entry ::: ### Deliverables from This Phase | BA Deliverable | PH Deliverable | Purpose | |:---------------|:---------------|:--------| | Elicitation Results | Engagement Summary | Raw findings documentation | | Requirements Document | Program Protocol | Detailed specifications | | User Stories / Use Cases | Service-User Scenarios | Actionable descriptions | | Stakeholder Feedback Log | Community Input Register | Track all input received | ### Moving Forward With needs elicited and documented, the next phase focuses on **Requirements Analysis**: organizing, prioritizing, and specifying the detailed requirements that will guide solution design.