Có một câu nói nổi tiếng trong ngành phần mềm: "If you don't know where you're going, any road will take you there." Requirements Engineering (Kỹ nghệ yêu cầu) chính là la bàn giúp bạn xác định đích đến trước khi bắt đầu hành trình phát triển phần mềm.
Theo nghiên cứu của Standish Group, khoảng 70% dự án phần mềm thất bại không phải do kỹ thuật kém, mà do yêu cầu không rõ ràng hoặc thay đổi liên tục. Đây chính là lý do tại sao Requirements Engineering lại quan trọng đến vậy.
Requirements (yêu cầu) là mô tả về những gì hệ thống cần làm và các ràng buộc mà nó phải tuân theo. Chúng ta chia requirements thành hai loại chính:
Đây là những gì hệ thống phải làm - các tính năng, hành vi cụ thể mà người dùng mong đợi.
Ví dụ thực tế:
Chú ý: Functional requirements nên cụ thể, đo lường được, và tránh mơ hồ. So sánh hai cách viết:
Đây là những ràng buộc về cách thức hệ thống hoạt động - chất lượng, hiệu năng, bảo mật. Chúng thường bị bỏ qua nhưng lại cực kỳ quan trọng.
Các nhóm phổ biến:
Performance (Hiệu năng):
Scalability (Khả năng mở rộng):
Security (Bảo mật):
Usability (Khả năng sử dụng):
Reliability (Độ tin cậy):
Maintainability (Khả năng bảo trì):
Functional requirements quyết định features bạn build. Non-functional requirements quyết định architecture bạn chọn. Ví dụ:
Khơi gợi yêu cầu là nghệ thuật "khai thác" nhu cầu thực sự từ stakeholders. Đây là giai đoạn khó nhất vì:
1. Interviews (Phỏng vấn)
Nói chuyện trực tiếp với stakeholders - từ end-users đến managers.
Tips để phỏng vấn hiệu quả:
2. Observation (Quan sát)
Đôi khi người dùng làm khác với những gì họ nói. Hãy quan sát họ làm việc thực tế.
Ví dụ: Bạn đang làm app cho nhân viên bán hàng. Thay vì chỉ hỏi họ cần gì, hãy đi cùng họ một ngày. Bạn có thể phát hiện:
→ Requirements thực sự: Offline-first mobile app với auto-sync và single data entry.
3. Workshops & Brainstorming
Tập hợp nhiều stakeholders cùng lúc để thảo luận. Kỹ thuật hữu ích:
4. Prototyping
"Show, don't tell." Tạo mockup hoặc prototype để stakeholders visualize được sản phẩm.
Low-fidelity: Wireframes vẽ tay, Figma sketches
High-fidelity: Interactive prototype với Figma/Adobe XD
Lợi ích: Stakeholders dễ feedback hơn khi thấy được giao diện cụ thể, tránh hiểu lầm.
5. Questionnaires & Surveys
Hữu ích khi bạn có nhiều users cần gather feedback, nhưng:
6. Document Analysis
Đọc tài liệu hiện có: user manuals, business processes, competitor analysis, support tickets.
Insight từ support tickets: Nếu 60% tickets là về "quên mật khẩu" → yêu cầu: tích hợp social login hoặc passwordless authentication.
Ai viết: Business Analyst
Đối tượng: Stakeholders, management
Nội dung: HIGH-LEVEL business goals, không đi sâu technical
Cấu trúc điển hình:
Ví dụ BRD requirement: "Tăng tỷ lệ chuyển đổi từ visitor sang customer lên 15% trong Q2 bằng cách đơn giản hóa checkout process."
Ai viết: System Analyst, Technical Lead
Đối tượng: Development team, QA
Nội dung: DETAILED technical specifications
Cấu trúc điển hình:
Ví dụ SRS requirement: "FR-101: Hệ thống cho phép guest checkout không cần đăng ký. User nhập email, shipping address, payment info. Hệ thống validate email format, kiểm tra địa chỉ qua Google Maps API, xử lý payment qua Stripe. Response time < 3s."
Think of it như một pyramid:
BRD được viết trước, sau đó được "refine" thành SRS với technical details.
Scope Creep là hiện tượng requirements liên tục được thêm vào mà không điều chỉnh timeline/budget. Đây là "kẻ thù số 1" của mọi project manager.
1. Baseline Requirements
Sau khi sign-off BRD/SRS, tạo một baseline - bản requirements chính thức được approve. Mọi thay đổi đều phải so sánh với baseline này.
2. Change Request Process
Thiết lập quy trình formal cho mọi thay đổi:
3. MoSCoW Prioritization
Phân loại requirements theo độ ưu tiên:
Khi có change request mới, classify nó vào MoSCoW và trade-off với existing requirements.
4. Timeboxing
Với Agile, fix timeline cho sprint nhưng flexible về scope. Features không hoàn thành được chuyển sang sprint sau.
5. Documentation & Communication
Mọi requirements change phải:
Không phải mọi change đều là "scope creep xấu". Chấp nhận khi:
✅ Involve stakeholders sớm và thường xuyên
Đừng đợi đến cuối mới cho họ xem sản phẩm.
✅ Viết requirements testable
Mỗi requirement nên có acceptance criteria rõ ràng để QA test.
✅ Sử dụng User Stories cho Agile
Format: "As a [role], I want [feature] so that [benefit]."
Example: "As a customer, I want to save items to wishlist so that I can purchase them later."
✅ Traceability Matrix
Map mỗi requirement đến design, code, và test cases. Đảm bảo không có requirement nào bị "lạc mất".
✅ Validation vs Verification
✅ Review & Update thường xuyên
Requirements không phải "khắc trên đá". Review định kỳ để đảm bảo vẫn relevant.
❌ Ambiguous language
Tránh từ mơ hồ như "fast", "user-friendly", "robust". Thay bằng metrics cụ thể.
❌ Goldplating
Không tự ý thêm features mà stakeholder không yêu cầu, kể cả khi bạn nghĩ nó "cool".
❌ Analysis Paralysis
Đừng cố gắng document 100% requirements trước khi bắt đầu code. Với Agile, embrace iterative refinement.
❌ Ignoring Non-Functional Requirements
Nhiều team chỉ focus vào features mà quên security, performance, scalability → technical debt khổng lồ sau này.
Trong bài tiếp theo, chúng ta sẽ khám phá System Design & Design Patterns - cách chuyển requirements thành kiến trúc hệ thống cụ thể và các mẫu thiết kế giúp giải quyết vấn đề tái diễn.
Bài viết thuộc series "From Zero to AI Engineer" - Module 1: Development Process