Product Requirements Document

1. Project Overview

What is being built and why. One paragraph: the client, the problem, the solution. Keep it concrete -- a reader should understand the project after this section alone.

Example: "Rivera Dental needs an appointment booking system because their phone-only process loses patients who call outside business hours."

2. Client Background

Who the client is, what their business does, and what context matters for the build. Include details that affect design decisions -- location, audience, how they currently operate.

Example: "Family dental practice in suburban Milwaukee, two dentists, one receptionist. Patients skew older and prefer simple interfaces."

3. Requirements

What the system must do, organized by feature area. Each requirement should be specific enough to build from and testable enough to verify. Use numbered lists.

4. User Stories

Who uses the system and what they need. Format: "As a [role], I want [capability] so that [benefit]." Include the primary user and any secondary users.

5. Technical Constraints

Technology choices, platform requirements, browser support, performance targets, accessibility standards, or integration needs that the build must satisfy.

6. Success Criteria

How you know the project is done. Specific, measurable outcomes that map back to the requirements. These become your verification checklist.