4. TỔNG QUAN YÊU CẦU
4.1 Phân loại thay đổi & Xử lý yêu cầu
Mục này được thực hiện trước khi viết User Story, Functional Requirement hoặc Use Case chi tiết. Mục tiêu là xác định một chức năng đang ở trạng thái nào, thay đổi loại gì và mức đặc tả cần dùng. Người viết không được mặc định mọi chức năng đều là chức năng mới hoặc đều phải viết lại toàn bộ Use Case.
4.1.1 Trạng thái hiện tại của chức năng
| Current State |
Khi nào chọn |
Ý nghĩa khi đặc tả |
| NOT_EXIST |
Chức năng/chế độ xử lý chưa tồn tại trên hệ thống hiện tại. |
Đánh giá phạm vi xây mới và tác động; dùng New Specification. |
| EXISTING |
Chức năng đã tồn tại trên hệ thống. |
Bắt buộc phân loại tiếp Change Type trước khi quyết định viết Reference, Delta hay Full Re-spec. |
| LEGACY / UNKNOWN |
Có chức năng cũ nhưng tài liệu/logic hiện tại chưa đủ rõ. |
Khảo sát As-Is trước; chưa được kết luận To-Be khi chưa xác định baseline. |
4.1.2 Danh mục loại thay đổi (Change Type Catalog)
| Change Type |
Dùng khi |
Phải mô tả tối thiểu |
Treatment mặc định |
| NEW |
Chức năng chưa tồn tại và cần xây mới. |
Business Need; scope; FR; UC/Rule/UI/Data cần thiết; impact đến module khác. |
New Spec |
| UNCHANGED |
Chức năng đã có, đã khảo sát và không thay đổi trong release. |
Current status; phạm vi tham chiếu; regression impact nếu có. |
Reference |
| UI_CHANGE |
Logic nghiệp vụ giữ nguyên, thay layout/control/UX/field presentation. |
As-Is UI; To-Be UI; UI delta; xác nhận Logic/Data/API/Permission có đổi hay không. |
Delta Spec |
| MINOR_LOGIC |
Thêm/sửa điều kiện, validation hoặc xử lý nhỏ nhưng không làm thay đổi bản chất workflow. |
As-Is rule/step; delta; To-Be; affected UC/rule/test. |
Delta Spec |
| MAJOR_LOGIC |
Thay đổi đáng kể workflow, calculation, state hoặc hành vi cốt lõi. |
As-Is summary; To-Be; state/workflow; UC bị ảnh hưởng; rule; regression scope. |
Full Re-spec |
| DATA_CHANGE |
Thay đổi field/entity/schema/source/mapping/lifecycle hoặc dữ liệu lịch sử. |
As-Is/To-Be data; migration/backfill; compatibility; reconciliation; rollback nếu áp dụng. |
Delta hoặc Full Re-spec |
| PERMISSION_CHANGE |
Thay đổi role, action permission hoặc data scope. |
As-Is/To-Be permission; affected actions/screens/APIs; regression security scope. |
Delta hoặc Full Re-spec |
| INTEGRATION_CHANGE |
Thay API, external system, payload, mapping, protocol hoặc device integration. |
As-Is/To-Be interface; mapping; compatibility; error/retry/idempotency. |
Delta hoặc Full Re-spec |
| CONFIG_CHANGE |
Thay parameter, master configuration, feature toggle hoặc policy có thể cấu hình. |
Config key/scope/default/effective rule; affected behavior. |
Delta Spec |
| REPORT_CHANGE |
Thay report/dashboard/KPI hoặc cách tổng hợp số liệu. |
Metric definition; source; filter; formula; display delta. |
Delta hoặc Full Re-spec |
| NFR_CHANGE |
Chức năng không đổi về nghiệp vụ nhưng thay yêu cầu hiệu năng, bảo mật, retention, availability... |
NFR As-Is/Target; measurable criterion; verification method. |
Delta Spec |
| DEPRECATED |
Chức năng hiện có cần ngừng sử dụng hoặc thay thế. |
Reason; dependency; data retention; replacement; transition plan. |
Deprecation Spec |
4.1.3 Requirement Treatment - phải viết sâu đến đâu?
| Treatment |
Áp dụng |
Nội dung cần viết |
Không cần làm |
| Reference |
EXISTING + UNCHANGED |
Tên chức năng/UC; trạng thái Existing; kết luận không thay đổi; regression/reference link. |
Không copy lại flow, UI và rule cũ nếu không có thay đổi. |
| Delta Spec |
Thay đổi cục bộ: UI, minor logic, permission, config, data/interface nhỏ. |
As-Is liên quan; Change; To-Be; impact; phần UI/Rule/Data/Permission bị đổi. |
Không viết lại toàn bộ UC nếu các bước không bị ảnh hưởng. |
| Full Re-spec |
Major logic/cross-module hoặc baseline cũ không còn phù hợp. |
Đặc tả đầy đủ To-Be: UC/flow, rules, state/workflow, UI/Data/Permission/Integration liên quan. |
Không dựa vào câu "giữ nguyên phần còn lại" nếu không có baseline rõ. |
| New Spec |
Chức năng hoàn toàn mới. |
Business Need/FR; UC hoặc specification phù hợp; UI/Data/Permission/Integration/NFR liên quan. |
Không tạo As-Is giả như "As-Is: chưa có". |
| Deprecation Spec |
Ngừng hoặc thay thế chức năng cũ. |
Đối tượng bị loại bỏ; dependency; dữ liệu; migration/transition; replacement. |
Không chỉ ghi "bỏ chức năng" mà thiếu impact. |
4.1.4 Decision Matrix - chọn case nào
| Tình trạng khảo sát |
Change Type |
Treatment |
Ví dụ |
| Chưa có chức năng |
NEW |
New Spec |
HRM chưa có Tổng hợp phép -> xây mới. |
| Đã có, không đổi |
UNCHANGED |
Reference |
Xem chi tiết hồ sơ giữ nguyên. |
| Đã có, chỉ đổi giao diện |
UI_CHANGE |
Delta Spec |
Danh sách nhân sự đổi layout/filter bar. |
| Đã có, thêm một điều kiện/rule nhỏ |
MINOR_LOGIC |
Delta Spec |
Bổ sung filter theo trạng thái Active. |
| Đã có, đổi workflow/state lớn |
MAJOR_LOGIC |
Full Re-spec |
Phép từ duyệt 1 cấp thành nhiều cấp. |
| Đã có, thêm/cập nhật dữ liệu |
DATA_CHANGE |
Delta/Full |
Bổ sung WorkLocation và backfill dữ liệu cũ. |
| Đã có, đổi data scope/quyền |
PERMISSION_CHANGE |
Delta/Full |
Manager chỉ xem nhân viên thuộc cây quản lý. |
| Đã có, đổi API/device |
INTEGRATION_CHANGE |
Delta/Full |
Đổi nguồn log chấm công từ file sang API. |
| Đã có, dừng sử dụng |
DEPRECATED |
Deprecation Spec |
Ngừng màn hình log cũ sau khi thay bằng trang mới. |
Ánh xạ sang Case A–F trình bày chi tiết ở mục 4.1.6: UNCHANGED → Case A, UI_CHANGE → Case B, MINOR_LOGIC → Case C, MAJOR_LOGIC (và các case Delta/Full khác nếu đủ lớn) → Case D, NEW → Case E, DEPRECATED → Case F.
4.1.5 Mẫu Change Assessment cho từng chức năng
| Thuộc tính |
Hướng dẫn điền |
| Function / UC ID |
Mã chức năng hoặc Use Case hiện hữu. |
| Tên chức năng |
Tên nghiệp vụ người dùng hiểu được. |
| Current State |
NOT_EXIST / EXISTING / LEGACY-UNKNOWN. |
| As-Is Summary |
2-5 bullet mô tả đúng phần hiện tại liên quan đến thay đổi. Không chép toàn bộ tài liệu cũ. |
| Problem / Change Reason |
Vấn đề hiện tại hoặc lý do business/technical cần thay đổi. |
| Change Type |
Chọn một hoặc nhiều loại trong Change Type Catalog (4.1.2). |
| Change Level |
Low / Medium / High hoặc Minor / Major theo quy ước dự án. |
| To-Be Summary |
Mô tả kết quả/hành vi mục tiêu sau thay đổi. |
| Impact Scope |
Within Function / Module / Cross-module / System-wide. |
| Affected Artefacts |
FR / UC / Rule / Screen / Data / Permission / API / NFR / Test. |
| Legacy Data Impact |
None / Backfill / Migration / Compatibility / Reconciliation / TBD. |
| Treatment |
Reference / Delta Spec / Full Re-spec / New Spec / Deprecation Spec. |
| Open Items |
Các câu hỏi chưa được xác nhận. |
Mỗi chương Module Specification (5–9) mở đầu bằng bảng Change Assessment tóm tắt (cột Function ID/Chức năng/Current State/Change Type/Impact/Treatment/Change Summary) — là bản rút gọn của template trên, dùng cho toàn bộ chức năng trong module (xem áp dụng tại mục "Đánh giá & Xử lý Thay đổi" trong Chương 5).
4.1.6 Mẫu mô tả theo từng case
Case A - Existing / Unchanged
- Current State: EXISTING
- Change Type: UNCHANGED
- Treatment: Reference
- As-Is: [tham chiếu baseline hiện hữu]
- To-Be: Không thay đổi.
- Impact: Không development; thực hiện regression theo phạm vi liên quan.
- Mapping MkDocs:
!!! abstract "Đặc tả Use Case" + !!! info "Existing Specification" + !!! note "Change" = None + !!! info "Regression Scope".
Case B - Existing / UI Change
- Current State: EXISTING
- Change Type: UI_CHANGE
- Treatment: Delta Spec
- As-Is UI: [màn hình/bố cục hiện tại]
- To-Be UI: [màn hình/bố cục mục tiêu]
- UI Delta: [field/control/layout thay đổi]
- Business Logic / Data / Permission / API: Unchanged hoặc liệt kê phần thay đổi thực tế.
- Mapping MkDocs:
!!! failure "As-Is UI" + !!! success "To-Be UI" + !!! quote "UI Delta" + !!! info "Data/Permission Impact" + !!! info "Regression Scope".
Case C - Existing / Minor Logic
- Current State: EXISTING
- Change Type: MINOR_LOGIC
- Treatment: Delta Spec
- As-Is: [rule/step hiện tại]
- Problem: [vấn đề]
- To-Be: [rule/step mới]
- Affected: [UC step / Rule / Screen / Test]
- Mapping MkDocs:
!!! failure "As-Is" + !!! success "To-Be" + !!! quote "Delta" + !!! info "Affected/Unchanged Components".
Case D - Existing / Major Logic
- Current State: EXISTING
- Change Type: MAJOR_LOGIC
- Treatment: Full Re-spec
- As-Is Summary: [baseline hiện tại]
- To-Be Process/State: [workflow mục tiêu]
- Affected Modules/UCs: [danh sách]
- Full To-Be Specification: UC + Flow + Rule + State + UI/Data/Permission/Integration liên quan.
- Mapping MkDocs:
!!! example "Main Flow" + !!! note "Alternate Flows" + !!! warning "Exception Flows" (nếu có).
Case E - New Function
- Current State: NOT_EXIST
- Change Type: NEW
- Treatment: New Spec
- Business Need / User Story / FR: [nguồn yêu cầu]
- Scope & Impact: [module/cross-module]
- Specification: UC hoặc loại specification phù hợp + Rule/UI/Data/Permission/Integration.
- Mapping MkDocs: bảng
!!! abstract đầy đủ (Goal, Trigger, Preconditions, Postconditions...) + !!! example "Main Flow" + !!! note "Alternate Flows" + !!! warning "Exception Flows".
Case F - Deprecated
- Current State: EXISTING
- Change Type: DEPRECATED
- Treatment: Deprecation Spec
- Reason: [lý do bỏ/thay thế]
- Replacement: [chức năng mới nếu có]
- Dependency/Data Impact: [ảnh hưởng]
- Transition: [kế hoạch ngừng/migration nếu áp dụng]
- Mapping MkDocs:
!!! bug "Lý do loại bỏ" + !!! info "Xử lý dữ liệu cũ" + !!! warning "UC/Rule/Screen bị ảnh hưởng".
Nguyên tắc: một chức năng có thể có nhiều Change Type đồng thời (ví dụ MAJOR_LOGIC + DATA_CHANGE + PERMISSION_CHANGE); khi đó ghi đầy đủ các type và chọn Treatment theo mức đặc tả cao nhất cần thiết.
4.1.7 Quy tắc phân loại bắt buộc
- Một chức năng EXISTING phải có ít nhất Current State + Change Type + Treatment trước khi được đặc tả chi tiết.
- Một chức năng có thể có nhiều Change Type đồng thời, ví dụ MAJOR_LOGIC + PERMISSION_CHANGE + DATA_CHANGE; Treatment lấy theo mức đặc tả cao nhất cần thiết.
- Impact Level không đồng nghĩa Change Type: UI_CHANGE vẫn có thể có impact lớn nếu ảnh hưởng nhiều màn hình/module.
- Không dùng các nhãn mơ hồ "Chỉnh sửa" hoặc "Thay đổi" nếu không chỉ rõ thay đổi UI, logic, data, permission, integration hay NFR.
- Nếu chưa đủ thông tin để phân loại, dùng LEGACY / UNKNOWN và mở Open Item để khảo sát As-Is; không tự kết luận.
4.2 Nhu cầu nghiệp vụ
Danh sách các nhu cầu nghiệp vụ (Business Needs) đóng vai trò là động lực chính để xây dựng hệ thống HRM.
| ID |
Business Need |
Module Liên Quan |
| BN-01 |
Công ty cần một nguồn hồ sơ nhân sự tập trung, bảo mật cao (RBAC, Data Scope) và theo dõi được lịch sử thay đổi thông tin của từng cá nhân. |
Hồ sơ nhân sự |
| BN-02 |
Xóa bỏ tình trạng chấm công thủ công trên giấy, cần hệ thống ghi nhận thời gian thực tế và tự động hóa quy trình giải trình đi muộn/về sớm. |
Chấm công |
| BN-03 |
Minh bạch hóa quỹ phép, số hóa hoàn toàn quy trình duyệt đơn xin nghỉ phép nhiều cấp (Manager, HR) nhằm giảm sai sót. |
Quản lý phép |
| BN-04 |
Tự động hóa việc tổng hợp bảng công tháng dựa trên dữ liệu chấm công và nghỉ phép, hỗ trợ khóa kỳ công chống sửa đổi trái phép. |
Bảng công & Log |
4.3 Bản đồ User Story
| Actor |
Action (Muốn làm gì) |
Value (Để làm gì) |
Feature / Module |
| Nhân viên |
Xem chi tiết ngày công và quỹ phép của bản thân |
Để biết được mình đã đi làm đủ bao nhiêu ngày và còn bao nhiêu ngày nghỉ phép. |
Chấm công, Phép |
| Nhân viên |
Khởi tạo đơn xin nghỉ phép trực tuyến |
Để cấp trên có thể phê duyệt nhanh chóng mà không cần đơn từ giấy tờ. |
Quản lý phép |
| Quản lý |
Xem danh sách nhân sự thuộc phòng ban của mình |
Để quản lý đội ngũ và phân bổ công việc hợp lý. |
Hồ sơ nhân sự |
| Quản lý |
Phê duyệt/Từ chối đơn xin phép của nhân viên |
Để kiểm soát nguồn lực làm việc hàng ngày của team. |
Quản lý phép |
| HR/Admin |
Thêm mới hồ sơ nhân sự & import hàng loạt |
Để số hóa danh sách cán bộ công nhân viên vào hệ thống. |
Hồ sơ nhân sự |
| HR/Admin |
Tính toán lại bảng công và chốt báo cáo tháng |
Để có số liệu chính xác tuyệt đối gửi sang hệ thống tính lương. |
Bảng công, Log |
4.4 Danh mục yêu cầu chức năng
Danh sách dưới đây liệt kê các Yêu cầu Chức năng (FR) cốt lõi của hệ thống và ánh xạ đến các Use Case tương ứng.
| FR ID |
Yêu cầu Chức năng (System shall...) |
Use Case ID |
Phân hệ |
| FR-HR-01 |
Hệ thống cho phép thêm mới, cập nhật và lưu lịch sử thông tin hồ sơ nhân sự. |
UC-HR-03, UC-HR-04 |
Hồ sơ nhân sự |
| FR-HR-02 |
Hệ thống hỗ trợ xuất hồ sơ nhân sự ra định dạng Word theo mẫu chuẩn. |
UC-HR-06 |
Hồ sơ nhân sự |
| FR-ATT-01 |
Hệ thống nhận và lưu trữ sự kiện chấm công (IN/OUT) từ thiết bị quét vân tay/khuôn mặt. |
UC-ATT-01 |
Chấm công |
| FR-ATT-02 |
Hệ thống tự động phát hiện các ngày công lỗi (thiếu IN/OUT) và cho phép nhân viên nộp giải trình. |
UC-ATT-04 |
Chấm công |
| FR-LV-01 |
Hệ thống tự động trừ quỹ phép tương ứng sau khi Đơn xin nghỉ phép được phê duyệt thành công. |
UC-LV-07 |
Quản lý phép |
| FR-LV-02 |
Cấp quản lý trực tiếp sẽ nhận được thông báo khi nhân viên cấp dưới nộp đơn nghỉ phép. |
UC-LV-02 |
Quản lý phép |
| FR-TS-01 |
Hệ thống có công cụ tự động tổng hợp số ngày làm việc, số giờ làm thêm dựa trên dữ liệu chấm công. |
UC-TS-01 |
Bảng công |
| FR-TS-02 |
Chức năng "Chốt kỳ công" (Lock) ngăn chặn tất cả mọi thay đổi đối với bảng công của tháng đó. |
UC-TS-05 |
Bảng công |
| FR-LOG-01 |
Hệ thống cho phép xuất báo cáo tổng hợp tháng (Monthly Summary) sang định dạng Excel. |
UC-LOG-01 |
Log & Báo cáo |