Câu hỏi: SWR302 - Phần 1: Yêu cầu phần mềm và quan hệ với khách hàng

Đáp án đúng gồm hai ý: "All participants in the requirements approval process must understand what signing off implies." và "Reaching agreement on requirements ensures that both customers and developers have a shared understanding of project objectives.". Ký duyệt yêu cầu (sign-off) có ý nghĩa là các bên đồng ý rằng bộ yêu cầu hiện tại là đường cơ sở (baseline) để lập kế hoạch và xây dựng, vì vậy mọi người tham gia phải hiểu rõ chữ ký đó cam kết điều gì; và quá trình đạt đồng thuận chính là cách tạo hiểu biết chung giữa khách hàng và nhà phát triển. Phát biểu "is an infallible method to prevent any changes later in the project" sai vì không có cách nào ngăn hoàn toàn thay đổi; yêu cầu vẫn đổi và được xử lý qua quy trình kiểm soát thay đổi. Phát biểu cho rằng ký duyệt nhằm "freeze requirements and prevent any future modifications" sai vì đường cơ sở không phải đóng băng; thay đổi sau ký duyệt được chấp nhận nếu đi qua phân tích tác động và phê duyệt.

Đáp án đúng: "Ineffective communication between customers and the development team.". Expectation gap (khoảng cách kỳ vọng) là khoảng chênh giữa sản phẩm khách hàng nghĩ họ sẽ nhận và sản phẩm đội phát triển thực sự giao. Khoảng cách này lớn dần khi hai bên ít trao đổi: khách hàng chỉ tham gia lúc đầu và lúc nghiệm thu, trong khi nhu cầu của họ đã đổi và cách hiểu của đội đã lệch. Cách thu hẹp là gắn kết khách hàng thường xuyên qua rà soát, prototype, demo theo vòng lặp. "A rigorous testing process." sai vì kiểm thử chặt giúp phát hiện sai lệch sớm, không tạo ra khoảng cách. "Continuously updating the requirements documentation." sai vì cập nhật tài liệu liên tục giữ cho hai bên cùng nhìn một phiên bản yêu cầu, tức là làm hẹp khoảng cách. "Time pressure from project management." có thể gây ra nhiều vấn đề như cắt bớt chất lượng, nhưng không phải nguyên nhân cốt lõi khiến kỳ vọng của khách hàng lệch với sản phẩm. "Using advanced technology in software development." sai vì công nghệ dùng để xây không quyết định việc hiểu đúng nhu cầu.

Đáp án đúng: "A superset of stakeholders". Bên liên quan (stakeholder) là mọi cá nhân hay tổ chức bị ảnh hưởng hoặc có ảnh hưởng tới dự án, nên tập này rộng nhất; khách hàng là một phần của bên liên quan, và người dùng lại là một phần trong đó. Vì vậy nói người dùng là tập bao của bên liên quan là sai, đây chính là phát biểu không đúng cần chọn. "A subset of the product’s customers in some cases" là đặc điểm đúng: có lúc người dùng cũng là khách hàng, như người mua phần mềm để tự dùng. "A subset of the product’s users" đúng theo nghĩa mỗi lớp người dùng (user class) chỉ là một nhóm con trong toàn bộ người dùng sản phẩm. "Includes direct users and indirect users" cũng đúng: người dùng trực tiếp thao tác hệ thống, còn người dùng gián tiếp nhận kết quả từ nó như báo cáo, nên cả hai đều phải được xét khi khơi gợi yêu cầu.

Đáp án đúng: "Elicitation, analysis, specification, and validation.". Kỹ nghệ yêu cầu chia thành phát triển yêu cầu (requirements development) và quản lý yêu cầu (requirements management). Phát triển yêu cầu có bốn phân ngành: khơi gợi để thu thập yêu cầu từ bên liên quan, phân tích để làm rõ, mô hình hoá, xếp ưu tiên, đặc tả để ghi thành tài liệu có cấu trúc, và thẩm định để xác nhận yêu cầu đúng với nhu cầu. Các hoạt động này lặp đi lặp lại chứ không chạy một lượt. "Planning, execution, monitoring, and control." sai vì đây là các nhóm quy trình của quản lý dự án. "Collection, documentation, review, and approval." sai vì tuy gần nghĩa nhưng không phải bộ thuật ngữ chuẩn, và bỏ mất phần phân tích, vốn là nơi yêu cầu được tinh chỉnh và soát lỗi. "Business, user, functional, and nonfunctional." sai vì đây là các loại hay tầng yêu cầu, tức sản phẩm của phát triển yêu cầu, chứ không phải các hoạt động của nó.

Đáp án đúng: "Establish a clear decision-making rule". Bất đồng giữa các bên liên quan là chuyện thường xuyên trong phát triển yêu cầu, nên ngay từ đầu dự án cần xác định ai là người ra quyết định cho từng loại vấn đề và họ quyết theo quy tắc nào, ví dụ đồng thuận, biểu quyết đa số hay người có thẩm quyền quyết sau khi nghe ý kiến; có quy tắc rõ thì tranh cãi được giải quyết nhanh và công bằng. "Let developers decide" sai vì lập trình viên không nắm giá trị nghiệp vụ, quyết định yêu cầu không phải trách nhiệm của họ. "Avoid involving too many users" sai vì né tránh người dùng chỉ làm thiếu thông tin chứ không giải quyết bất đồng. "Follow whatever the executive sponsor says" không phải quy tắc ra quyết định: nhà tài trợ có thể là người quyết cuối ở một số vấn đề, nhưng làm theo mọi điều họ nói mà không có quy trình sẽ bỏ qua ý kiến các bên khác.