02 Elicitation Toolkit

Elicitation Toolkit Skill

Use When

• selecting and conducting interviews, workshops, observation, surveys, document analysis, or prototypes to gather requirements; use stakeholder-analysis to identify participants first.
• Use this procedure when the required source artefacts are available and Elicitation plan, raw evidence, and issue log is the next lifecycle deliverable.

Do Not Use When

• Use stakeholder-analysis when that neighbouring route owns the decision or deliverable.
• Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.

Required Inputs

Workflow

1. Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.
2. Apply this skill's existing domain workflow and decision rules to produce Elicitation plan, raw evidence, and issue log.
3. Stop when a required source, accountable decision owner, or deterministic test oracle is absent.
4. Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.

Outputs

Evidence Produced

Capability and permission boundaries

Read and search are required. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require explicit authority.

Degraded mode

Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check not assessed; never convert an unassessed check into a pass.

Decision Rules

Quality Standards

• Preserve stable identifiers and bidirectional traceability from project evidence to Elicitation plan, raw evidence, and issue log and its acceptance checks.
• Apply ISO/IEEE measures only with a named metric, method, threshold, evidence source, and responsible reviewer; run the anti-slop gate before release.

Anti-Patterns

• Producing Elicitation plan, raw evidence, and issue log from assumed context. Fix: cite the project source or mark the scope blocked.
• Accepting a material requirement without a deterministic oracle. Fix: add a measurable result, boundary, and verification method.
• Crossing into stakeholder-analysis without routing the decision. Fix: hand off the named input and preserve trace links.
• Treating an unavailable check as passed. Fix: mark it not assessed and state the release consequence.
• Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.

References

• Skill authoring and release standard
• Domain Checklists
• Interview Guide
• Jad Workshop
• Observation Ethnography
• Prototyping For Elicitation
• Questionnaires Surveys

Overview

This skill provides a structured, multi-technique approach to requirements elicitation. It guides the AI through selecting the most appropriate elicitation technique based on stakeholder availability, domain complexity, and requirements maturity, then executes the chosen technique to produce a grounded elicitation log. The skill supports interviews, Joint Application Development (JAD) workshops, prototyping, observation, questionnaires, contextual inquiry, benchmarking, and artifact analysis, with domain-specific checklist hooks for specialized industries.

When to Use This Skill

• After the stakeholder register has been produced by 01-stakeholder-analysis
• When requirements need to be gathered from diverse stakeholder groups
• When the elicitation technique is unclear and a decision framework is needed
• When domain-specific requirements (healthcare, SaaS, POS, GIS) require specialized checklists
• When previous elicitation rounds produced incomplete or ambiguous requirements

Quick Reference

Input Files

Output Files

Core Instructions

Follow these six steps in order. Halt and notify the user if a required input file is missing.

Step 1: Read Context Files

Read stakeholder_register.md from projects/<ProjectName>/<phase>/<document>/, and vision.md and features.md from projects/<ProjectName>/_context/. Optionally read glossary.md. Log every file path read. If any required file is missing, halt execution and report the gap.

Step 2: Assess Elicitation Context

Evaluate three dimensions to determine the appropriate elicitation technique:

Dimension 1 -- Stakeholder Availability

Dimension 2 -- Domain Complexity

Dimension 3 -- Requirements Maturity

Step 3: Select Elicitation Technique

Use the following decision matrix to recommend one or more techniques:

Present the recommendation to the user with rationale. The user may override the selection.

Step 4: Execute Elicitation Technique

Execute the selected technique using the corresponding protocol. Each technique produces structured findings.

Technique A: Structured Interview

1. Select target stakeholders from the register (prioritize "Manage Closely" and "Keep Informed" quadrants)
2. Prepare interview questions using the three-tier approach:
   • Context questions: Establish the stakeholder's role and perspective
   • Open-ended questions: Explore needs, pain points, and workflows
   • Closed questions: Confirm specific requirements, constraints, and priorities
3. For each finding, record:
   • Source stakeholder (by ID from the register)
   • Verbatim statement or paraphrase
   • Requirement type: Functional, Non-Functional, Constraint, or Assumption
   • Confidence level: Confirmed, Likely, or Uncertain

Reference: references/interview-guide.md

Technique B: JAD Workshop

1. Define workshop scope and objectives from features.md
2. Identify participants from the stakeholder register (minimum: one sponsor, two users, one developer)
3. Structure the workshop agenda:
   • Opening: scope confirmation, ground rules
   • Discovery: facilitated discussion of features and workflows
   • Consensus: prioritization and conflict resolution
   • Closure: action items and next steps
4. Record consensus decisions, dissenting views, and open items

Reference: references/jad-workshop.md

Technique C: Prototyping

1. Identify features from features.md that benefit from visual exploration
2. Describe low-fidelity prototype elements (screens, workflows, data layouts)
3. Define feedback questions for each prototype element
4. Record stakeholder reactions, suggested changes, and confirmed requirements

Reference: references/prototyping-for-elicitation.md

Technique D: Observation

1. Identify processes or workflows relevant to the project scope
2. Define observation targets: tasks, sequences, decision points, pain points
3. Document observed workflows with:
   • Step-by-step task descriptions
   • Time estimates per task
   • Error-prone steps
   • Workarounds currently in use
4. Derive requirements from observed gaps and inefficiencies

Reference: references/observation-ethnography.md

Technique E: Questionnaire

1. Design the questionnaire with question types matched to information needs:
   • Multiple choice for categorical data
   • Likert scale (1-5) for satisfaction and priority ratings
   • Open-ended for qualitative insights
2. Target distribution to stakeholder groups from the register
3. Define minimum response thresholds for statistical validity
4. Summarize responses with aggregated metrics and notable outliers

Reference: references/questionnaires-surveys.md

Technique F: Contextual Inquiry

1. Arrange to observe target stakeholders in their actual working environment while they perform real tasks (not a staged demo)
2. Adopt the "apprentice" posture — the analyst is a learner; the stakeholder is the expert performing their normal work
3. Ask questions in real time while observing; do not defer all questions to a separate debrief session
4. Document observed workflows with:
   • Step-by-step task descriptions including physical environment interactions
   • Tacit knowledge and undocumented workarounds currently in use
   • Physical or environmental constraints that affect system requirements
   • Discrepancies between what stakeholders say they do and what they actually do
5. Derive requirements from observations; tag requirements sourced solely from verbal statements vs. observed behaviour
6. Record field notes immediately; produce process maps from the notes before the next working session

• Best for: Discovering undocumented workflows, tacit knowledge, physical environment constraints; domains where users cannot fully articulate their needs in a formal interview setting
• Output: Field notes, process maps, discovered requirements that users could not articulate verbally

Reference: references/observation-ethnography.md

Technique G: Benchmarking

1. Identify the comparison targets: industry standards, regulatory benchmarks, or direct competitor products relevant to the project domain
2. Define the comparison dimensions aligned to the project scope (features, performance thresholds, NFR values, UX patterns)
3. For each dimension, record:
   • The client's current state (from context files or stakeholder interviews)
   • The benchmark value or feature presence in the comparison target
   • The gap classification: Functional Gap (missing feature), Performance Gap (below threshold), or Parity (meets benchmark)
4. Derive NFR targets from benchmark performance data; express as measurable thresholds (e.g., "The system shall process a transaction in ≤ 2 seconds, per industry median of 1.8 seconds")
5. Use the gap list to set stakeholder expectations before detailed requirements are written; attach the benchmark table to the elicitation log

• Best for: Establishing NFR baselines, identifying table-stakes features, setting stakeholder expectations for new system capabilities
• Output: Benchmark comparison table, functional and performance gap list, NFR targets derived from industry standards

Reference: references/benchmarking-template.md

Technique H: Data Gathering / Artifact Analysis

1. Collect all available existing artefacts from the client: documents, reports, spreadsheets, database schemas, input forms, screen captures, and logs from the current system
2. For each artefact, record:
   • Artefact ID and type (form, report, schema, screenshot, policy document)
   • Source system or process
   • Business rules embedded in the artefact (calculated fields, validation rules, conditional logic)
   • Data entities, attributes, and observed relationships
3. Annotate each artefact with derived requirements and business rules; use [ARTEFACT-SOURCE: <ID>] tags to preserve traceability
4. Identify discrepancies between artefact-derived requirements and verbally stated requirements; flag each discrepancy with [CONFLICT: Artefact vs. Stated Requirement]
5. Build a data dictionary entry for every data entity discovered; feed entries into the project glossary
6. For legacy system migration projects, map every existing field and rule to a proposed new-system equivalent; mark gaps with [MIGRATION-GAP]

• Best for: Understanding as-is processes, identifying hidden business rules, legacy system migration, and cross-checking verbally stated requirements against physical evidence
• Output: Annotated artefacts, business rule inventory, data dictionary entries, migration gap list (if applicable)

Reference: references/artifact-analysis-checklist.md

Step 5: Apply Domain-Specific Checklists

If the project domain matches one of the following, apply the corresponding checklist to ensure domain-critical requirements are not missed:

For each checklist item, record whether the item was addressed (Yes/No/Partial) and the source of the finding.

Reference: references/domain-checklists.md

Step 6: Write Elicitation Log

Assemble all findings and write to projects/<ProjectName>/<phase>/<document>/elicitation_log.md. Log the total finding count, technique(s) used, and the number of unresolved items.

Output Format Specification

The generated elicitation_log.md shall follow this structure:

# Elicitation Log: [Project Name]

## Document Header
- Project: [Name]
- Version: 1.0
- Date: [Current Date]
- Technique(s) Used: [Interview / JAD / Prototyping / Observation / Questionnaire / Contextual Inquiry / Benchmarking / Artifact Analysis]
- Status: Draft

## 1. Elicitation Context
### 1.1 Stakeholder Availability Assessment
### 1.2 Domain Complexity Assessment
### 1.3 Requirements Maturity Assessment
### 1.4 Technique Selection Rationale

## 2. Elicitation Findings
### 2.1 Functional Requirements
### 2.2 Non-Functional Requirements
### 2.3 Constraints
### 2.4 Assumptions

## 3. Source Attribution Matrix

## 4. Domain Checklist Results (if applicable)

## 5. Open Items and Unresolved Questions

## 6. Confidence Summary

## 7. Standards Traceability

## Appendix A: Raw Interview/Workshop Notes
## Appendix B: Revision History

Each finding in Section 2 shall use this format:

#### EL-XXX: [Finding Title]

- **Type**: Functional | Non-Functional | Constraint | Assumption
- **Source**: [Stakeholder ID] -- [Role]
- **Technique**: [Interview | JAD | Prototyping | Observation | Questionnaire]
- **Statement**: "[Verbatim or paraphrased stakeholder statement]"
- **Derived Requirement**: The system shall [requirement statement].
- **Confidence**: Confirmed | Likely | Uncertain
- **Priority**: Critical | High | Medium | Low
- **Notes**: [Additional context or dependencies]

Common Pitfalls

• Selecting a single technique without considering stakeholder availability, leading to low participation and incomplete findings
• Recording findings without source attribution, making downstream validation impossible
• Skipping domain-specific checklists, resulting in missed regulatory or integration requirements
• Treating elicitation as a one-pass activity rather than iterating when confidence levels are low
• Using leading questions that bias stakeholder responses toward a predetermined solution
• Failing to distinguish between requirements, constraints, and assumptions in the log

Verification Checklist

• All required input files were read and logged
• Elicitation context was assessed across all three dimensions
• Technique selection rationale is documented and grounded in context assessment
• Every finding has a source stakeholder ID, technique, and confidence level
• Findings are classified by type (Functional, Non-Functional, Constraint, Assumption)
• Domain-specific checklists were applied if the domain matches a supported category
• Open items and unresolved questions are explicitly listed
• No requirement statement uses subjective language without a defined metric
• Standards Traceability section maps to IEEE 29148 Section 6.3

Integration

Standards Compliance

Resources

• references/interview-guide.md -- Structured interview protocol
• references/jad-workshop.md -- JAD workshop facilitation guide
• references/prototyping-for-elicitation.md -- Low-fi prototyping workflow
• references/observation-ethnography.md -- Contextual inquiry and observation checklist (Techniques D and F)
• references/questionnaires-surveys.md -- Survey design templates
• references/domain-checklists.md -- Domain-specific elicitation checklists
• references/benchmarking-template.md -- Benchmark comparison table and gap classification guide (Technique G)
• references/artifact-analysis-checklist.md -- Artifact inventory, business rule extraction, and migration gap checklist (Technique H)
• Java enterprise requirements overlay -- elicit version, transaction, failure, migration, production, and support evidence for Java/JVM estates