requirements-gathering

name	requirements-gathering
description	Use when eliciting, documenting, and registering feature requirements in roadmap.md. Load during the Planning phase of SDLC.

requirements-gathering

SDLC Phase: Planning

Elicit, document, and register requirements for new features.

Principles

• Understand the problem first — Before proposing a solution, ensure the problem is clearly defined and scoped.
• One feature per proposal — Each requirement should be atomic. If a proposal covers multiple concerns, split it.
• Consider alternatives — There is always more than one way. Evaluate trade-offs before committing to an approach.
• Register before implementing — A requirement is not ready until it is documented and confirmed.

Elicitation

When gathering a requirement, establish:

Question	Purpose
Who is the user or stakeholder?	Defines who benefits and who approves
What problem does this solve?	Justifies the effort
Why now?	Establishes priority — is this blocking something else?
How will success be measured?	Defines acceptance criteria
What is out of scope?	Prevents scope creep

Scoping

Define the requirement clearly:

• In scope — What the feature will do, the capabilities it provides, the APIs it exposes.
• Out of scope — What the feature will explicitly not do. This is as important as what is in scope.
• Dependencies — What other features, crates, or external systems this depends on.
• Constraints — MSRV, no_std compatibility, zero external deps, no unsafe, etc.

Analysis Considerations

Before documenting a requirement, consider:

• Crate impact — Which crates need changes? Does this affect the dependency graph?
• API surface — What new types, traits, or functions are needed? What existing APIs change?
• Backward compatibility — Does this break existing users? If so, can it be done compatibly?
• Implementation complexity — Rough lines of code, algorithmic complexity, risk areas.
• Testability — How will this be tested? Can it be tested in isolation?

Documentation

Requirements are documented in docs/roadmap.md following this structure:

### {Feature Name}

**Status:** proposed | in-progress | done
**Crate:** {crate name}
**Source:** requirements-gathering

{Description of the feature}

**API sketch:** (optional, if known)

Roadmap entries should be concise. Detailed analysis and discussion belong in GitHub Issues or linked documents.

Human Confirmation

After documenting the requirement, stop and wait for human confirmation before proceeding. Do not write code, create PRs, or take any implementation action without confirmation. Requirements that are not confirmed may change or be rejected.

Output Requirements

• Requirement documented in docs/roadmap.md with clear scope, dependencies, and constraints
• Summary presented to the user for confirmation