Requirement
Phát biểu về một nhu cầu, một năng lực hệ thống phải có, hoặc một điều kiện phải thoả mãn — viết ra để khách, BA, dev và QC hiểu giống nhau chứ không mỗi người một kiểu.
Định nghĩa
Nghề BA xoay quanh đúng một thứ: làm cho cái đang nằm trong đầu người này chui được sang đầu người kia mà không méo. Cái "thứ" đó gọi là requirement. BABOK v3 định nghĩa nó là một phát biểu có thể sử dụng được (usable representation) về nhu cầu — chú ý chữ "có thể sử dụng được", nghĩa là nói miệng trong cuộc họp thì chưa tính, phải ghi lại được ở dạng nào đó thì mới thành requirement.
Requirement ghi lại điều gì phải đúng thì khách mới hết đau, chứ không dừng ở việc chép lại câu "khách muốn gì".
Bốn tầng yêu cầu theo BABOK
Đây là chỗ nhiều bạn junior bị rối, vì trong dự án ai cũng gọi tuốt là "requirement".
| Tầng | Trả lời câu hỏi | Ai phát biểu |
|---|---|---|
| Business requirement | Vì sao làm dự án này | Ban lãnh đạo, chủ đầu tư |
| Stakeholder requirement | Nhóm người dùng này cần làm được gì | Trưởng phòng, nhân viên nghiệp vụ |
| Solution requirement | Hệ thống phải làm gì và tốt đến đâu | BA viết, dựa trên hai tầng trên |
| Transition requirement | Cần gì để chuyển từ hệ cũ sang hệ mới | BA, PM, đội vận hành |
Tầng trên là lý do tồn tại của tầng dưới. Nếu bạn không truy được một màn hình đang code về tới một business requirement nào đó, khả năng cao màn hình đó không nên tồn tại.
Một yêu cầu tốt trông như thế nào
Không cần thuộc lòng danh sách nào. Nhưng có mấy tính chất đáng nhớ, vì QC sẽ bắt lỗi bạn bằng đúng chúng.
Kiểm chứng được là tính chất đầu tiên: đọc xong phải nghĩ ra được cách test. "Hệ thống phải thân thiện" thì chịu; "màn hình danh sách tải xong dưới 2 giây với 10.000 bản ghi" thì test được ngay. Kế đó là không mơ hồ, tức một câu chỉ hiểu được một nghĩa — tránh "và/hoặc", "nếu cần thiết", "tương tự như trên". Rồi tới nguyên tử: một yêu cầu một ý, và câu nào có chữ "đồng thời" thì thường là hai yêu cầu bị dính vào nhau.
Hai tính chất còn lại ít được nhắc lúc mới vào nghề. Truy vết được: biết nó từ đâu ra, ai yêu cầu, phần nào của giải pháp đang gánh nó. Khả thi: nằm trong ngân sách, thời gian và công nghệ đang có, chứ đừng trông vào thứ sang năm mới mua.
Ví dụ thực tế
Ba bạn trực tổng đài của một chuỗi phòng khám mười một cơ sở nghe không xuể 870 lượt đặt lịch mỗi ngày. Dự án app đặt lịch bắt đầu từ chỗ đó.
- Business requirement: giảm 30% lượng cuộc gọi vào tổng đài đặt lịch trong 6 tháng.
- Stakeholder requirement: lễ tân phải xem được lịch trống của toàn bộ bác sĩ trong ngày trên một màn hình.
- Solution requirement (FR): hệ thống cho phép lễ tân lọc slot trống theo cơ sở, chuyên khoa và khung giờ.
- Solution requirement (NFR): màn hình lịch hiển thị dưới 2 giây khi có 58 bác sĩ và 870 slot.
- Transition requirement: nhập 38.400 hồ sơ bệnh nhân từ file Excel của phần mềm cũ, đối soát trùng theo số điện thoại.
Lỗi hay gặp
Ghi lại lời khách nguyên văn rồi gọi đó là requirement. Khách nói "tôi muốn có cái nút xuất Excel" — đó là giải pháp khách tự nghĩ ra, không phải nhu cầu. Hỏi thêm một câu "anh xuất ra để làm gì" thì hoá ra họ cần gửi số liệu cho kế toán mỗi sáng thứ Hai, và cái cần làm là một email tự động chứ không phải cái nút.
Chuyện hay gặp không kém là trộn requirement với design. "Dropdown chọn tỉnh/thành" là design. Requirement là "người dùng chọn được địa chỉ giao hàng theo đơn vị hành chính hiện hành". Viết chặt quá vào UI thì mỗi lần Figma đổi là tài liệu sai theo.
Còn cái đau nhất: không có ai chốt. Tài liệu vẫn ở trạng thái draft, sprint vẫn chạy, đến khi tranh cãi thì không có bản nào để mở ra làm căn cứ. Requirement chỉ có giá trị khi có người ký vào và có ngày tháng.
Nếu bạn mới vào nghề, hãy tập một thói quen nhỏ: mỗi yêu cầu bạn viết ra, tự hỏi "ai sẽ nổi giận nếu cái này không có". Không trả lời được thì bỏ.
