Solution Requirement
Tầng mô tả hệ thống phải làm được gì và làm tốt đến mức nào, chia thành yêu cầu chức năng và phi chức năng. Đây là tầng BA viết ra, không phải tầng khách đọc cho chép.
Định nghĩa
Đến tầng này thì câu chuyện chuyển từ "người ta cần gì" sang "hệ thống phải làm gì". Solution requirement mô tả năng lực và tính chất của giải pháp, chi tiết đủ để dev code và QC viết test case. Trong bốn tầng của BABOK v3, đây là tầng dày chữ nhất. Phần lớn công viết lách của BA đổ vào đây.
Hai tầng trên là nghe và hiểu. Tầng này là viết. Sai ở đây thì dev code sai, và không ai phát hiện cho tới khi test.
Gồm những gì
Chỉ hai loại con, và ranh giới khá rõ:
- Functional requirement: hệ thống làm được gì. Tính tiền, gửi thông báo, chặn đơn trùng, xuất báo cáo.
- Non-functional requirement: làm tốt đến đâu. Nhanh bao nhiêu, chịu được bao nhiêu người, mã hoá thế nào, chạy trên trình duyệt nào.
Nhiều bạn nhớ nhầm rằng business rule cũng nằm trong đây. Không hẳn. Business rule là chính sách của doanh nghiệp, tồn tại kể cả khi không có phần mềm nào; solution requirement là thứ mô tả cách hệ thống thực thi chính sách đó. Tách riêng ra thì lúc chính sách đổi, bạn biết chính xác chỗ nào phải sửa.
So sánh với stakeholder requirement
| Stakeholder requirement | Solution requirement | |
|---|---|---|
| Chủ ngữ của câu | Người dùng | Hệ thống |
| Ai viết | Ghi lại từ người dùng nghiệp vụ | BA viết ra, khách xác nhận |
| Mức chi tiết | Việc cần làm được | Đủ để code và test |
| Sống ở đâu | BRD, biên bản khảo sát | FRD, SRS, user story + AC |
| Ví dụ | Kế toán đối soát được giao dịch theo ngày | Hệ thống cho phép tải file đối soát .csv, khớp theo mã giao dịch, hiển thị danh sách lệch |
Ví dụ thực tế
Tổng đài của một sàn thương mại điện tử nội địa nhận trung bình 640 cuộc gọi mỗi ngày chỉ để huỷ đơn. Sàn chạy khoảng 11.400 đơn một ngày, và đội sản phẩm quyết định cho khách tự huỷ.
Stakeholder requirement: khách muốn tự huỷ đơn mà không phải gọi tổng đài; đội kho không muốn nhận lệnh huỷ khi đơn đã lên xe.
Solution requirement viết ra từ đó:
- FR: người mua huỷ được đơn ở trạng thái "Chờ xác nhận" và "Đang chuẩn bị hàng" qua ứng dụng.
- FR: khi đơn đã chuyển sang "Đã bàn giao vận chuyển", nút huỷ ẩn đi và hệ thống hiển thị hướng dẫn liên hệ tổng đài.
- FR: mỗi lần huỷ ghi lại lý do do người mua chọn từ danh mục 6 lý do và đẩy sự kiện sang hệ thống kho trong vòng 5 giây.
- NFR: API huỷ đơn xử lý được 5 yêu cầu/giây ở giờ cao điểm (tương đương khoảng 8% đơn bị huỷ, dồn vào khung 20–22h), thời gian phản hồi p95 dưới 800ms.
- NFR: lịch sử huỷ đơn lưu tối thiểu 24 tháng, truy xuất được theo mã đơn.
Chỗ hay bị viết hỏng
Viết solution requirement mà thực chất là mô tả giao diện. "Nút Huỷ đơn màu đỏ nằm góc phải phía dưới" không phải yêu cầu, đó là quyết định thiết kế. Nếu bạn khoá cứng nó vào tài liệu, mỗi lần designer chỉnh Figma là tài liệu lệch, và sau vài vòng thì không ai tin tài liệu nữa.
Ngược lại, viết mơ hồ tới mức dev phải đoán cũng tệ ngang. "Hệ thống xử lý các trường hợp huỷ đơn hợp lệ" — hợp lệ là những trạng thái nào, ai định nghĩa. Câu đó chắc chắn sinh ra một cuộc họp làm rõ vào giữa sprint.
Mức chi tiết vừa đủ có một phép thử đơn giản: đưa cho một bạn dev chưa từng dự họp nào của dự án đọc. Bạn ấy hỏi lại bao nhiêu câu thì bạn biết tài liệu thiếu bấy nhiêu chỗ.
Câu hay bị hỏi phỏng vấn
"Solution requirement khác business requirement chỗ nào" — trả lời bằng chủ ngữ: business requirement nói về doanh nghiệp và mục tiêu, solution requirement nói về hệ thống và hành vi. Kèm một ví dụ hai câu cho cùng một dự án thì thường là đủ.
Câu khó hơn: "Ai chịu trách nhiệm cho solution requirement?" Đáp án ngắn là BA, và điều đó có nghĩa là nếu tài liệu mơ hồ dẫn tới code sai, đừng đổ cho khách nói không rõ.
