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

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.

Vậy, định nghĩa chính xác nhất về yêu cầu là gì? Yêu cầu là một tính chất mà sản phẩm phải có để mang lại giá trị cho bên liên quan. Điều này có nghĩa là yêu cầu là một đặc điểm hoặc tính năng mà sản phẩm phải có để đáp ứng nhu cầu hoặc mong muốn của người dùng. Ví dụ, một yêu cầu có thể là một tính năng mới, một chức năng cải tiến hoặc một tính năng bảo mật. Yêu cầu là cơ sở để thiết kế và phát triển sản phẩm, và nó giúp đảm bảo rằng sản phẩm đáp ứng được nhu cầu và mong muốn của người dùng. Vì vậy, yêu cầu là một khái niệm quan trọng trong quá trình thiết kế và phát triển sản phẩm.

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.

Câu hỏi này yêu cầu bạn xác định thông tin không đúng về khách hàng phần mềm. Các lựa chọn bao gồm: một phần của các bên liên quan, một cá nhân hoặc tổ chức nhận được lợi ích trực tiếp hoặc gián tiếp từ sản phẩm, họ có thể yêu cầu, trả tiền, chọn, chỉ định, sử dụng hoặc nhận được đầu ra được tạo bởi sản phẩm phần mềm. Tuy nhiên, 'như vậy là nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp' không phải là khách hàng phần mềm. Khách hàng phần mềm thường là người sử dụng cuối cùng hoặc tổ chức có nhu cầu sử dụng sản phẩm phần mềm. Nhân viên pháp lý, kiểm toán viên tuân thủ, nhà cung cấp có thể là các bên liên quan khác nhau nhưng không phải là khách hàng phần mềm.

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.

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.

Quá trình phát triển yêu cầu đại diện bao gồm các hoạt động như chọn kỹ thuật thu thập yêu cầu, đánh giá yêu cầu, lập kế hoạch thu thập yêu cầu và phân tích yêu cầu. Tuy nhiên, hoạt động không được bao gồm trong quá trình này là chọn một chu kỳ phát triển phần mềm phù hợp. Chu kỳ phát triển phần mềm là một khái niệm rộng hơn và bao gồm nhiều giai đoạn khác nhau, chẳng hạn như lập kế hoạch, thiết kế, triển khai, thử nghiệm và bảo trì. Trong khi đó, quá trình phát triển yêu cầu đại diện chỉ tập trung vào việc thu thập, xác định và xác minh yêu cầu của hệ thống.

Trong một dự án Agile, vai trò của một nhà phân tích kinh doanh là xác định quy trình yêu cầu nhẹ nhàng, linh hoạt và thích nghi theo yêu cầu của dự án. Họ cũng cần giúp xác nhận rằng nhu cầu của khách hàng được thể hiện chính xác trong danh sách yêu cầu (backlog). Ngoài ra, họ cần hỗ trợ sắp xếp ưu tiên cho danh sách yêu cầu. Điều này giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đáp ứng được nhu cầu của khách hàng.

Kỹ thuật được sử dụng để thể hiện phạm vi của một dự án là gì? Để trả lời câu hỏi này, chúng ta cần hiểu rõ về các kỹ thuật khác nhau được sử dụng trong việc thể hiện phạm vi của một dự án. Ecosystem map (Bản đồ hệ sinh thái) và Context diagram (Bản đồ ngữ cảnh) là hai kỹ thuật được sử dụng để thể hiện phạm vi của một dự án. Ecosystem map giúp thể hiện các thành phần và mối quan hệ giữa chúng trong hệ sinh thái của dự án, trong khi Context diagram giúp thể hiện các đối tượng và mối quan hệ giữa chúng trong ngữ cảnh của dự án. Cả hai kỹ thuật này đều giúp người lập kế hoạch và quản lý dự án hiểu rõ về phạm vi của dự án và có thể đưa ra quyết định sáng suốt.

Trong sơ đồ ngữ cảnh, các thực thể bên ngoài được minh họa bằng hình dạng và dữ liệu lưu chuyển được minh họa bằng đường nét.

Khi định nghĩa rõ phạm vi của một dự án phần mềm trong tài liệu phạm vi, điều này giúp tránh hiện tượng phạm vi dự án mở rộng không kiểm soát được (scope creep). Điều này có thể dẫn đến lãng phí thời gian, tài nguyên và chi phí. Bằng cách xác định rõ phạm vi dự án, các nhà phát triển có thể tập trung vào các yêu cầu chính và tránh các yêu cầu không liên quan. Điều này giúp đảm bảo dự án được hoàn thành đúng hạn và đạt được mục tiêu mong muốn.

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.

Người dùng là một phần của nhóm khách hàng của sản phẩm. Tuy nhiên, người dùng không nhất thiết phải là khách hàng. Ví dụ, một người dùng có thể là nhân viên của công ty sử dụng sản phẩm, nhưng không phải là khách hàng của sản phẩm. Một người dùng cũng có thể là người sử dụng sản phẩm miễn phí, nhưng không phải là khách hàng. Do đó, người dùng không phải là một phần của nhóm khách hàng của sản phẩm. Thay vào đó, người dùng là một phần của nhóm người sử dụng sản phẩm.

Để xác định liệu bạn đã hoàn thành yêu cầu thu thập thông tin (requirements elicitation) hay chưa, bạn cần xem xét các tín hiệu sau. Đầu tiên, khi người dùng lặp lại các vấn đề họ đã thảo luận trước đó, điều đó có thể là dấu hiệu cho thấy bạn đã thu thập đủ thông tin. Thứ hai, nếu các yêu cầu mới được đề xuất đều được xác định là nằm ngoài phạm vi (out of scope), điều đó cho thấy bạn đã thu thập đủ thông tin về yêu cầu chính. Cuối cùng, nếu các yêu cầu mới được đề xuất đều có mức độ ưu tiên thấp, điều đó cũng cho thấy bạn đã thu thập đủ thông tin về yêu cầu chí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.