ITO
Phòng PMO Quy trình phát triển phần mềm
Tải PDF
Mô hình Waterfall · v1.0 · Tháng 5, 2026

Danh sách tài liệu quy trình phát triển phần mềm

Tổng hợp các tài liệu cần tạo lập tại công ty ITO, áp dụng cho phạm vi từ giai đoạn lấy yêu cầu đến trước khi bước vào Dev (lập trình).

33
Tổng tài liệu
26
Bắt buộc
6
Khuyến nghị
1
Tùy dự án

1Tổng quan

Tài liệu này tổng hợp 33 tài liệu bắt buộc và khuyến nghị cần được tạo lập trong quy trình phát triển phần mềm theo mô hình Waterfall tại công ty ITO. Toàn bộ tài liệu được phân chia theo 5 giai đoạn:

#Giai đoạnSố tài liệu
1KHỞI TẠO DỰ ÁN (Project Initiation)3
2KHẢO SÁT & LẤY YÊU CẦU (Requirements Elicitation)5
3PHÂN TÍCH YÊU CẦU (Requirements Analysis)7
4THIẾT KẾ HỆ THỐNG (System Design)7
5LẬP KẾ HOẠCH & CHUẨN BỊ DEV (Planning & Pre-Development)11
TỔNG CỘNG33

Phân loại mức độ bắt buộc

Mức độSố tài liệuÝ nghĩa
Bắt buộc26Phải có ở mọi dự án – không có sẽ ảnh hưởng nghiêm trọng đến chất lượng/tiến độ.
Khuyến nghị6Nên có để tăng độ chuyên nghiệp; có thể giảm bớt với dự án nhỏ.
Tùy dự án1Chỉ tạo khi đặc thù dự án yêu cầu (vd: tích hợp hệ thống bên thứ 3).

2Bảng tổng hợp toàn bộ tài liệu

Bảng dưới đây liệt kê toàn bộ 33 tài liệu cần thiết. Chi tiết từng tài liệu được mô tả ở phần 3.

#Tên tài liệuPhụ tráchMức độ
GIAI ĐOẠN 1 – KHỞI TẠO DỰ ÁN (Project Initiation)
1.1Project Charter – Bản đề xuất / Tuyên bố dự ánProject Manager (PM) / Giám đốc dự ánBắt buộc
1.2Stakeholder Register – Danh sách các bên liên quanPM / BABắt buộc
1.3Project Kick-off Document – Tài liệu khởi động dự ánPMBắt buộc
GIAI ĐOẠN 2 – KHẢO SÁT & LẤY YÊU CẦU (Requirements Elicitation)
2.1Meeting Minutes (MoM) – Biên bản các cuộc họp khảo sátBA (Business Analyst)Bắt buộc
2.2As-Is Survey Report – Báo cáo khảo sát hiện trạngBAKhuyến nghị
2.3Business Requirements Document (BRD) – Tài liệu yêu cầu nghiệp vụBABắt buộc
2.4User Story / Use Case List – Danh sách User Story / Use CaseBABắt buộc
2.5Glossary – Từ điển thuật ngữ dự ánBAKhuyến nghị
GIAI ĐOẠN 3 – PHÂN TÍCH YÊU CẦU (Requirements Analysis)
3.1Software Requirements Specification (SRS) – Đặc tả yêu cầu phần mềmBA (Lead) + Tech Lead reviewBắt buộc
3.2Functional Requirements Specification (FRS/FSD) – Đặc tả yêu cầu chức năng chi tiếtBABắt buộc
3.3Non-Functional Requirements (NFR) – Yêu cầu phi chức năngBA + Solution ArchitectBắt buộc
3.4Use Case / Activity / Sequence Diagram – Sơ đồ Use Case / Activity / SequenceBA / Solution ArchitectKhuyến nghị
3.5Business Process Diagram (BPMN) – Sơ đồ quy trình nghiệp vụ To-BeBAKhuyến nghị
3.6Wireframe / Mockup / Prototype – Bản vẽ giao diện sơ bộ / Mockup / PrototypeUI/UX Designer + BABắt buộc
3.7Requirements Traceability Matrix (RTM) – Ma trận truy vết yêu cầuBA / QA LeadBắt buộc
GIAI ĐOẠN 4 – THIẾT KẾ HỆ THỐNG (System Design)
4.1High-Level Design (HLD) – Thiết kế kiến trúc tổng thểSolution Architect / Tech LeadBắt buộc
4.2Low-Level Design (LLD) / Detailed Design Document (DDD) – Thiết kế chi tiết moduleTech Lead / Senior DevBắt buộc
4.3Database Design Document – Tài liệu thiết kế cơ sở dữ liệuDBA / Tech LeadBắt buộc
4.4UI/UX Design Specification – Đặc tả thiết kế giao diệnUI/UX DesignerBắt buộc
4.5API Specification / Interface Design – Đặc tả API & InterfaceBackend Tech LeadBắt buộc
4.6Security Design Document – Tài liệu thiết kế bảo mậtSecurity Engineer / Tech LeadKhuyến nghị
4.7Integration Design Document – Tài liệu thiết kế tích hợpSolution ArchitectTùy dự án
GIAI ĐOẠN 5 – LẬP KẾ HOẠCH & CHUẨN BỊ DEV (Planning & Pre-Development)
5.1Project Plan / Master Plan – Kế hoạch tổng thể dự ánPMBắt buộc
5.2Work Breakdown Structure (WBS) – Cấu trúc phân rã công việcPMBắt buộc
5.3Effort Estimation – Bảng ước lượng nhân lựcTech Lead + PMBắt buộc
5.4Risk Management Plan & Risk Register – Kế hoạch & Sổ đăng ký rủi roPMBắt buộc
5.5Communication Plan – Kế hoạch giao tiếpPMKhuyến nghị
5.6Quality Assurance Plan – Kế hoạch đảm bảo chất lượngQA LeadBắt buộc
5.7Test Strategy & Master Test Plan – Chiến lược & kế hoạch kiểm thửQA Lead / Test ManagerBắt buộc
5.8Configuration Management Plan – Kế hoạch quản lý cấu hìnhDevOps / Tech LeadBắt buộc
5.9Coding Standards & Guidelines – Tiêu chuẩn lập trình & quy tắc codeTech LeadBắt buộc
5.10Development Environment Setup Document – Hướng dẫn cài đặt môi trường DevDevOps / Tech LeadBắt buộc
5.11Dev Kick-off Document – Tài liệu khởi động giai đoạn DevPM + Tech LeadBắt buộc

3Mô tả chi tiết từng tài liệu

Mỗi tài liệu được mô tả theo 5 trường thông tin: Mục đích, Phụ trách, Đầu vào, Đầu ra, Mức độ.

GIAI ĐOẠN 1 – KHỞI TẠO DỰ ÁN (Project Initiation)
Mục tiêu: Hợp thức hóa dự án, xác định phạm vi sơ bộ và các bên liên quan trước khi bước vào giai đoạn khảo sát chi tiết.
1.1

Project Charter

Bản đề xuất / Tuyên bố dự án
Bắt buộc
Mục đích
Tài liệu chính thức công nhận sự tồn tại của dự án; xác định mục tiêu, phạm vi tổng quát, ngân sách sơ bộ, tiêu chí thành công và quyền hạn của Project Manager.
Phụ trách
Project Manager (PM) / Giám đốc dự án
Đầu vào
Yêu cầu kinh doanh từ khách hàng / Sales hand-over.
Đầu ra
Project Charter đã được ký duyệt bởi Sponsor.
1.2

Stakeholder Register

Danh sách các bên liên quan
Bắt buộc
Mục đích
Liệt kê đầy đủ stakeholder (khách hàng, end-user, vendor, nội bộ ITO…), vai trò, mức độ ảnh hưởng/quan tâm để PM xây dựng chiến lược giao tiếp.
Phụ trách
PM / BA
Đầu vào
Project Charter, hợp đồng, sơ đồ tổ chức khách hàng.
Đầu ra
Bảng stakeholder + bản đồ Power/Interest.
1.3

Project Kick-off Document

Tài liệu khởi động dự án
Bắt buộc
Mục đích
Tài liệu trình bày trong buổi kick-off chính thức với khách hàng: mục tiêu, scope, timeline cấp cao, team, kênh giao tiếp, quy trình làm việc.
Phụ trách
PM
Đầu vào
Project Charter, Stakeholder Register.
Đầu ra
Slide kick-off + biên bản kick-off được ký xác nhận.
GIAI ĐOẠN 2 – KHẢO SÁT & LẤY YÊU CẦU (Requirements Elicitation)
Mục tiêu: Thu thập đầy đủ yêu cầu nghiệp vụ từ khách hàng/người dùng cuối thông qua phỏng vấn, workshop, khảo sát hiện trạng.
2.1

Meeting Minutes (MoM)

Biên bản các cuộc họp khảo sát
Bắt buộc
Mục đích
Ghi nhận nội dung từng cuộc họp với khách hàng: người tham dự, các quyết định, action items, người chịu trách nhiệm, deadline. Là bằng chứng pháp lý khi có tranh chấp về phạm vi.
Phụ trách
BA (Business Analyst)
Đầu vào
Lịch họp, agenda.
Đầu ra
MoM được khách hàng xác nhận (qua email hoặc chữ ký).
2.2

As-Is Survey Report

Báo cáo khảo sát hiện trạng
Khuyến nghị
Mục đích
Mô tả quy trình hiện tại của khách hàng (As-Is): các bước nghiệp vụ, hệ thống đang dùng, dữ liệu, vấn đề/đau điểm. Làm cơ sở để đề xuất To-Be.
Phụ trách
BA
Đầu vào
Phỏng vấn, quan sát, tài liệu nội bộ khách hàng.
Đầu ra
Báo cáo hiện trạng + sơ đồ quy trình As-Is.
2.3

Business Requirements Document (BRD)

Tài liệu yêu cầu nghiệp vụ
Bắt buộc
Mục đích
Mô tả các yêu cầu ở góc độ kinh doanh: mục tiêu, KPI, đối tượng sử dụng, ràng buộc nghiệp vụ. Đây là tài liệu cấp cao mà khách hàng (business side) đọc và ký duyệt.
Phụ trách
BA
Đầu vào
MoM, As-Is Report.
Đầu ra
BRD đã được ký duyệt.
2.4

User Story / Use Case List

Danh sách User Story / Use Case
Bắt buộc
Mục đích
Liệt kê các tình huống sử dụng (use case) và câu chuyện người dùng (user story) ở mức tổng quan trước khi đi sâu vào đặc tả.
Phụ trách
BA
Đầu vào
BRD.
Đầu ra
Bảng user story/use case có ID, tên, actor, mô tả ngắn, độ ưu tiên.
2.5

Glossary

Từ điển thuật ngữ dự án
Khuyến nghị
Mục đích
Thống nhất cách hiểu các thuật ngữ nghiệp vụ giữa khách hàng – BA – Dev – QA. Tránh nhầm lẫn và sai sót khi viết code/test case.
Phụ trách
BA
Đầu vào
MoM, BRD.
Đầu ra
Bảng thuật ngữ Việt – Anh + định nghĩa.
GIAI ĐOẠN 3 – PHÂN TÍCH YÊU CẦU (Requirements Analysis)
Mục tiêu: Chuyển hóa yêu cầu nghiệp vụ thành đặc tả chi tiết, có thể đưa vào thiết kế và phát triển.
3.1

Software Requirements Specification (SRS)

Đặc tả yêu cầu phần mềm
Bắt buộc
Mục đích
Tài liệu trung tâm – mô tả chi tiết toàn bộ yêu cầu chức năng & phi chức năng, quy tắc nghiệp vụ, ràng buộc kỹ thuật, giả định, phạm vi loại trừ. Theo chuẩn IEEE 830.
Phụ trách
BA (Lead) + Tech Lead review
Đầu vào
BRD, User Story List, Glossary.
Đầu ra
SRS đã được khách hàng + Tech Lead ký duyệt (baseline).
3.2

Functional Requirements Specification (FRS/FSD)

Đặc tả yêu cầu chức năng chi tiết
Bắt buộc
Mục đích
Đặc tả chi tiết từng màn hình, từng chức năng: input, validation, business rule, output, message, exception. Có thể tách rời SRS hoặc lồng trong SRS tùy quy mô dự án.
Phụ trách
BA
Đầu vào
SRS, Wireframe.
Đầu ra
FSD đã được ký duyệt.
3.3

Non-Functional Requirements (NFR)

Yêu cầu phi chức năng
Bắt buộc
Mục đích
Mô tả các yêu cầu về performance, security, availability, scalability, usability, compliance (GDPR, ISO 27001…). Nếu thiếu thì hệ thống dễ fail UAT.
Phụ trách
BA + Solution Architect
Đầu vào
SRS, ràng buộc khách hàng.
Đầu ra
NFR matrix có metric đo lường (vd: response < 2s).
3.4

Use Case / Activity / Sequence Diagram

Sơ đồ Use Case / Activity / Sequence
Khuyến nghị
Mục đích
Mô hình hóa hành vi hệ thống bằng UML để dev và QA dễ hình dung luồng nghiệp vụ và các tương tác giữa actor – hệ thống – module.
Phụ trách
BA / Solution Architect
Đầu vào
SRS, FSD.
Đầu ra
Bộ diagram UML (PNG/PlantUML/Draw.io) đính kèm SRS.
3.5

Business Process Diagram (BPMN)

Sơ đồ quy trình nghiệp vụ To-Be
Khuyến nghị
Mục đích
Sơ đồ BPMN mô tả luồng nghiệp vụ tương lai (To-Be) sau khi áp dụng phần mềm. So sánh với As-Is để thấy rõ giá trị mang lại.
Phụ trách
BA
Đầu vào
As-Is Report, BRD.
Đầu ra
BPMN To-Be đã được khách hàng xác nhận.
3.6

Wireframe / Mockup / Prototype

Bản vẽ giao diện sơ bộ / Mockup / Prototype
Bắt buộc
Mục đích
Trực quan hóa giao diện để khách hàng xác nhận sớm về layout, luồng người dùng, trước khi đầu tư vào thiết kế chi tiết và code.
Phụ trách
UI/UX Designer + BA
Đầu vào
FSD, User Story.
Đầu ra
Wireframe (Figma/Axure/Balsamiq) hoặc HTML prototype clickable.
3.7

Requirements Traceability Matrix (RTM)

Ma trận truy vết yêu cầu
Bắt buộc
Mục đích
Bảng ánh xạ Requirement ID ↔ Use Case ↔ Design ↔ Test Case ↔ Code Module. Đảm bảo không yêu cầu nào bị bỏ sót và mọi thứ đều có gốc gác.
Phụ trách
BA / QA Lead
Đầu vào
SRS, FSD, Test Cases.
Đầu ra
File Excel RTM được cập nhật xuyên suốt vòng đời dự án.
GIAI ĐOẠN 4 – THIẾT KẾ HỆ THỐNG (System Design)
Mục tiêu: Chuyển yêu cầu thành thiết kế kỹ thuật để Dev có thể bắt tay vào lập trình. Đây là cầu nối cuối cùng trước Dev.
4.1

High-Level Design (HLD)

Thiết kế kiến trúc tổng thể
Bắt buộc
Mục đích
Mô tả kiến trúc tổng thể: các thành phần hệ thống, công nghệ sử dụng, mô hình triển khai, sơ đồ deployment, sơ đồ tích hợp với hệ thống bên ngoài.
Phụ trách
Solution Architect / Tech Lead
Đầu vào
SRS, NFR.
Đầu ra
Tài liệu HLD + Architecture Diagram + Deployment Diagram.
4.2

Low-Level Design (LLD) / Detailed Design Document (DDD)

Thiết kế chi tiết module
Bắt buộc
Mục đích
Đi sâu vào từng module: class diagram, hàm, thuật toán, validation chi tiết, error handling. Là 'bản vẽ kỹ thuật' để Dev viết code.
Phụ trách
Tech Lead / Senior Dev
Đầu vào
HLD, FSD.
Đầu ra
DDD cho từng module/feature.
4.3

Database Design Document

Tài liệu thiết kế cơ sở dữ liệu
Bắt buộc
Mục đích
ERD, schema, data dictionary, index, ràng buộc, chiến lược migration/seed. Cơ sở để DBA/Dev tạo DB.
Phụ trách
DBA / Tech Lead
Đầu vào
SRS, LLD.
Đầu ra
ERD + DDL script + data dictionary.
4.4

UI/UX Design Specification

Đặc tả thiết kế giao diện
Bắt buộc
Mục đích
Thiết kế giao diện hoàn thiện (high-fidelity): màu sắc, typography, spacing, component, responsive breakpoint, animation. Bộ design system + asset.
Phụ trách
UI/UX Designer
Đầu vào
Wireframe, FSD.
Đầu ra
File Figma + design tokens + assets export (icon, image).
4.5

API Specification / Interface Design

Đặc tả API & Interface
Bắt buộc
Mục đích
Chi tiết các endpoint API: URL, method, request/response schema, status code, authentication. Theo chuẩn OpenAPI/Swagger.
Phụ trách
Backend Tech Lead
Đầu vào
LLD, HLD.
Đầu ra
OpenAPI YAML/JSON + Swagger UI hoặc tài liệu Postman collection.
4.6

Security Design Document

Tài liệu thiết kế bảo mật
Khuyến nghị
Mục đích
Xác định mô hình xác thực/phân quyền (RBAC, OAuth2, JWT…), mã hóa dữ liệu, bảo vệ OWASP Top 10, audit log, quản lý secret.
Phụ trách
Security Engineer / Tech Lead
Đầu vào
NFR, HLD.
Đầu ra
Security Design + Threat Model.
4.7

Integration Design Document

Tài liệu thiết kế tích hợp
Tùy dự án
Mục đích
Mô tả cách tích hợp với hệ thống bên thứ 3 (payment, ERP, SSO, SMS…): giao thức, luồng dữ liệu, xử lý lỗi, retry strategy.
Phụ trách
Solution Architect
Đầu vào
HLD, API spec từ bên thứ 3.
Đầu ra
Integration Design + Sequence Diagram.
GIAI ĐOẠN 5 – LẬP KẾ HOẠCH & CHUẨN BỊ DEV (Planning & Pre-Development)
Mục tiêu: Chuẩn bị kế hoạch chi tiết, môi trường làm việc và các quy chuẩn kỹ thuật để Dev team có thể bắt tay vào code.
5.1

Project Plan / Master Plan

Kế hoạch tổng thể dự án
Bắt buộc
Mục đích
Lịch trình chi tiết theo Gantt: milestone, deliverable, dependency, deadline, người chịu trách nhiệm. Là baseline để theo dõi tiến độ.
Phụ trách
PM
Đầu vào
WBS, Effort Estimation.
Đầu ra
MS Project / Excel Gantt được khách hàng phê duyệt.
5.2

Work Breakdown Structure (WBS)

Cấu trúc phân rã công việc
Bắt buộc
Mục đích
Phân rã toàn bộ công việc dự án thành các work package nhỏ, có thể giao việc và ước lượng được.
Phụ trách
PM
Đầu vào
Project Charter, SRS.
Đầu ra
Cây WBS (mind map / list).
5.3

Effort Estimation

Bảng ước lượng nhân lực
Bắt buộc
Mục đích
Ước lượng man-days/man-hours cho từng task theo Function Point, Use Case Point hoặc Three-Point Estimation.
Phụ trách
Tech Lead + PM
Đầu vào
WBS, FSD.
Đầu ra
Bảng estimation (Excel) có buffer rủi ro.
5.4

Risk Management Plan & Risk Register

Kế hoạch & Sổ đăng ký rủi ro
Bắt buộc
Mục đích
Liệt kê rủi ro tiềm ẩn (kỹ thuật, nhân sự, khách hàng, vendor), đánh giá xác suất × ảnh hưởng, kế hoạch ứng phó (avoid/mitigate/transfer/accept).
Phụ trách
PM
Đầu vào
Project Charter, SRS.
Đầu ra
Risk Register (Excel) có owner và trigger.
5.5

Communication Plan

Kế hoạch giao tiếp
Khuyến nghị
Mục đích
Quy định kênh & tần suất giao tiếp: daily, weekly meeting, status report, escalation matrix. Tránh thông tin lạc hoặc đứt đoạn.
Phụ trách
PM
Đầu vào
Stakeholder Register.
Đầu ra
Bảng Communication Matrix.
5.6

Quality Assurance Plan

Kế hoạch đảm bảo chất lượng
Bắt buộc
Mục đích
Quy định tiêu chuẩn chất lượng (ISO/CMMI), quy trình review code, định nghĩa Done, các checkpoint kiểm tra chất lượng.
Phụ trách
QA Lead
Đầu vào
NFR, Project Plan.
Đầu ra
QA Plan có metric (defect density, code coverage…).
5.7

Test Strategy & Master Test Plan

Chiến lược & kế hoạch kiểm thử
Bắt buộc
Mục đích
Xác định phạm vi test, các loại test (unit, integration, system, UAT, performance, security), môi trường test, công cụ, tiêu chí pass/fail.
Phụ trách
QA Lead / Test Manager
Đầu vào
SRS, NFR, RTM.
Đầu ra
Test Strategy + Master Test Plan.
5.8

Configuration Management Plan

Kế hoạch quản lý cấu hình
Bắt buộc
Mục đích
Quy định nguyên tắc quản lý source code (Git branching: GitFlow/Trunk-based), versioning, release naming, môi trường (Dev/SIT/UAT/Prod), CI/CD pipeline.
Phụ trách
DevOps / Tech Lead
Đầu vào
HLD.
Đầu ra
Config Management Plan + sơ đồ branching.
5.9

Coding Standards & Guidelines

Tiêu chuẩn lập trình & quy tắc code
Bắt buộc
Mục đích
Quy định convention đặt tên, cấu trúc thư mục, format code, comment, log, exception handling, review checklist. Đồng nhất chất lượng code toàn team.
Phụ trách
Tech Lead
Đầu vào
Công nghệ đã chọn ở HLD.
Đầu ra
Coding Standards Document + linter config (ESLint, Checkstyle…).
5.10

Development Environment Setup Document

Hướng dẫn cài đặt môi trường Dev
Bắt buộc
Mục đích
Hướng dẫn dev mới setup máy: tool, IDE, dependency, biến môi trường, kết nối DB, chạy local. Giúp onboarding nhanh.
Phụ trách
DevOps / Tech Lead
Đầu vào
HLD, Config Management Plan.
Đầu ra
README/Confluence + Docker compose / script tự động.
5.11

Dev Kick-off Document

Tài liệu khởi động giai đoạn Dev
Bắt buộc
Mục đích
Tài liệu/slide khởi động pha Dev: review SRS, design, plan, phân công module, milestone, expectation. Đảm bảo dev hiểu rõ trước khi viết dòng code đầu tiên.
Phụ trách
PM + Tech Lead
Đầu vào
Tất cả tài liệu trên.
Đầu ra
Slide kick-off + biên bản phân công.

4Lời khuyên khi triển khai tại ITO

Tailoring theo quy mô dự án

Không phải dự án nào cũng cần đủ 33 tài liệu. Với dự án nhỏ (< 3 tháng, < 5 người), có thể gộp BRD + SRS, gộp HLD + LLD, lược bỏ Security/Integration Doc nếu không có yêu cầu đặc thù.

Sign-off rõ ràng từng baseline

Các tài liệu thuộc nhóm Bắt buộc (Project Charter, BRD, SRS, FSD, HLD, Test Plan) phải có ký xác nhận từ khách hàng/Sponsor trước khi chuyển giai đoạn. Đây là cơ sở kiểm soát Change Request.

Quản lý phiên bản & lưu trữ

Toàn bộ tài liệu lưu trên Confluence/SharePoint với quy ước version (v0.1 draft → v1.0 baseline). Mọi thay đổi sau baseline phải đi qua quy trình Change Request.

Sử dụng template chuẩn của ITO

PMO duy trì bộ template (Word/Excel) cho từng tài liệu nói trên. Các dự án phải dùng template chuẩn để đảm bảo consistency và rút ngắn thời gian soạn.

Đầu vào của Dev = Đầu ra của 5 giai đoạn này

Dự án chỉ nên start Dev khi đã có đủ: SRS + FSD baseline, HLD + LLD, DB Design, API Spec, UI/UX final, Project Plan, WBS, Test Plan, Coding Standards và Dev Environment.

Áp dụng RTM xuyên suốt vòng đời

RTM phải được khởi tạo từ giai đoạn 3 và cập nhật liên tục đến UAT. Đây là công cụ duy nhất giúp PM/QA chắc chắn không bỏ sót yêu cầu.

5Điều chỉnh quy trình tài liệu khi có AI tham gia

⚡

Tài liệu KHÔNG mất đi vai trò – mà còn quan trọng hơn

Vì chúng chính là prompt cho AI sinh ra code, test, thiết kế. Chất lượng output AI tỉ lệ thuận với độ chính xác của tài liệu đầu vào.

5.1. Bốn nguyên tắc nền tảng

Tài liệu là prompt cho AI

SRS, FSD, LLD, API Spec không chỉ để con người đọc – mà còn là input để AI generate code/test. Càng chi tiết và phi-mơ-hồ, output AI càng đúng.

Human-in-the-loop bắt buộc

Mọi output do AI tạo (code, tài liệu, test case) phải được review bởi engineer/BA có trách nhiệm trước khi commit/baseline.

Bảo vệ dữ liệu & IP

Không đưa thông tin khách hàng/NDA, source code độc quyền, secret… lên AI public. Chỉ dùng AI đã được ITO phê duyệt và có hợp đồng DPA.

Round-trip tài liệu ↔ code

Khi tài liệu thay đổi → AI regen code; khi code thay đổi → AI update tài liệu. PMO duy trì single source of truth (SRS + OpenAPI).

5.2. Tài liệu hiện có cần được làm chặt hơn

Tài liệuĐiều chỉnh
SRS / FSD / NFRViết theo Given-When-Then hoặc EARS để AI parse dễ. Tránh từ mơ hồ ("nhanh", "thân thiện"). Mỗi requirement có ID duy nhất và acceptance criteria đo đếm được.
HLD / LLDBổ sung Architecture Decision Record (ADR) để AI hiểu lý do chọn công nghệ. Diagram xuất bằng PlantUML/Mermaid (text-based) thay vì ảnh.
API SpecificationBắt buộc theo chuẩn OpenAPI 3.x (file YAML/JSON), kèm example. AI có thể gen client SDK, mock server, test case từ file này.
Database DesignSchema viết bằng SQL DDL hoặc Prisma/dbml; data dictionary có comment trên mỗi cột để AI đoán đúng business meaning.
Coding StandardsBổ sung mục AI-generated code rules: cấm copy nguyên block AI, bắt buộc test, format theo linter, kiểm tra license/SBOM.
RTMMở rộng cột AI-Assisted: ghi nhận task nào do AI tham gia, prompt được dùng, phục vụ audit & retrospective.

Giải thích nhanh 6 thuật ngữ ở mục 5.2

Given-When-Then
Cú pháp BDD viết yêu cầu theo 3 mệnh đề: Given (điều kiện ban đầu) – When (hành động xảy ra) – Then (kết quả mong đợi). Mỗi kịch bản chạy được trực tiếp bằng Cucumber/SpecFlow → vừa là spec, vừa là test.
EARS (Easy Approach to Requirements Syntax)
Bộ 5 mẫu câu chuẩn (When / While / Where / If-Then / Ubiquitous) để viết yêu cầu phần mềm. Mỗi yêu cầu = một mệnh đề "shall" đo đếm được, có ID duy nhất để truy vết. Áp dụng cho SRS, FSD theo chuẩn IEEE 830.
Architecture Decision Record (ADR)
Tài liệu ngắn (1–2 trang) ghi lại một quyết định kiến trúc: bối cảnh, các phương án, lý do chọn, hệ quả. Lưu cùng source code, có version. Giúp team mới (và AI) hiểu được "tại sao chọn React, không chọn Vue".
OpenAPI 3.x (trước là Swagger)
Chuẩn quốc tế mô tả REST API bằng file YAML/JSON: endpoint, method, request/response schema, status code, auth. Từ một file OpenAPI có thể auto-gen client SDK, mock server, test case, tài liệu Swagger UI – cực mạnh khi kết hợp AI.
AI-generated code rules
Quy tắc bổ sung trong Coding Standards dành riêng cho code do AI sinh ra: cấm copy nguyên block không hiểu, bắt buộc viết unit test, chạy SBOM/license scan, format theo linter, ghi nguồn prompt trong commit message.
AI-Assisted (cột mới trong RTM)
Cột mới trong Requirements Traceability Matrix đánh dấu task nào có sự tham gia của AI (code, test, doc), kèm tên/version prompt được dùng. Phục vụ audit, đo lường hiệu quả AI và xử lý khi có vấn đề bản quyền.

5.3. 5 tài liệu MỚI cần bổ sung

N1

AI Usage Policy

Quy định sử dụng AI

Quy định danh mục AI tools được phép, phạm vi dữ liệu cho phép upload, cách xử lý dữ liệu nhạy cảm, hình thức kỷ luật khi vi phạm. Áp dụng toàn công ty.

Phụ trách: CTO + Legal + Security
N2

Prompt Library

Thư viện prompt chuẩn

Tập hợp prompt đã kiểm thử cho từng tác vụ: gen SRS từ MoM, gen test case từ FSD, gen code từ LLD, code review… Có versioning và ví dụ output mẫu.

Phụ trách: AI Champion + Tech Lead
N3

AI Output Review Checklist

Checklist review output AI

Tiêu chí review code/tài liệu do AI sinh: tính đúng đắn, hallucination, security (OWASP), license/IP, performance, test coverage. Bắt buộc trước khi merge PR.

Phụ trách: QA Lead + Tech Lead
N4

Data & IP Risk Assessment

Đánh giá rủi ro dữ liệu/IP

Đánh giá theo dự án: dữ liệu nào được phép gửi lên AI cloud, công cụ AI nào tuân thủ GDPR/ISO 27001, biện pháp bảo vệ (private endpoint, on-prem LLM…).

Phụ trách: Security + DPO
N5

AI Tooling Stack Doc

Tài liệu hệ AI tools dự án

Liệt kê các AI tool được dùng trong dự án (IDE plugin, agent, test gen…), version, license, account/license owner, hướng dẫn cấu hình SSO/bảo mật.

Phụ trách: DevOps + Tech Lead

5.4. Tài liệu có thể giảm tải hoặc tự động hóa

Tài liệuCách AI hỗ trợ
GlossaryAI tự trích xuất thuật ngữ từ MoM, BRD, SRS và đề xuất định nghĩa thống nhất – BA chỉ duyệt thay vì viết từ đầu.
As-Is Survey ReportAI ghi âm + transcribe + tóm tắt phỏng vấn khách hàng → BA chỉ chỉnh sửa, validate.
UML / BPMN diagramAI sinh PlantUML/Mermaid trực tiếp từ SRS – không cần vẽ thủ công bằng Visio/Draw.io.
Test Cases (initial)AI sinh test case từ FSD/acceptance criteria; QA review và bổ sung edge case.
Meeting MinutesAI note-taker (Otter, Fireflies, Zoom AI) tự sinh MoM, action items – BA chỉ verify.

5.5. Vai trò mới trong team dự án

Vai tròTrách nhiệm chính
AI Champion
Thường là Tech Lead/Senior		Đầu mối về AI trong dự án: chọn tool, đào tạo, audit prompt, đo lường hiệu quả (thời gian tiết kiệm, defect rate). Báo cáo PMO hàng tháng.
Prompt Engineer / BA-AIBA truyền thống nâng cấp – ngoài viết SRS còn viết prompt template, đảm bảo prompt tạo ra output đúng spec.
AI ReviewerVai trò bổ sung cho QA: kiểm tra mọi output AI (code, doc, test) theo checklist N3 trước khi đưa vào baseline.
Data Privacy Officer (DPO)Phê duyệt việc gửi dữ liệu lên AI cloud, đảm bảo tuân thủ NDA, GDPR, ISO 27001.

5.6. Rủi ro cần kiểm soát

1

Hallucination (AI bịa)

AI có thể tạo ra code/spec sai sự thật nhưng nghe rất thuyết phục. Biện pháp: human review bắt buộc, unit test phủ ≥ 80%, đối chiếu với SRS gốc.

2

Vi phạm IP / License

Code AI gen có thể trùng với open-source GPL/AGPL gây vi phạm bản quyền. Biện pháp: chạy SBOM scan (Snyk, Black Duck), cấm code AI ở module độc quyền của khách hàng.

3

Rò rỉ dữ liệu nhạy cảm

Đưa NDA, source code khách hàng, PII lên AI public là vi phạm hợp đồng. Biện pháp: chỉ dùng AI có DPA/đặt on-prem, lọc dữ liệu trước khi prompt, log mọi prompt.

4

Phụ thuộc & suy giảm kỹ năng

Junior dev quá phụ thuộc AI → mất khả năng debug, thiết kế. Biện pháp: code-without-AI day định kỳ, mentoring, evaluation tay nghề.

5

Bias & Fairness

AI có thể sinh ra logic phân biệt đối xử trong các module xét duyệt (HR, tín dụng…). Biện pháp: bổ sung fairness test trong Test Plan, review bởi domain expert.

5.7. Bộ tài liệu ITO sau khi nâng cấp

LoạiTrước AISau AI
Tổng tài liệu3338 (+5 tài liệu mới về AI)
Bắt buộc2629 (thêm Policy, Checklist, Risk Assessment)
Khuyến nghị68 (thêm Prompt Library, Tooling Stack)
Vai trò mới04 (AI Champion, Prompt Eng, AI Reviewer, DPO)
– Hết –