SRS là viết tắt của:

Yêu cầu chức năng mô tả những gì hệ thống cần phải làm. Chúng bao gồm các quy trình xử lý, dữ liệu được tổ chức như thế nào và các báo cáo đầu ra. Yêu cầu bảo mật lại thuộc loại yêu cầu phi chức năng, nó mô tả cách hệ thống thực hiện các chức năng đó một cách an toàn và đáng tin cậy. Do đó, "Bảo mật" không phải là một yêu cầu chức năng.

Giai đoạn xác định và phân tích yêu cầu (Requirements elicitation and analysis) nhằm mục đích thu thập, phân tích và đặc tả các yêu cầu của người dùng và các bên liên quan đối với hệ thống phần mềm. Kết quả cuối cùng của giai đoạn này là một tài liệu mô tả đầy đủ và chi tiết các yêu cầu, được gọi là Tài liệu đặc tả yêu cầu phần mềm (Software Requirements Specification - SRS). Tài liệu SRS này sẽ là cơ sở để thiết kế, phát triển và kiểm thử hệ thống.

Các sơ đồ DFD, Use case, ERD là các công cụ hỗ trợ trong quá trình phân tích yêu cầu, nhưng không phải là kết quả cuối cùng của giai đoạn này.

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ì.