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

Mô hình phát triển phần mềm dựa trên mẫu thử (prototype) được sử dụng khi yêu cầu của khách hàng chưa rõ ràng hoặc chưa đầy đủ. Trong trường hợp này, việc xây dựng một mẫu thử giúp khách hàng hình dung được sản phẩm cuối cùng và đưa ra các phản hồi, từ đó giúp nhà phát triển hiểu rõ hơn về yêu cầu và điều chỉnh sản phẩm cho phù hợp. Các lựa chọn khác không mô tả đúng mục đích sử dụng của mô hình prototype.

Mô hình phát triển phần mềm tuần tự tuyến tính (hay còn gọi là mô hình thác nước) là một mô hình cổ điển, trong đó các giai đoạn phát triển phần mềm được thực hiện một cách tuần tự, từ phân tích yêu cầu, thiết kế, cài đặt, kiểm thử và triển khai.

• Phương án 1: Đúng một phần. Mô hình này là cũ và ít được sử dụng trong các dự án phức tạp, thay vào đó là các mô hình linh hoạt hơn.
• Phương án 2: Sai. Mô hình tuần tự tuyến tính không phù hợp cho các nhóm phát triển lớn vì nó thiếu sự linh hoạt và khó khăn trong việc phối hợp.
• Phương án 3: Đúng. Mô hình này phù hợp nhất khi các yêu cầu được xác định rõ ràng và không có nhiều thay đổi trong suốt quá trình phát triển. Khi yêu cầu không rõ ràng, việc quay lại các giai đoạn trước để sửa đổi sẽ rất khó khăn và tốn kém.
• Phương án 4: Sai. Mô hình tuần tự tuyến tính không phải là cách nhanh nhất để tạo một chương trình thực thi. Các mô hình phát triển nhanh (Rapid Application Development - RAD) hoặc Agile sẽ phù hợp hơn cho mục tiêu này.

Do đó, phương án hợp lý nhất là phương án 3.

Độ lớn (Volume) trong phân tích yêu cầu dùng để chỉ số lượng dữ liệu phát sinh hoặc số lượng các nghiệp vụ mà hệ thống phải xử lý trong một khoảng thời gian nhất định. Do đó, đáp án chính xác nhất là "Là số lượng dữ liệu phát sinh trong một chu kỳ nào đó". Các đáp án khác liên quan đến số lượng máy tính, người dùng, hoặc nghiệp vụ (không kèm theo chu kỳ) không phản ánh đầy đủ ý nghĩa của "Volume" trong ngữ cảnh này.

Nguyên lý đặc tả yêu cầu phần mềm bao gồm 7 nguyên lý:

1. Tách biệt các mối quan tâm: Yêu cầu nên được tổ chức sao cho các vấn đề khác nhau được giải quyết riêng biệt, giúp dễ dàng hiểu, quản lý và thay đổi.
2. Mức độ trừu tượng thích hợp: Yêu cầu nên được viết ở mức độ trừu tượng phù hợp với đối tượng mục tiêu, tránh chi tiết quá sớm hoặc quá mức cần thiết.
3. Hình thức hóa: Sử dụng các ký hiệu và công cụ hình thức hóa để làm rõ và xác minh tính nhất quán của các yêu cầu.
4. Lặp lại: Đặc tả yêu cầu là một quá trình lặp đi lặp lại, liên tục được tinh chỉnh và cải tiến dựa trên phản hồi và hiểu biết mới.
5. Quản lý thay đổi: Thiết lập quy trình để quản lý các thay đổi đối với yêu cầu một cách có kiểm soát.
6. Tính truy vết: Đảm bảo rằng có thể truy vết nguồn gốc của mỗi yêu cầu, cũng như tác động của nó đối với các phần khác của hệ thống.
7. Kiểm tra tính nhất quán: Đảm bảo rằng các yêu cầu không mâu thuẫn với nhau và phù hợp với các ràng buộc của hệ thống.

Độ đo mức độ bảo trì thường được đánh giá bằng các chỉ số liên quan đến hiệu quả và chất lượng của công tác bảo trì. Trong các lựa chọn được đưa ra:

• Phương án 1: Số vấn đề giải quyết trong tháng / tổng số vấn đề phát sinh trong tháng: Thể hiện khả năng giải quyết vấn đề bảo trì một cách nhanh chóng và hiệu quả. Tỷ lệ này cao cho thấy hệ thống bảo trì hoạt động tốt, xử lý kịp thời các sự cố.
• Phương án 2: Số lần bảo trì vượt quá tiêu chuẩn thời gian / tổng số lần bảo trì: Cho thấy mức độ tuân thủ thời gian bảo trì đã đặt ra. Tỷ lệ này thấp thể hiện quy trình bảo trì được thực hiện đúng thời gian, tránh ảnh hưởng đến hoạt động.
• Phương án 3: Số lần bảo trì sai sót / tổng số lần bảo trì: Thể hiện chất lượng của công tác bảo trì. Tỷ lệ này thấp cho thấy kỹ năng và quy trình bảo trì tốt, giảm thiểu sai sót.
• Phương án 4: Thời gian trung bình của một lần bảo trì: Cho thấy hiệu quả của quy trình bảo trì. Thời gian trung bình ngắn thể hiện quy trình tối ưu, giảm thời gian chết của hệ thống.

Như vậy, cả 4 phương án đều có thể được sử dụng để đo lường mức độ bảo trì, tuy nhiên phương án 1 phản ánh trực tiếp nhất hiệu quả giải quyết vấn đề, thể hiện khả năng ứng phó với các sự cố phát sinh.