Quiz: SWR302_FA24_BL3W_FE - Có đáp án và giải thích chi tiết

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

Câu tuyên bố trên cho rằng tất cả màn hình trong hệ thống phải tải nhanh chóng. Để đánh giá tính chính xác và khả thi của tuyên bố này, chúng ta cần xem xét từng khía cạnh. Tính chính xác (correct) của tuyên bố này có thể được đánh giá là đúng vì nó xác định rõ yêu cầu về tốc độ tải màn hình. Tuy nhiên, tính khả thi (feasible) của tuyên bố này có thể không hoàn toàn đúng vì tốc độ tải màn hình phụ thuộc vào nhiều yếu tố như cấu hình hệ thống, dung lượng dữ liệu, và hiệu suất phần cứng. Vì vậy, tuyên bố này có thể được đánh giá là 'Correct và Feasible' nhưng với một số hạn chế.

Một mô hình phân tích được sử dụng để thể hiện các trạng thái khác nhau mà một hệ thống hoặc một đối tượng trong hệ thống có thể tồn tại, cũng như các chuyển đổi được phép giữa các trạng thái. Mô hình này giúp cho việc phân tích và thiết kế hệ thống trở nên dễ dàng hơn. Nó cho phép các nhà phát triển và nhà thiết kế xem xét các trạng thái khác nhau mà hệ thống có thể tồn tại và các chuyển đổi được phép giữa các trạng thái.

Một mô hình phân tích thể hiện luồng quy trình di chuyển từ một hoạt động sang hoạt động khác được gọi là sơ đồ luồng quy trình (Process Flow Diagram) hoặc sơ đồ hoạt động (Activity Diagram). Tuy nhiên, trong các lựa chọn đã cho, sơ đồ luồng quy trình không có, nhưng có một lựa chọn khác có thể phù hợp, đó là sơ đồ hoạt động (Activity Diagram). Sơ đồ hoạt động thể hiện các hoạt động và các luồng quy trình giữa chúng, giúp phân tích và mô hình hóa quy trình kinh doanh.

Một bảng điều khiển (dashboard) là một công cụ quan trọng trong việc theo dõi và phân tích dữ liệu. Nó cung cấp một cái nhìn tổng quan, đa chiều về tình hình của một tổ chức hoặc quy trình. Bảng điều khiển thường bao gồm nhiều biểu đồ, đồ thị và các hình thức khác nhau để thể hiện dữ liệu. Điều này giúp người dùng dễ dàng hiểu và phân tích dữ liệu, từ đó đưa ra quyết định sáng suốt. Bảng điều khiển có thể được sử dụng trên màn hình hoặc được in ra dưới dạng báo cáo.

Một mô hình dữ liệu là một hình ảnh trực quan thể hiện các đối tượng dữ liệu và các tập hợp dữ liệu mà hệ thống sẽ xử lý và mối quan hệ giữa chúng. Nó giúp xác định cấu trúc dữ liệu và cách dữ liệu được liên kết với nhau trong hệ thống. Mô hình dữ liệu thường được sử dụng trong thiết kế cơ sở dữ liệu và phát triển phần mềm để đảm bảo dữ liệu được tổ chức và quản lý một cách hiệu quả.

Tuyên bố trên đề cập đến tính chất chất lượng nào của hệ thống? Hệ thống cần phải có khả năng nhập bất kỳ cấu trúc hóa học hợp lệ nào từ công cụ ChemDraw phiên bản 13.0 hoặc trước đó và MarvinSketch phiên bản 5.0 hoặc trước đó. Điều này cho thấy hệ thống cần phải tương tác và tích hợp được với các công cụ khác nhau, không phụ thuộc vào phiên bản. Khả năng này được gọi là tính tương tác (Interoperability). Tính tương tác là khả năng của hệ thống để tương tác và tích hợp được với các hệ thống, ứng dụng hoặc thiết bị khác, đảm bảo rằng dữ liệu được trao đổi và sử dụng một cách chính xác và hiệu quả.

Tính chất chất lượng bên ngoài (external quality attribute) là những đặc điểm của một hệ thống hoặc phần mềm mà người dùng quan tâm. Các lựa chọn bên dưới đều là tính chất chất lượng bên ngoài, ngoại trừ một trong số đó. Tính sẵn có (Availability) là khả năng của hệ thống để sẵn sàng sử dụng khi người dùng cần. Tính toàn vẹn (Integrity) là khả năng của hệ thống để đảm bảo dữ liệu được cập nhật và lưu trữ chính xác. Tính an toàn (Safety) là khả năng của hệ thống để đảm bảo an toàn cho người dùng và hệ thống. Tính tái sử dụng (Reusability) là khả năng của hệ thống để được sử dụng lại trong nhiều dự án khác nhau. Tuy nhiên, tính tái sử dụng không phải là một tính chất chất lượng bên ngoài, mà là một tính chất chất lượng bên trong (internal quality attribute).

Throwaway prototype là một loại prototype được xây dựng để đáp ứng nhu cầu cụ thể trong một giai đoạn nhất định. Nó thường được sử dụng khi đội ngũ phát triển gặp phải sự không chắc chắn, mơ hồ, không đầy đủ hoặc không rõ ràng trong yêu cầu. Mục đích chính của một prototype như vậy là để trả lời các câu hỏi, giải quyết sự không chắc chắn và cải thiện chất lượng yêu cầu. Khi xây dựng một prototype như vậy, đội ngũ phát triển không cần phải tuân thủ các kỹ thuật xây dựng phần mềm nghiêm ngặt. Điều này cho phép họ tập trung vào việc giải quyết các vấn đề quan trọng và tạo ra một sản phẩm có thể đáp ứng nhu cầu của khách hàng. Tuy nhiên, nó không phải là một sản phẩm cuối cùng và có thể được loại bỏ sau khi hoàn thành.

Một mockup là một mô hình giả lập của hệ thống, thường được sử dụng trong quá trình thiết kế và phát triển phần mềm. Nó cho phép người dùng tương tác với hệ thống và đánh giá các tính năng và giao diện người dùng. Trong các lựa chọn trên, câu trả lời sai là 'nó đi sâu vào tất cả các lớp kiến trúc hoặc vào chi tiết chức năng'. Điều này không đúng vì mockup thường chỉ tập trung vào giao diện người dùng và các hành vi cơ bản của hệ thống, chứ không phải tất cả các lớp kiến trúc và chi tiết chức năng.

Khi bạn tạo bản mẫu toàn bộ giải pháp thay vì chỉ những phần có khả năng cao nhất, rủi ro cao nhất hoặc phức tạp nhất, bạn sẽ gặp phải một số vấn đề. Đầu tiên, bạn có thể đang đầu tư quá nhiều nỗ lực vào bản mẫu, điều này có thể dẫn đến lãng phí thời gian và nguồn lực. Thứ hai, bạn có thể bị phân tâm bởi những chi tiết nhỏ nhặt, điều này có thể khiến bạn mất tập trung vào mục tiêu chính. Cuối cùng, bạn có thể gặp áp lực phải phát hành bản mẫu sớm, điều này có thể dẫn đến việc bạn phải cắt giảm các tính năng quan trọng hoặc giảm chất lượng của bản mẫu. Ngoài ra, bạn cũng có thể tạo ra những kỳ vọng không thực tế về hiệu suất của bản mẫu, điều này có thể dẫn đến thất vọng khi bản mẫu không đạt được những kỳ vọng đó.

Kỹ thuật MoSCoW là một phương pháp được sử dụng để xác định ưu tiên các yêu cầu trong một dự án. Mỗi chữ cái viết hoa trong MoSCoW đại diện cho một mức độ ưu tiên khác nhau. M - Must (Phải có), S - Should (Nên có), C - Could (Có thể có), W - Won't (Không có). Vì vậy, đáp án đúng là "Must, Should, Could, Won't".

Câu hỏi này yêu cầu bạn xác định hoạt động không liên quan đến xác minh yêu cầu. Trong quá trình phát triển yêu cầu, có bốn thành phần chính: xác định yêu cầu, phân tích yêu cầu, xác minh yêu cầu và xác định yêu cầu. Xác minh yêu cầu là một hoạt động quan trọng để đảm bảo yêu cầu có tất cả các tính chất mong muốn của yêu cầu chất lượng cao. Nó cũng đảm bảo rằng yêu cầu đã được viết đúng và có liên quan đến mục tiêu kinh doanh. Tuy nhiên, câu trả lời không chính xác trong lựa chọn này là "Itis the fourth component of requirements development." vì nó chỉ là một phần của quá trình phát triển yêu cầu, không phải là hoạt động xác minh yêu cầu.

Một bản mẫu phần mềm là một bản dựng thử nghiệm của một sản phẩm mới. Nó thường được tạo ra để kiểm tra ý tưởng và xác định các yêu cầu của sản phẩm. Bản mẫu phần mềm có thể được xem là một phần thực hiện của sản phẩm mới, vì nó chỉ bao gồm một số tính năng hoặc chức năng của sản phẩm. Nó cũng có thể được xem là một bản dựng khả thi của sản phẩm mới, vì nó thể hiện một cách khả thi để triển khai sản phẩm. Ngoài ra, bản mẫu phần mềm cũng có thể được xem là một bản dựng sơ bộ của sản phẩm mới, vì nó thường được tạo ra trước khi sản phẩm được hoàn thiện. Tuy nhiên, bản mẫu phần mềm không phải lúc nào cũng là bản dựng hoàn chỉnh của sản phẩm mới.

Các yếu tố sau đây có thể ngăn cản việc tái sử dụng yêu cầu. Yêu cầu được viết bằng ngôn ngữ tự nhiên có thể chứa các sự không rõ ràng, thiếu thông tin và giả định ẩn. Điều này có thể dẫn đến việc khó khăn trong việc hiểu và thực hiện yêu cầu. Vì vậy, việc tái sử dụng yêu cầu sẽ gặp khó khăn khi yêu cầu không được viết rõ ràng và chính xác.

Extent of reuse là một khái niệm quan trọng trong thiết kế và phát triển phần mềm, đặc biệt là trong lĩnh vực tái sử dụng mã nguồn. Nó đề cập đến mức độ mà một yêu cầu chức năng hoặc một phần của yêu cầu chức năng có thể được tái sử dụng trên một dự án mới. Trong thực tế, tái sử dụng không chỉ giới hạn ở việc sao chép và dán một yêu cầu chức năng đơn lẻ mà còn bao gồm cả việc tái sử dụng các yêu cầu chức năng phức tạp hơn như các trường hợp sử dụng, yêu cầu hiệu suất, yêu cầu sử dụng người dùng và các quy tắc kinh doanh. Mức độ tái sử dụng có thể khác nhau tùy thuộc vào tính chất của yêu cầu chức năng và mức độ phức tạp của dự án.

Trong quá trình phát triển phần mềm, yêu cầu (requirements) đóng vai trò quan trọng. Chúng không chỉ ảnh hưởng đến kế hoạch dự án mà còn tác động trực tiếp đến quá trình thiết kế và viết mã nguồn. Yêu cầu cũng giúp xác định các hoạt động kiểm tra và thử nghiệm, đảm bảo rằng sản phẩm cuối cùng đáp ứng được các tiêu chuẩn và yêu cầu đã được đặt ra. Vì vậy, yêu cầu (requirements) là nền tảng quan trọng để xây dựng một sản phẩm phần mềm chất lượng cao.

Một dự án cải tiến (enhancement project) là một loại dự án trong đó các khả năng mới được thêm vào một hệ thống hiện có. Điều này có nghĩa là dự án cải tiến không thay thế hệ thống hiện có hoàn toàn, mà thay vào đó, nó bổ sung thêm các tính năng hoặc khả năng mới để cải thiện hiệu suất, tính năng hoặc trải nghiệm người dùng của hệ thống hiện có. Dự án cải tiến thường được thực hiện để đáp ứng nhu cầu mới của khách hàng, cải thiện hiệu suất hệ thống hoặc bổ sung thêm các tính năng mới để cạnh tranh với các đối thủ trong ngành. Ví dụ, một công ty có thể thực hiện dự án cải tiến để thêm tính năng mới vào hệ thống quản lý khách hàng của mình, chẳng hạn như khả năng theo dõi và phân tích dữ liệu khách hàng. Điều này sẽ giúp công ty có thể hiểu rõ hơn về nhu cầu và hành vi của khách hàng, từ đó có thể cung cấp dịch vụ tốt hơn và tăng cường mối quan hệ với khách hàng.

Trong phát triển agile, các câu chuyện người dùng (user stories) và các câu chuyện lớn (epics) là hai khái niệm quan trọng. Câu chuyện người dùng là những tuyên bố ngắn gọn và rõ ràng về nhu cầu của người dùng, giúp khởi đầu cho các cuộc thảo luận chi tiết. Các câu chuyện lớn, hoặc epics, là những câu chuyện người dùng quá lớn để được triển khai trong một chu kỳ phát triển (iteration) duy nhất. Vì vậy, chúng thường được chia nhỏ thành nhiều câu chuyện người dùng nhỏ hơn để dễ dàng triển khai.

Câu hỏi này yêu cầu bạn xác định thông tin không liên quan đến dự án được giao ngoài (outsourced projects). Các lựa chọn bao gồm: - Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. - Đó là khó khăn hơn để có được ý kiến của nhà phát triển về yêu cầu và để chuyển lại phản hồi của người dùng về phần mềm đã được giao cho nhà phát triển. - Cần có định nghĩa hợp đồng chính thức về yêu cầu, điều này có thể dẫn đến tranh chấp nếu sự khác biệt trong việc giải thích được phát hiện muộn trong dự án. Câu trả lời đúng là: Nó tận dụng kỹ năng phát triển có sẵn trong nội bộ. Vì dự án được giao ngoài thường không tận dụng kỹ năng phát triển có sẵn trong nội bộ mà thay vào đó là thuê ngoài để thực hiện.

Để xử lý một yêu cầu thay đổi, có bốn nhiệm vụ cần được thực hiện. Trước hết, chúng ta phải đánh giá yêu cầu thay đổi (evaluate change request). Tiếp theo, chúng ta phải đưa ra quyết định thay đổi (make change decision). Sau đó, chúng ta phải thực hiện thay đổi (implement the change). Cuối cùng, chúng ta phải kiểm tra lại thay đổi (verify the change) để đảm bảo rằng nó đã được thực hiện đúng cách và không có lỗi nào.

Change Control Board (CCB) là một nhóm người có trách nhiệm quyết định xem một thay đổi dự án có được chấp thuận hay không. Họ chịu trách nhiệm xem xét và đánh giá các đề xuất thay đổi, sau đó quyết định có chấp thuận hay không. CCB thường bao gồm các thành viên quan trọng như nhà quản lý dự án, nhà phát triển, người kiểm tra chất lượng và khách hàng. Mục tiêu của CCB là đảm bảo rằng các thay đổi được thực hiện một cách có trách nhiệm và không ảnh hưởng đến chất lượng dự án. Họ cũng đảm bảo rằng các thay đổi được thực hiện một cách hợp lý và không gây ra bất kỳ sự cố nào. Trong quá trình làm việc, CCB thường phải xem xét các yếu tố như tác động của thay đổi đến dự án, chi phí của thay đổi, thời gian thực hiện và khả năng thành công của thay đổi. Nếu CCB chấp thuận một thay đổi, họ sẽ tạo ra một bản ghi chép chi tiết về thay đổi đó, bao gồm lý do thay đổi, tác động của thay đổi và kế hoạch thực hiện. Điều này giúp đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về thay đổi và có thể thực hiện nó một cách hiệu quả.

Giải pháp yêu cầu theo dõi (requirements tracing) là một công cụ quan trọng trong quản lý dự án. Nó cho phép tạo liên kết giữa các nhiệm vụ trong kế hoạch dự án và tiến độ phát triển. Điều này giúp tăng cường theo dõi dự án, đảm bảo rằng các nhiệm vụ được thực hiện đúng theo kế hoạch. Ngoài ra, yêu cầu theo dõi còn giúp xác định các yêu cầu chưa được đáp ứng và cần phải bổ sung. Điều này giúp giảm thiểu chi phí phát triển và tăng cường chất lượng sản phẩm cuối cùng.

Một Requirements Traceability Matrix (RTM) là một công cụ quan trọng trong quá trình quản lý yêu cầu. Mục đích chính của RTM là theo dõi mối quan hệ giữa các yêu cầu và các tài liệu khác liên quan đến dự án. Điều này giúp đảm bảo rằng tất cả các yêu cầu đã được đáp ứng và các tài liệu khác đều phù hợp với yêu cầu. RTM cũng giúp xác định các yêu cầu nào đã được thực hiện và các yêu cầu nào vẫn còn chưa được thực hiện. Điều này giúp dự án được quản lý một cách hiệu quả và giảm thiểu các vấn đề phát sinh trong quá trình thực hiện.

Trong quản lý dự án, việc xác định và ưu tiên rủi ro là một phần quan trọng để đảm bảo dự án được thực hiện một cách hiệu quả và an toàn. Có nhiều phương pháp để xác định rủi ro, nhưng phương pháp phổ biến nhất là sử dụng phương pháp phân tích rủi ro (Risk Analysis). Phương pháp này bao gồm việc xác định, phân tích và ưu tiên rủi ro dựa trên mức độ nghiêm trọng và khả năng xảy ra của chúng. Để ưu tiên rủi ro, chúng ta cần xem xét cả khả năng xảy ra và tác động tiềm ẩn của rủi ro. Khả năng xảy ra của rủi ro được đo lường bằng mức độ xác suất xảy ra, trong khi tác động tiềm ẩn được đo lường bằng mức độ ảnh hưởng đến dự án. Bằng cách xem xét cả hai yếu tố này, chúng ta có thể xác định rủi ro nào cần được ưu tiên xử lý đầu tiên. Phương pháp này giúp đảm bảo rằng chúng ta tập trung vào những rủi ro có khả năng gây thiệt hại lớn nhất và có thể thực hiện các biện pháp phòng ngừa hoặc giảm thiểu rủi ro một cách hiệu quả.

Để quản lý rủi ro hiệu quả, cần phải hiểu rõ các yếu tố cơ bản của quá trình này. Trong đó, có ba yếu tố quan trọng là đánh giá rủi ro (Risk assessment), kiểm soát rủi ro (Risk control) và giảm thiểu rủi ro (Risk reduction). Đánh giá rủi ro giúp xác định mức độ nghiêm trọng của rủi ro, từ đó có thể đưa ra quyết định về cách thức xử lý. Kiểm soát rủi ro liên quan đến việc thực hiện các biện pháp để ngăn chặn hoặc giảm thiểu rủi ro. Giảm thiểu rủi ro là quá trình tìm kiếm các giải pháp để giảm thiểu tác động tiêu cực của rủi ro. Ba yếu tố này thường được sử dụng cùng nhau để tạo thành một hệ thống quản lý rủi ro toàn diện.

Mục tiêu chính của quản lý rủi ro trong các dự án phần mềm là xác định và đánh giá các mối đe dọa tiềm ẩn có thể ảnh hưởng đến dự án. Quá trình này giúp các nhà phát triển phần mềm nhận thức được những rủi ro tiềm ẩn và có thể chuẩn bị các biện pháp phòng ngừa hoặc giảm thiểu tác động của chúng. Bằng cách xác định các mối đe dọa tiềm ẩn, các nhà phát triển phần mềm có thể tạo ra các kế hoạch dự phòng và thực hiện các biện pháp để giảm thiểu rủi ro, từ đó đảm bảo dự án được thực hiện một cách hiệu quả và an toàn.

Trong các dự án Agile, một epic là một khái niệm quan trọng trong quản lý dự án. Nó được định nghĩa là một tập hợp các user story liên quan đến nhau, thường quá lớn để hoàn thành trong một chu kỳ phát triển (iteration) duy nhất. Điều này có nghĩa là epic có thể bao gồm nhiều user story khác nhau, và nó có thể được thực hiện trong nhiều chu kỳ phát triển khác nhau. Epic cũng có thể được coi là một trong những tính năng quan trọng nhất của dự án, vì nó thường liên quan đến các yêu cầu chính của khách hàng.

Trong Agile, Epic là một khái niệm quan trọng giúp định nghĩa mục tiêu và yêu cầu của dự án. Nó đại diện cho một nhu cầu của người dùng hoặc yêu cầu kinh doanh ở mức độ cao, có thể được chia nhỏ thành các câu chuyện người dùng (user stories) nhỏ hơn và dễ quản lý hơn. Ví dụ, một Epic có thể là 'Tăng cường trải nghiệm khách hàng' và được chia nhỏ thành các user stories như 'Tạo trang web mới', 'Tối ưu hóa quá trình thanh toán trực tuyến', v.v. Mục đích của Epic là giúp nhóm phát triển hiểu rõ yêu cầu và mục tiêu của dự án, từ đó có thể lập kế hoạch và triển khai các công việc cần thiết.

Các tiêu chí chấp nhận (Acceptance Criteria) là một phần quan trọng trong quy trình phát triển phần mềm. Nó bao gồm các điều kiện cần được đáp ứng để một yêu cầu của người dùng được coi là đã được thực hiện đúng. Các tiêu chí chấp nhận thường bao gồm các yếu tố sau: - Đảm bảo phần mềm đáp ứng được các yêu cầu chức năng (functional requirements) của người dùng. Điều này có thể được thực hiện thông qua việc chạy các thử nghiệm chấp nhận (acceptance tests) được định nghĩa dựa trên các yêu cầu của người dùng. - Đảm bảo phần mềm đáp ứng được các yêu cầu không chức năng (nonfunctional requirements) như hiệu suất, bảo mật, độ tin cậy, v.v. - Theo dõi các lỗi và vấn đề mở (open defects and issues) để đảm bảo rằng phần mềm được phát triển và thử nghiệm một cách hiệu quả. - Các tiêu chí chấp nhận không bao gồm việc có giao diện người dùng (user interface) hiện đại hoặc theo xu hướng.

Trong bước phân tích yêu cầu, kỹ thuật nào không phổ biến để thể hiện yêu cầu?

Khi có mâu thuẫn giữa phát triển sản phẩm và khách hàng, cách giải quyết vấn đề này là rất quan trọng. Trước hết, chúng ta cần hiểu rằng khách hàng là người sử dụng sản phẩm và họ có nhu cầu, mong muốn cụ thể. Tuy nhiên, phát triển sản phẩm cũng cần phải đảm bảo rằng sản phẩm đó đáp ứng được các mục tiêu kinh doanh của công ty. Vì vậy, khi có mâu thuẫn, chúng ta cần phải cân nhắc và tìm ra giải pháp phù hợp nhất. Giải pháp tốt nhất là khách hàng được ưu tiên, nhưng phải đảm bảo rằng ưu tiên đó vẫn nằm trong phạm vi mục tiêu kinh doanh của công ty. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu của khách hàng và vẫn đạt được mục tiêu kinh doanh.

Khi tham gia vào nhiều đại diện người dùng khác nhau thay vì chỉ dựa vào một đại diện duy nhất, chúng ta có thể đảm bảo được một cái nhìn toàn diện hơn về nhu cầu đa dạng của người dùng. Điều này giúp chúng ta hiểu rõ hơn về những mong muốn và kỳ vọng của người dùng, từ đó có thể thiết kế và phát triển sản phẩm hoặc giải pháp phù hợp hơn với nhu cầu của họ. Ngoài ra, việc tham gia vào nhiều đại diện người dùng còn giúp chúng ta nhận ra và giải quyết được những rủi ro tiềm ẩn mà chúng ta có thể bỏ qua nếu chỉ dựa vào một đại diện duy nhất.

Các nhà vận động sản phẩm (product champions) đóng vai trò quan trọng trong quá trình phát triển sản phẩm. Họ có nhiệm vụ thu thập yêu cầu từ các thành viên của nhóm người dùng mà họ đại diện và giải quyết các mâu thuẫn không nhất quán. Đồng thời, họ cũng đóng vai trò là điểm liên hệ chính giữa các thành viên của một nhóm người dùng cụ thể và nhà phân tích kinh doanh của dự án. Điều này giúp đảm bảo rằng các yêu cầu của người dùng được hiểu và thực hiện chính xác.

Trong câu hỏi này, chúng ta đang được hỏi về loại quy tắc kinh doanh được thể hiện trong một tuyên bố cụ thể. Tuyên bố này cho rằng nếu một khách hàng tiềm năng không phản hồi lại sau 30 ngày kể từ khi liên hệ lần đầu tiên, thì đó phải là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó. Loại quy tắc kinh doanh được thể hiện ở đây là quy tắc suy luận (inference). Quy tắc suy luận là quy tắc kinh doanh cho phép hệ thống đưa ra kết luận hoặc quyết định dựa trên dữ liệu và thông tin đã có. Trong trường hợp này, hệ thống sẽ suy luận rằng khách hàng tiềm năng không phản hồi lại sau 30 ngày là một khách hàng tiềm năng lạnh và có thể được đánh dấu theo cách đó.

Trong việc mô tả một trường hợp sử dụng, các điều kiện có khả năng ngăn cản trường hợp sử dụng thành công được gọi là ngoại lệ. Ngoại lệ là các điều kiện không mong muốn có thể xảy ra trong quá trình thực hiện một trường hợp sử dụng, chẳng hạn như lỗi dữ liệu, lỗi kết nối mạng, v.v. Khi xác định ngoại lệ, chúng ta cần phải xác định rõ nguyên nhân và cách giải quyết của chúng để đảm bảo rằng trường hợp sử dụng vẫn có thể hoạt động một cách hiệu quả. Ngoài ra, ngoại lệ cũng giúp chúng ta xác định các trường hợp sử dụng phụ, những trường hợp sử dụng có thể xảy ra nhưng không phải là trường hợp sử dụng chính.

Để tìm kiếm các quy tắc kinh doanh, bạn có thể tham khảo các nguồn sau: Thứ nhất, kiến thức phổ biến từ tổ chức, thường được thu thập từ những người đã làm việc với doanh nghiệp trong một thời gian dài và hiểu rõ chi tiết về cách thức hoạt động của nó. Điều này giúp bạn hiểu được quy trình và quy tắc kinh doanh của tổ chức. Thứ hai, hệ thống di sản (Legacy systems) chứa các quy tắc kinh doanh trong yêu cầu và mã nguồn của chúng. Điều này cho phép bạn hiểu được cách thức hoạt động của hệ thống và các quy tắc kinh doanh được áp dụng. Thứ ba, phân tích tài liệu hiện có, bao gồm các yêu cầu kỹ thuật từ dự án trước, quy định, tiêu chuẩn ngành, tài liệu chính sách doanh nghiệp, hợp đồng và kế hoạch kinh doanh. Điều này giúp bạn hiểu được quy tắc kinh doanh và cách thức hoạt động của doanh nghiệp. Tóm lại, việc tìm kiếm quy tắc kinh doanh là một quá trình phức tạp và đòi hỏi sự tham gia của nhiều nguồn lực khác nhau.

Requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, nó đại diện cho một tập hợp các yêu cầu mà các bên liên quan đã đồng ý, thường xác định nội dung của một phiên bản cụ thể hoặc một vòng lặp phát triển. Requirements baseline giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan, đồng thời giúp giảm thiểu rủi ro và tăng cường hiệu suất phát triển. Khi tạo ra một requirements baseline, các nhà phát triển cần xem xét kỹ lưỡng các yêu cầu của hệ thống, bao gồm cả các tính năng, chức năng, và đặc điểm kỹ thuật. Điều này giúp đảm bảo rằng hệ thống được phát triển đáp ứng được các yêu cầu của các bên liên quan và đáp ứng được nhu cầu của người dùng cuối cùng. Requirements baseline cũng giúp các nhà phát triển theo dõi và quản lý các yêu cầu của hệ thống, từ đó giúp cải thiện hiệu suất phát triển và giảm thiểu rủi ro. Tóm lại, requirements baseline là một khái niệm quan trọng trong quy trình phát triển hệ thống, giúp đảm bảo rằng hệ thống được phát triển đáp ứng được nhu cầu và kỳ vọng của các bên liên quan.

Quá trình quản lý yêu cầu (Requirements Management) là một phần quan trọng trong vòng đời phát triển phần mềm. Nó bao gồm việc thu thập, xác định, phân tích, xác định và quản lý yêu cầu của khách hàng. Trong các hoạt động sau, hoạt động nào được coi là một phần của nỗ lực quản lý yêu cầu?

Một đại diện được chỉ định của một lớp người dùng cụ thể cung cấp các yêu cầu người dùng cho nhóm mà họ đại diện. Người đại diện này đóng vai trò quan trọng trong việc xác định và ưu tiên các yêu cầu của nhóm, đảm bảo rằng các yêu cầu này được thực hiện một cách hiệu quả và phù hợp với mục tiêu của nhóm. Họ cũng phải có khả năng giao tiếp và làm việc hiệu quả với các thành viên khác trong nhóm, cũng như với các bên liên quan khác.

Một yêu cầu được định nghĩa tốt nhất là một nhu cầu hoặc mong muốn của doanh nghiệp để giải quyết một vấn đề hoặc đạt được một mục tiêu. Yêu cầu là một khái niệm quan trọng trong quản lý dự án và phát triển sản phẩm, giúp xác định rõ những gì cần được thực hiện để đáp ứng nhu cầu của khách hàng hoặc đạt được mục tiêu kinh doanh. Một yêu cầu thường bao gồm các yếu tố như: mục tiêu, yêu cầu chức năng, yêu cầu không chức năng, và các ràng buộc khác. Việc định nghĩa rõ ràng và chính xác yêu cầu giúp đảm bảo rằng dự án được thực hiện đúng hướng và đạt được kết quả mong muốn.

Khi xây dựng hệ thống thông tin, việc tham gia của các bên liên quan, bao gồm cả chuyên gia dữ liệu, vào quá trình xác định yêu cầu dữ liệu là rất quan trọng. Điều này giúp đảm bảo một cái nhìn toàn diện về nhu cầu và phức tạp của dữ liệu. Bằng cách tham gia vào quá trình này, các chuyên gia dữ liệu có thể cung cấp kiến thức chuyên môn và kinh nghiệm để giúp xác định chính xác yêu cầu dữ liệu của hệ thống. Điều này giúp tránh những sai sót và nhầm lẫn trong quá trình thiết kế và phát triển hệ thống, từ đó đảm bảo hệ thống hoạt động chính xác và hiệu quả.

Trong quá trình phát triển yêu cầu, việc thiết lập cơ chế quản lý thay đổi yêu cầu là rất quan trọng. Điều này giúp dự án có thể thích nghi với nhu cầu thay đổi trong quá trình thực hiện, đồng thời vẫn duy trì được sự kiểm soát. Khi yêu cầu thay đổi, cơ chế này sẽ giúp dự án cập nhật và điều chỉnh các yêu cầu phù hợp, tránh gây ra sự cố hoặc lãng phí tài nguyên. Ngoài ra, cơ chế này cũng giúp dự án duy trì được sự minh bạch và rõ ràng trong quá trình thay đổi, đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về các thay đổi và tác động của chúng.

Trong một tài liệu yêu cầu phần mềm, phần mô tả giao diện người dùng thuộc về phần nào?

Swimlane diagram là một loại biểu đồ được sử dụng để minh họa các quy trình hoặc quy trình kinh doanh. Nó thường được sử dụng để hiển thị các bước trong một quy trình, cùng với các cá nhân hoặc nhóm chịu trách nhiệm thực hiện từng bước. Trong một Swimlane diagram, các bước quy trình thường được hiển thị dưới dạng hình dạng đặc biệt. Câu hỏi yêu cầu bạn xác định hình dạng nào thường được sử dụng để hiển thị các bước quy trình trong một Swimlane diagram.

Trong sơ đồ trường hợp sử dụng, mũi tên từ người dùng đến trường hợp sử dụng thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng. Điều này có nghĩa là người dùng đó sẽ tương tác với hệ thống để đạt được mục tiêu của trường hợp sử dụng. Ví dụ, nếu một người dùng là người đặt hàng trực tuyến, thì mũi tên từ người dùng đến trường hợp sử dụng 'Đặt hàng trực tuyến' thể hiện rằng người dùng đó là người dùng cho trường hợp sử dụng này. Điều này giúp xác định rõ ràng vai trò của người dùng trong hệ thống và đảm bảo rằng hệ thống đáp ứng được nhu cầu của người dùng.