Câu hỏi: SWR302 Software Requirements – Bộ ôn tập cuối kỳ số 9

Đáp án đúng: "Inconsistent behavior is implemented". Yêu cầu mơ hồ (ambiguous) cho phép nhiều cách hiểu; khi các nhà phát triển khác nhau hiện thực theo cách hiểu riêng của mình, các phần của hệ thống sẽ hành xử không nhất quán với nhau và có thể không khớp mong đợi của khách hàng, buộc phải làm lại. Vì thế yêu cầu tốt phải rõ ràng, chỉ có một cách hiểu. "The software works better" sai vì diễn giải khác nhau chỉ sinh lỗi và mâu thuẫn, không làm phần mềm tốt hơn. "Developers work faster" sai vì có thể nhanh lúc đầu nhưng sau đó tốn công sửa, tổng thời gian tăng. "Ambiguities go unnoticed" mô tả điều kiện dẫn tới vấn đề, tức mơ hồ không được phát hiện khi rà soát, chứ không phải hậu quả khi nhà phát triển đã hiện thực theo nhiều cách khác nhau.

Đá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: "Model the application environment". Trong các thực hành tốt của kỹ nghệ yêu cầu, nhóm khơi gợi (elicitation) gồm xác định tầm nhìn và phạm vi, phỏng vấn, tổ chức workshop, quan sát người dùng; còn mô hình hoá môi trường ứng dụng, như vẽ sơ đồ ngữ cảnh hay ecosystem map, được xếp vào nhóm phân tích (analysis). Cần nói thẳng: một số bộ đáp án lưu hành chọn "Define product vision and project scope", nhưng việc định nghĩa tầm nhìn và phạm vi nằm ngay trong danh sách hoạt động khơi gợi vì nó xác lập mục tiêu và ranh giới để thu thập yêu cầu, nên đó không phải ngoại lệ. "Hold elicitation interviews" là hoạt động khơi gợi điển hình, trao đổi trực tiếp với bên liên quan. "Observe users performing their jobs" cũng là khơi gợi, giúp phát hiện nhu cầu ngầm mà người dùng không tự nói ra.

Đá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.

Đáp án đúng gồm ba ý: "Literacy skills for effectively interpreting written material and communicating requirements.", "Facilitation skills to manage group discussions and ensure effective participation from all stakeholders." và "Analytical skills to break down complex problems and identify feasible solutions.". Chuyên viên phân tích nghiệp vụ (business analyst) làm việc chủ yếu với con người và thông tin: phải đọc hiểu tài liệu, viết yêu cầu rõ ràng; phải điều phối (facilitate) các buổi khơi gợi để mọi bên được nói và đi tới đồng thuận; và phải phân tích, tách vấn đề phức tạp thành phần nhỏ, tìm khoảng trống và giải pháp khả thi. Phương án "Technical skills to ensure the analyst can implement the software" sai vì BA không có nhiệm vụ lập trình hệ thống; hiểu biết kỹ thuật có ích để trao đổi với lập trình viên và đánh giá tính khả thi, nhưng khả năng tự cài đặt phần mềm không phải kỹ năng cốt lõi của vai trò này.

Đá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: "Through an apprenticeship program with mentoring". Nhiều người trở thành business analyst (chuyên viên phân tích nghiệp vụ) từ vai trò khác như người dùng nghiệp vụ, nhà phát triển, kiểm thử viên; cách chuyển đổi hiệu quả là học việc có người hướng dẫn, làm cùng một người phân tích giàu kinh nghiệm để rèn kỹ năng khơi gợi, phân tích, viết đặc tả và giao tiếp trên dự án thật. Phương án "By studying software development exclusively" sai vì vai trò này cần kiến thức nghiệp vụ và kỹ năng giao tiếp, chứ không chỉ kỹ thuật lập trình. Phương án "By focusing only on user interface design skills" sai vì thiết kế giao diện chỉ là một mảng nhỏ so với phạm vi công việc của người phân tích. Phương án "By avoiding involvement in diverse business activities" sai vì tiếp xúc rộng với hoạt động nghiệp vụ là nền tảng để hiểu nhu cầu của tổ chức.

Đáp án đúng gồm ba ý: "Business Requirements", "Scope and Limitations" và "Business Context". Tài liệu tầm nhìn và phạm vi (vision and scope document) thuộc tầng yêu cầu kinh doanh, khuôn điển hình có ba phần lớn: yêu cầu kinh doanh gồm bối cảnh, cơ hội, mục tiêu kinh doanh, chỉ số thành công, tầm nhìn, rủi ro; phạm vi và giới hạn nêu các tính năng chính, phạm vi từng bản phát hành và những gì không làm; bối cảnh kinh doanh mô tả bên liên quan, ưu tiên dự án và môi trường triển khai. "Specific Requirements" là phần của khuôn đặc tả yêu cầu phần mềm (SRS), nơi ghi chi tiết yêu cầu chức năng và phi chức năng, không thuộc tài liệu tầm nhìn và phạm vi. "General Description" là phần mô tả tổng quan sản phẩm trong khuôn SRS, cũng không phải một mục của tài liệu tầm nhìn và phạm vi.

Đáp án đúng: "rectangles, lines/arcs with arrows". Trong sơ đồ ngữ cảnh (context diagram), hệ thống là một hình tròn duy nhất ở giữa, các thực thể bên ngoài như người dùng, tổ chức, hệ thống khác vẽ bằng hình chữ nhật, còn luồng dữ liệu giữa thực thể và hệ thống vẽ bằng đường hay cung có mũi tên chỉ chiều dữ liệu đi, kèm tên dữ liệu. Ký hiệu này kế thừa từ sơ đồ luồng dữ liệu cấp cao nhất. "ovals, lines/arcs with arrows" sai ở vế đầu, vì hình tròn hay bầu dục dùng cho chính hệ thống hoặc tiến trình, không dùng cho thực thể bên ngoài. "ovals, lines/arcs without arrows" sai cả hai vế: thực thể ngoài không vẽ bầu dục, và luồng dữ liệu phải có mũi tên vì chiều đi của dữ liệu là thông tin quan trọng của sơ đồ. "triangles, lines/arcs with arrows" sai vì hình tam giác không phải ký hiệu nào trong sơ đồ ngữ cảnh.

Đáp án đúng: "Prevent scope creep and ensure project focus". Tài liệu phạm vi (vision and scope) vạch ranh giới giữa cái gì nằm trong và cái gì nằm ngoài dự án hay đợt phát hành; nó là chuẩn để đánh giá mỗi yêu cầu mới có thuộc phạm vi không, từ đó ngăn scope creep (phạm vi phình ra mất kiểm soát) và giữ nhóm tập trung vào mục tiêu nghiệp vụ. "Limit stakeholder involvement" sai vì phạm vi rõ ràng không nhằm hạn chế sự tham gia của các bên liên quan, chính họ góp phần thống nhất phạm vi. "Speed up the development process" chỉ là hệ quả gián tiếp nếu có, mục đích chính của việc định nghĩa phạm vi là kiểm soát nội dung chứ không phải tốc độ. "Avoid addressing project risks" sai vì tài liệu phạm vi thường còn nêu giả định, ràng buộc và rủi ro, chứ không né tránh chúng.

Đáp án đúng gồm ba ý: "Users repeat issues they already covered in previous discussions.", "Suggested new features, user requirements, or functional requirements are all deemed to be out of scope." và "Proposed new requirements are all low priority.". Không có thời điểm tuyệt đối cho biết khơi gợi (elicitation) đã xong, nên người phân tích dựa vào tín hiệu: người dùng chỉ nhắc lại điều đã nói, ý mới đều nằm ngoài phạm vi, yêu cầu mới đề xuất đều ưu tiên thấp; tất cả cho thấy nguồn yêu cầu mới có giá trị đã cạn. Phương án "Developers and testers who review the requirements for an area raise many questions." sai vì đây là tín hiệu ngược lại: nhiều câu hỏi chứng tỏ yêu cầu ở mảng đó còn mơ hồ hoặc thiếu, cần khơi gợi tiếp; tín hiệu hoàn tất là khi lập trình viên và kiểm thử viên đọc yêu cầu mà chỉ còn ít câu hỏi.

Đáp án đúng: "Identifying and engaging the right stakeholders". Khơi gợi yêu cầu (elicitation) là thu thập yêu cầu từ con người và tài liệu, nên trước khi chọn kỹ thuật phỏng vấn, workshop hay quan sát, người phân tích phải xác định ai là bên liên quan, ai đại diện cho từng lớp người dùng và mời họ tham gia; thiếu đúng người thì yêu cầu sẽ thiếu hoặc sai ngay từ gốc. Phương án "Designing the user interface" sai vì thiết kế giao diện diễn ra sau khi đã hiểu yêu cầu. Phương án "Building the prototype" sai vì prototype có thể dùng làm kỹ thuật khơi gợi nhưng chỉ dựng được khi đã có hiểu biết ban đầu từ bên liên quan, không phải bước đầu tiên. Phương án "Writing test scripts" thuộc khâu kiểm thử, cần yêu cầu đã được đặc tả.

Đá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: "Drafting straw man models and questions beforehand". Khi chuẩn bị một buổi khơi gợi có điều phối (facilitated elicitation) như workshop, người điều phối nên soạn trước mô hình nháp (straw man) và danh sách câu hỏi, vì người tham gia thường góp ý và sửa một bản có sẵn dễ hơn nhiều so với tự tạo từ trang trắng; nhờ vậy buổi làm việc tập trung và hiệu quả. "Finalizing all requirements before the session." đi ngược mục đích, buổi khơi gợi là để thu thập và làm rõ yêu cầu chứ không phải xác nhận thứ đã chốt. "Inviting only senior stakeholders." sai vì thiếu người dùng thực, những người hiểu công việc hằng ngày, nên dễ bỏ sót nhu cầu thật. "Avoiding any pre-session communication" sai vì cần gửi trước mục tiêu, chương trình và tài liệu để người tham gia chuẩn bị.

Đáp án đúng gồm hai ý: "Actors" và "Name". Một đặc tả ca sử dụng tối thiểu phải có định danh, tên ca sử dụng, thường là động từ cộng danh từ nói lên mục tiêu, và tác nhân (actor) khởi động hoặc tham gia tương tác; thiếu tên thì không gọi được, thiếu tác nhân thì không biết ai hưởng lợi, nên ca sử dụng không còn ý nghĩa. "Pre-condition" là chỗ hay gây tranh cãi: có người cho rằng tiền điều kiện cũng bắt buộc vì mẫu đặc tả nào cũng có ô này, nhưng thực ra nó nên có chứ không bắt buộc; nhiều ca sử dụng không cần điều kiện gì trước khi bắt đầu và ô đó được để trống, nên nó không thuộc phần bắt buộc. "Post-condition" tương tự, hậu điều kiện mô tả trạng thái hệ thống sau khi ca sử dụng hoàn tất, rất hữu ích cho kiểm thử và nên được viết, nhưng có thể bỏ trống khi chưa đủ thông tin mà ca sử dụng vẫn hợp lệ, nên cũng không bắt buộc.

Đáp án đúng: "To provide concise, actionable descriptions of features from the user’s perspective". User story là mô tả ngắn một nhu cầu theo góc nhìn người dùng, thường dạng là một vai trò, tôi muốn làm gì để đạt lợi ích gì, kèm tiêu chí chấp nhận; trong agile chúng là đơn vị yêu cầu được đưa vào backlog, ước lượng, xếp ưu tiên và làm rõ dần qua trao đổi. Phương án "To replace the Vision and Scope document" sai vì tầm nhìn và phạm vi ở tầng yêu cầu nghiệp vụ vẫn cần trong agile để định hướng, story ở tầng người dùng nằm bên dưới. Phương án "To prioritize non-functional requirements" sai vì story chủ yếu diễn đạt nhu cầu chức năng, còn ưu tiên là việc làm trên backlog. Phương án "To finalize the system's architecture" sai vì kiến trúc là quyết định thiết kế, user story không chốt kiến trúc.

Đáp án đúng: "Use case diagrams show the graphical user interface that needs to be implemented.". Câu hỏi tìm phát biểu không đúng về mục đích của use case diagram (sơ đồ ca sử dụng): sơ đồ này chỉ thể hiện tác nhân, ca sử dụng và quan hệ giữa chúng ở mức khái niệm, hoàn toàn không mô tả màn hình hay giao diện đồ họa cần xây, vì giao diện thuộc thiết kế. Phát biểu "both behavior diagrams because they describe the behavior of the system" đúng theo UML, vì sơ đồ ca sử dụng mô tả hành vi và có thể được xem như một dạng đặc biệt của sơ đồ lớp với bộ phân loại là tác nhân và ca sử dụng, nên không được chọn. Phát biểu "usually referred to as behavior diagrams used to describe a set of actions" cũng đúng, nêu mục đích mô tả tập hành động hệ thống thực hiện cùng người dùng bên ngoài. Phát biểu "A use case describes a sequence of interactions between a system and an external actor" là định nghĩa chuẩn của ca sử dụng, nên cũng không phải đáp án.

Đáp án đúng: "To identify and address missing or unclear requirements". Một tài liệu đặc tả yêu cầu phần mềm (SRS) tốt phải đầy đủ; xử lý sự thiếu hoàn chỉnh nghĩa là tìm ra yêu cầu còn thiếu hoặc chưa rõ, đánh dấu chỗ chưa biết bằng TBD, giao người chịu trách nhiệm và giải quyết trước khi xây dựng, vì yêu cầu thiếu là nguồn lỗi tốn kém nhất. "To eliminate unnecessary requirements" là việc cắt bỏ yêu cầu ngoài phạm vi hoặc không mang giá trị, ngược hướng với bổ sung chỗ thiếu. "To finalize the system design" sai vì thiết kế là hoạt động sau đặc tả, không phải mục đích của việc rà soát độ đầy đủ yêu cầu. "To prepare for testing and validation" là lợi ích gián tiếp, vì SRS đầy đủ giúp viết kiểm thử tốt hơn, nhưng không phải mục đích trực tiếp của việc xử lý thiếu sót.

Đá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.