Goon-Strat

CCSDS Requirements Traceability Plan

Source basis:

• Tracks/CCSDS/CCSDS 235.1-W-0.4 Reference Implementation — Functional Requirements - requirements.pdf

Purpose

Translate FR/NFR requirements into implementation ownership, test evidence, and gateway acceptance so no mandatory item is missed at submission time.

Why This Document Is Separate From Deliverables

• deliverables explains what and when.
• requirements explains exact functional/non-functional obligations and how each is proven.
• Keeping both separate avoids schedule completion being mistaken for compliance completion.

Functional Requirement Backbone

• Gateway 0: Architecture and environment readiness
• Gateway 1: SPDU FRs (F1/F2, variable SPDUs, validation, directives, hex-dump interoperability)
• Gateway 2: COP-P FRs (FOP-P/FARM-P, sequencing, retransmission, resynchronization)
• Gateway 3: Frame FRs (P/U handling, parsing, version support, format compliance)
• Gateway 4: Physical abstraction FRs (mock/network/unreliable transport paths)
• Gateway 5: State machine FRs (full/half/simplex tables + transition validation)
• Gateway 6: Hailing/session FRs (caller/responder, lifecycle, reconnect, callbacks)
• Gateway 7: Integration FRs (end-to-end lifecycle + performance evidence)
• Gateway 8: Conformance FRs (including PICS)
• Gateway 9: Interoperability FRs (SPDU, COP-P, session cross-implementation)
• Gateway 10: Documentation and examples FRs

Non-Functional Requirements Focus

• Performance: under 1 ms SPDU/frame processing and memory constraints
• Testability: high coverage and reproducible vectors
• Reliability: robust error handling and stable recovery paths
• Maintainability: modularity and clear boundaries

Traceability Workflow

1. Requirement ingestion:
   • Parse each FR/NFR into unique IDs and map to source section/table.
2. Implementation mapping:
   • Assign owner and module path for each requirement.
3. Test mapping:
   • Attach unit/integration/conformance tests with pass criteria.
4. Evidence capture:
   • Store logs, vectors, benchmarks, and reports per requirement ID.
5. Review and closure:
   • Requirement status can only be set to complete with reproducible evidence.

Why this workflow:

• It creates judge-auditable proof chains from requirement to evidence.
• It reduces integration surprises by forcing early verification.

6-Person Ownership Model

• Engineer A: normative interpretation and ambiguity resolution
• Engineer B: FR/NFR test architecture and acceptance thresholds
• Engineer C: interoperability and operational validation criteria
• Developer A: core protocol implementation (SPDU/COP-P)
• Developer B: frame/transport/tooling implementation
• Developer C: integration automation, benchmark harness, evidence collection

Evidence Schema (per requirement)

• Requirement ID
• Source reference
• Owner
• Implementation location
• Test IDs
• Benchmark constraints
• Artifacts (paths)
• Status
• Reviewer sign-off

Exit Criteria

• 100% mandatory FR coverage with linked tests
• NFR targets measurable in CI or reproducible scripts
• PICS inputs pre-populated before final conformance week
• No unresolved requirement ambiguities without explicit documented assumptions

⬆️ Back to Top ⬆️

---

Back Page

Next Page