Đến gần trưa, whiteboard đã hơi rối: mũi tên, ô vuông, vài bước bị gạch đi, và một dấu hỏi nằm cạnh "approval exception". Nhưng căn phòng lại yên hơn buổi sáng. Mọi người bớt tranh luận bằng trí nhớ riêng và bắt đầu chỉ vào cùng một bức tranh.
Đó là giá trị lặng lẽ của requirements modeling. Model không cần đẹp. Nó cần làm cho cuộc trò chuyện dễ sửa hơn.
Ghi chú nguồn: Series này được viết từ file Markdown nội bộ về Lean Business Analysis, tổng hợp ý từ Emrah Yayici, PMI và Business Analysis For Dummies. Em xem đây là tư liệu làm việc, không thay thế cho việc đọc các sách gốc.
Model là công cụ để suy nghĩ
Requirement thường bắt đầu bằng câu chữ. Câu chữ linh hoạt, rất hữu ích lúc đầu, nhưng cũng dễ giấu gap. Một stakeholder nói "system should notify the manager", và năm người tưởng tượng năm trigger, channel, timing rule và escalation path khác nhau.
Model biến một phần câu chữ đó thành cấu trúc chung. Nó có thể là context diagram, process flow, decision table, data dictionary, use case, user story map, wireframe hoặc state diagram. Mục đích không phải khoe notation. Mục đích là lộ ambiguity khi nó còn rẻ.
Tư liệu nhóm requirements model thành năm họ thực tế: scope, process, rule, data và interface models. Cách phân loại này hữu ích vì nhắc mình rằng một diagram hiếm khi giải thích được mọi thứ.
| Nhóm model | Câu hỏi nó trả lời | Ví dụ thường gặp |
|---|---|---|
| Scope | Cái gì nằm trong, ngoài và connected? | Context diagram, ecosystem map, feature model, use case diagram |
| Process | Công việc chảy qua người và system như thế nào? | Swimlane, process flow, use case description, user story map |
| Rule | Logic nào quyết định chuyện gì xảy ra? | Business rules catalog, decision table, decision tree |
| Data | Thông tin nào tồn tại, di chuyển hoặc đổi state? | ERD, DFD, data dictionary, state diagram |
| Interface | User hoặc system tương tác ở bề mặt thế nào? | Wireframe, report table, UI flow, display-action-response model |
Scope models đặt đường biên
Scope problem là một trong những thứ đau nhất vì nó thường trông như commitment problem. Team nghĩ đã thống nhất "customer onboarding", rồi sau đó phát hiện sales, KYC, billing, support, analytics và compliance đều ngầm nghĩ phần của mình nằm trong onboarding.
Context diagram giúp bằng cách đặt solution ở giữa và vẽ actors, systems, data flows bên ngoài. Ecosystem map mở rộng góc nhìn tới partners, departments, regulators, channels và products khác. Business objectives model nối công việc về outcome. Feature model cho thấy các capability group chính. Use case diagram có thể cho biết ai tương tác với function nào.
Ví dụ một lending product. Feature "application review" nghe nhỏ cho tới khi context diagram cho thấy applicant portal, credit bureau, fraud service, document storage, underwriting team, notification service, audit log và CRM. Diagram không giải quyết project, nhưng nó làm scope đủ thật để bàn.
Process models làm handoff hiện ra
Process models đặc biệt hữu ích khi delay, rework hoặc ownership mơ hồ là một phần vấn đề. Swimlane diagram có thể cho thấy một refund request đi từ customer support sang finance, quay lại support, lên manager, rồi tới payment gateway. Mỗi lane cho biết ai own bước đó. Mỗi mũi tên là một handoff có thể gãy.
Với refund flow, process model có thể làm lộ ra rằng agent không biết refund có trong policy hay không cho tới sau khi tạo ticket. Vậy là sinh escalation thừa. Requirement tốt hơn có thể là "show policy eligibility before ticket submission", không chỉ là "add refund status to ticket screen".
User story cũng là process model nếu dùng tốt. Story "As a support agent, I want to see refund eligibility before submitting a ticket so that I can resolve simple cases without escalation" giữ user, capability và outcome nối với nhau. INVEST giúp nhắc story nên independent, negotiable, valuable, estimable, small và testable. Nhưng acronym không có phép màu. Story vẫn cần example.
Rule models bắt logic ẩn
Business rules thường ẩn trong những cụm như "eligible customer", "high risk", "manager approval" hoặc "standard discount". Rule model làm logic đó hiện ra.
Decision table hữu ích khi nhiều condition kết hợp với nhau. Ví dụ:
| Customer tier | Refund age | Amount | Decision |
|---|---|---|---|
| Gold | Dưới 30 ngày | Dưới 100 dollars | Auto approve |
| Gold | Dưới 30 ngày | Từ 100 dollars | Manager review |
| Standard | Dưới 14 ngày | Dưới 50 dollars | Auto approve |
| Bất kỳ | Ngoài policy window | Bất kỳ | Deny hoặc exception review |
Khi table đã visible, stakeholders có thể challenge nó. Gold tier có thật sự đủ để auto approval không? Fraud flag thì sao? Partial refund thì sao? Những câu hỏi này dễ hỏi hơn nhiều trước khi logic bị chôn trong code.
Data models giữ chữ nghĩa trung thực
Nhiều tranh cãi requirement thật ra là tranh cãi data. "Customer" có thể là account holder với billing, active user với product, legal entity với compliance, và contact person với sales. Data dictionary có thể tiết kiệm nhiều ngày nhầm lẫn bằng cách định nghĩa term, format, owner, allowed values và relationship.
Data flow diagram hữu ích khi information đi qua boundary. Entity relationship diagram hữu ích khi structure quan trọng. State diagram hữu ích khi một object thay đổi theo thời gian: application draft, submitted, under review, approved, rejected, expired, withdrawn. Giá trị không nằm ở vẻ học thuật. Giá trị nằm ở việc giảm assumption lệch nhau.
Ví dụ, nếu application có thể "approved" nhưng vẫn thiếu bank details, state model nên gọi tên chuyện đó rõ ràng. Nếu không, support sẽ hứa một kiểu, operations chờ một kiểu, và engineering encode một state không ai own.
Interface models bảo vệ đoạn cuối cùng
Interface models nối requirement với nơi con người thật sự hành động. Wireframe, report table, UI flow và display-action-response description giúp team nghĩ về user thấy gì, action nào available, và system phản hồi thế nào.
Report table có thể hữu ích hơn một mockup bóng bẩy khi câu hỏi chính là ý nghĩa dữ liệu: column name, source, calculation rule, filter behavior, refresh cadence và owner. Low-fidelity wireframe tốt hơn khi layout và user decision flow quan trọng. UI flow tốt hơn khi risk nằm ở navigation giữa các state.
Model bao nhiêu là đủ?
Đủ modeling nghĩa là team có thể ra quyết định tiếp theo với ít assumption ẩn hơn. Nếu một story và ba example đã đủ, làm vậy. Nếu một rule table tránh được vài tuần rework, làm vậy. Nếu một ERD formal là cần thiết vì năm system phụ thuộc cùng một entity, làm vậy.
Thói quen BA khỏe mạnh không phải "lúc nào cũng vẽ diagram". Nó là: khi chữ bắt đầu lung lay, hãy làm ý tưởng hiện ra.