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

Đáp án đúng: "It is a language with a rich set of keywords that permits precise statements of quality attributes and other project goals.". Planguage là ngôn ngữ đặc tả do Tom Gilb đề xuất, dùng các từ khoá như TAG, GIST, SCALE, METER, MUST, PLAN, WISH để viết thuộc tính chất lượng sao cho đo được: chỉ rõ đại lượng đo, cách đo, mức tối thiểu chấp nhận và mức mong muốn. Nó giúp tránh các câu mơ hồ kiểu "hệ thống phải nhanh". "It is a programming language." sai vì Planguage không biên dịch hay chạy được, nó chỉ dùng để viết yêu cầu. "It is a planning language used in project management." sai vì dù tên gợi chữ planning, nó không dùng để lập lịch hay phân bổ nguồn lực mà để đặc tả mục tiêu định lượng. "It is a language to express non functional requirements." chỉ đúng một phần: Planguage hay được dùng cho yêu cầu phi chức năng, nhưng phát biểu này thiếu điểm cốt lõi là bộ từ khoá phong phú cho phép viết chính xác, và nó còn áp dụng cho các mục tiêu dự án khác chứ không riêng yêu cầu phi chức năng, nên không phải mô tả đầy đủ nhất.

Đáp án đúng: "To reduce the effort and cost of requirements development". Tái sử dụng yêu cầu (requirements reuse) là lấy lại những yêu cầu đã được viết, rà soát và kiểm chứng ở dự án trước hay ở thành phần dùng chung, nhờ đó giảm công sức và chi phí cho các hoạt động khơi gợi, phân tích, đặc tả và thẩm định; lợi ích kéo theo là tính nhất quán và chất lượng cao hơn. "To improve system security" sai vì bảo mật không phải mục tiêu chính của tái sử dụng, chỉ khi tái dùng đúng yêu cầu bảo mật đã kiểm chứng thì mới có ích gián tiếp. "To validate requirements more efficiently" chỉ là lợi ích phụ: yêu cầu tái dùng vẫn phải được thẩm định trong bối cảnh mới. "To develop new requirements faster" dễ gây nhầm nhưng tái sử dụng không sinh ra yêu cầu mới, nó dùng lại yêu cầu có sẵn, còn tốc độ là hệ quả của việc giảm công sức.

Đáp án đúng: "Written requirements.". Bản mẫu (prototype) giúp khơi gợi và thẩm định yêu cầu bằng cách cho người dùng nhìn và thử một phần hệ thống, nhưng nó không ghi lại được các chi tiết ẩn như quy tắc nghiệp vụ, điều kiện ngoại lệ, yêu cầu chất lượng hay logic phía sau màn hình; vì vậy bản mẫu chỉ bổ sung chứ không thay thế yêu cầu viết thành văn bản. Phương án "Multiple iterations." không phải thứ bản mẫu thay thế, mà ngược lại việc làm bản mẫu thường cần nhiều vòng lặp đánh giá và chỉnh sửa. Phương án "Plausible data." là lời khuyên khi làm bản mẫu: dùng dữ liệu hợp lý, giống thật để người đánh giá không bị phân tâm, chứ không phải thứ bị thay thế. Phương án "The purpose of the prototype" là điều cần xác định rõ trước khi làm bản mẫu (thăm dò hay tiến hoá, bỏ đi hay giữ lại), bản mẫu không thể thay mục đích của chính nó.

Đáp án đúng: "Stakeholders stuffing in more features to satisfy every interest, risking the project collapsing under its own weight.". Scope creep (phình phạm vi) là khi yêu cầu mới liên tục được thêm vào sau khi phạm vi đã thống nhất; khi không có quy trình kiểm soát thay đổi (change control) để đánh giá tác động và quyết định nhận hay từ chối, các bên liên quan cứ nhồi tính năng để chiều mọi mong muốn, khiến chi phí, tiến độ và chất lượng vỡ dần cho tới khi dự án sụp vì chính khối lượng của nó. Phương án "Adjusting scope in a controlled way to optimize cost." sai vì điều chỉnh có kiểm soát chính là quản lý phạm vi đúng cách, ngược với chữ uncontrolled. Phương án "Cutting scope to meet a deadline." là thu hẹp phạm vi, không phải phình ra. Phương án "Improving quality without changing scope." không đụng tới phạm vi nên không thể là scope creep. Phương án "Moving part of the scope to a later phase as planned." là hoãn tính năng sang bản phát hành sau theo kế hoạch, một kỹ thuật hợp lệ để giữ phạm vi trong tầm kiểm soát.

Đáp án đúng: "It helps in delivering the most critical or valuable functionality as early as possible, ensuring maximum business value within project constraints.". Trong dự án agile, backlog sản phẩm được sắp ưu tiên liên tục để mỗi vòng lặp (iteration) giao phần có giá trị cao nhất trước; khi kỳ vọng của khách hàng cao mà thời gian ngắn, ưu tiên hoá (prioritization) là cách quyết định làm gì trước, hoãn gì, để giá trị kinh doanh đạt tối đa trong giới hạn thời gian, ngân sách và nhân lực. Phương án nói việc ưu tiên giúp quản lý dự án làm "without customer input, focusing solely on cost and efficiency" sai vì ưu tiên hoá cần khách hàng hoặc product owner tham gia đánh giá giá trị, không thể chỉ dựa vào chi phí. Phương án cho rằng ưu tiên để bỏ bớt tính năng và chỉ đảm bảo "only critical bugs are fixed before release" sai vì ưu tiên hoá áp cho mọi hạng mục trong backlog, mục đích là giao giá trị chứ không phải chỉ sửa lỗi nghiêm trọng. Phương án cho quản lý dự án "choose which requirements to ignore" chỉ theo ngân sách và nhân sự sai vì ưu tiên không phải đơn phương gạt bỏ yêu cầu mà là sắp thứ tự cùng các bên liên quan, cân nhắc giá trị, chi phí và rủi ro.

Đáp án đúng gồm hai ý: "In the waterfall life cycle, most of the requirements development effort is concentrated at the beginning of the project." và "Agile and incremental development projects allocate requirements development effort throughout the project, with small but frequent efforts.". Cách phân bổ công sức phát triển yêu cầu phụ thuộc vòng đời: mô hình thác nước dồn phần lớn việc khơi gợi, phân tích, đặc tả và thẩm định vào đầu dự án rồi mới thiết kế và xây dựng; dự án lặp, tăng dần hay agile làm một ít yêu cầu đủ cho từng vòng lặp, lặp lại nhiều lần suốt dự án. "Iterative and phased life cycles involve gathering and refining requirements only once at the start of the project." sai vì đặc trưng của vòng đời lặp và phân giai đoạn là mỗi vòng hay mỗi giai đoạn lại thu thập và tinh chỉnh yêu cầu cho phần sắp làm, không phải một lần duy nhất. "Regardless of the life cycle, no additional requirements work is needed once the initial requirements phase is complete." sai vì ở mọi vòng đời yêu cầu vẫn thay đổi và phải được làm rõ, quản lý thay đổi, cập nhật suốt dự án, kể cả thác nước.

Đáp án đúng: "Consistency, ensuring that requirements do not conflict with other requirements or higher-level business, user, or system requirements.". Ngoài đặc tính của từng yêu cầu riêng lẻ, cả tập yêu cầu còn phải có bốn đặc tính: complete (đầy đủ), consistent (nhất quán), modifiable (sửa được) và traceable (truy vết được). Định nghĩa nhất quán trong đáp án là đúng: yêu cầu không mâu thuẫn nhau và không mâu thuẫn với yêu cầu nghiệp vụ, yêu cầu người dùng hay yêu cầu hệ thống ở tầng trên. "Completeness, meaning it is acceptable if some necessary information is absent as long as the core requirements are documented." sai vì đầy đủ nghĩa là không thiếu thông tin cần thiết, chỗ chưa biết phải đánh dấu TBD. "Modifiability, which allows changes to be made without maintaining a history of changes or considering dependencies among requirements" sai vì sửa được đòi hỏi giữ lịch sử thay đổi và nắm quan hệ giữa các yêu cầu. "Traceability, where requirements should be loosely linked and not necessarily connected to their origin or to derived elements" sai vì truy vết đòi hỏi nối mỗi yêu cầu ngược về nguồn gốc và xuôi tới thiết kế, mã, test.

Đáp án đúng: "To track the relationship between requirements and other project artifacts". Ma trận truy vết yêu cầu (Requirements Traceability Matrix) là công cụ của quản lý yêu cầu, ghi các liên kết xuôi và ngược giữa từng yêu cầu với nguồn gốc của nó (mục tiêu nghiệp vụ, use case) và với các sản phẩm phía sau như thiết kế, mã, ca kiểm thử. Nhờ đó nhóm phân tích được tác động khi có thay đổi và kiểm tra không yêu cầu nào bị bỏ sót. Phương án "To trace the origin of software bugs" sai vì truy nguyên lỗi là việc của gỡ lỗi và quản lý lỗi, dù RTM có thể giúp tìm yêu cầu liên quan. Phương án "To document project milestones" sai vì mốc tiến độ thuộc kế hoạch dự án. Phương án "To manage project budgets" sai vì ngân sách thuộc quản lý dự án, không phải mục đích của ma trận truy vết.

Đáp án đúng: "70-85%". Số liệu thường được trích dẫn trong kỹ nghệ yêu cầu cho thấy làm lại (rework) chiếm một phần lớn chi phí phát triển, và trong phần làm lại đó, khoảng 70 tới 85 phần trăm bắt nguồn từ lỗi yêu cầu như thiếu, sai, mơ hồ hay mâu thuẫn. Lý do là lỗi yêu cầu được phát hiện càng muộn thì càng phải sửa lan qua thiết kế, mã, kiểm thử và tài liệu, nên đầu tư vào khơi gợi, đặc tả và thẩm định tốt mang lại lợi ích lớn. Phương án "10-30%" quá thấp, đánh giá thấp vai trò của yêu cầu trong chi phí làm lại. Phương án "30-50%" dễ gây nhầm vì đó gần với tỷ lệ mà làm lại chiếm trong tổng chi phí phát triển, chứ không phải tỷ lệ làm lại do lỗi yêu cầu. Phương án "90-100%" quá cao vì lỗi thiết kế, lỗi lập trình và lỗi môi trường cũng gây làm lại.

Đáp án đúng: "Collaborate with multiple business analysts and product champions to gather comprehensive requirements.". Với dự án phức tạp, một product owner khó nắm hết nhu cầu của mọi nhóm người dùng, nên cách làm được khuyến nghị là chia sẻ công việc khơi gợi yêu cầu: nhiều chuyên viên phân tích nghiệp vụ (business analyst) cùng các product champion, tức người đại diện cho từng lớp người dùng (user class), thu thập và làm rõ yêu cầu, còn product owner vẫn giữ quyền ra quyết định và ưu tiên. "Replace the product owner with a more knowledgeable individual." không giải quyết gốc vấn đề vì độ phức tạp vượt khả năng của bất kỳ một cá nhân nào. "Simplify the project to reduce complexity." là cắt phạm vi, chỉ hợp lý khi phía nghiệp vụ đồng ý thu hẹp mục tiêu, còn câu hỏi là làm sao hiểu đủ yêu cầu. "Delegate all decision-making to the development team." khiến yêu cầu do người không đại diện cho người dùng quyết định, dễ làm sai nhu cầu thật.

Đáp án đúng: "The project risks significant delays and cost overruns". Đạt thoả thuận về yêu cầu (requirements agreement) mà chưa thật sự rõ ràng nghĩa là các bên ký vào những điều họ hiểu khác nhau; khi mơ hồ lộ ra ở thiết kế, xây dựng hay kiểm thử, đội phải làm lại, và chi phí sửa lỗi yêu cầu càng về sau càng đắt. Đó là lý do yêu cầu thiếu rõ ràng là nguồn rủi ro lớn về tiến độ và chi phí. "The developers will proceed with an ambiguous understanding" mô tả một hiện tượng có thể xảy ra, nhưng đó là nguyên nhân trung gian chứ không phải hệ quả mà câu hỏi nhắm tới; hậu quả thực sự của việc làm theo cách hiểu mơ hồ chính là trễ hạn và vượt ngân sách. "Customer feedback will be ignored" sai vì sự mơ hồ không khiến phản hồi bị bỏ qua; ngược lại thường dẫn tới nhiều phản hồi và yêu cầu sửa. "The project will be automatically canceled" sai vì không có cơ chế huỷ tự động nào; dự án vẫn chạy, chỉ là với rủi ro cao hơn.

Đáp án đúng: "design". Phát triển yêu cầu (requirements development) gồm bốn hoạt động: elicitation (khơi gợi, thu thập nhu cầu từ các bên liên quan), analysis (phân tích, làm mịn, mô hình hoá và xếp ưu tiên), specification hay documentation (đặc tả, ghi yêu cầu thành văn bản) và validation (thẩm định, kiểm tra yêu cầu đúng nhu cầu thật). Thiết kế là hoạt động phía sau, biến yêu cầu thành giải pháp kỹ thuật, nên không phải một bước của phát triển yêu cầu. "elicitation" là bước đầu tiên, nơi người phân tích nghiệp vụ phỏng vấn, tổ chức workshop, quan sát để thu thập nhu cầu. "analysis" là bước tách, làm rõ, mô hình hoá yêu cầu và phát hiện xung đột. "validation" là bước xác nhận yêu cầu đúng và đủ trước khi xây dựng. "documentation" chính là bước đặc tả, ghi yêu cầu vào SRS hay backlog, nên vẫn thuộc phát triển yêu cầu.

Đá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: "Ensuring clarity, consistency, and avoiding ambiguities". Hệ thống phức tạp có rất nhiều yêu cầu đan xen giữa nhiều nhóm người dùng và hệ thống con, nên thách thức chính của việc đặc tả là viết sao cho mỗi yêu cầu rõ ràng, các yêu cầu không mâu thuẫn nhau và không có cách hiểu kép; đây là các đặc tính chất lượng của một bộ yêu cầu tốt mà hoạt động đặc tả và thẩm định phải bảo đảm. Phương án "Eliminating low-priority requirements" sai vì yêu cầu ưu tiên thấp vẫn được ghi lại và có thể làm ở bản sau; ưu tiên hóa không phải thách thức của việc viết tài liệu. Phương án "Skipping stakeholder validation" là một thói quen xấu, không phải thách thức cần vượt qua. Phương án "Focusing only on functional needs" sai vì hệ thống phức tạp càng cần đặc tả cả yêu cầu phi chức năng như hiệu năng, bảo mật, độ tin cậy.

Đáp án đúng: "The ultimate product that will achieve the business objectives and what portion of the ultimate product vision the current project or development iteration will address". Tầm nhìn sản phẩm (product vision) mô tả sản phẩm cuối cùng sẽ giúp đạt mục tiêu kinh doanh, còn phạm vi dự án (project scope) xác định phần nào của tầm nhìn đó được dự án hoặc vòng lặp hiện tại thực hiện; cả hai thuộc tầng yêu cầu kinh doanh và được ghi trong tài liệu tầm nhìn và phạm vi. "Function, performance and constraints of a computer-based system" là nội dung của đặc tả hệ thống, chi tiết hơn và nằm ở tầng yêu cầu hệ thống. Phương án về "indicators that stakeholders will use to define and measure success" kèm phát biểu được coi là đúng khi chưa có bằng chứng gộp hai khái niệm khác là chỉ số thành công (success metrics) và giả định (assumption); chúng cũng xuất hiện trong phần yêu cầu kinh doanh nhưng không phải định nghĩa của tầm nhìn và phạm vi. "The benefits the business" chỉ nói tới lợi ích kinh doanh, tức mục tiêu mà tầm nhìn hướng tới, không phải bản thân tầm nhìn và phạm vi.

Đáp án đúng: "It ensures that high-value requirements are implemented first.". Khi các bên liên quan đưa ra yêu cầu xung đột hoặc vượt quá nguồn lực, ưu tiên hoá (prioritization) là hoạt động phân tích giúp quyết định cái gì làm trước dựa trên giá trị kinh doanh, chi phí, rủi ro; nhờ đó xung đột được giải quyết bằng tiêu chí chung thay vì theo ai nói to hơn, và phần giá trị cao nhất được giao sớm. "It eliminates non-functional requirements from consideration." sai vì ưu tiên hoá áp dụng cho cả yêu cầu phi chức năng; thuộc tính chất lượng như bảo mật hay hiệu năng có thể được xếp ưu tiên rất cao. "It finalizes all requirements before the design phase." sai vì xếp ưu tiên không chốt cứng toàn bộ yêu cầu; danh sách ưu tiên còn được xem lại khi có thay đổi. "It focuses on budget over stakeholder needs" sai vì ưu tiên hoá cân nhắc chi phí cùng với giá trị cho bên liên quan, không đặt ngân sách lên trên nhu cầu của họ.

Đáp án đúng: "The steps involved in a process and the roles or departments responsible for each step". Swimlane diagram (sơ đồ làn bơi) là một dạng sơ đồ quy trình chia thành các làn ngang hoặc dọc, mỗi làn ứng với một vai trò, bộ phận hay hệ thống; các bước được đặt vào làn của bên thực hiện nên người đọc thấy cả trình tự công việc lẫn ai chịu trách nhiệm. Trong kỹ nghệ yêu cầu nó dùng ở bước phân tích để mô hình hoá quy trình nghiệp vụ và tìm yêu cầu còn thiếu. "The system's data flow" là nội dung của data flow diagram, vốn không có khái niệm làn theo vai trò. "The transition of states in a system" là việc của state-transition diagram hay state table, mô tả đối tượng chuyển trạng thái. "The user interface design" thuộc về wireframe, prototype hay dialog map, không phải sơ đồ làn bơi.

Đáp án đúng: "A prioritized list of features, bugs, and tasks to be worked on". Trong dự án agile, product backlog là danh sách động mọi hạng mục công việc còn chờ làm cho sản phẩm (user story, tính năng, lỗi cần sửa, công việc kỹ thuật), được sắp theo độ ưu tiên và liên tục điều chỉnh; mỗi vòng lặp nhóm kéo các hạng mục ưu tiên cao nhất vào làm. Phương án "A detailed list of project risks" sai vì danh sách rủi ro là sổ rủi ro (risk list) trong quản lý dự án, không phải backlog. Phương án "A set of predefined user stories" thiếu ý cốt lõi: backlog không cố định từ trước mà được thêm, bớt, sắp lại liên tục, và ngoài story còn chứa lỗi, công việc kỹ thuật. Phương án "A document outlining system architecture" sai vì tài liệu kiến trúc thuộc thiết kế, không phải danh sách công việc ưu tiên.

Đáp án đúng: "They provide a realistic user experience for stakeholder feedback". High-fidelity prototype (bản mẫu độ trung thực cao) trông và hoạt động gần giống sản phẩm thật, có giao diện chi tiết và tương tác thực, nên khi dùng trong thẩm định yêu cầu, bên liên quan trải nghiệm hệ thống như người dùng thật và đưa phản hồi cụ thể về luồng thao tác, bố cục, tính khả dụng. Phương án "They finalize the system architecture" sai vì prototype tập trung vào điều người dùng thấy, không chốt kiến trúc bên trong. Phương án "They replace low-fidelity prototypes" sai vì hai loại bổ trợ nhau: bản phác thảo độ trung thực thấp rẻ, nhanh, hợp để khám phá ý tưởng sớm, còn bản độ trung thực cao hợp để tinh chỉnh chi tiết về sau. Phương án "They eliminate the need for testing" sai vì prototype không thay được kiểm thử phần mềm thật.

Đáp án đúng: "primary". Trong sơ đồ use case, đường liên kết có mũi tên đi từ tác nhân (actor) tới use case cho biết tác nhân đó khởi động use case, tức là tác nhân chính (primary actor), người có mục tiêu mà use case phục vụ. Ví dụ nhân viên phòng thí nghiệm khởi động use case đặt mua hoá chất. "secondary" sai vì tác nhân phụ chỉ tham gia hỗ trợ để use case hoàn tất, như một hệ thống kho bên ngoài được gọi tới, và mũi tên khi có thường đi từ use case hướng ra tác nhân đó. "main" nghe gần nghĩa trong cách nói thông thường nhưng không phải thuật ngữ chuẩn dùng để phân loại tác nhân trong mô hình use case. "side" hoàn toàn không phải một loại tác nhân trong UML hay trong kỹ nghệ yêu cầu.