Câu hỏi: SWR302 Software Requirements – Bộ ôn tập thi lại số 7

Đáp án đúng: "Requirements Volatility Chart". Requirements volatility (độ biến động yêu cầu) đo số lượng yêu cầu được thêm, sửa, xoá theo thời gian; vẽ thành biểu đồ, nó cho thấy khối lượng thay đổi và xu hướng của chúng, giúp phát hiện khi yêu cầu chưa ổn định gần ngày phát hành. Đây là một chỉ số của hoạt động quản lý yêu cầu, gắn với kiểm soát thay đổi. "Use Case Matrix" sai vì ma trận ca sử dụng chỉ đối chiếu ca sử dụng với các phần tử khác, như tác nhân hay yêu cầu chức năng, nó không theo dõi số lần thay đổi theo thời gian. "MoSCoW Grid" sai vì MoSCoW là kỹ thuật xếp ưu tiên Must, Should, Could, Won't, không đo lượng thay đổi. "Stakeholder Priority Index" sai vì một chỉ số ưu tiên bên liên quan, nếu có, phản ánh mức quan trọng của bên liên quan hay yêu cầu, chứ không cho thấy khối lượng và xu hướng thay đổi yêu cầu.

Đáp án đúng: "To help determine the best approach to document the backlog and facilitate its prioritization with the product owner and team". Trong môi trường agile, product backlog là danh sách công việc được xếp ưu tiên; product owner là người chịu trách nhiệm cuối cùng về thứ tự ưu tiên, còn người phân tích nghiệp vụ hỗ trợ: chọn cách ghi backlog (user story, tiêu chí chấp nhận, mô hình) và điều phối (facilitate) việc xếp ưu tiên cùng product owner và nhóm. "To eliminate the backlog entirely." sai vì backlog là công cụ trung tâm của agile, không thể bỏ. "To solely manage and prioritize the backlog without customer input" sai vì người phân tích nghiệp vụ không tự quyết một mình, ưu tiên phải dựa vào ý kiến khách hàng và product owner. "To ensure the backlog never changes" sai vì backlog được tinh chỉnh liên tục, đón nhận thay đổi là tinh thần của agile.

Đáp án đúng: "System feature". Trong mẫu đặc tả yêu cầu phần mềm (Software Requirements Specification), mục Overall description (mô tả tổng quan) gồm các tiểu mục mô tả bối cảnh sản phẩm: "Product perspective" (vị trí sản phẩm trong hệ thống lớn hơn), "User classes and characteristics" (các nhóm người dùng và đặc điểm của họ), "Operating environment" (môi trường vận hành), "Design and implementation constraints" (ràng buộc thiết kế và cài đặt) và "Assumptions and dependencies" (giả định và phụ thuộc). Cả năm mục này đều đúng là thành phần của Overall description nên không được chọn. Còn System features là một chương riêng của mẫu SRS, nơi mô tả từng tính năng kèm yêu cầu chức năng chi tiết, không thuộc phần mô tả tổng quan, vì vậy đây là câu trả lời cho câu hỏi dạng NOT.

Đáp án đúng: "By categorizing requirements as Must-have, Should-have, Could-have, and Won’t-have". MoSCoW là kỹ thuật ưu tiên hóa yêu cầu trong hoạt động phân tích và lập kế hoạch phát hành, xếp mỗi yêu cầu vào bốn nhóm: Must (bắt buộc phải có), Should (nên có nhưng không sống còn), Could (có thì tốt nếu còn thời gian) và Won’t (lần này sẽ không làm). Nhờ các nhóm rõ nghĩa, bên liên quan và đội phát triển dễ thống nhất phạm vi cho từng bản phát hành. Phương án "By focusing on technical feasibility" sai vì MoSCoW dựa trên mức cần thiết với nghiệp vụ, tính khả thi kỹ thuật chỉ là một yếu tố tham khảo. Phương án "By skipping stakeholder engagement" sai vì việc xếp nhóm đòi hỏi bên liên quan cùng thảo luận và đồng thuận. Phương án "By eliminating low-priority requirements" sai vì nhóm Won’t không xóa yêu cầu mà chỉ ghi nhận rằng nó không nằm trong lần giao này và có thể xem lại ở bản sau.

Đáp án đúng: "Managing the project schedule". Chuyên viên phân tích nghiệp vụ (business analyst) chịu trách nhiệm chính cho các hoạt động phát triển yêu cầu như khơi gợi, phân tích, đặc tả, thẩm định và hỗ trợ quản lý yêu cầu; còn lập và theo dõi lịch trình dự án là việc của quản lý dự án (project manager), nên đây là nhiệm vụ không điển hình của BA. "Eliciting requirements" là việc cốt lõi của BA: phỏng vấn, tổ chức workshop, quan sát để thu thập nhu cầu từ các bên liên quan. "Analyzing business processes" cũng thuộc vai trò BA vì phải hiểu quy trình hiện tại để xác định thay đổi và yêu cầu cho hệ thống. "Validating the requirements" là hoạt động thẩm định, BA tổ chức rà soát và kiểm tra để chắc yêu cầu phản ánh đúng nhu cầu thật.

Đáp án đúng: "To prioritize high-value requirements for early implementation". Phân loại Must-have và Should-have là cách xếp ưu tiên kiểu MoSCoW: Must là bắt buộc để sản phẩm có giá trị, Should là quan trọng nhưng có thể dời nếu thiếu nguồn lực. Mục đích là để đội làm trước những yêu cầu mang giá trị cao nhất và có căn cứ khi phải cắt bớt phạm vi. "To eliminate low-priority requirements altogether" sai vì Should-have không bị loại; yêu cầu ưu tiên thấp chỉ bị dời sang đợt sau, vẫn nằm trong danh sách. "To finalize coding strategies" sai vì xếp ưu tiên là hoạt động phân tích yêu cầu, không quyết định chiến lược viết mã. "To reduce the scope of non-functional requirements" sai vì phân loại này áp dụng cho mọi loại yêu cầu và không nhằm thu hẹp riêng yêu cầu phi chức năng; một thuộc tính chất lượng hoàn toàn có thể là Must-have.

Đáp án đúng: "To track changes and ensure alignment with project goals". Traceability (khả năng truy vết) là việc liên kết mỗi yêu cầu ngược về nguồn gốc của nó (mục tiêu nghiệp vụ, yêu cầu người dùng) và xuôi tới thiết kế, mã, ca kiểm thử; thuộc hoạt động quản lý yêu cầu. Khi yêu cầu thay đổi, các liên kết này cho biết thay đổi ảnh hưởng tới đâu và yêu cầu mới có còn phục vụ mục tiêu dự án không. "To prioritize functional requirements" sai vì xếp ưu tiên là một hoạt động phân tích riêng, dựa vào giá trị, chi phí, rủi ro chứ không dựa vào liên kết truy vết. "To reduce stakeholder involvement" sai vì truy vết không thay thế được sự tham gia của các bên liên quan. "To eliminate ambiguous requirements" là việc của viết yêu cầu rõ ràng và review, truy vết không làm yêu cầu bớt mơ hồ.

Đáp án đúng: "Because it ensures that use cases capture the correct interaction scenarios by clearly defining the roles (actors) that a user can assume.". Người dùng (user) là con người cụ thể, còn tác nhân (actor) là một vai trò tương tác với hệ thống; một người có thể đóng nhiều vai, và một actor cũng có thể là hệ thống khác hoặc thiết bị. Phân biệt hai khái niệm giúp use case được viết theo vai trò và mục tiêu của vai trò đó, nhờ vậy kịch bản tương tác đúng và không trùng lặp. Phương án "allows designers to ignore interactions with non-human systems" sai vì actor chính là cách đưa hệ thống ngoài vào mô hình, không phải bỏ qua chúng. Phương án "simplifies the use case diagrams by limiting the number of actors" sai vì mục đích là mô tả đúng vai trò, không phải giảm số actor. Phương án "separates the business logic from the technical implementation" sai vì đó là nguyên tắc chung của việc tách yêu cầu khỏi thiết kế, không liên quan tới phân biệt user với actor.

Đáp án đúng: "exceptions". Trong đặc tả use case (ca sử dụng), luồng chính mô tả con đường thành công thường gặp nhất; exceptions (ngoại lệ) là các điều kiện có thể ngăn ca sử dụng hoàn thành thành công, chẳng hạn mất kết nối hay thẻ thanh toán bị từ chối, kèm cách hệ thống phản ứng như báo lỗi, khôi phục hoặc kết thúc. Phương án "alternative flows" sai vì luồng thay thế là các biến thể vẫn dẫn tới mục tiêu thành công, chỉ đi đường khác so với luồng chính. Phương án "secondary scenarios" là cách gọi chung các kịch bản khác ngoài kịch bản chính, có thể gồm cả luồng thay thế lẫn ngoại lệ, nên không chỉ đích danh các điều kiện gây thất bại. Phương án "backup flows" không phải thuật ngữ chuẩn trong mô tả use case.

Đáp án đúng: "Increase the complexity of requirements". Cải tiến quy trình yêu cầu nhằm giảm làm lại, giảm chi phí và tăng giá trị dự án mang lại; làm yêu cầu phức tạp hơn đi ngược mục tiêu đó, vì yêu cầu tốt phải rõ ràng, súc tích và dễ kiểm chứng, nên đây là điều không phải mục tiêu. "Improve the accuracy of project estimates" là mục tiêu đúng: yêu cầu đầy đủ và ổn định giúp ước lượng công sức và thời gian sát hơn. "Reduce the cost of creating and maintaining software" cũng đúng vì lỗi yêu cầu phát hiện muộn rất tốn kém để sửa, nên làm yêu cầu tốt từ đầu cắt giảm chi phí cả lúc phát triển lẫn bảo trì. "Increase the value delivered by projects" đúng vì khi hiểu đúng nhu cầu, đội tập trung xây những gì thật sự mang lại giá trị cho khách hàng và tổ chức.

Đáp án đúng: "Validation ensures the product satisfies customer needs, while verification ensures the product meets its specifications.". Validation (thẩm định) trả lời câu hỏi có làm đúng sản phẩm không: yêu cầu hay sản phẩm có đáp ứng nhu cầu và mục tiêu kinh doanh của khách hàng. Verification (kiểm chứng) trả lời câu hỏi có làm sản phẩm đúng cách không: kết quả có khớp với đặc tả hay yêu cầu đã định. "Validation ensures that the product meets the user's needs, while verification ensures it is free from defects." sai ở vế sau: kiểm chứng là so với đặc tả, không bảo đảm sản phẩm hết lỗi; không hoạt động nào chứng minh được điều đó. "Validation occurs before the design phase, and verification occurs after." sai vì phân biệt hai khái niệm theo mục đích chứ không theo thời điểm; cả hai diễn ra suốt dự án, ví dụ rà soát yêu cầu cũng là kiểm chứng. "Validation is about internal testing, while verification is about external approval." sai vì đảo lộn ý nghĩa: thẩm định mới gắn với khách hàng bên ngoài, còn kiểm chứng thường là đối chiếu nội bộ với đặc tả.

Đáp án đúng: "Discovery of requirement gaps". Conceptual testing (kiểm thử khái niệm) là việc viết ca kiểm thử ở mức khái niệm ngay từ yêu cầu, trước khi có mã, thuộc hoạt động thẩm định yêu cầu. Khi cố nghĩ cách kiểm thử một yêu cầu, người viết sẽ thấy chỗ thiếu, chỗ mơ hồ hay mâu thuẫn, nên kỹ thuật này giúp phát hiện lỗ hổng yêu cầu từ sớm, khi sửa còn rẻ. "Interface design" sai vì thiết kế giao diện là hoạt động sau và kiểm thử khái niệm không nhằm tạo ra giao diện. "Team building" không phải mục tiêu của kỹ thuật thẩm định này, dù làm việc chung có thể giúp nhóm gắn kết hơn. "Detailed coding" sai vì kiểm thử khái niệm chủ động tránh phụ thuộc vào cài đặt, nó làm việc với yêu cầu trước khi viết mã.

Đáp án đúng: "To provide a full picture of the intended system by supplementing textual requirements.". Mô hình trực quan (visual models) như sơ đồ ngữ cảnh, sơ đồ luồng dữ liệu, sơ đồ trạng thái, ERD thể hiện cùng thông tin ở một góc nhìn khác với văn bản; đặt cạnh yêu cầu viết, chúng giúp lộ ra chỗ thiếu, mâu thuẫn và giúp các bên hiểu chung về hệ thống. Phương án "To completely replace all textual requirements documents." sai vì mô hình không chứa hết chi tiết như ràng buộc, thuộc tính chất lượng, dữ liệu cụ thể, nên phải đi kèm văn bản chứ không thay thế. Phương án "To make diagrams look more appealing." sai vì giá trị của mô hình là truyền đạt và phân tích, không phải thẩm mỹ. Phương án "To primarily identify project management tasks." sai vì mô hình phân tích mô tả hệ thống cần xây, còn việc xác định công việc dự án thuộc lập kế hoạch.

Đáp án đúng: "The number of loans that loan processors can enter per day". Chỉ số hiệu suất chính (key performance indicator, KPI) đo kết quả nghiệp vụ mà tổ chức quan tâm; khi thay thế một hệ thống (replacement project), yêu cầu quan trọng là hệ mới phải giữ hoặc cải thiện các KPI đó, và năng suất nhập hồ sơ vay mỗi ngày của nhân viên xử lý chính là thước đo trực tiếp hiệu quả nghiệp vụ cho vay. "The number of user interface changes per day" không phải chỉ số nghiệp vụ, nó chỉ đo tần suất thay đổi giao diện. "The number of features added to the system" là thước đo hoạt động phát triển, nhiều tính năng không đồng nghĩa nghiệp vụ hiệu quả hơn. "The total amount of data processed by the system" là chỉ số kỹ thuật về khối lượng xử lý, không gắn trực tiếp với kết quả mà người cho vay cần đạt.

Đáp án đúng: "Version control, change control, requirements status tracking, and requirements tracing". Quản lý yêu cầu (requirements management) là nhánh song song với phát triển yêu cầu, gồm bốn hoạt động: quản lý phiên bản cho từng yêu cầu và tài liệu yêu cầu, kiểm soát thay đổi qua quy trình đề xuất, đánh giá, quyết định, theo dõi trạng thái từng yêu cầu như đề xuất, đã duyệt, đã cài đặt, đã kiểm chứng, và truy vết yêu cầu tới nguồn gốc, thiết kế, mã và ca kiểm thử. "Version control, project scheduling, change control and budget management" sai vì lập lịch và quản lý ngân sách là việc của quản lý dự án. "Change control, risk assessment, requirements tracing and stakeholder engagement" sai vì đánh giá rủi ro và gắn kết bên liên quan là hoạt động quản lý dự án hoặc khơi gợi, không nằm trong bộ bốn hoạt động quản lý yêu cầu. "Change control, testing, deployment, and maintenance" sai vì kiểm thử, triển khai, bảo trì là các giai đoạn vòng đời phần mềm, không phải hoạt động quản lý yêu cầu.

Đáp án đúng: "Establishing clear acceptance criteria". Với dự án thuê ngoài (outsourced), nhóm phát triển ở xa, ít cơ hội hỏi lại, nên yêu cầu phải được viết chi tiết hơn và đi kèm tiêu chí chấp nhận (acceptance criteria) rõ ràng để hai bên thống nhất thế nào là sản phẩm đạt; đây là chỗ giao nhau giữa đặc tả và thẩm định yêu cầu. "Focusing only on cost-cutting measures" sai vì chỉ chăm chăm cắt chi phí dễ dẫn tới yêu cầu hiểu sai và làm lại tốn kém hơn. "Avoiding regular communication" đi ngược khuyến nghị, vì dự án thuê ngoài cần giao tiếp thường xuyên, có lịch họp và kênh hỏi đáp cố định. "Disregarding change management processes" sai vì thay đổi yêu cầu trong dự án thuê ngoài thường kéo theo thay đổi hợp đồng và chi phí, nên càng cần quy trình kiểm soát thay đổi chặt chẽ.

Đáp án đúng: "functional requirement". Câu này nói rõ một hành vi mà hệ thống phải cung cấp để người dùng thực hiện: sắp xếp danh sách dự án theo thứ tự chữ cái xuôi và ngược; mô tả hệ thống phải làm gì trong một tình huống là đúng định nghĩa yêu cầu chức năng, thường viết ở dạng người dùng có thể làm hoặc hệ thống phải làm. Phương án "business requirement" sai vì yêu cầu nghiệp vụ nói về mục tiêu kinh doanh, lý do làm dự án, như tăng doanh thu hay giảm chi phí, không mô tả thao tác cụ thể. Phương án "stake-holder requirement" sai vì đây là cách gọi chung cho nhu cầu của các bên liên quan ở mức cao, còn câu đã đặc tả tới hành vi cụ thể của hệ thống. Phương án "data requirement" sai vì yêu cầu dữ liệu mô tả cấu trúc, định dạng, phạm vi giá trị của dữ liệu, trong khi câu này nói về một thao tác trên dữ liệu.

Đáp án đúng: "The "then" clause of an inference simply provides a piece of knowledge, not an action to be taken". Trong phân loại quy tắc nghiệp vụ, inference (quy tắc suy diễn) và action enabler cùng có dạng nếu điều kiện thì kết quả, nhưng vế sau khác bản chất: inference tạo ra một sự thật mới, ví dụ nếu khách hàng chưa thanh toán sau 30 ngày thì tài khoản bị coi là quá hạn, còn action enabler ra lệnh hệ thống làm một việc. Phương án "Inferences trigger a system action, while action enablers provide new knowledge" đảo ngược hai khái niệm. Phương án "Inferences are always quantitative, while action enablers are qualitative" sai vì loại quy tắc mang tính định lượng là computation (quy tắc tính toán), còn inference có thể hoàn toàn định tính. Phương án "Action enablers are atomic, while inferences are composite" sai vì cả hai đều là quy tắc nguyên tử trong phân loại này; quy tắc phức hợp thường được tách thành nhiều quy tắc nguyên tử.