Chương 7 - Hỗ trợ của Công cụ (Tool Support)

Mục tiêu học tập (Syllabus v3.3.0):
— EO 7.1.1: Biết các loại công cụ RE khác nhau (L1 — liệt kê)
— EO 7.2.1: Giải thích những gì cần cân nhắc khi đưa công cụ RE vào tổ chức (L2 — giải thích có lý do)

Một Kỹ sư Yêu cầu cần có công cụ để thực hành nghề nghiệp của mình một cách đúng đắn — giống như một người thợ mộc cần các công cụ của mình: bút chì, búa, cưa và máy khoan để thiết kế và hiện thực hóa một món đồ nội thất. Nếu không có công cụ, việc ghi lại các yêu cầu, cùng làm việc trên các yêu cầu và kiểm soát các yêu cầu là rất khó khăn hoặc thậm chí không thể thực hiện được.

Chương này xem xét các loại công cụ Kỹ nghệ Yêu cầu (RE) khác nhau hiện có, cũng như các khía cạnh cần được tính đến khi đưa công cụ Kỹ nghệ Yêu cầu vào một tổ chức.

7.1 Các Công cụ trong Kỹ nghệ Yêu cầu (Tools in Requirements Engineering)

Kỹ nghệ Yêu cầu là một nhiệm vụ khó khăn nếu không có sự hỗ trợ của công cụ. Công cụ là cần thiết để hỗ trợ các nhiệm vụ và hoạt động Kỹ nghệ Yêu cầu. Các công cụ hiện có thường tập trung vào việc hỗ trợ các nhiệm vụ cụ thể — chẳng hạn như tài liệu hóa yêu cầu hoặc hỗ trợ quy trình RE — và hiếm khi bao quát toàn bộ các nhiệm vụ và hoạt động trong quy trình Kỹ nghệ Yêu cầu. Vì vậy không có gì ngạc nhiên khi Kỹ sư Yêu cầu phải có sẵn một bộ công cụ để hỗ trợ các thành phần khác nhau trong quy trình Kỹ nghệ Yêu cầu — cũng giống như người thợ mộc cần nhiều loại công cụ khác nhau (ví dụ: phần mềm thiết kế có máy tính hỗ trợ — CAD) để thiết kế một món đồ nội thất, và cần các công cụ như cưa, bào, giấy nhám để hiện thực hóa nó.

Công cụ chỉ là phương tiện hỗ trợ cho quy trình Kỹ nghệ Yêu cầu và Kỹ sư Yêu cầu. Các công cụ như vậy được gọi là công cụ CASE (kỹ thuật phần mềm có máy tính hỗ trợ — computer-aided software engineering). Công cụ CASE hỗ trợ một nhiệm vụ cụ thể trong quy trình sản xuất phần mềm [Fugg1993].

🔑 THUẬT NGỮ

— CASE tool:**

Tiếng Anh: “CASE (computer-aided software engineering) tools support a specific task in the software production process.”
Tiếng Việt: Công cụ CASE là công cụ hỗ trợ một nhiệm vụ cụ thể trong quy trình sản xuất phần mềm. Mọi công cụ RE đều là công cụ CASE.

Chúng ta phân biệt các loại công cụ khác nhau hỗ trợ các khía cạnh sau của Kỹ nghệ Yêu cầu:

📌 GHI CHÚ ÔN THI

— EO 7.1.1 (L1): Phải thuộc đủ 6 nhóm tool** và biết mỗi nhóm phục vụ mục đích gì. Đây là L1 — liệt kê chính xác, không cần giải thích sâu.

■ Quản lý yêu cầu (Management of requirements)

Các công cụ trong nhóm này có các thuộc tính cần thiết để hỗ trợ các hoạt động và chủ đề được mô tả trong Chương 6. Với các công cụ thuộc loại này, có thể thiết lập mức độ kiểm soát cao hơn đối với quy trình Kỹ nghệ Yêu cầu. Yêu cầu luôn có thể thay đổi, và trong một môi trường mà điều này xảy ra thường xuyên, một công cụ có các thuộc tính phù hợp là không thể thiếu. Các công cụ trong nhóm này hỗ trợ:

Định nghĩa và lưu trữ các thuộc tính yêu cầu nhằm xác định và thu thập dữ liệu về sản phẩm công việc và yêu cầu, như mô tả trong Mục 6.5
Hỗ trợ và tài liệu hóa việc ưu tiên hóa yêu cầu (Mục 6.8)
Quản lý vòng đời, kiểm soát phiên bản, cấu hình và đường cơ sở như mô tả trong các Mục 6.2, 6.3 và 6.4
Theo dõi và truy xuất nguồn gốc yêu cầu, cũng như các khiếm khuyết trong yêu cầu và sản phẩm công việc (Mục 6.6)
Quản lý thay đổi đối với yêu cầu — như đã học ở Mục 6.7, thay đổi là điều không thể tránh khỏi và cần được quản lý cẩn thận

⚠️ BẪY ĐỀ THI

— Câu A0922 (practice exam, EO 7.1.2): “Nhiệm vụ nào KHÔNG phải năng lực của tool Quản lý yêu cầu?” → Đáp án C: “Đo lường và báo cáo về quy trình RE” — đây thuộc nhóm Quản lý quy trình RE**, không phải Quản lý yêu cầu. Lưu ý thêm: “Mô hình hóa yêu cầu” (đáp án B) cũng không thuộc nhóm này — nhưng C mới là đáp án đúng vì xa nhất về khái niệm.

■ Quản lý quy trình RE (Management of the RE process)

Để hỗ trợ quy trình Kỹ nghệ Yêu cầu, cần có thông tin để cho phép điều chỉnh hoặc cải tiến quy trình. Loại công cụ này có thể:

Đo lường và báo cáo về quy trình và luồng công việc Kỹ nghệ Yêu cầu
Thông tin này giúp cải thiện quy trình Kỹ nghệ Yêu cầu và giảm thiểu lãng phí.
Đo lường và báo cáo về chất lượng sản phẩm
Thông tin này giúp phát hiện các khiếm khuyết và lỗ hổng, từ đó có thể được sử dụng để cải thiện chất lượng sản phẩm.

⚠️ BẪY ĐỀ THI

— Ranh giới nhóm 1 vs nhóm 2:**

“Đo lường và báo cáo về quy trình RE” → Quản lý quy trình RE (nhóm 2)
“Theo dõi và truy xuất nguồn gốc yêu cầu” → Quản lý yêu cầu (nhóm 1)

Nguyên tắc phân biệt: nhóm 1 hướng vào yêu cầu cụ thể, nhóm 2 hướng vào quy trình RE tổng thể.

■ Tài liệu hóa kiến thức về yêu cầu (Documentation of knowledge about the requirements)

Lượng kiến thức (và yêu cầu) được tích lũy trong một dự án có thể rất lớn. Ngoài ra, một lượng lớn kiến thức về sản phẩm cũng được tích lũy trong suốt vòng đời của nó. Tất cả thông tin liên quan cần được tài liệu hóa cẩn thận để đáp ứng các mục đích sau:

Chia sẻ và tạo ra sự hiểu biết chung về yêu cầu
Bảo đảm yêu cầu như một nghĩa vụ pháp lý
Tổng quan và hiểu sâu về các yêu cầu

■ Mô hình hóa yêu cầu (Modeling of requirements)

Như đã học ở Mục 3.4.1.6, diễn đạt yêu cầu bằng cả sơ đồ lẫn ngôn ngữ tự nhiên sẽ tận dụng được điểm mạnh của cả hai hình thức ký hiệu. Một công cụ có khả năng mô hình hóa yêu cầu cho phép:

Cấu trúc hóa tư duy của bản thân — có thể được dùng như một công cụ hỗ trợ tư duy
Xác định yêu cầu bằng ngôn ngữ chính thức hơn so với yêu cầu dạng văn bản thuần túy, với tất cả các lợi ích đi kèm

⚠️ BẪY ĐỀ THI

— Nhóm 3 vs nhóm 4: “Mô hình hóa yêu cầu” là nhóm riêng biệt (nhóm 4)**, không phải một phần của “Tài liệu hóa kiến thức (nhóm 3)”. Handbook tách hẳn hai nhóm này. Đề thi có thể hỏi “Mô hình hóa thuộc nhóm nào?” — không phải Tài liệu hóa.

■ Cộng tác trong Kỹ nghệ Yêu cầu (Collaboration in Requirements Engineering)

Khi nhiều người và nhiều lĩnh vực chuyên môn khác nhau cùng làm việc trên một dự án, một công cụ có thể hỗ trợ và tạo điều kiện cho sự cộng tác đó — đặc biệt trong thế giới hiện nay, khi ngày càng nhiều hoạt động được thực hiện tại chỗ (tại nhà). Loại công cụ này hỗ trợ việc khai thác, tài liệu hóa và quản lý yêu cầu.

■ Kiểm thử và/hoặc mô phỏng yêu cầu (Testing and/or simulation of the requirements)

Các công cụ ngày càng trở nên tinh vi hơn. Ngày càng có nhiều tùy chọn được phát triển cho việc kiểm thử và/hoặc mô phỏng yêu cầu trước. Điều này cho phép dự đoán tốt hơn liệu các yêu cầu được đề xuất có đạt được hiệu quả như mong muốn hay không.

Các công cụ hiện có thường là sự kết hợp của các tính năng kể trên. Như đã đề cập, có thể cần kết hợp nhiều công cụ khác nhau để hỗ trợ Kỹ nghệ Yêu cầu một cách đầy đủ. Nếu sử dụng nhiều công cụ, điều quan trọng là phải chú ý đến sự tích hợp giữa chúng và sự tương tác với các ứng dụng và hệ thống khác, nhằm đảm bảo hoạt động thông suốt.

Đôi khi, các loại công cụ khác — ví dụ như công cụ văn phòng hoặc công cụ theo dõi vấn đề — được sử dụng, hay nói đúng hơn là bị lạm dụng, để tài liệu hóa hoặc quản lý yêu cầu. Tuy nhiên, các công cụ này có những hạn chế và chỉ nên được sử dụng khi các Kỹ sư Yêu cầu và các bên liên quan đang kiểm soát tốt quy trình RE và các yêu cầu đã được căn chỉnh. Nếu không, đây là một rủi ro lớn trong quy trình RE, vì các công cụ đó không hỗ trợ bất kỳ hoạt động quản lý yêu cầu nào.

📌 GHI CHÚ ÔN THI

— Điều kiện dùng office/issue-tracking tool: Chỉ hợp lệ khi đồng thời** thoả hai điều kiện:

Kỹ sư Yêu cầu và bên liên quan đang kiểm soát tốt quy trình RE, VÀ
Các yêu cầu đã được căn chỉnh (requirements are aligned)

Thiếu một trong hai → đây là rủi ro lớn, không phải lựa chọn hợp lệ.

7.2 Đưa Công cụ vào Sử dụng (Introducing Tools)

Việc lựa chọn một công cụ RE không khác gì việc lựa chọn công cụ cho bất kỳ mục đích nào khác. Bạn cần mô tả các mục tiêu, bối cảnh và yêu cầu trước khi lựa chọn và triển khai công cụ phù hợp.

Công cụ chỉ là phương tiện hỗ trợ cho quy trình Kỹ nghệ Yêu cầu và Kỹ sư Yêu cầu. Chúng không giải quyết được các vấn đề về tổ chức hay con người. Hãy tưởng tượng rằng bạn và các đồng nghiệp muốn tài liệu hóa yêu cầu theo một cách thống nhất. Công cụ có thể hỗ trợ điều này — chẳng hạn bằng một mẫu tài liệu trong công cụ soạn thảo văn bản hoặc trang wiki. Nhưng điều đó không đảm bảo rằng tất cả đồng nghiệp sẽ áp dụng phương pháp làm việc này, cũng không đảm bảo rằng họ có đủ kỷ luật để ghi lại và quản lý yêu cầu theo cách đó. Điều có thể giúp ích là cùng nhau đưa ra các thỏa thuận, kiểm tra xem các thỏa thuận có được thực hiện không, và có thể trao đổi với nhau khi các thỏa thuận không được tuân thủ. Một công cụ sẽ không giúp bạn làm được điều đó. Việc đưa công cụ Kỹ nghệ Yêu cầu vào sử dụng đòi hỏi phải có trách nhiệm và quy trình Kỹ nghệ Yêu cầu rõ ràng.

📌 GHI CHÚ ÔN THI

— Nguyên tắc cốt lõi 7.2 (L2): Tool không giải quyết được vấn đề tổ chức hay con người. Trước khi chọn tool, phải thực hiện đúng quy trình RE: (1) xác định mục tiêu → (2) xác định bối cảnh → (3) đặc tả yêu cầu cho chính tool đó. Đây là ứng dụng RE vào việc chọn tool — “Practice what you preach.”

⚠️ BẪY ĐỀ THI

— Câu K0910-B (practice exam): “Việc lựa chọn tool nên để người dùng tự quyết định” → FALSE** Lý do: Lựa chọn tool đòi hỏi quy trình có hệ thống gồm 7 góc nhìn đánh giá. Người dùng chỉ là một trong số đó (User perspective).

Một công cụ có thể giúp bạn cấu hình quy trình Kỹ nghệ Yêu cầu một cách hiệu lực và hiệu quả. Các công cụ thường cung cấp một khung làm việc được xây dựng dựa trên kinh nghiệm từ các thực tiễn tốt nhất. Các khung làm việc này sau đó có thể được tùy chỉnh để phù hợp với từng tình huống cụ thể.

Như đã học ở các chương trước, các hoạt động cốt lõi của Kỹ nghệ Yêu cầu không phải là các quy trình độc lập.

Việc lựa chọn công cụ RE phù hợp bắt đầu từ việc xác định các mục tiêu và/hoặc vấn đề bạn muốn giải quyết trong quy trình RE. Bước tiếp theo là xác định bối cảnh của hệ thống (trong trường hợp này là bộ công cụ). Hãy cân nhắc các khía cạnh của bối cảnh — tức là các bên liên quan, quy trình, sự kiện, v.v. — và áp dụng các kỹ năng Kỹ nghệ Yêu cầu của bạn để xác định yêu cầu cho chính công cụ RE đó. Hãy tự áp dụng chính những nguyên tắc của mình.

Các mục tiếp theo mô tả một số khía cạnh cần được tính đến khi đưa một công cụ Kỹ nghệ Yêu cầu (mới) vào tổ chức của bạn.

7.2.1 Tính đến Toàn bộ Chi phí Vòng đời, Không chỉ Chi phí Giấy phép (Consider All Life Cycle Costs beyond License Costs)

Các chi phí rõ ràng nhất, chẳng hạn như chi phí mua hoặc chi phí cấp phép, thường đã được tính đến. Ngoài ra, các chi phí ít thấy hơn cũng phải được xem xét, chẳng hạn như việc sử dụng nguồn lực trong quá trình triển khai, vận hành và bảo trì công cụ.

📌 GHI CHÚ ÔN THI

— 7.2.1: Chi phí hay bị bỏ sót = triển khai + vận hành + bảo trì** (không chỉ mua/cấp phép).

7.2.2 Tính đến Các Nguồn lực Cần thiết (Consider Necessary Resources)

Việc xác định yêu cầu và giám sát quá trình lựa chọn đòi hỏi các nguồn lực cần thiết, ngoài các chi phí đã đề cập ở mục trước. Những người cần thiết để hướng dẫn quá trình lựa chọn, các Kỹ sư Yêu cầu, nguồn lực phần cứng và các nguồn lực khác không nên bị bỏ qua. Sau khi công cụ đã được đưa vào sử dụng, các nguồn lực cũng có thể được yêu cầu cho việc bảo trì và hỗ trợ người dùng.

📌 GHI CHÚ ÔN THI

— Phân biệt 7.2.1 vs 7.2.2:**

7.2.1 = chi phí tài chính (mua, cấp phép, triển khai, vận hành, bảo trì)
7.2.2 = nguồn lực con người và kỹ thuật (người hướng dẫn lựa chọn, RE, phần cứng, hỗ trợ sau triển khai)

7.2.3 Tránh Rủi ro bằng cách Chạy các Dự án Thí điểm (Avoid Risks by Running Pilot Projects)

Việc đưa vào một công cụ mới có thể đe dọa khả năng kiểm soát đối với cơ sở yêu cầu hiện tại. Một tình trạng hỗn loạn về yêu cầu có thể phát sinh vì có sự chuyển đổi từ phương pháp làm việc và/hoặc công cụ cũ sang phương pháp làm việc và công cụ mới. Việc đưa một công cụ mới vào trong một dự án đang thực hiện chắc chắn sẽ dẫn đến sự chậm trễ trong việc bàn giao yêu cầu và thậm chí toàn bộ dự án.

🔑 THUẬT NGỮ

— requirements base / requirements chaos:**

Tiếng Anh: “The introduction of a new tool can threaten the control over the current requirements base.”
Requirements base (cơ sở yêu cầu): toàn bộ yêu cầu đang được kiểm soát tại một thời điểm.
Requirements chaos (hỗn loạn yêu cầu): tình trạng mất kiểm soát đối với yêu cầu, thường xảy ra khi chuyển đổi tool không có kế hoạch.

Việc đưa công cụ mới vào — có thể kèm theo phương pháp làm việc khác — nên được thử nghiệm ở quy mô nhỏ, nơi các rủi ro và tác động vẫn ở mức có thể kiểm soát được. Có một số cách để thực hiện điều này:

Áp dụng công cụ vào một dự án/hệ thống không quan trọng
Sử dụng công cụ song song (dự phòng) bên cạnh một dự án đang thực hiện
Áp dụng công cụ vào một tình huống/dự án giả định
Nhập/sao chép yêu cầu từ một dự án đã hoàn thành

Khi bạn đã đạt đến điểm mà công cụ đáp ứng được các mục tiêu và yêu cầu đã đặt ra, nó có thể được triển khai rộng rãi hơn trong tổ chức hoặc cho các dự án khác.

📌 GHI CHÚ ÔN THI

— 4 cách chạy pilot project (cần thuộc đủ):**

Dự án/hệ thống không quan trọng
Song song bên cạnh dự án đang chạy
Tình huống/dự án giả định
Nhập yêu cầu từ dự án đã hoàn thành

⚠️ BẪY ĐỀ THI

— Đưa tool mới vào dự án đang chạy: Handbook dùng từ “irrevocably” (chắc chắn, không thể tránh khỏi) — không phải “có thể” gây chậm trễ. Đây là khẳng định tuyệt đối: không bao giờ** đưa tool mới vào giữa chừng dự án.

7.2.4 Đánh giá Công cụ theo các Tiêu chí đã Xác định (Evaluate the Tool according to Defined Criteria)

Việc lựa chọn công cụ phù hợp có thể là một nhiệm vụ khó khăn. Xác minh kỹ lưỡng xem liệu các mục tiêu và yêu cầu có được đáp ứng hay không là một phương pháp tiếp cận tiêu chuẩn trong Kỹ nghệ Yêu cầu. Một phương pháp tiếp cận có hệ thống, đánh giá công cụ từ nhiều góc nhìn khác nhau, cũng góp phần đưa ra lựa chọn đúng đắn. Các góc nhìn sau đây có thể được xem xét:

📌 GHI CHÚ ÔN THI

— 7 góc nhìn đánh giá tool (EO 7.2.1, L2):**

Góc nhìn	Câu hỏi trọng tâm
Dự án (Project)	Tool hỗ trợ thông tin quản lý dự án cần thiết không?
Quy trình (Process)	Tool hỗ trợ đủ quy trình RE? Có thể tùy chỉnh theo quy trình hiện tại không?
Người dùng (User)	Dễ dùng? Phân quyền đủ không? Người dùng có chấp nhận không?
Sản phẩm (Product)	Chức năng đủ? Lưu dữ liệu ở đâu? Có lộ trình phát triển không? Còn được hỗ trợ không?
Nhà cung cấp (Supplier)	Ở đâu? Hỗ trợ được tổ chức như thế nào?
Kinh tế (Economic)	Lợi ích có xứng chi phí? Cần hợp đồng bảo trì riêng không?
Kiến trúc (Architecture)	Phù hợp hạ tầng IT? Liên kết được với hệ thống khác không? Tuân thủ ràng buộc kiến trúc không?

■ Góc nhìn dự án (Project perspective)

Góc nhìn này nhấn mạnh các khía cạnh quản lý dự án. Công cụ có hỗ trợ dự án và các thông tin cần thiết trong dự án không?

■ Góc nhìn quy trình (Process perspective)

Góc nhìn này xác minh mức độ hỗ trợ đối với quy trình Kỹ nghệ Yêu cầu. Công cụ có hỗ trợ đầy đủ quy trình RE không? Công cụ có thể được điều chỉnh đủ để phù hợp với quy trình RE và phương pháp làm việc hiện tại không?

■ Góc nhìn người dùng (User perspective)

Góc nhìn này xác minh mức độ áp dụng thực tế của những người dùng công cụ. Đây là góc nhìn quan trọng, vì nếu người dùng không hài lòng với công cụ, rủi ro công cụ không được chấp nhận sẽ tăng lên. Công cụ có hỗ trợ đầy đủ việc phân quyền cho người dùng và nhóm không? Công cụ có đủ thân thiện với người dùng và trực quan không?

■ Góc nhìn sản phẩm (Product perspective)

Các chức năng mà công cụ cung cấp được xác minh từ góc độ này. Các yêu cầu có được công cụ bao phủ đầy đủ không? Dữ liệu được lưu trữ ở đâu? Có lộ trình phát triển cho các phần mở rộng chức năng của công cụ không? Công cụ có còn được nhà cung cấp hỗ trợ trong thời gian tới không?

■ Góc nhìn nhà cung cấp (Supplier perspective)

Với góc nhìn này, trọng tâm nằm ở dịch vụ và độ tin cậy của nhà cung cấp. Nhà cung cấp ở đâu? Hỗ trợ cho công cụ này được sắp xếp như thế nào?

■ Góc nhìn kinh tế (Economic perspective)

Góc nhìn này xem xét luận điểm lợi ích-chi phí: công cụ có mang lại đủ lợi ích so với chi phí không? Chi phí (quản lý) cho việc mua sắm và bảo trì là bao nhiêu? Công cụ đóng góp gì cho quy trình RE? Có cần một hợp đồng bảo trì (riêng biệt) không?

🔑 THUẬT NGỮ

— business case:**

Tiếng Anh: “This perspective looks at the business case: does the tool deliver sufficient benefits in relation to the costs?”
Tiếng Việt: Luận điểm lợi ích-chi phí — đánh giá liệu lợi ích có xứng đáng với chi phí bỏ ra không.

■ Góc nhìn kiến trúc (Architecture perspective)

Góc nhìn này đánh giá mức độ phù hợp của công cụ với tổ chức (về mặt công nghệ thông tin). Công nghệ được áp dụng có phù hợp với tổ chức không? Công cụ có thể được liên kết đầy đủ với các hệ thống khác không? Công cụ có phù hợp với toàn cảnh IT của tổ chức và có tuân thủ các ràng buộc về kiến trúc không?

🔑 THUẬT NGỮ

— IT landscape:**

Tiếng Anh: “Does the tool fit into the IT landscape and does it comply with the architectural constraints?”
Tiếng Việt: Toàn cảnh IT — bức tranh tổng thể về hạ tầng, hệ thống và công nghệ đang được sử dụng trong tổ chức.

⚠️ BẪY ĐỀ THI

— Câu K0910-C và K0910-D (practice exam):**

C: Tool phải hỗ trợ thiết lập test case cho shift-left testing → FALSE — nội dung này không tồn tại trong Chương 7. Đây là bẫy ngoài phạm vi syllabus EU7.
D: Lựa chọn tool bị ảnh hưởng bởi chuỗi công cụ hiện có → TRUE — thuộc Góc nhìn Kiến trúc: tool mới phải liên kết được với các hệ thống khác đang dùng.

7.2.5 Hướng dẫn Nhân viên Cách Sử dụng Công cụ (Instruct Employees on the Use of the Tool)

Một khi công cụ đã được chọn, người dùng nên làm quen với những cơ hội mà công cụ có thể mang lại cho quy trình Kỹ nghệ Yêu cầu. Người dùng — tức là các Kỹ sư Yêu cầu — nên được đào tạo về cách sử dụng công cụ trong quy trình Kỹ nghệ Yêu cầu hiện tại. Nếu người dùng không được đào tạo đầy đủ, điều này có thể dẫn đến việc không phải tất cả các lợi ích của công cụ được khai thác. Thực tế, có thể công cụ sẽ bị sử dụng sai cách, kéo theo tất cả các hệ quả liên quan.

Quy trình Kỹ nghệ Yêu cầu cũng có thể bị thay đổi do chính công cụ được chọn. Các khía cạnh trong quy trình Kỹ nghệ Yêu cầu vốn không thể thực hiện được trước đây nay có thể trở nên khả thi với một công cụ mới — ví dụ: quản lý phiên bản đầy đủ, mô hình hóa yêu cầu, v.v. Điều này có thể đồng nghĩa với việc các quy trình (thủ tục) mới được thống nhất, các mẫu tài liệu được điều chỉnh hoặc áp dụng, các thay đổi được thực hiện đối với phương pháp làm việc, v.v. Sự tham gia của Kỹ sư Yêu cầu vào quá trình thay đổi này góp phần vào sự thành công trong việc chấp nhận công cụ.

📌 GHI CHÚ ÔN THI

— 7.2.5: Hai hệ quả khi không đào tạo đủ:**

Không khai thác hết lợi ích của tool
Tool bị dùng sai cách → kéo theo toàn bộ hệ quả liên quan

📌 GHI CHÚ ÔN THI

— Tool có thể buộc thay đổi quy trình RE: Không phải điều xấu — nhưng sự tham gia của Kỹ sư Yêu cầu** trong quá trình thay đổi là yếu tố quyết định sự thành công trong việc chấp nhận tool.

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

Tài liệu sau đây có thể được tham khảo để có cái nhìn tổng quan về các công cụ hiện có và các đánh giá về công cụ. Juan M. Carrillo de Gea và các cộng sự cung cấp một cái nhìn toàn diện về vai trò của các công cụ Kỹ nghệ Yêu cầu [dGeA2011].

Bài viết của Barbara Kitchenham, Stephen Linkman và David Law [KiLL1997] mô tả và xác nhận một phương pháp đánh giá công cụ có hệ thống. Nếu bạn đang tìm kiếm một công cụ RE, danh sách đầy đủ các công cụ Kỹ nghệ Yêu cầu được cung cấp trên trang web Volere [Vole2026] hoặc tại [BiHe2020].

Phần tổng hợp ôn thi

🔑 Thuật ngữ cần thuộc nguyên văn tiếng Anh

Thuật ngữ tiếng Anh	Định nghĩa gốc (Handbook)	Tiếng Việt
CASE tool	Tools that support a specific task in the software production process	Công cụ hỗ trợ một nhiệm vụ cụ thể trong quy trình sản xuất phần mềm
Requirements base	The current set of requirements under control	Cơ sở yêu cầu — toàn bộ yêu cầu đang được kiểm soát tại một thời điểm
Requirements chaos	Loss of control over requirements during tool/method transition	Hỗn loạn yêu cầu — mất kiểm soát khi chuyển đổi công cụ hoặc phương pháp làm việc
Aligned (requirements)	Requirements agreed and stabilized by stakeholders	Yêu cầu đã được căn chỉnh / đồng thuận
Business case	Assessment of whether benefits sufficiently outweigh costs	Luận điểm lợi ích-chi phí
IT landscape	The overall picture of IT infrastructure, systems, and technologies in use	Toàn cảnh IT của tổ chức
Irrevocably	Without possibility of reversal — certain, unavoidable	Chắc chắn / không thể tránh khỏi
Pilot project	Small-scale test of a tool before wider organizational rollout	Dự án thí điểm — thử nghiệm quy mô nhỏ trước khi triển khai rộng

📌 Điểm quan trọng cần nhớ khi thi

6 nhóm tool RE (EO 7.1.1 — L1): Quản lý yêu cầu / Quản lý quy trình RE / Tài liệu hóa kiến thức / Mô hình hóa yêu cầu / Cộng tác / Kiểm thử và mô phỏng
Office/issue-tracking tool chỉ hợp lệ khi đồng thời đủ 2 điều kiện: quy trình RE đang kiểm soát tốt VÀ yêu cầu đã căn chỉnh
Tool không giải quyết vấn đề tổ chức/con người — phải có trách nhiệm và quy trình RE rõ ràng trước
Quy trình chọn tool = ứng dụng RE: xác định mục tiêu → xác định bối cảnh → đặc tả yêu cầu cho tool
7 góc nhìn đánh giá tool (7.2.4 — L2): Dự án / Quy trình / Người dùng / Sản phẩm / Nhà cung cấp / Kinh tế / Kiến trúc
4 cách chạy pilot project (7.2.3): không quan trọng / song song / giả định / đã hoàn thành
Đào tạo người dùng (7.2.5): thiếu đào tạo → không khai thác hết lợi ích VÀ có thể dùng sai

⚠️ Bẫy phổ biến trong đề thi

Phát biểu sai	Sự thật đúng
“Đo lường quy trình RE” thuộc nhóm Quản lý yêu cầu	❌ Thuộc Quản lý quy trình RE
“Mô hình hóa yêu cầu” là một phần của Tài liệu hóa kiến thức	❌ Là nhóm riêng biệt
Có thể đưa tool mới vào dự án đang thực hiện	❌ Chắc chắn (irrevocably) gây chậm trễ
Lựa chọn tool nên để người dùng tự quyết	❌ Cần quy trình có hệ thống, 7 góc nhìn đánh giá
Tool phải hỗ trợ shift-left testing (K0910-C)	❌ Ngoài phạm vi Chương 7 hoàn toàn
“Irrevocably” = “có thể” gây chậm trễ	❌ = chắc chắn, không thể tránh khỏi

Đáp án câu hỏi Practice Exam — Chương 7

K0910 (2 điểm, EO 7.2.1) — True/False:

	Đáp án	Căn cứ trong Handbook
A) Tool phải hỗ trợ các sản phẩm công việc mà quy trình RE yêu cầu	✅ TRUE	7.2: xác định yêu cầu cho chính tool trước khi chọn
B) Lựa chọn tool nên để người dùng tự quyết	❌ FALSE	Cần 7 góc nhìn có hệ thống, không chỉ user
C) Tool phải hỗ trợ thiết lập test case cho shift-left testing	❌ FALSE	Không tồn tại trong nội dung Chương 7
D) Lựa chọn tool bị ảnh hưởng bởi chuỗi công cụ hiện có	✅ TRUE	Góc nhìn Kiến trúc — liên kết với hệ thống khác

A0922 (1 điểm, EO 7.1.2) — Nhiệm vụ nào KHÔNG thuộc tool Quản lý yêu cầu?

	Nhóm thực sự thuộc về	Đáp án
A) Theo dõi quan hệ logic giữa các yêu cầu	Quản lý yêu cầu ✓
B) Mô hình hóa yêu cầu	Mô hình hóa (nhóm riêng)
C) Đo lường và báo cáo về quy trình RE	Quản lý quy trình RE	✅ ĐÁP ÁN ĐÚNG
D) Ưu tiên hóa yêu cầu	Quản lý yêu cầu ✓

Bản dịch đối chiếu 100% với CPRE Foundation Level Handbook v1.3.0, Chương 7, trang 147–152. Ghi chú ôn thi dựa trên Syllabus CPRE FL v3.3.0 và Practice Exam Set_Public_EN_3.3.2.