Requirements Elicitation
DiscoveryRequirements elicitation từ beginner đến advanced: interview, workshop, observation, FAQD log, templates, case studies, và cách biến user pain thành requirement, user story và acceptance criteria.
Đăng nhập để đánh dấu kỹ năng và theo dõi tiến độ.
Roadmap — Cách học và đạt kỹ năng
Requirements Elicitation là gì?
Requirements elicitation là quá trình khám phá, làm rõ, kiểm chứng và thống nhất nhu cầu thật của user, business và system trước khi viết requirement hoặc user story. Nó khác với “requirements gathering” vì stakeholder không luôn biết chính xác họ cần gì. BA/PM phải khai thác context, pain point, constraint, rule, exception và success metric để biến insight thành requirement có thể build và test.
Một requirement tốt không bắt đầu bằng “stakeholder muốn button X”. Nó bắt đầu bằng evidence: ai đang gặp pain, pain xảy ra khi nào, ảnh hưởng business ra sao, workaround hiện tại là gì, rule nào cần tuân thủ, và decision nào đã được approve.
Mindset quan trọng: Elicit, không phải chỉ hỏi
| Cách yếu | Cách đúng | Ví dụ câu hỏi tốt hơn |
|---|---|---|
| “Anh/chị muốn feature gì?” | Hỏi pain, goal, context và workaround. | “Lần gần nhất việc này bị kẹt là khi nào? Anh/chị đã xử lý thế nào?” |
| Chỉ nghe manager. | Nghe cả frontline operator, support, QA, finance, legal, system owner. | “Ai là người thực sự làm bước này hằng ngày? Tôi có thể shadow 30 phút không?” |
| Ghi mọi câu nói thành requirement. | Tách Facts, Assumptions, Questions, Decisions trước. | “Điều này đã xảy ra bao nhiêu lần? Có data hoặc ticket sample không?” |
| Chốt scope bằng cảm giác. | Chốt bằng decision log, tradeoff và success metric. | “Nếu chỉ làm MVP, decision nào bắt buộc có và cái gì có thể để phase 2?” |
FAQD: Facts, Assumptions, Questions, Decisions
FAQD là cách quản lý clarity trong elicitation. Nhiều dự án thất bại vì team trộn lẫn “sự thật”, “phỏng đoán”, “câu hỏi chưa trả lời” và “quyết định đã chốt”. Khi mọi thứ bị trộn thành note dài, Engineering build nhầm, QA không biết expected behavior, stakeholder tưởng đã thống nhất nhưng thật ra chưa.
| Loại note | Định nghĩa | Format nên ghi | Ví dụ | Action tiếp theo |
|---|---|---|---|---|
| Facts | Thông tin đã quan sát hoặc có evidence. | Fact + source + date + evidence link. | “37/120 refund tickets tháng 5 thiếu ảnh sản phẩm. Source: Zendesk export 2026-05-18.” | Dùng làm input cho problem statement và metric. |
| Assumptions | Điều team tin là đúng nhưng chưa kiểm chứng. | Assumption + risk + owner + validation method. | “User sẽ upload ảnh nếu flow dưới 2 phút. Owner: PM. Validate bằng prototype test 5 users.” | Validate bằng data, interview, prototype hoặc experiment. |
| Questions | Điểm chưa rõ đang cản requirement. | Question + owner + due date + decision needed. | “Refund dưới 200k có cần Finance approve không? Owner: Finance Lead. Due: Friday.” | Resolve trước story grooming hoặc sprint planning. |
| Decisions | Điều đã được thống nhất bởi đúng decision maker. | Decision + approver + date + rationale + impact. | “MVP auto-approve refund dưới 200k nếu order delivered trong 7 ngày. Approved by Ops Head.” | Convert thành business rule, AC, permission hoặc workflow. |
9 kỹ thuật elicitation theo BABOK - giải thích đầy đủ hơn
| Kỹ thuật | Khi nào dùng | Cách làm tốt | Output | Pitfall |
|---|---|---|---|---|
| Interview | Cần hiểu motivation, pain, edge case, politics. | Semi-structured: chuẩn bị 8-12 câu hỏi, hỏi follow-up theo STAR: situation, task, action, result. | Persona notes, pain points, quote, FAQD log. | Hỏi leading questions làm user trả lời theo ý mình. |
| Workshop | Cần alignment giữa nhiều team hoặc chốt scope. | Agenda rõ, timebox, pre-read, decision maker có mặt, dùng dot vote hoặc MoSCoW. | Prioritized scope, decision log, open questions. | Workshop biến thành status meeting không có decision. |
| Observation | Process thật khác SOP; user có workaround không nói ra. | Shadow user, ghi screen steps, wait time, copy/paste, tool switching. | As-is process, bottleneck, hidden requirements. | Quan sát một case rồi generalize quá sớm. |
| Document analysis | Compliance, contract, SOP, policy, legacy workflow. | Highlight rule, exception, owner, deadline, data fields, audit needs. | Business rules, constraints, glossary. | Đọc document nhưng không validate thực tế vận hành. |
| Survey | Cần quantify sau khi đã có hypothesis từ qualitative discovery. | Hỏi ít, rõ, tránh câu hỏi kép, segment respondent. | Priority signal, frequency, severity, preference. | Dùng survey để khám phá vấn đề mới khi chưa hiểu domain. |
| Prototyping | Cần reaction trước khi build; solution còn mơ hồ. | Paper/clickthrough prototype, task-based test, hỏi “Bạn sẽ làm gì tiếp?” | Usability risk, missing requirement, terminology issue. | Hỏi user có thích không thay vì quan sát họ làm task. |
| Focus group | Cần hiểu perception hoặc language của nhóm user. | Moderator trung lập, tránh một người dominate, ghi disagreement. | Themes, language, objections. | Dùng focus group để quyết định priority thay cho behavior data. |
| Brainstorming | Cần divergent solution hoặc option trước khi converge. | Dùng SCAMPER, crazy 8s, “how might we”, sau đó vote theo impact/effort. | Solution options, opportunity ideas. | Brainstorm quá sớm khi problem chưa rõ. |
| Reverse engineering | System cũ không có tài liệu, logic nằm trong code/UI/report. | Walk through screens, export data, compare expected vs actual, hỏi system owner. | Current logic, business rules, migration gaps. | Assume current system behavior là desired behavior. |
Template 1: Elicitation plan trước khi gặp stakeholder
| Field | Cần điền gì? | Ví dụ |
|---|---|---|
| Business objective | Mục tiêu kinh doanh cần hỗ trợ. | Giảm refund resolution time từ 6 ngày xuống 2 ngày. |
| Scope boundary | Bắt đầu/kết thúc ở đâu, không làm gì. | Từ lúc customer request return đến lúc refund approved; không bao gồm logistics pickup phase 2. |
| Stakeholders | Decision maker, user thật, approver, affected teams. | Support agent, warehouse lead, finance lead, customer, product ops. |
| Known facts | Evidence hiện có trước session. | Support tickets, current SOP, dashboard, refund policy. |
| Assumptions to validate | Những điều nếu sai sẽ ảnh hưởng solution. | Customer có thể tự upload ảnh; warehouse check trong 24h. |
| Questions | Câu hỏi cần trả lời trong session. | Case nào bắt buộc Finance approve? Fraud rule hiện tại là gì? |
| Technique | Interview, observation, workshop, prototype... | Observation 45 phút + interview 30 phút + workshop 60 phút. |
| Expected output | Artifact phải có sau session. | As-is flow, FAQD log, requirement list, open decision list. |
Template 2: Interview guide dùng được trong thực tế
- Context: “Vai trò của bạn trong process này là gì? Bạn làm việc này bao nhiêu lần mỗi tuần?”
- Trigger: “Process bắt đầu khi nào? Ai hoặc system nào tạo request?”
- Current workflow: “Bạn có thể walk me through case gần nhất không? Mở tool thật nếu được.”
- Pain: “Bước nào tốn thời gian nhất? Bước nào dễ sai nhất? Vì sao?”
- Workaround: “Khi system không hỗ trợ, bạn dùng Excel/email/chat như thế nào?”
- Rules: “Có rule, policy, permission, approval threshold nào không?”
- Exceptions: “Nếu thiếu data, bị reject, duplicate, timeout, fraud, system down thì sao?”
- Impact: “Nếu không xử lý, ảnh hưởng customer/business/team ra sao?”
- Success: “Nếu solution thành công, metric nào phải thay đổi?”
- Validation: “Tôi summarize lại như này đúng không? Có ai khác cần confirm không?”
Note-taking format: ghi quote nguyên văn khi có insight quan trọng, nhưng requirement phải được viết lại bằng ngôn ngữ testable. Ví dụ quote: “Tôi phải mở 4 tab chỉ để biết refund có hợp lệ không.” Requirement: “System shall display order status, return window, payment method and refund eligibility on one review screen.”
Template 3: Workshop agenda 90 phút để chốt scope
| Thời lượng | Hoạt động | Facilitation tips | Output |
|---|---|---|---|
| 0-10 phút | Goal, scope, decision needed. | Nêu rõ hôm nay cần chốt gì và không bàn gì. | Shared objective. |
| 10-30 phút | Map as-is process. | Mỗi team thêm step của mình; không tranh luận solution. | As-is flow. |
| 30-45 phút | Mark pain points. | Dùng dots: delay, error, rework, risk, customer pain. | Pain map. |
| 45-60 phút | Convert pain to needs. | Viết needs độc lập với UI solution. | Need statements. |
| 60-75 phút | Prioritize MVP vs later. | Dùng MoSCoW hoặc impact/effort; decision maker phải chốt. | Prioritized scope. |
| 75-90 phút | Decisions, questions, owners. | Review FAQD, assign owners and dates. | Decision log + next actions. |
Từ user pain đến requirement và user story
| Bước | Output | Ví dụ e-commerce refund |
|---|---|---|
| Evidence | Fact có source. | “35% refund tickets phải hỏi lại order ID hoặc ảnh sản phẩm.” |
| Pain statement | Ai đau, vì sao, impact gì. | Support agent mất thời gian hỏi lại thông tin, customer chờ lâu, SLA breach. |
| Need statement | User cần khả năng gì, không gắn UI. | Agent cần thấy đủ eligibility data và evidence trong một màn hình review. |
| Functional requirement | System behavior testable. | System shall show order status, delivery date, payment method, refund policy result and uploaded evidence. |
| Business rule | Policy/decision. | Refund dưới 200k auto-approve nếu delivered trong 7 ngày và không có fraud flag. |
| User story | As a / I want / so that. | As a support agent, I want a refund eligibility panel so that I can decide without opening multiple tools. |
| Acceptance criteria | Given / When / Then. | Given order is delivered within 7 days and amount < 200k, when agent opens review, then system displays “Eligible for auto-approval”. |
Requirement quality checklist
- Clear: người khác đọc hiểu giống nhau, không dùng từ mơ hồ như “nhanh”, “dễ”, “thân thiện” nếu không có metric.
- Atomic: một requirement mô tả một behavior/rule chính, không gộp 5 thứ vào một câu.
- Testable: QA có thể verify bằng scenario hoặc data.
- Traceable: liên kết về source: interview, ticket, policy, workshop decision.
- Feasible: Engineering hiểu dependency, data source, permission, system constraint.
- Prioritized: có MoSCoW, value/risk, deadline hoặc release target.
- Complete enough: có happy path, exception, non-functional requirement, data, permission, reporting nếu liên quan.
Case study 1: Ngân hàng số - onboarding KYC
Problem: completion rate thấp ở bước KYC. Business nghĩ cần redesign UI. Sau elicitation, team phát hiện pain chính là user không hiểu vì sao phải chụp lại CCCD và nhân viên compliance reject hồ sơ vì glare/blur nhưng reason không rõ.
| Evidence | Insight | Requirement | User story |
|---|---|---|---|
| Observation: user retry photo 3-4 lần. | Instruction thiếu ví dụ ảnh hợp lệ. | System shall show live capture guidance and sample accepted/rejected images. | As a new user, I want clear ID photo guidance so that I can complete KYC without repeated rejection. |
| Compliance rejects with free-text reasons. | Reason không standardized nên Support khó giúp user. | Reviewer must select standardized rejection reason with user-facing explanation. | As a support agent, I want standardized rejection reasons so that I can explain next action clearly. |
| Policy says high-risk profiles need manual review. | Không phải mọi hồ sơ nên auto-approve. | System shall route high-risk KYC cases to manual review queue with SLA timer. | As a compliance reviewer, I want risky cases prioritized so that regulatory risk is controlled. |
Lesson: Nếu chỉ hỏi “cần feature gì”, team có thể build thêm upload button. Elicitation tốt phát hiện policy, rejection reason, image quality, SLA và communication requirement.
Case study 2: B2B SaaS - sales discount approval
Problem: Sales team nói “cần discount approval tool”. Elicitation cho thấy vấn đề thật là decision ownership và audit: Finance cần kiểm soát margin, Legal cần review contract term, Sales cần tốc độ, Billing cần rule chính xác.
- Fact: 28% deals tháng trước dùng discount ngoài pricing policy.
- Assumption: Discount dưới 15% có thể auto-approve bởi Sales Manager.
- Question: Nếu discount đi kèm custom termination clause, Legal có phải approve không?
- Decision: MVP yêu cầu Finance approve discount > 15% hoặc contract term > 24 tháng.
Requirement examples:
- System shall calculate approval path based on discount percentage, ARR, contract term and legal clause flags.
- System shall store approver, timestamp, original request, approved value and final billing plan for audit.
- System shall block quote generation if required approvals are missing.
Case study 3: Internal operations - procurement request
Problem: Employees complain procurement is slow. Manager asks for “one-click approval”. Observation shows requests bounce because information is incomplete: vendor tax ID, budget code, security review and contract owner are often missing.
| Pain | Root cause | Better requirement |
|---|---|---|
| Request waits 5 days. | Approver lacks budget context. | Procurement request must include budget code, remaining budget and department owner before submission. |
| Security review late. | No routing rule for SaaS/vendor data access. | If vendor handles customer data, system shall route request to Security before Finance approval. |
| Employees do not know status. | No notification or SLA visibility. | System shall show current owner, pending step, SLA due date and required action. |
Common pitfalls và cách tránh
- Solution bias: Stakeholder nói “tôi cần dashboard”, nhưng requirement thật có thể là “tôi cần biết exception nào cần action trước 5 giờ chiều”. Hãy hỏi decision họ cần đưa ra.
- Happy-path only: Nếu không hỏi exception, Engineering sẽ tự đoán. Luôn hỏi reject, timeout, duplicate, missing data, permission denied, manual override.
- No decision maker: Workshop không có người có quyền chốt thì chỉ tạo thêm opinions. Mời đúng approver hoặc ghi rõ decision pending.
- No traceability: Story không có source dễ bị challenge. Link mỗi story tới evidence hoặc decision log.
- Too much documentation, not enough clarity: Tài liệu dài không giúp nếu không có decision, owner, acceptance criteria và open questions.
30-day practice plan
- Tuần 1: chọn một process thật, shadow 2 users, tạo FAQD log, tách ít nhất 10 facts và 5 assumptions.
- Tuần 2: chạy 3 interviews, viết problem statement, pain map và open questions với owner.
- Tuần 3: tổ chức workshop 60-90 phút, chốt MVP scope, decision log và requirement matrix.
- Tuần 4: convert 5 requirements thành user stories + acceptance criteria, review với Engineering/QA, chỉnh đến khi testable.
Definition of done cho elicitation tốt
- Stakeholders chính, real users và approvers đã được identify.
- Facts, Assumptions, Questions, Decisions được tách riêng.
- Requirement trace được về evidence, policy hoặc approved decision.
- Happy path và exception paths đều được capture.
- Business rules, data fields, permission và reporting needs rõ ràng nếu liên quan.
- Open questions có owner và due date.
- User stories có acceptance criteria đủ để QA test và Engineering estimate.
- Success metrics được định nghĩa trước khi build.
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.