---
artifact-status: draft   # draft | approved — approval state of this generated file (gate reads this)
---
# Product Requirements Document (PRD)

> **Last Updated:** [Date]  ·  **Product Manager:** [Name]  ·  **Contributors:** [Names/Roles]
> **BRD:** [Business Requirements Document](brd.md) — business context, objectives, rules, and entities live there (single source of truth). This PRD references the BRD and does not restate business analysis.

---

## 1. Product Goal

> **PG-NNN = a short, product-oriented statement of what the product is for and the axis it optimises** (derived from BRD.Business Objective + BRD.Problem Statement). Read it and you understand what the product is built to do without reading the whole FR list.
> Each PG **references the BR(s) it serves** (`BR-NNN`) but does NOT copy the BR's numbers — it states an operable direction the team and designer can build/draw against.
> **Two consumers:** (1) UI/UX Design takes its design intent from here; (2) the Master Plan orders features by their contribution to these goals. Keep it to a few lines.

- **PG-001** _(BR-001, BR-003)_ — [e.g. Help the guest complete a purchase as fast as possible, optimising for checkout speed and low friction. Direction: one-page checkout, cut steps from 5 to 3, minimise required fields]
- **PG-002** _(BR-002)_ — [product goal + direction]

---

## 2. User Personas

> Detailed portrait of a **human** actor (derived from BRD.Actor — reference the `AT-NNN`). Only human actors get a persona; external-system actors do not (they flow to SAD.Integration Contract instead). One human `AT-NNN` may expand into one or more personas. Role, goals, device, tech-savviness, accessibility needs, pain points. End-to-end journeys belong in User Flows below, not here.

#### Persona: [Name] _(AT-001)_
- **Role:** [Job title]
- **Goals:** [What they're trying to achieve]
- **Pain Points:** [Current frustrations]

---

## 3. User Flows

> High-level end-to-end journey per persona across the system (derived from BRD.Business Flow). Main steps only — no per-screen detail or validation (that lives in Feature Spec.User Flow). Lets stakeholders catch missing flows early and lets the planning agent derive feature dependencies.

| ID | Persona | User Flow (main steps) |
|----|---------|------------------------|
| UF-001 | [e.g. Guest Shopper] | [e.g. Browse → Add to cart → Checkout → Pay → Receive confirmation] |
| UF-002 | [e.g. Registered Customer] | [e.g. Login → View order history → Reorder] |

---

## 4. Product Data Model

> Main entities and their **relationships** at business level — relationships only, no attributes, no technical cardinality, no fields. Use `E-NNN` codes from BRD.Entities. This is the layer where the customer confirms the system understands how business objects relate. Mode: **Inline**.

- [e.g. E-003 Order contains many E-006 OrderItem]
- [e.g. E-006 OrderItem belongs to one E-002 Product]
- [e.g. E-003 Order belongs to one E-001 Customer]
- [e.g. E-004 Payment is tied to one E-003 Order]

---

## 5. Functional Requirements

> **FR = a specific system behaviour — the WHAT.** Each FR must reference at least one **BR** from the BRD (the WHY it exists). An FR with no BR reference is untraceable and must be fixed.
> Acceptance Criteria use Given/When/Then; an EARS phrasing is encouraged for the core trigger, e.g. *"WHEN a guest submits an order WITH a valid email, the system SHALL create the order with status = Confirmed."*
> **AC drive test planning** — each AC generates test IDs (`{PROJECT}_F{FEATURE}_AC{N}_SMOKE_NNN`) and automated tests. Clarity here = fewer bugs in code.
> Priority is **not** grouped here — it lives in BRD.Business Requirement (MoSCoW) and the Feature Map & Dependency table below.

- **FR-001** _(BR-001)_ — [Description of system behaviour]
  - **AC-1:** Given [context], when [action], then [outcome]
  - **AC-2:** Given [context], when [action], then [outcome]
- **FR-002** _(BR-002)_ — [Description of system behaviour]
  - **AC-1:** Given [context], when [action], then [outcome]

---

## 6. Non-Functional Requirements

> Measurable, derived from BRD.Constraint & Assumption (NFR group) + entity volume.

- **NFR-001:** Performance — [e.g. checkout page load P95 ≤ 2s]
- **NFR-002:** Security — [requirement]
- **NFR-003:** Scalability — [e.g. handle 500 concurrent orders]

---

## 7. Out of Scope

> What the system explicitly will NOT do (derived from BRD.Project Scope). Explicit exclusions prevent scope creep.

- [e.g. No inventory management]
- [e.g. No logistics integration]
- [e.g. No product reviews]

---

## 8. Modules

> Group features into independent business modules — each module gathers features that share the same business area and core entity. Drives accurate Feature Map & Dependency (cross-module = integration point). Each PRD Module maps 1-to-1 to a SAD Module (a logical component grouping that lives inside a SAD Container) — not to a Container directly.

| ID | Module | Core Entities | Features it groups |
|----|--------|---------------|--------------------|
| MOD-01 | [e.g. Catalog] | [E-002 Product] | [Browse, Search, Product detail] |
| MOD-02 | [e.g. Order] | [E-003 Order] | [Checkout, Order history] |

---

## 9. Feature Map & Dependency

> Features grouped by Module, with priority and dependencies. A cross-module dependency is an integration point → flag it; each becomes a SAD Integration Contract (IC-NN). This is the input the Master Plan uses to order feature execution.

| Feature | Module | Priority | Depends on | Cross-module? |
|---------|--------|----------|------------|---------------|
| [e.g. Checkout] | MOD-02 Order | P0 | [Cart, Pay] | Yes → IC needed |
| [e.g. Product Detail] | MOD-01 Catalog | P0 | — | No |

---

## Completeness Disposition

> Business-completeness lenses (`.tas/rules/common/business-completeness.md`). Every lens
> dispositioned before approval — Covered (with `Persona/FR/Module/NFR` ref) or `N/A — reason`.
> A gap that is really a business gap routes back to the BRD, not invented here.

| # | Lens | Disposition | Ref / Reason |
|---|------|-------------|--------------|
| L1 | Actor & role coverage | | |
| L2 | Entity lifecycle (business CRUD) | | |
| L3 | Identity & access governance | | |
| L4 | Data confidentiality & scope | | |
| L5 | Notifications & feedback | | |
| L6 | Exception & edge paths | | |
| L7 | Data lifecycle | | |
| L8 | i18n / l10n | | |
| L9 | Reporting & analytics | | |
| L10 | Onboarding & first-run / bootstrap | | |

---

## Changelog

> The **Customer Sign-off Reference** column is required on any row that sets the version to Approved — point to the email or file the customer signed (signer name + date).

| Date | Version | Changes | Author | Customer Sign-off Reference |
|------|---------|---------|--------|-----------------------------|
| [Date] | 1.0 | Initial draft | [Name] | — |

---

## AI Usage Log

| # | Date | Command | Input (est.) | Output (est.) |
|---|------|---------|-------------|---------------|
| 1 | [Date] | /tas-prd | ~{N}k | ~{N}k |
| **Total** | | | **~{N}k** | **~{N}k** |