Quản lý Mẫu Kịch bản Telesale (Template)

I. Tổng quan

Mô tả ngắn gọn về bối cảnh và mục tiêu của tính năng.

1. Vấn đề

Trình bày khó khăn, nỗi đau (pain point) hiện tại của người dùng hoặc hệ thống.
Ví dụ: Người dùng đang phải xuất file Excel thủ công định kỳ mỗi cuối tháng làm mất nhiều thời gian và dễ sai sót.

2. Giải pháp

Cách tính năng này giải quyết vấn đề trên.
Ví dụ: Xây dựng tính năng tự động xuất và gửi báo cáo qua email vào ngày cuối cùng của tháng.

3. Đối tượng

4. Tầm nhìn/insight (Các vấn đề sẽ làm trong tương lai)

Định hướng mở rộng của tính năng sau này để Dev/Design thiết kế hệ thống có tính mở, có thể nâng cấp dễ dàng.
Ví dụ: Hiện tại chỉ hỗ trợ xuất Excel. Tương lai sẽ cho phép người dùng tự config thêm xuất định dạng PDF, CSV; cho phép tự cấu hình thời gian nhận linh hoạt hơn.

1. Danh sách tính năng

Liệt kê rành mạch các tính năng/chức năng con dưới dạng bullet point hoặc bảng.
Ví dụ:
- Tạo cấu hình gửi báo cáo tự động
- Sửa/Xóa cấu hình
- Bật/Tắt (Toggle) cấu hình

2. Đặc tả chi tiết Trình bày chi tiết cách hoạt động của tính năng.

Tùy vào độ phức tạp của tính năng, BA có thể chọn 1 trong 2 cách trình bày Use Case:

Cách 1: Gạch đầu dòng (Dùng cho tính năng đơn giản, flow ngắn, team Agile)

User story 1: Là một [Quản lý], tôi muốn [có thể tự thiết lập lịch gửi báo cáo] để [không phải làm thủ công].
- Use case 1.1 (Happy path - Lập lịch thành công): Nhập đủ Email và Tần suất “Hàng ngày” -> Bấm “Lưu” -> Hệ thống lưu hợp lệ -> Hiện popup thành công.
- Use case 1.2 (Exception - Lỗi giới hạn): Nhập 6 email (vượt quá 5) -> Bấm “Lưu” -> Hệ thống báo lỗi text đỏ: “Tối đa 5 email” -> Chặn không cho tạo.

Cách 2: Kẻ bảng Use Case Specification (Khuyên dùng cho tính năng phức tạp, nhiều logic rẽ nhánh)

Tên Use Case	[UC-01] Lập lịch gửi báo cáo thành công
Actor (Người dùng)	Quản lý chi nhánh, Admin
Pre-condition (Tiền ĐK)	User đã đăng nhập và có quyền truy cập trang Cấu hình.
Main Flow (Luồng chính)	1. User bấm “Tạo mới”. 2. Hệ thống hiển thị Form. 3. User điền Email hợp lệ (<= 5) và chọn Tần suất. 4. User click “Lưu”. 5. Hệ thống validate hợp lệ, lưu vào Database. 6. Hệ thống đóng popup báo “Thành công”.
Alternate/Exception Flow (Luồng rẽ nhánh/Ngoại lệ)	3a. User nhập sai định dạng Email: Khung đỏ báo lỗi. 3b. User nhập > 5 Email: Chặn “Tối đa 5 email”. 4a. User bấm “Hủy”: Đóng popup không lưu.
Post-condition (Hậu ĐK)	Một record mới được sinh ra trong DB table `reports`, hệ thống xếp lịch Cronjob tương ứng.

3. Danh sách nghiệp vụ

Các quy tắc kinh doanh (Business rules), công thức tính toán, hoặc điều kiện logic ràng buộc mã chặt chẽ.
Ví dụ:
- Mỗi cấu hình chỉ được phép nhập tối đa 5 email.
- Chỉ tài khoản đang ở trạng thái “Active” mới nhận được email.
- Nếu gửi báo cáo “Hàng ngày”, số liệu sẽ được chốt tính toán vào 23:59:59 của ngày hôm đó.

4. Giao diện

Link thiết kế Figma hoặc diễn giải bố cục UI, các component cần dùng.
Ví dụ: [Link Figma tính năng X]
Yêu cầu: Layout popup nằm giữa màn hình, ưu tiên sử dụng Dropdown select có thể search cho phần Chọn nhân viên.

(nếu có - tuỳ tính năng)

Các yêu cầu về mặt hệ thống như: hiệu năng, bảo mật, lưu vết (logging), mức độ đáp ứng (Rate Limit, Concurrent Users).
Ví dụ:
- API tạo báo cáo không được phản hồi (response time) quá 3 giây.
- Tính năng cần được ghi log lại mỗi khi có thao tác Xóa để audit (truy vết).
- Giao diện cần response tốt trên các thiết bị Mobile (màn hình dưới 768px).

Tính năng này có phụ thuộc vào sự thay đổi của một module/API nào khác đang có (hoặc của team khác) không? Tính năng này có tác động làm đổi luồng của một màn hình cũ nào không?
Ví dụ: Việc tạo tính năng này yêu cầu cập nhật lại Service Gửi Email hiện tại (do cần đính kèm file). Phụ thuộc vào màn Quản lý người dùng (User Management) để lấy danh sách email.

Dev định nghĩa chi tiết cấu trúc Request/Response giao tiếp giữa Frontend - Backend, hoặc Backend - Backend.

API 1: Tạo cấu hình gửi báo cáo (Ví dụ)

Request Body Payload:

{
  "emails": ["[email protected]", "[email protected]"],
  "frequency": "daily"
}

Response 200 (Thành công):

{
  "id": 1024,
  "message": "Tạo thành công"
}

Response 400 (Lỗi validate): {"error": "Số lượng email không vượt quá 5."}

Mô tả các trường hợp kiểm thử/nghiệm thu (Acceptance Criteria) để đảm bảo QA và Dev có chung tiêu chuẩn đánh giá hoàn thành. Bao gồm cả luồng chuẩn (Happy path) và ngoại lệ (Edge cases).
Ví dụ:
- TC1 (Happy Path): Nhập đủ thông tin hợp lệ -> Bấm Lưu -> Hệ thống tạo thành công và đóng popup, data hiển thị mới nhất trên bảng.
- TC2 (Ngoại lệ): Bỏ trống trường Email -> Bấm Lưu -> Khung input Email báo lỗi màu đỏ “Vui lòng nhập email”.
- TC3 (Business Rule): Thêm 6 email vào khung -> Bấm Lưu -> Hệ thống báo lỗi giới hạn (không cho phép tạo).