Trắc nghiệm Công nghệ Phần mềm Bài: PHA XÁC ĐỊNH YÊU CẦU CỔ ĐIỂN là một trong những đề thi thuộc Chương 6: PHA XÁC ĐỊNH YÊU CẦU trong học phần Công nghệ Phần mềm chuyên ngành Công Nghệ Thông Tin cấp độ Đại học. Đây là phần kiến thức quan trọng, tập trung vào cách tiếp cận truyền thống trong việc xác định yêu cầu – một quy trình tuần tự, chi tiết và cố định, đóng vai trò nền tảng cho các giai đoạn phát triển phần mềm tiếp theo.
Trong bài học này, người học cần nắm vững các nội dung cốt lõi như: đặc điểm của pha xác định yêu cầu cổ điển (như trong mô hình Thác nước), tầm quan trọng của việc thu thập và đặc tả yêu cầu đầy đủ ngay từ đầu, các công cụ và kỹ thuật được sử dụng, cũng như những ưu điểm và nhược điểm cố hữu của phương pháp này. Việc hiểu rõ pha yêu cầu cổ điển sẽ giúp sinh viên nhận thức được bối cảnh lịch sử và sự tiến hóa của các phương pháp xác định yêu cầu trong Công nghệ Phần mềm.
Hãy cùng Dethitracnghiem.vn tìm hiểu về đề thi này và tham gia làm kiểm tra ngay lập tức!
Trắc nghiệm Công nghệ Phần mềm Bài: PHA XÁC ĐỊNH YÊU CẦU CỔ ĐIỂN
Câu 1.Trong Pha Xác định Yêu cầu Cổ điển (Traditional Requirements Phase), hoạt động nào là trọng tâm?
A. Xây dựng mã nguồn.
B. Kiểm thử chức năng.
C. Triển khai sản phẩm.
D. Thu thập và đặc tả yêu cầu một cách toàn diện và chi tiết.
Câu 2.Mô hình vòng đời phần mềm nào là điển hình cho việc áp dụng Pha Xác định Yêu cầu Cổ điển?
A. Mô hình Agile.
B. Mô hình Xoắn ốc.
C. Mô hình Lặp và Tăng.
D. Mô hình Thác nước (Waterfall Model).
Câu 3.Đặc điểm chính của yêu cầu trong Pha Xác định Yêu cầu Cổ điển là gì?
A. Liên tục thay đổi và phát triển.
B. Luôn mơ hồ và không rõ ràng.
C. Không cần tài liệu hóa.
D. Cần được cố định và ổn định trước khi chuyển sang các pha tiếp theo.
Câu 4.Kết quả đầu ra quan trọng nhất của Pha Xác định Yêu cầu Cổ điển là gì?
A. Mã nguồn đã hoàn thiện.
B. Bản mẫu thử nghiệm.
C. Báo cáo kiểm thử.
D. Tài liệu Đặc tả Yêu cầu Phần mềm (Software Requirements Specification – SRS) đầy đủ.
Câu 5.Tại sao Pha Xác định Yêu cầu Cổ điển lại nhấn mạnh vào việc thu thập yêu cầu đầy đủ ngay từ đầu?
A. Để làm cho dự án phức tạp hơn.
B. Để giảm chi phí bảo trì.
C. Để tăng tốc độ viết mã.
D. Vì các pha tiếp theo (thiết kế, cài đặt) phụ thuộc chặt chẽ vào độ chính xác và đầy đủ của yêu cầu này.
Câu 6.Một nhược điểm lớn của Pha Xác định Yêu cầu Cổ điển là gì?
A. Khó thu thập yêu cầu ban đầu.
B. Làm cho quá trình phát triển linh hoạt hơn.
C. Giảm rủi ro dự án.
D. Khó khăn trong việc xử lý các yêu cầu thay đổi sau khi pha đã hoàn thành.
Câu 7.Trong Pha Xác định Yêu cầu Cổ điển, sự tương tác với khách hàng thường diễn ra như thế nào sau giai đoạn thu thập ban đầu?
A. Rất thường xuyên và liên tục.
B. Qua các bản mẫu thường xuyên.
C. Chỉ khi có lỗi nghiêm trọng.
D. Hạn chế, chủ yếu chỉ để xác nhận các tài liệu đã được hoàn thành.
Câu 8.Ưu điểm của Pha Xác định Yêu cầu Cổ điển là gì, đặc biệt trong các dự án có tính ổn định cao?
A. Giảm sự cần thiết của tài liệu.
B. Khuyến khích sự thay đổi liên tục.
C. Tăng tốc độ phát triển.
D. Cung cấp sự kiểm soát và khả năng dự đoán tốt hơn cho các dự án với yêu cầu ổn định.
Câu 9.Một yêu cầu được coi là “không mơ hồ” (unambiguous) trong Pha Xác định Yêu cầu Cổ điển nghĩa là gì?
A. Nó có thể được hiểu theo nhiều cách khác nhau.
B. Nó không cần phải được người khác đọc.
C. Nó phải được viết bằng tiếng Anh.
D. Mỗi câu lệnh trong đặc tả chỉ có thể được diễn giải theo một cách duy nhất.
Câu 10.Nếu một lỗi do yêu cầu bị hiểu sai được phát hiện ở giai đoạn cài đặt trong một dự án sử dụng Pha Xác định Yêu cầu Cổ điển, chi phí sửa chữa sẽ như thế nào?
A. Thấp hơn so với pha yêu cầu.
B. Bằng nhau.
C. Không liên quan.
D. Cao hơn đáng kể (theo cấp số nhân) so với việc phát hiện sớm.
Câu 11.Tài liệu SRS trong Pha Xác định Yêu cầu Cổ điển thường chứa đựng những loại yêu cầu nào?
A. Chỉ yêu cầu phi chức năng.
B. Chỉ yêu cầu về hiệu suất.
C. Chỉ yêu cầu về giao diện người dùng.
D. Cả yêu cầu chức năng và phi chức năng một cách chi tiết.
Câu 12.Phát biểu nào sau đây **đúng** về Pha Xác định Yêu cầu Cổ điển?
A. Nó linh hoạt với sự thay đổi của thị trường.
B. Nó khuyến khích phát hành sản phẩm sớm.
C. Nó là phương pháp tối ưu cho mọi loại dự án.
D. Nó đòi hỏi sự tài liệu hóa kỹ lưỡng và chính xác.
Câu 13.Vấn đề “Big-bang Integration” (Tích hợp Big Bang) thường là một hậu quả của mô hình nào khi áp dụng Pha Xác định Yêu cầu Cổ điển?
A. Mô hình Agile.
B. Mô hình Bản mẫu nhanh.
C. Mô hình Xoắn ốc.
D. Mô hình Thác nước (do tích hợp tất cả các module ở cuối dự án).
Câu 14.Trong Pha Xác định Yêu cầu Cổ điển, việc xác định các “trường hợp sử dụng” (Use Cases) có vai trò gì?
A. Để thiết kế cơ sở dữ liệu.
B. Để viết code.
C. Để kiểm thử hiệu suất.
D. Để mô tả các chức năng của hệ thống từ góc nhìn của người dùng.
Câu 15.Tại sao Pha Xác định Yêu cầu Cổ điển lại ít phù hợp với các dự án có yêu cầu không ổn định hoặc đổi mới liên tục?
A. Vì nó quá nhanh.
B. Vì nó không có tài liệu.
C. Vì nó quá rẻ.
D. Vì sự cứng nhắc và chi phí cao khi phải thay đổi yêu cầu đã được cố định.
Câu 16.Để đảm bảo tính “có thể truy vết” (Traceability) trong Pha Xác định Yêu cầu Cổ điển, điều gì là cần thiết?
A. Không cần phải liên kết các yêu cầu.
B. Chỉ liên kết yêu cầu với mã nguồn.
C. Chỉ liên kết yêu cầu với người dùng.
D. Thiết lập mối liên kết rõ ràng giữa yêu cầu với các phần tử thiết kế, mã nguồn và trường hợp kiểm thử.
Câu 17.Hoạt động “Thẩm định yêu cầu” (Requirements Validation) trong Pha Xác định Yêu cầu Cổ điển có ý nghĩa gì?
A. Để tìm kiếm lỗi cú pháp.
B. Để thay đổi yêu cầu.
C. Để thêm yêu cầu mới.
D. Để kiểm tra và xác nhận rằng các yêu cầu đã được tài liệu hóa phản ánh đúng nhu cầu thực tế của khách hàng.
Câu 18.Khái niệm “Đường cơ sở yêu cầu” (Requirements Baseline) có ý nghĩa gì trong Pha Xác định Yêu cầu Cổ điển?
A. Yêu cầu có thể thay đổi bất cứ lúc nào.
B. Yêu cầu chỉ dành cho giai đoạn đầu.
C. Yêu cầu chỉ dành cho người lập trình.
D. Tập hợp các yêu cầu đã được phê duyệt và không được thay đổi nếu không có quy trình quản lý thay đổi chính thức.
Câu 19.Trong Pha Xác định Yêu cầu Cổ điển, việc sử dụng các biểu đồ như Biểu đồ Luồng Dữ liệu (DFD) hoặc Biểu đồ Thực thể-Mối quan hệ (ERD) nhằm mục đích gì?
A. Để làm cho dự án tốn kém hơn.
B. Để tạo ra bản mẫu.
C. Để viết mã nguồn.
D. Để phân tích và mô hình hóa cấu trúc dữ liệu và luồng xử lý của hệ thống.
Câu 20.Ai là người chịu trách nhiệm chính trong việc phê duyệt cuối cùng các tài liệu yêu cầu trong Pha Xác định Yêu cầu Cổ điển?
A. Lập trình viên.
B. Người kiểm thử.
C. Quản lý dự án.
D. Khách hàng hoặc đại diện khách hàng.
Câu 21.Vấn đề “thiếu linh hoạt” (lack of flexibility) của Pha Xác định Yêu cầu Cổ điển có thể dẫn đến điều gì nếu yêu cầu kinh doanh thay đổi đột ngột?
A. Dự án sẽ hoàn thành nhanh hơn.
B. Chất lượng sản phẩm sẽ cao hơn.
C. Chi phí dự án sẽ giảm.
D. Gây ra sự chậm trễ lớn, vượt ngân sách và có thể làm cho sản phẩm trở nên không phù hợp.
Câu 22.Một yêu cầu được coi là “đầy đủ” (complete) trong Pha Xác định Yêu cầu Cổ điển nếu:
A. Nó có ít dòng code nhất.
B. Nó được viết bằng ngôn ngữ đơn giản.
C. Nó không chứa bất kỳ lỗi nào.
D. Nó mô tả tất cả các chức năng, thuộc tính và ràng buộc cần thiết mà hệ thống phải có.
Câu 23.Pha Xác định Yêu cầu Cổ điển thường được áp dụng cho các dự án có tính chất nào?
A. Công nghệ mới, chưa xác định.
B. Yêu cầu thay đổi thường xuyên.
C. Dự án nhỏ, thử nghiệm.
D. Yêu cầu rõ ràng, ổn định, và đã được xác định trước.
Câu 24.Tầm quan trọng của việc “Review” (Đánh giá) tài liệu yêu cầu trong Pha Xác định Yêu cầu Cổ điển là gì?
A. Để tìm lỗi cú pháp.
B. Để làm cho tài liệu dài hơn.
C. Để chứng minh đã hoàn thành công việc.
D. Phát hiện sớm các lỗi, mâu thuẫn hoặc sự mơ hồ trong yêu cầu trước khi chúng được đưa vào thiết kế và cài đặt.
Câu 25.Khi một dự án phần mềm sử dụng Pha Xác định Yêu cầu Cổ điển, sự “chậm trễ trong phản hồi” từ khách hàng có thể gây ra vấn đề gì?
A. Tăng tốc độ phát triển.
B. Giảm chi phí.
C. Làm cho dự án an toàn hơn.
D. Kéo dài thời gian của pha yêu cầu, hoặc gây ra hiểu lầm nếu quyết định được đưa ra mà không có phản hồi kịp thời.
