Bốn tầng của yêu cầu (Four layers of requirements)

Một lỗi phổ biến là gọi mọi tài liệu trong dự án là “spec”. Thật ra có bốn tầng, mỗi tầng trả lời một câu hỏi riêng. Bạn không cần biến chúng thành bốn bộ tài liệu cồng kềnh, nhưng nên hiểu mỗi tầng đang trả lời gì.

Bốn câu hỏi

TầngCâu hỏiAi chịu trách nhiệm
Business Requirement (BR)Vì sao làm việc này?PO / nghiệp vụ
Use Case (UC)Ai làm gì với hệ thống?PO + Dev cùng viết
Entity ModelLàm với những khái niệm (danh từ) nào?Dev + nghiệp vụ
Acceptance CriteriaBiết đúng bằng cách nào?Dev + QA

Dòng chảy: một BR thường sinh ra một hoặc vài Use Case; mỗi Use Case tham chiếu tới các Entity; mỗi Use Case kết thúc bằng các AC - và chính AC là chỗ nối spec trực tiếp sang test.

Vì sao user story ba dòng không đủ

“Là khách hàng, tôi muốn đặt hàng bằng QR Code, để thanh toán nhanh hơn.” - ba dòng quen thuộc, nhưng chỉ là điểm bắt đầu cho một cuộc trò chuyện. Trước đây cuộc trò chuyện đó diễn ra giữa PO và dev; giờ nếu AI viết code, nó cần được ghi lại rõ hơn, nếu không AI sẽ tự điền phần còn thiếu (QR hết hạn 5 phút hay 15 phút? “Claude chọn…”).

Liên quan