Chuỗi Business Analyst · Kỳ 5 trên 11
Yêu cầu đã lấy xong, đã ghi vào danh sách. Nhưng một danh sách dài mấy chục dòng thì cậu lập trình viên của chị Hà vẫn chưa thể bắt tay làm được. Cậu ấy cần biết chi tiết hơn: bấm nút này thì chuyện gì xảy ra, nhập sai thì báo lỗi gì, ai được xem màn hình nào. Đây là lúc BA phải viết tài liệu. Có hai cách viết phổ biến nhất: FS (viết kiểu truyền thống) và user story (viết kiểu ngắn gọn). Kỳ 5 giải thích cả hai, và quan trọng hơn là khi nào dùng cái nào.
(Chị Hà và tiệm cơm là tình huống tưởng tượng để minh họa.)
FS là gì?
FS là viết tắt của Functional Specification, tiếng Việt hay gọi là đặc tả chức năng. Hiểu đơn giản, đây là một cuốn “sách hướng dẫn” mô tả sản phẩm sẽ hoạt động thế nào, trước khi sản phẩm tồn tại. Giống như công thức nấu ăn của một món chưa nấu: có nguyên liệu gì, làm từng bước ra sao, nếu cháy thì xử lý thế nào.
Một FS tử tế thường trả lời được cho mỗi chức năng:
- Chức năng này để làm gì, ai dùng nó.
- Điều kiện trước khi dùng: phải đăng nhập chưa, phải có đơn chưa.
- Các bước diễn ra, từng bước một, theo thứ tự.
- Các trường hợp khác thường: nhập sai, hết giờ chốt đơn, mất mạng.
- Quy tắc nghiệp vụ liên quan: ví dụ chỉ được hủy đơn trước giờ chốt.
- Thông báo hiển thị ở từng tình huống.
Ví dụ trích từ FS của chức năng “Hủy đơn cơm” ở tiệm chị Hà: “Khách chỉ được hủy khi đơn đang ở trạng thái Đã ghi nhận và chưa quá 9 giờ 30. Nếu quá giờ, hệ thống hiển thị thông báo ‘Đã hết giờ chốt đơn, anh chị vui lòng liên hệ quán’. Nếu hủy thành công, hệ thống đổi trạng thái đơn thành Đã hủy và gửi tin xác nhận.”
Ưu điểm của FS là đầy đủ, ít sót, hợp với dự án lớn hoặc làm theo kiểu tuần tự mà mình đã nhắc ở Kỳ 2. Nhược điểm là dày, viết lâu, và đôi khi chưa kịp đọc xong thì yêu cầu đã đổi.
User story là gì?
User story (tạm dịch là “câu chuyện người dùng”) là cách viết yêu cầu thật ngắn, từ góc nhìn của người dùng, thường theo mẫu một câu:
> Với tư cách là [một loại người dùng], tôi muốn [làm một việc], để [đạt một lợi ích].
Ví dụ với tiệm chị Hà:
- Với tư cách là khách, tôi muốn hủy đơn đã đặt, để không bị tính tiền suất cơm tôi không ăn.
- Với tư cách là bếp trưởng, tôi muốn xem tổng số suất theo món vào mỗi sáng, để nấu đủ, không dư.
Câu thứ ba “để …” là phần nhiều người hay bỏ, nhưng lại quan trọng nhất. Nó cho cả nhóm biết vì sao chức năng này cần có. Khi đội kỹ thuật hiểu lý do, họ có thể đề xuất cách làm tốt hơn thay vì làm đúng từng chữ.
User story không đứng một mình. Nó đi kèm tiêu chí chấp nhận (acceptance criteria), tức là điều kiện để coi story này đã xong. Ví dụ cho story “hủy đơn”:
- Khách hủy được khi đơn chưa quá 9 giờ 30.
- Sau 9 giờ 30, hệ thống không cho hủy và hiện thông báo hết giờ.
- Khi hủy thành công, khách nhận được tin xác nhận.
Có người viết tiêu chí theo kiểu Given – When – Then (Cho trước – Khi – Thì), ví dụ: Cho trước đơn chưa quá giờ chốt, khi khách bấm hủy, thì đơn được hủy và khách nhận tin xác nhận. Kiểu này giúp người kiểm thử đọc là biết cách thử.
FS và user story khác nhau ở đâu?
Có thể hình dung bằng chuyện đi chợ:
- FS giống một bản thực đơn kèm công thức đầy đủ cho cả tuần: món nào, nguyên liệu bao nhiêu, nấu bao lâu. Làm theo là ra, nhưng lập ra mất nhiều thời gian.
- User story giống mảnh giấy ghi nhanh trên tủ lạnh: “Con muốn ăn canh chua vì hôm nay trời nóng”. Ngắn, dễ thêm bớt, nhưng cần người nấu hiểu ý và hỏi lại khi chưa rõ.
| FS | User story | |
|---|---|---|
| Độ dài | Dài, chi tiết | Ngắn, ghi ý chính |
| Góc nhìn | Hệ thống làm gì | Người dùng cần gì và vì sao |
| Hợp với | Dự án lớn, quy trình chặt, làm tuần tự | Làm theo chu kỳ ngắn, yêu cầu hay đổi |
| Rủi ro | Viết lâu, dễ lỗi thời | Dễ thiếu chi tiết nếu không có tiêu chí chấp nhận |
Không có cách nào “đúng hơn”. Nhiều nhóm kết hợp cả hai: dùng user story để nói điều cần làm, rồi bổ sung phần mô tả chi tiết cho những chức năng phức tạp như thanh toán hay tính tiền.
Viết một user story tốt
Mấy điều giúp user story đỡ “chung chung”:
- Một story một việc. Nếu trong câu có chữ “và”, hãy cân nhắc tách đôi.
- Nêu đúng loại người dùng. “Người dùng” quá mơ hồ, hãy ghi rõ khách, bếp trưởng hay người giao cơm.
- Có “để …” nói rõ lợi ích.
- Có tiêu chí chấp nhận, càng cụ thể càng tốt, nếu có thể thì đo được.
- Đủ nhỏ để làm xong trong một chu kỳ ngắn. Story quá to như “làm toàn bộ hệ thống đặt cơm” thì nên chia nhỏ.
Những lỗi thường gặp
- Viết story như danh sách chức năng của hệ thống (“hệ thống gửi email”) thay vì từ góc nhìn người dùng.
- Bỏ phần “để …” nên không ai biết lý do.
- Không có tiêu chí chấp nhận, đến lúc nghiệm thu mỗi người hiểu một kiểu.
- Viết FS quá dài mà không ai đọc. Một tài liệu hay là tài liệu được đọc.
- Chép nguyên văn lời khách hàng mà không phân tích lại.
Tạm kết
FS và user story đều chỉ là công cụ để cả nhóm hiểu cùng một điều. Chọn cách nào tùy vào dự án, miễn là người đọc hiểu được và người kiểm thử thử được.
Kỳ trước nói về cách lấy yêu cầu từ khách hàng. Kỳ sau mình sẽ nói về ba loại sơ đồ BA hay vẽ: BA Kỳ 6: Use case, ERD và BPMN, cái nào dùng để làm gì.
