Mục tiêu và người dùng
1. Vấn đề kinh doanh nào cần giải quyết? Hãy mô tả ai đang gặp khó khăn, công đoạn nào gây chậm trễ và kết quả nào cần thay đổi. Gợi ý: bắt đầu từ quy trình thực tế thay vì tên công nghệ hoặc danh sách màn hình, vì cùng một vấn đề có thể có nhiều cách xử lý.
2. Ai là người sử dụng chính? Liệt kê từng nhóm người dùng, nhiệm vụ, thiết bị và quyền truy cập dự kiến. Ví dụ: nhân viên nhập đơn trên máy tính, quản lý duyệt trên điện thoại, còn khách hàng chỉ được xem trạng thái đơn của mình.
Quy trình và kết quả
3. Quy trình hiện tại diễn ra thế nào? Vẽ luồng từ đầu vào đến kết quả, gồm cả bước dùng bảng tính, email, giấy tờ và phê duyệt thủ công. Gợi ý: đánh dấu nơi dữ liệu được nhập lại, nơi thường xảy ra lỗi và trường hợp phải xử lý ngoại lệ.
4. Kết quả nào dùng để đánh giá dự án? Chọn một số kết quả có thể quan sát như thời gian xử lý, tỷ lệ nhập liệu lại hoặc khả năng tra cứu. Phần mềm hoạt động được là thước đo tiến độ quan trọng; việc bàn giao thường xuyên cũng giúp doanh nghiệp kiểm tra giá trị sớm hơn. [2]
Dữ liệu và tích hợp
5. Dữ liệu đến từ đâu và ai được phép sử dụng? Cần ghi rõ định dạng, chất lượng, khối lượng tương đối, người quản lý và dữ liệu nhạy cảm. Gợi ý: kiểm tra khả năng xuất dữ liệu khỏi hệ thống cũ trước khi coi việc chuyển đổi là một phần đơn giản của dự án.
6. Phần mềm phải kết nối với hệ thống nào? Liệt kê nền tảng, mục đích trao đổi dữ liệu, tài liệu API và quyền quản trị hiện có. Không nên mặc định mọi dịch vụ đều hỗ trợ tích hợp mong muốn; khả năng triển khai còn phụ thuộc giao diện kỹ thuật và chính sách của từng nhà cung cấp.
Phạm vi và nghiệm thu
7. Điều gì bắt buộc có trong phiên bản đầu? Chia yêu cầu thành bắt buộc, nên có và có thể làm sau. Gợi ý: ưu tiên một luồng nghiệp vụ hoàn chỉnh để người dùng thử sớm. Cách làm này phù hợp với nguyên tắc cung cấp phần mềm có giá trị thường xuyên và đón nhận thay đổi yêu cầu. [2]
8. Tiêu chí nghiệm thu là gì? Với mỗi chức năng quan trọng, mô tả đầu vào, kết quả mong muốn, quyền thực hiện và tình huống lỗi. Cũng cần thống nhất môi trường kiểm tra, dữ liệu mẫu, người xác nhận và cách ghi nhận vấn đề để tránh đánh giá chỉ dựa trên cảm nhận.
Quyết định và kế hoạch
9. Ai có quyền quyết định? Xác định người duyệt phạm vi, người trả lời nghiệp vụ, người nghiệm thu và thời gian phản hồi dự kiến. Việc người làm kinh doanh và đội phát triển phối hợp thường xuyên giúp các thay đổi được hiểu và xử lý gần thời điểm phát sinh. [2]
10. Mốc thời gian nào thực sự quan trọng? Nêu ngày cần sử dụng, lý do và phần phạm vi phải sẵn sàng tại từng mốc. Gợi ý: phân biệt hạn bắt buộc với mục tiêu mong muốn; khi thời gian cố định, doanh nghiệp cần chủ động chọn phần việc có thể lùi lại.
Vận hành, bảo mật và ngân sách
11. Ai sẽ vận hành phần mềm sau bàn giao? Làm rõ trách nhiệm quản trị, hỗ trợ người dùng, giám sát, sao lưu, cập nhật và phản hồi lỗ hổng. SSDF của NIST cung cấp ngôn ngữ chung để bên mua và bên phát triển trao đổi về thực hành phát triển an toàn, nhưng cần điều chỉnh theo rủi ro, nguồn lực và bối cảnh dự án. [1]
12. Ngân sách và cách phê duyệt thay đổi ra sao? Một khoảng ngân sách cùng quy trình quyết định giúp đội dự án đề xuất phạm vi và kiến trúc thực tế hơn. Gợi ý: thống nhất cách ước lượng, nội dung báo cáo, người duyệt và cách xử lý yêu cầu mới; đây là nội dung cần thương lượng, không phải điều khoản mặc định cho mọi dự án.