ada-tp-to-srs-derivation

Read the full TP, confirm architecture decisions (deployment, frameworks, multi-system relationships) with stakeholders, then apply six derivation paths: direct mapping, decomposition, cross-tool extraction, architecture-derived, precision correction, and AC atomization. Every requirement must trace back to a TP clause.

Each requirement uses a ### REQ-F-XXX heading with a priority emoji (P0/P1/P2), an Actor tag, bold Title/Description/Acceptance Criteria sections, and Given/When/Then acceptance criteria in English. The whole entry is wrapped in a code fence with a source annotation referencing the TP clause.

Add an appendix mapping every TP clause to its REQ-F requirement IDs, marking architecture-derived items as derived rather than protocol-sourced. Each requirement also carries an inline source annotation, and the matrix must show no orphan requirements or uncovered clauses.

Split an AC into its own requirement only when it has a different Given precondition, different trigger, and an independently verifiable result. Exception and validation scenarios sharing the same Given/When should remain as ACs of the parent requirement, and splitting is done only on explicit user request.

Run the verify-srs-fences.py script against the SRS markdown file. It checks that fence count equals twice the requirement count, REQ-F IDs are sequential without gaps, priority emoji distribution matches the appendix statistics, and no vague terms remain in requirement bodies.

Do not use it when writing an SRS from scratch without a source protocol, or when reviewing an existing SRS. The TP document must exist and be complete before derivation begins, since the methodology enforces strict fidelity to the source protocol.