> ## Documentation Index
> Fetch the complete documentation index at: https://learn.cleeksy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cơ bản về Scenario

> Cách viết user scenario đủ rõ để thiết kế và kiểm thử.

Trang này cung cấp chuẩn tối thiểu để viết **scenario** phục vụ thiết kế và triển khai hệ thống vận hành số. Scenario tốt giúp giảm hiểu nhầm, giảm scope creep và giúp cấu hình app nhất quán.

<Info>
  Scenario là đầu vào quan trọng cho **Design** trong vòng lặp Scenario-Driven (SDD) và cũng là nền tảng để chọn phạm vi theo SMALL.
</Info>

## Mục tiêu

* Chuẩn hoá định dạng scenario để dùng chung giữa nghiệp vụ và người cấu hình app
* Xác định “đủ rõ để build” (quality bar) trước khi bắt đầu cấu hình
* Tránh các lỗi phổ biến: mô tả mơ hồ, trộn giải pháp vào yêu cầu, scope phình to

Liên quan:

* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)

## Scenario là gì?

Một **scenario** mô tả một luồng công việc cụ thể theo góc nhìn người dùng (actor), từ lúc kích hoạt (trigger) đến kết quả (outcome). Scenario tập trung vào:

* **Ai** thực hiện (actor/role)
* **Vì sao** bắt đầu (trigger)
* **Các bước chính** cần xảy ra (main steps)
* **Ngoại lệ quan trọng** (exceptions)
* **Kết quả mong muốn** (outcome + success criteria)

<Note>
  Scenario không phải tài liệu “kể chuyện”. Scenario là mô tả có cấu trúc để chuyển thành dữ liệu, UI và workflow.
</Note>

## Định dạng scenario tối thiểu

Khuyến nghị dùng format sau cho mỗi scenario:

### 1) Tên scenario

Ngắn gọn và hành động rõ: “Tạo yêu cầu mua”, “Phê duyệt yêu cầu mua”, “Procurement cập nhật trạng thái mua sắm”.

### 2) Actor và mục tiêu

* **Actor**: vai trò thực hiện (Requester/Approver/Procurement…)
* **Mục tiêu**: kết quả mà actor cần đạt

### 3) Trigger và điều kiện trước

* **Trigger**: sự kiện bắt đầu (nhân viên cần mua hàng)
* **Preconditions**: điều kiện cần có (đã đăng nhập, có quyền tạo yêu cầu…)

### 4) Luồng chính (Main flow)

Danh sách bước theo thứ tự, mỗi bước nên có:

* hành động của actor
* hệ thống phản hồi/ghi nhận gì
* trạng thái thay đổi (nếu có)

### 5) Ngoại lệ quan trọng (Exceptions)

Chỉ giữ 1–3 ngoại lệ “đáng tiền” cho vòng đầu, ví dụ:

* thiếu thông tin bắt buộc
* bị từ chối phê duyệt
* vượt ngưỡng chi phí cần escalations (nếu có)

### 6) Outcome và tiêu chí thành công

* **Outcome**: trạng thái kết thúc (Approved/Rejected/Closed…)
* **Success criteria**: cách biết scenario hoàn thành (ví dụ: trạng thái cập nhật, người liên quan được thông báo, log/audit có đủ)

## Ví dụ scenario (Purchase Request)

### Scenario: Gửi Purchase Request để xin phê duyệt

* **Actor**: Requester
* **Mục tiêu**: tạo yêu cầu mua và gửi để phê duyệt
* **Trigger**: phát sinh nhu cầu mua hàng
* **Preconditions**: có quyền tạo Purchase Request

**Main flow**

1. Requester tạo bản ghi Purchase Request (nhập tiêu đề, mô tả, loại mua, chi phí dự kiến)
2. Hệ thống lưu bản ghi ở trạng thái Draft
3. Requester gửi yêu cầu → chuyển trạng thái Pending Approval
4. Hệ thống thông báo cho Approver

**Exceptions**

* Nếu thiếu thông tin bắt buộc → hệ thống chặn gửi và hiển thị lỗi
* Nếu Requester không có quyền gửi → hệ thống ẩn hành động hoặc chặn thao tác

**Outcome**

* Yêu cầu ở trạng thái Pending Approval và Approver nhận được thông báo

<Note>
  Ví dụ trên cố ý giữ “tối thiểu chạy được”. Các biến thể ít gặp nên đưa vào backlog thay vì đưa vào vòng đầu.
</Note>

## Quality bar: “Đủ rõ để build”

Một scenario được coi là **ready** khi:

* Actor và trigger rõ ràng (không mơ hồ)
* Có danh sách bước chính có thứ tự
* Có outcome cụ thể và có thể kiểm chứng
* Vai trò liên quan đã được nêu (ít nhất vai trò chính)
* Có tối đa 1–3 ngoại lệ quan trọng cho vòng đầu
* Có dữ liệu tối thiểu cần thu thập (các trường bắt buộc đã biết)

<Warning>
  Nếu outcome không đo/kiểm chứng được (“xử lý nhanh”, “trơn tru”), scenario chưa sẵn sàng. Cần chuyển thành tiêu chí cụ thể (thời gian, trạng thái, thông báo, SLA…).
</Warning>

## Từ scenario sang cấu hình Cleeksy (mapping tối thiểu)

Scenario tốt giúp xác định nhanh các cấu phần:

* **Danh từ nghiệp vụ** → Entities/Fields (Purchase Request, Supplier, Item…)
* **Bước công việc / trạng thái** → Workflow states & transitions
* **Actor** → Roles/Permissions
* **Điều kiện / policy** → validation/protection/role gates
* **Kết quả cần theo dõi** → dashboard/metrics (khi cần)

Tham khảo:

* [Cơ bản về App](/build-apps/app-basics)
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)

## Lỗi phổ biến và cách tránh

### 1) Trộn giải pháp vào yêu cầu

* Sai: “Cần có Kanban và dashboard”
* Đúng: “Cần theo dõi trạng thái theo cột và có tổng số yêu cầu theo trạng thái”

### 2) Mô tả chung chung

* Sai: “Procurement xử lý mua hàng”
* Đúng: “Procurement cập nhật trạng thái In Procurement → Completed và ghi số PO (nếu có)”

### 3) Quá nhiều ngoại lệ ở vòng đầu

* Dấu hiệu: workflow có quá nhiều nhánh và điều kiện ngay từ đầu
* Cách xử lý: đưa ngoại lệ ít gặp vào backlog, chỉ giữ ngoại lệ quan trọng

### 4) Không xác định “xong việc” là gì

* Dấu hiệu: không có trạng thái kết thúc hoặc không có tiêu chí kiểm chứng
* Cách xử lý: thêm outcome + success criteria

## Bước tiếp theo

* Chọn phạm vi theo SMALL: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* Quyết định ranh giới app: [Ranh giới App](/foundations/app-boundaries)
* Tổ chức delivery theo SDD: [SDD là gì](/sdd/overview)