Yêu cầu nào là yêu cầu chức năng?

Tài liệu SRS (Software Requirements Specification) mô tả đầy đủ các yêu cầu chức năng và phi chức năng của một hệ thống phần mềm. Người chịu trách nhiệm chính trong việc viết tài liệu này thường là phân tích viên (analyst). Phân tích viên có vai trò thu thập, phân tích và mô tả các yêu cầu từ khách hàng và các bên liên quan, sau đó chuyển chúng thành một tài liệu SRS chi tiết và dễ hiểu.

• Người quản lý dự án (project manager) có vai trò quản lý dự án, lập kế hoạch, phân công công việc và theo dõi tiến độ, nhưng không trực tiếp viết SRS.
• Lập trình viên (programmer) có vai trò viết mã chương trình dựa trên tài liệu SRS.
• Khách hàng (customer) cung cấp yêu cầu, nhưng không viết tài liệu SRS.

Phân tích yêu cầu phần mềm bao gồm các tác vụ như mô hình hóa và thừa nhận vấn đề, đặc tả và xem xét, định giá và tổng hợp. Lập kế hoạch và lịch biểu là các hoạt động thuộc về quản lý dự án, không phải là một phần của phân tích yêu cầu phần mềm.

Do đó, đáp án C là đáp án đúng.

Mục đích của việc xây dựng mô hình phân tích bao gồm: mô tả yêu cầu của khách hàng, phát triển một giải pháp tóm tắt cho vấn đề và thiết lập một nền tảng cho thiết kế phần mềm. Việc xác định một tập những yêu cầu phần mềm là một phần của quá trình phân tích yêu cầu, nhưng không phải là mục đích chính của việc xây dựng mô hình phân tích. Mô hình phân tích giúp hiểu rõ hơn về bài toán, yêu cầu và các ràng buộc, từ đó đưa ra giải pháp phù hợp.

Thiết kế phần mềm tốt đảm bảo chất lượng tổng thể của sản phẩm phần mềm. Chất lượng bao gồm nhiều yếu tố như độ tin cậy, tính bảo trì, hiệu suất, tính dễ sử dụng, v.v. Các lựa chọn khác như Accuracy (độ chính xác), Complexity (độ phức tạp), Efficiency (hiệu quả) chỉ là những khía cạnh riêng lẻ của chất lượng phần mềm chứ không bao quát được toàn bộ ý nghĩa của việc thiết kế phần mềm. Do đó, 'Quality' (chất lượng) là từ đơn thích hợp nhất để tóm tắt tầm quan trọng của thiết kế phần mềm.

Câu hỏi này liên quan đến các khái niệm trong thiết kế hệ thống và biểu đồ luồng dữ liệu. Cụ thể, nó hỏi về ý nghĩa của luồng tổng thể (transaction flow) trong một đoạn biểu đồ luồng dữ liệu có tính trình tự cao và theo đường thẳng.

• Luồng giao dịch (transaction flow): Luồng giao dịch xảy ra khi một luồng dữ liệu tổng thể được chia thành nhiều đường dẫn khác nhau, mỗi đường dẫn xử lý một loại giao dịch cụ thể. Trong trường hợp này, luồng dữ liệu có tính trình tự cao và đi theo đường thẳng, điều này không phù hợp với định nghĩa của luồng giao dịch.
• Luồng biến đổi (transform flow): Luồng biến đổi xảy ra khi dữ liệu được biến đổi qua một chuỗi các bước xử lý liên tiếp. Tính trình tự cao và đường thẳng trong biểu đồ luồng dữ liệu cho thấy một quá trình biến đổi tuần tự rõ ràng. Do đó, đây là đáp án phù hợp nhất.
• Liên kết thấp (low coupling): Liên kết thấp đề cập đến mức độ phụ thuộc giữa các module. Mặc dù luồng biến đổi có thể có liên kết thấp, nhưng câu hỏi tập trung vào bản chất của luồng dữ liệu, không phải mức độ liên kết.
• Module hóa tốt (good modularity): Module hóa tốt là một đặc điểm thiết kế quan trọng, nhưng nó không trực tiếp mô tả luồng dữ liệu trong trường hợp này.

Vì vậy, đáp án đúng nhất là D. Luồng biến đổi (transform) vì nó mô tả chính xác tình huống luồng dữ liệu được mô tả trong câu hỏi.