Requirements as Code: Making the Compiler Enforce Your Development Lifecycle📋

Table of Contents📋

Part I: The Problem and the Chain📋

Why requirements in Jira, code in repos, and tests elsewhere creates a structural gap. The six-project architecture that makes the compiler enforce every link via typeof() and nameof().

Part II: Requirements ARE Types📋

The fundamental shift: features as abstract records, acceptance criteria as abstract methods. Base types, the requirement hierarchy, the AcceptanceCriterionResult return type, concrete requirements like UserRolesFeature. Plus the generated navigable artifacts: [ForRequirement], [Verifies], [TestsFor], and RequirementRegistry.

Part III: SharedKernel and Specifications📋

Domain value types shared across layers. Specification interfaces per feature that the domain must implement. The validator bridge for compliance mode.

Part IV: Implementation and Tests📋

Compiler-enforced domain code that implements spec interfaces. Type-linked verification where every test references the AC it proves via typeof().

Part V: The Production Host📋

DI wiring, controllers annotated with [ForRequirement], startup compliance validation, DLL artifact boundaries, and OpenAPI enrichment.

Part VI: IDE Navigation and Traceability📋

The Ctrl+Click chain from test to AC to feature to epic. Source-generated traceability matrix and compiler diagnostics for coverage gaps.

Part VII: Roslyn Analyzers📋

Four analyzer families -- REQ1xx (requirement coverage), REQ2xx (specification implementation), REQ3xx (test coverage), REQ4xx (quality gates). Severity configuration via .editorconfig. The full CI pipeline.

Part VIII: Generation Pipeline, Lifecycle, and CMF Integration📋

The five-stage source generation pipeline. The requirement lifecycle state machine. Integration with existing CMF DSLs: M3/M2/M1/M0 mapping, DDD, Workflow, Admin.

Part IX: Before, After, and Why This Matters📋

The before-and-after comparison. Requirements Driven Development as a methodology. Cross-DLL features, ACs as live code, the developer perspective, .Requirements as a company asset. Why this matters for developers, QA, ops, and architects.