Chuỗi Business Analyst · Kỳ 3 trên 11
Trong cuộc họp đầu tiên của dự án đặt cơm, chị Hà nói chắc nịch: “Ứng dụng phải nhanh, dễ dùng, bảo mật nhé.” Cậu lập trình viên gật đầu rồi hỏi nhỏ: “Chị ơi, nhanh là bao nhiêu giây ạ? Dễ dùng là sao ạ?” Chị Hà ngẩn người.
Chuyện này xảy ra ở rất nhiều dự án, và nó dẫn thẳng tới một câu hỏi: requirement là gì, và phải viết thế nào để người khác hiểu giống mình? Kỳ 3 trả lời câu đó bằng ví dụ ứng dụng đặt cơm của chị Hà.
(Chị Hà và cuộc họp là tình huống tưởng tượng để minh họa.)
Requirement là gì? Cứ nghĩ như gọi món
Requirement (tiếng Việt gọi là yêu cầu) là một điều mà sản phẩm phải làm được hoặc phải đáp ứng để giải quyết vấn đề của người dùng. Ra quán, bạn gọi “một phần cơm sườn, ít cay, không hành”. Đó là một yêu cầu: có món gì, làm ra sao, kèm điều kiện gì.
Điểm hay bị nhầm là yêu cầu nói cần gì, không nói làm thế nào. “Cần một nút màu xanh ở góc phải” là một cách làm. “Khách đặt xong phải nhận được xác nhận ngay” mới là yêu cầu. Nói đúng yêu cầu thì đội kỹ thuật còn chỗ chọn cách làm tốt nhất, giống như đầu bếp chọn cách nấu sao cho ra đúng món bạn gọi.
Ba tầng yêu cầu: từ muốn đến làm
Yêu cầu đi từ lớn đến nhỏ, giống bản vẽ một ngôi nhà:
- Yêu cầu nghiệp vụ (business requirement): mục tiêu lớn của doanh nghiệp. Với nhà là “phải mát vào mùa hè”. Với tiệm cơm là “giảm số suất nấu sai, nấu thiếu”.
- Yêu cầu người dùng (user requirement): điều từng nhóm người cần. “Phòng ngủ phải mát” với nhà. “Khách muốn tự đặt mà không cần nhắn Zalo” với tiệm cơm.
- Yêu cầu giải pháp (solution requirement): những điều cụ thể sản phẩm phải có để đáp ứng hai tầng trên. Tầng này lại chia thành hai loại rất quan trọng, mình nói ngay bên dưới.
Mỗi yêu cầu ở tầng cuối nên truy ngược được về một nhu cầu thật. Nếu truy không ra, rất có thể bạn đang làm một thứ không ai cần.
Yêu cầu chức năng: hệ thống làm gì
Yêu cầu chức năng (functional requirement) mô tả sản phẩm làm được những việc gì. Với ngôi nhà, đó là “phải có bếp, có phòng ngủ, có nhà vệ sinh”. Với ứng dụng đặt cơm:
- Khách chọn món, chọn số lượng và giờ nhận cơm.
- Hệ thống gửi thông báo xác nhận sau khi đặt thành công.
- Khách hủy được đơn trước giờ chốt.
- Bếp xem được tổng số suất theo từng món vào mỗi sáng.
Yêu cầu phi chức năng: làm tốt đến đâu
Yêu cầu phi chức năng (non-functional requirement) nói về chất lượng, tức là làm tốt đến mức nào. Với nhà là “bếp phải thoáng, cửa phải chống trộm”. Những nhóm hay gặp với phần mềm:
- Tốc độ: trang tải nhanh đến mức nào, bao nhiêu khách đặt cùng lúc thì vẫn chạy ổn.
- Bảo mật: ai xem được dữ liệu nào, thông tin cá nhân của khách được bảo vệ ra sao.
- Độ ổn định: giờ cao điểm 10 giờ sáng có bị đơ không.
- Dễ dùng: người lần đầu dùng có tự đặt được không.
- Dễ mở rộng: sau này mở thêm chi nhánh thứ hai thì có dễ không.
Người mới hay quên nhóm này vì khách hàng ít khi nói tới, cho đến lúc hệ thống chậm rì hoặc lộ dữ liệu. Chủ động hỏi về chúng là dấu hiệu của một BA có kinh nghiệm.
Câu “nhanh, dễ dùng” của chị Hà nên viết lại thế nào?
Một yêu cầu tốt có năm đặc điểm. Mình áp luôn vào câu của chị Hà:
| Đặc điểm | Nghĩa là | Chưa tốt | Tốt hơn |
|---|---|---|---|
| Rõ ràng | Chỉ có một cách hiểu | “Ứng dụng phải dễ dùng” | “Khách lần đầu đặt cơm xong trong tối đa 5 bước” |
| Đo được | Có con số hoặc tiêu chí | “Phải nhanh” | “Danh sách món tải xong trong tối đa 3 giây” |
| Kiểm thử được | Thử xong biết đạt hay chưa | “Dữ liệu phải an toàn” | “Mật khẩu được lưu dưới dạng mã hóa, không hiển thị lại” |
| Nhất quán | Không mâu thuẫn với yêu cầu khác | Chỗ này ghi hủy trước 1 giờ, chỗ kia ghi trước 2 giờ | Một quy tắc hủy duy nhất, ghi ở một nơi |
| Có ưu tiên | Biết cái nào phải có, cái nào để sau | Cái gì cũng “quan trọng” | Phân thành phải có, nên có, có thì tốt |
Các con số trong ví dụ chỉ để minh họa. Mỗi dự án sẽ tự thỏa thuận mức phù hợp với khách hàng.
Có thêm hai thuật ngữ bạn sẽ gặp hoài. Tiêu chí chấp nhận (acceptance criteria) là điều kiện để coi một yêu cầu đã đạt, ví dụ “đặt sau 9 giờ 30 thì hệ thống phải báo hết giờ chốt đơn”. Truy vết yêu cầu (traceability) nghe cao siêu nhưng chỉ là biết mỗi yêu cầu bắt nguồn từ đâu và được kiểm tra bằng kịch bản nào, như khi bạn đánh số từng món trong thực đơn và đối chiếu với phiếu gọi món.
Ghi yêu cầu sao cho dễ theo dõi
- Đánh mã cho từng yêu cầu, ví dụ FR-001 cho chức năng, NFR-001 cho phi chức năng, để nhắc tới khỏi nhầm.
- Ghi nguồn: yêu cầu này do ai nói, trong cuộc họp nào.
- Ghi trạng thái: đề xuất, đã duyệt, đang làm hay đã nghiệm thu.
- Một yêu cầu một ý. Câu nào có chữ “và” thì thường nên tách đôi.
Ghi vậy thì khi khách hỏi “cái này có trong phạm vi không”, bạn trả lời được ngay.
4 lỗi hay gặp
- Trộn cách làm vào yêu cầu, như chỉ định luôn màu nút thay vì nêu nhu cầu.
- Dùng từ mơ hồ (nhanh, dễ dùng, thân thiện, linh hoạt) mà không kèm con số.
- Chỉ viết đường đi suôn sẻ, quên trường hợp lỗi, hết hạn, mất kết nối.
- Không hỏi về phi chức năng, đến lúc nghiệm thu mới phát hiện thiếu.
Tạm kết
Hiểu yêu cầu là gì chưa quan trọng bằng việc cả nhóm hiểu giống nhau. Hãy ghi ra, đọc lại với khách hàng và đội kỹ thuật, rồi mới coi là chốt.
Nếu cần ôn bối cảnh, xem BA Kỳ 2: BA làm gì trong một dự án phần mềm. Bước tiếp theo, cách hỏi để lấy được yêu cầu thật, nằm ở BA Kỳ 4: Lấy yêu cầu từ khách hàng.
