WorksheetsCâu hỏi trắc nghiệm về đặc tả use case và đánh giá yêu cầu
Total questions: 26
Worksheet time: 13mins
Lợi ích của việc liên kết use case với mô hình miền là gì?
Đảm bảo rằng các mô tả use case phù hợp với các đối tượng trong miền
Giảm số lượng kịch bản cần thiết bằng cách bỏ qua ngoại lệ
Thay thế hoàn toàn tài liệu yêu cầu bằng sơ đồ lớp
Tự động sinh mã nguồn từ mô hình miền
Điều gì nên được sử dụng để bổ sung mô tả use case?
Các nguyên mẫu GUI hoặc bản phác thảo màn hình
Biểu đồ mạng nội bộ
Tài liệu kiểm thử hiệu năng
Báo cáo tài chính dự án
Một trong các bước đầu tiên khi đánh giá use case là gì?
Chuyển các yêu cầu chức năng vào use case
Bắt đầu viết mã giao diện người dùng ngay lập tức
Xóa các tình huống ngoại lệ để đơn giản hóa
Tập trung vào đo lường hiệu năng trước tiên
Lợi ích của việc sử dụng ngôn ngữ chủ động trong mô tả use case là gì?
Làm cho các yêu cầu rõ ràng hơn và dễ hiểu hơn
Giảm thời gian tài liệu bằng cách bỏ chi tiết
Tăng tính mơ hồ để dễ thay đổi sau này
Cho phép bỏ qua vai trò của người dùng
Làm thế nào để tránh tình trạng "intermangled" trong đặc tả use case?
Ghi lại các yêu cầu chức năng trong tài liệu riêng biệt
Trộn yêu cầu với thiết kế giao diện trong cùng một phần
Chỉ mô tả luồng chính và bỏ qua các yêu cầu khác
Thêm thuật ngữ kỹ thuật khó hiểu vào tài liệu
Tại sao cần có các "kịch bản thay thế" trong mỗi use case?
Để xử lý các tình huống đặc biệt hoặc lỗi tiềm ẩn trong hệ thống
Để rút ngắn tài liệu bằng cách bỏ qua ngoại lệ
Để thay thế hoàn toàn luồng chính
Để tập trung vào giao diện mà không xét hành vi hệ thống
Việc sử dụng giao diện người dùng (GUI) giúp cải thiện đặc tả use case như thế nào?
Làm rõ hành vi của người dùng và phản hồi của hệ thống
Loại bỏ nhu cầu mô tả hành động người dùng
Chỉ tập trung vào kiến trúc hệ thống
Giảm số lượng kịch bản cần xét
Tại sao việc viết use case theo ngôn ngữ chủ động lại quan trọng?
Giúp lập trình viên hiểu rõ hơn về cách triển khai yêu cầu
Giúp tài liệu dài hơn để đáp ứng tiêu chuẩn hình thức
C. Để giúp lập trình viên hiểu rõ hơn về cách triển khai yêu cầu
Tạo ra nhiều thuật ngữ chuyên môn hơn
Trong buổi đánh giá yêu cầu, tại sao cần tạo nguyên mẫu (prototype) cho giao diện người dùng?
Để xác minh rằng các yêu cầu được thể hiện đúng trong thiết kế giao diện
Để thay thế tài liệu yêu cầu bằng hình ảnh
Để tối ưu hiệu năng hệ thống
Để loại bỏ nhu cầu kiểm thử
Tại sao nên sử dụng các bước "Hành động của người dùng/Phản hồi của hệ thống" trong mô tả use case?
để Làm rõ cách hệ thống tương tác với người dùng, chia nhỏ quy trình thành các bước logic đối ứng
Giảm chi tiết tài liệu để dễ đọc
Chỉ tập trung vào phía hệ thống và bỏ qua người dùng
Thay thế luồng chính bằng sơ đồ
Tại sao việc đặt tên rõ ràng cho các đối tượng trong mô hình miền lại quan trọng?
để Đảm bảo rằng các lập trình viên hiểu rõ vai trò của từng đối tượng
Giúp bỏ qua yêu cầu chức năng
Tăng tính trừu tượng để tài liệu khó đọc hơn
Cho phép không cần liên kết với use case
Vai trò của việc tạo các nguyên mẫu giao diện (prototypes) trong buổi đánh giá yêu cầu là gì?
Để xác định các hành vi người dùng mà tài liệu chưa nêu rõ
Để thay thế quá trình kiểm thử tích hợp
Để đo lường hiệu năng cơ sở dữ liệu
Để giảm số lượng use case cần viết
Việc chuyển đổi từ giọng bị động sang giọng chủ động trong mô tả use case có tác dụng gì?
Làm cho văn bản rõ ràng hơn về các hành động của người dùng và hệ thống
Giúp tài liệu mơ hồ hơn để linh hoạt
Cho phép bỏ qua các bước tương tác
Tăng độ dài tài liệu mà không tăng độ rõ ràng
Bạn đang thực hiện đánh giá một use case, nhưng mô tả quá trừu tượng và khó hiểu. Bạn sẽ làm gì để cải thiện tài liệu?
Cụ thể hóa các hành động của người dùng và phản hồi của hệ thống bằng cách sử dụng giọng chủ động
Giữ nguyên mô tả để tránh thay đổi phạm vi
Bỏ qua các tình huống ngoại lệ để tài liệu ngắn hơn
Chuyển toàn bộ sang thuật ngữ kỹ thuật
Trong quá trình đánh giá, khách hàng phàn nàn rằng hệ thống không đáp ứng được yêu cầu của họ, mặc dù yêu cầu đã được phê duyệt trước đó. Bạn sẽ xử lý thế nào?
Thực hiện lại buổi đánh giá yêu cầu với khách hàng để tìm ra sự khác biệt và cập nhật tài liệu
Bỏ qua ý kiến khách hàng vì yêu cầu đã phê duyệt
Chuyển vấn đề sang nhóm vận hành mà không điều tra
Dừng dự án ngay lập tức
Ai cần tham gia vào buổi đánh giá yêu cầu?
Đại diện khách hàng, người dùng cuối, nhân viên marketing, và các bên liên quan khác
Chỉ nhóm phát triển phần mềm
Chỉ quản lý dự án
Chỉ nhóm kiểm thử
Điều gì sẽ xảy ra nếu các yêu cầu chức năng bị lẫn vào văn bản mô tả use case?
Gây nhầm lẫn khi phân tích và thiết kế
Giúp tài liệu ngắn gọn hơn
Tăng tính linh hoạt của yêu cầu
Không ảnh hưởng đến quá trình phát triển
Làm thế nào để tránh tình trạng "intermangled" trong đặc tả use case?
Ghi lại các yêu cầu chức năng trong tài liệu riêng biệt
Trộn yêu cầu với mô tả kịch bản để tiết kiệm thời gian
Chỉ mô tả luồng chính và bỏ qua ngoại lệ
Giảm số lượng use case bằng cách gộp yêu cầu
Khi mô tả các bước trong use case, tại sao cần liên kết các bước này với các đối tượng miền?
Để đảm bảo rằng mô hình miền hỗ trợ trực tiếp các yêu cầu của hệ thống
Để loại bỏ vai trò người dùng khỏi tài liệu
Để thay thế yêu cầu bằng kiến trúc phần mềm
Để tăng tính trừu tượng của tài liệu
Việc sử dụng giao diện người dùng (GUI) giúp cải thiện đặc tả use case như thế nào?
Làm rõ hành vi của người dùng và phản hồi của hệ thống
Loại bỏ nhu cầu phân tích nghiệp vụ
Tập trung vào cấu trúc cơ sở dữ liệu
Giảm số lượng kịch bản cần xét
Làm thế nào việc truy vết (traceability) các yêu cầu đến các use case giúp ích cho dự án?
Đảm bảo rằng mọi yêu cầu đều được thực hiện và kiểm tra
Cho phép bỏ qua kiểm thử hệ thống
Thay thế tài liệu thiết kế
Giảm nhu cầu giao tiếp với khách hàng
Vai trò của việc tạo các nguyên mẫu giao diện (prototypes) trong buổi đánh giá yêu cầu là gì?
Để xác định các hành vi người dùng mà tài liệu chưa nêu rõ
Để loại bỏ hoàn toàn mô tả use case
Để đo lường tải hệ thống
Để thay thế kế hoạch kiểm thử
Việc chuyển đổi từ giọng bị động sang giọng chủ động trong mô tả use case có tác dụng gì?
Làm cho văn bản rõ ràng hơn về các hành động của người dùng và hệ thống
Làm cho tài liệu dài hơn mà không rõ ràng
Cho phép bỏ qua phản hồi của hệ thống
Tăng tính mơ hồ của các bước
Tại sao cần tạo ra các kịch bản "trời mưa" (rainy-day scenarios) trong mỗi use case?
Để dự đoán và xử lý các lỗi hoặc trường hợp ngoại lệ có thể xảy ra
Để loại bỏ các ngoại lệ khỏi phạm vi dự án
Để thay thế kiểm thử hệ thống
Để làm tài liệu ngắn hơn
Bạn đang thực hiện đánh giá một use case, nhưng mô tả quá trừu tượng và khó hiểu. Bạn sẽ làm gì để cải thiện tài liệu?
Cụ thể hóa các hành động của người dùng và phản hồi của hệ thống bằng cách sử dụng giọng chủ động
Giữ nguyên mô tả để tránh thay đổi phạm vi
Bỏ qua các kịch bản thay thế
Thêm thuật ngữ kỹ thuật phức tạp
Khách hàng phàn nàn hệ thống không đáp ứng yêu cầu dù đã phê duyệt trước đó. Bạn xử lý thế nào?
Thực hiện lại buổi đánh giá yêu cầu với khách hàng để tìm ra sự khác biệt và cập nhật tài liệu
Bỏ qua vì yêu cầu đã phê duyệt
Đổ lỗi cho nhóm kiểm thử
Hoãn dự án vô thời hạn
