Requirements Manager

• Primary: All phases — requirements are a living document from Phase A through operations.
• Critical gates: SRR (System Requirements Review), PDR, CDR.

Core Philosophy

Requirements change frequently. They should be easy to read, easy to diff in git, and easy to parse by scripts if needed. We use Markdown with structured blocks.

The Requirements Format

Structure of a Requirement Block

### [REQ-PWR-001] Minimum Battery Capacity
**Status**: DRAFT | APPROVED | VERIFIED
**Parent**: [REQ-SYS-050]
**Verification Method**: Test | Analysis | Inspection | Demonstration

The spacecraft shall have a minimum usable battery capacity of 1500 Wh at end-of-life (EOL) to support eclipse operations.

**Rationale**: Based on worst-case eclipse duration of 35 minutes and average power draw of 2 kW, with 20% margin.

File Organization

Store requirements by subsystem in /requirements/:

• requirements/system_level.md — Top-level mission and system requirements
• requirements/power_system.md — EPS requirements
• requirements/thermal.md — Thermal requirements
• etc.

ID Convention

REQ-[SUBSYSTEM]-[NUMBER] — e.g., REQ-PWR-001, REQ-STR-003, REQ-SYS-100.

Workflows

1. Creating Requirements

• Ask for the subsystem and goal.
• Generate new requirement blocks with unique IDs.
• Ensure every requirement has a clear, testable "shall" statement and a rationale.

2. Updating Requirements

• Use search to find the relevant requirement ID.
• Update text and rationale.
• Add a **History**: note summarizing the change.

3. Traceability Audit

• Scan the requirements directory.
• Build a Parent → Child tree.
• Flag orphan requirements (no parent, unless top-level system).
• Flag requirements with no verification method.

4. Requirements Flowdown

When a domain skill (e.g., thermal-assessment) derives a requirement from analysis:

• Create the requirement in the appropriate file.
• Trace it to the parent system requirement.
• Set verification method based on how it will be confirmed.

Writing Style

• Use "shall" for requirements, "will" for facts/declarations, "should" for goals.
• Avoid "soft" words: approximately, sufficient, robust, flexible.
• Every requirement must be testable — if you can't verify it, rewrite it.
• Be concise.

Interface

• Reads from: User input, existing requirements files
• Writes to: /requirements/
• Consumed by: All other skills (as their starting point), v-and-v-manager (for verification closure)