Tài liệu yêu cầu
1. Khái niệm Tài liệu Yêu cầu là gì?
Tài liệu Yêu cầu (Requirement Document) là tài liệu chính thức ghi lại đầy đủ các yêu cầu chức năng, phi chức năng, và các ràng buộc của hệ thống, phần mềm, hoặc quy trình mà dự án cần đáp ứng. Đây là cơ sở giao tiếp giữa các bên liên quan (Business, Technical, QA) để đảm bảo cùng hiểu về những gì cần phát triển.
2. Mục đích của Tài liệu Yêu cầu
Mục đích
Ý nghĩa
Xác định rõ phạm vi dự án
Định nghĩa chính xác các yêu cầu và giới hạn công việc.
Làm cơ sở thiết kế, phát triển và kiểm thử
Cung cấp thông tin cho lập trình viên, tester thực hiện công việc.
Thống nhất giữa các bên liên quan
Đảm bảo các bên hiểu đúng, tránh hiểu sai hoặc mâu thuẫn yêu cầu.
Quản lý sự thay đổi
Làm căn cứ để xét duyệt các thay đổi về sau.
3. Nội dung chính của Tài liệu Yêu cầu
I. Thông tin chung
Mục
Nội dung
Tên dự án
Tên chính thức của dự án.
Mô tả tổng quan
Tóm tắt mục tiêu, ý nghĩa của dự án.
Phạm vi dự án
Những gì sẽ làm và sẽ không làm (In-scope/Out-of-scope).
Các bên liên quan
Danh sách những người/nhóm ảnh hưởng hoặc tham gia.
Thuật ngữ và định nghĩa (Glossary)
Giải thích các từ chuyên ngành, viết tắt.
II. Yêu cầu chức năng (Functional Requirements)
Yêu cầu
Mô tả
Yêu cầu nghiệp vụ
Mô tả chi tiết các chức năng hệ thống phải có.
Luồng nghiệp vụ (Business Flow)
Các bước, quy trình xử lý chính.
Luồng dữ liệu (Data Flow)
Dữ liệu vào, ra, cách xử lý.
Mô tả màn hình (nếu có)
Giao diện, chức năng tương tác.
🔑 Ví dụ:
"Hệ thống cho phép người dùng đăng ký tài khoản với các thông tin: Họ tên, Email, Mật khẩu."
III. Yêu cầu phi chức năng (Non-functional Requirements)
Loại yêu cầu
Ví dụ nội dung
Hiệu suất (Performance)
"Hệ thống xử lý 1000 giao dịch/giờ."
Bảo mật (Security)
"Thông tin người dùng được mã hóa AES-256."
Khả dụng (Availability)
"Hệ thống hoạt động 24/7 với 99.9% uptime."
Khả năng mở rộng (Scalability)
"Hỗ trợ thêm 5000 người dùng mà không giảm tốc độ."
IV. Ràng buộc và giả định (Constraints & Assumptions)
Loại
Mô tả
Giả định (Assumptions)
"Người dùng có Internet khi sử dụng hệ thống."
Ràng buộc (Constraints)
"Phải dùng nền tảng .NET Core và Azure Cloud."
V. Phụ lục (Appendix)
Loại nội dung
Ví dụ
Sơ đồ luồng (Flowchart, BPMN)
Mô hình quy trình nghiệp vụ.
Mockups, Wireframes
Bản vẽ giao diện mẫu.
ERD, Sơ đồ dữ liệu
Mô hình hóa quan hệ dữ liệu.
4. Các loại tài liệu yêu cầu theo tiêu chuẩn BA
Loại tài liệu
Ý nghĩa / Trường hợp sử dụng
Business Requirements Document (BRD)
Yêu cầu ở mức độ kinh doanh, mục tiêu tổng thể.
System Requirements Specification (SRS)
Yêu cầu hệ thống chi tiết, dành cho đội kỹ thuật.
Functional Specification Document (FSD)
Tài liệu chi tiết về chức năng của hệ thống.
User Stories/Use Cases
Mô tả tình huống sử dụng từ góc nhìn người dùng.
Product Requirements Document (PRD)
Tài liệu yêu cầu sản phẩm (gần với FSD).
5. Nguyên tắc khi viết tài liệu yêu cầu
Nguyên tắc
Giải thích
Rõ ràng, dễ hiểu
Tránh dùng từ ngữ mơ hồ, diễn giải ngắn gọn, dễ đọc.
Đầy đủ và chi tiết
Đảm bảo bao phủ toàn bộ yêu cầu cần thiết.
Có thể kiểm chứng (testable)
Yêu cầu phải đo lường và kiểm thử được.
Nhất quán (Consistent)
Không mâu thuẫn giữa các yêu cầu.
Có thể thực hiện được (Feasible)
Yêu cầu phải phù hợp với nguồn lực, công nghệ.
Có thể theo dõi (Traceable)
Có thể gán mã số và liên kết với các yêu cầu khác.
6. Vai trò của Business Analyst khi làm tài liệu yêu cầu
Thu thập và tổng hợp thông tin từ các bên liên quan.
Phân tích và làm rõ các yêu cầu phức tạp.
Xác nhận yêu cầu với khách hàng và đội dự án.
Chuyển hóa yêu cầu thành tài liệu chi tiết, dễ hiểu.
Cập nhật tài liệu khi có thay đổi.
7. Mẫu Template đơn giản cho Tài liệu Yêu cầu
8. Kết luận
✅ Tài liệu yêu cầu là xương sống của mọi dự án, giúp đảm bảo phát triển đúng và đủ, hạn chế sai sót và tranh chấp trong quá trình làm việc.
Last updated