In words
What it is, why it matters, and what it is like.
Why am I learning this?
This concept is the first real control point in a spec-driven workflow. It is the foundation for everything that follows: technical design, task cards, tests, and acceptance criteria. Once you master this, you will be able to write a requirements document that removes ambiguity before it multiplies into every downstream artifact. It unlocks further study: Engineering Intent Documents, Acceptance Criteria, Requirements Traceability, Review Gates, Spec Drift, and the Spec-to-Code Pipeline. Without a clear requirements document, all the other artifacts — the design, the tasks, the acceptance criteria — are built on sand.
The idea, in plain terms
Think of a requirements document as the contract between what you want and what you build. It is not the code, not the design, not the tests — it is the statement of what the product must do and for whom. It states the *what* and *why*, deliberately not the *how*. For example, if you are building a mobile app for a local grocery store, the requirements document says: "A customer must be able to browse items by category, add them to a cart, and place an order for delivery." It does *not* say "We will use a React Native front end with a Node.js backend." That is the *how*, and it belongs to the technical design. The requirements document is the first artifact in the pipeline, and it is the one that everything else checks back against. If the requirement is vague — say, "the app should be fast" — then the developer does not know if 100 milliseconds is fast or 2 seconds is fast. That ambiguity multiplies: the design might optimise for the wrong thing, the task cards might be written incorrectly, and the acceptance criteria might test the wrong behaviour. By the time the code is written, the original idea is hardly recognisable. A well-written requirements document prevents this by making the *what* and *why* unambiguous from the start.
An analogy
Imagine you are hiring an architect to build your house. You do not tell the architect "build me something nice" — that is a vibe, not a requirement. You say: "I need a three-bedroom house, with a kitchen that opens to the living room, and a bathroom on the ground floor." That is the requirements document. The architect then designs the blueprints — that is the technical design. The builder uses the blueprints to make a list of tasks: "lay the foundation, frame the walls, install the plumbing." Those are the task cards. The inspector checks that each room meets the building code — those are the acceptance criteria. If the requirements document said "three bedrooms" but the builder only made two, the inspector would catch it. The analogy breaks down slightly because in software, the requirements themselves can change as you learn more, but the principle holds: you must write down what you want before you can build it. And the requirements document is the first place where you can catch problems — a bad requirement here costs you a redesign; a bad requirement discovered later costs you a rebuild.
Definition
A product requirements document (PRD) is a structured statement of what a product must do and for whom, from which technical design and tasks derive.
Where this sits
This is the first step in the Spec-Driven Development pipeline. It sits right after the Engineering Intent Document, which captures the build direction — problem, users, goals, constraints — before you write formal requirements. The PRD formalises that intent into specific, testable statements. It connects forward to Acceptance Criteria, which turn each requirement into a testable condition, and to Requirements Traceability, which keeps a link from each requirement through design, tasks, and tests. It also directly feeds Task Cards, which are the next move after the requirements and design are approved. Everything in the spec-driven workflow flows from this document, so getting it right is the first real control point.
