OOP B3

Use case giúp trả lời câu hỏi nào liên quan đến hệ thống?

• Hệ thống sẽ được triển khai như thế nào?

• Người dùng của hệ thống đang cố gắng làm gì và trải nghiệm người dùng ra sao?

• Cách hệ thống lưu trữ dữ liệu trong cơ sở dữ liệu.

• Sự phân bổ nguồn lực phát triển trong dự án.

Yêu cầu chức năng (functional requirements) thường là gì?

• Một tài liệu đầy đủ chi tiết về thiết kế hệ thống.

• Một tập hợp các yêu cầu cao và thấp cấp từ nhiều nguồn, thường được ghi lại liên tiếp trong một tài liệu Word.

• Một sơ đồ thể hiện các đối tượng trong hệ thống.

• Một mô hình các trường hợp sử dụng của hệ thống.

Vai trò của use case trong việc bổ sung cho yêu cầu chức năng là gì?

• Để thay thế hoàn toàn tài liệu yêu cầu chức năng.

• Để cung cấp một phương pháp có cấu trúc giúp ghi lại các yêu cầu hành vi, hỗ trợ quá trình thiết kế.

• Để xác định các trường hợp thử nghiệm phần mềm.

• Để lập danh sách các lỗi tiềm ẩn trong hệ thống.

Tại sao không nên thiết kế, lập trình, hoặc ước tính trực tiếp từ tài liệu yêu cầu chức năng (functional specification)?

• Vì tài liệu yêu cầu chức năng thường có nhiều lỗi.

• Vì thiết kế trực tiếp từ tài liệu yêu cầu chức năng giống như chơi trò "chọn số ngẫu nhiên", cần có thêm bước khám phá để làm rõ yêu cầu.

• Vì tài liệu yêu cầu chức năng không liên quan đến quá trình thiết kế phần mềm.

• Vì tài liệu yêu cầu chức năng chỉ dành cho nhóm quản lý.

Điều gì làm cho yêu cầu chức năng (functional requirements) trở thành bước đầu tiên trong quá trình thu thập yêu cầu?

• Vì yêu cầu chức năng cung cấp một bản thiết kế chi tiết của hệ thống

• Vì yêu cầu chức năng là tập hợp các yêu cầu ban đầu từ các bên liên quan, giúp xác định các yêu cầu hành vi cần làm rõ hơn.

• Vì yêu cầu chức năng thay thế hoàn toàn các trường hợp sử dụng.

• Vì yêu cầu chức năng chỉ bao gồm các yêu cầu kỹ thuật.

Trong ngữ cảnh của use case, "rainy-day scenario" là gì?

• Một kịch bản mô tả cách người dùng sử dụng hệ thống trong điều kiện lý tưởng.

• Một kịch bản mô tả cách hệ thống hoạt động trong các tình huống không mong muốn hoặc khi người dùng sử dụng các tính năng ít phổ biến.

• Một kịch bản mô tả các tính năng hiệu năng của hệ thống.

• Một kịch bản mô tả giao diện người dùng.

Khi xây dựng use case, việc tổ chức use case với các tác nhân (actors) có mục đích gì?

• Để tối ưu hóa mã nguồn

• Để làm rõ vai trò của từng người dùng và chức năng tương ứng họ thực hiện

• Để phân tích mô hình dữ liệu

• Để đảm bảo tính toàn vẹn của hệ thống

Tại sao việc viết use case theo cấu trúc "noun-verb-noun" lại quan trọng?

• Để dễ dàng mô hình hóa cơ sở dữ liệu

• Để tạo ra một thiết kế hướng đối tượng dễ dàng từ use case

• Để tạo sơ đồ lớp

• Để viết mã nguồn trực tiếp

Khi hệ thống gặp lỗi trong quá trình kiểm thử và không thực hiện đúng theo use case, bước tiếp theo là gì?

• Xây dựng lại hệ thống từ đầu

• Chỉnh sửa mã nguồn để phản ánh đúng hành vi trong use case

• Thay đổi yêu cầu ban đầu

• Tạo thêm các sơ đồ trạng thái

Khi phát hiện một đối tượng không được mô tả trong use case nhưng có liên quan đến hệ thống, bạn sẽ làm gì?

• Bỏ qua đối tượng này

• Thêm đối tượng vào use case và mô hình miền

• Chỉ thay đổi mô hình miền

• Xóa bỏ đối tượng