Bỏ qua

Chương 6 – Các Thực hành Quản lý đối với Yêu cầu

CPRE Foundation Level Handbook v1.3.0 — Bản dịch tiếng Việt đầy đủ, sát 100% bản gốc

📋 TỔNG QUAN CHƯƠNG 6

Mức nhận thức tổng thể: L2 | Thời lượng syllabus: 2 giờ

Thuật ngữ chính: requirements management · change management · traceability · requirements attributes · requirements life cycle · prioritization

Section EO Mức Nội dung kiểm tra
6.1 EO 6.1.1 L1 RM là gì, tại sao cần
6.2 EO 6.2.1 L2 Giải thích tại sao cần mô hình vòng đời
6.3 EO 6.3.1 L2 Giải thích versioning trong tình huống cụ thể
6.4 EO 6.4.1 L1 Biết công dụng configuration & baseline
6.5 EO 6.5.1–6.5.3 L1+L2 Attributes, views, attribute schema
6.6 EO 6.6.1–6.6.3 L1 Lý do traceability, implicit vs explicit
6.7 EO 6.7.1 L1 Xử lý thay đổi: linear vs agile
6.8 EO 6.8.1–6.8.3 L1 Lý do, 6 bước, 2 loại kỹ thuật ưu tiên hóa

Yêu cầu không được khắc trên đá, tồn tại vĩnh cửu — chúng là những thực thể sống! Chúng được sinh ra qua khơi gợi (elicitation), lớn lên qua tài liệu hóa, được định hình qua thẩm định (validation). Khi trưởng thành, chúng đi làm qua triển khai, rồi sau một vòng đời vận hành dài lâu và thịnh vượng, chúng nghỉ hưu vào quên lãng. Suốt hành trình đó, cha mẹ của chúng — các Kỹ sư Yêu cầu — luôn đồng hành. Chúng ta nuôi dưỡng từ thời thơ ấu, dạy dỗ trong thời niên thiếu, đồng hành qua các mối quan hệ, và giúp chúng tìm được chỗ đứng trong một hệ thống khỏe mạnh. Đó chính là quản lý yêu cầu (requirements management).

Tất nhiên, có những định nghĩa chính thức hơn. Tiêu chuẩn ISO/IEC/IEEE 29148:2018 [ISO29148] định nghĩa: “Các hoạt động nhằm xác định, tài liệu hóa, bảo trì, giao tiếp, theo dõi và truy xuất các yêu cầu trong suốt vòng đời của một hệ thống, sản phẩm hoặc dịch vụ.” Bảng thuật ngữ CPRE [Glin2025] định nghĩa ngắn gọn hơn: “Quá trình quản lý các yêu cầu hiện có và các sản phẩm công việc liên quan, bao gồm lưu trữ, thay đổi và truy xuất các yêu cầu.” Bảng thuật ngữ này cũng xác định quản lý yêu cầu là một phần không thể thiếu của Kỹ nghệ Yêu cầu: “Cách tiếp cận có hệ thống và kỷ luật đối với việc đặc tả và quản lý các yêu cầu với mục tiêu…”

Quản lý yêu cầu có thể diễn ra ở ba cấp độ:

  • Các yêu cầu đơn lẻ (individual requirements)
  • Các sản phẩm công việc (work products) chứa những yêu cầu này
  • Hệ thống liên quan đến các sản phẩm công việc và yêu cầu trong đó

Trong thực tế, quản lý yêu cầu chủ yếu diễn ra ở cấp sản phẩm công việc. Một sản phẩm công việc có thể chứa nhiều yêu cầu (ví dụ: bản mô tả giao diện bên ngoài), chỉ một yêu cầu (ví dụ: một user story trong dự án agile), hoặc toàn bộ tập yêu cầu của cả hệ thống (ví dụ: bản đặc tả yêu cầu phần mềm). Lưu ý: sản phẩm công việc ở cả ba cấp đều phải được quản lý, và bạn cần nắm rõ quan hệ giữa chúng.

Phần trên trả lời câu hỏi cái gì (what) của quản lý yêu cầu. Phần còn lại của chương này dành cho cách thức (how). Trước khi đi vào chi tiết, cần ghi nhớ một số nguyên tắc nền: muốn quản lý được thứ gì, phải nhận ra nó, lưu trữ nó, và tìm lại nó được. Do đó, định danh duy nhất (unique identification), chuẩn hóa phù hợp, tránh dư thừa, kho lưu trữ trung tâm, và quyền truy cập được kiểm soát là những yêu cầu bắt buộc.

Phần 6.1 xem xét các tình huống ảnh hưởng đến giá trị, tầm quan trọng và nỗ lực của quản lý yêu cầu.

Phần 6.2 theo dõi yêu cầu qua vòng đời, là một phần của sản phẩm công việc mà Kỹ sư Yêu cầu và nhân viên CNTT tạo ra khi phát triển, triển khai và vận hành hệ thống.

Trong vòng đời đó, nhiều phiên bản sản phẩm công việc được tạo ra — bắt đầu từ bản nháp 0.1, sau hàng loạt thay đổi, tiến hóa thành phiên bản cuối, chẳng hạn 3.2. Kiểm soát phiên bản được bàn trong Phần 6.3.

Khi phát triển và vận hành hệ thống CNTT, xử lý từng yêu cầu riêng lẻ là không thực tế. Vì vậy, các tập hợp yêu cầu nhất quán được nhận diện thành cấu hình và đường cơ sở (configurations and baselines), giải thích ở Phần 6.4.

Để xử lý sản phẩm công việc và yêu cầu hiệu quả, cần xác định và thu thập dữ liệu về chúng — chủ đề của Phần 6.5.

Phần 6.6 bàn về truy xuất nguồn gốc (traceability) — một đặc tính chất lượng đặc biệt quan trọng. Không có truy xuất nguồn gốc, không thể liên kết hành vi thực tế của hệ thống với đòi hỏi ban đầu của các bên liên quan.

Phần 6.7 giải quyết vấn đề thay đổi yêu cầu. Ở giai đoạn đầu, thay đổi diễn ra thường xuyên; sau khi thẩm định, yêu cầu nên ổn định. Nhưng thay đổi vẫn sẽ tiếp tục xảy ra — cần có quy trình xử lý rõ ràng.

Các yêu cầu vốn khác nhau về tầm quan trọng và giá trị. Nguồn lực có hạn, không phải mọi yêu cầu đều được triển khai. Các bên liên quan phải quyết định yêu cầu nào làm trước, cái nào để sau — hoặc bỏ qua. Ưu tiên hóa (prioritization), mô tả trong Phần 6.8, hỗ trợ quyết định này.

6.1 Quản lý Yêu cầu là gì? (What is Requirements Management?)

Như đã thấy ở phần giới thiệu, quản lý yêu cầu là quản lý các yêu cầu hiện có và sản phẩm công việc liên quan, bao gồm lưu trữ, thay đổi và truy xuất chúng. Nhưng tại sao phải quản lý?

Yêu cầu là những thực thể sống: chúng được tạo ra, sử dụng, cập nhật và xóa đi trong cả phát triển lẫn vận hành. Suốt vòng đời đó, tất cả các bên cần truy cập được đúng phiên bản của yêu cầu phù hợp với họ. Nếu không quản lý tốt, rủi ro xảy ra là: ai đó bỏ qua yêu cầu, làm việc với phiên bản lỗi thời hoặc phiên bản sai, bỏ qua mối quan hệ giữa các yêu cầu. Hậu quả là hiệu quả và hiệu suất của quá trình phát triển và vận hành hệ thống bị ảnh hưởng nghiêm trọng. Nói cách khác: giá trị của quản lý yêu cầu đúng đắn nằm ở sự cải thiện hiệu quả và hiệu suất của hệ thống.

Giá trị này không thể tách rời khỏi giá trị của hệ thống và bối cảnh dự án. Trong thực tế, mức độ quản lý yêu cầu rất đa dạng [Rupp2020] — từ nhiệm vụ phụ không chính thức của Kỹ sư Yêu cầu với một bảng tính, đến chức năng toàn thời gian của người quản lý yêu cầu chuyên trách với cơ sở dữ liệu được công cụ hỗ trợ.

Nhu cầu quản lý chặt chẽ hơn xuất hiện khi: số lượng yêu cầu, bên liên quan và nhà phát triển tăng lên; vòng đời kỳ vọng dài hơn; yêu cầu chất lượng hoặc tần suất thay đổi cao hơn; quy trình phát triển phức tạp hơn với tiêu chuẩn và quy định nghiêm ngặt hơn, bao gồm cả nhu cầu về dấu vết kiểm toán chi tiết (detailed audit trail).

Thực tế thường gặp: đầu dự án, nhóm nhỏ làm với tập yêu cầu đơn giản nên quản lý bị xem nhẹ. Về sau, độ phức tạp tăng, nhóm mất kiểm soát, dẫn đến vấn đề chất lượng — và tốn rất nhiều công để bắt kịp. Đầu tư vào quản lý yêu cầu ngay từ đầu dự án, với tầm nhìn đến nhu cầu ở giai đoạn cuối, sẽ hiệu quả hơn nhiều.

📌 ÔN THI — 6.1

  • RM = quản lý yêu cầu hiện có: lưu trữ + thay đổi + truy xuất. Không phải tạo mới.
  • Giá trị của RM gắn trực tiếp với giá trị hệ thống và bối cảnh dự án — không có giá trị độc lập.
  • Mức độ RM tăng khi: số requirements tăng, nhiều stakeholders, vòng đời dài, quy trình phức tạp, tiêu chuẩn/quy định nhiều hơn.
  • Đầu tư vào RM từ đầu dự án hiệu quả hơn nhiều so với bắt kịp ở giai đoạn sau.

⚠️ TRAP — 6.1

  • RM ≠ elicitation (khơi gợi) và ≠ validation (thẩm định). Đây là 3 hoạt động riêng biệt.
  • RM không chỉ cần khi dự án lớn — dự án nhỏ cũng cần, chỉ khác mức độ.
  • “Managing requirements” ≠ “creating requirements” — câu hỏi hay đánh lừa điểm này.

🔑 THUẬT NGỮ — 6.1

Requirements management (CPRE Glossary): “The process of managing existing requirements and requirements related work products, including the storing, changing and tracing of requirements.” → Quá trình quản lý các yêu cầu hiện có và sản phẩm công việc liên quan, bao gồm lưu trữ, thay đổi và truy xuất yêu cầu.

6.2 Quản lý Vòng đời (Life Cycle Management)

Yêu cầu và sản phẩm công việc đều có vòng đời. Chúng ta thấy chúng được tạo ra, làm rõ (elaborated), thẩm định (validated), hợp nhất (consolidated), triển khai (implemented), sử dụng, thay đổi, bảo trì, làm lại (reworked), tái cấu trúc (refactored), cho nghỉ hưu (retired), lưu trữ (archived) và/hoặc xóa đi (deleted).

Đó chính là ý nghĩa của vòng đời: một yêu cầu tồn tại ở một trong các trạng thái (states) được xác định, và chỉ có thể chuyển sang các trạng thái khác theo các chuyển đổi trạng thái (state transitions) được định nghĩa trước. Hình 6.1 minh họa biểu đồ trạng thái đơn giản hóa cho vòng đời của một yêu cầu. Để rõ ràng, các chuyển đổi không được gắn nhãn. Ví dụ: chuyển đổi từ Đang được xây dựng (Under construction) sang Đã triển khai (Implemented) có thể được kích hoạt bởi quyết định go-live của product owner. Hai vùng màu xám thể hiện vị trí các nhóm trạng thái trong quy trình phát triển hệ thống tổng thể.

[Hình 6.1 – Biểu đồ trạng thái đơn giản hóa của vòng đời một yêu cầu]

Có hai yếu tố làm phức tạp thêm:

Thứ nhất, sản phẩm công việc và các yêu cầu bên trong có vòng đời riêng biệt, chỉ chồng chéo một phần. Ví dụ: một sản phẩm công việc (definition study) ở trạng thái “đang thay đổi” không có nghĩa tất cả yêu cầu trong đó đều phải thay đổi. Ngược lại, trạng thái “implemented” không có ý nghĩa với toàn bộ sản phẩm công việc — chỉ một số yêu cầu cụ thể mới được triển khai thành mã nguồn.

Thứ hai, mỗi vai trò trong dự án quan tâm đến các trạng thái khác nhau. Kỹ sư Yêu cầu theo dõi đến “validated” là đủ; với người quản lý dự án, vòng đời chỉ có ý nghĩa từ “documented” trở đi.

Kỹ sư Yêu cầu chủ động quản lý vòng đời sản phẩm công việc của mình. Quản lý vòng đời bao gồm:

  • Định nghĩa mô hình vòng đời cho sản phẩm công việc và các yêu cầu trong đó:
  • Các trạng thái có thể có
  • Các chuyển đổi được phép giữa các trạng thái
  • Sự kiện kích hoạt từng chuyển đổi
  • Đảm bảo chỉ các chuyển đổi được phép mới xảy ra
  • Ghi lại trạng thái thực tế của sản phẩm công việc và yêu cầu
  • Ghi lại các chuyển đổi thực tế đã xảy ra
  • Báo cáo về trạng thái và chuyển đổi

Nói ngắn gọn: nắm rõ yêu cầu đang ở trạng thái nào, đã ở đâu, sẽ đi đến đâu, thay đổi thế nào, và tại sao.

💡 Gợi ý: Kỹ sư Yêu cầu có thể được yêu cầu báo cáo ai đã phê duyệt phiên bản nào của một yêu cầu để phát hành cho giai đoạn viết mã. Theo dõi trạng thái còn hữu ích để xây dựng dashboard tiến độ dự án và xác định yêu cầu nào cần xử lý trước.

Trạng thái của sản phẩm công việc thường được ghi nhận qua một thuộc tính (attribute) (xem Phần 6.5). Ghi thêm ngày bắt đầu và kết thúc của từng trạng thái cũng rất hữu ích. Trong dự án agile, trạng thái được suy ra từ vị trí của hạng mục trên product backlog, task backlog hoặc task board. Đáp ứng definition of ready và definition of done về bản chất là đạt được trạng thái tiếp theo.

Mức độ chi tiết của quản lý vòng đời cần được điều chỉnh theo nhu cầu. Với một số dự án, ba trạng thái đơn giản — đang phát triển (under development), trong sản xuất (in production), đã lưu trữ (archived) — là đủ. Với dự án phức tạp hoặc trọng yếu, cần mô hình chi tiết hơn, quy trình chuyển đổi nghiêm ngặt hơn, và dấu vết kiểm toán (audit trail) đầy đủ.

📌 ÔN THI — 6.2 (EO 6.2.1 – L2: phải giải thích được, không chỉ liệt kê)

  • Lý do cần mô hình vòng đời: kiểm soát ai có quyền thay đổi ở từng giai đoạn, báo cáo tiến độ, tổ chức công việc.
  • Work product và individual requirement có vòng đời riêng biệt, chỉ chồng chéo một phần.
  • Mỗi vai trò quan tâm trạng thái khác nhau: RE → đến “validated”; PM → từ “documented” trở đi.
  • Trong agile: trạng thái = vị trí trên backlog / task board + definition of ready / definition of done.

⚠️ TRAP — 6.2

  • Work product ở trạng thái “under change” không đồng nghĩa tất cả requirements bên trong phải thay đổi.
  • Trạng thái “implemented” không có ý nghĩa với toàn bộ work product — chỉ áp dụng cho từng requirement riêng lẻ.
  • Mức độ chi tiết vòng đời phải được tailored theo nhu cầu — không phải lúc nào cũng cần mô hình phức tạp.

🔑 THUẬT NGỮ — 6.2

State transition (chuyển đổi trạng thái): Sự chuyển đổi được định nghĩa trước từ trạng thái này sang trạng thái khác trong vòng đời, được kích hoạt bởi một sự kiện cụ thể.

6.3 Kiểm soát Phiên bản (Version Control)

Việc sản phẩm công việc và yêu cầu thay đổi trong vòng đời là bình thường (xem Phần 6.7). Sau mỗi thay đổi, sản phẩm công việc trở thành một phiên bản mới (new version).

Có hai lý do cần kiểm soát phiên bản:

  • Thay đổi đôi khi gặp trục trặc. Khiếm khuyết phát sinh, hoặc lợi ích kỳ vọng không đạt được. Khi đó, có thể tạo phiên bản mới để sửa, hoặc quay lại phiên bản trước đó. Đôi khi, sau khi suy nghĩ lại, ta đơn giản là thích phiên bản cũ hơn.
  • Cần hiểu lịch sử của sản phẩm công việc — sự tiến hóa từ nguồn gốc đến hiện tại. Điều này giúp đưa ra quyết định về thay đổi tương lai, hoặc giải thích tại sao sản phẩm công việc hiện tại lại là như vậy.

Kiểm soát phiên bản đòi hỏi ba biện pháp:

  • Định danh duy nhất cho mỗi phiên bản, để phân biệt các phiên bản của cùng sản phẩm công việc. Đây là số phiên bản, thường kèm ngày tháng.
  • Mô tả rõ ràng từng thay đổi. Phải nêu và hiểu được sự khác biệt giữa một phiên bản và phiên bản tiền nhiệm. Mô tả này phải gắn kết rõ ràng với số phiên bản.
  • Chính sách lưu trữ nghiêm ngặt, cho phép tìm và lấy lại phiên bản cũ. Trừ khi bị giới hạn lưu trữ, nên giữ lại tất cả phiên bản trước — mất đi thì không thể phục hồi khi cần. Mặt khác, lưu trữ không giới hạn hiếm khi khả thi, nên cũng cần chính sách dọn dẹp sản phẩm công việc không còn dùng đến.

Thông thường, một sản phẩm công việc chứa nhiều yêu cầu. Nếu chỉ một yêu cầu thay đổi, cả yêu cầu đó lẫn sản phẩm công việc đều cần số phiên bản mới, trong khi các yêu cầu không đổi giữ nguyên số cũ. Điều này nhanh chóng gây rối. Giải pháp thực tế: chỉ đánh số phiên bản ở cấp sản phẩm công việc, để tất cả yêu cầu bên trong kế thừa số phiên bản và lịch sử thay đổi.

Số phiên bản thường gồm (ít nhất) hai phần:

  • Version (phiên bản): Bắt đầu từ 0 khi đang phát triển. Khi được phê duyệt chính thức, phát hành hoặc ra mắt, gán version 1. Sau đó chỉ tăng khi có cập nhật lớn, có thực chất.
  • Increment (phần tăng): Bắt đầu từ 1, tăng theo mỗi thay đổi nhỏ có thể thấy từ bên ngoài — về nội dung hoặc chỉ mang tính văn bản, biên tập. Sub-increment dùng riêng cho sửa lỗi đánh máy. Increment 9 đôi khi ký hiệu phiên bản cuối cùng trước khi phê duyệt hoặc phát hành.

Mỗi thay đổi chính thức được gán một số phiên bản mới.

Lưu ý: thay đổi trạng thái vòng đời không phải lý do để tăng số phiên bản, trừ khi kèm theo thay đổi nội dung hoặc văn bản. Ví dụ: yêu cầu nhận trạng thái “validated” và số phiên bản 1.0 sau khi phê duyệt. Khi trạng thái chuyển sang “under construction” rồi “implemented” mà không có thay đổi nội dung, số phiên bản không cần thay đổi. Cuối cùng có thể đến “archived” mà vẫn giữ nguyên số 1.0.

📌 ÔN THI — 6.3 (EO 6.3.1 – L2: áp dụng vào tình huống cụ thể)

  • 2 lý do cần version control: (1) rollback khi thay đổi sai; (2) hiểu lịch sử tiến hóa để hỗ trợ quyết định tương lai.
  • 3 biện pháp bắt buộc: định danh phiên bản + mô tả thay đổi gắn với số phiên bản + chính sách lưu trữ nghiêm ngặt.
  • Cấu trúc: Version (0 → 1 khi phát hành, tăng khi cập nhật lớn) + Increment (tăng mỗi thay đổi nhỏ).
  • Nên đánh version ở cấp work product, để requirements kế thừa — tránh rối.

⚠️ TRAP — 6.3

  • Thay đổi trạng thái vòng đời KHÔNG làm tăng version number, trừ khi kèm theo thay đổi nội dung/văn bản.
  • Lý do thứ 2 là “biết lịch sử” — không phải “tạo nền tảng cho phát triển tiếp theo”.

🔑 THUẬT NGỮ — 6.3

Version control (kiểm soát phiên bản): Quá trình theo dõi sản phẩm công việc qua quá trình tiến hóa. Mọi thay đổi phải được phản ánh bằng một phiên bản mới.

Version number (số phiên bản): Định danh duy nhất của một phiên bản cụ thể, thường gồm ít nhất hai phần: version và increment.

6.4 Cấu hình và Đường cơ sở (Configurations and Baselines)

Giả sử bạn lưu trữ toàn bộ phiên bản của tất cả yêu cầu theo khuyến nghị ở trên. Kết quả là một cơ sở dữ liệu ngày càng phình to, và bạn bắt đầu mất kiểm soát. Một ngày, khách hàng đến hỏi: “Chúng tôi đã triển khai hệ thống tại tất cả chi nhánh. Có vấn đề với các phép tính tại văn phòng Barcelona. Phiên bản nào của các yêu cầu tính toán đang được dùng ở đó?” Nếu không trả lời được, đó là lúc bạn ước gì đã chú ý hơn đến quản lý cấu hình (configuration management).

Vậy cấu hình (configuration) là gì? Định nghĩa đầy đủ có trong bảng thuật ngữ CPRE [Glin2025]. Ngắn gọn lại: với Kỹ sư Yêu cầu, cấu hình là một tập hợp nhất quán các sản phẩm công việc có liên hệ logic với nhau, chứa các yêu cầu. Tập hợp này được chọn có chủ đích — thường để làm rõ yêu cầu nào đang hoặc đã có hiệu lực trong một tình huống cụ thể.

Một cấu hình đúng cần có năm thuộc tính:

  • Có liên hệ logic (Logically connected): Các yêu cầu thuộc về nhau trong phạm vi một mục tiêu nhất định.
  • Nhất quán (Consistent): Không có mâu thuẫn nội bộ và có thể tích hợp vào hệ thống.
  • Duy nhất (Unique): Cả cấu hình lẫn từng yêu cầu trong đó đều được xác định rõ ràng.
  • Không thể thay đổi (Unchangeable): Mỗi yêu cầu được chọn với một phiên bản cố định, không bao giờ thay đổi trong cấu hình này.
  • Cơ sở để thiết lập lại (Basis for reset): Cho phép quay lại cấu hình trước nếu xảy ra thay đổi không mong muốn.

Cấu hình được tài liệu hóa như sản phẩm công việc thông thường — có định danh duy nhất, trạng thái, số phiên bản và ngày. Tuy nhiên vì bản chất không thể thay đổi, cấu hình luôn chỉ có một phiên bản duy nhất (ví dụ: 1.0).

Một cấu hình có hai chiều kích (dimensions) [CoWe1998]:

Chiều kích sản phẩm (The product dimension)

Xác định yêu cầu nào được đưa vào cấu hình. Đôi khi gồm tất cả yêu cầu hiện có, nhưng thường là một tập con — ví dụ: toàn bộ yêu cầu triển khai cho thị trường Pháp. Bản phát hành cho thị trường Anh (British release) của cùng hệ thống có thể có cấu hình khác.

Chiều kích phiên bản (The version dimension)

Trong một cấu hình, mỗi yêu cầu chỉ xuất hiện ở đúng một phiên bản — có thể là mới nhất hoặc cũ hơn, tùy mục đích. Chỉ cần một yêu cầu đổi sang phiên bản khác là đã tạo ra cấu hình mới.

[Hình 6.2 – Ví dụ về các cấu hình]

Hình trên minh họa các cấu hình khác nhau của cùng một hệ thống với 9 yêu cầu. Một số vẫn đang phát triển (ví dụ R6 v0.1); một số đã có nhiều phiên bản (ví dụ R1 v2.0). Cấu hình bên trái là cấu hình đang chạy trong môi trường sản xuất: R1 v2.0, R2 v1.0, R3 v1.2 (có hai cập nhật nhỏ sau triển khai), R5 v2.0, R7 v1.0, R9 v1.0. R4, R6, R8 đang phát triển, không có mặt ở đây, cũng như các phiên bản mới của R7 và R9.

Cấu hình bên phải là cấu hình trong môi trường kiểm thử tại cùng thời điểm: R1 và R2 giống nhau; R3 và R5 không còn; R4, R6, R8 được đưa vào; R7 và R9 ở phiên bản cao hơn so với môi trường sản xuất.

Một số cấu hình được đối xử đặc biệt trong dự án — gọi là đường cơ sở (baselines). Baseline là cấu hình ổn định, đã được thẩm định và kiểm soát thay đổi, đánh dấu một cột mốc trong dự án. Ví dụ: cấu hình cuối giai đoạn thiết kế ngay trước khi bắt đầu viết mã, hoặc cấu hình tại thời điểm go-live.

Trong dự án agile, sprint backlog là baseline đầu vòng lặp tiếp theo. Baseline hữu ích cho lập kế hoạch vì là điểm xuất phát ổn định. Chúng thường được đóng băng như một mỏ neo. Nếu có gì sai nghiêm trọng, nhóm có thể roll-back về trạng thái của baseline và khởi động lại.

Với Kỹ sư Yêu cầu, cấu hình chủ yếu liên quan đến sản phẩm công việc chứa yêu cầu. Nhưng trong thực tế, cấu hình dự án rộng hơn nhiều — bao gồm yêu cầu, thiết kế, mã nguồn, test case của toàn bộ nhóm. Trong dự án phức tạp, quản lý cấu hình có thể là công việc toàn thời gian, cần công cụ chuyên dụng.

📌 ÔN THI — 6.4 (EO 6.4.1 – L1)

  • Configuration = tập hợp nhất quán các work product, mỗi requirement ở đúng một phiên bản.
  • 5 thuộc tính: Logically connected · Consistent · Unique · Unchangeable · Basis for reset.
  • Baseline = configuration ổn định + đã thẩm định + kiểm soát thay đổi → đánh dấu cột mốc dự án.
  • Trong agile: sprint backlog = baseline đầu vòng lặp tiếp theo.
  • Configuration chỉ có một phiên bản duy nhất (ví dụ: 1.0).
  • Hai chiều kích: product dimension (requirements nào) + version dimension (phiên bản nào).

⚠️ TRAP — 6.4

  • Baseline ≠ version của một requirement đơn lẻ — baseline là cấu hình của tập hợp requirements.
  • Chỉ cần một requirement đổi phiên bản → đây là configuration mới hoàn toàn.
  • Thay đổi vào baseline đã phát hành → phải tạo baseline mới, không sửa trực tiếp.
  • Trước khi thay đổi requirements đã có baseline → phải phân tích tác động (impact analysis) trước.

Câu thi thực tế (A0804): “Mô tả đúng nhất về baseline?” ✅ C) A released configuration of requirements — đáp án đúng.

🔑 THUẬT NGỮ — 6.4

Configuration (CPRE Glossary): “A consistent set of work products that contain requirements.” — Tập hợp nhất quán các sản phẩm công việc chứa yêu cầu.

Baseline (CPRE Glossary): “A stable, change-controlled configuration of work products, used for release planning or other delivery milestones in a project.” — Cấu hình ổn định, được kiểm soát thay đổi, dùng cho lập kế hoạch phát hành hoặc các cột mốc bàn giao.

6.5 Thuộc tính và Khung nhìn (Attributes and Views)

Đầu ra của Kỹ sư Yêu cầu là các sản phẩm công việc chứa yêu cầu. Để quản lý các yêu cầu đó, cần thu thập và duy trì dữ liệu về chúng — gọi là siêu dữ liệu (metadata), tức dữ liệu về dữ liệu. Siêu dữ liệu giúp sản phẩm công việc trở nên hữu hình và có thể quản lý được. Nhờ đó, ta có thể trả lời các câu hỏi như: “Yêu cầu nào được lên kế hoạch cho bản phát hành tiếp theo?”, “Bản phát hành này tốn bao nhiêu công sức?”, “Có bao nhiêu yêu cầu có độ ưu tiên cao?”

Khi xem yêu cầu là thực thể cần thu thập thông tin, các đặc tính của chúng được gọi là thuộc tính (attributes). Một số thuộc tính phổ biến đã đề cập: định danh duy nhất, số phiên bản, trạng thái, ngày tháng. Thuộc tính nào cần có phụ thuộc vào nhu cầu thông tin của các bên liên quan. Ngay từ đầu dự án, cần thiết lập một lược đồ thuộc tính (attribute schema) để đáp ứng các nhu cầu này.

Tiêu chuẩn ISO [ISO29148] là điểm khởi đầu tốt, với 8 thuộc tính được khuyến nghị:

  • Định danh (Identification): Mỗi yêu cầu cần có định danh duy nhất, bất biến — số, tên hoặc ký hiệu gợi nhớ (mnemonic). Không có định danh phù hợp, quản lý yêu cầu gần như không thực hiện được.
  • Độ ưu tiên của bên liên quan (Stakeholder priority): Mức độ ưu tiên đã được thống nhất từ góc nhìn bên liên quan. Xem Phần 6.8 để biết cách xác định.
  • Phụ thuộc (Dependency): Đôi khi yêu cầu phụ thuộc lẫn nhau. Một yêu cầu ưu tiên thấp có thể phải làm trước vì yêu cầu ưu tiên cao hơn phụ thuộc vào nó.
  • Rủi ro (Risk): Khả năng triển khai gây ra vấn đề — thiệt hại, chi phí phát sinh, chậm trễ, khiếu kiện. Đây là ước tính, cần được thống nhất giữa các bên liên quan.
  • Nguồn gốc (Source): Yêu cầu xuất phát từ đâu? Thông tin này cần cho thẩm định, giải quyết mâu thuẫn, sửa đổi hoặc xóa bỏ.
  • Lý do (Rationale): Tại sao yêu cầu này cần thiết? Mục tiêu nào của bên liên quan cần được đáp ứng?
  • Độ khó (Difficulty): Ước tính công sức triển khai. Cần cho lập kế hoạch và ước tính dự án.
  • Loại (Type): Yêu cầu chức năng (functional), yêu cầu chất lượng (quality) hay ràng buộc (constraint)?

Thông tin này có thể lưu trong tài liệu, bảng tính hoặc cơ sở dữ liệu — yêu cầu là hàng, thuộc tính là cột. Trong agile, yêu cầu ghi trên story card với tiêu đề thẻ là các thuộc tính. Công cụ quản lý yêu cầu (xem Chương 7) cần hỗ trợ lưu trữ và báo cáo dữ liệu này.

Thuộc tính giúp báo cáo về sản phẩm công việc và yêu cầu. Cách đơn giản nhất là xuất báo cáo đầy đủ với mọi dữ liệu. Nhưng với hệ thống phức tạp hơn mức tối giản, báo cáo kiểu đó vô dụng — quá nhiều thông tin, không ai đọc nổi. Thay vào đó, cần điều chỉnh báo cáo theo nhu cầu của từng đối tượng, thông qua khung nhìn (views) [Glin2025].

Một khung nhìn là cách (thường được định nghĩa trước) để lọc và sắp xếp dữ liệu — tạo ra báo cáo hiển thị đúng những gì đối tượng cần, không thừa không thiếu. Mỗi khung nhìn được định nghĩa với mục đích rõ ràng: cung cấp thông tin phù hợp cho một nhóm mục tiêu cụ thể.

Có ba loại khung nhìn:

  • Khung nhìn chọn lọc (Selective views): Hiển thị thông tin về một tập con được chọn của yêu cầu. Ví dụ: chỉ phiên bản mới nhất, chỉ yêu cầu trạng thái “validated”, chỉ yêu cầu ưu tiên cao, hoặc ngược lại — chỉ yêu cầu cấp cao để có cái nhìn tổng quan toàn hệ thống.
  • Khung nhìn chiếu (Projective views): Hiển thị một tập con thuộc tính — ví dụ chỉ định danh, số phiên bản và tên.
  • Khung nhìn tổng hợp (Aggregating views): Hiển thị tóm tắt, tổng số hoặc giá trị trung bình — ví dụ: tổng số yêu cầu theo bộ phận (4 từ Sales, 5 từ Logistics).

[Hình 6.3 – Các loại khung nhìn khác nhau]

Thực tế thường kết hợp nhiều loại — ví dụ: danh sách ID, số phiên bản, tên và loại (= chiếu) của tất cả yêu cầu thuộc Sales (= chọn lọc).

📌 ÔN THI — 6.5 (EO 6.5.1–6.5.3)

  • 8 thuộc tính ISO [ISO29148] — nhớ đủ tên + công dụng:
Thuộc tính Mục đích
Identification Định danh duy nhất, bất biến
Stakeholder priority Độ ưu tiên đã được thống nhất
Dependency Phụ thuộc giữa các requirements
Risk Khả năng gây vấn đề khi triển khai
Source Nguồn gốc (dùng cho validation, conflict resolution)
Rationale Lý do tại sao requirement cần thiết
Difficulty Ước tính công sức triển khai
Type Functional / Quality / Constraint
  • 3 loại views: Selective (lọc requirements) · Projective (lọc cột/thuộc tính) · Aggregating (tổng hợp/thống kê).
  • Thực tế thường dùng kết hợp nhiều loại.
  • Attribute schema nên thiết lập ngay từ đầu dự án.

⚠️ TRAP — 6.5

  • Unique identifier KHÔNG dùng để ước tính kích thước tổng thể đặc tả — bẫy hay xuất hiện trong câu K0821.
  • Difficulty ≠ Risk: Difficulty là công sức, Risk là khả năng xảy ra vấn đề.
  • Selective = lọc hàng (requirements nào); Projective = lọc cột (thuộc tính nào) — đừng nhầm.

🔑 THUẬT NGỮ — 6.5

Attribute (thuộc tính): Đặc tính của một yêu cầu, dùng để thu thập và duy trì siêu dữ liệu phục vụ quản lý yêu cầu.

View (CPRE Glossary): “An (often predefined) way to filter and sort the data on your work products, resulting in a report that shows precisely what the audience needs.” — Cách lọc và sắp xếp dữ liệu, tạo báo cáo hiển thị đúng những gì đối tượng cần.

6.6 Truy xuất nguồn gốc (Traceability)

Truy xuất nguồn gốc [GoFi1994] là chủ đề xuyên suốt cuốn sổ tay này. Thiếu truy xuất nguồn gốc, Kỹ nghệ Yêu cầu gần như không thực hiện được vì bạn sẽ không thể:

  • Cung cấp bằng chứng rằng một yêu cầu được đáp ứng
  • Chứng minh yêu cầu đã được triển khai bằng phương tiện nào
  • Chứng minh sản phẩm tuân thủ luật và tiêu chuẩn hiện hành
  • Tìm ra sản phẩm công việc còn thiếu (ví dụ: test case có đủ cho tất cả yêu cầu không?)
  • Phân tích tác động của một thay đổi lên các yêu cầu (xem Phần 6.7)

Với hệ thống an toàn then chốt (safety-critical), nhiều tiêu chuẩn quy trình còn bắt buộc triển khai truy xuất nguồn gốc.

Có ba loại câu hỏi mà truy xuất nguồn gốc có thể trả lời (xem Hình 6.4):

  • Truy xuất ngược (Backward traceability): Yêu cầu này từ đâu đến? Nguồn nào (bên liên quan, tài liệu, hệ thống khác) đã được phân tích trong khơi gợi? Còn gọi là pre-requirements specification traceability.
  • Truy xuất tiến (Forward traceability): Yêu cầu này được dùng ở đâu? Sản phẩm chuyển giao nào (module code, test case, thủ tục, sổ tay) dựa trên nó? Còn gọi là post-requirements specification traceability.
  • Truy xuất giữa các yêu cầu (Traceability between requirements): Yêu cầu khác có phụ thuộc vào yêu cầu này không — hoặc ngược lại? Yêu cầu có phải là sự làm mịn (refinement) của yêu cầu cấp cao hơn không (ví dụ: epic → user stories → acceptance criteria)?

[Hình 6.4 – Các loại truy xuất nguồn gốc]

Có hai cách tài liệu hóa truy xuất nguồn gốc:

Ngầm định (Implicitly) — qua cấu trúc tài liệu, biểu mẫu chuẩn hoặc quy ước đặt tên. Một số ví dụ:

  • Đặt tên yêu cầu theo mã Req-xxx-nnn, trong đó xxx là bộ phận yêu cầu. Khi đó Req-sal-012 ngay lập tức cho biết đây là yêu cầu của Sales → đó là truy xuất ngược ngầm định.
  • Xuất bản danh sách tất cả yêu cầu sẽ đưa vào bản phát hành ngày 1 tháng 7 → truy xuất tiến ngầm định.
  • Viết tài liệu có phần riêng về tính toán giá cả → truy xuất giữa các yêu cầu.

Tường minh (Explicitly) — tài liệu hóa trực tiếp mối quan hệ dựa trên định danh duy nhất. Thực hiện qua [HuJD2011]:

  • Thuộc tính Source theo đề xuất của ISO [ISO29148]
  • Tham chiếu trong tài liệu đến tài liệu tiền nhiệm hoặc yêu cầu riêng lẻ
  • Ma trận truy xuất nguồn gốc (traceability matrix) trong bảng tính hoặc cơ sở dữ liệu (xem Bảng 6.1)
  • Hyperlink kiểu Wiki trong tài liệu văn bản
  • Biểu đồ dấu vết (trace graph) trực quan hóa các mối quan hệ

Công cụ quản lý yêu cầu hoặc quản lý cấu hình (xem Chương 7) thường có chức năng hỗ trợ truy xuất nguồn gốc. Với dự án lớn — đặc biệt kết hợp đánh số phiên bản — quản lý truy xuất có thể rất phức tạp. Lúc đó, công cụ tốt là không thể thiếu.

Bảng 6.1 – Ví dụ về ma trận truy xuất nguồn gốc

Source R1 R2 R3 R4 R5 R6 R7
Interview Mrs. Smith 06/08 X X X
Summary questionnaire May 12 X X X X
Field observation report 07/03 X X X
Company regulations version 17.a.02 X X X
Documentation API HRM system v3.0.2.a X X X

📌 ÔN THI — 6.6 (EO 6.6.1–6.6.3)

  • 5 lý do cần traceability (thiếu 1 là sai):
  • Bằng chứng requirement được đáp ứng
  • Chứng minh requirement đã triển khai bằng phương tiện nào
  • Tuân thủ pháp luật và tiêu chuẩn
  • Tìm work product bị thiếu (ví dụ: test case)
  • Phân tích tác động thay đổi (impact analysis)
  • 3 loại: Backward (← nguồn gốc) · Forward (→ nơi dùng) · Between requirements (← → phụ thuộc nhau).
  • Implicit = qua cấu trúc tài liệu, quy ước đặt tên.
  • Explicit = dựa trên unique ID: attribute Source / tham chiếu / traceability matrix / hyperlink / trace graph.

⚠️ TRAP — 6.6

  • Traceability KHÔNG hỗ trợ “xuất dữ liệu từ công cụ quản lý yêu cầu” — bẫy câu A0820.
  • Backward = pre-RS traceability; Forward = post-RS traceability — nhớ đúng tên kỹ thuật.
  • Với hệ thống safety-critical, traceability là bắt buộc theo tiêu chuẩn.

🔑 THUẬT NGỮ — 6.6

Traceability (CPRE Glossary): “The ability to trace a requirement back to its origin and forward to subsequent work products, as well as to other requirements that this requirement depends on.” → Khả năng truy xuất yêu cầu ngược về nguồn gốc, tiến đến sản phẩm công việc tiếp theo, và đến các yêu cầu mà nó phụ thuộc vào.

Traceability matrix (ma trận truy xuất nguồn gốc): Bảng tài liệu hóa tường minh mối quan hệ giữa requirements và nguồn gốc/artifacts liên quan.

6.7 Xử lý Thay đổi (Handling Change)

“Nguyên tắc 7: Chào đón các yêu cầu thay đổi, thậm chí muộn trong quá trình phát triển. Agile khai thác sự thay đổi vì lợi thế cạnh tranh của khách hàng.” [BeeA2001]

Những người sáng lập phong trào agile nói thẳng: thay đổi yêu cầu sẽ luôn xảy ra, dù muốn hay không. Nhiều người ngại thay đổi vì nó là rủi ro, mối đe dọa với sự ổn định của dự án.

Nhưng thay đổi yêu cầu không phải sự kiện độc lập — nó được kích hoạt bởi bối cảnh bên ngoài thay đổi. Một đạo luật mới có hiệu lực, thêm ràng buộc cho hệ thống. Thị trường phát triển đòi hiệu suất cao hơn. Đối thủ tung ra tính năng hấp dẫn mà khách hàng cũng muốn có. Hay đơn giản là bên liên quan có nhận thức mới sau quá trình phát triển. Thay đổi phải được nhìn nhận là cơ hội để có hệ thống tốt hơn, tạo thêm giá trị cho người dùng.

Nhưng dù là cơ hội, mọi thay đổi đều mang rủi ro: có thể đưa vào khiếm khuyết, làm chậm tiến độ, tốn thêm chi phí, người dùng từ chối tiếp nhận. Vì vậy, thay đổi không phải thứ cần tránh — nhưng mọi thay đổi phải được xử lý cẩn thận để đạt giá trị tối ưu ở chi phí chấp nhận được với rủi ro tối thiểu.

Trong tài liệu quản lý dịch vụ CNTT [Axelos2019], kích hoạt thay đổi (change enablement) là một thực hành cốt lõi. Nó đảm bảo thay đổi được triển khai hiệu quả, an toàn và kịp thời, cân bằng giữa hiệu quả, thông lượng, tuân thủ và kiểm soát rủi ro. Ba khía cạnh trọng tâm:

  • Đảm bảo rủi ro đã được đánh giá chính xác
  • Ủy quyền cho thay đổi tiến hành
  • Quản lý việc triển khai thay đổi

Kích hoạt thay đổi yêu cầu tổ chức chỉ định một thẩm quyền thay đổi (change authority) và định nghĩa quy trình xử lý. Xem Hình 6.5. Các biện pháp được điều chỉnh theo phương pháp phát triển và thời điểm xảy ra thay đổi.

[Hình 6.5 – Quy trình kích hoạt thay đổi]

Khi yêu cầu còn ở trạng thái bản nháp (draft): Tác giả tự quyết, không cần quy trình nghiêm ngặt.

Khi yêu cầu đã được phát hành để dùng trong dự án: Tác giả không còn tự do quyết định vì mọi thay đổi sẽ ảnh hưởng đến các sản phẩm công việc khác dựa trên yêu cầu đó. Trước khi quyết định có triển khai thay đổi không, phải thực hiện phân tích tác động (impact analysis) — đây là lúc truy xuất nguồn gốc là không thể thiếu.

Trong phát triển tuyến tính, thẩm quyền thay đổi thuộc về quản lý dự án, ban chỉ đạo hoặc Ban Kiểm soát Thay đổi (Change Control Board). Một quy trình chính thức được tuân theo với quyết định và lập kế hoạch rõ ràng. Trong phát triển lặp lại, thẩm quyền thuộc về product owner — người quyết định và đưa thay đổi được chấp nhận vào product backlog như hạng mục mới, sau đó xử lý như bất kỳ backlog item nào khác.

Khi yêu cầu đã triển khai trong hệ thống đang vận hành: Quy trình càng nghiêm ngặt hơn vì thay đổi tác động đến người dùng và quy trình nghiệp vụ.

Ở giai đoạn này, phân biệt ba loại thay đổi:

  • Thay đổi tiêu chuẩn (Standard change): Rủi ro thấp, được hiểu rõ và ủy quyền trước — ví dụ: thay đổi thuế VAT.
  • Thay đổi thông thường (Normal change): Dựa trên Request for Change chính thức, được lên lịch, đánh giá và ủy quyền — ví dụ: thay đổi thuật toán tính giá.
  • Thay đổi khẩn cấp (Emergency change): Cần triển khai ngay để giải quyết sự cố — nhưng hiếm khi liên quan đến thay đổi yêu cầu.

Thẩm quyền thay đổi thường thuộc về Hội đồng Tư vấn Thay đổi (Change Advisory Board) [Math2019]. Trong DevOps và cách tiếp cận lặp lại, thay đổi có thể được ủy quyền bởi release manager.

📌 ÔN THI — 6.7 (EO 6.7.1 – L1)

  • Thay đổi = cơ hội cải thiện hệ thống. Nhưng phải xử lý cẩn thận.
  • 3 giai đoạn & thẩm quyền:
Giai đoạn Thẩm quyền
Draft Tác giả tự quyết
Released (phát hành cho dự án) Linear: CCB / Iterative: Product Owner
Operational (vận hành) Change Advisory Board / Release Manager
  • Impact analysis bắt buộc khi requirement đã phát hành → traceability là nền tảng.
  • 3 loại thay đổi khi vận hành: Standard · Normal · Emergency (hiếm khi thay đổi requirements).

⚠️ TRAP — 6.7

  • Emergency change hiếm khi liên quan đến thay đổi requirements — đừng nhầm là luôn liên quan.
  • Change request có thể gửi bất kỳ lúc nào, nhưng phải xử lý trong baseline tương lai.
  • Dù development chưa bắt đầu, thay đổi baseline vẫn cần tạo baseline mới.

🔑 THUẬT NGỮ — 6.7

Change enablement (kích hoạt thay đổi): Thực hành đảm bảo thay đổi được triển khai hiệu quả, an toàn và kịp thời, cân bằng giữa hiệu quả, thông lượng, tuân thủ và kiểm soát rủi ro.

Change Control Board (CCB) — Ban Kiểm soát Thay đổi: Thẩm quyền thay đổi trong cách tiếp cận tuyến tính.

Change Advisory Board (CAB) — Hội đồng Tư vấn Thay đổi: Thẩm quyền thay đổi khi hệ thống vận hành.

6.8 Ưu tiên hóa (Prioritization)

Yêu cầu chỉ là khái niệm trong tâm trí. Chúng chỉ tạo ra giá trị khi được triển khai trong hệ thống vận hành — và điều đó tiêu tốn công sức, thời gian, tiền bạc, sự chú ý. Nguồn lực luôn có hạn, không thể triển khai tất cả cùng lúc. Vì vậy, các bên liên quan phải quyết định yêu cầu nào làm trước, cái nào để sau — hoặc bỏ qua hẳn. Đó là ưu tiên hóa (prioritization) [Wieg1999].

Độ ưu tiên của yêu cầu là mức độ quan trọng được gán cho nó theo các tiêu chí nhất định [Glin2025]. Để ưu tiên hóa được, trước tiên phải xác định tiêu chí đánh giá. Muốn xác định tiêu chí, phải biết mục tiêu là gì. Mục tiêu thường là của các bên liên quan, không phải của Kỹ sư Yêu cầu — nên cần xác định ai tham gia. Khi đã rõ mục tiêu của họ, thường cũng rõ luôn rằng không phải toàn bộ yêu cầu cần ưu tiên hóa — mà chỉ một tập con được xác định theo mục tiêu đó.

Có 6 bước để ưu tiên hóa yêu cầu:

Bước 1 – Xác định mục tiêu và ràng buộc chính

Bối cảnh dự án quyết định phần lớn lý do ưu tiên hóa. Chọn tính năng cho bản phát hành tiếp theo → tập trung vào business value. Chọn user story cho vòng lặp → story points và phụ thuộc kỹ thuật quan trọng hơn. Ràng buộc kỹ thuật hoặc pháp lý có thể giới hạn lựa chọn.

Bước 2 – Xác định tiêu chí đánh giá

Tiêu chí phụ thuộc mục tiêu và ràng buộc. Các tiêu chí thường dùng: business value, tính khẩn cấp từ góc nhìn người dùng, công sức triển khai, rủi ro khi sử dụng, phụ thuộc logic và kỹ thuật, ràng buộc pháp lý, hoặc sở thích chủ quan (mang tính liên cá nhân) của bên liên quan. Đôi khi chỉ dùng một tiêu chí, nhưng kết hợp cân bằng nhiều tiêu chí thường cho kết quả tốt hơn.

Bước 3 – Xác định bên liên quan tham gia

Mục tiêu ảnh hưởng đến việc mời ai — nhưng chính bên liên quan lại đặt ra mục tiêu, nên có sự phụ thuộc lẫn nhau cần nhận thức rõ. Ví dụ: ưu tiên hóa cho ra mắt hệ thống mới → mời đại diện kinh doanh và nhóm khách hàng tương lai. Ưu tiên hóa product backlog cho vòng lặp → scrum team tham gia.

Bước 4 – Xác định tập yêu cầu cần ưu tiên hóa

Không phải toàn bộ yêu cầu đều cần ưu tiên hóa. Ràng buộc có thể quy định một số yêu cầu nhất định là must-have. Thực tế, chỉ hữu ích khi ưu tiên hóa những yêu cầu mà ta có quyền lựa chọn đưa vào hay không. Giai đoạn dự án cũng quan trọng: đầu dự án có thể đưa bản nháp vào; giai đoạn cuối nên giới hạn ở yêu cầu phiên bản ổn định. Các yêu cầu đem so sánh nên ở mức trừu tượng tương đương — ví dụ: đầu dự án ưu tiên hóa themes/features, khi lập kế hoạch vòng lặp ưu tiên hóa user stories.

Bước 5 – Chọn kỹ thuật ưu tiên hóa

Các kỹ thuật khác nhau về công sức, độ kỹ lưỡng và chi tiết. Yếu tố quan trọng nhất: tất cả bên liên quan phải đồng ý về kỹ thuật sẽ dùng. Nếu không, kết quả sẽ không được chấp nhận và toàn bộ nỗ lực là vô ích.

Bước 6 – Thực hiện ưu tiên hóa

Áp dụng toàn bộ tiêu chí đánh giá lên tất cả yêu cầu đã chọn. Cùng với bên liên quan, thực hiện kỹ thuật đã chọn. Kết quả là danh sách yêu cầu được ưu tiên hóa. Lưu ý: các bên liên quan khác nhau có thể cho kết quả khác nhau dù đồng ý về tiêu chí — khi đó đây là mâu thuẫn yêu cầu cần giải quyết theo Phần 4.3.

Có hai loại kỹ thuật ưu tiên hóa:

Kỹ thuật tự phát (Ad hoc techniques)

Chuyên gia gán độ ưu tiên dựa trên kinh nghiệm — về bản chất chỉ dùng một tiêu chí: nhận thức chủ quan. Nếu chuyên môn cao và được bên liên quan chấp nhận, đây là cách nhanh, rẻ và dễ. Biến thể: mời nhiều chuyên gia và lấy trung bình. Kỹ thuật phổ biến: Top-10 ranking và MoSCoW (Must have / Should have / Could have / Won’t have this time). Phân tích Kano (Phần 4.2.1) cũng hữu ích: dissatisfiers là must-have, satisfiers là should-have, delighters là could- hoặc won’t-have. Xem thêm [McIn2016].

Kỹ thuật phân tích (Analytical techniques)

Chuyên gia gán trọng số cho nhiều tiêu chí (lợi ích, chi phí, rủi ro, thời gian triển khai…), sau đó ưu tiên được tính là kết quả có trọng số. Tốn công hơn, nhưng cho thấy rõ yếu tố nào quyết định ưu tiên — giúp kết quả dễ được bên liên quan chấp nhận.

Hai lưu ý quan trọng: Thứ nhất, kết quả phụ thuộc mạnh vào trọng số. Bên liên quan phải thống nhất trọng số trước khi ưu tiên hóa — tránh ai đó cố tình thay đổi để điều hướng kết quả. Thứ hai, các tiêu chí được đánh giá hầu hết là ước tính, không phải sự thật đo được, thường nằm trên thang đo đơn giản (thấp / trung bình / cao). Chất lượng ước tính quyết định chất lượng kết quả. Xem [Olso2014].

💡 Gợi ý: Dễ bị cám dỗ dùng kỹ thuật chi tiết và bỏ nhiều công để tạo ra ước tính “chính xác tuyệt đối”. Kết quả là yêu cầu A đạt 22.76, B đạt 23.12, C đạt 20.29 — và bạn kết luận C phải làm trước, A trước B. Nhưng rất có thể bạn vừa tạo ra sự giả-chính xác (pseudo-accuracy). Kết luận thực tế hơn là: ba yêu cầu này quan trọng như nhau — đúng như cảm giác ban đầu.

Luôn đảm bảo công sức bỏ ra xứng đáng với giá trị của kết quả ưu tiên hóa. Nhớ lại Nguyên tắc 1: định hướng giá trị (value orientation).

📌 ÔN THI — 6.8 (EO 6.8.1–6.8.3)

  • Lý do ưu tiên hóa: nguồn lực hạn chế → phải quyết định requirements nào làm trước.
  • 6 bước theo đúng thứ tự: Mục tiêu & ràng buộc → Tiêu chí → Bên liên quan → Tập requirements → Kỹ thuật → Thực hiện.
  • 2 loại kỹ thuật:
Ad hoc Analytical
Cơ sở Kinh nghiệm chuyên gia (1 tiêu chí chủ quan) Trọng số nhiều tiêu chí, tính toán có hệ thống
Ví dụ Top-10, MoSCoW, Kano Ma trận trọng số
Ưu điểm Nhanh, rẻ, dễ Minh bạch, được stakeholders chấp nhận
Rủi ro Phụ thuộc cá nhân Pseudo-accuracy
  • MoSCoW + Kano: Must = dissatisfier · Should = satisfier · Could/Won’t = delighter.

⚠️ TRAP — 6.8

  • Ưu tiên hóa KHÔNG dùng để tài liệu hóa chi phí triển khai → đó là thuộc tính Difficulty.
  • Ưu tiên hóa KHÔNG dùng để nhận ra requirements có thể tái sử dụng.
  • Analytical technique dễ dẫn đến pseudo-accuracy — 22.76 vs 23.12 không có nghĩa A thực sự quan trọng hơn B.
  • Trọng số phải được thống nhất trước khi bắt đầu ưu tiên hóa.

🔑 THUẬT NGỮ — 6.8

Priority of a requirement (CPRE Glossary): “The level of importance assigned to it according to certain criteria.” — Mức độ quan trọng được gán cho yêu cầu theo các tiêu chí nhất định.

MoSCoW: Must have · Should have · Could have · Won’t have this time.

Pseudo-accuracy (giả-chính xác): Sai lầm khi tin rằng kết quả tính toán chi tiết phản ánh độ chính xác thực sự, trong khi đầu vào chỉ là ước tính trên thang đo thứ tự.

6.9 Tài liệu Đọc thêm (Further Reading)

Các sách giáo khoa của Pohl [Pohl2010], Davis [Davi2005], Hull, Jackson và Dick [HuJD2011], van Lamsweerde [vLam2009] và Wiegers & Beatty [WiBe2013] cung cấp cái nhìn toàn diện về quản lý yêu cầu. Tài liệu chuyên sâu hơn: Sổ tay CPRE Advanced Level về Requirements Management của Bühne và Herrmann [BuHe2024].

Cleland-Huang, Gotel và Zisman [CIGZ2012] bàn sâu về truy xuất nguồn gốc.

Olson [Olso2014] và Wiegers [Wieg1999] đề cập các kỹ thuật ưu tiên hóa.

PHỤ LỤC — Bảng thuật ngữ song ngữ Chương 6

Tiếng Anh Tiếng Việt
Requirements management Quản lý yêu cầu
Work product Sản phẩm công việc
Life cycle Vòng đời
State Trạng thái
State transition Chuyển đổi trạng thái
Version control Kiểm soát phiên bản
Version number Số phiên bản
Increment Phần tăng
Sub-increment Phần tăng phụ
Configuration Cấu hình
Baseline Đường cơ sở
Product dimension Chiều kích sản phẩm
Version dimension Chiều kích phiên bản
Logically connected Có liên hệ logic
Consistent Nhất quán
Unchangeable Không thể thay đổi
Basis for reset Cơ sở để thiết lập lại
Roll-back Quay lui
Attribute Thuộc tính
Attribute schema Lược đồ thuộc tính
Metadata Siêu dữ liệu
Identification Định danh
Stakeholder priority Độ ưu tiên của bên liên quan
Dependency Phụ thuộc
Risk Rủi ro
Source Nguồn gốc
Rationale Lý do
Difficulty Độ khó
Type Loại
View Khung nhìn
Selective view Khung nhìn chọn lọc
Projective view Khung nhìn chiếu
Aggregating view Khung nhìn tổng hợp
Traceability Truy xuất nguồn gốc
Backward traceability Truy xuất nguồn gốc ngược
Forward traceability Truy xuất nguồn gốc tiến
Pre-RS traceability Truy xuất trước đặc tả yêu cầu
Post-RS traceability Truy xuất sau đặc tả yêu cầu
Traceability between requirements Truy xuất giữa các yêu cầu
Traceability matrix Ma trận truy xuất nguồn gốc
Implicit traceability Truy xuất ngầm định
Explicit traceability Truy xuất tường minh
Impact analysis Phân tích tác động
Change enablement Kích hoạt thay đổi
Change authority Thẩm quyền thay đổi
Change Control Board (CCB) Ban Kiểm soát Thay đổi
Change Advisory Board (CAB) Hội đồng Tư vấn Thay đổi
Standard change Thay đổi tiêu chuẩn
Normal change Thay đổi thông thường
Emergency change Thay đổi khẩn cấp
Prioritization Ưu tiên hóa
Priority Độ ưu tiên
Ad hoc technique Kỹ thuật tự phát
Analytical technique Kỹ thuật phân tích
MoSCoW MoSCoW (Must/Should/Could/Won’t)
Top-10 ranking Xếp hạng Top-10
Pseudo-accuracy Giả-chính xác
Safety-critical system Hệ thống an toàn then chốt
Audit trail Dấu vết kiểm toán
Definition of ready Định nghĩa sẵn sàng
Definition of done Định nghĩa hoàn thành
Sprint backlog Danh sách tồn đọng vòng lặp
Product backlog Danh sách tồn đọng sản phẩm