Bỏ qua

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

Nguồn gốc: Dịch từ CPRE Foundation Level Handbook v1.3.0, Chương 7, trang 147–152
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)

Kỹ sư Yêu cầu cần có công cụ để làm nghề — cũng như thợ mộc cần bút chì, búa, cưa và máy khoan. Không có công cụ, việc ghi lại, cộng tác và kiểm soát yêu cầu là rất khó, 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à nhiệm vụ khó nếu không có công cụ hỗ trợ. 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 chỉ tập trung hỗ trợ một số nhiệm vụ nhất định — chẳng hạn tài liệu hóa yêu cầu hoặc hỗ trợ quy trình RE — hiếm khi bao quát toàn bộ. Vì vậy, Kỹ sư Yêu cầu thường cần một bộ công cụ kết hợp. Cũng như thợ mộc cần phần mềm CAD để thiết kế, rồi cần cưa, bào, giấy nhám để gia công — mỗi công đoạn cần công cụ riêng.

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:

📌 Ô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 tool trong nhóm này có các thuộc tính cần thiết để hỗ trợ các hoạt động được mô tả trong Chương 6. Dùng các tool này, mức độ kiểm soát quy trình RE được nâng lên đáng kể. Yêu cầu luôn có thể thay đổi — và trong môi trường thay đổi thường xuyên, tool với các thuộc tính phù hợp là không thể thiếu. Các tool 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

⚠️ TRAP — 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)

Để điều chỉnh và cải tiến quy trình RE, cần có thông tin phản hồi. Loại tool này cung cấp thông tin đó thông qua hai chức năng chính:

  • Đ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.

⚠️ TRAP — 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 tích lũy trong một dự án — và trong suốt vòng đời sản phẩm — có thể rất lớn. Tất cả cần được lưu lại đầy đủ để phục vụ ba mục đích chính:

  • 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:

  • Sắp xếp và làm rõ tư duy — tool mô hình hóa có thể 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

⚠️ TRAP — 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 cùng làm việc trên một dự án — đặc biệt khi làm việc từ xa ngày càng phổ biến — tool cộng tác giúp duy trì và phối hợp công việc nhóm. Loại tool này hỗ trợ cả việc khai thác, tài liệu hóa lẫn 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)

Tool ngày càng tinh vi hơn, với nhiều tùy chọn cho việc kiểm thử và mô phỏng yêu cầu ngay từ đầu. Điều này giúp dự đoán sớm hơn liệu yêu cầu có đạt hiệu quả như kỳ vọng không.

Các tool hiện có thường là sự kết hợp của nhiều tính năng kể trên. Có thể cần dùng nhiều tool song song để bao phủ đủ RE. Khi đó, cần chú ý đến sự tích hợp giữa chúng và khả năng tương tác với các hệ thống khác, để đảm bảo vận hành thông suốt.

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

📌 Ô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:

  1. Kỹ sư Yêu cầu và bên liên quan đang kiểm soát tốt quy trình RE, VÀ
  2. 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)

Chọn tool RE không khác gì chọn bất kỳ công cụ nào: phải xác định mục tiêu, bối cảnh và yêu cầu trước — rồi mới chọn và triển khai.

Tool chỉ là phương tiện hỗ trợ quy trình RE và Kỹ sư Yêu cầu. Tool không giải quyết được vấn đề tổ chức hay con người. Ví dụ: cả nhóm muốn tài liệu hóa yêu cầu theo chuẩn thống nhất — tool có thể cung cấp mẫu sẵn (trong word processor hoặc wiki). Nhưng tool không đảm bảo đồng nghiệp sẽ tuân thủ, cũng không tạo ra kỷ luật làm việc. Cái thực sự giúp được là: thống nhất quy tắc với nhau, kiểm tra việc thực hiện, và trao đổi thẳng thắn khi quy tắc bị bỏ qua. Đưa tool RE vào tổ chức đòi hỏi trách nhiệm và quy trình RE phải được xác lập rõ ràng từ trước.

📌 Ô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.”

⚠️ TRAP — 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 khác, tool có thể giúp cấu hình quy trình RE hiệu quả hơn. Nhiều tool được xây dựng dựa trên kinh nghiệm thực tiễn tốt nhất, cung cấp sẵn một khung làm việc — có thể tùy chỉnh cho phù hợp với từng tổ chức.

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

Quy trình chọn tool bắt đầu từ việc xác định mục tiêu và vấn đề cần giải quyết trong RE. Tiếp theo là xác định bối cảnh của hệ thống — ở đây chính là bộ tool. Xem xét các bên liên quan, quy trình, sự kiện liên quan — rồi áp dụng kỹ năng RE để đặc tả yêu cầu cho chính tool đó. Hãy tự áp dụng chính những gì mình làm.

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ụ.

📌 Ô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.

📌 Ô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)

Đưa tool mới vào có thể đe dọa khả năng kiểm soát cơ sở yêu cầu hiện tại. Tình trạng hỗn loạn yêu cầu dễ xảy ra khi chuyển đổi từ cách làm cũ sang tool và phương pháp mới. Đặc biệt, đưa tool mới vào giữa chừng một dự án đang chạy sẽ chắc chắn dẫn đến chậm trễ bàn giao yêu cầu, thậm chí chậm cả 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.

📌 ÔN THI — 4 cách chạy pilot project (cần thuộc đủ):

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

⚠️ TRAP — Đư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:

📌 Ô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)

Góc nhìn này xác minh các chức năng tool cung cấp: yêu cầu có được bao phủ đủ không, dữ liệu lưu ở đâu, có lộ trình phát triển tính năng không, và tool 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.

⚠️ TRAP — 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)

Sau khi chọn xong tool, người dùng — tức các Kỹ sư Yêu cầu — cần được đào tạo để làm quen với những gì tool có thể hỗ trợ trong quy trình RE hiện tại. Không đào tạo đủ dẫn đến hai hệ quả: một là không khai thác hết lợi ích của tool, hai là tool bị dùng sai cách — kéo theo toàn bộ hậu quả đi kèm.

Bản thân việc đưa tool mới vào cũng có thể buộc phải thay đổi quy trình RE. Những việc trước đây không làm được — như quản lý phiên bản đầy đủ, mô hình hóa yêu cầu — nay trở nên khả thi. Điều đó dẫn đến: thống nhất quy trình mới, điều chỉnh mẫu tài liệu, thay đổi cách làm việc, v.v. Kỹ sư Yêu cầu tham gia vào quá trình thay đổi này là yếu tố then chốt để tool được chấp nhận.

📌 ÔN THI — 7.2.5: Hai hệ quả khi không đào tạo đủ:

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

📌 Ô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)

Một số tài liệu tham khảo hữu ích về công cụ RE và phương pháp đánh giá tool: Juan M. Carrillo de Gea và các cộng sự cung cấp cái nhìn toàn diện về vai trò của các công cụ RE [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

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 4 cách chạy pilot project (7.2.3): không quan trọng / song song / giả định / đã hoàn thành
  7. Đà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.