Bối cảnh và kết quả mong muốn
Bối cảnh: [Quy trình hoặc tình huống hiện tại]. Vấn đề: [Trở ngại cụ thể và nhóm đang chịu ảnh hưởng]. Kết quả mong muốn: [Thay đổi có thể quan sát sau khi triển khai]. Lý do thực hiện lúc này: [Sự kiện, nhu cầu vận hành hoặc ưu tiên kinh doanh]. Người quyết định: [Vai trò hoặc bộ phận có quyền chốt ưu tiên]. Gợi ý: mô tả vấn đề trước khi nêu giải pháp để đội dự án còn không gian kiểm tra các phương án phù hợp.
Người phụ trách kinh doanh và đội phát triển cần phối hợp thường xuyên; phần mềm hoạt động được cũng là một thước đo tiến độ quan trọng theo các nguyên tắc Agile. Vì vậy, brief nên là điểm khởi đầu cho trao đổi và phản hồi liên tục, không phải tài liệu dùng để đóng băng mọi yêu cầu ngay từ đầu. [1]
Người dùng và luồng chính
Người dùng chính: [Một vài nhóm người dùng quan trọng]. Nhu cầu của từng nhóm: [Công việc họ cần hoàn thành]. Luồng chính: [Điểm bắt đầu] → [Các hành động quan trọng] → [Kết quả cuối]. Ngoại lệ cần lưu ý: [Trường hợp cần phê duyệt, xử lý thủ công hoặc chuyển sang bộ phận khác]. Gợi ý: chỉ đưa vào brief những luồng có ảnh hưởng trực tiếp đến phạm vi phiên bản đầu.
Ví dụ: “Nhân viên kinh doanh nhận yêu cầu báo giá, chọn sản phẩm, gửi duyệt chiết khấu và xuất bản PDF cho khách; trưởng nhóm xem các báo giá vượt ngưỡng nội bộ.” Mô tả này cho thấy người dùng, trình tự và điểm kiểm soát, nhưng chưa mặc nhiên bao gồm mọi trường hợp ngoại lệ.
Phạm vi phiên bản đầu
Bắt buộc: [Các chức năng cần có để hoàn thành luồng chính]. Có thể làm sau: [Các cải tiến không cản trở kết quả ban đầu]. Ngoài phạm vi: [Những nội dung chưa thực hiện]. Ràng buộc đã biết: [Thiết bị, môi trường vận hành, hệ thống phải kết nối hoặc quy định nội bộ]. Gợi ý: gắn mỗi chức năng bắt buộc với một người dùng hoặc kết quả, tránh danh sách tính năng không rõ mục đích.
Agile khuyến khích bàn giao phần mềm hoạt động thường xuyên và chấp nhận điều chỉnh yêu cầu khi hiểu biết thay đổi. Brief vì thế nên xác định một lát cắt nghiệp vụ có thể sử dụng và kiểm tra được, đồng thời ghi rõ cơ chế xem xét các yêu cầu mới thay vì gom toàn bộ mong muốn vào một lần bàn giao. [1]
Dữ liệu, tích hợp và bảo mật
Dữ liệu đầu vào: [Nguồn và người chịu trách nhiệm]. Dữ liệu đầu ra: [Báo cáo, tệp hoặc màn hình cần có]. Phân quyền: [Ai được xem, tạo, sửa, duyệt hoặc xóa]. Tích hợp: [Tên hệ thống, mục đích, chiều trao đổi và đầu mối xác nhận]. Bảo mật cần xem xét: [Dữ liệu nhạy cảm, xác thực, nhật ký và cách tiếp nhận thông tin lỗ hổng]. Không nên tự giả định hệ thống đã có API nếu chưa được kiểm tra.
NIST SSDF xem thực hành phát triển phần mềm an toàn là nội dung cần tích hợp vào vòng đời phát triển và điều chỉnh theo rủi ro, nhu cầu kinh doanh, nguồn lực, chi phí, tính khả thi và khả năng áp dụng. Gợi ý: dùng brief để ghi nhận các ưu tiên bảo mật cần đánh giá; danh sách này không phải cam kết rằng hệ thống sẽ an toàn tuyệt đối. [2]
Nghiệm thu và điểm còn mở
Tiêu chí nghiệm thu: [Người dùng nào thực hiện hành vi gì, trong điều kiện nào và kết quả mong đợi là gì]. Giả định: [Điều đang được coi là đúng nhưng chưa xác minh]. Câu hỏi mở: [Thông tin có thể làm thay đổi phạm vi hoặc kiến trúc]. Mốc rà soát: [Thời điểm hoặc sự kiện tiếp theo]. Người xác nhận: [Vai trò chịu trách nhiệm trả lời và phê duyệt].
Gợi ý: ưu tiên làm rõ nguồn dữ liệu chuẩn, quy tắc phê duyệt, quyền truy cập, phụ thuộc tích hợp và cách xử lý khi quy trình không đi theo luồng chính. Sau mỗi vòng trao đổi, cập nhật brief để phản ánh quyết định mới và chuyển các chi tiết đã đủ rõ sang tài liệu yêu cầu hoặc danh sách công việc phù hợp.