Tuần 5 • Buổi 2 — BRD / PRD / SRS & Use Case

BRD / PRD / SRS & Use Case

Khi làm việc trên các dự án lớn hơn, user story chưa đủ — cần các tài liệu yêu cầu chính thức để làm cầu nối giữa business, product và engineering. Buổi này phân biệt rõ BRD, PRD, SRS và Use Case.

---

1. BRD — Business Requirements Document

BRD là gì? Tài liệu mô tả nhu cầu kinh doanh — vấn đề cần giải quyết, mục tiêu, phạm vi từ góc nhìn business. Không đi vào giải pháp kỹ thuật.

Ai viết? Business Analyst, phối hợp với Business Stakeholders.

Cấu trúc BRD điển hình:

1. Executive Summary — Tóm tắt vấn đề kinh doanh
Business Objectives — Mục tiêu đo được (OKR/KPI)
Scope — Phạm vi dự án (in scope / out of scope)
Stakeholders — Ai liên quan, ai quyết định
Business Requirements — Yêu cầu nghiệp vụ cấp cao
Constraints — Ràng buộc (ngân sách, thời gian, pháp lý)
Assumptions & Dependencies

Ví dụ thực tế — Dự án tích hợp ví điện tử vào app ngân hàng:

> Business Objective: Tăng tỷ lệ thanh toán số trong app lên 40% trong Q4 2026. > In Scope: Liên kết tài khoản ngân hàng với ví MoMo, ZaloPay. > Out of Scope: Tích hợp ví nước ngoài (PayPal, Stripe).

---

2. PRD — Product Requirements Document

PRD là gì? Tài liệu mô tả sản phẩm sẽ xây dựng để đáp ứng BRD — bao gồm tính năng, user flow, non-functional requirements, nhưng chưa đi vào kiến trúc kỹ thuật.

Ai viết? Product Manager / Product Owner, phối hợp với BA và Design.

Cấu trúc PRD điển hình:

1. Problem Statement — Vấn đề người dùng đang gặp
User Personas — Chân dung người dùng mục tiêu
Goals & Success Metrics — Chỉ số thành công
Features & User Stories — Danh sách tính năng + stories
User Flows / Wireframes — Luồng sử dụng
Non-Functional Requirements — Hiệu năng, bảo mật, khả năng mở rộng
Out of Scope
Timeline & Milestones

Ví dụ thực tế — PRD cho tính năng liên kết ví:

> User Persona: Nguyễn Lan, 28 tuổi, nhân viên văn phòng Hà Nội, dùng app ngân hàng 5-6 lần/tuần, muốn không phải chuyển app khi thanh toán. > Success Metric: 60% user liên kết ví thành công trong lần đầu mở tính năng.

---

3. SRS — Software Requirements Specification

SRS là gì? Tài liệu đặc tả yêu cầu kỹ thuật chi tiết nhất — mô tả chính xác hệ thống phải làm gì, theo chuẩn IEEE 830.

Ai viết? BA phối hợp chặt với Engineering Lead / Architect.

Cấu trúc SRS (IEEE 830):

1. Introduction
   1.1 Purpose
   1.2 Scope
   1.3 Definitions & Acronyms
Overall Description
   2.1 Product Perspective
   2.2 User Classes
   2.3 Assumptions
Specific Requirements
   3.1 Functional Requirements (FR-001, FR-002...)
   3.2 Non-Functional Requirements
   3.3 Interface Requirements (API, UI, Hardware)
Use Cases (cross-reference)
Appendices

Ví dụ FR trong SRS:

FR-012: Liên kết ví điện tử
Hệ thống PHẢI hiển thị danh sách ví được hỗ trợ (MoMo, ZaloPay, VNPay)
Hệ thống PHẢI xác thực OTP trong vòng 60 giây
Hệ thống PHẢI mã hóa token ví theo chuẩn AES-256
Hệ thống PHẢI ghi log mọi giao dịch liên ví trong 3 năm

Lưu ý từ khóa: PHẢI (SHALL/MUST) vs NÊN (SHOULD) vs CÓ THỂ (MAY).

---

4. So sánh BRD vs PRD vs SRS

5. Use Case — Tình huống sử dụng

Use Case mô tả tương tác giữa actor (người dùng hoặc hệ thống ngoài) với hệ thống để đạt một mục tiêu cụ thể.

Các thành phần:

• Actor: Ai tương tác với hệ thống (người dùng, hệ thống khác, timer)
• Use Case Name: Động từ + danh từ (Liên kết ví, Hủy giao dịch)
• Precondition: Điều kiện trước khi use case bắt đầu
• Main Flow: Luồng chính (happy path)
• Alternative Flow: Các lựa chọn khác vẫn thành công
• Exception Flow: Lỗi, hệ thống xử lý thế nào
• Postcondition: Trạng thái sau khi hoàn thành

Use Case: UC-007 Liên kết ví điện tử
Actor: Khách hàng cá nhân
Precondition:
  - User đã đăng nhập app ngân hàng
  - User chưa liên kết ví MoMo
Main Flow:
  1. User chọn 'Liên kết ví' trong menu Thanh toán
  2. Hệ thống hiển thị danh sách ví (MoMo, ZaloPay, VNPay)
  3. User chọn MoMo và nhập SĐT đăng ký MoMo
  4. Hệ thống gửi OTP đến SĐT của user
  5. User nhập OTP trong 60 giây
  6. Hệ thống xác thực và hiển thị 'Liên kết thành công'
  7. Ví MoMo xuất hiện trong danh sách thanh toán
Alternative Flow A: SĐT đã liên kết ví khác
  A1. Tại bước 3, nếu SĐT đã liên kết ZaloPay
  A2. Hệ thống hỏi 'Bạn có muốn thay thế liên kết hiện tại?'
  A3. User chọn Có → tiếp tục bước 4
  A4. User chọn Không → kết thúc, giữ liên kết cũ
Exception Flow E1: OTP hết hạn
  E1. User không nhập OTP trong 60 giây
  E2. Hệ thống hiển thị 'OTP đã hết hạn'
  E3. User có thể chọn Gửi lại OTP (tối đa 3 lần)
  E4. Sau 3 lần thất bại: khóa tính năng 30 phút
Exception Flow E2: Lỗi kết nối MoMo API
  E2a. Hệ thống hiển thị 'Dịch vụ tạm thời gián đoạn'
  E2b. Ghi log lỗi, không lưu trạng thái liên kết
Postcondition: Ví MoMo được liên kết, user có thể thanh toán qua ví

---

6. Khi nào dùng gì?

• Startup / Agile thuần: Dùng User Stories + PRD lite — bỏ qua BRD và SRS đầy đủ
• Doanh nghiệp lớn / Ngân hàng / Chính phủ: BRD → PRD → SRS — đủ bộ, có ký duyệt
• Outsource / Fixed-price contract: SRS là bắt buộc — làm cơ sở nghiệm thu
• Internal product team: PRD là xương sống, Use Cases thay thế SRS

Tự luyện

• Tìm một PRD open-source (gợi ý: Notion, Linear, Figma đều có mẫu). Đọc và chỉ ra: phần nào thuộc PRD, phần nào overlap với SRS?
• Viết một Use Case đầy đủ (main + 1 alternative + 1 exception) cho tình huống: 'Người dùng quên mật khẩu và reset qua email' trong một app HR nội bộ.
• Với dự án giả định trong lớp: quyết định nên dùng BRD hay PRD hay SRS — và giải thích lý do.