9. Xác định và Ưu tiên Hóa Yêu cầu
Mục lục
📌 Chương 9.1 – Yêu cầu là gì? – Khái niệm gốc rễ của mọi dự án Agile
🧭 1. Đặt vấn đề: Vì sao phải hiểu đúng khái niệm “Yêu cầu”?
Trong mọi dự án phát triển phần mềm – từ nhỏ đến lớn, từ truyền thống đến Agile – yêu cầu (requirement) luôn là điểm xuất phát. Mỗi dòng mã, mỗi thiết kế, mỗi ca kiểm thử… đều phải xuất phát từ yêu cầu.
Tuy nhiên, nếu không hiểu đúng “yêu cầu là gì”, ta sẽ dễ:
- Viết yêu cầu mơ hồ, không đo lường được
- Phát triển phần mềm sai định hướng
- Bỏ sót những ràng buộc quan trọng
- Giao tiếp kém giữa kỹ thuật và người dùng
Vì thế, hiểu đúng yêu cầu là điều tối quan trọng trong Agile, nơi mà mọi thứ đều xoay quanh giá trị người dùng.
🧩 2. Định nghĩa yêu cầu theo góc nhìn Agile
Một yêu cầu là bất kỳ điều gì hệ thống phải làm, nên làm, hoặc không được làm, để đáp ứng mục tiêu kinh doanh hoặc mong đợi của người dùng.
Yêu cầu có thể là:
| Loại yêu cầu | Ví dụ thực tế |
|---|---|
| 🔹 Tính năng (Function) | “Cho phép người dùng đăng nhập bằng tài khoản Google.” |
| 🔹 Dịch vụ (Service) | “Hệ thống gửi email xác nhận đơn hàng sau khi mua.” |
| 🔹 Ràng buộc (Constraint) | “Phải tuân thủ luật bảo vệ dữ liệu GDPR.” |
📌 Không phải yêu cầu nào cũng là thứ “người dùng muốn thêm” – nhiều khi đó là thứ “người dùng buộc phải có” mà họ không nhận ra.
📋 3. Các đặc điểm của một yêu cầu tốt
Một yêu cầu trong Agile cần được:
- Gắn với mục tiêu kinh doanh cụ thể
- Có nguồn gốc rõ ràng (ai yêu cầu, vì lý do gì)
- Có thể kiểm thử được (tức là xác định được đã làm xong hay chưa)
- Được ưu tiên rõ ràng (không phải yêu cầu nào cũng quan trọng như nhau)
- Có chủ sở hữu – người xác nhận nó đúng hay chưa
Mỗi yêu cầu nên có các thuộc tính:
| Thuộc tính | Mô tả |
|---|---|
| Mã số (ID) | Mỗi yêu cầu có mã riêng (REQ001, REQ045…) |
| Nguồn gốc (Source) | Từ ai? khách hàng, người dùng, quy định? |
| Lợi ích | Giá trị kinh doanh hoặc kỹ thuật mang lại |
| Chủ sở hữu | Người có trách nhiệm xác nhận đúng hay sai |
| Tiêu chí chấp nhận | Điều kiện để xác định yêu cầu được xem là “hoàn tất” |
❗ 4. Những hiểu lầm phổ biến về yêu cầu
| Hiểu lầm | Thực tế |
|---|---|
| “Yêu cầu là danh sách tính năng.” | Không chỉ vậy – còn có luật, ràng buộc, quy trình. |
| “Yêu cầu nên thật chi tiết từ đầu.” | Trong Agile, yêu cầu được làm rõ dần theo từng vòng lặp. |
| “Yêu cầu là cố định.” | Yêu cầu có thể thay đổi theo phản hồi thực tế – Agile chấp nhận điều này. |
| “Yêu cầu là trách nhiệm của BA hoặc khách hàng.” | Yêu cầu là trách nhiệm chung – ai cũng cần hiểu và đóng góp. |
🎯 5. Vai trò của yêu cầu trong Agile
Trong Agile (đặc biệt là DSDM, Scrum, XP…), yêu cầu là:
- Nền tảng để xây dựng Product Backlog
- Cơ sở để viết User Story, Acceptance Criteria
- Gắn liền với giá trị người dùng – từ đó lập kế hoạch theo MoSCoW hoặc Sprint Planning
- Được kiểm thử và phản hồi nhanh trong từng Timebox
💬 Agile không chỉ làm đúng yêu cầu, mà còn làm đúng những yêu cầu cần thiết – đúng lúc.
✅ Tổng kết nội dung
- Yêu cầu là một thực thể trung tâm, định hình toàn bộ hoạt động phát triển.
- Nó bao gồm cả tính năng, dịch vụ và ràng buộc – không chỉ là “chức năng người dùng mong muốn”.
- Mỗi yêu cầu cần có thông tin truy vết rõ ràng, người sở hữu, mức độ ưu tiên và tiêu chí hoàn thành.
- Agile coi yêu cầu là thực thể sống – thay đổi, phân rã, cụ thể dần theo thời gian, song hành cùng giá trị kinh doanh.
🧭 Chương 9.2 – Cách xác định yêu cầu trong Agile
🎯 1. Vì sao việc “xác định yêu cầu” lại quan trọng?
Dù bạn đang phát triển hệ thống đặt vé, ứng dụng ngân hàng hay phần mềm học trực tuyến, bước đầu tiên luôn là hiểu rõ: người dùng cần gì? tổ chức muốn đạt điều gì? Đây là quá trình xác định yêu cầu (requirements elicitation).
Nếu xác định sai:
- Nhóm phát triển sẽ viết mã cho một thứ không ai dùng
- Người dùng thất vọng vì phần mềm “sai sai”
- Doanh nghiệp lãng phí nguồn lực vào thứ vô giá trị
✅ Agile không yêu cầu bạn “ghi tất cả yêu cầu từ đầu”, mà yêu cầu xác định đúng – vào đúng thời điểm cần thiết.
🛠️ 2. Quy trình xác định yêu cầu gồm những bước nào?
Bước 1 – Tìm nguồn yêu cầu (Requirement Sources)
Yêu cầu có thể đến từ:
- Khách hàng, người dùng cuối
- Bộ phận kinh doanh
- Luật pháp, chính sách bảo mật
- Hệ thống cũ (legacy) cần thay thế
- Đội ngũ kỹ thuật, quản lý rủi ro…
📌 Trong Agile, mọi người trong nhóm đều có thể đề xuất yêu cầu mới nếu nó mang lại giá trị.
Bước 2 – Sử dụng kỹ thuật thu thập yêu cầu
| Kỹ thuật | Mô tả | Dùng khi |
|---|---|---|
| 📋 Phỏng vấn | Gặp trực tiếp người dùng để hỏi nhu cầu | Yêu cầu phức tạp, liên quan trải nghiệm |
| 🤝 Workshop | Nhiều bên họp chung, tương tác trực tiếp (Facilitated Workshop) | Dự án lớn, nhiều bên liên quan |
| 🧪 Quan sát | Theo dõi người dùng thật khi làm việc | Dễ áp dụng với hệ thống đang tồn tại |
| 🧠 Tưởng tượng tình huống (Scenario) | Đặt ra kịch bản “nếu … thì …” | Đào sâu insight người dùng |
| 📄 Phân tích tài liệu cũ | Từ hệ thống cũ, hợp đồng, quy định | Yêu cầu bắt buộc, tính kế thừa cao |
Bước 3 – Ghi nhận yêu cầu đúng cách
Mỗi yêu cầu nên được ghi với các thông tin:
| Trường thông tin | Giải thích |
|---|---|
| ID | Mã định danh duy nhất (REQ001, REQ018…) |
| Tên yêu cầu | Ngắn gọn, dễ hiểu |
| Mô tả chi tiết | Nêu rõ “ai cần gì để làm gì” |
| Loại yêu cầu | Chức năng / Phi chức năng / Ràng buộc |
| Nguồn gốc | Ai đề xuất? Dựa vào đâu? |
| Ưu tiên | Must / Should / Could / Won’t |
| Tiêu chí chấp nhận | Khi nào thì xem là “hoàn thành”? |
| Trạng thái | Mới, đã phân tích, đã phê duyệt, đã phát triển… |
📋 Agile ưu tiên tính rõ ràng, đơn giản, dễ hiểu hơn là mô tả dài dòng.
Bước 4 – Kiểm tra và xác nhận lại với người liên quan
- Sau khi ghi nhận, cần xác minh lại yêu cầu:
- Có đúng điều người dùng muốn không?
- Có trùng hoặc mâu thuẫn với yêu cầu khác không?
- Có thể kiểm thử được không?
- Có khả thi về mặt kỹ thuật không?
📌 Agile khuyến khích kiểm tra yêu cầu thông qua nguyên mẫu, thử nghiệm nhỏ (prototype, wireframe) để xác nhận sớm.
🧠 3. Vai trò của mô hình hóa trong xác định yêu cầu
- Mô hình giúp người dùng và nhóm phát triển “thấy” được ý tưởng
- Ví dụ: sơ đồ quy trình (flowchart), giao diện mẫu (wireframe), mô hình dữ liệu (ERD)
🎯 Nhờ mô hình, ta phát hiện mâu thuẫn và sai sót ngay từ giai đoạn sớm, tiết kiệm chi phí và thời gian.
✅ Tổng kết
- Xác định yêu cầu là nền móng của mọi hoạt động Agile
- Cần kết hợp nhiều kỹ thuật: phỏng vấn, workshop, mô hình hóa
- Ghi nhận yêu cầu không chỉ là “viết lại lời người dùng” mà là chuyển nhu cầu thành thông tin có thể phát triển và kiểm thử
- Đừng quên: yêu cầu tốt luôn có nguồn gốc, tiêu chí chấp nhận và mức ưu tiên rõ ràng
💬 “Xác định sai yêu cầu không làm bạn thất bại – nhưng phát hiện sai sau khi đã code thì chắc chắn là tai họa.”
🧩 Chương 9.3 – Yêu cầu Chức năng & Phi chức năng: Cặp đôi không thể thiếu trong Agile
📍 1. Phân biệt hai loại yêu cầu quan trọng nhất
Trong mọi dự án phần mềm, yêu cầu thường chia làm hai loại chính:
| Loại yêu cầu | Mô tả ngắn | Câu hỏi giúp xác định |
|---|---|---|
| 🧭 Chức năng (Functional) | Hệ thống làm gì? | “Người dùng có thể thực hiện hành động gì?” |
| 🎛 Phi chức năng (Non-functional) | Hệ thống làm tốt đến đâu? | “Trải nghiệm ra sao? Giới hạn là gì?” |
📌 Cả hai đều quan trọng: chức năng giúp sản phẩm “làm được việc”, còn phi chức năng giúp “dùng được thoải mái, an toàn và hiệu quả”.
🔹 2. Yêu cầu chức năng – Functional Requirements
📘 Định nghĩa:
Là các hành động mà hệ thống phải thực hiện, nhằm đáp ứng một nhu cầu cụ thể của người dùng hoặc quy trình nghiệp vụ.
📋 Ví dụ thực tế:
- “Người dùng có thể tạo tài khoản.”
- “Hệ thống hiển thị danh sách sản phẩm theo từ khóa tìm kiếm.”
- “Admin có thể xóa người dùng bất kỳ.”
- “Khi đơn hàng được tạo, hệ thống gửi email xác nhận.”
🧾 Mô tả dạng User Story (trong Agile):
Là một [vai trò người dùng], tôi muốn [chức năng cụ thể], để [đạt được mục đích].
Ví dụ:
Là một khách hàng, tôi muốn xem trạng thái đơn hàng, để biết đơn của tôi đã được giao hay chưa.
📌 User Story không nói “hệ thống làm thế nào” – mà chỉ nói “ai cần gì, để làm gì”.
🔸 3. Yêu cầu phi chức năng – Non-Functional Requirements
📘 Định nghĩa:
Là những đặc tính thể hiện chất lượng hoặc giới hạn kỹ thuật của hệ thống, không trực tiếp tạo ra hành động nhưng ảnh hưởng đến trải nghiệm sử dụng.
📋 Ví dụ các loại phổ biến:
| Nhóm | Ví dụ yêu cầu |
|---|---|
| 🔒 Bảo mật | “Người dùng phải xác thực hai lớp khi đăng nhập.” |
| 🚀 Hiệu suất | “Trang dashboard phải tải trong vòng <2 giây với 1000 người dùng đồng thời.” |
| 🧠 Khả năng học & sử dụng | “Người mới chỉ mất 5 phút để hiểu giao diện chính.” |
| 🔧 Khả năng bảo trì | “Code phải tuân theo chuẩn PSR-12 để dễ sửa.” |
| 🌍 Khả năng di động | “Ứng dụng chạy được cả Android và iOS.” |
| 📦 Tính tương thích | “Phần mềm tích hợp được với hệ thống CRM hiện tại.” |
📌 Những yêu cầu này không hiển thị trực tiếp, nhưng nếu không đảm bảo → người dùng sẽ “bỏ chạy”.
⚠️ 4. Lỗi phổ biến khi viết hoặc phân loại yêu cầu
| Lỗi | Mô tả |
|---|---|
| ❌ Viết mơ hồ | “Hệ thống cần nhanh hơn.” → Nhanh là bao nhiêu? với bao nhiêu người dùng? |
| ❌ Lẫn lộn chức năng – phi chức năng | “Người dùng dễ sử dụng” → Không rõ đây là tính năng hay chất lượng? |
| ❌ Bỏ qua yêu cầu phi chức năng | Nhất là bảo mật, hiệu suất, khả năng chịu tải |
✅ Giải pháp: Dùng tiêu chí SMART: Specific, Measurable, Achievable, Relevant, Time-bound
🎯 5. Cách quản lý 2 loại yêu cầu này trong Agile
- Chức năng → ghi dưới dạng User Story trong Product Backlog
- Phi chức năng → có thể ghi thành:
- “Acceptance Criteria” cho từng story
- “Definition of Done” toàn team
- Hoặc thành “Enabler Stories” riêng để theo dõi kỹ thuật
📌 Trong Scrum, không được xem phi chức năng là thứ “để sau” – mà phải đi kèm từ đầu.
✅ Tổng kết chương
- Mọi hệ thống đều cần có chức năng đúng và chất lượng tốt – đó là sự kết hợp giữa 2 loại yêu cầu chính
- Yêu cầu chức năng trả lời “có thể làm gì”, còn phi chức năng trả lời “dùng như thế nào”
- Không quản lý tốt yêu cầu phi chức năng sẽ dẫn đến hệ thống khó dùng, dễ bị lỗi, không mở rộng được
💬 “Tính năng khiến người dùng ở lại – chất lượng khiến họ yêu thích.”
🔍 Chương 9.4 – Phân rã yêu cầu trong từng giai đoạn của vòng đời Agile
🧭 1. Yêu cầu không xuất hiện “một lần duy nhất”
Trong mô hình truyền thống (Waterfall), tất cả yêu cầu thường được viết chi tiết ngay từ đầu dự án. Tuy nhiên, trong Agile – đặc biệt là DSDM – yêu cầu được phân rã dần theo thời gian, tương ứng với mức độ hiểu biết và mức ưu tiên của sản phẩm.
📌 Agile quan niệm: yêu cầu “sống” và “tiến hóa” – không cứng nhắc và đóng băng.
🪜 2. Ba giai đoạn phát triển yêu cầu trong DSDM
| Giai đoạn | Đặc điểm yêu cầu |
|---|---|
| 🔹 Khả thi (Feasibility) | Yêu cầu rất tổng quát, mang tính khái niệm. Ví dụ: “Hệ thống cần hỗ trợ thanh toán trực tuyến.” |
| 🔹 Nền tảng (Foundations) | Bắt đầu phân tích sâu hơn, phân loại theo MoSCoW, xác định tiêu chí chấp nhận, viết user story. |
| 🔹 Phát triển (Exploration + Engineering) | Phân rã cụ thể từng yêu cầu thành chi tiết kỹ thuật, kèm prototype, test case, mockup, v.v. |
🧠 Ví dụ phân rã:
Feasibility: “Cần đăng ký tài khoản”
→ Foundations: “Người dùng có thể đăng ký bằng email hoặc Google”
→ Development: “Form gồm 3 trường; dữ liệu gửi về API/signup; validation gồm: regex email, min-length password,…”
📊 3. Tăng dần độ chi tiết – tăng song song mức truy vết
| Tiêu chí | Feasibility | Foundations | Development |
|---|---|---|---|
| Số lượng yêu cầu | < 100 | 100–200 | > 200 |
| Mức độ chi tiết | Cấp cao | Trung bình | Rất chi tiết |
| Truy vết (traceability) | Theo nhóm chức năng | Theo user story | Theo code, test, logic |
| Định dạng | Gợi ý, mô tả tổng quát | User Story + Acceptance | Task + Mockup + Dev Spec |
📌 Đừng bắt ép yêu cầu phải chi tiết từ đầu – điều đó chỉ làm tốn thời gian và khó thích nghi với thay đổi.
🔧 4. Kỹ thuật phân rã yêu cầu phổ biến
- User Story → Task
Ví dụ: “Người dùng tạo đơn hàng” → task: thiết kế form, tạo API, test, UI validation - Epic → Feature → Story
Epic: “Quản lý đơn hàng”
→ Feature: “Tạo đơn”, “Hủy đơn”, “Xem lịch sử”
→ Story: cụ thể cho từng vai trò, hành vi - Use Case Diagram → Use Case → Flow
Với hệ thống có nhiều tác nhân và nghiệp vụ phức tạp - Prototype → Định nghĩa yêu cầu mới
Dùng mô hình giả lập để “khơi gợi” yêu cầu chưa nói ra
📉 5. Lợi ích khi phân rã yêu cầu theo từng giai đoạn
- Không bị quá tải khi mới bắt đầu dự án
- Tập trung vào phần ưu tiên nhất (MoSCoW)
- Dễ thích nghi với thay đổi từ người dùng
- Giảm chi phí tài liệu hóa sai ngay từ đầu
- Mỗi vòng lặp đều bổ sung yêu cầu theo nhu cầu thực tế
💬 “Chúng ta không cần biết hết mọi thứ để bắt đầu – nhưng cần bắt đầu để biết thêm mọi thứ.”
✅ Tổng kết
- Agile không yêu cầu “biết tất cả yêu cầu ngay từ đầu”
- Yêu cầu được phân rã dần từ khái quát → chi tiết qua các giai đoạn
- Mức độ chi tiết phải tương ứng với thời điểm cần thiết
- Phân rã giúp nhóm linh hoạt, thích nghi và không bị mắc kẹt trong “đống giấy tờ không cập nhật”
🧮 Chương 9.5 – Ưu tiên hóa yêu cầu bằng MoSCoW: Không phải yêu cầu nào cũng quan trọng như nhau
🎯 1. Tại sao cần ưu tiên hóa yêu cầu?
Trong mọi dự án – thời gian, nhân lực và chi phí luôn giới hạn. Không thể thực hiện tất cả yêu cầu ngay từ đầu. Nếu không có sự ưu tiên:
- Tài nguyên bị dàn trải
- Các tính năng “đẹp nhưng không cần” lại hoàn thành sớm hơn cái “cốt lõi”
- Người dùng phải chờ những thứ họ thực sự cần
📌 Agile yêu cầu chúng ta luôn chọn đúng việc cần làm trước, và đó là lý do MoSCoW tồn tại.
🧭 2. MoSCoW là gì?
MoSCoW là một kỹ thuật đơn giản và hiệu quả để phân loại mức độ ưu tiên của yêu cầu trong Agile. Tên gọi là viết tắt (chữ O được thêm để dễ đọc):
| Mức ưu tiên | Ý nghĩa |
|---|---|
| M – Must Have | Bắt buộc có. Nếu thiếu, dự án coi như thất bại |
| S – Should Have | Nên có. Quan trọng nhưng có thể chấp nhận tạm thời không có |
| C – Could Have | Có cũng tốt. Không ảnh hưởng nếu hoãn lại |
| W – Won’t Have (this time) | Sẽ không làm trong bản này. Có thể làm sau, hoặc loại bỏ |
🧪 3. Cách áp dụng MoSCoW trong thực tế
📋 Ví dụ: Dự án làm app đặt lịch khám bệnh
| Yêu cầu | Phân loại |
|---|---|
| Đăng nhập, tạo lịch hẹn | Must Have |
| Gửi thông báo nhắc lịch qua SMS | Should Have |
| Giao diện tối | Could Have |
| Tích hợp hồ sơ sức khỏe quốc gia | Won’t Have (this release) |
💡 Mẹo:
- Đặt câu hỏi: Nếu yêu cầu này không có, hệ thống có dùng được không?
- Cẩn thận: không để mọi thứ thành “Must” – nếu tất cả đều ưu tiên cao, thì… chẳng cái nào thực sự ưu tiên.
🧠 4. Tỷ lệ phân bổ đề xuất trong MoSCoW
| Mức ưu tiên | Tỷ lệ khuyến nghị trong tổng nỗ lực |
|---|---|
| Must Have | ~60% |
| Should Have | ~20% |
| Could Have | ~20% |
| Won’t Have | 0% (chỉ ghi nhận – không làm) |
📌 Tỷ lệ này giúp đảm bảo nguồn lực được tập trung vào cái quan trọng nhất.
🧾 5. Gắn MoSCoW vào vòng đời Agile như thế nào?
- Feasibility: Xác định các “Must” ban đầu để đánh giá khả thi
- Foundations: Phân loại toàn bộ backlog → xây dựng PRL (Prioritised Requirements List)
- Timebox Planning: Chọn từ Must/Should vào mỗi Timebox sao cho đủ khả năng hoàn thành
- Review: Sau mỗi vòng lặp → xem có cần “nâng hạng” hoặc “giảm hạng” yêu cầu không
⚠️ 6. Lỗi phổ biến khi áp dụng MoSCoW
| Lỗi | Hậu quả |
|---|---|
| Tất cả đều là “Must Have” | Mất hiệu quả phân loại, backlog phình to |
| Không có tiêu chí đánh giá “Must” | Mơ hồ, dễ bị áp lực từ nhiều phía |
| Không cập nhật lại MoSCoW sau khi dự án thay đổi | Ưu tiên sai lệch so với thực tế hiện tại |
✅ Giải pháp: MoSCoW không phải phân loại “1 lần rồi để đó” – cần xem lại thường xuyên.
✅ Tổng kết
- MoSCoW là công cụ mạnh mẽ giúp Agile tập trung làm đúng việc, đúng lúc
- Không phải yêu cầu nào cũng quan trọng như nhau – và điều này phải được thể hiện rõ trong backlog
- Áp dụng MoSCoW giúp:
- Ưu tiên hóa rõ ràng
- Lập kế hoạch chính xác
- Giảm tranh cãi và tăng cam kết giữa các bên liên quan
💬 “Bạn không thể làm mọi thứ – nhưng có thể chọn đúng thứ để làm.”
🔄 Chương 9.6 – Quản lý Vòng đời Yêu cầu trong Agile
🎯 1. Yêu cầu không đứng yên – chúng có vòng đời
Trong Agile, yêu cầu không được viết ra một lần rồi kết thúc. Chúng “sống” cùng dự án, cần được:
- Xác định
- Hiểu rõ
- Phân tích
- Xác minh
- Theo dõi
- Cập nhật nếu có thay đổi
📌 Đó là lý do ta cần quản lý vòng đời của yêu cầu (Requirements Lifecycle Management).
🧭 2. Các giai đoạn chính trong vòng đời yêu cầu
| Giai đoạn | Mục tiêu chính | Kết quả đầu ra |
|---|---|---|
| 1. Thu thập (Elicitation) | Khám phá yêu cầu từ người dùng, hệ thống cũ, luật, … | Tập hợp ý tưởng và mong đợi ban đầu |
| 2. Phân tích (Analysis) | Làm rõ nội dung, loại bỏ mâu thuẫn, gắn với giá trị kinh doanh | Yêu cầu rõ ràng, hợp lý, khả thi |
| 3. Xác thực (Validation) | Kiểm tra yêu cầu có đúng nhu cầu không, có khả thi không | Yêu cầu đã được xác nhận với người sở hữu |
| 4. Quản lý (Management) | Theo dõi thay đổi, truy vết yêu cầu đến sản phẩm cuối cùng | Yêu cầu luôn nhất quán và cập nhật |
🧪 3. Các kỹ thuật hỗ trợ từng giai đoạn
| Giai đoạn | Kỹ thuật thường dùng |
|---|---|
| Elicitation | Phỏng vấn, Workshop, Quan sát, Khảo sát |
| Analysis | Mô hình hóa (Use Case, DFD), User Story Mapping |
| Validation | Prototyping, Walkthrough, Acceptance Criteria |
| Management | Backlog grooming, Traceability matrix, Version control |
📌 Agile ưa chuộng các kỹ thuật nhẹ, nhanh, cộng tác cao.
🔗 4. Quản lý sự thay đổi yêu cầu (Change Control)
Trong Agile, thay đổi là điều bình thường, không phải vấn đề.
✔️ Cách xử lý:
- Backlog là tài liệu sống – thay đổi được cập nhật liên tục
- Mỗi thay đổi đều cần: lý do, người yêu cầu, đánh giá tác động
- Nếu phức tạp, dùng “Change Request Form” đơn giản
💬 “Nếu bạn không cho phép thay đổi, bạn sẽ không phát triển đúng sản phẩm. Nhưng nếu bạn không kiểm soát thay đổi, bạn sẽ không phát triển được gì cả.”
🔍 5. Truy vết yêu cầu (Requirement Traceability)
Là khả năng liên kết yêu cầu với các phần khác trong hệ thống, ví dụ:
- User Story → Task → Code
- User Story → Test case
- Business requirement → Product goal → Feature
📌 Việc truy vết giúp:
- Phát hiện thiếu sót
- Đánh giá tác động khi thay đổi
- Đảm bảo kiểm thử đủ (test coverage)
🧠 6. Vai trò của BA / PO / Nhóm phát triển
| Vai trò | Trách nhiệm chính |
|---|---|
| 📊 Business Analyst (BA) | Thu thập, phân tích, mô hình hóa, xác thực yêu cầu |
| 👑 Product Owner (PO) | Ưu tiên, phê duyệt, chấp thuận thay đổi |
| 👥 Development Team | Góp ý về khả thi kỹ thuật, ước lượng, hiện thực hóa yêu cầu |
🧩 Trong Agile, mọi người đều có tiếng nói – nhưng PO là người quyết định cuối cùng.
✅ Tổng kết chương
- Yêu cầu trong Agile có vòng đời – từ ý tưởng đến hiện thực, luôn cần được kiểm soát
- Quản lý yêu cầu tốt giúp:
- Giảm sai sót
- Thích nghi thay đổi
- Tăng giá trị sản phẩm cuối cùng
- Các bước gồm: Thu thập → Phân tích → Xác thực → Quản lý → Truy vết → Kiểm soát thay đổi
💬 “Quản lý yêu cầu không phải là viết tài liệu – mà là đảm bảo đúng điều cần được phát triển.”
