spec-driven-development

Specification-driven development is writing a structured specification before coding to reduce miscommunication. Use it for early-stage projects or changes spanning multiple modules with unclear, evolving requirements to establish a shared truth.

Draft a project specification covering six core areas: objective, commands, project structure, code style, testing strategy, and boundaries. This specification-first approach guides implementation and code reviews.

Software architecture documentation for evolving requirements should include objectives, commands, structure, code style, testing strategy, boundaries, explicit success criteria, and open questions. This living document updates as decisions change.

Yes, specification-driven development targets early-stage projects with unclear or evolving requirements. It enforces a six-area specification to reframe unclear requirements into a concrete document, reducing rework before coding begins.

Handle requirement changes by treating the specification as a living document. Update the spec as decisions change, capturing new tests and acceptance criteria within the document to maintain a single source of truth.

Writing a specification before coding prevents guessing and reduces rework. Code without a spec lacks a shared source of truth, leading to miscommunication, whereas a prior spec defines what to build and how to know it is done.