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

Đáp án đúng: "Quality attributes describe the system's functional behaviors in terms of user interactions.". Thuộc tính chất lượng (quality attributes) là một loại yêu cầu phi chức năng, mô tả hệ thống phải tốt tới mức nào (hiệu năng, khả dụng, bảo mật, độ tin cậy) chứ không mô tả hệ thống làm gì; gán cho chúng việc mô tả hành vi chức năng là sai nên đây là phát biểu cần chọn. Phương án "Business rules are the origin of several types of software requirements" đúng: quy tắc nghiệp vụ (business rules) là chính sách, luật lệ tồn tại ngoài phần mềm, sinh ra nhiều yêu cầu nhưng bản thân không phải yêu cầu phần mềm. Phương án "describe the system's performance characteristics rather than its specific behaviors" đúng vì yêu cầu phi chức năng nói về đặc tính chất lượng, không phải hành vi cụ thể. Phương án "Functional requirements describe how the system will perform certain actions" đúng vì yêu cầu chức năng mô tả hệ thống phải làm gì trong điều kiện nhất định. Ba phát biểu này đúng nên không được chọn.

Đáp án đúng: "By reducing rework, unnecessary features, and miscommunications.". Làm lại do lỗi yêu cầu chiếm phần lớn chi phí sửa chữa, nên thực hành yêu cầu tốt như khơi gợi đúng bên liên quan, đặc tả rõ ràng, rà soát sớm và kiểm soát thay đổi giúp phát hiện lỗi khi sửa còn rẻ, tránh xây tính năng không ai dùng và giảm hiểu lầm giữa khách hàng với nhóm phát triển. Phương án "By increasing the number of features developed." sai vì làm nhiều tính năng hơn làm tăng chứ không giảm chi phí, và thường dẫn tới phình phạm vi. Phương án "By increasing the project timeline." sai vì kéo dài tiến độ đồng nghĩa tốn thêm nguồn lực. Phương án "By focusing solely on technical specifications." sai vì bỏ qua yêu cầu nghiệp vụ và yêu cầu người dùng dễ dẫn tới làm sai sản phẩm, gây làm lại tốn kém hơn.

Đá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 gồm ba ý: "Define business requirements", "Identify project stakeholders and user classes" và "Document requirements". Danh sách nhiệm vụ của người phân tích nghiệp vụ (business analyst) gồm định nghĩa yêu cầu nghiệp vụ, lập kế hoạch tiếp cận yêu cầu, xác định các bên liên quan và các user class, khơi gợi, phân tích, đặc tả và truyền đạt yêu cầu, dẫn dắt thẩm định, hỗ trợ xếp ưu tiên và quản lý yêu cầu. Ba ý được chọn khớp đúng các nhiệm vụ đó. "Lead requirements prioritization" dễ gây nhầm vì người phân tích quả thật tham gia việc xếp ưu tiên, nhưng chỗ khác biệt nằm ở chữ lead và facilitate: quyền quyết định thứ tự ưu tiên thuộc về khách hàng, product owner hay đại diện nghiệp vụ, còn người phân tích chỉ facilitate (điều phối, hỗ trợ), tức là chuẩn bị thông tin về giá trị, chi phí, rủi ro và dẫn buổi thảo luận chứ không tự dẫn dắt và quyết định thứ tự ưu tiên.

Đá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 gồm hai ý: "The business analyst primarily focuses on eliciting, analyzing, documenting, and validating the needs of the project stakeholders." và "The business analyst plays a central role in collecting and disseminating product information, while the project manager focuses on communicating project information.". Chuyên viên phân tích nghiệp vụ (business analyst) là người chịu trách nhiệm chính về yêu cầu: khơi gợi, phân tích, đặc tả, thẩm định nhu cầu các bên liên quan; họ là đầu mối thông tin về sản phẩm, còn quản lý dự án lo thông tin về dự án như tiến độ, nguồn lực, chi phí. Phương án "solely responsible for managing communication between the customer" sai vì BA là kênh chính chứ không phải duy nhất, khách hàng và nhóm phát triển vẫn trao đổi trực tiếp, nhất là trong agile. Phương án "often acts as the project manager, handling both internal and external" sai vì trong agile BA thường góp sức cho product owner hoặc nhóm, không kiêm vai trò quản lý dự án.

Đáp án đúng: "Business requirements". Tài liệu tầm nhìn và phạm vi (Vision and Scope Document) ghi tầng yêu cầu nghiệp vụ: cơ hội hay vấn đề kinh doanh, mục tiêu nghiệp vụ, chỉ số thành công, tầm nhìn sản phẩm cùng phạm vi và giới hạn của dự án. Nó được xây dựng từ yêu cầu nghiệp vụ, rồi chính nó làm khung để khơi gợi các tầng bên dưới. Phương án "User requirements" sai vì yêu cầu người dùng (mô tả việc người dùng cần làm, thường bằng use case hay user story) được ghi ở tài liệu yêu cầu người dùng và phải nằm trong phạm vi tầm nhìn đã đặt, tức là đi sau. Phương án "System requirements" sai vì yêu cầu hệ thống mô tả hệ thống gồm nhiều thành phần phần cứng và phần mềm, ở tầng chi tiết hơn nhiều. Phương án "Original requirements" không phải tên một tầng yêu cầu chuẩn trong kỹ nghệ yêu cầu.

Đáp án đúng gồm hai ý: "A context diagram visually illustrates the boundary between the system being developed and external entities that interact with it." và "The primary purpose of a context diagram is to depict the interactions between the system and external entities without detailing the internal workings of the system.". Context diagram (sơ đồ ngữ cảnh) là mô hình phạm vi: toàn bộ hệ thống được vẽ thành một khối duy nhất ở giữa, xung quanh là các thực thể ngoài như người dùng, tổ chức, hệ thống khác, nối với nó bằng các luồng dữ liệu hay điều khiển; nó cho biết cái gì nằm trong và ngoài ranh giới mà không mở hệ thống ra. Phương án "includes detailed information about the system’s internal processes and data" sai vì chi tiết tiến trình và dữ liệu bên trong thuộc các sơ đồ luồng dữ liệu mức thấp hơn. Phương án "relationship between user interfaces and system components within the boundary" sai vì sơ đồ ngữ cảnh không thể hiện thành phần bên trong ranh giới, cũng không mô hình hóa giao diện người dùng.

Đáp án đúng: "Context diagram". Sơ đồ ngữ cảnh (context diagram) là mức trừu tượng cao nhất của mô hình luồng dữ liệu: toàn bộ hệ thống được vẽ thành một tiến trình duy nhất ở giữa, xung quanh là các thực thể bên ngoài (external entity) cùng luồng dữ liệu trao đổi với chúng, nhờ đó thể hiện ranh giới và phạm vi hệ thống. "Data flow diagram" phân rã hệ thống thành các tiến trình con, kho dữ liệu và luồng dữ liệu chi tiết bên trong, nên nằm ở mức thấp hơn chứ không phải cái nhìn tổng quan. "Entity-relationship diagram" mô hình hoá dữ liệu và quan hệ giữa chúng, không thể hiện tiến trình hay thực thể ngoài. "Use case diagram" cũng ở mức cao nhưng cho thấy tác nhân và các mục tiêu người dùng đạt được qua hệ thống, không mô tả luồng dữ liệu giữa hệ thống và thực thể bên ngoài.

Đáp án đúng: "Training courses". Elicitation (khơi gợi yêu cầu) là hoạt động tìm ra yêu cầu từ bên liên quan và các nguồn khác; kỹ thuật phổ biến gồm phỏng vấn, hội thảo, nhóm tập trung, quan sát, bảng hỏi, phân tích tài liệu, phân tích giao diện hệ thống. Khoá đào tạo là để truyền kiến thức cho người học, dòng thông tin đi ngược chiều với khơi gợi, nên không phải kỹ thuật khơi gợi. "Interviews" là kỹ thuật khơi gợi cơ bản nhất, BA hỏi trực tiếp từng người hay nhóm nhỏ để hiểu nhu cầu. "Focus groups" là kỹ thuật khơi gợi, tập hợp một nhóm người dùng đại diện để lấy ý kiến về nhu cầu, sở thích, kỳ vọng với sản phẩm. "Observations" là kỹ thuật khơi gợi, BA quan sát người dùng làm việc thực tế để thấy những bước họ không kể ra khi phỏng vấn. Ba kỹ thuật này đều đúng là khơi gợi nên không được chọn trong câu hỏi phủ định.

Đáp án đúng: "To link requirements to design, development, and testing artifacts". Requirements traceability matrix (RTM, ma trận truy vết yêu cầu) là bảng ghi liên kết giữa từng yêu cầu với nguồn gốc của nó và với các sản phẩm phía sau như thiết kế, mã nguồn, ca kiểm thử; đây là công cụ của hoạt động quản lý yêu cầu, phục vụ phân tích tác động thay đổi và kiểm tra mọi yêu cầu đều được hiện thực, được kiểm thử. "To identify redundant requirements" chỉ là lợi ích phụ: nhìn ma trận có thể thấy yêu cầu trùng lặp hay không gắn mục tiêu nào, nhưng đó không phải mục tiêu chính khi lập RTM. "To finalize the system budget" sai vì ngân sách thuộc quản lý dự án, ma trận truy vết không chốt chi phí. "To prioritize stakeholder meetings" sai vì việc sắp lịch họp với các bên liên quan không liên quan tới truy vết yêu cầu.

Đáp án đúng: "Data Definitions (DD)". Định nghĩa dữ liệu (data definitions) mô tả đặc điểm và cấu trúc của dữ liệu hệ thống xử lý: tên phần tử, kiểu, độ dài, định dạng, miền giá trị, thành phần của cấu trúc phức hợp; chúng thường được gom trong từ điển dữ liệu (data dictionary) và gắn với mô hình dữ liệu như ERD. Phương án "Process Descriptions (PD)" sai vì mô tả quy trình nói về các bước xử lý, biến đổi dữ liệu chứ không nói cấu trúc của dữ liệu. Phương án "Business Rules (BR)" sai vì quy tắc nghiệp vụ là chính sách, ràng buộc, công thức tính của tổ chức; chúng có thể ràng buộc giá trị dữ liệu nhưng không định nghĩa cấu trúc dữ liệu. Phương án "Quality Attributes (QA)" sai vì thuộc tính chất lượng mô tả hệ thống tốt tới mức nào khi vận hành như hiệu năng, bảo mật, không phải đặc điểm dữ liệu.

Đáp án đúng: "To gather structured information from a large number of users". Questionnaire (bảng câu hỏi khảo sát) là kỹ thuật khơi gợi yêu cầu cho phép thu thập dữ liệu có cấu trúc từ rất nhiều người với chi phí thấp, hữu ích khi người dùng đông, phân tán về địa lý hoặc khi cần số liệu thống kê về thói quen, mức hài lòng; điểm yếu là khó hỏi sâu nên thường kết hợp với phỏng vấn hay workshop. Phương án "To create user stories" sai vì user story được viết từ thông tin đã khơi gợi, khảo sát chỉ là một nguồn đầu vào. Phương án "To define technical specifications" sai vì đặc tả kỹ thuật là việc của thiết kế, người trả lời khảo sát không định nghĩa nó. Phương án "To train users on the system" sai vì đào tạo người dùng là hoạt động triển khai, không thuộc khơi gợi yêu cầu.

Đáp án đúng: "A verb followed by an object". Tên use case nên thể hiện mục tiêu mà tác nhân muốn đạt, viết dạng động từ hành động cộng tân ngữ, ví dụ Request a Chemical hay Print Boarding Pass, để đọc tên là hiểu ngay người dùng làm gì với hệ thống. "A noun followed by a verb" sai trật tự, kiểu đặt tên này khiến tên giống mô tả sự vật thay vì hành động hướng tới mục tiêu. "A random combination of words" rõ ràng không có giá trị vì tên use case phải nhất quán và dễ hiểu cho mọi bên liên quan. "A descriptive phrase" nghe hợp lý nhưng quá chung chung: một cụm mô tả có thể là danh từ hay tên chức năng như Chemical Management, không nói rõ hành động và mục tiêu cụ thể, nên không phải quy ước đặt tên được khuyến nghị.

Đá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: "Include relationship". Quan hệ include dùng khi một chuỗi bước chung được nhiều ca sử dụng cần tới; phần chung được tách thành ca sử dụng riêng, và các ca sử dụng gốc luôn gọi nó. Kiểm tra tín dụng ở đây là bước bắt buộc của cả gửi yêu cầu vay lẫn đề nghị hạn mức tín dụng, nên hai ca sử dụng này include ca sử dụng Perform credit check. "Extend relationship" sai vì extend dùng cho hành vi tuỳ chọn hoặc chỉ xảy ra khi có điều kiện, bổ sung vào ca sử dụng gốc tại một điểm mở rộng; ca gốc vẫn hoàn chỉnh khi không có phần mở rộng, trong khi kiểm tra tín dụng là phần không thể thiếu. "Generalization relationship" sai vì khái quát hoá diễn tả quan hệ cha con, ca sử dụng con là một dạng đặc biệt của ca cha và kế thừa hành vi; kiểm tra tín dụng không phải dạng tổng quát của gửi yêu cầu vay hay đề nghị hạn mức, mà chỉ là một bước dùng chung.

Đáp án đúng: "include". Quan hệ include nghĩa là ca sử dụng cơ sở luôn gọi tới ca sử dụng được bao gồm như một hành vi con dùng chung; extend nghĩa là ca mở rộng chỉ chen vào ca cơ sở khi một điều kiện tuỳ chọn xảy ra. Ở đây chọn include với lập luận thanh toán hoá đơn luôn cần bước viết séc như một hành vi con dùng chung. Cần nói thẳng đây là câu còn tranh cãi: câu hỏi không mô tả nội dung hai ca sử dụng, tên Play a bill ở đây cần hiểu là Pay a bill (thanh toán hoá đơn), và nếu viết séc chỉ là một trong nhiều cách thanh toán tuỳ chọn thì quan hệ hợp lý lại là "extend"; đáp án được chốt vẫn là include. "generalization" không khớp vì quan hệ tổng quát hoá dùng khi một ca là phiên bản chuyên biệt của ca kia, mà viết séc là một bước trong việc trả tiền chứ không phải một kiểu thanh toán hoá đơn.

Đáp án đúng gồm ba ý: "It allows us to refer to specific requirements in a change request, modification history, cross-reference, or requirements traceability matrix.", "It enables reusing the requirements in multiple projects." và "It facilitates collaboration between team members when they’re discussing requirements.". Gán nhãn định danh duy nhất (unique identifier) cho từng yêu cầu trong SRS là thực hành của đặc tả và quản lý yêu cầu: có nhãn ổn định thì yêu cầu được trỏ tới chính xác trong yêu cầu thay đổi, lịch sử sửa đổi, tham chiếu chéo và ma trận truy vết; được gọi lại khi tái sử dụng ở dự án khác; và khi thảo luận mọi người nói cùng một yêu cầu mà không phải chép lại cả câu. Phương án "It makes the SRS look more professional." sai vì vẻ chuyên nghiệp không phải lý do kỹ thuật; nhãn có giá trị vì giúp truy vết và quản lý thay đổi, không phải để trang trí tài liệu.

Đáp án đúng: "Logical data model". Theo khuôn SRS (đặc tả yêu cầu phần mềm) chuẩn, mục Data requirements (yêu cầu dữ liệu) là phần cố định chứa logical data model (mô hình dữ liệu logic) và từ điển dữ liệu, nên đây là thành phần chắc chắn thuộc SRS. Có tài liệu ôn tập chọn "Usecase descripions", và mô tả ca sử dụng đôi khi được đính kèm SRS, nhưng theo cách tách tài liệu chuẩn chúng thường nằm ở tài liệu yêu cầu người dùng, còn SRS mô tả các yêu cầu chức năng dẫn xuất từ đó; vì vậy mô hình dữ liệu logic mới là mục cố định của SRS. Phương án "Vision statement", "Succes metrics" và "Limitations and exclusions" đều thuộc tài liệu tầm nhìn và phạm vi (vision and scope document): tuyên bố tầm nhìn nêu sản phẩm hướng tới đâu, chỉ số thành công đo mục tiêu kinh doanh, còn giới hạn và loại trừ xác định những gì không làm.