📝 Đề Thi Thử — CPRE Foundation Level (Set Public EN 3.3.2)
Thông tin đề thi thử
- Nguồn gốc: IREB Practice Exam — Questionnaire Set_Public_EN_3.3.2 (Syllabus v3.3.0)
- Tổng điểm tối đa: 70 điểm | Điểm đậu: 49 điểm (70%)
- Thời gian: 75 phút (hoặc 90 phút nếu thi bằng ngôn ngữ không phải tiếng mẹ đẻ)
- Số câu hỏi: 45 câu (K = Đúng/Sai, A = 1 đáp án, P = nhiều đáp án)
- Lưu ý: Câu hỏi dạng K/P — chọn sai số lượng ô trong cùng 1 hàng/câu = 0 điểm cả câu đó
Cách sử dụng hiệu quả nhất
Đọc câu hỏi → Tự suy nghĩ → Rồi mới click "Xem đáp án & giải thích" để kiểm tra.
Chương 1 — Giới thiệu & Tổng quan về RE (4 điểm)
Câu 1 — K 2 điểm EO 1.1.1
Với mỗi phát biểu sau về yêu cầu chất lượng (quality requirements), hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Quality requirements đề cập đến QUY TRÌNH tạo ra phần mềm, không phải sản phẩm. | ||
| B) Quality requirements có thể bổ sung cho functional requirements. | ||
| C) Quality requirements được khơi gợi SAU KHI đã hoàn thành functional requirements. | ||
| D) Quality requirements có thể được cụ thể hóa bằng các functional requirements bổ sung. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Sai: Quality requirements mô tả các thuộc tính của sản phẩm (hiệu năng, bảo mật, độ tin cậy...), không phải của quy trình làm việc.
- B = Đúng: Ví dụ, một quality requirement về hiệu năng ("response time < 2s") hoàn toàn có thể bổ sung và ràng buộc một functional requirement ("hệ thống phải xử lý đơn hàng").
- C = Sai: Quality requirements được khơi gợi song song với functional requirements, không phải sau. Chúng thường ảnh hưởng lẫn nhau.
- D = Đúng: Một quality requirement trừu tượng ("hệ thống phải đảm bảo tính sẵn sàng cao") có thể được cụ thể hóa bằng các functional requirements như "tự động chuyển đổi sang server dự phòng khi server chính gặp sự cố."
Câu 2 — A 1 điểm EO 1.4.1
Nhiệm vụ nào sau đây KHÔNG phải là nhiệm vụ cốt lõi của Kỹ sư Yêu cầu? (1 đáp án)
A) Eliciting requirements (Khơi gợi yêu cầu)
B) Formalizing requirements (Hình thức hóa yêu cầu)
C) Documenting requirements (Tài liệu hóa yêu cầu)
D) Validating requirements (Thẩm định yêu cầu)
Xem đáp án & giải thích
Đáp án: B
"Formalizing" (hình thức hóa / dùng ký hiệu hình thức) không nằm trong danh sách các nhiệm vụ cốt lõi của RE theo IREB. Bốn nhóm nhiệm vụ cốt lõi là: Eliciting (khơi gợi), Documenting (tài liệu hóa), Consolidating/Validating (thẩm định & đồng thuận), và Managing (quản lý). Việc dùng ký hiệu hình thức (formal notation) chỉ là một kỹ thuật tùy chọn trong tài liệu hóa, không phải một nhiệm vụ độc lập.
Câu 3 — P 1 điểm EO 1.3.2
Khách hàng đưa ra các yêu cầu sau với nhà thầu phát triển hệ thống thông tin:
- A) Nhà thầu phải xử lý một change request trong vòng năm ngày.
- B) Báo cáo kiểm thử từ integration test phải được cung cấp để kiểm tra, và báo cáo từ system test phải được bàn giao.
- C) Hệ thống phải cho phép thông lượng 100 giao dịch mỗi giây vào bất kỳ lúc nào.
- D) Công cụ Subversion phải được dùng để quản lý cấu hình.
- E) Trong điều kiện tải bình thường, thời gian phản hồi không được vượt quá hai giây trong 90% trường hợp.
Hai yêu cầu nào đề cập đến HỆ THỐNG cần xây dựng? (2 đáp án)
A) Yêu cầu A B) Yêu cầu B C) Yêu cầu C D) Yêu cầu D E) Yêu cầu E
Xem đáp án & giải thích
Đáp án: C và E
- C = Đúng: "100 giao dịch/giây" là một quality requirement về hiệu năng (throughput) của hệ thống — mô tả thuộc tính của sản phẩm cần xây dựng.
- E = Đúng: "Thời gian phản hồi ≤ 2s" là quality requirement về hiệu năng (response time) của hệ thống.
- A là ràng buộc về quy trình của nhà thầu (process constraint). B là yêu cầu về tài liệu (documentation). D là ràng buộc về công cụ (tool constraint).
Chương 2 — Nguyên tắc Cơ bản của RE (6 điểm)
Câu 4 — A 1 điểm EO 2.1.1
Phát biểu nào sau đây KHÔNG phải là nguyên tắc cơ bản của Kỹ nghệ Yêu cầu (RE)? (1 đáp án)
A) Value orientation (Định hướng giá trị)
B) Problem — requirement — solution (Vấn đề → yêu cầu → giải pháp)
C) Regular retrospectives (Họp tổng kết định kỳ)
D) Systematic and disciplined work (Làm việc có hệ thống và kỷ luật)
Xem đáp án & giải thích
Đáp án: C
"Regular retrospectives" (họp cải tiến định kỳ) là một thực hành của Scrum/Agile, không phải một trong 9 nguyên tắc cơ bản của RE theo IREB. Chín nguyên tắc của IREB bao gồm: Value orientation, System thinking, View points, Shared understanding, Problem-requirement-solution, Agreed requirements, Abstraction, Iterative approach, Systematic and disciplined work.
Câu 5 — K 2 điểm EO 2.2.1
Shared understanding (Hiểu biết chung) là một nguyên tắc của RE. Với mỗi phát biểu sau, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Đạt được explicit shared understanding (hiểu biết chung tường minh) là một trong những mục tiêu chính của RE. | ||
| B) Nếu không có shared understanding, sẽ không thể xác định được các nguồn yêu cầu (requirement sources) liên quan. | ||
| C) Một mức độ implicit shared understanding (hiểu biết chung ngầm định) nhất định là không thể thiếu vì không thể đặc tả mọi thứ một cách tường minh. | ||
| D) RE trong phát triển agile không thể vận hành nếu không dựa vào implicit shared understanding. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Đúng: RE nhằm tạo ra sự hiểu biết chung rõ ràng giữa tất cả các bên về hệ thống cần xây dựng.
- B = Đúng: Nếu không có shared understanding cơ bản, các bên sẽ nói về những vấn đề khác nhau, không thể xác định ai là stakeholder liên quan hay yêu cầu đến từ đâu.
- C = Đúng: Không thể đặc tả tường minh tất cả mọi thứ — luôn có một lượng kiến thức ngầm định được các bên mặc nhiên chia sẻ (ví dụ: luật lệ ngành, quy ước hiển nhiên).
- D = Đúng: Agile thậm chí còn dựa nhiều hơn vào implicit shared understanding giữa team và khách hàng, thay vì đặc tả tường minh đầy đủ.
Câu 6 — K 2 điểm EO 2.2.2
Khi xác định system boundary (ranh giới hệ thống) và context boundary (ranh giới ngữ cảnh), các khía cạnh nào CẦN được xem xét và không cần được xem xét?
| Cần xét đến | Không cần xét đến | |
|---|---|---|
| A) Bản thân hệ thống (the system) | ||
| B) System context (ngữ cảnh hệ thống) | ||
| C) Application domain (lĩnh vực ứng dụng) | ||
| D) Các interface giữa hệ thống và system context |
Xem đáp án & giải thích
| Cần xét đến | Không cần xét đến | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích: Tất cả bốn khía cạnh đều cần được xem xét khi xác định ranh giới:
- A: Hệ thống là đối tượng trung tâm cần được xác định rõ phạm vi.
- B: System context bao gồm tất cả những gì tồn tại ngoài hệ thống nhưng có thể ảnh hưởng đến nó hoặc bị nó ảnh hưởng — cần xác định để biết context boundary nằm ở đâu.
- C: Application domain (lĩnh vực chuyên môn, ví dụ: tài chính, y tế) là nền tảng để hiểu ngữ cảnh và xác định những gì thuộc phạm vi context.
- D: Các interface xác định điểm kết nối giữa hệ thống và môi trường — không thể xác định system boundary mà bỏ qua.
Câu 7 — A 1 điểm EO 2.2.2
Trong quá trình RE cho một ứng dụng cơ sở dữ liệu trực tuyến, bạn phát hiện ra các quy định bảo vệ dữ liệu không áp dụng vì dữ liệu được xử lý là dữ liệu ẩn danh. Phát hiện này sẽ ảnh hưởng đến yếu tố nào? (1 đáp án)
A) System boundary (ranh giới hệ thống)
B) Context boundary (ranh giới ngữ cảnh)
C) System interfaces (các interface của hệ thống)
D) Application boundary (ranh giới ứng dụng)
Xem đáp án & giải thích
Đáp án: B
Các quy định pháp lý (luật bảo vệ dữ liệu) là một phần của môi trường/ngữ cảnh bên ngoài hệ thống. Khi các quy định này không áp dụng, thành phần "môi trường pháp lý" đó bị loại ra khỏi phạm vi cần quan tâm — tức là context boundary thay đổi. System boundary (phạm vi những gì hệ thống thực hiện) và system interfaces (kết nối kỹ thuật) không bị ảnh hưởng trực tiếp.
⚠️ Bẫy: "Application boundary" không phải thuật ngữ chuẩn của IREB.
Chương 3 — Sản phẩm Công việc & Thực hành Tài liệu hóa (30 điểm)
Câu 8 — A 1 điểm EO 3.1.1
Phát biểu nào sau đây về work products (sản phẩm công việc) là KHÔNG đúng? (1 đáp án)
A) Bất kỳ thông tin được ghi lại nào được tạo ra trong quá trình RE đều là work product.
B) Các artifact được ghi lại mô tả thông tin đã thu thập dưới dạng kết quả trung gian hoặc cuối cùng đều là work products.
C) User stories, activity diagrams, use cases và prototypes đều là work products.
D) Chỉ có tài liệu yêu cầu cuối cùng mô tả một tập hợp yêu cầu cố định mới là work products.
Xem đáp án & giải thích
Đáp án: D
Phát biểu D sai vì định nghĩa của IREB về work product bao gồm cả các kết quả trung gian (intermediate results), không chỉ tài liệu yêu cầu cuối cùng. Ví dụ: bản ghi phỏng vấn, prototype, activity diagram trong quá trình phân tích — tất cả đều là work products. Phát biểu A, B, C đều đúng với định nghĩa này.
Câu 9 — A 1 điểm EO 3.4.6
Khái niệm nào sau đây KHÔNG thể tìm thấy trong UML class diagrams? (1 đáp án)
A) Associations (quan hệ kết hợp)
B) States (trạng thái)
C) Multiplicities (bội số/số lượng)
D) Attributes (thuộc tính)
Xem đáp án & giải thích
Đáp án: B
States (trạng thái) là yếu tố của statecharts/state diagrams (biểu đồ trạng thái), không xuất hiện trong class diagrams. Class diagrams mô tả cấu trúc tĩnh của hệ thống: classes, attributes, associations và multiplicities — nhưng không thể hiện các trạng thái động của đối tượng.
Câu 10 — P 2 điểm EO 3.8.2
Bạn muốn thiết kế một tài liệu yêu cầu phù hợp tốt nhất với những người sẽ làm việc với nó trong các giai đoạn tiếp theo. Chọn hai sự kết hợp tốt nhất giữa vai trò và tiêu chí chất lượng yêu cầu. (2 đáp án)
A) Đối với tester, yêu cầu phải có khả năng hiện thực hóa (realizable).
B) Đối với developer, yêu cầu phải dễ dàng thay đổi (changeable).
C) Đối với tất cả mọi người liên quan, các yêu cầu trong work product phải nhất quán (consistent).
D) Đối với project manager, các yêu cầu phải cần thiết (necessary).
E) Đối với bộ phận bảo trì, yêu cầu phải có thể ưu tiên hóa (prioritizable).
Xem đáp án & giải thích
Đáp án: C và D
- C = Đúng: Tính nhất quán (consistency) mang lại lợi ích cho tất cả các bên — developer, tester, PM, maintenance đều bị ảnh hưởng nếu các yêu cầu mâu thuẫn nhau.
- D = Đúng: Project manager cần biết mỗi yêu cầu có thực sự cần thiết (necessary) không để quản lý scope và tránh lãng phí nguồn lực.
- A Sai: Realizable (có thể hiện thực hóa) là tiêu chí của developer/architect, không phải tester.
- B Sai: Changeability (dễ thay đổi) quan trọng với bộ phận bảo trì hơn là developer ban đầu.
- E Sai: Prioritization là nhiệm vụ của PM/PO, không đặc trưng cho maintenance.
Câu 11 — P 2 điểm EO 3.1.2
Một công ty muốn hỗ trợ quy trình chuẩn bị đấu thầu bằng một hệ thống thông tin. Trong các cuộc thảo luận ban đầu, bạn phát hiện: (1) bạn không hiểu một số thuật ngữ của công ty; (2) các đại diện không dùng thuật ngữ nhất quán; (3) người liên lạc chính mô tả kỳ vọng dưới dạng các luồng tương tác giữa chuyên gia và hệ thống. Hai cách tiếp cận nào đặc biệt phù hợp để khơi gợi và tài liệu hóa yêu cầu trong trường hợp này? (2 đáp án)
A) Tạo statechart
B) Xây dựng glossary (bảng thuật ngữ)
C) Khơi gợi và tài liệu hóa quality requirements
D) Tạo use case diagram và đặc tả các use cases
E) Tạo và kiểm thử prototypes
Xem đáp án & giải thích
Đáp án: B và D
- B = Đúng: Vấn đề thuật ngữ không nhất quán → cần glossary để đồng thuận về định nghĩa chung. Đây là giải pháp trực tiếp cho vấn đề (1) và (2).
- D = Đúng: "Luồng tương tác giữa người dùng và hệ thống" là mô tả điển hình của use cases. Use case diagram phù hợp để mô hình hóa dạng yêu cầu này.
- A Sai: Statechart phù hợp cho hệ thống có nhiều trạng thái, không phải vấn đề thuật ngữ hay luồng tương tác.
- C Sai: Quality requirements là bước tiếp theo, không phải ưu tiên hàng đầu ở giai đoạn này.
- E Sai: Prototype hữu ích nhưng không giải quyết trực tiếp vấn đề thuật ngữ và mô tả luồng.
Câu 12 — K 2 điểm EO 3.1.2
Các phát biểu sau đây về việc chọn notation (ký hiệu) để tài liệu hóa functional requirements — phát biểu nào ÁP DỤNG và không áp dụng?
| Áp dụng | Không áp dụng | |
|---|---|---|
| A) Stakeholders phải có khả năng đọc được notation được dùng cho work product. | ||
| B) Diagrams BẮT BUỘC phải được áp dụng trong các dự án phát triển hướng đối tượng (OO). | ||
| C) Để đảm bảo giao tiếp tối ưu, nên dùng notation phù hợp với loại yêu cầu. | ||
| D) Graphical notations rất phù hợp để mô tả system requirements. |
Xem đáp án & giải thích
| Áp dụng | Không áp dụng | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Áp dụng: Stakeholders cần hiểu được tài liệu để có thể validate và cho phản hồi — đây là yêu cầu tối quan trọng khi chọn notation.
- B = Không áp dụng: Không có quy tắc bắt buộc phải dùng diagrams chỉ vì dự án là OO. Việc chọn notation phụ thuộc vào loại yêu cầu và đối tượng sử dụng.
- C = Áp dụng: Mỗi loại yêu cầu phù hợp với một notation khác nhau (use case cho luồng tương tác, class diagram cho cấu trúc dữ liệu...).
- D = Áp dụng: Graphical notations (sơ đồ) có lợi thế trong việc mô tả hành vi, luồng và cấu trúc — phù hợp cho system requirements.
Câu 13 — K 2 điểm EO 3.8.2
IREB định nghĩa các tiêu chí chất lượng cho work products. Với các phát biểu sau, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Một requirements specification được gọi là non-redundant (không dư thừa) nếu mỗi yêu cầu chỉ được tài liệu hóa một lần và không chồng lấp với các yêu cầu khác. | ||
| B) Một use case diagram có thể không nhất quán với một activity diagram dù cả hai đều non-redundant. | ||
| C) Một requirements specification được gọi là consistent (nhất quán) nếu không có yêu cầu đơn lẻ nào mâu thuẫn với các yêu cầu khác. | ||
| D) Một use case specification được gọi là conformant (phù hợp chuẩn) nếu nó chứa đủ tất cả các yêu cầu liên quan đến sản phẩm cuối. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A, B, C = Đúng — đây là định nghĩa chuẩn của IREB.
- D = Sai: ⚠️ Bẫy kinh điển! "Conformant" (phù hợp chuẩn) nghĩa là tài liệu tuân thủ các quy tắc/chuẩn đã thỏa thuận (templates, quy ước, quy định), không phải là "chứa đủ tất cả yêu cầu liên quan." Thuộc tính đó là "Complete" (đầy đủ). Hai tiêu chí này hoàn toàn khác nhau.
Câu 14 — P 2 điểm EO 3.3.1
Phrase template (mẫu câu lệnh) có thể được dùng để tài liệu hóa yêu cầu bằng ngôn ngữ tự nhiên. Bạn muốn giới thiệu template này trong dự án và cần thuyết phục project manager. Hai lập luận nào sau đây là tốt nhất? (2 đáp án)
A) Phrase templates giúp tài liệu hóa yêu cầu có cấu trúc tốt bằng cách cung cấp một cấu trúc cú pháp (syntactic structure) được định sẵn.
B) Yêu cầu viết theo phrase template sẽ không chứa các quan hệ không đầy đủ (incomplete relationships).
C) Việc học cách viết yêu cầu theo phrase template không đòi hỏi nhiều thời gian.
D) Dùng phrase template về cơ bản mang lại mức độ thông tin nhiều hơn.
E) Yêu cầu viết theo phrase template đảm bảo rằng các tiêu chí chất lượng cho yêu cầu được đáp ứng.
Xem đáp án & giải thích
Đáp án: A và C
- A = Đúng: Đây là lợi ích cốt lõi — cấu trúc cú pháp định sẵn giúp yêu cầu có dạng chuẩn, dễ đọc, dễ kiểm tra tính đầy đủ.
- C = Đúng: Từ góc độ thuyết phục project manager, phrase template tương đối đơn giản để học so với các ký hiệu hình thức (formal notations), giúp hạ thấp rào cản áp dụng.
- B Sai: Templates giúp giảm thiểu nhưng không đảm bảo loại bỏ hoàn toàn các quan hệ không đầy đủ.
- D Sai: Templates cung cấp cấu trúc tốt hơn, không nhất thiết nhiều thông tin hơn về mặt nội dung.
- E Sai: "Đảm bảo" (ensure) là quá tuyệt đối — templates hỗ trợ chất lượng nhưng không thể đảm bảo.
Câu 15 — A 1 điểm EO 3.2.1
Yêu cầu sau đây có vấn đề nghiêm trọng nhất là gì? "The system Alpha should display all data sets in all submenus." (1 đáp án)
A) Yêu cầu được viết theo thể bị động (passive voice).
B) Đã sử dụng universal quantifiers (từ định lượng toàn thể — "all").
C) Yêu cầu có điều kiện không đầy đủ (incomplete conditions).
D) Đã sử dụng nominalizations (danh từ hóa).
Xem đáp án & giải thích
Đáp án: B
Từ "all" (tất cả) xuất hiện hai lần: "all data sets" và "all submenus" — đây là universal quantifiers, một bẫy ngôn ngữ nguy hiểm trong viết yêu cầu. Nó tạo ra phạm vi không rõ ràng và thường không thể kiểm thử đầy đủ (mọi data set trong mọi submenu là bao nhiêu?). Lưu ý: câu ở thể chủ động ("should display"), không có nominalization rõ ràng, và không thiếu điều kiện.
Câu 16 — K 2 điểm EO 3.3.1
Với các phát biểu sau khi làm việc với template-based work products, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Templates cung cấp blueprint để cấu trúc hóa cả yêu cầu đơn lẻ lẫn toàn bộ đặc tả. | ||
| B) Template-based work products cho yêu cầu đơn lẻ có thể giúp ngăn ngừa việc diễn đạt yêu cầu không đầy đủ bằng ngôn ngữ tự nhiên. | ||
| C) Template-based work products về bản chất có nội dung tốt hơn các yêu cầu được viết tự do. | ||
| D) Templates là bắt buộc đối với tất cả các tác giả của một requirements specification. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Đúng: Templates có thể hoạt động ở cả hai cấp độ: cấu trúc từng câu yêu cầu (phrase template) hoặc cấu trúc toàn bộ tài liệu (document template).
- B = Đúng: Khi template yêu cầu điền vào các trường bắt buộc (subject, verb, object, condition), nó giúp phát hiện và ngăn ngừa các thiếu sót thường gặp.
- C = Sai: Templates chỉ cung cấp cấu trúc — nội dung vẫn phụ thuộc hoàn toàn vào kiến thức và kinh nghiệm của người viết.
- D = Sai: Templates là công cụ hỗ trợ, không phải quy tắc bắt buộc.
Câu 17 — A 1 điểm EO 3.4.4
Một hệ thống quản lý đội xe courier cần được phát triển. Hệ thống phải định kỳ truyền vị trí địa lý của xe về trung tâm. Các yêu cầu sau được tài liệu hóa:
- R1: "Hệ thống phải hoạt động khi chìa khóa còn trong ổ khóa."
- R2: "Hệ thống phải hoạt động khi có tài xế ngồi ở ghế lái."
- R3: "Hệ thống phải chuyển sang chế độ lost-signal nếu có ít hơn ba vệ tinh khả dụng."
Loại sơ đồ nào phù hợp nhất để hỗ trợ loại yêu cầu này? (1 đáp án)
A) State diagram (Biểu đồ trạng thái)
B) Class diagram (Biểu đồ lớp)
C) Context diagram (Biểu đồ ngữ cảnh)
D) Use case diagram (Biểu đồ use case)
Xem đáp án & giải thích
Đáp án: A
R1, R2, R3 mô tả các điều kiện hoạt động (operational states) và điều kiện chuyển đổi trạng thái của hệ thống (khi nào ON, khi nào lost-signal). Đây là bài toán điển hình cho state diagram (biểu đồ trạng thái / statechart). Class diagram mô tả cấu trúc dữ liệu; context diagram mô tả ranh giới hệ thống; use case diagram mô tả chức năng từ góc nhìn người dùng.
Câu 18 — K 2 điểm EO 3.4.6
Để hỗ trợ các diễn viên và đạo diễn trẻ, một cuộc thi phim ngắn được tổ chức (3 phim hay nhất được trao giải, thời lượng tối đa 20 phút). Sơ đồ dưới đây mô tả các ràng buộc cần tuân thủ. Các phát biểu sau có khớp với sơ đồ không?
| Khớp | Không khớp | |
|---|---|---|
| A) Ba đạo diễn có thể cùng đạo diễn một bộ phim. | ||
| B) Một bộ phim chỉ có một diễn viên vẫn có thể dự thi. | ||
| C) Một đạo diễn có thể đạo diễn hai bộ phim trong cuộc thi. | ||
| D) Một diễn viên có thể đóng trong số lượng phim bất kỳ. | ||
| E) Một bộ phim bắt buộc phải có đúng mười diễn viên. |
Xem đáp án & giải thích
| Khớp | Không khớp | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ | |
| E) | ✅ |
Giải thích (dựa trên bội số trong sơ đồ gốc):
- A = Không khớp: Sơ đồ giới hạn số đạo diễn tối đa là 2 cho mỗi phim (không phải 3).
- B = Khớp: Số lượng diễn viên tối thiểu mỗi phim ≥ 1 (không yêu cầu tối thiểu cao hơn).
- C = Khớp: Sơ đồ cho phép một đạo diễn đạo diễn nhiều phim (bao gồm 2 phim).
- D = Khớp: Một diễn viên có thể tham gia vào số lượng phim tùy ý (multiplicity = *).
- E = Không khớp: Sơ đồ không quy định cố định 10 diễn viên bắt buộc.
Câu 19 — A 1 điểm EO 3.4.4
Điều gì KHÔNG được thể hiện trong use case diagram? (1 đáp án)
A) Các bước quy trình (process steps) của ứng dụng
B) Các actor của ứng dụng
C) Ranh giới giữa ứng dụng và môi trường của nó
D) Chức năng (functionality) của ứng dụng
Xem đáp án & giải thích
Đáp án: A
Use case diagram thể hiện cái gì hệ thống làm (what), không phải như thế nào (how). Cụ thể: - B: Actor → có (hình người que bên ngoài hệ thống) - C: Ranh giới hệ thống → có (hình chữ nhật bao quanh use cases) - D: Chức năng → có (các use cases là các chức năng từ góc nhìn người dùng) - A: Các bước quy trình (process steps) → KHÔNG có — đây là nội dung của activity diagram hoặc sequence diagram.
Câu 20 — K 2 điểm EO 3.4.5
Một công ty muốn đưa ra quy trình ủy quyền truy cập các phần bảo mật của intranet bằng mật khẩu có thời hạn. Sơ đồ dưới đây mô tả các trạng thái và chuyển đổi trạng thái của người dùng. Hãy xác định các yêu cầu nào được mô hình hóa ĐÚNG và yêu cầu nào sai hoặc không có trong sơ đồ.
| Đúng trong sơ đồ | Sai / Không có trong sơ đồ | |
|---|---|---|
| A) Người dùng ở trạng thái blocked có thể được mở khóa bằng cách đặt lại mật khẩu. | ||
| B) Nếu phát hiện lạm dụng với người dùng ở trạng thái entitled, mật khẩu sẽ bị khóa. | ||
| C) Nếu thời hạn hiệu lực của mật khẩu người dùng entitled hết hạn, mật khẩu bị xóa và người dùng chuyển về trạng thái not entitled. | ||
| D) Nếu yêu cầu ứng dụng được chấp thuận, người dùng nhận được email thông báo. |
Xem đáp án & giải thích
| Đúng trong sơ đồ | Sai / Không có trong sơ đồ | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Sai/Không có: Sơ đồ không mô hình hóa việc mở khóa (unblock) từ trạng thái blocked bằng cách đặt lại mật khẩu.
- B = Đúng: Transition từ entitled → blocked khi phát hiện lạm dụng được thể hiện trong sơ đồ.
- C = Đúng: Transition từ entitled → not entitled khi hết hạn hiệu lực có trong sơ đồ.
- D = Sai/Không có: Sơ đồ không mô hình hóa việc gửi email thông báo khi yêu cầu được chấp thuận.
Câu 21 — K 2 điểm EO 3.4.7
Sơ đồ dưới đây mô tả quy trình thực hiện một phép đo. Các phát biểu sau có KHỚP với sơ đồ không?
| Khớp | Không khớp | |
|---|---|---|
| A) "Initialize measuring device" phải xảy ra TRƯỚC "Register at server". | ||
| B) "Register at server" xảy ra ngay khi "Load certificates" hoàn thành. | ||
| C) "Initialize network connection" và "Load certificates" phải kết thúc CÙNG LÚC. | ||
| D) "Deactivate measuring device" được thực thi ngay khi "Data receipt confirmed" = true. |
Xem đáp án & giải thích
| Khớp | Không khớp | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Không khớp: Trong sơ đồ, "Initialize measuring device" và "Register at server" không có quan hệ bắt buộc theo thứ tự đó — chúng có thể diễn ra song song hoặc theo thứ tự khác.
- B = Không khớp: "Register at server" không phụ thuộc trực tiếp vào "Load certificates" một mình — có nhiều hoạt động song song khác cần hoàn thành.
- C = Không khớp: Hai hoạt động này chạy song song nhưng không có synchronization bar (thanh đồng bộ) yêu cầu kết thúc cùng lúc.
- D = Khớp: Có một guard condition/decision rõ ràng trong sơ đồ: khi "Data receipt confirmed" = true, hệ thống thực thi "Deactivate measuring device".
Câu 22 — P 2 điểm EO 3.4.2
Trong RE, hai ưu điểm THỰC CHẤT nào của graphical models (ví dụ: use case models, state machines) so với đặc tả văn bản thuần túy bằng ngôn ngữ tự nhiên? (2 đáp án)
A) Models thường tập trung vào các khía cạnh cụ thể và giảm tải nhận thức (cognitive load) khi hiểu yêu cầu.
B) Models cho phép mô tả đầy đủ (complete description) tất cả yêu cầu cho hệ thống.
C) Models có thể được kiểm tra dễ dàng hơn ngôn ngữ tự nhiên và có cú pháp hạn chế làm giảm sự mơ hồ và thiếu sót.
D) Models được tạo bằng công cụ có repository nên phù hợp hơn cho việc quản lý yêu cầu.
E) Với công cụ thích hợp, source code có thể được sinh ra từ models, tiết kiệm nỗ lực kiểm thử.
Xem đáp án & giải thích
Đáp án: A và C
- A = Đúng: Mỗi loại sơ đồ chỉ tập trung vào một khía cạnh nhất định (ví dụ: state diagram chỉ về trạng thái), giúp người đọc dễ hiểu hơn thay vì phải đọc nhiều trang văn bản.
- C = Đúng: Cú pháp hình thức của UML/BPMN có quy tắc cụ thể → giảm mơ hồ; có thể dùng công cụ để kiểm tra tính đúng đắn cú pháp tự động.
- B Sai: Models là trừu tượng hóa (abstraction) — chúng tập trung vào khía cạnh cụ thể, không mô tả đầy đủ toàn bộ hệ thống.
- D Sai: Đây là ưu điểm của công cụ, không phải của bản thân models.
- E Sai: Code generation từ models không phổ biến và không phải ưu điểm chính của graphical models.
Câu 23 — K 2 điểm EO 3.4.7
Sơ đồ dưới đây mô tả quy trình tính toán tuyến đường của hệ thống navigation. Với mỗi phát biểu sau về sơ đồ, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Có thể tính toán tuyến đường mà không cần truy vấn thông tin giao thông. | ||
| B) Có thể tính toán tuyến đường SAU KHI đã truy vấn thông tin giao thông. | ||
| C) Hệ thống có thể hỏi người dùng về việc tính toán tuyến đường một cách linh động mà KHÔNG CẦN xác định tọa độ GPS trước. | ||
| D) Thứ tự của "Enter destination" và "Determine GPS coordinates" là tùy ý (có thể thực hiện theo thứ tự nào cũng được). |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Đúng: Trong sơ đồ, bước "Query traffic information" là tùy chọn (có nhánh bỏ qua bước này) — vẫn có thể tính tuyến đường trực tiếp.
- B = Đúng: Luồng có truy vấn thông tin giao thông trước khi tính toán cũng tồn tại trong sơ đồ.
- C = Sai: Tọa độ GPS phải được xác định TRƯỚC khi có thể tiến hành tính toán tuyến đường — đây là tiền điều kiện bắt buộc trong sơ đồ.
- D = Đúng: "Enter destination" và "Determine GPS coordinates" chạy song song (parallel fork), không có thứ tự bắt buộc giữa hai bước này.
Câu 24 — P 2 điểm EO 3.4.4
Bạn đang mô hình hóa yêu cầu cho hệ thống quản lý trường đại học. Các bước đăng ký cho sinh viên mới cần được tài liệu hóa bằng phương pháp model-based. Hai loại sơ đồ nào phù hợp nhất? (2 đáp án)
A) BPMN diagram
B) Laus-Ohl diagram
C) Activity diagram
D) Class diagram
E) Use case diagram
Xem đáp án & giải thích
Đáp án: A và C
- A = Đúng: BPMN (Business Process Model and Notation) là tiêu chuẩn công nghiệp cho việc mô hình hóa quy trình nghiệp vụ — hoàn toàn phù hợp để mô tả "các bước đăng ký."
- C = Đúng: Activity diagram (biểu đồ hoạt động) của UML mô tả luồng hoạt động step-by-step — phù hợp trực tiếp với yêu cầu.
- B Sai: "Laus-Ohl diagram" không phải là ký hiệu chuẩn trong IREB/UML.
- D Sai: Class diagram mô tả cấu trúc dữ liệu, không phải quy trình.
- E Sai: Use case diagram mô tả chức năng và actor, không mô tả chi tiết các bước của quy trình.
Câu 25 — A 1 điểm EO 3.1.4
Khi đặc tả một hệ thống, cần xem xét các khía cạnh khác nhau. Khía cạnh "function and flow" (chức năng và luồng) mô tả điều gì? (1 đáp án)
A) Khả năng di chuyển (portability) của hệ thống
B) Phản ứng của hệ thống với một chuyển đổi trạng thái nội bộ
C) Cấu trúc của dữ liệu đầu vào và đầu ra
D) Sự biến đổi dữ liệu đầu vào thành dữ liệu đầu ra
Xem đáp án & giải thích
Đáp án: D
Khía cạnh "function and flow" mô tả cách hệ thống xử lý/biến đổi dữ liệu đầu vào thành đầu ra — tức là luồng xử lý chức năng (functional flow). Các khía cạnh khác: portability (A) là quality requirement; phản ứng với state transition (B) thuộc khía cạnh hành vi/trạng thái; cấu trúc dữ liệu (C) thuộc khía cạnh dữ liệu (data aspect).
Chương 4 — Thực hành Xây dựng Yêu cầu (14 điểm)
Câu 26 — A 1 điểm EO 4.3.2
Bạn là Kỹ sư Yêu cầu trong một dự án và đang thu thập yêu cầu chi tiết cho một use case qua nhiều buổi phỏng vấn với các stakeholders khác nhau. Sau đó bạn phát hiện ra mâu thuẫn trong các phát biểu về cách sắp xếp chức năng trong menu trên giao diện người dùng. Cách xử lý tốt nhất là gì? (1 đáp án)
A) Bạn thảo luận phát hiện này với một stakeholder sẵn có và ghi lại lời khuyên của họ.
B) Bạn mời tất cả các stakeholders liên quan đến một cuộc họp và đạt được thỏa thuận về điểm này.
C) Dựa vào kinh nghiệm về giao diện người dùng, bạn tự giải quyết vấn đề để tiết kiệm thời gian.
D) Bạn chuyển vấn đề cho product owner và để họ quyết định dựa trên đánh giá rủi ro.
Xem đáp án & giải thích
Đáp án: B
Khi có mâu thuẫn giữa các stakeholders, cách giải quyết đúng là mời tất cả các bên liên quan để đạt được thỏa thuận chung (consensus). Đây là nguyên tắc "Agreed requirements" của IREB. Chỉ hỏi một người (A) có thể gây ra lệch lạc. Tự quyết định (C) là điều Kỹ sư Yêu cầu không được phép làm — quyết định phải thuộc về stakeholders. Chuyển cho product owner (D) có thể là bước tiếp theo nếu không đạt được thỏa thuận, nhưng không phải bước đầu tiên và tốt nhất.
Câu 27 — P 1 điểm EO 4.1.2
Hai phát biểu nào sau đây đặc trưng tốt nhất mối quan hệ giữa Kỹ sư Yêu cầu và stakeholder trong vai trò tester? (2 đáp án)
A) Kỹ sư Yêu cầu cung cấp đầu vào cho công việc của stakeholder.
B) Kết quả của Kỹ sư Yêu cầu được quản lý bởi stakeholder.
C) Stakeholder có thể đóng góp để đảm bảo chất lượng công việc của Kỹ sư Yêu cầu.
D) Stakeholder giám sát công việc của Kỹ sư Yêu cầu.
E) Không có mối quan hệ nào giữa công việc của Kỹ sư Yêu cầu và vai trò stakeholder.
Xem đáp án & giải thích
Đáp án: A và C
- A = Đúng: Requirements documents (đầu ra của RE) là đầu vào trực tiếp cho công việc của tester — tester thiết kế test cases dựa trên yêu cầu.
- C = Đúng: Tester có thể review yêu cầu để phát hiện lỗi, mâu thuẫn, hoặc yêu cầu không thể kiểm thử (không verifiable) → đóng góp vào chất lượng của RE.
- B Sai: Tester không "quản lý" kết quả của RE.
- D Sai: Tester không "giám sát" Kỹ sư Yêu cầu.
Câu 28 — A 1 điểm EO 4.2.2
Mô hình Kano cho rằng dissatisfiers (basic factors — yếu tố cơ bản) khó để khơi gợi. Kỹ thuật khơi gợi nào sau đây HIỆU QUẢ NHẤT đối với dissatisfiers? (1 đáp án)
A) Prototyping
B) Questionnaire (Bảng câu hỏi)
C) Field observation (Quan sát thực địa)
D) Brainstorming
Xem đáp án & giải thích
Đáp án: C
Dissatisfiers (basic factors) là những yêu cầu mà người dùng mặc nhiên kỳ vọng — họ không nhắc đến vì coi đó là hiển nhiên (chỉ bất mãn khi thiếu, không vui hơn khi có đủ). Vì vậy, hỏi trực tiếp (bảng câu hỏi, phỏng vấn) thường không phát hiện được. Field observation (quan sát người dùng làm việc thực tế) mới tiết lộ những kỳ vọng ngầm định này. Prototyping và brainstorming phù hợp hơn cho delighters (excitement factors).
Câu 29 — P 2 điểm EO 4.2.3
Hai khía cạnh nào QUAN TRỌNG NHẤT cần xem xét khi chọn kỹ thuật khơi gợi (elicitation technique) phù hợp? (2 đáp án)
A) Sự sẵn sàng của những người liên quan.
B) Sở thích cá nhân của Kỹ sư Yêu cầu.
C) Phân loại yêu cầu theo mô hình Kano.
D) Độ phức tạp của công cụ cần thiết.
E) Thói quen sử dụng một kỹ thuật quen thuộc.
Xem đáp án & giải thích
Đáp án: A và C
- A = Đúng: Kỹ thuật phỏng vấn yêu cầu stakeholder có mặt; quan sát thực địa đòi hỏi tiếp cận môi trường làm việc — sự sẵn sàng là ràng buộc thực tế quyết định kỹ thuật nào khả thi.
- C = Đúng: Như đã thấy ở Câu 28, loại yêu cầu (dissatisfier/satisfier/delighter) quyết định trực tiếp kỹ thuật nào hiệu quả nhất.
- B, D, E Sai: Sở thích cá nhân, độ phức tạp công cụ và thói quen không phải tiêu chí đúng đắn để lựa chọn kỹ thuật tốt nhất.
Câu 30 — A 1 điểm EO 4.3.2
Kỹ thuật nào sau đây KHÔNG phù hợp để giải quyết xung đột yêu cầu (requirements conflicts)? (1 đáp án)
A) Overruling (Ra lệnh quyết định)
B) Definition of variants (Định nghĩa các biến thể)
C) Compromise (Thỏa hiệp)
D) Sampling (Lấy mẫu)
Xem đáp án & giải thích
Đáp án: D
Sampling (lấy mẫu) là một kỹ thuật khơi gợi yêu cầu (elicitation) — ví dụ: lấy mẫu dữ liệu trong system archeology. Nó không phải là kỹ thuật giải quyết xung đột. Ba kỹ thuật giải quyết xung đột theo IREB là: Overruling (quyết định theo thẩm quyền cao hơn), Compromise (tìm điểm dung hòa), và Definition of variants (giữ nguyên cả hai nhu cầu dưới dạng biến thể khác nhau).
Câu 31 — P 2 điểm EO 4.1.4
Hai thuộc tính QUAN TRỌNG NHẤT trong một danh sách stakeholders là gì? (2 đáp án)
A) Chức năng/vai trò (function/role) của họ
B) Sở thích cá nhân của họ
C) Người quản lý trực tiếp (boss) của họ
D) Mức độ liên quan (relevance) của họ
E) Các dự án trước đây của họ
Xem đáp án & giải thích
Đáp án: A và D
- A = Đúng: Chức năng/vai trò xác định quan điểm (viewpoint) và lĩnh vực quan tâm của stakeholder — ảnh hưởng đến loại yêu cầu họ đóng góp.
- D = Đúng: Mức độ liên quan xác định mức độ ưu tiên tương tác với họ — ai cần được phỏng vấn kỹ, ai chỉ cần thông báo.
- B, C, E là thông tin phụ trợ, không phải thuộc tính cốt lõi trong quản lý stakeholders.
Câu 32 — P 1 điểm EO 4.2.2
Hai ưu điểm chính của việc dùng questionnaires (bảng câu hỏi) để khơi gợi yêu cầu là gì? (2 đáp án)
A) Questionnaires cho phép số lượng người tham gia lớn.
B) Questionnaires cho phép đưa ra các nhận định có ý nghĩa thống kê về yêu cầu.
C) Questionnaires cho phép kiểm tra mức độ hiểu biết của người tham gia.
D) Questionnaires cho phép thu thập nhiều insights nhất về delighters (excitement factors).
E) Questionnaires cho phép dễ dàng xử lý nhu cầu riêng của từng stakeholder.
Xem đáp án & giải thích
Đáp án: A và B
- A = Đúng: Questionnaire có thể gửi đồng thời cho hàng trăm người — ưu điểm về quy mô mà phỏng vấn trực tiếp không đạt được.
- B = Đúng: Với số lượng lớn người tham gia, kết quả questionnaire có thể được phân tích thống kê để xác định xu hướng yêu cầu.
- C Sai: Questionnaire là giao tiếp một chiều, không thể xác minh mức độ hiểu biết.
- D Sai: Questionnaire không phù hợp cho delighters (excitemet factors cần khám phá sáng tạo).
- E Sai: Questionnaire là chuẩn hóa, không dễ điều chỉnh cho từng cá nhân.
Câu 33 — K 2 điểm EO 4.2.2
Với các phát biểu sau về kỹ thuật khơi gợi yêu cầu, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Interview (phỏng vấn) là một gathering technique (kỹ thuật thu thập). | ||
| B) Analogy technique (kỹ thuật tương tự) là một gathering technique. | ||
| C) System archeology (khảo cổ học hệ thống) là một observation technique (kỹ thuật quan sát). | ||
| D) Apprenticing (học việc/theo dõi thực tế) là một observation technique. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
IREB phân loại kỹ thuật khơi gợi thành: gathering (thu thập từ nguồn có sẵn), observation (quan sát trực tiếp), và creativity/idea-generating (tạo ý tưởng mới).
- A = Đúng: Interview thu thập kiến thức từ stakeholders → gathering.
- B = Sai: Analogy technique dùng để tạo ra yêu cầu mới bằng cách so sánh với hệ thống khác → creativity/idea-generating, không phải gathering.
- C = Sai: System archeology phân tích tài liệu và hệ thống hiện có để khai thác thông tin → đây là gathering (artifact-based), không phải observation.
- D = Đúng: Apprenticing = quan sát người dùng trong môi trường làm việc thực tế, đôi khi tham gia trực tiếp → observation.
Câu 34 — A 1 điểm EO 4.3.1
Đối với một hệ thống navigation dùng trên quốc tế, một stakeholder yêu cầu chỉ dùng giọng nữ cho đầu ra giọng nói. Một stakeholder khác cho rằng điều này mang tính phân biệt và yêu cầu thêm giọng nam. Loại xung đột nào mô tả tốt nhất tình huống này? (1 đáp án)
A) Relationship conflict (xung đột quan hệ cá nhân)
B) Interest conflict (xung đột lợi ích)
C) Structural conflict (xung đột cấu trúc)
D) Value conflict (xung đột giá trị)
Xem đáp án & giải thích
Đáp án: D
Hai stakeholders có quan điểm trái ngược nhau dựa trên hệ giá trị và niềm tin khác nhau (một người coi "chỉ giọng nữ" là bình thường, người kia coi đó là phân biệt giới tính). Đây là value conflict (xung đột giá trị) — không phải về lợi ích vật chất (interest conflict), không phải về quan hệ cá nhân (relationship conflict), và không phải về nguồn lực hay tổ chức (structural conflict).
Câu 35 — A 2 điểm EO 4.4.3
Trong dự án của bạn, một hệ thống phanh mới cho tàu cao tốc đang được phát triển. Kỹ thuật thẩm định (validation) nào phù hợp nhất để thẩm định các yêu cầu hệ thống của một cấu phần an toàn quan trọng (safety-critical component)? (1 đáp án)
A) A/B testing
B) Prototype
C) Walkthrough
D) Inspection
Xem đáp án & giải thích
Đáp án: D
Inspection là kỹ thuật review chính thức và có cấu trúc nhất — với checklist, vai trò được phân công rõ (moderator, author, reviewers), quy trình phát hiện lỗi nghiêm ngặt. Đây là lựa chọn phù hợp nhất cho hệ thống safety-critical như phanh tàu cao tốc, nơi sai sót có thể gây thảm họa. Walkthrough ít chính thức hơn và phụ thuộc nhiều vào tác giả. Prototype không phù hợp cho phần cứng safety-critical đắt tiền. A/B testing dùng cho sản phẩm consumer, không phải safety-critical.
Chương 5 — Quy trình & Cấu trúc Công việc (3 điểm)
Câu 36 — P 2 điểm EO 5.2.1
Hai facet (chiều cấu hình) QUAN TRỌNG NHẤT cần xem xét khi cấu hình một quy trình RE là gì? (2 đáp án)
A) Time facet: linear vs. iterative (tuyến tính vs. lặp lại)
B) Budget facet: tight vs. large (ngân sách hạn hẹp vs. dồi dào)
C) Purpose facet: prescriptive vs. explorative (quy định sẵn vs. khám phá)
D) Methodology facet: structure-based vs. process-based
E) Interaction facet: team-driven vs. individual-driven
Xem đáp án & giải thích
Đáp án: A và C
Theo IREB, hai chiều chính để cấu hình quy trình RE là:
- A = Đúng: Time facet (linear vs. iterative) — xác định liệu yêu cầu được thu thập toàn bộ một lần hay được tinh chỉnh qua nhiều vòng lặp.
- C = Đúng: Purpose facet (prescriptive vs. explorative) — xác định liệu yêu cầu đã được biết trước (phạm vi rõ ràng) hay cần khám phá/phát hiện dần (scope mờ).
- B, D, E không phải các chiều cấu hình RE chính thức theo IREB.
Câu 37 — A 1 điểm EO 5.3.1
Dựa trên phân tích các yếu tố ảnh hưởng, cần cấu hình một sự kết hợp phù hợp của các process facets. Trong thực tế, một số kết hợp cụ thể thường xuất hiện. Kết hợp nào sau đây KHÔNG được công nhận như vậy? (1 đáp án)
A) Product-oriented RE process (iterative, explorative, market oriented)
B) Human-oriented RE process (linear, process-based, individual)
C) Participatory RE process (iterative, explorative, customer specific)
D) Contractual RE process (linear, prescriptive, customer specific)
Xem đáp án & giải thích
Đáp án: B
"Human-oriented RE process" không phải là một cấu hình quy trình RE được IREB công nhận. Ba cấu hình điển hình theo IREB là: - Contractual RE (tuyến tính, quy định sẵn, theo hợp đồng khách hàng) - Product-oriented RE (lặp lại, khám phá, hướng thị trường) - Participatory RE (lặp lại, khám phá, theo khách hàng cụ thể)
Chương 6 — Thực hành Quản lý Yêu cầu (10 điểm)
Câu 38 — K 2 điểm EO 6.5.3
Với các phát biểu sau về views (góc nhìn) đối với yêu cầu, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Không phải mọi stakeholder đều cần có quyền truy cập vào TẤT CẢ các yêu cầu. | ||
| B) Các yêu cầu liên quan đến nhau có thể được nhóm lại để hỗ trợ việc review. | ||
| C) Các yêu cầu có thể được ẩn khỏi những stakeholders không có quyền truy cập. | ||
| D) Việc dùng views đảm bảo rằng nhiều người có thể làm việc trên cùng một specification cùng lúc. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A, B, C = Đúng: Đây là ba mục đích chính của views — phân quyền, nhóm logic và ẩn thông tin nhạy cảm.
- D = Sai: ⚠️ Khả năng nhiều người làm việc đồng thời trên cùng một tài liệu là tính năng của version control và locking mechanism, không phải của views. Views không đảm bảo (assure) điều này.
Câu 39 — A 1 điểm EO 6.6.1
Traceability (khả năng truy xuất nguồn gốc) của yêu cầu có nhiều mục tiêu. Phát biểu nào sau đây KHÔNG đúng? (1 đáp án)
A) Traceability hỗ trợ phân tích tác động (impact analysis).
B) Traceability hỗ trợ xác minh việc triển khai (verification of implementation).
C) Traceability hỗ trợ xuất dữ liệu (exports) từ công cụ quản lý yêu cầu.
D) Traceability hỗ trợ tìm kiếm nguồn gốc của một yêu cầu.
Xem đáp án & giải thích
Đáp án: C
Xuất dữ liệu (export) là tính năng của công cụ (tool capability), không phải mục tiêu của traceability. Traceability là một khái niệm về mối quan hệ và kết nối giữa các artifact — mục tiêu của nó là: phân tích tác động khi thay đổi (A), xác minh rằng tất cả yêu cầu đã được triển khai (B), và truy xuất nguồn gốc yêu cầu đến từ đâu (D).
Câu 40 — K 2 điểm EO 6.5.2
Thông tin bổ sung về yêu cầu được quản lý bằng attributes. Một ví dụ là unique identifier (định danh duy nhất). Với các phát biểu sau, hãy xác định Đúng hay Sai. Unique identifiers hữu ích...
| Đúng | Sai | |
|---|---|---|
| A) ...để ước tính tổng quy mô (overall size) của một đặc tả. | ||
| B) ...để có cơ sở giao tiếp không mơ hồ (unambiguous communication). | ||
| C) ...để thiết lập các tham chiếu đến các yêu cầu khác. | ||
| D) ...để thiết lập traceability đến các development artifacts khác. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Sai: Ước tính quy mô đặc tả không phải mục đích của unique identifiers — đó là tác dụng phụ, không phải lý do tồn tại.
- B = Đúng: Có ID duy nhất → thay vì nói "yêu cầu về thời gian phản hồi", mọi người nói "REQ-042" → không nhầm lẫn.
- C = Đúng: ID cho phép một yêu cầu tham chiếu ("liên kết đến") yêu cầu khác một cách chính xác.
- D = Đúng: ID là cơ sở của traceability matrix — liên kết yêu cầu đến test cases, code, design artifacts.
Câu 41 — P 2 điểm EO 6.4.1
Bạn đã tạo ra một requirements baseline và bàn giao cho development. Trong thời gian đó, stakeholders đã gửi change requests cho các yêu cầu trong baseline này. Hai phương án nào sau đây đại diện cho change management đúng đắn? (2 đáp án)
A) Các thay đổi cho yêu cầu trong baseline được thực hiện bằng cách tạo version mới của yêu cầu trong baseline hiện tại.
B) Trước khi điều chỉnh yêu cầu theo change requests, phải xác định tác động của các thay đổi.
C) Change requests có thể được gửi bất kỳ lúc nào và có thể được xem xét cho development khi tạo baseline tương lai.
D) Change requests khẩn cấp không được phân tích hay ước tính mà được chuyển thẳng cho development.
E) Nếu development cho yêu cầu bị thay đổi chưa bắt đầu, thay đổi có thể được xử lý mà không cần tạo baseline mới.
Xem đáp án & giải thích
Đáp án: B và C
- B = Đúng: Trước bất kỳ thay đổi nào, impact analysis là bắt buộc — thay đổi một yêu cầu có thể kéo theo nhiều hệ quả cho các yêu cầu khác, test cases, thiết kế.
- C = Đúng: Change management không ngăn cản việc nhận change requests — chúng có thể được thu thập và đưa vào baseline tiếp theo một cách có kiểm soát.
- A Sai: Thay đổi trong một baseline đã được release phải được tạo thành baseline mới, không phải version mới trong baseline cũ.
- D Sai: Không có change request nào được phép bỏ qua phân tích và ước tính, kể cả khẩn cấp.
- E Sai: Dù development chưa bắt đầu, baseline đã được release vẫn cần một baseline mới nếu có thay đổi.
Câu 42 — K 2 điểm EO 6.8.1
Các attributes được dùng để quản lý các đặc tính bổ sung của yêu cầu. Priority (ưu tiên) là một ví dụ. Với các phát biểu sau về lý do ưu tiên hóa (prioritizing) yêu cầu, hãy xác định Đúng hay Sai. Một lý do để ưu tiên hóa là...
| Đúng | Sai | |
|---|---|---|
| A) ...để quyết định yêu cầu nào sẽ được triển khai trong release tiếp theo. | ||
| B) ...để quyết định nên tập trung kiểm thử những yêu cầu nào trước. | ||
| C) ...để tài liệu hóa chi phí triển khai một yêu cầu tốn bao nhiêu. | ||
| D) ...để nhận ra những yêu cầu nào có thể tái sử dụng. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Đúng: Đây là mục đích chính — phân bổ nguồn lực phát triển có hạn vào các yêu cầu quan trọng nhất trước.
- B = Đúng: Ưu tiên giúp tập trung kiểm thử vào các chức năng có giá trị cao hoặc rủi ro cao trước.
- C = Sai: Tài liệu hóa chi phí triển khai là nhiệm vụ của cost estimation, không phải của prioritization.
- D = Sai: Nhận ra yêu cầu tái sử dụng là mục tiêu của requirements reuse management, không phải prioritization.
Câu 43 — A 1 điểm EO 6.4.1
Version management và configuration management được dùng để quản lý yêu cầu. "Version" và "baseline" là hai thuật ngữ thường gặp. Mô tả nào SAU ĐÂY phù hợp nhất cho một baseline? (1 đáp án)
A) Một version của một yêu cầu
B) Một released configuration của một yêu cầu riêng lẻ
C) Một released configuration của các yêu cầu (tập hợp)
D) Một version chưa được release của một requirements specification
Xem đáp án & giải thích
Đáp án: C
Baseline là một tập hợp yêu cầu đã được phê duyệt và release tại một thời điểm nhất định — không phải một yêu cầu đơn lẻ (A, B), và không phải bản chưa release (D). Baseline đại diện cho một "snapshot" đã được đồng thuận của toàn bộ requirements specification, dùng làm cơ sở tham chiếu cho các hoạt động tiếp theo (development, testing, change management).
Chương 7 — Hỗ trợ của Công cụ (3 điểm)
Câu 44 — K 2 điểm EO 7.2.1
Với tư cách là Kỹ sư Yêu cầu, bạn phải chọn một công cụ hỗ trợ quy trình RE. Với các phát biểu sau, hãy xác định Đúng hay Sai.
| Đúng | Sai | |
|---|---|---|
| A) Công cụ phải hỗ trợ các artifact được yêu cầu trong quy trình RE đang áp dụng. | ||
| B) Việc chọn công cụ nên được để cho người dùng trực tiếp của công cụ quyết định. | ||
| C) Công cụ phải hỗ trợ người dùng thiết lập test cases như một phần của quy trình RE (shift-left testing). | ||
| D) Việc chọn công cụ bị ảnh hưởng bởi tool chain (ví dụ: công cụ configuration management) mà công cụ này phải hoạt động cùng. |
Xem đáp án & giải thích
| Đúng | Sai | |
|---|---|---|
| A) | ✅ | |
| B) | ✅ | |
| C) | ✅ | |
| D) | ✅ |
Giải thích:
- A = Đúng: Công cụ phải phù hợp với quy trình — nếu quy trình dùng use cases, công cụ phải hỗ trợ use cases.
- B = Sai: Quyết định chọn công cụ là quyết định tổ chức, liên quan đến nhiều bên (IT, quản lý, RE team) — không thể chỉ để người dùng cuối quyết định đơn phương.
- C = Sai: Hỗ trợ thiết lập test cases (shift-left testing) không phải là yêu cầu bắt buộc cho mọi công cụ RE — phụ thuộc vào quy trình của từng tổ chức.
- D = Đúng: Công cụ RE phải tích hợp được với các công cụ khác trong hệ sinh thái (configuration management, CI/CD, project management).
Câu 45 — A 1 điểm EO 7.1.2
Nhiệm vụ nào sau đây KHÔNG phải là khả năng của một công cụ hỗ trợ QUẢN LÝ yêu cầu (requirements management tool) trong quy trình RE? (1 đáp án)
A) Tracking logical relationships between requirements (Theo dõi mối quan hệ logic giữa các yêu cầu)
B) Modelling of requirements (Mô hình hóa yêu cầu)
C) Measuring and reporting of the Requirements Engineering process (Đo lường và báo cáo quy trình RE)
D) Providing support for the prioritization of requirements (Hỗ trợ ưu tiên hóa yêu cầu)
Xem đáp án & giải thích
Đáp án: B
Câu hỏi hỏi về công cụ quản lý yêu cầu (requirements management tool) — không phải công cụ RE nói chung. Công cụ quản lý yêu cầu tập trung vào: tracking, versioning, tracing, prioritizing và reporting. Modelling (tạo sơ đồ, biểu đồ UML/BPMN) là tính năng của modelling tools (công cụ mô hình hóa riêng biệt), không phải chức năng cốt lõi của requirements management tools.
⚠️ Bẫy: Một số công cụ hiện đại tích hợp cả hai — nhưng theo IREB, modelling không phải là capability định nghĩa của RM tools.
📊 Bảng tổng hợp kết quả
| Hạng mục | Chi tiết |
|---|---|
| Tổng điểm tối đa | 70 điểm |
| Điểm đậu tối thiểu | 49 điểm (70%) |
| Số câu K (True/False) | 15 câu × 2 điểm = 30 điểm |
| Số câu A (1 đáp án) | 17 câu × 1–2 điểm = 19 điểm |
| Số câu P (nhiều đáp án) | 13 câu × 1–2 điểm = 21 điểm |
Đánh giá điểm số của bạn
Sau khi làm xong tất cả 45 câu, hãy tổng hợp điểm theo thang dưới đây:
| Điểm | Nhận xét |
|---|---|
| ≥ 63 điểm (90%) | Xuất sắc — sẵn sàng thi thật |
| 56–62 điểm (80–89%) | Tốt — cần củng cố thêm 1–2 chương yếu |
| 49–55 điểm (70–79%) | Đủ điều kiện đậu — nên ôn thêm để đảm bảo |
| < 49 điểm (< 70%) | Cần học lại — tập trung vào các chương có câu sai nhiều |
Nguồn gốc đề thi
Đề thi thử này được dịch và số hóa từ: IREB Practice Exam — Questionnaire Set_Public_EN_3.3.2 (Syllabus CPRE Foundation Level 3.3.0). Đáp án được xác minh từ Answers to the Practice Exam EN và CorrectionAidForThePracticeExam EN (Excel). Bản quyền thuộc về IREB e.V. — được phép sử dụng cho mục đích đào tạo khi ghi rõ nguồn.