Trong ngữ cảnh của phân tích yêu cầu, hai loại phân tách vấn đề là

Câu hỏi yêu cầu tìm ra mục không phải là đặc trưng chung trong các phương pháp thiết kế. Các phương pháp thiết kế thường bao gồm quản lý cấu hình, sử dụng các ký hiệu để mô tả các thành phần chức năng và các nguyên tắc để đánh giá chất lượng thiết kế. Heuristic tinh chế là một kỹ thuật cụ thể được sử dụng trong một số phương pháp thiết kế, nhưng nó không phải là một đặc trưng chung cho tất cả các phương pháp thiết kế. Do đó, đáp án D là đáp án phù hợp nhất.

Mục đích của việc tham chiếu chéo các yêu cầu (thường được thể hiện dưới dạng ma trận truy vết yêu cầu - Requirements Traceability Matrix) trong tài liệu thiết kế là để đảm bảo rằng tất cả các yêu cầu đã được xác định và ghi lại đều được xem xét và đáp ứng đầy đủ trong quá trình thiết kế. Điều này giúp xác minh rằng không có yêu cầu nào bị bỏ sót và thiết kế cuối cùng thực sự đáp ứng nhu cầu của người dùng và các bên liên quan. Các lựa chọn khác không phải là mục đích chính của việc tham chiếu chéo yêu cầu.

Phân tích câu hỏi:
Câu hỏi này liên quan đến việc chuyển đổi hoặc ánh xạ giao dịch (transaction) thành một thiết kế kiến trúc đầy đủ trong phát triển phần mềm. Chúng ta cần xác định yếu tố bổ sung nào là cần thiết nhất để đạt được mục tiêu này.

Đánh giá các phương án:
* A. Sơ đồ quan hệ - thực thể (Entity-Relationship Diagram - ERD): ERD mô tả cấu trúc dữ liệu, các thực thể và mối quan hệ giữa chúng. Đây là một phần quan trọng của thiết kế kiến trúc, đặc biệt khi liên quan đến dữ liệu.
* B. Từ điển dữ liệu (Data Dictionary): Từ điển dữ liệu chứa thông tin chi tiết về các yếu tố dữ liệu, chẳng hạn như kiểu dữ liệu, kích thước, ràng buộc. Nó bổ sung cho ERD và cung cấp cái nhìn sâu sắc hơn về dữ liệu.
* C. Mô tả việc xử lý cho mỗi module: Điều này đề cập đến logic nghiệp vụ và cách các module tương tác với nhau để xử lý các giao dịch. Đây là yếu tố quan trọng để hoàn thiện thiết kế kiến trúc, đặc biệt là phần xử lý.
* D. Những Test-case cho mỗi module: Test-case dùng để kiểm tra chức năng của module, không trực tiếp tham gia vào việc tạo ra thiết kế kiến trúc.

Giải thích đáp án đúng:
Trong các lựa chọn trên, "Mô tả việc xử lý cho mỗi module" là yếu tố cần thiết nhất để hoàn thiện thiết kế kiến trúc từ các giao dịch. Việc ánh xạ giao dịch không chỉ liên quan đến dữ liệu mà còn cả logic xử lý. ERD và từ điển dữ liệu tập trung vào khía cạnh dữ liệu, còn test-case chỉ là công cụ kiểm tra. Mô tả việc xử lý cho mỗi module sẽ giúp xác định cách các giao dịch được thực hiện, luồng dữ liệu và sự tương tác giữa các thành phần, từ đó tạo ra một thiết kế kiến trúc đầy đủ.

Mô hình hình ảnh hệ thống (C) tập trung vào việc thể hiện giao diện người dùng một cách trực quan, bao gồm cả "look and feel" (diện mạo và cảm giác) và các thông tin hỗ trợ khác giúp người dùng tương tác dễ dàng hơn với hệ thống. Các mô hình khác không trực tiếp đề cập đến khía cạnh giao diện người dùng và trải nghiệm người dùng một cách cụ thể như mô hình hình ảnh hệ thống.

Bảng quyết định (Decision Table) là một công cụ được sử dụng để mô tả logic nghiệp vụ phức tạp, đặc biệt khi có nhiều điều kiện và hành động liên quan. Nó giúp làm rõ các trường hợp khác nhau và các hành động tương ứng cần thực hiện.

Phương án A: "Để tư liệu tất cả những trạng thái phụ thuộc" - Mặc dù bảng quyết định có thể giúp tư liệu các trạng thái phụ thuộc, nhưng đây không phải là mục đích chính và duy nhất của nó.

Phương án B: "Để hướng dẫn phát triển kế hoạch quản lý dự án" - Bảng quyết định không trực tiếp hướng dẫn phát triển kế hoạch quản lý dự án. Nó tập trung vào logic nghiệp vụ cụ thể.

Phương án C: "Chỉ khi xây dựng hệ chuyên gia" - Bảng quyết định không chỉ giới hạn trong việc xây dựng hệ chuyên gia. Nó có thể được sử dụng rộng rãi trong nhiều lĩnh vực khác.

Phương án D: "Khi một tập phức tạp những điều kiện và hoạt động xuất hiện trong thành phần" - Đây là đáp án chính xác nhất. Bảng quyết định đặc biệt hữu ích khi phải đối mặt với các tình huống phức tạp, trong đó có nhiều điều kiện và hoạt động cần được xem xét và kết hợp để đưa ra quyết định.