Spec-Driven Development Requirements Engineering Enterprise Architecture AI-Assisted Development

Spec-Driven Development & Multi-Level Requirements: The Complete Guide

How product, project, and subsystem requirements are being transformed by spec-first workflows — and the tools making traceability possible at enterprise scale.

July 10, 2026 Michel Laclé 16 min read

Audio Version

The Problem: Requirements at Scale

In large organizations, requirements don't live at a single level. They cascade across teams, products, and systems in ways that traditional tools struggle to capture.

Consider a typical enterprise software organization. You have product managers who own one or more products. Each product serves a market segment and has its own roadmap, feature set, and lifecycle. Products can be sold independently or combined into solutions for specific clients.

Then you have project teams. A project is the delivery of a solution to a client — which might involve selling an existing product, modifying it, or building something new. The project team coordinates across multiple products, customizing and integrating them for a specific customer engagement.

And underneath it all, you have development teams. These are the engineers building features and capabilities within the products themselves. Each product is composed of subsystems — microservices, libraries, modules — each implemented against a specific technology stack, each with its own set of technical requirements.

This creates a multi-level requirements landscape:

For decades, enterprises managed this complexity with heavy-weight tools like IBM DOORS, Jama Connect, and Polarion ALM. These platforms provided structured requirement modules, multi-level traceability, baselines, and compliance support for regulated industries. But they were slow, expensive, and disconnected from the actual development workflow.

Spec-driven development changes the equation. By making the specification the primary artifact — with code treated as a generated or verified secondary artifact — SDD offers a fundamentally different approach to requirements management. The question is: how does it handle the multi-level complexity that enterprises have struggled with for decades?

What Is Spec-Driven Development

Spec-Driven Development (SDD) emerged in 2025 as the dominant methodology for AI-assisted software engineering. As the arXiv paper by Deepak Babu Piskala frames it: "In spec-driven development, code is the implementation detail of the specification — not the other way around." [Link]

The canonical workflow follows a structured pipeline: Define → Specify → Plan → Tasks → Implement → Validate. Specifications are structured documents — typically Markdown — that capture requirements, acceptance criteria, architecture decisions, and implementation tasks. AI agents read the spec and generate code that must conform to it. The spec acts as both a prompt and a validation gate.

There are three levels of rigor, from lightest to heaviest:

Thoughtworks added Spec-Driven Development to their Technology Radar in 2025, and Martin Fowler published an analysis of the key tools — Kiro, Spec Kit, and Tessl — that are defining the landscape. [Link]

What makes SDD different from traditional requirements management isn't just the AI component. It's the inversion of the artifact hierarchy. In traditional workflows, code is the source of truth and specs guide it. In SDD, the spec is the source of truth and code serves it. This has profound implications for how requirements are managed, traced, and evolved across an organization.

Multi-Level Requirements in the SDD World

Let's map the traditional multi-level requirements hierarchy onto the spec-driven development model.

Product Requirements → Product Specifications

At the product level, requirements define what the product delivers to its market. In a spec-driven world, these become product-level specifications — structured documents that capture the product's capabilities, constraints, and acceptance criteria.

GitHub Spec Kit's "Constitution" concept is designed for this level. The Constitution is the immutable architectural DNA that governs every spec and implementation downstream. It defines the non-negotiable principles — security standards, performance targets, API contracts — that every product-level spec must conform to. [Link]

Product specifications in SDD are lighter than traditional PRDs. Instead of 100-page documents written in Word or Confluence, they're structured Markdown files living in the codebase — machine-readable, version-controlled, and directly consumable by AI agents.

Project Requirements → Project Specifications

Project requirements are specific to a client engagement. They define what modifications, customizations, or new features are needed for a particular delivery. In traditional workflows, these were often managed as separate work items in Jira or Azure DevOps, with fragile manual links back to product requirements.

In SDD, project specifications are generated from a combination of the product Constitution and project-specific constraints. The workflow might look like this:

  1. Product team maintains the product Constitution and core specifications.
  2. Project team forks or references the relevant product specs, adding project-specific requirements as deltas.
  3. AI agents generate implementation plans that satisfy both product-level and project-level constraints.
  4. Changes are validated against the full requirement hierarchy before merge.

GitHub Spec Kit's enterprise discussion around "Change Request" entities addresses this directly: change requests reference original specs by ID, carry their own review cycle, and on merge archive and update the spec — addressing versioning, change management, governance, and drift. [Link]

Subsystem Requirements → Capability Specifications

Each product is composed of subsystems — microservices, libraries, modules — each with its own technical requirements. In SDD, these become capability-level specifications, organized by subsystem.

OpenSpec takes this approach explicitly. Specs live alongside code, organized by capability, with a proposal-first workflow and delta markers. Each change gets its own folder with proposal, specs, design, and tasks. Over time, archived specs form a complete system behavior document. [Link]

Amazon Kiro uses a three-document system at the subsystem level: requirements.md (written in EARS notation for machine-parseable clarity), design.md, and tasks.md. This structure ensures that subsystem requirements are unambiguous, testable, and directly traceable to implementation. [Link]

Traceability in the SDD World

Requirements traceability — the ability to follow a requirement from its origin through design, implementation, testing, and deployment — has been a core challenge for enterprises. Traditional approaches used Requirements Traceability Matrices (RTMs), which were manually maintained spreadsheets that quickly became stale.

SDD changes traceability from a manual documentation exercise to an automated workflow property. Here's how:

Bidirectional Links Through Structure

In SDD, every spec generates structured artifacts — requirements, design decisions, and tasks. Each task is tied to specific code changes. This creates an automatic bidirectional traceability chain:

Because specs live in the codebase as version-controlled files, the traceability chain is preserved through git history. You can see exactly which spec change led to which code change, when, and by whom.

Automated Impact Analysis

When a requirement changes, you need to know what else is affected. Traditional tools like IBM DOORS Next and Jama Connect offer automated impact analysis — flagging all linked artifacts affected by a change. In SDD, this is built into the workflow.

Because specs are structured documents with explicit dependencies, AI agents can analyze the impact of a spec change before implementation begins. Tools like Traycer implement continuous verification loops that catch spec drift in real time. [Link]

Emerging "agentic requirements management" takes this further — autonomous agents handle consistency checks, trace link maintenance, and impact pre-analysis while engineers focus on design decisions. [Link]

Live Traceability Across Tools

The concept of "live traceability" — real-time visibility across the development lifecycle — is being adopted by both traditional ALM platforms and SDD tools. Jama Connect's "Live Traceability™" shows changes propagating across tools in real time, from PLM systems through requirements platforms to Jira and CI/CD pipelines. [Link]

In SDD, live traceability is simpler because specs live in the same repository as code. There's no cross-tool synchronization to manage. The git repository is the single source of truth, and CI/CD pipelines can validate traceability as a pipeline step.

The Development Workflow

Who does what in a spec-driven, multi-level requirements environment? Let's walk through the roles and responsibilities.

Product Management

Product managers maintain the product Constitution and product-level specifications. Their workflow:

  1. Define product vision and capabilities as structured specs.
  2. Maintain the Constitution — the non-negotiable architectural principles.
  3. Review and approve project-specific spec deltas before they're implemented.
  4. Track spec evolution across product versions.

Tools: GitHub Spec Kit Constitution, Cursor rules for product-wide standards, or enterprise ALM platforms for regulated industries.

Project Management

Project managers bridge product specs with client-specific requirements. Their workflow:

  1. Reference product-level specs as the baseline.
  2. Add project-specific requirements as deltas or change requests.
  3. Coordinate across multiple product teams when a project spans several products.
  4. Validate that project deliverables satisfy both product and client requirements.

Tools: GitHub Spec Kit change requests, Jira Advanced Roadmaps for portfolio visibility, or Modern Requirements for Azure DevOps environments.

Engineering Leadership

Engineering leads translate product and project specs into subsystem-level specifications. Their workflow:

  1. Decompose product/project specs into subsystem requirements.
  2. Define technical constraints, architecture decisions, and implementation patterns.
  3. Review AI-generated implementation plans for technical feasibility.
  4. Ensure cross-subsystem consistency and integration.

Tools: Amazon Kiro for spec-first IDE workflows, OpenSpec for repo-native capability specs, or BMAD-METHOD for multi-agent orchestration with 12+ specialized AI personas. [Link]

Development Teams

Developers implement against subsystem specs. In SDD, their workflow is:

  1. Read the spec — it's the authoritative source of truth.
  2. Generate or review AI-generated implementation plans.
  3. Implement code that conforms to the spec.
  4. Validate that tests pass and spec requirements are satisfied.
  5. Update the spec if implementation reveals missing requirements or edge cases.

Tools: Claude Code, GitHub Copilot, Cursor, OpenCode, Windsurf — all with SDD workflow support via Spec Kit or OpenSpec integrations.

QA and Verification

In SDD, testing is derived from specifications. Each spec includes acceptance criteria that are directly testable. AI agents can generate test cases from Given/When/Then scenarios embedded in the spec.

Research shows that NLP-based validation tools reduce validation time by approximately 67%, identify 29% more defects, and lower costs by 40%. [Link]

Keeping Requirements Current

The biggest challenge in requirements management isn't creating requirements — it's keeping them current as the product evolves. Traditional PRDs become stale within weeks. SDD addresses this through several mechanisms:

Living Specs

Because specs live in the codebase, they're updated alongside code changes. When a developer modifies a feature, the spec is updated in the same commit. This eliminates the gap between documentation and implementation that plagues traditional workflows.

Spec Drift Detection

Tools like Traycer implement continuous verification loops. If code diverges from the spec, the tool flags it. If the spec needs updating to reflect new requirements, the tool surfaces the gap. This is the SDD equivalent of a linting rule for requirements.

Versioned Specs

OpenSpec's archival model addresses versioning explicitly. When a spec is completed, it's archived — not deleted. The archived specs form a complete system behavior document over time. You can trace the evolution of any requirement through the archive.

AI-Assisted Maintenance

Emerging AI tools can analyze code changes and suggest spec updates. IBM DOORS Next's Watson AI Requirements Quality Assistant flags ambiguous or incomplete requirements before review. Jama AI generates requirements and test cases adhering to industry standards. [Link]

The Tool Landscape

The SDD tool ecosystem is maturing rapidly. Here's the landscape as of mid-2026:

SDD-Native Tools

GitHub Spec Kit — The most widely adopted SDD framework. Open-sourced September 2025, 100k+ GitHub stars. Model-agnostic, works with any AI coding agent. Pipeline: Constitution → Specify → Plan → Tasks → Implement → PR. [Link]

Amazon Kiro — Agentic IDE built by AWS, fork of VS Code. GA released March 2026. Built-in SDD with "spec mode" vs "vibe mode." Uses EARS notation for machine-parseable requirements. Best for AWS-native teams and compliance-sensitive environments. [Link]

OpenSpec — Lightweight, repo-native. Specs organized by capability with proposal-first workflow. Added to Thoughtworks Technology Radar. Scored highest in independent evaluation across 13 categories. Skills installed by default across 24 tools. [Link]

Tessl — Most ambitious approach. Spec-as-source with code regeneration. 1:1 spec-to-code file mapping with // GENERATED FROM SPEC - DO NOT EDIT markers. Language/framework-agnostic API registry for AI agents. [Link]

Traycer — Mini-specs approach with continuous verification. Breaks high-level intent into small, maintainable specs. Plan becomes a persistent ticket system. [Link]

BMAD-METHOD — Multi-agent framework with 12+ specialized AI personas (Analyst, PM, Architect, Developer, etc.). Simulates an entire agile team using role-scoped AI personas. Audit-friendly artifacts for regulated industries. [Link]

Enterprise ALM Platforms (Adapting to SDD)

IBM DOORS Next — Enterprise standard for regulated industries. Watson AI-powered Requirements Quality Assistant. Supports ISO 26262, DO-178C, IEC 62304, CMMI. DOORS Classic reached end of support September 2025.

Jama Connect — Modern ALM with "Live Traceability™." AI-generated requirements and test cases. SOC 2 Type II certified. Strong integration with PLM, Jira, and Azure DevOps.

Siemens Polarion ALM — Integrated ALM for complex product development. Strong in systems engineering and hardware-software co-development.

Modern Requirements4DevOps — Built exclusively into Azure DevOps. Traceability matrices, baselining, review workflows. Extends Azure DevOps into a full ALM tool.

Planview — Portfolio management connecting strategy to execution. Anvi AI agents operating across cross-portfolio data fabric. Best for enterprise-scale governance and multi-business-unit coordination.

Choosing the Right Tool

The right tool depends on your context:

For organizations managing multi-level requirements specifically, the combination of a spec-driven tool (GitHub Spec Kit or OpenSpec) with an enterprise ALM platform (Jama Connect or Modern Requirements) provides the best of both worlds — lightweight spec workflows for development teams, with enterprise-grade traceability and governance for product and project management.

Adoption Challenges and "SpecFall"

SDD adoption isn't just a technical change — it's an organizational capability that must be developed. InfoQ's enterprise analysis warns of "SpecFall" — the equivalent of "Scrumerfall" — where organizations adopt the tooling without the cultural shifts, resulting in specs that become stale artifacts rather than living documents. [Link]

Key adoption challenges:

However, the industry consensus is clear. Thoughtworks, Martin Fowler, GitHub, Amazon, and a 67-source academic review all agreed in 2025 and 2026: the question is no longer whether to use SDD, but which implementation to choose.

Conclusion

Spec-driven development represents a fundamental shift in how we think about requirements. By making the specification the primary artifact — with code as a generated or verified secondary artifact — SDD offers a path to more disciplined, more traceable, and more maintainable software development.

For organizations managing multi-level requirements across products, projects, and subsystems, SDD provides a framework that addresses core challenges:

The tool landscape is maturing rapidly. GitHub Spec Kit leads in adoption, Amazon Kiro in IDE integration, OpenSpec in lightweight repo-native workflows, and Tessl in the ambitious spec-as-source vision. Traditional ALM platforms are adapting, adding AI capabilities and live traceability to remain relevant.

The organizations that will succeed are those that treat SDD not as a tool to install, but as an organizational capability to develop — one that bridges product management, project delivery, and engineering in a unified requirements workflow.

References