Bài 3 — Từ BRD sang SRS/FRS: viết yêu cầu chức năng chi tiết bằng AI

BRD nói nghiệp vụ cần gì. SRS/FRS (Software/Functional Requirements Specification) nói hệ thống phải làm gì để đáp ứng. Đây là bước "phóng to": mỗi Business Requirement (BR) nở ra thành nhiều Functional Requirement (FR) chi tiết, kèm luồng xử lý, quy tắc nghiệp vụ, xử lý lỗi. AI rất mạnh ở bước bung chi tiết này — nhưng cũng dễ bịa nhất, nên cần kiểm chặt.

Nguyên tắc chuyển đổi

Mỗi BR → nhiều FR. Ví dụ BR "tạo báo giá tự động" sẽ nở thành: FR chọn khách hàng, FR chọn sản phẩm, FR tính giá & chiết khấu, FR lưu nháp, FR gửi duyệt, FR xử lý khi vượt tồn kho... AI giúp bạn không bỏ sót các nhánh này.

Prompt mẫu: bung 1 BR thành các FR

Vai trò: Senior BA viết SRS.
Đầu vào: một Business Requirement.
Nhiệm vụ: Phân rã thành các Functional Requirement chi tiết.
Với mỗi FR, viết theo mẫu:
- ID: FR-<số>
- Mô tả: <hệ thống phải làm gì>
- Tiền điều kiện (Precondition)
- Luồng chính (Main flow, đánh bước 1..n)
- Luồng thay thế / lỗi (Alternate/Exception flow)
- Quy tắc nghiệp vụ (Business rules) nếu có
- Tiêu chí chấp nhận (Acceptance criteria, dạng Given/When/Then)

Quy tắc: KHÔNG bịa quy tắc nghiệp vụ chưa được nêu; đánh dấu
"[Giả định – cần xác nhận]" cho mọi suy diễn.

Business Requirement:
"""
BR-01: Là nhân viên Sales, tôi cần tạo báo giá tự động từ danh mục
sản phẩm để rút ngắn thời gian phản hồi khách hàng.
"""

Các bước làm

• Chọn từng BR một — đừng đổ cả BRD vào một lần, AI sẽ làm hời hợt. Bung từng cái để sâu.
• Chạy prompt phân rã cho BR đó.
• Rà luồng lỗi: phần AI hay làm tốt nhưng bạn phải kiểm — có xử lý hết trường hợp biên chưa (mất mạng, dữ liệu rỗng, quyền hạn)?
• Kiểm mọi "[Giả định – cần xác nhận]": biến chúng thành câu hỏi cho stakeholder hoặc dev.
• Kiểm tiêu chí chấp nhận: Given/When/Then phải kiểm thử được, không mơ hồ.
• Ghép các FR vào tài liệu SRS tổng, giữ đánh số nhất quán.

Ví dụ tiêu chí chấp nhận tốt vs xấu

• Xấu: "Báo giá phải nhanh." (không đo được)
• Tốt: "Given nhân viên đã chọn ≥1 sản phẩm, When bấm 'Tạo báo giá', Then hệ thống hiển thị tổng tiền đã tính chiết khấu trong ≤ 3 giây."

Bạn có thể yêu cầu AI viết lại mọi tiêu chí mơ hồ theo dạng đo được bằng prompt phụ: "Viết lại các acceptance criteria sau sao cho kiểm thử được, có ngưỡng cụ thể; chỗ nào thiếu ngưỡng hãy hỏi tôi."

Template FR tái sử dụng

FR-__ | <Tên chức năng>
Mô tả:
Actor:
Precondition:
Main flow:
  1.
  2.
Exception flow:
Business rules:
Acceptance criteria (Given/When/Then):
Ưu tiên: Must / Should / Could
Nguồn: BR-__

Giữ dòng Nguồn: BR-__ để mọi FR đều truy vết ngược được về nghiệp vụ — đây là công cụ chống "FR mồ côi" do AI bịa.

Checklist chất lượng FR

• [ ] Mỗi FR truy về được một BR (không FR mồ côi).
• [ ] Có luồng lỗi/thay thế, không chỉ happy path.
• [ ] Acceptance criteria đo được, có ngưỡng.
• [ ] Mọi giả định của AI đã được đánh dấu và xác nhận.
• [ ] Ưu tiên (MoSCoW) đã gán.

Sai lầm thường gặp

Ảo giác quy tắc nghiệp vụ: AI dễ tự chế ngưỡng ("chiết khấu tối đa 20%") nghe hợp lý nhưng sai với chính sách công ty bạn. Mọi con số phải do người xác nhận, không tin AI.

Bỏ luồng lỗi: nếu prompt không yêu cầu, AI thường chỉ viết happy path. Luôn bắt buộc exception flow.

Chi tiết giả: AI có thể viết bước rất chi tiết nhưng dựa trên hệ thống tưởng tượng khác công ty bạn. Đối chiếu với kiến trúc thật.

Rò rỉ: SRS có thể lộ logic nghiệp vụ cốt lõi (cách tính giá, thuật toán) — cân nhắc mức nhạy cảm trước khi đưa vào AI ngoài.

Phụ thuộc quá mức: SRS là hợp đồng giữa business và dev; sai sót do AI mà bạn không bắt được sẽ thành bug tốn kém. Bạn phải là người kiểm cuối.

Template sẵn dùng: SRS / FRD (Software Requirements Specification)

SOFTWARE REQUIREMENTS SPECIFICATION (SRS / FRD)
Hệ thống / Module: [Tên]        Người viết: [Tên]        Ngày: [ ]

>> SRS/FRD = "bản vẽ kỹ thuật cho thợ xây" — nói XÂY THẾ NÀO, chi tiết cho đội phát triển (dev).
   Thứ tự: BRD (doanh nghiệp cần gì) → PRD (sản phẩm trông thế nào) → SRS (kỹ thuật chi tiết).

1. MỤC ĐÍCH & PHẠM VI
   [Hệ thống/module này làm gì, ranh giới đến đâu]

2. THUẬT NGỮ & ĐỊNH NGHĨA
   - [Từ viết tắt, khái niệm nghiệp vụ]

3. YÊU CẦU CHỨC NĂNG CHI TIẾT
   FR-1: [Khi người dùng làm X → hệ thống phản hồi Y; nêu rõ điều kiện & ngoại lệ]
   FR-2: [ ]

4. YÊU CẦU DỮ LIỆU
   - [Bảng/thực thể, trường, kiểu dữ liệu, ràng buộc, quan hệ]

5. GIAO DIỆN & TÍCH HỢP
   - Màn hình: [ ]        - API bên ngoài: [ ]

6. YÊU CẦU PHI CHỨC NĂNG
   - Hiệu năng: [ ]     - Bảo mật: [ ]     - Khả dụng / tương thích: [ ]

7. RÀNG BUỘC & GIẢ ĐỊNH
   [ ]

8. TIÊU CHÍ NGHIỆM THU
   [Điều kiện để coi là "xong" và đạt]

=== MẸO ===
SRS để dev đọc là code được. Mỗi FR nên rõ điều kiện + ngoại lệ, kèm Acceptance Criteria (Given/When/Then).

Tải xuống: Word (.docx) · Markdown (.md) · Dùng công cụ tương tác