Files

Leonard-ThindPad-P50 2c7bcde741 improve BA skill

2026-09-09 06:34:57 +07:00

26 KiB

Raw Blame History

BRIEF — Module Giỏ hàng & Checkout (e-commerce)


Version	1.0
Date	2026-09-08
Author	BA (qua skill ba-1-discovery)
Status	🟡 Draft
Approved by	—
Profile	screen · greenfield · standard (xem `00-index/PROFILE_e-commerce.md`)
Source	`e-commerce/docs/00-project-brief.md` · `e-commerce/docs/sections/01-tong-quan.md` · `e-commerce/docs/sections/02-phan-tich-yeu-cau.md` (FR-05, FR-06, FR-07, NFR-01, NFR-03, NFR-05) · `e-commerce/docs/sections/07-giao-dien.md` (SCR-04…SCR-07, chỉ dùng làm bối cảnh) · `STAKEHOLDER_CartCheckout_v1.0.md` · `ELICITATION_CartCheckout_2026-09-08.md` · `RISK_CartCheckout_v1.0.md`
Scope	Module Giỏ hàng & Checkout — FR-05 (Giỏ hàng đa seller), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán VNPay/Momo/COD) — dự án e-commerce (marketplace). Không bao gồm toàn sàn.

Change Log

Version	Date	Người sửa	Thay đổi	CR
1.0	2026-09-08	BA (qua skill ba-1-discovery)	Bản đầu	—

1. Tóm tắt cho người quyết định

Sàn marketplace đa seller sắp xây (dự án e-commerce) cần một luồng giỏ hàng–checkout–thanh toán xử lý đúng đặc thù đa người bán: một khách mua từ nhiều seller trong một lần thanh toán, hệ thống tự tách thành các đơn con theo seller, thanh toán qua VNPay/Momo/COD. Đây là luồng giao dịch lõi — không có nó, sàn không ghi nhận được doanh thu và seller không nhận được đơn. Tài liệu này chốt phạm vi, mục tiêu đo được và bốn yêu cầu mức nghiệp vụ (RQ-001…RQ-004) cho module này; còn nhiều OQ cần PO/Tech Lead trả lời trước khi ký G1 chính thức (tên thật stakeholder, KPI baseline, chính sách giới hạn COD).

2. Bối cảnh

Dự án e-commerce là greenfield — chưa có hệ thống nào đang chạy để thay thế (xem 00-index/PROFILE_e-commerce.md). Vì vậy không có "cách làm thủ công hiện tại" của chính sàn này để mô tả; bối cảnh dưới đây là quyết định mô hình kinh doanh đã chốt, không phải số đo vận hành thật.

Thông tin hiện trạng	Giá trị	Nguồn
Số giao dịch/ngày (dự kiến khi vận hành)	Chưa vận hành — quy mô mục tiêu "lớn": hàng trăm nghìn SKU, hàng trăm nghìn–hàng triệu user đăng ký, cao điểm hàng nghìn–chục nghìn concurrent user mùa flash sale	`00-project-brief.md` mục 3
Số người thao tác checkout đồng thời	N/A — chưa vận hành	—
Thời gian xử lý trung bình	N/A — chưa vận hành; mục tiêu latency đề xuất ở NFR-01 (< 2s catalog/search, < 3s checkout) là giả định mặc định đã chốt trong brief, chưa phải SLA hợp đồng thật	`sections/02-phan-tich-yeu-cau.md` NFR-01, ghi chú cuối §2.2
Tỷ lệ sai sót hiện tại	N/A — chưa vận hành, không có hệ thống cũ	—

3. Phát biểu bài toán

Vấn đề: Sàn marketplace đa seller đã cam kết mô hình "khách mua từ nhiều seller trong một trải nghiệm thống nhất" (mục tiêu dự án, sections/01-tong-quan.md §1.1) nhưng chưa có luồng giỏ hàng–checkout–thanh toán nào xử lý được việc: (1) gộp sản phẩm nhiều seller vào một giỏ, (2) tách thành đơn con đúng theo từng seller khi khách xác nhận mua, (3) thu tiền qua nhiều kênh thanh toán phổ biến tại Việt Nam (VNPay, Momo, COD) mà không lưu thông tin thẻ. Thiếu luồng này, sàn không thể ra mắt MVP, seller không có cách nào nhận đơn hàng, và không có dữ liệu giao dịch để tính hoa hồng/payout ở các module khác.

❌ Không viết giải pháp ở đây — mục này giữ đúng quy tắc, không nêu tên màn hình/nút cụ thể.

Bằng chứng của vấn đề:

#	Bằng chứng	Nguồn	Loại
1	Mô hình kinh doanh đã xác nhận là marketplace đa seller (không phải single-vendor) — kéo theo yêu cầu bắt buộc về giỏ hàng/checkout đa seller	`00-project-brief.md` vòng 1, câu hỏi 1	Sự thật (quyết định đã chốt)
2	FR-05 (Giỏ hàng đa người bán), FR-06 (Checkout & tách đơn theo seller), FR-07 (Thanh toán) đều được xếp Must trong bảng yêu cầu đã duyệt	`sections/02-phan-tich-yeu-cau.md` §2.1	Sự thật
3	Guest (khách vãng lai) được xác nhận cho phép checkout không cần tài khoản	`sections/01-tong-quan.md` §1.2	Sự thật

Điều gì xảy ra nếu không làm gì cả? Sàn không ra mắt được MVP marketplace — toàn bộ các module phụ thuộc (quản lý đơn hàng, hoa hồng, payout, đánh giá sau mua) đều cần dữ liệu đơn hàng sinh ra từ checkout. Đây là điều kiện tiên quyết (blocker), không phải một cải tiến.

4. Mục tiêu kinh doanh & KPI

🔴 Cả hai GOAL dưới đây chưa có baseline số thật vì dự án greenfield (chưa vận hành). Theo quy tắc, không bỏ trống — ghi OQ kèm đề xuất cách đo baseline.

ID	Mục tiêu	Baseline hiện tại	Mục tiêu	Cách đo	Ai đo	Tần suất
GOAL-01	Giảm tỷ lệ bỏ giỏ hàng ở bước checkout đối với giỏ hàng có ≥2 seller (rủi ro cao hơn giỏ 1 seller do phí ship gộp — xem `RISK-04`)	❓ Chưa có — dự án chưa vận hành (`OQ-007`). Đề xuất cách đo: theo dõi tỷ lệ hoàn tất checkout trong 4–6 tuần đầu soft-launch, tách riêng theo số seller trong giỏ	PO xác nhận sau khi có số đo soft-launch, đề xuất ban đầu ≤ tỷ lệ bỏ giỏ của giỏ 1 seller + 10 điểm phần trăm	(số phiên checkout hoàn tất) / (số phiên bắt đầu checkout), theo nhóm số seller trong giỏ	BA + PO, hàng tuần trong 6 tuần đầu	Hàng tuần (giai đoạn đầu)
GOAL-02	Tỷ lệ thanh toán thành công trên tổng số phiên checkout đã chọn phương thức thanh toán	❓ Chưa có — chưa vận hành (`OQ-007`). Đề xuất đo baseline bằng dữ liệu 4 tuần đầu sau go-live, tách riêng theo kênh VNPay/Momo/COD	PO xác nhận; đề xuất tham khảo ngành ≥ 90% cho ví điện tử, COD không tính "thất bại" theo nghĩa kỹ thuật mà theo tỷ lệ hoàn/từ chối nhận hàng (liên quan `RISK-01`)	(số giao dịch thanh toán thành công) / (số giao dịch đã khởi tạo), theo kênh	BA + Kế toán đối soát (STK-04), hàng tuần	Hàng tuần (giai đoạn đầu), sau đó hàng tháng

5. Phạm vi

5.1 Trong phạm vi

#	Hạng mục	Vì sao cần	RQ liên quan
1	Giỏ hàng chứa sản phẩm từ nhiều seller khác nhau, nhóm hiển thị theo seller	Điều kiện tiên quyết của mô hình marketplace đa seller	RQ-001
2	Checkout: thu thập địa chỉ giao hàng, tự động tách giỏ hàng thành các đơn con theo từng seller	Mỗi seller cần xử lý đơn độc lập, không lẫn với seller khác	RQ-002
3	Thanh toán qua VNPay, Momo hoặc COD, không lưu thông tin thẻ trên hệ thống sàn	Đối tác thanh toán đã xác nhận; giảm phạm vi PCI-DSS (NFR-05)	RQ-003
4	Guest checkout — mua hàng không cần tạo tài khoản trước	Đã xác nhận trong `sections/01-tong-quan.md` §1.2	RQ-004

5.2 Ngoài phạm vi (quan trọng hơn mục 5.1)

#	Hạng mục	Lý do loại	Xử lý ở đâu / khi nào
1	Áp mã khuyến mãi/coupon (FR-13)	Được giao ở một module khác (Khuyến mãi), dù xuất hiện trên cùng màn hình checkout theo bối cảnh UI ở `sections/07-giao-dien.md` SCR-05	Module Khuyến mãi & Loyalty — cần PO xác nhận điểm nối, xem `OQ-004`
2	Dùng điểm thưởng loyalty khi checkout (FR-14)	Tương tự trên	Module Loyalty — `OQ-004`
3	Theo dõi/xử lý đơn hàng sau khi đã tạo (huỷ, đổi trả, khiếu nại — FR-08, FR-09, FR-25)	Là vòng đời đơn hàng sau checkout, không phải hành vi tạo đơn	GĐ1/GĐ2 của module Quản lý đơn hàng, chạy riêng
4	Xử lý tồn kho, đóng gói, cập nhật vận chuyển sau khi đơn được tạo (FR-26)	Thuộc vận hành kho, không phải luồng giỏ hàng/checkout	Module Vận hành đơn hàng, chạy riêng
5	KYC, cấu hình hoa hồng, payout cho seller (FR-17, FR-21, FR-22)	Không liên quan trực tiếp tới hành vi giỏ hàng/checkout của khách mua	Module Quản trị Seller & Tài chính, chạy riêng
6	Danh mục & tìm kiếm sản phẩm (FR-04)	Là bước trước giỏ hàng, đã có màn hình riêng (SCR-01…SCR-03)	Module Catalog & Tìm kiếm, chạy riêng
7	Nội dung/mẫu thông báo email/SMS xác nhận đơn hàng (FR-12)	Module này chỉ kích hoạt sự kiện gửi thông báo, không thiết kế nội dung/kênh gửi	Module Thông báo, chạy riêng — GĐ3 chỉ ghi rõ sự kiện trigger

5.3 Ranh giới hệ thống

flowchart LR
    GUEST(["👤 Guest"])
    CUS(["👤 Customer"])

    subgraph PHAMVI["Trong phạm vi — Module Giỏ hàng & Checkout"]
        CART["Giỏ hàng đa seller (FR-05)"]
        CHK["Checkout & tách đơn theo seller (FR-06)"]
        PAY["Thanh toán VNPay/Momo/COD (FR-07)"]
    end

    CATALOG[["Catalog & Tìm kiếm (FR-04) — ngoài phạm vi"]]
    PROMO[["Khuyến mãi & Loyalty (FR-13/14) — ngoài phạm vi"]]
    ORDER[["Quản lý đơn hàng sau checkout (FR-08/09) — ngoài phạm vi"]]
    SELLERBIZ[["KYC / Hoa hồng / Payout seller (FR-17/21/22) — ngoài phạm vi"]]
    NOTI[["Thông báo email/SMS (FR-12) — ngoài phạm vi"]]
    VNPAY[["VNPay"]]
    MOMO[["Momo"]]
    GHN[["GHN"]]
    GHTK[["GHTK"]]

    GUEST --> CART
    CUS --> CART
    CATALOG --> CART
    CART --> CHK
    PROMO -.-> CHK
    CHK --> GHN
    CHK --> GHTK
    CHK --> PAY
    PAY <--> VNPAY
    PAY <--> MOMO
    CHK --> ORDER
    CHK --> SELLERBIZ
    CHK --> NOTI

Khung đôi [[ ]] = ngoài phạm vi module này (có thể trong phạm vi dự án e-commerce nói chung, chạy ở module khác). Mũi tên hai chiều = trao đổi dữ liệu hai chiều với hệ thống ngoài.

Hệ thống	Trong/Ngoài phạm vi	Dữ liệu trao đổi	Chiều	Đầu mối
VNPay	Ngoài — tích hợp	Yêu cầu thanh toán, xác nhận kết quả (webhook — `ASM-01` chưa xác minh)	Hai chiều	Chưa xác định
Momo	Ngoài — tích hợp	Tương tự VNPay	Hai chiều	Chưa xác định
GHN	Ngoài — tích hợp	Địa chỉ giao hàng → phí ship/thời gian giao ước tính (`ASM-02` chưa xác minh)	Hai chiều	Chưa xác định
GHTK	Ngoài — tích hợp	Tương tự GHN	Hai chiều	Chưa xác định
Catalog & Tìm kiếm	Ngoài phạm vi module, trong phạm vi dự án	Sản phẩm, giá, tồn kho → giỏ hàng	Một chiều vào giỏ hàng	STK-06 (Tech Lead)
Khuyến mãi & Loyalty	Ngoài phạm vi module — điểm nối cần xác nhận (`OQ-004`)	Mã coupon/điểm thưởng → giảm giá áp vào checkout	Một chiều vào checkout	STK-01 (PO sàn)
Quản lý đơn hàng sau checkout	Ngoài phạm vi module, trong phạm vi dự án	Đơn con đã tạo → module quản lý đơn hàng	Một chiều ra khỏi module	STK-05 (Trưởng vận hành)
KYC/Hoa hồng/Payout seller	Ngoài phạm vi module	Dữ liệu giao dịch đã thanh toán → tính hoa hồng/payout	Một chiều ra khỏi module	STK-04 (Kế toán đối soát)
Thông báo email/SMS	Ngoài phạm vi module	Sự kiện "đơn đã tạo/thanh toán thành công" → trigger gửi	Một chiều ra khỏi module	Chưa xác định

6. Yêu cầu mức nghiệp vụ

ID	Phát biểu yêu cầu	Nguồn (STK + ngày)	MoSCoW	GOAL	Giải pháp khách gợi ý
RQ-001	Customer/Guest phải mua được sản phẩm từ nhiều seller khác nhau trong một giỏ hàng và hoàn tất bằng một lần checkout, thay vì phải đặt hàng riêng lẻ với từng seller trên các trang/luồng khác nhau.	STK-01 (PO sàn), qua `00-project-brief.md` vòng 1 (2026, vòng 1 không ghi ngày cụ thể)	Must	GOAL-01	"Giỏ hàng đa seller"
RQ-002	Hệ thống phải tự động tách một giỏ hàng đa seller thành các đơn con riêng theo từng seller ngay khi Customer/Guest xác nhận đặt hàng, để mỗi seller xử lý đơn của mình độc lập mà không thấy dữ liệu của seller khác.	STK-01 (PO sàn), STK-03 (Seller đại diện — chưa phỏng vấn trực tiếp), qua `00-project-brief.md` mục 2 & `sections/02-phan-tich-yeu-cau.md` FR-06	Must	GOAL-01	"tách đơn theo seller"
RQ-003	Customer/Guest phải thanh toán được bằng VNPay, Momo hoặc COD mà hệ thống sàn không lưu trữ thông tin thẻ thanh toán, để giảm phạm vi tuân thủ PCI-DSS.	STK-01 (PO sàn), STK-06 (Tech Lead — chưa xác nhận khả thi), qua `00-project-brief.md` vòng 1 & `sections/02-phan-tich-yeu-cau.md` NFR-05	Must	GOAL-02	"Thanh toán (VNPay/Momo + COD)"
RQ-004	Guest (khách vãng lai) phải checkout hoàn tất được mà không cần tạo tài khoản trước, để không mất khách hàng tiềm năng ở bước bắt buộc đăng ký.	STK-01 (PO sàn), qua `sections/01-tong-quan.md` §1.2	Must	GOAL-01	"guest checkout"

🔴 Kiểm tra phân bổ MoSCoW: cả 4/4 RQ đều Must = 100% > ngưỡng 60%. Theo quy tắc, đây là dấu hiệu "chưa phân loại thật" và cần hỏi PO câu "nếu chỉ kịp một nửa module này thì cắt cái nào". Trong trường hợp này, mức Must khớp với xếp hạng đã có sẵn ở FR-05/06/07 trong tài liệu phân tích yêu cầu đã duyệt (sections/02-phan-tich-yeu-cau.md), với lý do hợp lý là cả 4 RQ đều thuộc luồng giao dịch lõi không thể MVP thiếu. Tuy vậy, BA chưa tự ý coi đây là đã chốt — ghi OQ-008 để PO xác nhận lại đúng theo quy trình BA-1, không suy diễn thay PO.

MoSCoW	Nghĩa chính xác
Must	Không có thì bản phát hành này vô nghĩa
Should	Quan trọng, nhưng thiếu vẫn dùng được, có cách làm thủ công tạm
Could	Có thì tốt, cắt đầu tiên khi thiếu thời gian
Won't (this time)	Đã bàn và thống nhất không làm lần này

7. Ràng buộc

Loại	Nội dung	Nguồn	Ảnh hưởng
Thời gian	Ngân sách/thời gian dự án chưa xác định chính thức; giả định lộ trình MVP tiêu chuẩn ~9–12 tháng cho toàn sàn	`00-project-brief.md` mục 5, giả định #7	Có thể cần cắt phạm vi module nếu timeline thực tế ngắn hơn
Ngân sách / nguồn lực	Chưa xác định	`00-project-brief.md` mục 6	—
Công nghệ	Triển khai trên AWS; không ràng buộc tech stack cụ thể cho module này	`sections/01-tong-quan.md` §1.5	Kiến trúc chi tiết thuộc GĐ2/Tech Lead
Pháp lý / tuân thủ	NĐ52/85 (thông báo website TMĐT), NĐ13/2023 (bảo vệ dữ liệu cá nhân — địa chỉ/SĐT trong đơn hàng), PCI-DSS phạm vi giảm (không lưu thẻ)	`sections/01-tong-quan.md` §1.5, NFR-05	Cần đại diện Pháp chế xác nhận (chưa có — `OQ-003`); ảnh hưởng RQ-003, RISK-03
Tổ chức / quy trình	Không có hệ thống cũ, không có seller/khách hàng thật để tham chiếu quy trình — mọi giả định phải xác minh trước GĐ2/GĐ3	`00-project-brief.md` mục 3, mục 6	Số lượng `ASM` cao hơn bình thường cho một dự án brownfield

8. Giả định và rủi ro

Chi tiết đầy đủ ở RISK_CartCheckout_v1.0.md. Tóm tắt các mục ảnh hưởng trực tiếp tới phạm vi module này:

ID	Nội dung	Nếu sai thì sao
ASM-01	VNPay/Momo hỗ trợ webhook xác nhận thanh toán gần thời gian thực	Phải đổi cơ chế xác nhận đơn hàng ở GĐ3, ảnh hưởng NFR-01
ASM-02	GHN/GHTK cung cấp API tính phí ship/kiểm tra vùng phục vụ tại checkout	Không hiển thị được phí/thời gian giao theo seller lúc checkout
ASM-05	COD không giới hạn giá trị đơn ở MVP	Thiếu một business rule quan trọng, có thể lộ ở UAT dưới dạng rủi ro tài chính
RISK-01	Bùng đơn COD một phần khi giỏ đa seller bị tách nhiều đơn con	Tổn thất phí vận chuyển hoàn hàng cho seller, tranh chấp seller–sàn
RISK-02	Webhook thanh toán trễ/lỗi khiến đơn kẹt "Chờ thanh toán" dù đã thu tiền	Khiếu nại CSKH, sai lệch đối soát
RISK-03	Chưa có đại diện Pháp chế/Bảo mật rà soát việc chia sẻ PII cho seller	Rủi ro vi phạm NĐ13/2023 khi go-live

9. Tiêu chí thành công của giai đoạn

PO sàn xác nhận đúng phát biểu bài toán ở mục 3 (không phải giải pháp)
PO sàn chốt lại KPI/baseline ở mục 4 (dù chỉ là cam kết đo baseline trong X tuần đầu, không cần số thật ngay)
PO sàn xác nhận điểm nối với module Khuyến mãi/Loyalty (OQ-004) và ranh giới ngoài phạm vi ở mục 5.2
Tech Lead xác nhận sơ bộ tính khả thi của ASM-01, ASM-02 (không cần xác minh đầy đủ ở G1, nhưng phải biết là rủi ro)
RISK-01 (bùng COD) có người chịu trách nhiệm thật và hướng xử lý (chọn 1 trong 2 phương án BA đề xuất, hoặc phương án khác)
Có người đại diện Pháp chế/Bảo mật được chỉ định (OQ-003), dù việc rà soát chi tiết có thể làm ở GĐ2

10. Open Questions

Tổng hợp từ mọi artifact của lần chạy này. Sổ toàn dự án: 00-index/OQ_e-commerce.md.

ID	Câu hỏi	Hỏi ai	Từ ngày	Chặn gì	Phương án BA đề xuất
OQ-001	Tên thật + đầu mối liên lạc của STK-01…STK-06 là gì?	Điều phối dự án / PO	2026-09-08	Ký G1 thật	Dùng vai trò tạm để chạy tiếp; phải có tên thật trước khi coi G1 là ký hợp lệ
OQ-002	Mức Quan tâm × Ảnh hưởng ở `STAKEHOLDER` mục 2 là đánh giá của BA — từng STK có đồng ý không?	STK-01…STK-06	2026-09-08	Chiến lược tiếp cận	Giữ nguyên đánh giá ban đầu, điều chỉnh khi có phản hồi
OQ-003	Ai là đại diện Pháp chế/Bảo mật cho dự án? Cần xác nhận phạm vi lưu/chia sẻ PII khi tách đơn theo seller.	PO sàn	2026-09-08	RISK-03, RQ-003	Đề nghị PO chỉ định trước khi kết thúc GĐ2
OQ-004	Áp coupon (FR-13) và dùng điểm thưởng (FR-14) trong màn hình checkout có thuộc phạm vi module này không, hay là điểm tích hợp với module khác?	PO sàn	2026-09-08	Phạm vi mục 5.1/5.2, thiết kế màn hình checkout ở GĐ3	Đề xuất: coi là điểm tích hợp (module Khuyến mãi/Loyalty sở hữu logic, module này chỉ hiển thị kết quả) — PO quyết
OQ-005	Cần tổ chức phỏng vấn thật với Khách hàng đại diện (STK-02) và Seller đại diện (STK-03) — ai làm đầu mối sắp xếp?	Điều phối dự án / PO sàn	2026-09-08	Chất lượng RQ, phát hiện ngoại lệ thực tế	Đề nghị lên lịch trong tuần đầu GĐ2
OQ-006	Chính sách giới hạn giá trị đơn COD (nếu có) là gì?	PO sàn, Kế toán đối soát	2026-09-08	ASM-05, RISK-01, `BR` ở GĐ2	BA đề xuất 2 phương án ở RISK-01, PO chọn
OQ-007	Baseline thật cho GOAL-01 (tỷ lệ bỏ giỏ hàng) và GOAL-02 (tỷ lệ thanh toán thành công) là bao nhiêu?	PO sàn	2026-09-08	Đo lường hiệu quả ở GĐ5	Đo trong 4–6 tuần đầu soft-launch theo cách đề xuất ở mục 4
OQ-008	Xác nhận lại: cả 4 RQ của module này đều Must — nếu chỉ kịp một nửa thời gian, PO sẽ cắt cái nào?	PO sàn	2026-09-08	Ưu tiên hoá ở GĐ2 (`BACKLOG`)	Đề xuất giữ nguyên cả 4 vì đều thuộc luồng giao dịch lõi, nhưng đây là đề xuất — PO quyết

11. Ngoài phạm vi tài liệu này

Thiết kế màn hình chi tiết (field, validation, message lỗi) → GĐ3, SRS
Quy trình AS-IS/TO-BE chi tiết từng bước, business rule đầy đủ (VD công thức tính phí ship gộp) → GĐ2, PROCESS/BR
Ước lượng công sức, lịch trình → PM
Thiết kế API/kiến trúc tích hợp VNPay/Momo/GHN/GHTK → GĐ2/GĐ3, Tech Lead
Nội dung/mẫu email/SMS thông báo đơn hàng → module Thông báo (FR-12), ngoài phạm vi module này

Tự chấm

Gate G1 (chấm ở mức RIGOR = standard — áp đúng checklist §2 của workflow.md, không bớt/thêm)

#	Tiêu chí	☐/✅	Ghi chú
1	BRIEF có bối cảnh, phát biểu bài toán, phạm vi in/out, GOAL kèm KPI	✅	Có đủ; GOAL chưa có baseline số thật (greenfield) nhưng đã ghi `OQ-007` + đề xuất cách đo, đúng quy tắc "không bỏ trống"
2	STAKEHOLDER đủ 4 nhóm, có tên thật	☐	Đủ 4 nhóm (Quyết định/Sử dụng/Bị ảnh hưởng/Cung cấp thông tin) nhưng chưa có tên thật cho bất kỳ ai — chỉ có vai trò, chờ `OQ-001`. Thiếu hẳn đại diện Pháp chế/Bảo mật (`OQ-003`)
3	ELICITATION có ≥1 buổi với nhóm quyết định và nhóm sử dụng	☐	Có bản tổng hợp có nguồn (từ brief 3 vòng), nhưng không phải buổi làm việc trực tiếp với STK-02 (Sử dụng) riêng cho module này — xem `ELICITATION` mục 0 và `OQ-005`
4	RQ có MoSCoW, truy về được stakeholder cụ thể	✅ (có lưu ý)	4/4 RQ có MoSCoW + nguồn, nhưng nguồn là brief cấp dự án (qua STK-01) chứ chưa phải phỏng vấn riêng module; 100% Must đã ghi nhận và tạo `OQ-008` theo đúng quy tắc thay vì tự quyết
5	RISK/ASM đã ghi, rủi ro mức cao có người chịu trách nhiệm	☐	Đã ghi đủ 6 ASM + 4 RISK (3 mức 🔴); nhưng người chịu trách nhiệm mới là vai trò, chưa có tên thật (`OQ-001`), và RISK-03 chưa có người chịu trách nhiệm nào (chưa có đại diện Pháp chế)
6	KPI có baseline	☐	Cả 2 GOAL đều baseline = ❓ (đúng vì greenfield), đã đề xuất cách đo — chưa phải "có" baseline thật

Kết luận tự chấm: G1 chưa đủ điều kiện ký chính thức theo đúng nghĩa checklist — 3/6 tiêu chí còn ☐ do thiếu tên thật stakeholder, thiếu buổi làm việc trực tiếp, và KPI chưa có baseline số. Đây là kết quả đúng như thiết kế của GĐ1 chạy chế độ go không phỏng vấn thật: sản phẩm là một bộ khung đầy đủ cấu trúc + danh sách việc cụ thể cần làm trước khi PO ký thật. Không tự đánh ✅ cho có.

Quy tắc viết W1–W13

W1	W2	W3	W4	W5	W6	W7	W8	W9	W10	W11	W12	W13
✅	✅	✅	N/A (GĐ1 chưa có luồng lỗi màn hình)	N/A (GĐ1 chưa có text hiển thị)	N/A (GĐ1 chưa có trạng thái thực thể)	N/A (GĐ1 chưa có field/nút)	✅	✅	✅	✅	N/A (GĐ1 không có hình wireframe)	✅

Phần lớn nằm trong mô tả rủi ro (RISK_CartCheckout_v1.0.md RISK-01…04), dùng đúng công thức bắt buộc của template rủi ro "có thể xảy ra <sự kiện>, dẫn tới <hậu quả đo được>" — đây là cú pháp chuẩn của risk-register.md, không phải một phát biểu yêu cầu/NFR mơ hồ.
Một số nằm trong giả định ASM đang chờ xác minh (VD "đồng bộ đủ nhanh" ở ASM-06) — đây là hạn chế thật, chưa xác minh xong nên chưa thể quy về con số cụ thể; đã gắn ASM-06 và lịch xác minh trước GĐ3, không để trôi thành spec chính thức còn mơ hồ.
Một số nằm trong trích dẫn/diễn giải nguồn (F1 ở ELICITATION, ghi chú phạm vi ở BRIEF §5.3, §9) — mô tả khả năng/phạm vi bằng ngôn ngữ tự nhiên, không phải NFR/AC cần đo được ở GĐ1. Không có dòng nào trong 4 file dùng các từ này để né việc quyết định trong một phát biểu RQ/GOAL chính thức (mọi RQ/GOAL đều dùng "phải" và có phép đo). Đã quét TBD|TODO|\?\?\? — 0 kết quả là placeholder chưa xử lý thật (chỉ có 1 dòng tự nhắc tới chuỗi TBD|TODO trong chính câu giải thích quy tắc này); mọi chỗ chưa rõ đều dùng OQ-nnn.

26 KiB Raw Blame History Unescape Escape