Viết yêu cầu phần mềm là mô tả điều hệ thống phải làm và phải đạt, bằng ngôn ngữ đủ rõ để đội phát triển xây đúng và bên đặt hàng kiểm tra được khi nghiệm thu. Với bên đặt hàng, có ba lớp cần viết: yêu cầu kinh doanh (vì sao làm, đo thành công bằng gì), yêu cầu người dùng (ai cần làm gì) và yêu cầu hệ thống (chức năng cụ thể và các ràng buộc chất lượng như tốc độ, bảo mật, sẵn sàng).
Tài liệu chứa các lớp đó có nhiều tên: BRD (tài liệu yêu cầu kinh doanh), SRS (đặc tả yêu cầu phần mềm), hay một danh sách user story trong dự án agile. Tên gọi không quan trọng bằng ba phẩm chất: mỗi yêu cầu có lý do, có người cần, và có cách kiểm chứng. Bài này giải thích cấu trúc từng loại tài liệu, cách viết user story và tiêu chí chấp nhận, cách xếp ưu tiên, và mười dấu hiệu một yêu cầu sẽ gây tranh cãi lúc nghiệm thu.
Vì sao yêu cầu là nơi dự án phần mềm hỏng nhiều nhất
Từ thập niên 1980, Barry Boehm đã chỉ ra trong Software Engineering Economics (1981) rằng chi phí sửa một sai sót tăng mạnh theo giai đoạn phát hiện: hiểu sai yêu cầu phát hiện lúc viết đặc tả rẻ hơn nhiều lần so với phát hiện khi hệ thống đã chạy. Con số cụ thể trong các nghiên cứu về sau dao động và bị tranh luận, nhưng hướng của xu thế thì nhất quán: sai ở yêu cầu là sai đắt nhất vì mọi thứ phía sau được xây trên nó.
Ở các dự án đặt làm tại Việt Nam, kịch bản quen thuộc là bên đặt hàng nói "giống phần mềm cũ nhưng tốt hơn", đội phát triển làm theo cách họ hiểu, và đến buổi nghiệm thu thì cả hai mới phát hiện mỗi bên có một bức tranh khác. Cái thiếu không phải sự nhiệt tình mà là một tài liệu chung, đủ cụ thể, được cả hai ký xác nhận.
Yêu cầu cũng không đứng yên. Barry Boehm và về sau Steve McConnell mô tả "nón bất định": ở đầu dự án, sai số ước lượng rất rộng và chỉ thu hẹp dần khi yêu cầu được làm rõ. Vì vậy mục tiêu không phải viết một bộ yêu cầu hoàn hảo ngay từ đầu, mà viết đủ rõ cho phần sắp làm, và có cơ chế quản lý khi yêu cầu thay đổi.
Một nguyên nhân ít được nhắc là khoảng cách ngôn ngữ. Người nghiệp vụ nói bằng chứng từ, ngoại lệ và kinh nghiệm ("đơn này phải chờ anh Hùng duyệt"), còn lập trình viên cần trạng thái, điều kiện và quy tắc ("đơn trên ngưỡng giá trị X chuyển trạng thái chờ duyệt cấp hai"). Tài liệu yêu cầu tốt là bản dịch giữa hai thế giới đó, và người dịch giỏi là người hỏi "nếu không phải anh Hùng thì sao, nếu anh Hùng nghỉ phép thì sao".
BRD, SRS và product backlog khác nhau thế nào
Ba dạng tài liệu này không loại trừ nhau. Dự án theo mô hình thác nước thường có BRD rồi SRS; dự án agile thường có tầm nhìn sản phẩm ngắn gọn và một backlog user story được làm mịn dần. Nhiều dự án đặt làm dùng kết hợp: BRD để ký hợp đồng, backlog để làm việc hằng ngày.
| Tiêu chí | BRD | SRS | Product backlog |
|---|---|---|---|
| Trả lời câu hỏi | Vì sao làm, cho ai, đo thành công thế nào | Hệ thống phải làm gì, đạt chất lượng nào | Việc gì có giá trị nhất cần làm tiếp |
| Người viết chính | Chủ dự án, phân tích nghiệp vụ phía doanh nghiệp | Phân tích nghiệp vụ, kiến trúc sư (thường phía nhà cung cấp) | Product Owner, cùng đội phát triển |
| Mức chi tiết | Quy trình, mục tiêu, phạm vi, ràng buộc | Từng chức năng, dữ liệu, giao diện, phi chức năng | Chi tiết dần: việc gần thì kỹ, việc xa thì thô |
| Tính ổn định | Ít đổi | Đổi qua quy trình kiểm soát thay đổi | Đổi liên tục, có chủ ý |
| Chuẩn tham khảo | Thực hành phân tích nghiệp vụ (BABOK) | ISO/IEC/IEEE 29148, kế thừa IEEE 830 | Scrum Guide và thực hành user story |
IEEE 830 (bản 1998) từng là mẫu SRS phổ biến nhất; nó đã được thay bằng ISO/IEC/IEEE 29148, bản đầu năm 2011 và bản sửa đổi năm 2018. Bạn không cần tuân thủ chuẩn từng đề mục, nhưng danh sách đặc tính của một yêu cầu tốt trong chuẩn này, như cần thiết, không mơ hồ, khả thi, kiểm chứng được, nhất quán, là bộ lọc rất đáng dùng khi rà soát.
User story và tiêu chí chấp nhận
User story là một câu mô tả nhu cầu từ góc người dùng, dạng quen thuộc trong tiếng Anh là "As a… I want… so that…", tiếng Việt thường viết: "Là vai trò, cần làm gì, để đạt được gì". Mẫu này xuất phát từ nhóm làm việc tại Connextra ở Anh đầu những năm 2000 và được Mike Cohn phổ biến trong cuốn User Stories Applied (2004). Ví dụ: "Là thủ kho, cần quét mã vạch để xuất hàng, để không phải gõ mã và giảm nhầm lẫn."
Bản thân câu story chỉ là lời nhắc cho một cuộc trao đổi. Phần làm nó nghiệm thu được là tiêu chí chấp nhận. Cách viết hiệu quả là dạng kịch bản Cho trước – Khi – Thì (Given – When – Then): "Cho trước phiếu xuất đã duyệt, khi thủ kho quét một mã không có trong phiếu, thì hệ thống báo lỗi bằng âm thanh và không trừ tồn". Mỗi story nên có ba đến bảy kịch bản, gồm trường hợp thường, trường hợp biên và trường hợp lỗi.
Bill Wake đề xuất năm 2003 bộ tiêu chí INVEST cho story tốt: độc lập, thương lượng được, có giá trị, ước lượng được, nhỏ, kiểm thử được. Với bên đặt hàng, hai chữ quan trọng nhất là "có giá trị" và "kiểm thử được". Story kiểu "xây dựng cơ sở dữ liệu khách hàng" không có giá trị trực tiếp cho người dùng nào, và không biết thế nào là xong.
Yêu cầu phi chức năng: phần bị bỏ quên
Yêu cầu chức năng mô tả hệ thống làm gì; yêu cầu phi chức năng mô tả nó làm tốt đến mức nào. Mô hình chất lượng ISO/IEC 25010 chia thành nhiều đặc tính; dưới đây là những nhóm bên đặt hàng nên viết thành con số, kèm ví dụ giả định:
- Hiệu năng: 95% thao tác tra cứu dưới 2 giây khi có 300 người dùng đồng thời; báo cáo tháng xuất xong trong 30 giây.
- Sẵn sàng: hoạt động 99,5% thời gian trong giờ làm việc; cửa sổ bảo trì báo trước và ngoài giờ cao điểm.
- Bảo mật: phân quyền theo vai trò và chi nhánh; lưu nhật ký thao tác sửa xoá dữ liệu tài chính tối thiểu một số năm theo chính sách nội bộ.
- Khả năng dùng: nhân viên mới làm được năm thao tác chính sau một buổi hướng dẫn; dùng được trên điện thoại cho nhân viên hiện trường.
- Khôi phục: mất dữ liệu tối đa một giờ (RPO), khôi phục dịch vụ trong bốn giờ (RTO) khi sự cố máy chủ.
- Khả năng bảo trì và chuyển giao: mã nguồn có tài liệu kiến trúc, hướng dẫn cài đặt, bộ kiểm thử tự động cho các luồng chính.
- Tuân thủ: xử lý dữ liệu cá nhân theo quy định hiện hành về bảo vệ dữ liệu cá nhân; hoá đơn điện tử theo chuẩn cơ quan thuế.
Thiếu phần này, hệ thống có thể đáp ứng đủ mọi chức năng mà vẫn không dùng được: chạy chậm vào cuối tháng, sập khi khuyến mãi, hay không chuyển giao được vì chỉ một lập trình viên hiểu mã. Những tranh chấp tốn kém nhất thường nằm ở đây, vì không có con số thì không bên nào chứng minh được bên kia sai.
Xếp ưu tiên bằng MoSCoW
MoSCoW do Dai Clegg đề xuất khi làm việc tại Oracle giữa thập niên 1990 và được đưa vào phương pháp DSDM. Nó buộc nhóm phân loại thay vì đánh dấu mọi thứ là quan trọng.
| Nhóm | Ý nghĩa | Câu hỏi kiểm tra | Tỷ trọng gợi ý |
|---|---|---|---|
| Must have | Thiếu thì hệ thống không dùng được hoặc vi phạm pháp lý | Nếu thiếu, có đưa vào vận hành được không? | Không quá khoảng 60% công sức |
| Should have | Quan trọng nhưng có cách làm tạm | Có thể làm tay hoặc chờ đợt sau vài tuần không? | Khoảng 20% |
| Could have | Có thì tốt, ảnh hưởng nhỏ | Người dùng có phàn nàn nhiều nếu thiếu không? | Khoảng 20%, là vùng đệm |
| Won't have (lần này) | Đã thống nhất không làm trong đợt này | Có ghi lại để xem xét đợt sau không? | Ghi rõ để tránh hiểu lầm |
Tỷ trọng gợi ý theo tinh thần hướng dẫn của DSDM: nhóm Must chiếm phần lớn nhưng không phải toàn bộ, để còn vùng đệm khi ước lượng sai. Nhóm "Won't have" có giá trị không kém: viết ra điều không làm giúp tránh câu "tưởng là có" ở buổi nghiệm thu. Mô hình Kano (Noriaki Kano, 1984) là một cách bổ sung, phân biệt tính năng cơ bản, tính năng một chiều và tính năng gây thích thú.
Mười dấu hiệu một yêu cầu sẽ gây tranh cãi
Dùng danh sách này khi rà soát tài liệu trước khi ký. Mỗi dấu hiệu là một cuộc họp căng thẳng trong tương lai:
- Có từ mơ hồ: nhanh, dễ dùng, linh hoạt, đầy đủ, hiện đại, tối ưu, thân thiện.
- Có "v.v." hoặc "và các chức năng liên quan" — phạm vi mở không giới hạn.
- Mô tả giải pháp thay cho vấn đề, khiến đội phát triển mất quyền đề xuất cách tốt hơn.
- Không nói ai dùng: "hệ thống cho phép xuất báo cáo" — ai được xuất, báo cáo gì, dữ liệu nào?
- Không có trường hợp ngoại lệ: hàng trả lại, đơn huỷ giữa chừng, khách đổi địa chỉ sau khi đóng gói.
- Hai yêu cầu mâu thuẫn mà không có thứ tự ưu tiên.
- Dẫn chiếu "như phần mềm cũ" mà không mô tả phần mềm cũ làm gì.
- Gộp nhiều yêu cầu trong một câu, nghiệm thu được một nửa thì tính sao?
- Không có số liệu khối lượng: bao nhiêu đơn mỗi ngày, bao nhiêu mã hàng, bao nhiêu năm dữ liệu.
- Không có người ký xác nhận phía nghiệp vụ, nên về sau ai cũng chối được rằng đó không phải ý mình.
Quy tắc thực hành: mỗi yêu cầu nên có mã số, nguồn (ai đưa ra), mức ưu tiên, và ít nhất một tiêu chí chấp nhận. Bảng truy vết từ yêu cầu đến kịch bản kiểm thử về sau chính là xương sống của buổi nghiệm thu.
Câu hỏi thường gặp
Bên đặt hàng không có chuyên viên phân tích nghiệp vụ thì làm sao?
Có ba cách. Thuê nhà cung cấp làm giai đoạn khảo sát và đặc tả thành một hợp đồng riêng, có sản phẩm bàn giao là tài liệu yêu cầu, rồi mới đấu giá phần phát triển. Thuê tư vấn độc lập theo giờ để rà soát. Hoặc cử một người nghiệp vụ giỏi, cho học kỹ năng phân tích căn bản. Cách đầu giúp tách rủi ro, nhưng phải giữ quyền dùng tài liệu đó với nhà cung cấp khác.
Dự án agile có cần SRS không?
Không cần SRS theo kiểu một tài liệu dày ký một lần, nhưng vẫn cần những thứ SRS chứa: phạm vi tổng thể, yêu cầu phi chức năng, ràng buộc tích hợp, quy tắc nghiệp vụ. Agile Manifesto đề cao phần mềm chạy được hơn tài liệu đầy đủ, chứ không bảo bỏ tài liệu. Yêu cầu phi chức năng đặc biệt nên viết từ đầu vì nó ảnh hưởng kiến trúc.
Nên dùng nguyên mẫu giao diện thay cho viết yêu cầu không?
Nguyên mẫu, từ phác thảo giấy đến bản bấm thử được, giúp người dùng phản hồi tốt hơn đọc chữ rất nhiều, nên rất đáng làm. Nhưng nó không thay được quy tắc nghiệp vụ, ngoại lệ, phân quyền và yêu cầu phi chức năng. Cách hiệu quả là nguyên mẫu cho luồng chính, kèm tài liệu ngắn cho quy tắc mà màn hình không thể hiện được.
Ai ký xác nhận tài liệu yêu cầu phía doanh nghiệp?
Người có quyền quyết định nghiệp vụ và chịu trách nhiệm kết quả, thường là trưởng bộ phận sở hữu quy trình, cùng chủ dự án. Không nên để chỉ bộ phận CNTT ký, vì khi người dùng phản đối lúc vận hành, CNTT không có thẩm quyền nói thay nghiệp vụ. Với yêu cầu liên phòng ban, cần một người cấp cao hơn phân xử mâu thuẫn.
Yêu cầu nên chi tiết đến mức nào trước khi ký hợp đồng trọn gói?
Đủ để nhà cung cấp ước lượng với sai số chấp nhận được và để nghiệm thu không phải đoán. Thường nghĩa là liệt kê đủ chức năng với quy tắc chính, khối lượng dữ liệu, tích hợp, phi chức năng. Chi tiết màn hình có thể để giai đoạn thiết kế. Nếu chưa làm được mức đó, hợp đồng trọn gói là đặt cược, nên cân nhắc tách giai đoạn.
Có công cụ nào giúp quản lý yêu cầu thay cho Word và Excel?
Có nhiều công cụ quản lý backlog và yêu cầu, cả dạng thuê bao lẫn mã nguồn mở, hỗ trợ đánh số, liên kết yêu cầu với kiểm thử, lưu lịch sử thay đổi. Với dự án nhỏ, một bảng tính có cột mã, mô tả, ưu tiên, trạng thái, tiêu chí chấp nhận vẫn đủ dùng. Điều quan trọng là một nguồn duy nhất, không để mỗi người giữ một bản.