Chương 6 - Các thực hành quản lý yêu cầu
📋 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 của chương: 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
Các yêu cầu không được khắc trên đá, hiện diện vĩnh cửu từ quá khứ đến tương lai; chúng là những thực thể sống! Chúng được sinh ra thông qua khơi gợi (elicitation), lớn lên thông qua tài liệu hóa, và được định hình thông qua thẩm định (validation). Khi trưởng thành, chúng đi làm thông qua triển khai, và sau một cuộc đời vận hành—hy vọng là—dài lâu và thịnh vượng, chúng nghỉ hưu vào sự lãng quên. Trong suốt vòng đời của mình, cha mẹ của chúng—các Kỹ sư Yêu cầu—chăm sóc chúng. Chúng ta nuôi dưỡng chúng trong thời thơ ấu, dạy dỗ chúng trong thời niên thiếu, đồng hành cùng chúng trong các mối quan hệ, và giúp chúng tìm được một công việc tốt trong một hệ thống khỏe mạnh. Đó là những gì chúng ta gọi là quản lý yêu cầu (requirements management).
Tất nhiên, có những định nghĩa tốt hơn và chính thức hơn về quản lý yêu cầu. Tiêu chuẩn ISO/IEC/IEEE 29148:2018 [ISO29148] định nghĩa quản lý yêu cầu là “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ụ.” Trong bảng thuật ngữ CPRE [Glin2025], quản lý yêu cầu được định nghĩa là “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 đến yêu cầu, bao gồm việc lưu trữ, thay đổi và truy xuất các yêu cầu.” Bảng thuật ngữ CPRE cũng cho chúng ta biết rằng 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 ở các cấp độ khác nhau:
- 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à các yêu cầu được chứa trong đó
Trong thực tế, quản lý yêu cầu chủ yếu được thực hiện ở cấp độ sản phẩm công việc. Thông thường một sản phẩm công việc chứa nhiều yêu cầu đơn lẻ (ví dụ: một bản mô tả giao diện bên ngoài), trong khi các sản phẩm công việc khác chỉ chứa một yêu cầu duy nhất (ví dụ: một user story trong một dự án linh hoạt) hoặc chúng đại diện cho toàn bộ tập hợp các yêu cầu đối với một hệ thống (ví dụ: bản đặc tả yêu cầu phần mềm). Hãy nhận thức rằng tất cả các sản phẩm công việc ở cả ba cấp độ đều phải được quản lý, và đảm bảo rằng bạn biết các mối quan hệ giữa chúng.
Đoạn văn trên phác thảo 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): tất cả các loại thực hành có thể áp dụng để làm cho quản lý yêu cầu hoạt động. Trước khi đi sâu vào chi tiết của quản lý yêu cầu, hãy xem xét một số nguyên tắc dẫn dắt để làm cho nó hoạt động. Nếu bạn muốn quản lý một thứ gì đó, bạn phải có khả năng nhận ra nó, lưu trữ nó, và tìm lại nó. Do đó, định danh duy nhất (unique identification), một mức độ chuẩn hóa phù hợp, tránh sự dư thừa, một kho lưu trữ trung tâm, và quyền truy cập được quản lý là những điều bắt buộc.
Trong Phần 6.1, chúng ta sẽ xem xét ngắn gọn các tình huống ảnh hưởng đến giá trị, tầm quan trọng và nỗ lực liên quan đến quản lý yêu cầu.
Phần 6.2 theo dõi các yêu cầu trong vòng đời của chúng với tư cách là một phần của các sản phẩm công việc mà các Kỹ sư Yêu cầu và các nhân viên CNTT khác tạo ra và sử dụng trong khi phát triển, triển khai và vận hành một hệ thống CNTT.
Trong suốt vòng đời của một yêu cầu, nhiều phiên bản của các sản phẩm công việc (và các yêu cầu mà chúng chứa đựng) được tạo ra, bắt đầu với một bản nháp 0.1 ban đầu, và sau một loạt các thay đổi lớn và nhỏ, tiến hóa thành, ví dụ, một phiên bản cuối cùng 3.2. Kiểm soát phiên bản được thảo luận trong Phần 6.3.
Khi phát triển và sử dụng các hệ thống CNTT, việc xử lý tất cả các yêu cầu trên cơ sở từng cá nhân là không thực tế. Do đó, các tập hợp yêu cầu nhất quán được công nhận là các cấu hình và đường cơ sở (configurations and baselines), như được giải thích trong Phần 6.4.
Để xử lý các sản phẩm công việc và các yêu cầu một cách hiệu quả, chúng ta phải có khả năng xác định chúng và thu thập dữ liệu về chúng. Đó là chủ đề của Phần 6.5.
Phần 6.6 xem xét khả năng truy xuất nguồn gốc (traceability) của yêu cầu. Truy xuất nguồn gốc là một đặc tính chất lượng đặc biệt quan trọng của các yêu cầu, như bạn có thể đã hiểu khi đọc các định nghĩa về quản lý yêu cầu ở trên. Nếu không có truy xuất nguồn gốc, sẽ không thể liên kết hành vi thực tế của một hệ thống với các đòi hỏi ban đầu của các bên liên quan.
Phần 6.7 giải quyết các thay đổi đối với các yêu cầu xảy ra trong suốt vòng đời của chúng. Trong những giai đoạn đầu của sự tồn tại của chúng, những thay đổi có thể diễn ra thường xuyên, nhưng sau khi thẩm định, các yêu cầu nên được ổn định. Tuy nhiên, các thay đổi vẫn sẽ xảy ra. Để áp dụng chúng một cách có trật tự, một quy trình được xác định để xử lý thay đổi cần phải được thiết lập.
Theo bản chất, các yêu cầu khác nhau về tầm quan trọng và giá trị. Thông thường, các nguồn lực để làm rõ chúng là có hạn, vì vậy không phải mọi yêu cầu đều sẽ đi đến bước triển khai. Điều này có nghĩa là các bên liên quan sẽ phải quyết định khi nào một yêu cầu nhất định sẽ được triển khai hoặc thậm chí liệu nó có được triển khai hay không. Ưu tiên hóa (prioritization), được mô tả trong Phần 6.8, có thể củng cố quyết định này.
6.1 Quản lý Yêu cầu là gì? (What is Requirements Management?)
Trong phần giới thiệu, chúng ta đã thấy rằng quản lý yêu cầu có nghĩa là 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 đến yêu cầu, bao gồm việc lưu trữ, thay đổi và truy xuất các yêu cầu. Nhưng tại sao lại phải quản lý chúng?
Chúng ta quản lý các yêu cầu bởi vì chúng là những thực thể sống; chúng được tạo ra, được sử dụng, được cập nhật và bị xóa đi trong cả quá trình phát triển lẫn vận hành. Và trong suốt toàn bộ vòng đời đó, chúng ta phải đảm bảo rằng tất cả các bên liên quan có thể truy cập vào các phiên bản chính xác của tất cả các yêu cầu phù hợp với họ. Nếu chúng ta không quản lý các yêu cầu đúng cách, chúng ta đối mặt với rủi ro rằng một số bên có thể bỏ qua yêu cầu, bám vào các yêu cầu lỗi thời, làm việc với các phiên bản sai, bỏ qua các mối quan hệ, và vân vân. Điều này có thể cản trở nghiêm trọng hiệu quả và hiệu suất của quá trình phát triển và sử dụng hệ thố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 một hệ thống.
Điều này có nghĩa là giá trị của quản lý yêu cầu không thể tách rời khỏi giá trị của hệ thống được đề cập và bối cảnh của nó. Trong thực tế, chúng ta có thể thấy sự khác biệt rất lớn về tầm quan trọng, mức độ quản lý yêu cầu và nỗ lực liên quan [Rupp2020], từ một nhiệm vụ phụ không chính thức của một 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 một người quản lý yêu cầu chuyên trách với một cơ sở dữ liệu yêu cầu được hỗ trợ bởi công cụ.
Sự quản lý yêu cầu kỹ lưỡng hơn là cần thiết với số lượng lớn hơn các yêu cầu, các bên liên quan và các nhà phát triển; với thời gian sống kỳ vọng dài hơn; nhiều thay đổi hơn hoặc các đòi hỏi chất lượng cao hơn đối với hệ thống; và với một quy trình phát triển phức tạp hơn, các tiêu chuẩn, chuẩn mực và quy định nghiêm ngặt hơn, bao gồm cả nhu cầu về một dấu vết kiểm toán chi tiết (detailed audit trail).
Thường thì, chúng ta thấy rằng quản lý yêu cầu có phần bị lơ là ở giai đoạn đầu của một dự án, khi một nhóm nhỏ đang làm việc trên một tập hợp rõ ràng các yêu cầu cấp cao. Về sau, độ phức tạp tăng lên và nhóm mất đi cái nhìn tổng quan, dẫn đến các vấn đề về chất lượng và giảm hiệu quả. Sau đó, rất nhiều nỗ lực phải được dành ra để bắt kịp với mức độ kiểm soát được yêu cầu. Sẽ hiệu quả hơn nếu đầu tư một số nỗ lực ngay từ khi bắt đầu một dự án để thiết lập các nguồn lực và quy trình quản lý yêu cầu với những đòi hỏi được kỳ vọng ở giai đoạn cuối trong tâm trí.
📌 GHI CHÚ Ô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.
⚠️ BẪY ĐỀ THI
— 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 — ngay cả 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à các sản phẩm công việc liên quan đến yêu cầu, bao gồm việc lưu trữ, thay đổi và truy xuất các yêu cầu.
6.2 Quản lý Vòng đời (Life Cycle Management)
Như đã nêu trong phần giới thiệu, các yêu cầu và các sản phẩm công việc chứa các yêu cầu có một vòng đời. Chúng ta thấy chúng được tạo ra, được làm rõ (elaborated), được thẩm định (validated), được hợp nhất (consolidated), được triển khai (implemented), được sử dụng, được thay đổi, được bảo trì, được làm lại (reworked), được tái cấu trúc (refactored), được cho nghỉ hưu (retired), được lưu trữ (archived) và/hoặc bị xóa (deleted). Đó là những gì chúng ta có ý nghĩa về vòng đời của chúng: trong suốt vòng đời của mình, một yêu cầu có thể ở trong một số lượng giới hạn các trạng thái (states) và có thể chuyển đổi từ mỗi trạng thái sang một số trạng thái khác đã được xác định trước—được định nghĩa bởi các chuyển đổi trạng thái (state transitions). Hình 6.1 cho thấy một biểu đồ trạng thái được đơn giản hóa như một mô hình cho vòng đời của một yêu cầu đơn lẻ. Để cho rõ ràng, các chuyển đổi trạng thái không được gắn nhãn. Ví dụ, chuyển đổi từ trạng thái Đang được xây dựng (Under construction) sang Đã triển khai (Implemented) có thể được kích hoạt bởi một quyết định đưa vào hoạt động (go-live) từ chủ sở hữu sản phẩm (product owner). Hai khu vực màu xám trực quan hóa vị trí mà các trạng thái trong những khu vực này nằm 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]
Một yếu tố làm phức tạp là các sản phẩm công việc và các yêu cầu đơn lẻ có các vòng đời riêng biệt của chúng mà chỉ chồng chéo một phần. Lấy một ví dụ, hãy nghĩ về một sản phẩm công việc nghiên cứu định nghĩa (definition study) ở trạng thái đang thay đổi (under change); điều này không nhất thiết có nghĩa là tất cả các yêu cầu chứa trong sản phẩm công việc đó đều phải được thay đổi. Và đối với cùng một nghiên cứu định nghĩa đó, trạng thái đã triển khai (implemented) là không có ý nghĩa; chỉ một số yêu cầu trong đó sẽ được triển khai—hay nói chính xác hơn: một số mã nguồn nhất định, dựa trên những yêu cầu này.
Một yếu tố làm phức tạp khác có thể là trong thực tế, góc nhìn về vòng đời của các yêu cầu là khác nhau đối với các vai trò khác nhau. Đối với bạn với tư cách là một Kỹ sư Yêu cầu, để theo dõi công việc của mình, bạn quan tâm đến các trạng thái khác với người quản lý dự án, và các trạng thái khác nữa so với người quản lý sản phẩm hoặc một người quản lý thay đổi: trong biểu đồ ở trên, sự quan tâm của bạn có thể kết thúc ở trạng thái đã thẩm định (validated), trong khi đối với người quản lý dự án, nó chỉ bắt đầu ở trạng thái đã tài liệu hóa (documented).
Các Kỹ sư Yêu cầu chủ động quản lý vòng đời của các sản phẩm công việc của họ. Quản lý vòng đời ngụ ý:
- Định nghĩa các mô hình vòng đời cho các sản phẩm công việc của bạn và các yêu cầu chứa trong chúng với:
- Các trạng thái mà một sản phẩm công việc hoặc yêu cầu có thể đảm nhận
- Các chuyển đổi được cho phép giữa những trạng thái này
- Các sự kiện kích hoạt chuyển đổi từ trạng thái này sang trạng thái khác
- Đảm bảo rằng chỉ các chuyển đổi được cho phép một cách rõ ràng mới xảy ra
- Ghi chép các trạng thái thực tế mà các sản phẩm công việc và yêu cầu đảm nhận
- Ghi chép các chuyển đổi thực tế xảy ra
- Báo cáo về các trạng thái và chuyển đổi này
Nói một cách đơn giản: hãy đảm bảo rằng bạn biết trạng thái mà các yêu cầu của bạn đã ở, đang ở, và sẽ đảm nhận, làm thế nào chúng có thể thay đổi, và tại sao tất cả những điều này xảy ra.
💡 Gợi ý: Chẳng hạn, với tư cách là một Kỹ sư Yêu cầu, bạn có thể được yêu cầu báo cáo xem ai đã phê duyệt phiên bản nào của một yêu cầu để được phát hành làm đầu vào cho giai đoạn viết mã. Việc theo dõi các trạng thái của yêu cầu trong vòng đời của chúng cũng có thể hữu ích để xây dựng các bảng điều khiển (dashboards) và báo cáo về tiến độ của một dự án. Đây có thể là một cách tốt để tổ chức công việc và xác định những yêu cầu nào cần làm việc trước tiên.
Trạng thái của một sản phẩm công việc dưới sự quản lý vòng đời thường được ghi lại trong một thuộc tính (attribute) (xem Phần 6.5). Cũng có thể hữu ích khi tài liệu hóa ngày bắt đầu và ngày kết thúc của trạng thái đó trong các thuộc tính. Trong các dự án linh hoạt (agile), trạng thái của một sản phẩm công việc (hạng mục) có thể được dẫn xuất từ vị trí của nó trong product backlog, task backlog, và/hoặc trên bảng nhiệm vụ (task board). Ngoài ra, việc đáp ứng các tiêu chí của định nghĩa sẵn sàng (definition of ready) và định nghĩa hoàn thành (definition of done) có thể cung cấp thông tin liên quan, vì việc đáp ứng những tiêu chí này thực chất có nghĩa là đạt được một trạng thái tiếp theo.
Sự kỹ lưỡng và mức độ chi tiết của quản lý vòng đời nên được điều chỉnh cho phù hợp với nhu cầu của khách hàng, của dự án và của hệ thống. Ví dụ, các trạng thái đang phát triển (under development), trong sản xuất (in production) và đã lưu trữ (archived) có thể là đủ. Trong các dự án phức tạp hoặc trọng yếu, bạn có thể cần một mô hình chi tiết hơn nhiều về các trạng thái, các thủ tục nghiêm ngặt về chuyển đổi trạng thái, và một dấu vết kiểm toán (audit trail) cho thấy những gì đã xảy ra trong dự án.
📌 GHI CHÚ Ô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: biế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 đến các 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.
⚠️ BẪY ĐỀ THI
— 6.2
- “Work product ở trạng thái under change” không có nghĩa tất cả requirements trong đó đều phải thay đổi.
- Trạng thái “implemented” không có nghĩa với toàn bộ work product — chỉ có ý nghĩa với từng requirement riêng lẻ.
- Mức độ chi tiết của vòng đời phải 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ừ một trạng thái sang một trạng thái khác trong vòng đời của một yêu cầu hoặc sản phẩm công việc, được kích hoạt bởi một sự kiện cụ thể. → Sự dịch chuyển từ trạng thái này sang trạng thái khác theo một quy trình đã xác định.
6.3 Kiểm soát Phiên bản (Version Control)
Việc cả các sản phẩm công việc lẫn các yêu cầu đơn lẻ là một phần của sản phẩm công việc trải qua những thay đổi nhất định trong vòng đời của chúng là điều bình thường (xem Phần 6.7 để biết thêm thông tin về việc xử lý những thay đổi này). Sau mỗi thay đổi, sản phẩm công việc khác biệt với những gì nó có trước đó: nó đã trở thành một phiên bản mới (new version).
Chúng ta muốn kiểm soát các phiên bản của những sản phẩm công việc này vì hai lý do:
- Đôi khi các thay đổi gặp trục trặc. Sau một thời gian, các khiếm khuyết được tìm thấy, hoặc các lợi ích dự kiến không được hiện thực hóa. Trong trường hợp đó, chúng ta có thể triển khai các thay đổi mới trong một phiên bản tiếp theo, nhưng chúng ta cũng có thể quyết định quay lại một phiên bản trước và tiếp tục từ đó. Hoặc có thể, khi suy nghĩ lại, chúng ta đơn giản là vẫn thích phiên bản trước hơn.
- Chúng ta muốn biết lịch sử của sản phẩm công việc, hiểu được sự tiến hóa của nó từ nguồn gốc ban đầu cho đến hiện tại. Điều này có thể giúp ích khi chúng ta phải quyết định về các thay đổi trong tương lai, hoặc đơn giản là trả lời câu hỏi 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 phải được áp dụng:
- Một định danh cho mỗi phiên bản, để phân biệt giữa các phiên bản khác nhau của một sản phẩm công việc. Đây là số phiên bản, thường được bổ sung bằng ngày của phiên bản.
- Một mô tả rõ ràng về mỗi thay đổi. Bạn phải có khả năng kể ra—và hiểu—sự khác biệt giữa một phiên bản nhất định và phiên bản tiền nhiệm của nó. Mô tả thay đổi này phải được liên kết rõ ràng với số phiên bản.
- Một chính sách nghiêm ngặt về việc lưu trữ các phiên bản, cho phép bạn xác định vị trí và lấy lại các phiên bản cũ. Trừ khi những giới hạn lưu trữ quy định khác, bạn nên bảo tồn tất cả các phiên bản trước đó của tất cả các sản phẩm công việc của bạn, nếu không bạn có thể không có khả năng khôi phục một phiên bản khi cần. Mặt khác, việc lưu trữ không giới hạn hiếm khi là khả thi, vì vậy cũng cần có một chính sách lưu trữ và dọn dẹp các sản phẩm công việc không còn được sử dụng.
Thông thường một sản phẩm công việc chứa nhiều yêu cầu. Nếu một yêu cầu đơn lẻ trong sản phẩm công việc đó thay đổi, cả yêu cầu đó lẫn sản phẩm công việc đều cần được gán số phiên bản mới, trong khi các yêu cầu không thay đổi trong sản phẩm công việc giữ nguyên số phiên bản cũ. Điều này có thể nhanh chóng trở nên rất khó hiểu. Một giải pháp thực tế là chỉ thực hiện đánh số phiên bản ở cấp độ sản phẩm công việc và để tất cả các yêu cầu trong đó kế thừa số phiên bản và lịch sử thay đổi của sản phẩm công việc.
Số phiên bản thường được cấu thành từ (ít nhất) hai phần:
- Phiên bản (Version): Về nguyên tắc, phiên bản bắt đầu từ không khi sản phẩm công việc còn đang trong quá trình phát triển. Khi được phê duyệt chính thức, phát hành và/hoặc ra mắt, chúng ta gán cho nó phiên bản một. Sau đó, phiên bản chỉ được tăng lên đối với các cập nhật lớn, có thực chất.
- Phần tăng (Increment): Phần tăng hầu hết bắt đầu từ một và được tăng theo mỗi thay đổi (có thể nhìn thấy từ bên ngoài), về mặt nội dung hoặc thường chỉ mang tính văn bản hay biên tập. Một phần tăng phụ (sub-increment) bổ sung có thể được sử dụng chỉ để sửa lỗi đánh máy (typos). Phần tăng chín (increment nine) đôi khi được sử dụng để biểu thị một phiên bản cuối cùng ngay trước khi phê duyệt hoặc phát hành.
Một số phiên bản mới được gán cùng với mỗi thay đổi chính thức.
Thường thì, một sự thay đổi trong trạng thái vòng đời của một sản phẩm công việc không được coi là lý do để tăng số phiên bản, trừ khi nó đi kèm với một sự thay đổi về nội dung hoặc văn bản. Ví dụ, nếu một yêu cầu nhận được trạng thái đã thẩm định (validated) và số phiên bản 1.0 sau khi phê duyệt, thì không cần phải thay đổi số phiên bản này nếu trạng thái thay đổi thành đang được xây dựng (under construction) và sau đó là đã triển khai (implemented). Trạng thái cuối cùng có thể kết thúc ở đã lưu trữ (archived) nhưng vẫn giữ nguyên số phiên bản 1.0.
📌 GHI CHÚ Ô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) có thể rollback khi thay đổi sai; (2) hiểu được 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 liên kết với số phiên bản + chính sách lưu trữ nghiêm ngặt.
- Cấu trúc số phiên bản: Version (0 → 1 khi phát hành, tăng khi có cập nhật lớn) + Increment (tăng mỗi thay đổi nhỏ nhìn thấy được).
- Nên đánh version ở cấp work product, để requirements kế thừa — tránh nhầm lẫn.
⚠️ BẪY ĐỀ THI
— 6.3
- Thay đổi trạng thái vòng đời (validated → under construction → implemented → archived) 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 của version control là “biết lịch sử” — không phải “tạo nền tảng cho phát triển tiếp theo” (đó là nội dung bịa trong bản dịch cũ).
🔑 THUẬT NGỮ
— 6.3
Version control (kiểm soát phiên bản): Quá trình theo dõi tất cả các sản phẩm công việc trong quá trình tiến hóa của chúng. Mọi thay đổi trong một sản phẩm công việc 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ể của một sản phẩm công việc, 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 bảo tồn, như đã được khuyên ở trên, tất cả các phiên bản của tất cả các yêu cầu mà bạn phát triển trong một dự án. Khi đó bạn sẽ có một cơ sở dữ liệu không ngừng mở rộng chứa đầy các yêu cầu và bạn sẽ bắt đầu mất đi cái nhìn tổng quan. Một ngày nọ, khách hàng của bạn đến bàn của bạn và hỏi: “Chúng tôi đã triển khai hệ thống của bạn tại tất cả các chi nhánh. Bây giờ dường như có vấn đề với các phép tính tại văn phòng ở Barcelona. Bạn có thể cho tôi biết phiên bản nào của các yêu cầu tính toán họ đang sử dụng ở đó không?” Nếu bạn không thể trả lời câu hỏi đó, bạn sẽ ước rằng mình đã chú ý hơn đến quản lý cấu hình (configuration management).
Vậy, cấu hình (configuration) là gì? Bạn sẽ tìm thấy định nghĩa trong bảng thuật ngữ CPRE [Glin2025], nhưng tóm gọn lại, đối với một Kỹ sư Yêu cầu, một 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. Chúng ta lựa chọn tập hợp này với một mục đích cụ thể, thường là để làm rõ những yêu cầu nào đang hoặc đã có hiệu lực trong một tình huống nhất định.
Điều này thiết lập các thuộc tính sau cho một cấu hình đúng đắn:
- Có liên hệ logic (Logically connected): Tập hợp các yêu cầu trong cấu hình thuộc về nhau trong phạm vi của một mục tiêu nhất định.
- Nhất quán (Consistent): Tập hợp các yêu cầu không có mâu thuẫn nội bộ và có thể được tích hợp vào một hệ thống.
- Duy nhất (Unique): Cả bản thân cấu hình lẫn các yêu cầu cấu thành của nó đều được xác định rõ ràng và duy nhất.
- Không thể thay đổi (Unchangeable): Cấu hình được cấu thành từ các yêu cầu được lựa chọn, mỗi yêu cầu với một phiên bản cụ thể sẽ không bao giờ được thay đổi trong cấu hình này.
- Cơ sở để thiết lập lại (Basis for reset): Cấu hình cho phép quay trở lại (fallback) một cấu hình trước đó nếu bất kỳ thay đổi không mong muốn nào dường như đã xảy ra.
Một cấu hình được tài liệu hóa như một sản phẩm công việc, với một định danh duy nhất, một trạng thái, và một số phiên bản cùng ngày tháng, giống như bất kỳ sản phẩm công việc nào khác. Tuy nhiên, bởi vì một cấu hình theo định nghĩa là không thể thay đổi, nó sẽ luôn luôn chỉ có một phiên bản (ví dụ, 1.0).
Một cấu hình luôn luôn có hai chiều kích (dimensions) [CoWe1998]:
Chiều kích sản phẩm (The product dimension)
Chiều kích này chỉ ra những yêu cầu nào được bao gồm trong cấu hình cụ thể này. Đôi khi, một cấu hình sẽ chứa tất cả các yêu cầu khả dụng, nhưng thông thường, nó là một sự lựa chọn nhất định—ví dụ, tất cả các yêu cầu được triển khai trong bản phát hành cho thị trường Pháp của một hệ thống. Bản phát hành cho thị trường Anh (British release) của cùng một hệ thống đó khi đó có thể có một cấu hình khác.
Chiều kích phiên bản (The version dimension)
Trong một cấu hình cụ thể, mỗi yêu cầu được chọn hiện diện ở chính xác một, và chỉ một, phiên bản. Nó có thể là phiên bản mới nhất hoặc một phiên bản trước đó, tùy thuộc vào mục đích của chính cấu hình đó. Ngay khi dù chỉ một phiên bản khác của một yêu cầu duy nhất được chọn, đây là một cấu hình mới. Hãy tưởng tượng một hệ thống mà một bản phát hành mới sẽ được triển khai với một số yêu cầu ở phiên bản cao hơn: bản phát hành mới này khi đó sẽ có một cấu hình khác.
[Hình 6.2 – Ví dụ về các cấu hình]
Hình trên cho thấy một ví dụ về các cấu hình khác nhau của một hệ thống nhất định. Nó cho thấy một bộ sưu tập gồm chín yêu cầu. Một số trong chúng vẫn đang ở các giai đoạn phát triển ban đầu—ví dụ: yêu cầu 6 với phiên bản v0.1. Các yêu cầu khác đã có nhiều phiên bản hơn—chẳng hạn, yêu cầu 1 đã được hoàn thiện và đã có một cập nhật lớn, vì vậy bây giờ là phiên bản v2.0. Bức tranh bên trái cho thấy cấu hình hiện đang trong môi trường sản xuất. Nó bao gồm R1 v2.0, R2 v1.0, R3 v1.2 (yêu cầu này đã có hai cập nhật nhỏ sau khi triển khai), R5 v2.0, R7 v1.0 và R9 v1.0. R4, R6 và R8, đang trong quá trình phát triển, không có mặt trong cấu hình này, cũng như các phiên bản mới của R7 và R9.
Bức tranh bên phải cho thấy cấu hình đang đồng thời hiện diện trong môi trường kiểm thử hệ thống. Một số yêu cầu (R1, R2) giống nhau, một số không còn hiện diện (R3, R5), các yêu cầu đang trong quá trình phát triển (R4, R6 và R8) được đưa vào đây, và hai yêu cầu (R7 và R9) hiện diện ở phiên bản cao hơn so với trong cấu hình của môi trường sản xuất.
Trong nhiều dự án, một số cấu hình được xử lý theo cách đặc biệt: các cấu hình này được gọi là đường cơ sở (baselines). Một đường cơ sở là một cấu hình ổn định, đã được thẩm định và được kiểm soát thay đổi, đánh dấu một cột mốc hoặc một điểm nghỉ (resting point) trong dự án. Ví dụ có thể là cấu hình vào cuối giai đoạn thiết kế, ngay trước khi bắt đầu giai đoạn viết mã, hoặc cấu hình có hiệu lực tại thời điểm ra mắt (go-live) của một bản phát hành nhất định.
Sprint backlog trong một dự án linh hoạt đóng vai trò là đường cơ sở vào đầu của vòng lặp tiếp theo. Các đường cơ sở hữu ích cho mục đích lập kế hoạch vì chúng đại diện cho một điểm xuất phát ổn định cho giai đoạn tiếp theo. Chúng thường được đóng băng và giữ lại như một mỏ neo trong cuộc sống hỗn loạn của một dự án. Nếu có điều gì đó đi sai nghiêm trọng trong dự án, nhóm có thể thực hiện quay lui (roll-back) về tình trạng của đường cơ sở và khởi động lại từ đó.
Đối với Kỹ sư Yêu cầu, chủ yếu là cấu hình của các sản phẩm công việc chứa các yêu cầu là quan trọng. Nhưng trong thực tế, cấu hình trong một dự án có phạm vi rộng hơn nhiều, chứa các phiên bản được chọn của các sản phẩm công việc của tất cả các thành viên trong nhóm, chẳng hạn như các yêu cầu, thiết kế, mã nguồn và các ca kiểm thử. Trong các dự án phức tạp, quản lý cấu hình có thể là một công việc toàn thời gian, được thực hiện với các công cụ chuyên dụng.
📌 GHI CHÚ ÔN THI
— 6.4 (EO 6.4.1 – L1)
- Configuration = tập hợp nhất quán các work product có liên hệ logic, mỗi requirement hiện diện ở đúng một phiên bản.
- 5 thuộc tính của configuration: Logically connected · Consistent · Unique · Unchangeable · Basis for reset.
- Baseline = configuration ổn định + đã thẩm định + được kiểm soát thay đổi → đánh dấu cột mốc dự án.
- Trong agile: sprint backlog = baseline vào đầu vòng lặp tiếp theo.
- Cấu hình không thể thay đổi → chỉ có một phiên bản duy nhất (ví dụ: 1.0).
- Hai chiều kích của configuration: product dimension (requirements nào) + version dimension (phiên bản nào của mỗi requirement).
⚠️ BẪY ĐỀ THI
— 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 thay đổ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 được sửa trực tiếp trong baseline hiện tại.
- Trước khi thực hiện bất kỳ thay đổi nào vào 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.” — Một tập hợp nhất quán các sản phẩm công việc chứa các 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.” — Một cấu hình ổn định, được kiểm soát thay đổi của các sản phẩm công việc, dùng cho lập kế hoạch phát hành hoặc các cột mốc bàn giao trong dự án.
6.5 Thuộc tính và Khung nhìn (Attributes and Views)
Với tư cách là một Kỹ sư Yêu cầu, đầu ra của bạn bao gồm tất cả các loại sản phẩm công việc chứa các yêu cầu. Những yêu cầu này sẽ phải được quản lý, nếu không bạn và nhóm của bạn sẽ nhanh chóng mất đi cái nhìn tổng quan. Để quản lý các yêu cầu, bạn phải thu thập và duy trì dữ liệu về chúng—siêu dữ liệu (metadata), dữ liệu về dữ liệu. Siêu dữ liệu làm cho các sản phẩm công việc trở nên hữu hình, có thể quản lý được; thông qua siêu dữ liệu, bạn có thể cung cấp và thu thập thông tin về các yêu cầu và trả lời các câu hỏi liên quan trong và sau vòng đời dự án hoặc sản phẩm. Hãy nghĩ đến các câu hỏi như “Những yêu cầu nào được lên kế hoạch cho bản phát hành tiếp theo?” hoặc “Bản phát hành này có khả năng tốn bao nhiêu công sức?” hoặc “Có bao nhiêu yêu cầu có độ ưu tiên cao?”
Khi xem xét các yêu cầu là các thực thể mà thông tin là cần thiết, các đặc tính của những yêu cầu này được gọi là thuộc tính (attributes). Trong chương này, chúng ta đã thấy một số thuộc tính phổ biến, chẳng hạn như định danh duy nhất, số phiên bản, trạng thái, các ngày tháng. Các thuộc tính cần được định nghĩa cho các yêu cầu phụ thuộc vào nhu cầu thông tin của các bên liên quan trong dự án và hệ thống. Ngay từ đầu dự án, nên thiết lập một lược đồ thuộc tính (attribute schema) cho phép Kỹ sư Yêu cầu đáp ứng những nhu cầu này.
Một điểm khởi đầu tốt có thể được tìm thấy trong các tiêu chuẩn liên quan. Tiêu chuẩn ISO [ISO29148] đề cập đến:
- Định danh (Identification): Mỗi yêu cầu nên có một định danh duy nhất, bất biến, chẳng hạn như một số, tên, ký hiệu gợi nhớ (mnemonic). Không có định danh phù hợp, việc quản lý yêu cầu là rất khó khăn.
- Độ ưu tiên của bên liên quan (Stakeholder priority): Độ ưu tiên (đã được thống nhất) của yêu cầu từ góc độ của các bên liên quan. Xem Phần 6.8 để biết thông tin về cách xác định độ ưu tiên này.
- Phụ thuộc (Dependency): Đôi khi, có sự phụ thuộc giữa các yêu cầu. Điều này có thể có nghĩa là một yêu cầu có độ ưu tiên thấp phải được triển khai trước vì một yêu cầu có độ ưu tiên cao khác phụ thuộc vào nó.
- Rủi ro (Risk): Đây là về khả năng việc triển khai yêu cầu sẽ dẫn đến các vấn đề, chẳng hạn như thiệt hại, chi phí phát sinh, chậm trễ, khiếu kiện pháp lý. Về bản chất, đây là một ước tính, cần dựa trên sự đồng thuận giữa các bên liên quan.
- Nguồn gốc (Source): Nguồn gốc của yêu cầu là gì, nó đến từ đâu? Bạn có thể cần thông tin này để thẩm định, giải quyết mâu thuẫn, sửa đổi, hoặc xóa bỏ.
- Lý do (Rationale): Lý do cho bạn biết tại sao yêu cầu là cần thiết, các mục tiêu của các bên liên quan cần được đáp ứng bởi nó.
- Độ khó (Difficulty): Đây là ước tính về công sức cần thiết để triển khai yêu cầu. Nó cần thiết cho việc lập kế hoạch và ước tính dự án.
- Loại (Type): Thuộc tính này chỉ ra liệu yêu cầu là một yêu cầu chức năng (functional requirement), yêu cầu chất lượng (quality requirement) hay một ràng buộc (constraint).
Có nhiều cách để lưu trữ thông tin này. Nó có thể được chứa trong các tài liệu hoặc lưu trữ trong một bảng tính hoặc cơ sở dữ liệu, với các yêu cầu là các hàng và các thuộc tính của chúng là các cột. Trong môi trường linh hoạt, các yêu cầu có thể được ghi lại trên các thẻ câu chuyện (story cards), trong đó các tiêu đề trên thẻ là các thuộc tính. Như đã thảo luận trong Chương 7, các công cụ quản lý yêu cầu cần cung cấp chức năng để lưu trữ dữ liệu về các yêu cầu và cũng để báo cáo về chúng.
Các thuộc tính cho phép bạn cung cấp thông tin về các sản phẩm công việc và các yêu cầu chứa trong đó. Cách đơn giản nhất để làm như vậy là tạo ra một báo cáo với tất cả dữ liệu về tất cả các phiên bản của tất cả các yêu cầu. Đối với bất kỳ hệ thống nào phức tạp hơn mức đơn giản nhất, một báo cáo như vậy sẽ vô dụng vì không ai có thể bao quát hết tất cả thông tin do quá phức tạp. Do đó, bạn nên điều chỉnh các báo cáo của mình dựa trên nhu cầu thông tin của đối tượng mục tiêu. Điều này được thực hiện bằng cách sử dụng khung nhìn (views) [Glin2025].
Một khung nhìn là một cách (thường được định nghĩa trước) để lọc và sắp xếp dữ liệu trên các sản phẩm công việc của bạn, tạo ra một báo cáo hiển thị chính xác những gì đối tượng cần, không hơn không kém. Một khung nhìn được định nghĩa với mục đích rõ ràng là cung cấp thông tin liên quan cho một nhóm mục tiêu cụ thể.
Chúng ta phân biệt ba loại khung nhìn:
- Khung nhìn chọn lọc (Selective views): Những khung nhìn này cung cấp thông tin về một sự lựa chọn có chủ đích của các yêu cầu thay vì tất cả các yêu cầu. Ví dụ, một khung nhìn chỉ về các phiên bản mới nhất của các yêu cầu, hoặc tất cả các yêu cầu có trạng thái đã thẩm định (validated), hoặc về các yêu cầu có độ ưu tiên của bên liên quan là cao (high); trọng tâm có thể là trên một hệ thống con (subsystem), hoặc ngược lại để cung cấp một cái nhìn tổng quan trừu tượng về hệ thống chỉ thông qua các yêu cầu cấp cao của nó.
- Khung nhìn chiếu (Projective views): Một khung nhìn chiếu hiển thị một sự lựa chọn từ tất cả dữ liệu (thuộc tính) của các yêu cầu—ví dụ, chỉ định danh, số phiên bản và tên.
- Khung nhìn tổng hợp (Aggregating views): Trong một khung nhìn tổng hợp, bạn sẽ tìm thấy các bản tóm tắt, tổng số, hoặc giá trị trung bình, được tính toán từ một tập hợp các yêu cầu. Một ví dụ sẽ là tổng số các yêu cầu theo từng bộ phận: ví dụ, 4 từ Bộ phận Bán hàng (Sales), 5 từ Bộ phận Logistics.
[Hình 6.3 – Các loại khung nhìn khác nhau]
Trong hầu hết các trường hợp, một sự kết hợp của các khung nhìn được sử dụng—ví dụ, nếu bạn muốn cung cấp một danh sách với các ID, số phiên bản, tên và loại (= chiếu) của tất cả các yêu cầu cho Bộ phận Bán hàng (= chọn lọc).
📌 GHI CHÚ Ô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 từng cái:
| 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 ra vấn đề khi triển khai |
| Source | Nguồn gốc requirement (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 view cùng lúc.
- Attribute schema nên được thiết lập ngay từ đầu dự án.
⚠️ BẪY ĐỀ THI
— 6.5
- Unique identifier KHÔNG dùng để ước tính kích thước tổng thể đặc tả — đây là bẫy hay xuất hiện trong câu K0821.
- Difficulty ≠ Risk: Difficulty là ước tính công sức, Risk là ước tính 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 được sử 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 (thường được định nghĩa trước) để lọc và sắp xếp dữ liệu về sản phẩm công việc, tạo ra 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)
Xuyên suốt cuốn sổ tay này, chúng tôi đã đề cập đến chủ đề truy xuất nguồn gốc [GoFi1994]. Nếu không có khả năng truy xuất nguồn gốc thích hợp, Kỹ nghệ Yêu cầu gần như là không khả thi, vì bạn không thể thực hiện những điều sau:
- Cung cấp bằng chứng rằng một yêu cầu nhất định được đáp ứng
- Chứng minh rằng một yêu cầu đã được triển khai và bằng phương tiện nào
- Cho thấy sự tuân thủ của sản phẩm với các luật lệ và tiêu chuẩn hiện hành
- Tìm kiếm các sản phẩm công việc bị thiếu (ví dụ: tìm hiểu xem các ca kiểm thử có tồn tại cho tất cả các yêu cầu hay không)
- Phân tích các tác động của một sự thay đổi đối với các yêu cầu (xem Phần 6.7)
Trong nhiều trường hợp, đặc biệt đối với các hệ thống có tính an toàn then chốt (safety-critical systems), các tiêu chuẩn quy trình thậm chí còn yêu cầu một cách rõ ràng việc triển khai truy xuất nguồn gốc.
Có ba loại câu hỏi có thể được trả lời với sự hỗ trợ của khả năng truy xuất nguồn gốc (xem thêm Hình 6.4):
- Truy xuất nguồn gốc ngược (Backward traceability): Nguồn gốc của một yêu cầu nhất định là gì? Nó được tìm thấy ở đâu? Những nguồn nào (các bên liên quan, tài liệu, hệ thống khác) đã được phân tích trong quá trình khơi gợi? Truy xuất nguồn gốc ngược còn được biết đến là truy xuất nguồn gốc trước đặc tả yêu cầu (pre-requirements specification traceability).
- Truy xuất nguồn gốc tiến (Forward traceability): Yêu cầu này được sử dụng ở đâu? Những kết quả chuyển giao nào (các mô-đun được lập trình, các ca kiểm thử, các thủ tục, các sổ tay hướng dẫn) được dựa trên nó? Truy xuất nguồn gốc tiến còn được biết đến là truy xuất nguồn gốc sau đặc tả yêu cầu (post-requirements specification traceability).
- Truy xuất nguồn gốc giữa các yêu cầu (Traceability between requirements): Các yêu cầu khác có phụ thuộc vào yêu cầu này hay ngược lại không (ví dụ: các yêu cầu chất lượng liên quan đến một yêu cầu chức năng)? Yêu cầu có phải là một sự làm mịn (refinement) của một yêu cầu cấp cao hơn không (ví dụ: một epic được làm mịn thành một số user story, một user story được chi tiết hóa với một số tiêu chí chấp nhận)? Chúng liên quan với nhau như thế nào?
[Hình 6.4 – Các loại truy xuất nguồn gốc]
Có một vài cách để tài liệu hóa khả năng truy xuất nguồn gốc. Thường thì, điều này được thực hiện một cách ngầm định (implicitly)—ví dụ, bằng cách áp dụng các cấu trúc tài liệu, các biểu mẫu tiêu chuẩn, hoặc các quy ước đặt tên. Nếu bạn xác định tất cả các yêu cầu của mình bằng mã Req-xxx-nnn, trong đó xxx là viết tắt của bộ phận đã yêu cầu yêu cầu đó, mọi người sẽ hiểu rằng Req-sal-012 là một yêu cầu cho Bộ phận Bán hàng (đối với truy xuất nguồn gốc ngược). Nếu bạn xuất bản một tài liệu liệt kê tất cả các yêu cầu sẽ được triển khai trong bản phát hành ngày 1 tháng 7, bạn đang cung cấp thông tin truy xuất nguồn gốc tiến ngầm định.
Và nếu bạn viết một tài liệu với một phần chuyên dụng về, ví dụ, các tính toán giá cả, đó có thể là một ví dụ về truy xuất nguồn gốc giữa các yêu cầu. Một ví dụ khác có thể là một mô hình cấp cao và một mô tả văn bản của các yêu cầu chi tiết liên quan đến nó.
Trong các dự án phức tạp hơn, khả năng truy xuất nguồn gốc nên (cũng) được tài liệu hóa một cách tường minh (explicitly). Đối với truy xuất nguồn gốc tường minh, bạn tài liệu hóa mối quan hệ giữa các sản phẩm công việc dựa trên định danh duy nhất của chúng. Điều này có thể được thực hiện dưới nhiều hình thức khác nhau [HuJD2011]:
- Sử dụng các thuộc tính cụ thể chẳng hạn như Nguồn gốc (Source) được đề xuất bởi tiêu chuẩn ISO [ISO29148]
- Trong các tài liệu, thêm các tham chiếu đến các tài liệu tiền nhiệm, các sản phẩm công việc khác, hoặc các yêu cầu đơn lẻ
- Phát triển một ma trận truy xuất nguồn gốc (traceability matrix) trong một bảng tính, hoặc một bảng cơ sở dữ liệu (xem ví dụ trong Bảng 6.1 bên dưới)
- Trong tài liệu văn bản, sử dụng các siêu liên kết (hyperlinks) kiểu Wiki
- Trực quan hóa các mối quan hệ truy xuất nguồn gốc trong một biểu đồ dấu vết (trace graph) (Hình 6.4 là một hình thức đơn giản hóa của một biểu đồ như vậy)
Trong nhiều trường hợp, một công cụ quản lý yêu cầu hoặc quản lý cấu hình (xem Chương 7) cung cấp chức năng để hỗ trợ truy xuất nguồn gốc. Việc quản lý khả năng truy xuất nguồn gốc trong một dự án đáng kể có thể rất phức tạp, đặc biệt nếu bạn cũng phải tính đến việc đánh số phiên bản. Trong trường hợp đó, 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 |
📌 GHI CHÚ Ô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 của thay đổi (impact analysis)
- 3 loại traceability: Backward (← nguồn gốc) · Forward (→ nơi dùng) · Between requirements (← → phụ thuộc lẫn nhau).
- Implicit = qua cấu trúc tài liệu, quy ước đặt tên.
- Explicit = tài liệu hóa dựa trên unique ID: attribute Source / tham chiếu / traceability matrix / hyperlink / trace graph.
⚠️ BẪY ĐỀ THI
— 6.6
- Traceability KHÔNG hỗ trợ “xuất dữ liệu từ công cụ quản lý yêu cầu” — đây là bẫy câu A0820.
- Backward = pre-RS traceability; Forward = post-RS traceability — nhớ đúng tên kỹ thuật.
- Traceability bắt buộc theo tiêu chuẩn đối với hệ thống safety-critical — không phải tùy chọ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 một yêu cầu ngược về nguồn gốc và tiến đến các sản phẩm công việc tiếp theo, cũng như đến các yêu cầu khác mà yêu cầu này 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 các 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. Các quy trình linh hoạt (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 ra phong trào linh hoạt đã rất rõ ràng về điều này: các thay đổi yêu cầu sẽ luôn luôn xảy ra, dù bạn có muốn hay không. Nhiều người không thích những thay đổi chút nào, bởi vì mọi thay đổi đều là một rủi ro, một mối đe dọa đối với sự ổn định của dự án và hệ thống.
Tuy nhiên, việc thay đổi một yêu cầu không phải là một sự kiện độc lập: nó được kích hoạt bởi những thay đổi trong bối cảnh hệ thống, bởi những hiểu biết mới của các bên liên quan, bởi hành vi của đối thủ cạnh tranh, và vân vân; một đạo luật có hiệu lực, thêm một ràng buộc mới cho hệ thống; do nhu cầu thị trường ngày càng tăng, hiệu suất của hệ thống phải được cải thiện; một hệ thống của đối thủ cạnh tranh được ra mắt với một số tính năng hấp dẫn mà khách hàng của bạn cũng muốn có. Một sự thay đổi do đó nên được xem là cơ hội để có được một hệ thống tốt hơn, để cung cấp nhiều giá trị hơn cho người dùng.
Tuy nhiên, bất kể tình huống là gì, mọi thay đổi cũng là một rủi ro. Nó có thể đưa ra các khiếm khuyết, dẫn đến sự cố hệ thống. Nó có thể làm chậm tiến độ của dự án. Nó có thể tốn nhiều công sức và tiền bạc hơn so với tính toán trước đó. Người dùng có thể không thích nó và từ chối làm việc với nó. Tóm lại, mọi thứ có thể đi sai và làm xáo trộn một dự án hoặc hệ thống trước đây đang ổn định. Nhưng điều đó không có nghĩa là các thay đổi là xấu và cần phải tránh; nó có nghĩa là tất cả các thay đổi phải được xử lý cẩn thận để đạt được 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 về quản lý dịch vụ CNTT (xem [Axelos2019]), kích hoạt thay đổi (change enablement) được mô tả là một trong những thực hành cốt lõi. Thực hành này đảm bảo rằng các thay đổi được triển khai một cách hiệu quả, an toàn và kịp thời để đáp ứng kỳ vọng của các bên liên quan.
Thực hành này cân bằng giữa hiệu quả, thông lượng, sự tuân thủ và kiểm soát rủi ro. Nó tập trung vào ba khía cạnh:
- Đảm bảo rằng tất cả các rủi ro đã được đánh giá chính xác
- Ủy quyền cho phép các thay đổi được tiến hành
- Quản lý việc triển khai thay đổi
Kích hoạt thay đổi ngụ ý rằng một tổ chức chỉ định một thẩm quyền thay đổi (change authority) để quyết định về các thay đổi và định nghĩa một quy trình để xử lý chúng. Xem Hình 6.5 để biết phác thảo về quy trình này. Các biện pháp này thường được điều chỉnh theo phương pháp phát triển và thời điểm mà một sự thay đổi xảy ra.
[Hình 6.5 – Quy trình kích hoạt thay đổi]
Khi một yêu cầu vẫn còn ở trạng thái bản nháp (draft), tác giả có thẩm quyền để thay đổi nó và không có quy trình nghiêm ngặt nào được tuân theo.
Ngay khi một yêu cầu được phát hành để sử dụng tiếp trong dự án, tác giả không còn được tự do quyết định nữa, vì mọi thay đổi sẽ có tác động đến các sản phẩm công việc khác dựa trên yêu cầu này. Trước khi quyết định liệu một thay đổi có nên được triển khai hay không, cần phải thực hiện phân tích tác động (impact analysis) để làm rõ các công sức và rủi ro của thay đổi. Đây là lúc truy xuất nguồn gốc là không thể thiếu. Trong cách tiếp cận phát triển tuyến tính (linear development), thẩm quyền thay đổi thường được giao cho quản lý dự án, một ban chỉ đạo, hoặc một Ban Kiểm soát Thay đổi (Change Control Board), và một quy trình được tuân theo, với một quyết định chính thức về thay đổi và việc lập kế hoạch triển khai nó. Trong cách tiếp cận phát triển lặp lại (iterative development), thẩm quyền thay đổi thường thuộc về chủ sở hữu sản phẩm (product owner), người quyết định về thay đổi và thêm một thay đổi được chấp nhận vào product backlog như một hạng mục mới (sản phẩm công việc). Việc triển khai tiếp theo sau đó được xử lý giống như bất kỳ hạng mục product backlog nào khác.
Khi một yêu cầu đã được triển khai trong một hệ thống đang vận hành, cần phải tuân theo một quy trình thậm chí còn nghiêm ngặt hơn, vì mọi thay đổi bây giờ sẽ ảnh hưởng đến người dùng và các quy trình nghiệp vụ.
Ở đây, thường có sự phân biệt giữa các loại thay đổi:
- Thay đổi tiêu chuẩn (Standard change): Rủi ro thấp, được hiểu rõ và được ủy quyền trước — ví dụ: thay đổi tỷ lệ thuế VAT.
- Thay đổi thông thường (Normal change): Dựa trên một Yêu cầu Thay đổi (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 được triển khai càng sớm càng tốt, ví dụ: để giải quyết một sự cố — nhưng điều này hiếm khi liên quan đến việc thay đổi các yêu cầu.
Thông thường, thẩm quyền thay đổi thuộc về Hội đồng Tư vấn Thay đổi (Change Advisory Board) [Math2019]; trong cách tiếp cận lặp lại như DevOps, một thay đổi có thể được ủy quyền bởi một người quản lý bản phát hành (release manager).
📌 GHI CHÚ ÔN THI
— 6.7 (EO 6.7.1 – L1)
- Thay đổi = cơ hội cải thiện hệ thống, không phải mối đe dọa. Nhưng phải xử lý cẩn thận.
- 3 giai đoạn & thẩm quyền thay đổi:
| 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 (trong hệ thống 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 của impact analysis.
- 3 loại thay đổi khi vận hành: Standard (pre-authorized) · Normal (có RFC chính thức) · Emergency (khẩn cấp, hiếm khi thay đổi requirements).
⚠️ BẪY ĐỀ THI
— 6.7
- Thay đổi khẩn cấp (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 được xem xét trong baseline tương lai, không phải sửa trực tiếp vào baseline hiện tại.
- Kể cả khi 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 rằng các thay đổi được triển khai một cách hiệu quả, an toàn và kịp thời để đáp ứng kỳ vọng của các bên liên quan, 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 (linear/plan-driven).
Change Advisory Board (CAB) — Hội đồng Tư vấn Thay đổi: Thẩm quyền thay đổi khi hệ thống đang vận hành.
6.8 Ưu tiên hóa (Prioritization)
Bản thân các yêu cầu chỉ là những khái niệm trong tâm trí của mọi người. Chúng chỉ mang lại giá trị khi chúng được triển khai trong một hệ thống hoạt động. Việc triển khai này tiêu tốn công sức, thời gian, tiền bạc và sự chú ý. Trong hầu hết các trường hợp, các nguồn lực này là có hạn, có nghĩa là không phải tất cả các yêu cầu đều có thể được triển khai, ít nhất là không cùng một lúc. Điều này dẫn đến việc các bên liên quan phải quyết định những yêu cầu nào nên được thực hiện trước và những yêu cầu nào có thể được triển khai sau (hoặc hoàn toàn không). Nói cách khác: ưu tiên hóa (prioritization) [Wieg1999].
Độ ưu tiên của một yêu cầu được định nghĩa là mức độ quan trọng được gán cho nó theo các tiêu chí nhất định [Glin2025]. Do đó, trước tiên bạn phải xác định những tiêu chí nào nên được sử dụng để đánh giá các yêu cầu trước khi bạn có thể ưu tiên hóa chúng. Tuy nhiên, trước khi bạn có thể xác định các tiêu chí đánh giá, bạn phải biết mục tiêu của việc ưu tiên hóa là gì. Mục tiêu đó thường không phải là mục tiêu của bạn với tư cách là một Kỹ sư Yêu cầu mà là mục tiêu của các bên liên quan nhất định, vì vậy bạn phải quyết định ai là các bên liên quan cho việc ưu tiên hóa này. Và khi bạn biết mục tiêu của họ, thường sẽ rõ ràng là không phải tất cả các yêu cầu sẽ phải được ưu tiên hóa mà chỉ là một tập hợp con được xác định.
Tóm tắt những điều trên, chúng ta có thể phác thảo một chuỗi các bước cần tuân theo nếu chúng ta muốn ưu tiên hóa các yêu cầu:
Bước 1 – Xác định các mục tiêu và ràng buộc chính cho việc ưu tiên hóa
Bối cảnh dự án và hệ thống xác định phần lớn lý do cho việc ưu tiên hóa. Ví dụ, nếu bạn ưu tiên hóa để quyết định những tính năng nào sẽ được triển khai trong bản phát hành tiếp theo, bạn có thể tập trung vào giá trị kinh doanh (business value); nếu mục tiêu là chọn user story cho vòng lặp tiếp theo, điểm câu chuyện (story points) và các phụ thuộc kỹ thuật sẽ nổi bật hơn. Các ràng buộc kỹ thuật hoặc pháp lý có thể hạn chế các lựa chọn cần được thực hiện.
Bước 2 – Xác định các tiêu chí đánh giá mong muốn
Về nguyên tắc, các mục tiêu và ràng buộc quyết định các tiêu chí cần sử dụng. Các tiêu chí thường dùng bao gồm giá trị kinh doanh cho các bên liên quan, tính khẩn cấp được người dùng cảm nhận, công sức để triển khai, rủi ro cho việc sử dụng, các phụ thuộc logic và kỹ thuật, tính chất ràng buộc pháp lý của một yêu cầu, hoặc đơn giản là sở thích chủ quan (mang tính liên cá nhân) của các bên liên quan liên quan. Đôi khi chỉ một tiêu chí duy nhất được sử dụng, nhưng một sự lựa chọn cân bằng của một vài tiêu chí liên quan có thể mang lại kết quả tốt hơn.
Bước 3 – Xác định các bên liên quan phải được tham gia
Các mục tiêu và ràng buộc ảnh hưởng đến những bên liên quan nào bạn nên đưa vào quá trình ưu tiên hóa, nhưng mặt khác, chính các bên liên quan nhất định lại đặt ra những mục tiêu này, vì vậy bạn phải nhận thức được sự phụ thuộc lẫn nhau này. Ví dụ, khi ưu tiên hóa cho việc ra mắt một hệ thống mới, bạn có thể sẽ mời các đại diện kinh doanh và một nhóm khách hàng tương lai. Khi ưu tiên hóa product backlog để quyết định vòng lặp tiếp theo, nhóm scrum sẽ được tham gia.
Bước 4 – Xác định các yêu cầu phải được ưu tiên hóa
Khó có khả năng toàn bộ tập hợp các yêu cầu phải được ưu tiên hóa. Một lần nữa, điều này phụ thuộc chủ yếu vào các mục tiêu và ràng buộc cho việc ưu tiên hóa. Ví dụ, các 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 các yêu cầu mà bạn có sự lựa chọn về việc có đưa chúng vào bước tiếp theo của quá trình phát triển hay không. Điều này có nghĩa là giai đoạn dự án cũng là một yếu tố quan trọng. Trong giai đoạn đầu, bạn có thể đưa các bản nháp vào ưu tiên hóa; trong giai đoạn cuối, bạn thường sẽ hạn chế ưu tiên hóa đối với các yêu cầu đang ở phiên bản ổn định. Hãy lưu ý rằng các yêu cầu cần được ưu tiên hóa nên ở mức độ trừu tượng tương đương nhau tùy thuộc vào mục tiêu ưu tiên hóa. Ví dụ, trong giai đoạn đầu của dự án, bạn có thể ưu tiên hóa các chủ đề (themes) hoặc tính năng (features) trong khi ưu tiên hóa user story khi lập kế hoạch vòng lặp.
Bước 5 – Chọn kỹ thuật ưu tiên hóa
Một kỹ thuật ưu tiên hóa là cách thức mà các bên liên quan của bạn ưu tiên hóa các yêu cầu. Như được mô tả bên dưới, có nhiều kỹ thuật, khác nhau về công sức, sự kỹ lưỡng và mức độ chi tiết. Ở đây, các mục tiêu và ràng buộc cũng đặt ra bối cảnh, nhưng yếu tố quan trọng nhất là các bên liên quan tham gia đồng ý về kỹ thuật mà họ dự định sử dụng. Nếu không, họ sẽ không chấp nhận kết quả và nỗ lực ưu tiên hóa của bạn là vô ích.
Bước 6 – Thực hiện ưu tiên hóa
Khi tất cả công việc chuẩn bị đã hoàn thành, việc ưu tiên hóa thực tế có thể được tiến hành. Đầu tiên, tất cả các tiêu chí đánh giá đã xác định phải được áp dụng cho tất cả các yêu cầu được chọn. Cùng với các bên liên quan tham gia, bạn sau đó áp dụng kỹ thuật ưu tiên hóa đã chọn cho các yêu cầu được đánh giá. Kết quả là, bạn nhận được một danh sách yêu cầu được ưu tiên hóa. Tuy nhiên, có thể có một vấn đề. Các bên liên quan khác nhau có thể có các ưu tiên khác nhau, ngay cả khi họ đồng ý về các tiêu chí được đánh giá. Trong trường hợp đó, bạn thường có một mâu thuẫn yêu cầu cần được giải quyết giống như bất kỳ mâu thuẫn nào khác như được mô tả trong Phần 4.3 về giải quyết mâu thuẫn.
Nhìn kỹ hơn vào các kỹ thuật ưu tiên hóa, chúng ta phân biệt giữa hai loại:
Kỹ thuật ad-hoc (Ad hoc techniques)
Với các kỹ thuật ad-hoc, các chuyên gia gán các độ ưu tiên cho các yêu cầu được chọn dựa trên kinh nghiệm của chính họ. Về nguyên tắc, việc ưu tiên hóa này dựa trên một tiêu chí duy nhất, đó là nhận thức chủ quan của chuyên gia. Nếu sự chuyên môn này ở mức độ cao và được các bên liên quan chấp nhận, một kỹ thuật như vậy có thể là một cách nhanh chóng, rẻ tiền và dễ dàng để đạt được ưu tiên hóa. Một biến thể là mời nhiều chuyên gia và tính toán một loại độ ưu tiên trung bình. Các kỹ thuật ad-hoc phổ biến bao gồm xếp hạng Top-10 (Top-10 ranking) và ưu tiên hóa MoSCoW (Must have – Phải có, Should have – Nên có, Could have – Có thể có, Won’t have this time – Lần này sẽ không có). Phân tích Kano (Phần 4.2.1) cũng hữu ích: các yếu tố gây bất mãn (dissatisfiers) là must-have, các yếu tố thỏa mãn (satisfiers) là should-have, và các yếu tố làm hài lòng (delighters) có thể là could-have hoặc won’t-have. Để biết thêm bối cảnh, xem ví dụ [McIn2016].
Kỹ thuật phân tích (Analytical techniques)
Các kỹ thuật phân tích sử dụng một quy trình có hệ thống để gán các mức độ ưu tiên. Trong các kỹ thuật như vậy, các chuyên gia gán các trọng số cho nhiều tiêu chí đánh giá (chẳng hạn như lợi ích, chi phí, rủi ro, thời gian để triển khai, v.v.) và sau đó, các ưu tiên của yêu cầu được tính toán như là các kết quả có trọng số dựa trên các tiêu chí này. Các kỹ thuật như vậy mất nhiều công sức và thời gian hơn nhưng có ưu điểm là đưa ra một cái nhìn sâu sắc, rõ ràng vào các yếu tố quyết định các ưu tiên và vào quy trình qua đó các ưu tiên được thiết lập. Điều này có thể kích thích sự chấp nhận đối với kết quả giữa các bên liên quan. Tuy nhiên, hai khía cạnh phải được ghi nhớ. Thứ nhất, kết quả bị ảnh hưởng nặng nề bởi các yếu tố trọng số được sử dụng trong việc tính toán kết quả. Do đó, một sự thỏa thuận giữa các bên liên quan về các yếu tố trọng số này phải được thiết lập trước khi thực sự tiến hành ưu tiên hóa. Nếu không, một số người có thể cố gắng thay đổi các yếu tố trọng số để thao túng các ưu tiên. Khía cạnh thứ hai cần xem xét là các tiêu chí được đánh giá hầu hết là những ước tính, không phải là những sự thật được đo lường. Và các ước tính thường nằm trên một thang đo thứ tự đơn giản như thấp, trung bình, cao. Vì vậy, chất lượng của các ước tính mang tính quyết định đối với chất lượng của sự ưu tiên hóa được tạo thành. Tuy nhiên, các kỹ thuật phân tích vẫn hữu ích cho việc cung cấp một sự ưu tiên hóa được củng cố rõ ràng, dễ hiểu và do đó được các bên liên quan tham gia chấp nhận. Để có lời giải thích chi tiết về các kỹ thuật phân tích, hãy xem [Olso2014].
💡 Gợi ý: Có thể rất hấp dẫn khi áp dụng các kỹ thuật chi tiết, kỹ lưỡng và dành nhiều thời gian để tạo ra những ước tính chính xác hoàn hảo về tiền bạc, số giờ, số lượng doanh thu dự kiến, v.v. Điều này có thể dẫn đến việc yêu cầu A có mức ưu tiên được tính toán là 22.76, yêu cầu B là 23.12, và yêu cầu C là 20.29. Khi đó bạn sẽ kết luận rằng rõ ràng, C phải được thực hiện đầu tiên và A phải trước B. Tuy nhiên, bạn có thể vừa mới đưa vào một sự giả-chính xác (pseudo-accuracy) với phép tính này, và sẽ tốt hơn nếu kết luận rằng ba yêu cầu đó quan trọng như nhau, điều mà có thể là cảm giác trực giác của bạn ngay từ đầu. Luôn đảm bảo rằng nỗ lực bạn dành ra trong việc ưu tiên hóa được biện minh bởi giá trị của bản thân một sự ưu tiên hóa chính xác. Vì vậy một lần nữa, hãy ghi nhớ các mục tiêu và nhớ lại Nguyên tắc 1: định hướng giá trị (value orientation).
📌 GHI CHÚ ÔN THI
— 6.8 (EO 6.8.1–6.8.3)
- Lý do ưu tiên hóa: nguồn lực có hạn → phải quyết định requirements nào triển khai trước / vào bản phát hành nào.
- 6 bước theo đúng thứ tự: (1) Mục tiêu & ràng buộc → (2) Tiêu chí đánh giá → (3) Bên liên quan → (4) Tập requirements → (5) Kỹ thuật → (6) Thực hiện.
- 2 loại kỹ thuật:
| Ad hoc | Analytical | |
|---|---|---|
| Cơ sở quyết định | 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 | Giả-chính xác (pseudo-accuracy) |
- MoSCoW + Kano: Must=dissatisfier · Should=satisfier · Could/Won’t=delighter.
⚠️ BẪY ĐỀ THI
— 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 — kết quả 22.76 vs 23.12 không có nghĩa A quan trọng hơn B thực sự.
- Trọng số của analytical technique phải được thống nhất trước khi bắt đầu ưu tiên hóa — nếu không, có thể bị thao túng.
🔑 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 một yêu cầu theo các tiêu chí nhất định.
MoSCoW: Must have (phải có) · Should have (nên có) · Could have (có thể có) · Won’t have this time (lần này sẽ không có).
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ác ước tính trên thang đo thứ tự.
6.9 Tài liệu Đọc thêm (Further Reading)
Các cuốn sách giáo khoa của Pohl [Pohl2010], Davis [Davi2005], Hull, Jackson và Dick [HuJD2011], van Lamsweerde [vLam2009] và Wiegers và Beatty [WiBe2013] cung cấp một cái nhìn tổng quan toàn diện về quản lý yêu cầu. Các hiểu biết sâu sắc bổ sung về chủ đề quản lý yêu cầu được củng cố trong Sổ tay CPRE Cấp độ Nâng cao cho Quản lý Yêu cầu của Bühne và Herrmann [BuHe2024].
Cleland-Huang, Gotel và Zisman [CIGZ2012] cung cấp một sự luận bàn sâu sắc về truy xuất nguồn gốc.
Olson [Olso2014] và Wiegers [Wieg1999] đề cập đến 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 nguồn gốc 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 ad-hoc |
| 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 có tính 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 |