Kết quả cuối cùng của giai đoạn xác định và phân tích yêu cầu là:

Trong phân tích yêu cầu, chúng ta sử dụng nhiều sơ đồ khác nhau để mô tả và hiểu rõ hơn về hệ thống cần xây dựng. Các sơ đồ phổ biến bao gồm:

• Use Case Diagram (Sơ đồ Use Case): Mô tả tương tác giữa người dùng (actors) và hệ thống, xác định các chức năng chính mà hệ thống cung cấp.
• Activity Diagram (Sơ đồ hoạt động): Mô tả luồng công việc hoặc quy trình nghiệp vụ, thể hiện các hoạt động và quyết định.
• State Transition Diagram (Sơ đồ chuyển trạng thái): Mô tả các trạng thái của một đối tượng và các chuyển đổi giữa các trạng thái đó.

Tuy nhiên, Entity Relationship Diagram (ERD - Sơ đồ quan hệ thực thể) thường được sử dụng trong giai đoạn thiết kế cơ sở dữ liệu hơn là phân tích yêu cầu. ERD mô tả các thực thể (entities), thuộc tính (attributes) và mối quan hệ (relationships) giữa các thực thể này. Mặc dù thông tin về các thực thể và mối quan hệ có thể xuất hiện trong quá trình phân tích yêu cầu, việc xây dựng ERD chi tiết thường diễn ra sau khi các yêu cầu chức năng và phi chức năng đã được xác định rõ ràng.

Do đó, sơ đồ Entity Relationship Diagram (ERD) không phải là sơ đồ cần thiết trong giai đoạn phân tích yêu cầu so với các sơ đồ còn lại.

Phân tích yêu cầu thường bao gồm 4 giai đoạn chính:

1. Thu thập yêu cầu: Giai đoạn này liên quan đến việc thu thập thông tin về nhu cầu của người dùng và các bên liên quan. Các kỹ thuật được sử dụng bao gồm phỏng vấn, khảo sát, thảo luận nhóm, và phân tích tài liệu.

2. Phân tích yêu cầu: Giai đoạn này liên quan đến việc phân tích các yêu cầu đã thu thập được để xác định các yêu cầu xung đột, không rõ ràng hoặc không đầy đủ. Các kỹ thuật được sử dụng bao gồm mô hình hóa dữ liệu, mô hình hóa quy trình và phân tích nghiệp vụ.

3. Đặc tả yêu cầu: Giai đoạn này liên quan đến việc ghi lại các yêu cầu một cách rõ ràng, chính xác và đầy đủ. Các yêu cầu có thể được ghi lại bằng văn bản, sơ đồ hoặc mô hình.

4. Xác nhận yêu cầu: Giai đoạn này liên quan đến việc xác nhận rằng các yêu cầu đã ghi lại đáp ứng nhu cầu của người dùng và các bên liên quan. Các kỹ thuật được sử dụng bao gồm xem xét yêu cầu, thử nghiệm và mô phỏng.

Vì vậy, đáp án chính xác là 4.

Mật độ lỗi (defect density) là một chỉ số phần mềm đo lường số lượng lỗi trên một đơn vị kích thước của phần mềm (ví dụ: số lỗi trên 1000 dòng code - KLOC). Nó được sử dụng để đánh giá chất lượng của quá trình sản xuất phần mềm. Nếu mật độ lỗi cao, điều đó có nghĩa là quá trình sản xuất có nhiều vấn đề và cần được cải thiện. Các lựa chọn khác không phù hợp vì:

• Chất lượng sản phẩm cuối: Mật độ lỗi chỉ là một trong nhiều yếu tố ảnh hưởng đến chất lượng sản phẩm cuối cùng.
• Dự án phần mềm: Mật độ lỗi không đo lường toàn bộ dự án mà tập trung vào chất lượng code.
• Chất lượng bảo trì: Mật độ lỗi có thể ảnh hưởng đến chất lượng bảo trì, nhưng không phải là thước đo trực tiếp cho chất lượng bảo trì.

Kỹ thuật Facilitated Workshops (Hội thảo có người điều phối) là phương pháp thu thập yêu cầu mà trong đó, các bên liên quan cùng tham gia vào một buổi hội thảo được điều phối bởi một người trung gian. Mục tiêu là đạt được sự đồng thuận của tất cả các bên về các yêu cầu của dự án. Các phương án còn lại không tập trung vào sự nhất trí của số đông:

• Prototype (Mẫu thử): Tạo ra một phiên bản thử nghiệm của sản phẩm để thu thập phản hồi, nhưng không nhất thiết đòi hỏi sự đồng thuận của tất cả các bên.
• Observation (Quan sát): Quan sát người dùng sử dụng sản phẩm hoặc thực hiện công việc để thu thập yêu cầu, nhưng không liên quan đến việc đạt được sự đồng thuận.
• Questionnaires & Surveys (Bảng hỏi & Khảo sát): Thu thập thông tin từ một số lượng lớn người dùng thông qua bảng hỏi, nhưng không đảm bảo sự nhất trí giữa các câu trả lời.

Phần mềm có những đặc trưng khác biệt so với các sản phẩm vật lý. Đáp án đúng là 'Không hỏng đi, thoái hóa theo thời gian' vì:

• Không hỏng đi: Phần mềm không bị hao mòn vật lý như các thiết bị, máy móc. Nó có thể được sử dụng nhiều lần mà không bị giảm chất lượng.
• Thoái hóa theo thời gian: Mặc dù không hỏng về mặt vật lý, phần mềm có thể trở nên lỗi thời hoặc không còn phù hợp do sự thay đổi của công nghệ, yêu cầu người dùng, hoặc sự xuất hiện của các phần mềm mới tốt hơn. Đây chính là sự 'thoái hóa' của phần mềm.

Các đáp án khác không chính xác vì:

• Đơn giản, dễ hiểu, hữu hình: Phần mềm không phải lúc nào cũng đơn giản và dễ hiểu, đặc biệt là các phần mềm phức tạp. Tính hữu hình cũng không phải là đặc trưng của phần mềm (vô hình).
• Hao mòn, được chế tạo theo nghĩa cổ điển: Phần mềm không hao mòn và không được 'chế tạo' theo nghĩa cổ điển như các sản phẩm vật lý.
• Được lắp ráp từ mẫu có sẵn: Mặc dù có thể sử dụng các thư viện hoặc thành phần có sẵn, nhưng phần mềm thường được phát triển, xây dựng, và tùy chỉnh chứ không chỉ đơn thuần là lắp ráp từ mẫu có sẵn.