analyze-requirement-document
starsforks
How to install analyze-requirement-document?
anhtester/codex-testing-kit/analyze-requirement-document
$npx -y skills add anhtester/codex-testing-kit --skill analyze-requirement-documentPhân tích requirement document (Jira ticket, .doc, user story) — sinh tài liệu phân tích chi tiết, KHÔNG sinh test cases.
SKILL.md
| 1 | > **BẮT BUỘC (MANDATORY SKILL):** Bạn PHẢI nạp và đọc kỹ nội dung của skill **`$requirements-analyzer`** (tại `.agents/skills/requirements-analyzer/SKILL.md`) để hiểu cách phân tích yêu cầu chuẩn trước khi bắt đầu. |
| 2 | |
| 3 | # Workflow: Phân Tích Requirement Document |
| 4 | |
| 5 | Workflow này phân tích requirement documents (Jira tickets, .doc files, user stories, design mockups) và sinh ra một tài liệu phân tích chi tiết. **KHÔNG sinh test cases** — chỉ tập trung vào hiểu, phân rã, và phát hiện rủi ro/mơ hồ trong yêu cầu. |
| 6 | |
| 7 | ## Khi nào sử dụng |
| 8 | |
| 9 | - User cung cấp Jira ticket (.doc) hoặc requirement document và yêu cầu "phân tích" |
| 10 | - User muốn hiểu rõ scope, acceptance criteria, và dependencies trước khi viết test |
| 11 | - User cần danh sách các điểm mơ hồ (ambiguities) để clarify với PO/BA |
| 12 | - User nói: "phân tích requirement", "review yêu cầu", "analyze this ticket" |
| 13 | |
| 14 | ## Đầu vào (Input) |
| 15 | |
| 16 | Agent cần thu thập từ user: |
| 17 | |
| 18 | | # | Input | Bắt buộc | Mô tả | |
| 19 | |---|---|---|---| |
| 20 | | 1 | **Requirement document** | ✅ | File .doc, .md, URL Jira, hoặc text mô tả yêu cầu | |
| 21 | | 2 | **Mockup/Screenshot** | ⭕ Khuyến khích | Hình ảnh UI design, wireframe, hoặc screenshot hiện tại | |
| 22 | | 3 | **Related tickets** | ⭕ Tùy chọn | Các ticket phụ thuộc hoặc liên quan (dependencies) | |
| 23 | | 4 | **Context bổ sung** | ⭕ Tùy chọn | Thông tin về hệ thống hiện tại, business domain | |
| 24 | |
| 25 | > [!NOTE] |
| 26 | > Nếu user chỉ cung cấp file .doc mà không có mockup, agent vẫn phải phân tích đầy đủ dựa trên nội dung document. Nếu có mockup/screenshot, agent phân tích UI chi tiết hơn. |
| 27 | |
| 28 | ## Các bước thực hiện |
| 29 | |
| 30 | ### Bước 1: Thu thập và đọc hiểu (Information Gathering) |
| 31 | |
| 32 | 1. **Đọc requirement document** được user cung cấp (file .doc, .md, hoặc URL) |
| 33 | - Nếu file .doc format HTML (export từ Jira): parse HTML để trích xuất nội dung |
| 34 | - Xác định: Ticket ID, Type, Priority, Status, Reporter, Assignee, Fix Version, Sprint, Labels |
| 35 | 2. **Đọc mockup/screenshot** nếu có — phân tích UI layout, components, fields |
| 36 | 3. **Kiểm tra related tickets** nếu có trong cùng thư mục hoặc được user cung cấp |
| 37 | - Đọc và tóm tắt dependencies |
| 38 | 4. **Xác nhận** đã nắm được bối cảnh → tiếp tục phân tích |
| 39 | |
| 40 | ### Bước 2: Trích xuất thông tin cốt lõi (Core Analysis) |
| 41 | |
| 42 | 1. **Tổng quan Ticket** — Bảng metadata (ID, Type, Priority, Status, Sprint, Assignee...) |
| 43 | 2. **User Story** — Trích xuất format "As a... I want... So that..." |
| 44 | 3. **Phạm vi áp dụng (Scope)** — Xác định rõ các module/page/component bị ảnh hưởng |
| 45 | 4. **Acceptance Criteria** — Phân rã từng AC thành các nhóm logic, bao gồm: |
| 46 | - Mô tả chi tiết từng AC |
| 47 | - Bảng so sánh (nếu có cột mới, field mới, rule mới) |
| 48 | - Phân biệt rõ **mặc định vs tùy chọn** (nếu applicable) |
| 49 | |
| 50 | ### Bước 3: Phân tích UI từ Mockup (nếu có) |
| 51 | |
| 52 | Nếu user cung cấp mockup/screenshot: |
| 53 | |
| 54 | 1. **Mô tả layout** — Breadcrumb, header, sidebar, main content, footer |
| 55 | 2. **Liệt kê components** — Tables, forms, modals, buttons, dropdowns, tabs |
| 56 | 3. **Chi tiết fields** — Tên field, loại (input/dropdown/date picker), label, placeholder |
| 57 | 4. **So sánh** mockup với document — phát hiện inconsistency |
| 58 | 5. **Chụp quan sát** vào carousel trong artifact (nếu hình có sẵn) |
| 59 | |
| 60 | ### Bước 4: Phân tích Dependencies (Phụ thuộc) |
| 61 | |
| 62 | 1. Xác định các ticket/feature liên quan (referenced trong AC hoặc comments) |
| 63 | 2. Đọc và tóm tắt nội dung ticket phụ thuộc |
| 64 | 3. Nếu có mockup riêng cho dependency → phân tích UI chi tiết (fields, modals, interactions) |
| 65 | 4. Tổng hợp **Business Rules** từ tất cả requirements + mockups |
| 66 | 5. Đánh dấu rõ quy tắc nào từ ticket chính vs ticket phụ thuộc |
| 67 | |
| 68 | ### Bước 5: Phát hiện Ambiguities & Risks (Trọng tâm) |
| 69 | |
| 70 | > [!IMPORTANT] |
| 71 | > Đây là phần **giá trị cao nhất** của workflow — phát hiện những gì requirement KHÔNG nói rõ. |
| 72 | |
| 73 | **5.1. Điểm mơ hồ (Ambiguities):** |
| 74 | |
| 75 | Với mỗi ambiguity, ghi rõ: |
| 76 | - **Mã:** AMB-XX (đánh số tuần tự) |
| 77 | - **Câu hỏi:** Mô tả rõ ràng điều gì chưa rõ |
| 78 | - **Nguy cơ:** Impact nếu không được giải quyết |
| 79 | - **Mức độ:** 🔴 High / 🟡 Medium / 🟢 Low |
| 80 | |
| 81 | Các hướng phát hiện ambiguity: |
| 82 | - Từ khóa mơ hồ: "where applicable", "as needed", "similar to", "etc." |
| 83 | - Validation rules thiếu: min/max, format, required/optional |
| 84 | - Hành vi edge case: lỗi mạng, concurrent access, trống data |
| 85 | - Inconsistency giữa document và mockup (tên cột, format, layout) |
| 86 | - Threshold/config chưa xác định (ví dụ: bao nhiêu ngày = "approaching deadline"?) |
| 87 | - Conflict giữa requirements cũ và mới |
| 88 | |
| 89 | **5.2. Rủi ro kiểm thử (Testing Risks):** |
| 90 | |
| 91 | Với mỗi risk, ghi rõ: |
| 92 | - **Mã:** RISK-XX |
| 93 | - **Tên rủi ro** |
| 94 | - **Mô tả** |
| 95 | - **Mitigation** (cách giảm thiểu) |
| 96 | |
| 97 | ### Bước 6: Tổng hợp và trình bày (Synthesis & Delivery) |
| 98 | |
| 99 | 1. **Ma trận trạng thái** (nếu có state transitions) — bảng mapping trạng thái → hành vi |
| 100 | 2. **Checklist AC** — Tóm tắt tất cả AC dạng checkbox, nhóm theo chức năng |
| 101 | 3. **Khuyến nghị kiểm thử** — Gợi ý top 10 điều cần quan tâm nhất khi test |
| 102 | 4. **Xuất Artifact** — Lưu toàn bộ phân tích vào file `.md` |
| 103 | |
| 104 | ## Cấu trúc Output (Template Artifact |
People who liked this also viewed
6 picksType
- tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026
- qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026
- webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026
- playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 2026
