[📚 Docs](../../README.md) › [Guides](../README.md) › Product Owner / BA

# Hướng Dẫn PO/BA — Spec-Driven Docs

Tài liệu dành cho **Product Owner (PO)** và **Business Analyst (BA)** — vai trò, commands, các tình huống thực tế, và quy tắc viết PRD.

## Mục Lục

| Trang | Nội dung |
|---|---|
| [Commands](commands.md) | Bảng lệnh cho PO/BA · project lessons · xử lý feedback tester |
| [Tình huống thực tế](scenarios.md) | 12 scenario: tính năng mới, design spec, BDD, PRD thay đổi, brownfield, **System BDD synthesis & cross-platform conflict**, ... |
| [Checklist input PRD](../prd-input-checklist.md) | 7 câu chuẩn bị để PRD chuẩn ngay lần đầu (kèm lưu ý BE) |
| [Checklist input BDD (System/BE)](../bdd-input-checklist.md) | Chuẩn bị để `/generate-bdd` (system) chuẩn ngay lần đầu |
| [Quy tắc viết PRD](prd-writing-rules.md) | Platform-agnostic · testable AC · negative path · BR numbering |
| [Checklist handoff](handoff-checklist.md) | Checklist verify trước khi thông báo dev team bắt đầu |

## Vai Trò PO/BA Trong Framework

PO/BA là người duy nhất viết và approve tài liệu đầu vào + BDD:

```
PO/BA                     Dev team
──────────────────────    ──────────────────────────────
/define-product           đọc product-definition + BDD
/generate-prd        →    /review-context (xác nhận PRD)
/refine-prd (SA review)   /generate-tech-docs
/review-context           /generate-code + tests
/generate-design-spec →   /review-code / /dev-run-test
/generate-bdd (web)
/generate-bdd (app)
/generate-bdd (system)
```

**PO/BA chịu trách nhiệm:**
- Đảm bảo PRD platform-agnostic (không chứa UI details hay API specs)
- Đặt row `Domain` (bảng Metadata) đúng để dev team routing hoạt động
- Cập nhật `Status: approved` (bảng Metadata) trước khi handoff
- **Generate BDD cho tất cả platforms** theo thứ tự **outside-in: web → app → system** — System BDD được **tổng hợp từ web+app BDD** (project chỉ-BE thì system gen thẳng từ PRD). Xem [scenarios](scenarios.md).
- Thông báo dev team khi có PRD hoặc BDD mới/update

**PO/BA KHÔNG cần quan tâm:**
- Tech docs — dev team tự generate
- Source code — hoàn toàn dev team

### Tại sao BDD thuộc trách nhiệm của PO?

Đặt BDD trong spec repo giúp **tổng hợp toàn bộ tài liệu nghiệp vụ về một chỗ**.

```
PRD (WHAT + WHY)  →  BDD (HOW verified)  →  Code (HOW built)
   ↑ PO/BA            ↑ PO/BA              ↑ Dev
   spec repo          spec repo             dev repo
```

> **Sau khi BDD approved → QC chạy pipeline tự động:** Khi BDD của một UC được duyệt (đặt `@trace.status: approved` sau review-context BDD sạch), QC team chạy bộ lệnh native `/qc-analyze → /qc-plan → /qc-design-test → /qc-review → /qc-run-test → /qc-report` — đọc official `.feature`, generate + run Playwright/pytest, rồi ghi `qc_status` (official QC coverage) vào Living Docs. PO không chạy QC, nhưng nên biết bước này tồn tại ở downstream. Chi tiết: [chương QC Automation](../tester/qc-automation.md).

**3 lý do chính BDD thuộc PO:**

**1. Tổng hợp tài liệu nghiệp vụ tại một nơi** — Khi BDD nằm trong spec repo cùng PRD, mọi spec nghiệp vụ đều ở một chỗ — dễ review, audit, và generate báo cáo. Dev team đọc spec từ submodule, không cần tự suy ra scenarios.

**2. BDD viết ở mức nghiệp vụ — PO hiểu được** — BDD trong spec repo mô tả **hành vi hệ thống** bằng ngôn ngữ nghiệp vụ, không phải implementation detail:

| Platform | BDD trong spec repo (PO viết) | Test code (Dev viết) |
|---|---|---|
| Web | `When user submits login → sees dashboard` | `await page.click('#login-btn')` |
| App | `When user taps Login → navigates to Home` | `element(by.id('login')).tap()` |
| System | `When login request received → returns auth token` | `POST /api/auth/login assertions` |

**3. System BDD là nguồn sự thật cho BE** — tổng hợp từ FE + App BDD:
- FE BDD: "User expects auth token để truy cập tiếp"
- App BDD: "App expects user profile sau khi đăng nhập"
- System BDD: "BE phải trả `{ token, user_profile }` để thỏa mãn cả 2 platform"

> Khi web & app **kỳ vọng response khác nhau**, `/generate-bdd → system` dừng tại **CHECKPOINT** để PO chốt cách giải quyết (union / platform-hint / separate-endpoints) — quyết định ghi vào `@system.resolution:`. Quy trình + ví dụ đầy đủ: [scenarios › Tình huống 12](scenarios.md#tình-huống-12--system-bdd-synthesis-outside-in--xử-lý-cross-platform-conflict).

> Xem [Concepts › Traceability](../../03-concepts/traceability.md) để hiểu trace chain PRD → BDD → Code.

---

*Xem thêm:* [Developer Guide](../developer/README.md) · [Tester Guide](../tester/README.md) · [chương QC Automation](../tester/qc-automation.md) · [Reference › Commands](../../05-reference/commands.md)