SWR302 Software Requirements – Bộ ôn tập thi lại số 5 (60 câu)

Trong quá trình phát triển yêu cầu, có năm bước cơ bản: thu thập thông tin (elicitation), thiết kế (design), phân tích (analysis), xác minh (validation) và tạo tài liệu (documentation). Tuy nhiên, tạo tài liệu (documentation) không phải là một bước phát triển yêu cầu riêng biệt mà là một phần của quá trình phát triển yêu cầu. Nó là một bước sau khi đã thu thập thông tin, thiết kế và phân tích yêu cầu. Vì vậy, trong số các lựa chọn trên, tạo tài liệu (documentation) không phải là một bước phát triển yêu cầu độc lập.

Khách hàng có quyền được doanh nghiệp hiểu rõ về hoạt động kinh doanh và mục tiêu của họ. Họ cũng có quyền mô tả các đặc điểm sẽ giúp sản phẩm dễ sử dụng hơn. Ngoài ra, khách hàng có quyền nhận được một hệ thống đáp ứng được nhu cầu chức năng và tiêu chuẩn chất lượng của họ. Điều này giúp đảm bảo rằng hệ thống được thiết kế phù hợp với nhu cầu và mong muốn của khách hàng.

Dưới đây là câu trả lời cho câu hỏi: 'Đâu là điều không được bao gồm trong danh sách Yêu cầu về Hóa đơn Phần mềm?'. Các lựa chọn có sẵn là: - 'Chờ BAs nói ngôn ngữ của bạn.' - 'Chờ BAs tìm hiểu về doanh nghiệp và mục tiêu của bạn.' - 'Thông báo ngay các thay đổi về yêu cầu.' - 'Nhận giải thích về thực hành và sản phẩm yêu cầu.' - 'Thay đổi yêu cầu của bạn.' - 'Chờ một môi trường tôn trọng lẫn nhau.' Câu trả lời đúng là: 'Thay đổi yêu cầu của bạn.' Vì trong danh sách Yêu cầu về Hóa đơn Phần mềm, không có yêu cầu nào nói về việc thay đổi yêu cầu của người dùng. Các yêu cầu khác đều liên quan đến việc giao tiếp, học hỏi và tôn trọng lẫn nhau.

Một nhà phân tích kinh doanh có nhiều nhiệm vụ quan trọng trong quá trình phát triển dự án. Đầu tiên, họ phải xác định các yêu cầu kinh doanh của dự án, hiểu rõ về mục tiêu và yêu cầu của khách hàng. Sau đó, họ phải xác định các bên liên quan và lớp người dùng của dự án, bao gồm cả các bên có thể ảnh hưởng đến dự án. Cuối cùng, họ phải dẫn dắt quá trình ưu tiên yêu cầu, đảm bảo rằng các yêu cầu quan trọng nhất được ưu tiên thực hiện trước.

Vision và Scope Document là một tài liệu quan trọng trong quá trình phát triển dự án, nó được sử dụng để định nghĩa mục tiêu, phạm vi và yêu cầu của dự án. Vision Document thường được xây dựng dựa trên các yêu cầu kinh doanh, nó giúp xác định mục tiêu và hướng đi của dự án. Scope Document thì lại tập trung vào việc xác định phạm vi của dự án, bao gồm các yêu cầu và hạn chế của dự án. Vì vậy, Vision và Scope Document được coi là một phần quan trọng của quá trình phát triển dự án và được xây dựng dựa trên các yêu cầu kinh doanh.

Xác định các bên liên quan (stakeholders) là một bước quan trọng khi thu thập yêu cầu cho một hệ thống phần mềm. Điều này giúp bạn hiểu rõ ai đang tham gia vào dự án, ai sẽ bị ảnh hưởng bởi kết quả dự án và ai có thể ảnh hưởng đến kết quả dự án. Việc xác định các bên liên quan giúp bạn có thể thu thập yêu cầu chính xác và đầy đủ, từ đó đảm bảo rằng hệ thống phần mềm đáp ứng được nhu cầu và kỳ vọng của các bên liên quan. Ngoài ra, việc xác định các bên liên quan cũng giúp bạn có thể dự đoán và giải quyết các vấn đề có thể xảy ra trong quá trình thực hiện dự án.

Để tạo ra một tài liệu Vision và Scope hiệu quả, cần bao gồm các yếu tố sau đây. Trước hết, cần phải xác định rõ **Scope và Limitations** (Khái quát và Giới hạn) để hiểu rõ về phạm vi và giới hạn của dự án. Tiếp theo, cần phải xác định **Specific Requirements** (Yêu cầu cụ thể) để hiểu rõ về các yêu cầu cụ thể của dự án. Cuối cùng, cần phải xác định **Business Context** (Bối cảnh kinh doanh) để hiểu rõ về bối cảnh kinh doanh của dự án. Những yếu tố này sẽ giúp tạo ra một tài liệu Vision và Scope rõ ràng, cụ thể và hiệu quả.

Để viết được câu hỏi điều tra hiệu quả, cần bắt đầu bằng việc hỏi những câu hỏi mở (open-ended questions) ngay từ đầu. Những câu hỏi này cho phép người tham gia trả lời một cách tự do và chi tiết, giúp thu thập được thông tin đầy đủ và có ý nghĩa. Câu hỏi mở thường bắt đầu bằng từ như 'Bạn nghĩ gì về', 'Bạn cảm thấy thế nào khi', 'Bạn nghĩ rằng', v.v. Điều này giúp người tham gia có thể thể hiện quan điểm và ý kiến của mình một cách tự nhiên và chân thực. Ngoài ra, câu hỏi mở cũng giúp nhà điều tra có thể thu thập được thông tin sâu sắc và chi tiết hơn, giúp cho việc phân tích và tổng hợp dữ liệu trở nên dễ dàng hơn.

Elicitation là một quá trình hợp tác và phân tích bao gồm các hoạt động để thu thập, khám phá, trích xuất và thu thập yêu cầu. Quá trình này nhằm mục đích thu thập thông tin cần thiết từ khách hàng hoặc người sử dụng để xác định các yêu cầu của hệ thống hoặc sản phẩm. Elicitation thường bao gồm các hoạt động như thu thập yêu cầu, xác định yêu cầu và phân tích yêu cầu. Trong quá trình này, người tham gia sẽ thảo luận và chia sẻ ý tưởng để thu thập thông tin cần thiết. Quá trình này rất quan trọng vì nó giúp đảm bảo rằng các yêu cầu được thu thập chính xác và đầy đủ.

Một Use Case Diagram là một loại hình ảnh được sử dụng trong thiết kế phần mềm để mô tả các trường hợp sử dụng của một hệ thống. Mục đích chính của Use Case Diagram là để mô tả các hành vi của hệ thống và các tương tác giữa hệ thống và người dùng. Chúng thường được sử dụng để xác định các yêu cầu của hệ thống và để phân tích các yêu cầu này. Use Case Diagram không phải là để mô tả giao diện người dùng đồ họa (GUI) mà cần được thực hiện. Thay vào đó, chúng mô tả các hành vi của hệ thống và các tương tác giữa hệ thống và người dùng. Điều này có nghĩa là Use Case Diagram không thể được sử dụng để mô tả giao diện người dùng đồ họa mà cần được thực hiện. Vì vậy, đáp án "Use case diagrams show the graphical user interface that needs to be implemented" là không đúng.

Các Use Case mô tả các tương tác giữa hệ thống và các thực thể bên ngoài. Điều này có nghĩa là chúng mô tả các hành động mà người dùng thực hiện với hệ thống và hệ thống phản hồi lại như thế nào. Điều này giúp cho các nhà phát triển hiểu rõ hơn về yêu cầu của người dùng và có thể xây dựng được hệ thống đáp ứng được nhu cầu của họ. Ngoài ra, các Use Case cũng giúp cho việc xác định các yêu cầu chức năng của hệ thống trở nên dễ dàng hơn. Vì vậy, các Use Case là công cụ quan trọng trong việc thu thập và xác định các yêu cầu của hệ thống.

Sự khác biệt giữa Use Cases và User Stories là gì? Use Cases là một tài liệu kinh doanh xác định yêu cầu phần mềm hoặc tính năng ứng dụng. Trong khi đó, User Stories là một tài liệu kiểm thử xác định các bước để xác minh và xác thực rằng yêu cầu phần mềm hoặc tính năng ứng dụng tồn tại. Use Cases thường được sử dụng để mô tả các yêu cầu kinh doanh và chức năng của ứng dụng, trong khi User Stories được sử dụng để mô tả các yêu cầu kiểm thử và xác thực. Ví dụ, một Use Case có thể mô tả cách một người dùng có thể tạo một tài khoản mới, trong khi một User Story có thể mô tả các bước để kiểm thử tính năng tạo tài khoản mới.

Khi viết SRS, việc ghi nhãn các yêu cầu là rất quan trọng. Điều này cho phép chúng ta tham khảo các yêu cầu cụ thể trong yêu cầu thay đổi, lịch sử sửa đổi, liên kết, hoặc ma trận theo dõi yêu cầu. Ngoài ra, việc ghi nhãn yêu cầu cũng giúp chúng ta tái sử dụng các yêu cầu trong nhiều dự án khác nhau. Điều này giúp tiết kiệm thời gian và công sức trong quá trình phát triển phần mềm. Hơn nữa, việc ghi nhãn yêu cầu cũng giúp cải thiện sự hợp tác giữa các thành viên trong nhóm khi họ thảo luận về các yêu cầu.

Mỗi lựa chọn đều đóng vai trò quan trọng trong mô tả chi tiết của Software Requirements Specification (SRS). Tuy nhiên, 'System feature' không phải là một phần quan trọng trong mô tả tổng quan của SRS. SRS thường bao gồm các phần như 'Product perspective' (khái quát về sản phẩm), 'User classes and characteristics' (khái quát về người dùng), 'Operating environment' (khái quát về môi trường hoạt động), 'Design and implementation constraints' (khái quát về hạn chế trong thiết kế và triển khai), 'Assumptions and dependencies' (khái quát về giả định và phụ thuộc). 'System feature' thường được sử dụng để mô tả các tính năng cụ thể của hệ thống, chứ không phải là mô tả tổng quan.

Các yêu cầu phải được thể hiện theo các dạng sau: Đầu tiên, chúng ta cần đảm bảo rằng yêu cầu có thể thực hiện được (Feasible). Điều này có nghĩa là yêu cầu phải có thể đạt được trong thực tế, không chỉ là một mục tiêu lý thuyết. Thứ hai, yêu cầu phải chính xác (Correct). Điều này có nghĩa là yêu cầu phải rõ ràng, không mơ hồ và không gây hiểu lầm. Cuối cùng, yêu cầu phải có thể kiểm tra được (Verifiable). Điều này có nghĩa là yêu cầu phải có thể đo lường được, có thể xác minh được và có thể đánh giá được. Tóm lại, yêu cầu phải được thể hiện một cách rõ ràng, chính xác và đo lường được để đảm bảo rằng chúng ta có thể đạt được mục tiêu một cách hiệu quả.