1. KIỂM SOÁT TÀI LIỆU & THUẬT NGỮ
1.1 Quy ước tài liệu
- A4 portrait; body text Arial 10.5 pt; heading hierarchy 16/13/11.5 pt; line spacing 1.15.
- Requirement ID là bất biến và không được tái sử dụng sau khi đã phê duyệt.
- Một yêu cầu chỉ diễn đạt một nghĩa vụ; điều kiện gộp phải được tách thành các bullet/rule riêng biệt.
- Quyết định nghiệp vụ chưa xác định được đánh dấu
[CẦN XÁC NHẬN]thay vì tự suy đoán. - Mỗi loại thông tin chỉ có một vị trí chuẩn (canonical location): FR ở Requirement Overview; Flow ở Use Case; Rule dùng chung ở Module; UI/Data/Permission ở chương chuyên biệt của nó — không lặp lại giữa các chương (xem Sơ đồ Luồng đọc).
Riêng quy ước trình bày đặc thù của bản MkDocs này (Admonition !!! abstract, !!! example...) được định nghĩa tại 17. Quy tắc Soạn thảo & Đánh giá để tránh trùng lặp thông tin với mục này.
1.2 Thuật ngữ cốt lõi
| Thuật ngữ | Định nghĩa | Câu hỏi trả lời | Vị trí |
|---|---|---|---|
| Business Need | Vấn đề hoặc kết quả kinh doanh cần đạt. | Tại sao cần thay đổi? | Requirement Overview |
| User Story | Nhu cầu theo góc nhìn người dùng, thường dùng trong backlog Agile. | Người dùng cần gì và vì sao? | Requirement Overview / backlog reference |
| Functional Requirement (FR) | Phát biểu có ID về hành vi/khả năng phần mềm bắt buộc phải cung cấp. | Hệ thống phải làm gì? | Functional Requirement Catalog |
| Use Case (UC) | Mô tả mục tiêu của Actor và chuỗi tương tác Actor ↔ System. | Actor đạt mục tiêu bằng cách nào? | Trong Module |
| Business Rule | Quy tắc nghiệp vụ độc lập chi phối quyết định, điều kiện, tính toán hoặc trạng thái. | Luật xử lý là gì? | Module Rule Catalog hoặc UC-specific rule |
| Main Flow | Đường tương tác thành công thông thường. | Trình tự chuẩn là gì? | Use Case Detail |
| Alternate Flow | Nhánh nghiệp vụ hợp lệ khác đường chuẩn. | Nếu rẽ nhánh thì sao? | Use Case Detail |
| Exception Flow | Xử lý khi lỗi hoặc không thể hoàn tất. | Khi lỗi thì sao? | Use Case Detail |
| UI Specification | Đặc tả screen, field, control, trạng thái hiển thị. | Người dùng nhìn/thao tác gì? | UI Specification |
| Data Requirement | Yêu cầu về dữ liệu, nguồn, cấu trúc, lifecycle, retention. | Dữ liệu nào được lưu/xử lý? | Data Specification |
| Permission / Data Scope | Action được phép và phạm vi dữ liệu được truy cập. | Ai được làm gì trên dữ liệu nào? | Permission & Authorization |
| NFR | Yêu cầu chất lượng/ràng buộc có thể đo/verify. | Hệ thống phải nhanh/an toàn/ổn định đến mức nào? | NFR |
| Traceability | Liên kết nhu cầu → FR → UC/Rule/UI/Data → Test. | Coverage và impact ra sao? | Traceability Matrix |
1.3 Mối quan hệ giữa các tài liệu chính
| Artefact | Ví dụ HRM | Vai trò |
|---|---|---|
| User Story | Là Nhân viên, tôi muốn tạo đơn nghỉ phép để đăng ký thời gian nghỉ với quản lý. | Nhu cầu người dùng. |
| Functional Requirement | FR-LV-02: Hệ thống phải cho phép nhân viên tạo đơn nghỉ phép. | Khả năng bắt buộc. |
| Use Case | UC-LV-02: Tạo đơn phép. | Chuỗi tương tác. |
| Business Rule | RULE-LV-03: Số phép sử dụng được tính theo lịch làm việc và loại phép. | Luật xử lý. |
Một yêu cầu nghiệp vụ được truy vết xuyên suốt theo chuỗi Business Need → Functional Requirement → Use Case → Business Rule / UI / Data → Traceability Matrix, mỗi mắt xích chỉ được viết đầy đủ tại đúng "home" của nó như liệt kê ở bảng 1.2.