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

Trong quá trình thiết kế yêu cầu (requirement engineering), có bốn bước cơ bản là thu thập thông tin (elicitation), phân tích (analysis), thiết kế (design) và xác định tài liệu (documentation). Tuy nhiên, xác định tài liệu không phải là một bước trong quá trình thiết kế yêu cầu. Xác định tài liệu là một phần của quá trình phát triển phần mềm, liên quan đến việc tạo và quản lý các tài liệu liên quan đến dự án. Vì vậy, trong bốn lựa chọn trên, "documentation" không phải là một bước của thiết kế yêu cầu.

Requirements development là quá trình xác định và xác minh các yêu cầu của một dự án. Quá trình này bao gồm nhiều bước khác nhau, bao gồm Analysis, Validation, Design và Elicitation. Tuy nhiên, trong các bước này, Design không phải là một bước riêng biệt trong Requirements development. Thay vào đó, Design là một phần của quá trình phát triển yêu cầu, nơi các yêu cầu được xác định và mô tả chi tiết hơn. Design không phải là một bước độc lập mà là một phần của quá trình phát triển yêu cầu. Vì vậy, đáp án đúng là Design.

Một số bên liên quan là khách hàng, chẳng hạn như nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp, nhà thầu và nhà đầu tư mạo hiểm. Họ có thể có quyền truy cập vào thông tin về dự án và có thể ảnh hưởng đến quyết định kinh doanh của công ty. Vì vậy, việc xác định và quản lý các bên liên quan là rất quan trọng để đảm bảo rằng thông tin dự án được bảo mật và tuân thủ các quy định.

Hoạt động thu thập thông tin (elicitation) là một phần quan trọng trong quá trình thiết kế và phát triển sản phẩm. Các hoạt động thu thập thông tin thường bao gồm phỏng vấn người dùng, quan sát người dùng thực hiện công việc của họ và mô hình hóa môi trường ứng dụng. Tuy nhiên, định nghĩa tầm nhìn và phạm vi dự án sản phẩm không phải là một hoạt động thu thập thông tin. Thay vào đó, nó là một hoạt động quan trọng trong quá trình định hướng và lập kế hoạch dự án. Nó giúp xác định mục tiêu và phạm vi của dự án, từ đó hướng dẫn các hoạt động tiếp theo.

Loại yêu cầu nào tốt nhất để mô tả hành vi và thông tin mà giải pháp sẽ quản lý bao gồm các hành động hoặc phản hồi cụ thể của hệ thống? Loại yêu cầu này tập trung vào các chức năng cụ thể mà hệ thống sẽ thực hiện, bao gồm các hành động hoặc phản hồi mà hệ thống sẽ tạo ra. Ví dụ, yêu cầu về việc hệ thống phải gửi email xác nhận khi khách hàng đặt hàng hoặc yêu cầu về việc hệ thống phải hiển thị thông tin khách hàng khi họ đăng nhập. Loại yêu cầu này giúp đảm bảo rằng hệ thống sẽ thực hiện các chức năng mong muốn và tạo ra các phản hồi mong muốn.

Một Business analyst (BA) là người chịu trách nhiệm thu thập, phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. Các nhiệm vụ chính của một BA bao gồm: - Communicate requirements: Truyền đạt yêu cầu của khách hàng hoặc tổ chức đến các thành viên khác trong dự án. - Document requirements: Lưu trữ và quản lý yêu cầu của khách hàng hoặc tổ chức. - Analyze requirements: Phân tích và xác định nhu cầu của khách hàng hoặc tổ chức. - Elicit requirements: Thu thập và xác định nhu cầu của khách hàng hoặc tổ chức. - Assurance requirements: Đây là một nhiệm vụ không phải là trách nhiệm chính của một BA. Assurance requirements thường liên quan đến việc đảm bảo rằng các yêu cầu đã được thực hiện đúng và đáp ứng được nhu cầu của khách hàng hoặc tổ chức. Điều này thường là trách nhiệm của các chuyên gia khác như kiểm toán viên hoặc chuyên gia đảm bảo chất lượng. Vì vậy, Assurance requirements là một nhiệm vụ không phải là trách nhiệm chính của một Business analyst.

Mô tả và phạm vi là hai khái niệm quan trọng trong quá trình phát triển sản phẩm. Mô tả (Specifications) là bản mô tả chi tiết về sản phẩm, bao gồm các yêu cầu chức năng và phi chức năng. Phạm vi (Scope) là phạm vi của sản phẩm, bao gồm các tính năng và chức năng chính. Các hoạt động của người ủng hộ sản phẩm (Product Champions) thường được thực hiện trong giai đoạn phân tích (Analysis). Trong giai đoạn này, người ủng hộ sản phẩm sẽ tham gia vào việc xác định các yêu cầu của sản phẩm, phân tích các yêu cầu và xác định các tính năng chính của sản phẩm.

Sản phẩm tầm nhìn và phạm vi dự án mô tả mục tiêu cuối cùng của sản phẩm sẽ đạt được và phần nào của tầm nhìn sản phẩm cuối cùng mà dự án hoặc vòng phát triển hiện tại sẽ giải quyết. Điều này bao gồm việc xác định mục tiêu kinh doanh và phần nào của sản phẩm sẽ đạt được mục tiêu đó. Ví dụ, nếu dự án đang phát triển một hệ thống quản lý bán hàng, sản phẩm tầm nhìn và phạm vi dự án có thể mô tả hệ thống bán hàng trực tuyến sẽ đạt được mục tiêu tăng doanh thu và phần nào của hệ thống sẽ được triển khai trong dự án hiện tại.

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.

Khi tạo nhân vật (persona) cho mỗi lớp người dùng, điều quan trọng nhất là nhân vật đó phải đại diện cho lớp người dùng đó. Điều này có nghĩa là nhân vật phải phản ánh được đặc điểm, nhu cầu và hành vi của người dùng trong lớp đó. Nhân vật không nhất thiết phải là một người thật, mà chỉ cần là một hình tượng đại diện cho lớp người dùng. Ví dụ, nếu bạn đang thiết kế một ứng dụng cho người dùng trẻ tuổi, nhân vật của bạn có thể là một người trẻ tuổi với những đặc điểm và nhu cầu tương tự. Điều quan trọng là nhân vật phải phản ánh được thực tế và giúp bạn hiểu được người dùng của mình.

Để có thể sắp xếp danh sách dự án theo thứ tự chữ cái từ trước sang sau và ngược lại, người dùng phải có thể thực hiện được điều này. Điều này là một yêu cầu của người dùng vì nó liên quan trực tiếp đến cách người dùng tương tác với hệ thống. Yêu cầu này không liên quan đến chức năng của hệ thống mà là cách người dùng sử dụng hệ thống. Do đó, nó được coi là một yêu cầu của người dùng.

Kỹ thuật thu thập thông tin (elicitation) là một phần quan trọng trong quá trình phát triển sản phẩm hoặc giải pháp. Có nhiều kỹ thuật thu thập thông tin khác nhau, bao gồm phỏng vấn (interviews), nhóm thảo luận (focus groups) và quan sát (observations). Tuy nhiên, một số phương pháp không được coi là kỹ thuật thu thập thông tin, mà là phương pháp đào tạo (training courses). Phương pháp đào tạo thường được sử dụng để cung cấp kiến thức và kỹ năng cho người tham gia, nhưng không nhằm mục đích thu thập thông tin cụ thể. Vì vậy, trong danh sách các kỹ thuật thu thập thông tin, phương pháp đào tạo (training courses) không phải là một kỹ thuật thu thập thông tin.

Trong mô hình Use Case, các yếu tố bắt buộc phải có là những gì? Các Use Case phải có tên (Name), điều kiện trước (Pre-condition) và điều kiện sau (Post-condition). Điều kiện trước và sau giúp xác định rõ ràng các yêu cầu của Use Case, trong khi tên của Use Case giúp phân biệt nó với các Use Case khác. Các tác nhân (Actors) cũng là một phần quan trọng của Use Case, nhưng chúng không phải là bắt buộc. Vì vậy, đáp án đúng là ["Pre-condition", "Name", "Post-condition"].

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.