Tài liệu đặc tả yêu cầu phần mềm: 8 phần bắt buộc
Khung tám phần của tài liệu đặc tả yêu cầu phần mềm, cách đánh mã yêu cầu, mẫu ngưỡng đo cho yêu cầu phi chức năng và bảng truy vết yêu cầu đến kịch bản kiểm thử.
Mục lục bài viết
Trả lời nhanh
Tám phần bắt buộc của tài liệu đặc tả yêu cầu phần mềm, mẫu câu cho từng phần, một yêu cầu viết lại từ đầu đến cuối và danh sách kiểm tra trước khi chốt.
Tài liệu đặc tả yêu cầu phần mềm gồm tám phần: bối cảnh và mục tiêu, phạm vi, vai trò, luồng nghiệp vụ, yêu cầu chức năng có mã, yêu cầu phi chức năng có ngưỡng đo, quy tắc dữ liệu, tiêu chí nghiệm thu kèm bảng truy vết. Thiếu phần nào, nghiệm thu sẽ tranh luận.
Tóm tắt nhanh
- Tài liệu đặc tả là căn cứ nghiệm thu, không phải tài liệu mô tả cho vui. Mỗi câu trong đó phải trả lời được "đạt hay không đạt".
- Tám phần dưới đây được sắp theo thứ tự đọc, không theo thứ tự viết. Phần 5 và phần 6 thường viết trước, các phần còn lại viết sau để bao quanh.
- Đánh mã yêu cầu là kỹ thuật rẻ nhất và có tác dụng lớn nhất: mã cho phép nối yêu cầu với kịch bản kiểm thử, với hạng mục công việc và với biên bản nghiệm thu.
- Một tài liệu đặc tả không có ngưỡng đo cho yêu cầu phi chức năng là tài liệu sẽ thất bại ở khâu nghiệm thu.
Tài liệu đặc tả khác gì hợp đồng và backlog
Ba loại văn bản này hay bị dùng lẫn, và việc lẫn lộn gây ra hai vấn đề: hợp đồng bị biến thành tài liệu kỹ thuật, hoặc đặc tả bị biến thành danh sách việc.
- Hợp đồng xác lập nghĩa vụ pháp lý: ai làm gì, giá bao nhiêu, khi nào thanh toán, ai sở hữu kết quả. Hợp đồng dẫn chiếu đặc tả như một phụ lục.
- Tài liệu đặc tả mô tả sản phẩm sẽ được xây: gồm những gì, hoạt động thế nào, đo bằng gì. Đặc tả là căn cứ kỹ thuật và căn cứ nghiệm thu.
- Backlog là danh sách việc đã chia nhỏ để thực hiện theo vòng. Backlog thay đổi liên tục; đặc tả thay đổi có kiểm soát phiên bản.
Một tài liệu đặc tả tốt có thể đứng riêng: người không biết gì về dự án đọc vào vẫn hiểu sản phẩm làm gì, cho ai, và đạt nghĩa là thế nào. Nếu tài liệu chỉ đọc được khi có người thuyết minh kèm, nó chưa phải đặc tả.
Khung tám phần trong một trang
| Phần | Trả lời câu hỏi | Độ dài điển hình | Dấu hiệu phần này đang yếu |
|---|---|---|---|
| 1. Bối cảnh và mục tiêu | Vì sao làm, đo thành công bằng gì | Nửa trang đến một trang | Mục tiêu là "nâng cao hiệu quả" mà không có chỉ số |
| 2. Phạm vi | Làm gì, không làm gì | Một đến hai trang | Không có mục "không bao gồm" |
| 3. Vai trò người dùng | Ai dùng, được làm gì | Một trang, kèm ma trận quyền | Vai trò mô tả bằng chức danh, không bằng quyền |
| 4. Luồng nghiệp vụ | Quy trình chạy theo bước nào | Hai đến bốn trang | Chỉ có luồng chuẩn, không có luồng ngoại lệ |
| 5. Yêu cầu chức năng | Từng yêu cầu, có mã và ưu tiên | Phần dài nhất | Yêu cầu dùng tính từ thay vì hành vi |
| 6. Yêu cầu phi chức năng | Nhanh, an toàn, chịu tải ở mức nào | Một đến hai trang | Không có ngưỡng đo |
| 7. Quy tắc dữ liệu | Dữ liệu nào, ràng buộc gì, giữ bao lâu | Một đến hai trang | Không nói về dữ liệu cũ và dữ liệu lỗi |
| 8. Tiêu chí nghiệm thu và truy vết | Đạt nghĩa là gì, kiểm bằng gì | Một trang, kèm bảng | Không có bảng nối yêu cầu với kịch bản kiểm thử |
Phần 1: Bối cảnh và mục tiêu
Phần này trả lời hai câu: vì sao tổ chức làm dự án này, và dấu hiệu nào cho thấy dự án thành công sau khi đưa vào sử dụng.
Cách viết hiệu quả là mô tả hiện trạng bằng dữ kiện, rồi mô tả trạng thái mong muốn cũng bằng dữ kiện. Ví dụ: hiện tại mỗi kỳ chốt số, bộ phận kế toán phải đối chiếu thủ công ba nguồn dữ liệu; mục tiêu là số liệu chốt kỳ được tạo từ một nguồn duy nhất, có đối chiếu tự động và có log.
Điều cần tránh là mục tiêu dạng khẩu hiệu. "Nâng cao hiệu quả quản lý" không kiểm chứng được, không giúp chọn giữa hai phương án kỹ thuật, và không giúp kết luận dự án thành công hay không.
Mẫu câu nên dùng:
"Mục tiêu của dự án là giảm số bước thủ công trong quy trình chốt số kỳ từ quy trình hiện tại xuống còn một bước xác nhận. Chỉ số đo: số lần phải sửa tay sau khi chốt số, đo trong ba kỳ liên tiếp sau khi đưa vào sử dụng."
Phần 2: Phạm vi và ngoài phạm vi
Phạm vi là phần quyết định chi phí, và mục "không bao gồm" quan trọng ngang phần mô tả phạm vi. Lý do: hầu hết yêu cầu phát sinh miễn phí đều nằm trong vùng mờ mà mục này bỏ trống.
Cách viết: liệt kê theo ba lớp — nội dung bàn giao, đối tượng sử dụng, và giới hạn kỹ thuật.
Mẫu câu nên dùng:
"Phạm vi bao gồm: ứng dụng web cho bốn vai trò; ba luồng nghiệp vụ chính tại Phần 4; báo cáo tại Phần 5; tích hợp đọc danh mục sản phẩm từ hệ thống hiện hữu. Phạm vi không bao gồm: ứng dụng di động; tích hợp thiết bị quét mã phần cứng; chuyển đổi dữ liệu lịch sử trước năm hiện tại; đào tạo trực tiếp tại chi nhánh; vận hành hệ thống sau bàn giao."
Mỗi dòng trong mục "không bao gồm" nên có ghi chú về việc sẽ xử lý thế nào: làm ở giai đoạn sau, làm theo hợp đồng riêng, hoặc không làm. Ghi chú này ngăn tình huống một hạng mục bị hiểu là "sẽ làm sau" trong khi hợp đồng không có cam kết đó.
Phần 3: Đối tượng sử dụng và vai trò
Phần này mô tả người dùng theo quyền, không theo chức danh. Chức danh thay đổi giữa các tổ chức; quyền thì kiểm chứng được.
Một ma trận quyền tối thiểu gồm các cột: chức năng, xem, tạo, sửa, xoá, phê duyệt, xuất dữ liệu. Mỗi dòng là một chức năng chính; mỗi cột là một vai trò.
| Chức năng | Nhân viên | Quản lý | Kế toán | Quản trị hệ thống |
|---|---|---|---|---|
| Xem đơn hàng | Chỉ đơn của mình | Đơn của đơn vị | Tất cả | Tất cả |
| Tạo đơn hàng | Có | Có | Không | Không |
| Sửa đơn hàng | Chỉ khi chưa duyệt | Có | Không | Không |
| Xoá đơn hàng | Không | Không | Không | Có, có ghi log |
| Duyệt đơn hàng | Không | Có | Không | Không |
| Xuất báo cáo doanh thu | Không | Đơn vị mình | Tất cả | Tất cả |
Hai câu hỏi kiểm tra phần này: nếu một người đổi vai trò, quyền của họ thay đổi ở những chỗ nào; và hành động nào phải ghi log kèm người thực hiện. Câu thứ hai hay bị bỏ, và nó là câu quan trọng nhất khi có tranh chấp về dữ liệu.
Phần 4: Luồng nghiệp vụ chính
Luồng nghiệp vụ mô tả quy trình chạy theo từng bước, kèm người thực hiện và trạng thái dữ liệu sau mỗi bước. Phần này là cầu nối giữa mục tiêu và danh sách yêu cầu.
Cách viết hiệu quả: đánh số bước, và với mỗi bước ghi ba thông tin — ai làm, dữ liệu đổi trạng thái thế nào, và điều kiện nào phải đúng để bước đó xảy ra.
Mẫu câu nên dùng:
"Bước 3 — Quản lý duyệt đơn. Người thực hiện: vai trò Quản lý của đơn vị sở hữu đơn. Điều kiện: đơn ở trạng thái Chờ duyệt và tổng giá trị không vượt hạn mức của vai trò. Kết quả: trạng thái chuyển sang Đã duyệt hoặc Từ chối; hệ thống ghi log người duyệt, thời điểm và lý do từ chối nếu có."
Phần quan trọng nhất của luồng nghiệp vụ là các nhánh ngoại lệ. Luồng chuẩn thường dễ thống nhất; tranh chấp nằm ở câu hỏi: nếu người duyệt vắng thì sao, nếu đơn bị sửa sau khi duyệt thì sao, nếu dữ liệu từ hệ thống cũ đến muộn thì sao. Mỗi nhánh ngoại lệ nên có một dòng mô tả hành vi mong muốn.
Phần 5: Yêu cầu chức năng có mã
Đây là phần dài nhất và cũng là phần dễ viết ẩu nhất. Ba quy ước giúp phần này dùng được.
Quy ước 1 — mã yêu cầu theo nhóm chức năng. Ví dụ FR-ORD-01 cho nhóm đơn hàng, FR-RPT-03 cho nhóm báo cáo. Mã không thay đổi sau khi ban hành; nếu một yêu cầu bị thay thế, đánh dấu là thay thế bởi mã mới, không tái sử dụng mã cũ.
Quy ước 2 — ba mức ưu tiên. Bắt buộc, nên có, có thể có. Mức "bắt buộc" là mức dùng để nghiệm thu: nếu thiếu một yêu cầu bắt buộc, sản phẩm chưa đạt. Hai mức còn lại không chặn nghiệm thu nhưng cần được ghi nhận.
Quy ước 3 — mỗi yêu cầu có tiêu chí kiểm chứng. Tiêu chí có thể là một câu, nhưng phải quan sát được.
| Mã | Yêu cầu | Ưu tiên | Tiêu chí kiểm chứng |
|---|---|---|---|
| FR-ORD-01 | Tạo đơn hàng thủ công với thông tin khách, danh sách mặt hàng và ghi chú | Bắt buộc | Đơn lưu đúng dữ liệu nhập; xuất hiện trong danh sách của người tạo trong vòng 2 giây sau khi lưu |
| FR-ORD-04 | Duyệt hoặc từ chối đơn, có lý do khi từ chối | Bắt buộc | Trạng thái đổi đúng; lý do từ chối bắt buộc nhập; log ghi người duyệt và thời điểm |
| FR-ORD-07 | Chặn sửa đơn đã duyệt, trừ vai trò Quản trị | Bắt buộc | Với vai trò Nhân viên, nút sửa không hiển thị và API trả lỗi khi gọi trực tiếp |
| FR-RPT-02 | Báo cáo doanh thu theo ngày và theo đơn vị | Bắt buộc | Số liệu khớp dữ liệu gốc với bộ dữ liệu kiểm thử; tải dưới 2 giây với 50.000 đơn |
| FR-RPT-05 | Xuất danh sách đơn ra tệp Excel | Nên có | Tệp mở được, số dòng khớp bộ lọc, các cột đúng thứ tự |
Dòng FR-ORD-07 minh hoạ một điểm quan trọng: tiêu chí kiểm chứng phải kiểm tra cả giao diện lẫn API. Kiểm tra giao diện không đủ, vì quyền có thể bị vượt qua bằng cách gọi trực tiếp.
Phần 6: Yêu cầu phi chức năng có ngưỡng đo
Yêu cầu phi chức năng là phần hay bị bỏ trống nhất, và cũng là phần gây tranh chấp nhiều nhất khi nghiệm thu. Lý do: tính từ dễ viết, nhưng không ai kiểm chứng được.
| Loại | Cách viết không kiểm chứng được | Cách viết có ngưỡng đo |
|---|---|---|
| Hiệu năng | "Hệ thống phải nhanh" | "Trang danh sách tải dưới 2 giây với 50.000 bản ghi; API tìm kiếm trả kết quả dưới 1 giây ở mức tải 50 người dùng đồng thời" |
| Khả dụng | "Hệ thống phải ổn định" | "Thời gian hoạt động mục tiêu 99,5% mỗi tháng, đo từ công cụ giám sát bên ngoài; sự cố mức nghiêm trọng được thông báo trong 15 phút" |
| Bảo mật | "Hệ thống phải bảo mật" | "Mật khẩu lưu dưới dạng băm có muối; khoá tài khoản sau 5 lần đăng nhập sai liên tiếp; mọi hành động xoá dữ liệu ghi log kèm người thực hiện và thời điểm" |
| Tương thích | "Chạy trên mọi trình duyệt" | "Hoạt động đúng trên Chrome, Edge và Safari ở hai phiên bản gần nhất; kiểm thử trên màn hình 1366×768 và 1920×1080" |
| Sao lưu | "Có sao lưu dữ liệu" | "Sao lưu hằng ngày, giữ 30 ngày; diễn tập phục hồi một lần trước bàn giao, có biên bản ghi thời gian phục hồi thực tế" |
| Nhật ký | "Có ghi log" | "Log lưu tối thiểu 90 ngày; mỗi bản ghi gồm người thực hiện, thời điểm, hành động, đối tượng, giá trị trước và sau" |
| Khả năng truy cập | "Thân thiện với người khuyết tật" | "Điều hướng bằng bàn phím cho toàn bộ luồng chính; độ tương phản văn bản đạt mức AA; mọi trường nhập có nhãn đọc được bằng trình đọc màn hình" |
Nguyên tắc viết: mỗi yêu cầu phi chức năng phải trả lời ba câu — đo cái gì, ngưỡng bao nhiêu, đo bằng cách nào và trong điều kiện nào. Thiếu câu thứ ba, ngưỡng vẫn có thể tranh cãi.
Phần 7: Quy tắc dữ liệu và vòng đời
Phần này mô tả dữ liệu hệ thống quản lý: thực thể chính, trường bắt buộc, quy tắc kiểm tra, thời gian lưu, và cách xử lý dữ liệu cũ.
| Thực thể | Trường bắt buộc | Quy tắc kiểm tra | Thời gian lưu | Xử lý dữ liệu cũ |
|---|---|---|---|---|
| Đơn hàng | Mã đơn, ngày, khách, đơn vị, tổng tiền | Mã đơn duy nhất; tổng tiền bằng tổng dòng chi tiết; ngày không lớn hơn ngày hiện tại | Theo quy định lưu trữ của tổ chức | Chỉ chuyển đơn trong phạm vi thời gian tại Phần 2 |
| Khách hàng | Mã khách, tên, số điện thoại | Số điện thoại đúng định dạng; không trùng trong cùng đơn vị | Theo quy định lưu trữ | Bỏ qua bản ghi thiếu số điện thoại, ghi vào báo cáo lỗi |
| Mặt hàng | Mã, tên, đơn vị tính, giá | Giá không âm; đơn vị tính thuộc danh mục | Theo quy định lưu trữ | Chuyển toàn bộ danh mục đang hoạt động |
| Nhật ký thao tác | Người thực hiện, thời điểm, hành động, đối tượng | Không cho sửa hoặc xoá | Tối thiểu 90 ngày | Không chuyển dữ liệu cũ |
Ba điểm cần nêu rõ trong phần này mà nhiều tài liệu bỏ qua:
- Dữ liệu lỗi. Khi chuyển dữ liệu cũ, một phần bản ghi sẽ không hợp lệ. Cần quy định: bỏ qua hay chuyển với cờ đánh dấu, và báo cáo lỗi được gửi cho ai.
- Dữ liệu cá nhân. Nếu hệ thống xử lý dữ liệu cá nhân, cần nêu loại dữ liệu, mục đích, thời hạn lưu và bên thứ ba tham gia xử lý. Từ ngày 01/01/2026, khung pháp lý cho nội dung này là Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15.
- Dữ liệu xuất ra. Báo cáo xuất ra tệp là một đường rò dữ liệu. Cần quy định ai được xuất, xuất những trường nào, và có ghi log hay không.
Phần 8: Tiêu chí nghiệm thu và bảng truy vết
Tiêu chí nghiệm thu là phần biến tài liệu đặc tả thành công cụ. Cách viết hiệu quả nhất là một bảng truy vết nối ba cột: yêu cầu, kịch bản kiểm thử, và mốc bàn giao.
| Mã yêu cầu | Mã kịch bản kiểm thử | Mốc bàn giao | Điều kiện nghiệm thu |
|---|---|---|---|
| FR-ORD-01 | TC-ORD-01a, TC-ORD-01b | Đợt 1 | Cả hai kịch bản đạt trên môi trường kiểm thử |
| FR-ORD-04 | TC-ORD-04a, TC-ORD-04b, TC-ORD-04c | Đợt 1 | Ba kịch bản đạt, gồm trường hợp từ chối không nhập lý do phải bị chặn |
| FR-ORD-07 | TC-ORD-07a, TC-ORD-07b | Đợt 1 | Kiểm tra cả giao diện và gọi API trực tiếp |
| FR-RPT-02 | TC-RPT-02a | Đợt 2 | Số liệu khớp dữ liệu gốc, đạt ngưỡng thời gian tải |
| NFR-PERF-01 | TC-PERF-01 | Đợt 2 | Đo trên môi trường kiểm thử với bộ dữ liệu quy định |
Bảng này có ba tác dụng. Với đội thực hiện, nó là danh sách việc kiểm thử. Với khách hàng, nó là căn cứ ký biên bản. Với người kiểm tra sau này, nó là bằng chứng rằng phạm vi đã được kiểm tra đủ.
Điều kiện nghiệm thu nên ghi ở dạng "cả hai kịch bản đạt", không ghi "đã kiểm thử". Cách ghi thứ hai không xác định được kết quả.
Một yêu cầu viết lại từ đầu đến cuối
Để thấy tám phần liên kết với nhau thế nào, xét một yêu cầu thường gặp: báo cáo tồn kho.
Câu gốc trong yêu cầu: "Cần báo cáo tồn kho để quản lý nắm được hàng còn bao nhiêu."
Vấn đề của câu này: không xác định được đơn vị tồn kho, thời điểm chốt, phạm vi kho, cách xử lý hàng đang về, và người xem được dữ liệu của kho nào.
Viết lại thành yêu cầu chức năng:
FR-INV-03— Báo cáo tồn kho theo kho và theo mặt hàng. Ưu tiên: bắt buộc.Mô tả: người dùng chọn một kho và một thời điểm chốt; hệ thống hiển thị danh sách mặt hàng kèm số lượng tồn, số lượng đang giữ cho đơn chưa giao, và số lượng khả dụng. Có thể lọc theo nhóm hàng và tìm theo mã hoặc tên.
Quy tắc dữ liệu: số lượng khả dụng bằng số lượng tồn trừ số lượng đang giữ; hàng đang về không tính vào tồn; mặt hàng có số lượng bằng không vẫn hiển thị nếu có phát sinh trong kỳ.
Phân quyền: nhân viên chỉ xem kho được gán; quản lý xem mọi kho thuộc đơn vị; kế toán xem tất cả nhưng không xem giá vốn.
Yêu cầu phi chức năng: tải dưới 2 giây với 20.000 dòng; số liệu khớp với sổ kho tại cùng thời điểm chốt.
Tiêu chí kiểm chứng: với bộ dữ liệu kiểm thử có 3 kho và 500 mặt hàng, số liệu hiển thị khớp bảng tính đối chiếu do khách hàng cung cấp; thử với vai trò nhân viên của kho A, không thấy dữ liệu kho B.
Kịch bản kiểm thử:
TC-INV-03a(số liệu khớp),TC-INV-03b(phân quyền theo kho),TC-INV-03c(thời gian tải),TC-INV-03d(mặt hàng tồn bằng không trong kỳ).
Một yêu cầu như trên có thể đưa thẳng vào bảng truy vết, và từ đó vào biên bản nghiệm thu. Đó là tiêu chuẩn để đánh giá mọi yêu cầu khác trong tài liệu: nếu không viết được thành một khối tương tự, yêu cầu chưa sẵn sàng.
Cách đánh mã và cách nối yêu cầu với các mốc bàn giao được trình bày trong quy trình phát triển phần mềm gồm những bước nào.
Quy trình rà soát trước khi chốt
Một tài liệu đặc tả không nên được chốt bởi một người. Tối thiểu cần bốn góc nhìn: người sử dụng, người vận hành, người kiểm thử và người chịu trách nhiệm ngân sách.
| Người rà soát | Câu hỏi chính | Phần cần đọc kỹ |
|---|---|---|
| Người sử dụng đại diện | Quy trình mô tả có đúng việc đang làm không | Phần 4 và 5 |
| Người vận hành | Sau bàn giao, ai làm gì, xử lý sự cố thế nào | Phần 6 và 7 |
| Người kiểm thử | Mỗi yêu cầu có kiểm chứng được không | Phần 5, 6 và 8 |
| Người chịu trách nhiệm ngân sách | Phạm vi có khớp với nguồn lực không | Phần 2 |
Mười câu hỏi dùng làm danh sách kiểm tra trước khi chốt:
- Mục tiêu ở Phần 1 có chỉ số đo không?
- Phần 2 có mục "không bao gồm" không?
- Mỗi vai trò ở Phần 3 được mô tả bằng quyền, không bằng chức danh?
- Phần 4 có ít nhất ba nhánh ngoại lệ không?
- Mỗi yêu cầu ở Phần 5 có mã, ưu tiên và tiêu chí kiểm chứng?
- Có yêu cầu nào dùng tính từ mà không có ngưỡng không?
- Phần 6 có nêu cách đo và điều kiện đo cho từng ngưỡng không?
- Phần 7 có quy định xử lý dữ liệu lỗi và dữ liệu cá nhân không?
- Bảng truy vết ở Phần 8 phủ toàn bộ yêu cầu mức bắt buộc chưa?
- Tài liệu có số phiên bản, ngày ban hành và lịch sử thay đổi không?
Nếu câu 5, 7 hoặc 9 trả lời "chưa", đừng chốt. Ba câu này quyết định khả năng nghiệm thu của toàn bộ tài liệu.
Năm lỗi làm tài liệu đặc tả vô dụng
- Viết để đủ hồ sơ, không để dùng. Dấu hiệu: tài liệu dày, nhưng khi họp nghiệm thu không ai mở ra.
- Trộn giải pháp kỹ thuật vào yêu cầu. Yêu cầu nên nói cần gì, không nói dùng công nghệ nào. Trộn hai thứ khiến việc thay đổi công nghệ trở thành thay đổi phạm vi.
- Không có phiên bản. Tài liệu không có phiên bản khiến mọi thảo luận về "bản nào" trở thành bất khả thi.
- Không có bảng truy vết. Thiếu bảng này, không ai chứng minh được phạm vi đã được kiểm tra đủ.
- Chốt tài liệu khi chưa có người dùng thật đọc. Người dùng đọc sẽ phát hiện những câu mô tả quy trình không tồn tại, và đó là loại lỗi tốn kém nhất nếu để đến khâu kiểm thử.
Bức tranh tổng thể của các giai đoạn, kèm điểm kiểm tra từng bước, được trình bày trong quy trình phát triển phần mềm là gì. Với các dự án có yếu tố thuế và hợp đồng, cách tách cấu phần phần mềm và dịch vụ khác được trình bày trong thuế GTGT của phần mềm là bao nhiêu.
Câu hỏi thường gặp
Tài liệu đặc tả yêu cầu phần mềm có bắt buộc phải dài không?
Không. Độ dài phụ thuộc số lượng yêu cầu và mức độ phức tạp của nghiệp vụ. Với dự án nhỏ, tám phần có thể gói trong vài trang. Điều bắt buộc là mỗi yêu cầu có mã, có ưu tiên và có tiêu chí kiểm chứng; thiếu ba yếu tố này thì tài liệu dài bao nhiêu cũng không dùng được ở khâu nghiệm thu.
Ai nên viết tài liệu đặc tả?
Người hiểu cả nghiệp vụ và khả năng của hệ thống, thường là người phân tích nghiệp vụ phối hợp với người sử dụng đại diện. Điều quan trọng không phải chức danh mà là tài liệu phải được người dùng thật đọc và xác nhận trước khi chốt. Tài liệu do một bên viết và bên kia chỉ ký mà không đọc là nguồn gốc của phần lớn tranh chấp về phạm vi.
Có nên dùng câu chuyện người dùng thay cho tài liệu đặc tả không?
Có thể dùng câu chuyện người dùng làm đơn vị mô tả yêu cầu, miễn là mỗi câu chuyện có tiêu chí chấp nhận kiểm chứng được. Với dự án nhỏ và có phản hồi thường xuyên, danh sách câu chuyện kèm tiêu chí có thể thay tài liệu dài. Với dự án có hợp đồng phạm vi cố định hoặc cần thẩm định, tài liệu đặc tả riêng vẫn cần vì đó là căn cứ đối chiếu phạm vi.
Khi yêu cầu thay đổi thì sửa tài liệu hay làm phụ lục?
Cả hai cách đều dùng được, miễn là có kiểm soát phiên bản. Cách phổ biến là giữ tài liệu gốc và lập phụ lục thay đổi, mỗi phụ lục ghi mã yêu cầu bị ảnh hưởng. Cách này giúp nhìn được lịch sử thay đổi và giúp người mới đọc hiểu vì sao một yêu cầu hiện có hình dạng như vậy.
Cập nhật và kiểm chứng
Cập nhật tháng 10/2026. Nội dung phản ánh quy trình bốn chặng WinSell áp dụng — Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường. Các nội dung về nghiệm thu, sở hữu sản phẩm và xử lý dữ liệu cá nhân được đối chiếu theo Bộ luật Dân sự 91/2015/QH13, Luật Sở hữu trí tuệ hiện hành và Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15.
Bài viết mang tính tham khảo, không phải tư vấn pháp lý hay tư vấn thuế. Vui lòng đối chiếu văn bản gốc và tham khảo ý kiến chuyên gia.
WinSell xây dựng phần mềm theo yêu cầu với tài liệu đặc tả có mã yêu cầu và bảng truy vết, chốt trước khi triển khai — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.
Cần một hệ thống chạy được, không chỉ một bài viết?
WinSell xây phần mềm theo yêu cầu và làm SEO/GEO cho chính sản phẩm đó. Phạm vi và báo giá được chốt sau bước khám phá.
