"Sai requirement tốn gấp 100 lần so với sai code. Fix bug rẻ, fix sai yêu cầu thì cực đắt." - Barry Boehm
1. Requirement Types
1.1 Functional Requirements (FR)
Mô tả hệ thống phải làm gì - hành vi, chức năng cụ thể.
Ví dụ cho E-commerce:
- Người dùng có thể đăng ký bằng email hoặc Google OAuth
- Hệ thống gửi email xác nhận đơn hàng trong vòng 30 giây
- Admin có thể export report dạng Excel và PDF
1.2 Non-Functional Requirements (NFR)
Mô tả hệ thống phải hoạt động như thế nào - quality attributes.
| Category | Requirement | Measurable Target |
|---|---|---|
| Performance | Response time API | P95 < 200ms |
| Scalability | Concurrent users | 10,000 concurrent users |
| Availability | Uptime SLA | 99.9% (8.76h downtime/year) |
| Security | Authentication | OAuth 2.0 + MFA cho admin |
| Maintainability | Code coverage | > 80% unit test coverage |
| Usability | Page load | First Contentful Paint < 1.5s |
Thực chiến: NFR thường bị bỏ quên cho đến khi production gặp sự cố. Senior dev phải chủ động hỏi NFR ngay từ đầu dự án.
1.3 Constraints
Giới hạn không thể thương lượng:
- Technical: Phải dùng .NET 8, SQL Server, Azure
- Business: Go-live trước 01/06/2025
- Legal: Tuân thủ GDPR, PCI DSS cho payment
- Organizational: Team chỉ có 5 developers, budget $200k
2. User Stories Format
Template chuẩn
As a [role/persona]
I want [goal/desire]
So that [benefit/value]
Ví dụ thực tế
Story tốt:
As a online shopper
I want to save items to my wishlist
So that I can purchase them later without searching again
Story tệ:
As a user
I want a wishlist feature
So that the system has wishlist
Tại sao tệ? "User" quá generic, "feature" không mô tả hành vi, "so that" không nêu value thực sự.
INVEST Criteria cho User Stories
| Tiêu chí | Mô tả | Kiểm tra |
|---|---|---|
| Independent | Không phụ thuộc story khác để deliver value | Có thể deploy riêng? |
| Negotiable | Có thể thảo luận, điều chỉnh scope | PO và dev đã thống nhất? |
| Valuable | Mang lại giá trị cho user hoặc business | User care không? |
| Estimable | Team có thể estimate effort | Có đủ thông tin? |
| Small | Đủ nhỏ để hoàn thành trong 1 Sprint | < 8 story points? |
| Testable | Có thể viết test case kiểm chứng | AC rõ ràng chưa? |
3. Acceptance Criteria - Given-When-Then
Format
gherkinGiven [precondition / initial state] When [action performed] Then [expected outcome]
Ví dụ: Login Feature
gherkinScenario: Đăng nhập thành công với email hợp lệ Given người dùng đã có tài khoản với email "user@example.com" And người dùng ở trang Login When người dùng nhập email "user@example.com" và password đúng And nhấn nút "Đăng nhập" Then hệ thống chuyển hướng đến Dashboard And hiển thị message "Chào mừng bạn quay lại" Scenario: Đăng nhập thất bại sau 5 lần sai password Given người dùng đã nhập sai password 4 lần When người dùng nhập sai password lần thứ 5 Then tài khoản bị lock trong 30 phút And hệ thống gửi email cảnh báo đến người dùng And hiển thị message "Tài khoản đã bị khoá tạm thời"
Quy tắc viết AC tốt
- Mỗi scenario test 1 behavior - không gộp nhiều case
- Dùng data cụ thể - "5 lần" thay vì "nhiều lần"
- Cover cả happy path và edge case - đặc biệt error cases
- Có thể automation - viết AC kiểu này dễ convert sang SpecFlow/xUnit
4. Requirements Traceability Matrix (RTM)
Mục đích
Theo dõi mỗi requirement từ gốc (business need) đến ngọn (test case, code).
| Req ID | Business Need | User Story | Design Doc | Test Case | Status |
|---|---|---|---|---|---|
| REQ-001 | Tăng conversion rate checkout | US-012: One-click checkout | DD-005 | TC-045, TC-046 | Implemented |
| REQ-002 | Giảm fraud loss 30% | US-018: 3DS verification | DD-008 | TC-052, TC-053 | In Progress |
| REQ-003 | Comply GDPR Article 17 | US-025: Delete account data | DD-012 | TC-070 | Not Started |
| REQ-004 | Reduce support tickets 20% | US-030: Self-service FAQ | DD-015 | TC-078 | Implemented |
Khi nào cần RTM?
- Bắt buộc: Regulated industries (banking, healthcare, government)
- Nên có: Dự án > 6 tháng, nhiều team
- Có thể skip: Startup, small team, rapid prototyping
5. MoSCoW Prioritization
Framework
| Priority | Ý nghĩa | Guideline |
|---|---|---|
| Must have | Không có thì hệ thống vô dụng | ~60% total effort |
| Should have | Quan trọng nhưng có workaround | ~20% total effort |
| Could have | Nice-to-have, thêm giá trị | ~20% total effort |
| Won't have | Không làm trong release này | Documented cho sau |
Ví dụ: E-commerce MVP
| Feature | Priority | Lý do |
|---|---|---|
| User registration & login | Must | Không login = không mua được |
| Product catalog & search | Must | Core value proposition |
| Shopping cart & checkout | Must | Revenue-generating flow |
| Payment integration (VNPay) | Must | Phải có để thu tiền |
| Wishlist | Should | Tăng conversion nhưng có thể dùng bookmark |
| Product reviews & ratings | Should | Social proof quan trọng |
| Recommendation engine | Could | Tăng AOV nhưng phức tạp |
| Live chat support | Could | Nice-to-have, dùng email trước |
| Multi-language | Won't | V1 chỉ tiếng Việt |
Tip: Khi stakeholder nói "tất cả đều Must have" - hỏi lại: "Nếu chỉ được ship 3 features, bạn chọn cái nào?" Buộc họ prioritize.
6. Requirement Review Checklist
Trước khi đưa vào Sprint Backlog
- Complete: Đủ thông tin để dev bắt tay làm (DoR passed)
- Consistent: Không mâu thuẫn với requirements khác
- Unambiguous: Chỉ có 1 cách hiểu duy nhất
- Testable: Có acceptance criteria rõ ràng, measurable
- Feasible: Có thể implement với tech stack và timeline hiện tại
- Traceable: Có thể trace ngược về business need
- Prioritized: MoSCoW hoặc Weighted Shortest Job First (WSJF)
- Estimated: Team đã estimate story point
- NFR considered: Performance, security, scalability đã xét
- Dependencies identified: Biết phụ thuộc gì, ai, khi nào
Review Process
PO viết Story + AC
→ Dev review (technical feasibility)
→ QA review (testability)
→ UX review (usability)
→ Refinement session (team consensus)
→ Definition of Ready ✅
7. Common Mistakes in Requirements Gathering
Mistake 1: Gold Plating
Vấn đề: Dev tự thêm feature "vì nghĩ user cần". Fix: Chỉ build đúng requirement, đề xuất improvement qua backlog.
Mistake 2: Vague NFR
Vấn đề: "Hệ thống phải nhanh" - nhanh là bao nhiêu? Fix: Luôn có con số: "API response P95 < 200ms với 1000 concurrent users".
Mistake 3: Solution trong Requirement
Vấn đề: "Dùng Redis cache cho product catalog" - đây là solution, không phải requirement. Fix: "Product catalog phải load trong < 500ms" - để dev chọn solution.
Mistake 4: Missing Edge Cases
Vấn đề: Chỉ mô tả happy path. Fix: Luôn hỏi: "Điều gì xảy ra khi...?" - network error, invalid data, concurrent update, timeout.
Mistake 5: Assumption không document
Vấn đề: "Ai cũng hiểu mà" - nhưng mỗi người hiểu khác nhau. Fix: Ghi rõ assumptions trong story. Ví dụ: "Assumption: User đã verify email trước khi checkout".
Mistake 6: Bỏ qua stakeholder quan trọng
Vấn đề: Chỉ hỏi PO, quên operations team, support team, compliance. Fix: Stakeholder mapping - ai bị ảnh hưởng bởi feature này?
Session tiếp theo: Session 08 - Change Management sẽ đi sâu vào quy trình quản lý thay đổi trong dự án phần mềm.