Tài Liệu Yêu Cầu SRS & FRS: 6 Bước Dùng AI Viết Nhanh Cho Business Analyst

Biên soạn bởi đội ngũ giảng viên khóa IT Business Analyst tại Cole.

Viết tài liệu yêu cầu SRS (Software Requirements Specification) và FRS (Functional Requirements Specification) là một trong những việc tốn thời gian nhất của Business Analyst: gom thông tin từ hàng chục buổi họp, chuẩn hóa câu chữ, viết tiêu chí nghiệm thu, rồi cập nhật liên tục mỗi khi stakeholder đổi ý. Đây cũng chính là nơi AI tạo ra khác biệt rõ rệt nhất.

AI không thay thế vai trò của BA, nhưng nếu dùng đúng cách, nó trở thành một “co-writer” giúp bạn rút ngắn đáng kể thời gian soạn bản nháp để dành sức cho phần giá trị nhất: làm rõ nghiệp vụ và thống nhất giải pháp với các bên. Bài viết này tổng hợp quy trình, prompt mẫu, ví dụ thực tế và checklist kiểm soát chất lượng mà đội ngũ Cole đang áp dụng và giảng dạy.

Tóm tắt nhanh: AI hỗ trợ BA viết tài liệu yêu cầu SRS/FRS qua 4 việc chính: (1) dựng khung SRS chuẩn IEEE trong vài giây, (2) trích xuất yêu cầu chức năng và phi chức năng từ transcript cuộc họp, (3) chuẩn hóa câu chữ và sinh Acceptance Criteria, (4) chi tiết hóa từ User Story sang FRS theo module. BA vẫn là người chịu trách nhiệm cuối cùng về tính đúng, đủ và nhất quán của tài liệu.

Tài liệu yêu cầu SRS là gì? Khác gì BRD và FRS?

Tài liệu yêu cầu SRS là tài liệu mô tả đầy đủ hệ thống phần mềm cần làm gì (yêu cầu chức năng) và phải đạt chất lượng ra sao (yêu cầu phi chức năng như hiệu năng, bảo mật, khả dụng), cùng các ràng buộc, giả định và giao diện với hệ thống khác. SRS là “hợp đồng” chung giữa business, đội phát triển và đội kiểm thử.

Trong dự án phần mềm, SRS thường đi cùng hai tài liệu khác:

• BRD (Business Requirements Document): trả lời câu hỏi vì sao làm dự án: mục tiêu kinh doanh, phạm vi, KPI, stakeholder.
• SRS: trả lời hệ thống là gì: toàn bộ yêu cầu chức năng, phi chức năng và ràng buộc.
• FRS (Functional Requirements Specification): trả lời từng chức năng hoạt động ra sao: input, xử lý, output, business rule, thông báo lỗi.

Nhiều doanh nghiệp gộp SRS và FRS làm một, hoặc thay bằng Product Backlog và User Story trong mô hình Agile. Dù tên gọi khác nhau, bản chất vẫn là mô tả yêu cầu đủ rõ để đội phát triển xây dựng và đội QA kiểm thử được. Bạn có thể đọc thêm bài phân biệt BRD và SRS trong dự án phần mềm để nắm rõ hơn ranh giới giữa hai tài liệu.

Chuẩn quốc tế cho tài liệu yêu cầu SRS

Khung SRS phổ biến nhất xuất phát từ IEEE 830-1998 (Recommended Practice for Software Requirements Specifications). Chuẩn này hiện đã được thay thế bởi ISO/IEC/IEEE 29148:2018 về kỹ thuật yêu cầu (requirements engineering), nhưng cấu trúc mục lục của IEEE 830 vẫn được rất nhiều dự án tại Việt Nam sử dụng vì dễ áp dụng.

Theo IEEE 830, một SRS tốt cần có 8 đặc tính: đúng (correct), rõ ràng không mơ hồ (unambiguous), đầy đủ (complete), nhất quán (consistent), được xếp hạng ưu tiên (ranked), kiểm chứng được (verifiable), dễ sửa đổi (modifiable) và truy vết được (traceable). Đây cũng là bộ tiêu chí bạn nên dùng để kiểm tra output của AI ở phần sau.

AI giúp gì khi viết tài liệu yêu cầu SRS & FRS?

Dựa trên kinh nghiệm triển khai và giảng dạy, AI phát huy tốt nhất ở những việc có cấu trúc rõ và lặp lại nhiều lần:

Nói cách khác, AI giúp bạn đi từ “trang giấy trắng” đến bản nháp 60–70% nhanh hơn nhiều, còn 30–40% cuối cùng (độ chính xác nghiệp vụ, sự đồng thuận của stakeholder) vẫn phụ thuộc vào năng lực của BA.

Quy trình 6 bước dùng AI soạn tài liệu yêu cầu SRS & FRS

Để output của AI đạt chất lượng “sẵn sàng trình ký”, hãy làm theo quy trình dưới đây thay vì hỏi AI một câu chung chung.

Bước 1: Chuẩn bị “nguyên liệu” đầu vào cho tài liệu yêu cầu SRS

AI chỉ thông minh khi có đủ ngữ cảnh. Trước khi mở công cụ AI, hãy tập hợp:

• Transcript phỏng vấn stakeholder hoặc biên bản họp (meeting notes).
• BRD, tài liệu hệ thống cũ (legacy documents), quy trình nghiệp vụ hiện tại (AS-IS).
• Danh sách User Story hoặc yêu cầu sơ khai.
• Thuật ngữ nghiệp vụ (glossary) của doanh nghiệp.

Mẹo: chuẩn hóa transcript theo định dạng [Vai trò] – [Nội dung] (ví dụ: [Trưởng phòng CSKH] – Khách phải xem được lịch sử đơn 12 tháng) để AI không nhầm ai đang yêu cầu gì. Nếu bạn chưa quen kỹ thuật thu thập yêu cầu, xem thêm bài Elicitation trong Business Analysis.

Bước 2: Viết prompt theo công thức RICH

Thay vì ra lệnh chung chung, dùng công thức RICH để AI hiểu đúng vai trò và định dạng cần trả về:

• Role (Vai trò): “Bạn là Senior Business Analyst 10 năm kinh nghiệm trong mảng e-commerce.”
• Instruction (Chỉ dẫn): “Hãy trích xuất các yêu cầu chức năng cho tính năng thanh toán từ transcript dưới đây.”
• Context (Ngữ cảnh): “Ứng dụng bán lẻ trên mobile, khoảng 50.000 người dùng, tích hợp cổng thanh toán nội địa và ví điện tử.”
• Hint (Gợi ý định dạng): “Trình bày dạng bảng gồm ID, Tên yêu cầu, Mô tả, Mức ưu tiên (MoSCoW), Nguồn (ai yêu cầu).”

Bước 3: Dựng khung tài liệu yêu cầu SRS và danh sách yêu cầu sơ bộ

Yêu cầu AI dựng “khung xương” tài liệu yêu cầu SRS theo IEEE 830 trước, sau đó mới điền từng mục. Với phần yêu cầu chức năng, yêu cầu AI viết theo mẫu câu chuẩn “Hệ thống phải…” (The system shall…) và gán ID duy nhất (FR-01, FR-02…) để phục vụ truy vết về sau.

Bước 4: Tinh chỉnh câu chữ và tạo Acceptance Criteria

Đừng dừng ở bản nháp đầu tiên. Hãy yêu cầu AI:

• Viết lại các yêu cầu theo mẫu câu EARS (xem phần dưới) để loại bỏ mơ hồ.
• Viết 2–4 Acceptance Criteria dạng Given / When / Then cho mỗi yêu cầu.
• Liệt kê yêu cầu phi chức năng liên quan: hiệu năng, bảo mật, khả dụng, khả năng mở rộng, tuân thủ pháp lý.
• Chỉ ra các câu hỏi còn bỏ ngỏ cần hỏi lại stakeholder (open questions).

Bước 5: Chi tiết hóa FRS theo từng module

Với mỗi module, yêu cầu AI mô tả luồng Input → Processing → Output: trường dữ liệu đầu vào (kiểu, bắt buộc hay không, validation), logic xử lý và business rule, kết quả hiển thị, thông báo lỗi và các luồng ngoại lệ. Bạn cũng có thể yêu cầu AI sinh sơ đồ luồng bằng cú pháp Mermaid hoặc PlantUML để dán vào Confluence.

Bước 6: Review 3 vòng và baseline tài liệu

Dùng bản thảo tài liệu yêu cầu SRS từ AI làm cơ sở thảo luận, không phải bản chốt. Quy trình review nên gồm: BA tự review logic nghiệp vụ → Tech Lead review tính khả thi kỹ thuật → Stakeholder xác nhận nghiệp vụ. Khi có feedback, đưa feedback vào AI để cập nhật đồng loạt thay vì sửa tay từng trang, sau đó đánh số phiên bản và baseline tài liệu.

Viết yêu cầu rõ ràng hơn với mẫu câu EARS

Lỗi phổ biến nhất của tài liệu yêu cầu SRS, kể cả do người hay AI viết, là câu mơ hồ như “hệ thống phải nhanh”, “giao diện thân thiện”. EARS (Easy Approach to Requirements Syntax) do Alistair Mavin cùng cộng sự phát triển là bộ 5 mẫu câu giúp yêu cầu nhất quán và kiểm thử được. Bạn chỉ cần thêm vào prompt: “Viết lại các yêu cầu theo mẫu câu EARS.”

Ví dụ thực tế: từ biên bản họp đến tài liệu yêu cầu SRS

Giả sử bạn là BA của dự án app đặt lịch khám cho một phòng khám. Sau buổi họp, bạn cần chuyển đoạn biên bản sau thành tài liệu yêu cầu SRS:

[Giám đốc phòng khám] – Bệnh nhân phải đặt được lịch khám online, chọn bác sĩ và khung giờ.
[Lễ tân] – Hay bị đặt trùng giờ, nhiều người đặt xong không đến.
[Giám đốc phòng khám] – Nhắc lịch trước 1 ngày. Nếu hủy thì phải hủy trước 2 tiếng.
[IT] – Hệ thống cũ chỉ chịu được khoảng 200 người dùng cùng lúc.

Prompt gợi ý:

Bạn là Senior Business Analyst trong lĩnh vực y tế.
Từ biên bản họp dưới đây, hãy:
1. Trích xuất yêu cầu chức năng (FR) và phi chức năng (NFR), gán ID.
2. Viết mỗi yêu cầu theo mẫu câu EARS.
3. Với mỗi FR, viết 2-3 Acceptance Criteria dạng Given/When/Then.
4. Liệt kê các câu hỏi còn bỏ ngỏ cần hỏi lại stakeholder.
Trình bày dạng bảng: ID | Yêu cầu | Loại | Ưu tiên (MoSCoW) | Nguồn.
Không tự bịa thông tin không có trong biên bản; nếu thiếu, ghi vào mục câu hỏi.
[dán biên bản]

Kết quả AI trả về (đã được BA rà soát):

Acceptance Criteria cho FR-02:

Given khung giờ 9:00 ngày 15/10 của bác sĩ A còn trống
When bệnh nhân X xác nhận đặt khung giờ này
Then khung giờ 9:00 không còn hiển thị với bệnh nhân khác
And nếu hai người xác nhận cùng lúc, chỉ yêu cầu đến trước được ghi nhận, người sau nhận thông báo chọn giờ khác

Câu hỏi bỏ ngỏ AI gợi ý: nhắc lịch qua kênh nào (SMS, Zalo, email)? Có thu phí đặt cọc để giảm tình trạng “đặt rồi không đến” không? Con số 500 người dùng đồng thời dựa trên cơ sở nào?

Lưu ý con số “500 người dùng đồng thời” ở NFR-01 là AI tự đề xuất vì biên bản chỉ nói hệ thống cũ chịu được 200. Đây chính là loại chi tiết BA bắt buộc phải xác minh với Tech Lead trước khi đưa vào tài liệu chính thức.

Thư viện prompt mẫu cho tài liệu yêu cầu SRS & FRS

Dưới đây là các prompt có thể dùng ngay. Bạn có thể viết bằng tiếng Việt hoặc tiếng Anh; với tài liệu gửi đối tác nước ngoài, nên yêu cầu AI xuất song ngữ.

1. Dựng khung tài liệu SRS

Tạo mục lục chi tiết cho tài liệu SRS theo IEEE 830 cho hệ thống [quản lý kho cho chuỗi bán lẻ 50 cửa hàng].
Với mỗi mục, ghi 1-2 câu mô tả nội dung cần có và câu hỏi BA cần thu thập.

2. Trích xuất yêu cầu từ phỏng vấn

Act as a Business Analyst. Analyze the following interview excerpt and identify functional requirements.
Write each requirement as "The system shall..." with a unique ID and the stakeholder who raised it.
List anything unclear as open questions instead of assuming.

3. Soạn phần Assumptions & Constraints

Với ứng dụng đặt đồ ăn trên mobile, liệt kê 5 giả định (assumptions) và 5 ràng buộc (constraints)
về công nghệ, ngân sách, pháp lý và kỳ vọng người dùng, trình bày theo định dạng SRS chuyên nghiệp.

4. Viết FRS cho một tính năng

Viết FRS chi tiết cho tính năng "Tìm kiếm nâng cao". Bao gồm:
- Bảng trường input (tên, kiểu dữ liệu, bắt buộc, validation)
- Logic xử lý và business rule
- Quy tắc hiển thị kết quả, phân trang, sắp xếp
- Thông báo lỗi và luồng ngoại lệ

5. Kiểm tra chất lượng tài liệu

Đóng vai QA Lead. Review danh sách yêu cầu dưới đây theo 8 tiêu chí của IEEE 830
(correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, traceable).
Chỉ ra yêu cầu vi phạm, lý do và đề xuất cách viết lại.

6. Tạo ma trận truy vết

Từ danh sách User Story và danh sách FR dưới đây, tạo Requirements Traceability Matrix
dạng bảng: User Story ID | FR ID | Test Case gợi ý. Đánh dấu User Story chưa có FR tương ứng.

Cần thêm nhiều mẫu hơn? Tham khảo bộ 30 prompt template cho BA/PO.

Nên dùng công cụ AI nào để viết tài liệu yêu cầu SRS?

Các trợ lý AI phổ biến như ChatGPT, Claude, Gemini hay Microsoft Copilot đều làm tốt các bước trên. Khác biệt chủ yếu nằm ở độ dài ngữ cảnh (đọc được bao nhiêu trang tài liệu một lúc), khả năng tích hợp với công cụ bạn đang dùng (Word, Google Docs, Confluence, Jira) và chính sách dữ liệu của gói doanh nghiệp. Lời khuyên thực tế:

• Ưu tiên công cụ doanh nghiệp đã phê duyệt, có cam kết không dùng dữ liệu của bạn để huấn luyện mô hình.
• Với tài liệu dài (BRD, transcript nhiều buổi), chọn công cụ có cửa sổ ngữ cảnh lớn và hỗ trợ tải file.
• Tạo sẵn “dự án” hoặc “custom instruction” chứa glossary và template tài liệu yêu cầu SRS của công ty để AI dùng nhất quán.

Xem so sánh chi tiết trong bài BA/PO thời AI nên dùng ChatGPT, Gemini hay DeepSeek.

Checklist kiểm soát chất lượng output từ AI

AI có thể “hallucinate”, tức tự suy diễn thông tin không có trong input. Trước khi gửi tài liệu yêu cầu SRS cho stakeholder, hãy kiểm tra:

1. Mỗi yêu cầu có nguồn: truy được về một stakeholder, biên bản họp hoặc tài liệu cụ thể.
2. Không còn từ mơ hồ: tìm và thay các từ “nhanh”, “thân thiện”, “có thể”, “thường”, “v.v.” bằng con số hoặc điều kiện đo được.
3. Mỗi yêu cầu kiểm thử được: có ít nhất một Acceptance Criteria rõ ràng.
4. Không mâu thuẫn: không có hai yêu cầu trái ngược nhau về cùng một luồng.
5. Con số do người chốt: mọi chỉ số NFR (thời gian phản hồi, số người dùng, uptime) đều được Tech Lead xác nhận.
6. Định dạng dùng được ngay: bảng hoặc Markdown để dán vào Jira/Confluence.
7. Có đánh số phiên bản và lịch sử thay đổi.

Hạn chế của AI khi viết tài liệu yêu cầu SRS và cách khắc phục

• Thiếu yêu cầu ngầm: AI không biết những gì stakeholder “quên” nói. Dùng checklist theo domain (thanh toán, phân quyền, báo cáo, audit log…) để bổ sung.
• Bảo mật dữ liệu: không đưa thông tin khách hàng, dữ liệu cá nhân hay bí mật kinh doanh lên công cụ AI công cộng. Ẩn danh hóa tên riêng, số liệu nhạy cảm trước khi dùng. Tìm hiểu thêm tại bài bảo mật trong tư duy Business Analyst.
• Thiếu tư duy hệ thống: AI viết chi tiết từng phần tốt nhưng dễ mất kết nối giữa các module. BA cần giữ bức tranh tổng thể và ma trận truy vết.
• Tự tin sai: AI trình bày rất thuyết phục kể cả khi sai. Luôn yêu cầu AI ghi rõ phần nào là suy luận, phần nào có trong input.

Nếu bạn muốn so sánh với cách làm truyền thống, xem lại hướng dẫn chuẩn bị tài liệu SRS cho dự án phân tích nghiệp vụ.

Câu hỏi thường gặp

AI có thay thế được Business Analyst trong việc viết tài liệu yêu cầu SRS không?

Không. AI rút ngắn thời gian soạn thảo, nhưng việc hiểu nghiệp vụ, đặt câu hỏi đúng, cân bằng lợi ích các bên và chịu trách nhiệm về tài liệu vẫn là việc của BA. BA biết dùng AI sẽ có lợi thế lớn so với BA không dùng.

Viết tài liệu SRS bằng tiếng Việt hay tiếng Anh?

Tùy dự án. Tài liệu yêu cầu SRS cho dự án nội địa thường dùng tiếng Việt; dự án outsource hoặc có đối tác nước ngoài dùng tiếng Anh. AI hỗ trợ dịch và xuất song ngữ khá tốt, nhưng BA cần kiểm tra thuật ngữ chuyên ngành.

SRS có cần thiết trong dự án Agile không?

Agile ưu tiên User Story và Product Backlog, nhưng nhiều dự án (ngân hàng, bảo hiểm, chính phủ, outsource) vẫn yêu cầu SRS để làm cơ sở hợp đồng và nghiệm thu. AI giúp bạn chuyển đổi qua lại giữa User Story và SRS nhanh chóng.

Làm sao để AI không tự bịa yêu cầu trong tài liệu SRS?

Thêm vào prompt câu: “Chỉ dùng thông tin trong tài liệu được cung cấp; nếu thiếu, ghi vào mục câu hỏi bỏ ngỏ”, yêu cầu ghi nguồn cho từng yêu cầu và luôn review lại trước khi dùng.

Chuẩn nào nên dùng cho tài liệu yêu cầu SRS?

Khung IEEE 830 phổ biến và dễ áp dụng; ISO/IEC/IEEE 29148:2018 là chuẩn hiện hành và đầy đủ hơn. Quan trọng nhất là thống nhất một template trong công ty và dùng nó xuyên suốt.

Kết luận: BA biết dùng AI sẽ đi nhanh hơn

AI không thay thế Business Analyst, nhưng BA biết dùng AI sẽ làm việc nhanh và chất lượng hơn đáng kể. Làm chủ quy trình 6 bước, công thức prompt RICH, mẫu câu EARS và checklist chất lượng sẽ giúp bạn viết tài liệu yêu cầu SRS và FRS nhanh hơn, rõ ràng hơn, đồng thời có thêm thời gian cho việc tư vấn giải pháp và tạo giá trị thực sự cho sản phẩm.

👉 Muốn thực hành viết BRD, SRS, User Story và ứng dụng AI vào quy trình BA trên dự án thực tế? Tham khảo Khóa học IT Business Analyst 2026 thực chiến tại Cole: 25 buổi online qua Zoom, lộ trình từ cơ bản đến chuyên sâu, kèm dự án thực tế và hướng dẫn ứng dụng AI cho BA.

Tài liệu tham khảo

• ISO/IEC/IEEE 29148:2018 – Systems and software engineering – Life cycle processes – Requirements engineering.
• IEEE Std 830-1998 – IEEE Recommended Practice for Software Requirements Specifications.
• Alistair Mavin – EARS: Easy Approach to Requirements Syntax.
• IIBA – A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3.
• Xem thêm: Lộ trình BA từ A–Z và chi phí, chiến lược thi chứng chỉ IIBA.