40+ câu trắc nghiệm Phân tích yêu cầu phần mềm có đáp án - Phần 2

Phỏng vấn (closed interviews và open interviews)

Tìm kiếm các nhân sự

Tự quan sát quy trình nghiệp vụ

Các phương pháp trên đều đúng

Thu thập yêu cầu là công việc của cả nhà phát triển hệ thống và khách hàng.

Khi thu thập yêu cầu ta phải hiểu rõ về nghiệp vụ phần mềm, phạm vi của phần mềm và các thay đổi của hệ thống.

Khi thu thập yêu cầu phần mềm cần phát hiện ra được các yêu cầu phần mềm dựa trên nhiều phương pháp, thu hút được sự tham gia của nhiều chuyên gia, khách hàng để có thể có được các quan điểm xem xét phần mềm từ nhiều khía cạnh.

Cả ba đáp án trên đều đúng.

Khi làm việc với khách hàng để thu thập yêu cầu ta cần tổ chức các cuộc phỏng vấn đóng hoặc phỏng vấn mở.

Khi thu thập yêu cầu cần tìm kiếm các nhân sự như là các chuyên gia về các loại hệ thống cần xây dựng cho khách hàng, tìm kiếm những người cần sử dụng đến phần mềm này để phát hiện ra yêu cầu trong quy trình kỹ nghệ yêu cầu.

Khi thu thập yêu cầu cần nắm rõ trình tự nghiệp vụ của hệ thống.

Cả ba đáp án trên đều đúng.

Chúng ta có thể lặp lại nhiều lần quá trình phân tích và thu thập yêu cầu.

Khi phân tích và thu thập yêu cầu, chúng ta cần thương lượng và đàm phán với khách hàng để có được tính khả thi tốt nhất cho phần mềm.

Cần phân tích các rủi ro có thể xảy ra với các yêu cầu phần mềm để giải quyết tất cả các bất đồng về yêu cầu phần mềm dựa trên cơ sở thương lượng với khách.

Cả ba đáp án trên đều đúng.

Phân cấp các yêu cầu phần mềm dựa trên nhu cầu của khách hàng.

Phân loại các yêu cầu phần mềm và sắp xếp theo các nhóm liên quan.

Khảo sát từng yêu cầu trong mối quan hệ đến các yêu cầu khác.

Các đáp án trên đều đúng.

Phân tích các rủi ro có thể xảy ra với từng yêu cầu phần mềm.

Cần đánh giá thô về giá thành và thời gian thực hiện của từng yêu cầu phần mềm trong sản phẩm tổng thể.

Giải quyết các bất đồng với khách trên cơ sở thảo luận và thương lượng.

Các đáp án trên đều đúng.

Đặc tả vận hành chức năng

Đặc tả ràng buộc phi chức năng

Đặc tả các tính chất của hệ thống như: Độ tin cậy, thời gian trả lời, dung lượng bộ nhớ…

Tất cả các đáp án trên.

Biểu đồ Use Case

Biểu đồ phân rã chức năng

Câu chuyện người dùng (User Story)

Tất cả các đáp án trên

Biểu đồ lớp mức phân tích

Mô hình dữ liệu (Ví dụ biểu đồ ERD của Chen)

Biểu đồ giao tiếp

Tất cả các đáp án trên

Biểu đồ luồng quy trình nghiệp vụ (Ví dụ: BPMN)

Mô hình dữ liệu (Ví dụ biểu đồ ERD của Chen)

Biểu đồ máy trạng thái

Tất cả các đáp án trên

Thẩm định yêu cầu là việc nối tiếp việc phân tích yêu cầu vì nó tìm kiếm các vấn đề xảy ra với các yêu cầu.

Thẩm định yêu cầu là rất quan trọng vì nếu có lỗi trong bản đặc tả yêu cầu làm thay đổi hệ thống thường chi phí sửa lỗi cao hơn rất nhiều so với chi phí sửa lỗi thiết kế hay lỗi mã hóa.

Việc thẩm định yêu cầu là việc kiểm tra rằng các yêu cầu được xác định ra ở các bước trước có thực sự định nghĩa được hệ thống mà khách hàng cần.

Cả ba đáp án trên đều đúng.

Việc thẩm định yêu cầu là việc làm lại việc phân tích yêu cầu một lần nữa

Nếu không có thẩm định yêu cầu, lỗi về yêu cầu làm thay đổi hệ thống được phát hiện ra tại pha thiết kế hoặc mã hóa thường chi phí sửa thấp hơn nhiều so với chi phí chỉ sửa thiết kế hoặc sửa lỗi mã hóa.

Việc thẩm định yêu cầu là việc chứng tỏ rằng bản đặc tả yêu cầu là đúng với hệ thống khách hàng thực sự cần.

Vì chi phí sửa chữa yêu cầu phần mềm cao nên việc thẩm định rất quan trọng.

Xem xét lại yêu cầu, làm bản mẫu, tạo ca kiểm thử, sử dụng CASE.

Kiểm thử testcase cho từng nhóm yêu cầu, làm bản mẫu, sử dụng CASE

Đặt câu hỏi còn thiếu chức năng nào không? Có cài đặt được chức năng đó không? Có thể kiểm tra được tính đúng đắn không? Và chưa cần phải quan tâm đến mối tương quan giữa các chức năng.

Cả ba đáp án trên đều sai

Quản trị yêu cầu là quy trình quản trị sự thay đổi yêu cầu trong suốt quá trình công nghệ yêu cầu và phát triển hệ thống.

Quản trị yêu cầu chỉ để quản trị những lỗi tiềm tàng về yêu cầu phát sinh khi đã được đưa vào sử dụng.

Quản trị yêu cầu chỉ quản trị và duy trì mối quan hệ giữa các yêu cầu phụ thuộc nhau để có thể đánh giá được ảnh hưởng khi thay đổi yêu cầu.

Quản trị yêu cầu không cần theo dõi những yêu cầu đơn lẻ.

Quản trị yêu cầu quản trị cả quá trình cải tiến yêu cầu.

Cần cân nhắc trong việc thay đổi yêu cầu, nếu việc thay đổi yêu cầu làm thay đổi bản đặc tả yêu cầu và làm thay đổi cả việc thiết kế và thực thi hệ thống thì dừng lại bởi chi phí cho sự thay đổi là quá cao.

Trong quy tắc quản trị yêu cầu thì mỗi yêu cầu phải là duy nhất. Cần phải có chính sách xác định mối quan hệ giữa mỗi yêu cầu và giữa các yêu cầu.

Khi cân nhắc thay đổi yêu cầu cần đánh giá cả tác động và chi phí cho sự thay đổi.