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

Đáp án đúng: "Whether the cost of reuse is justified by the benefits". Tái sử dụng yêu cầu không miễn phí: phải tìm yêu cầu phù hợp, đánh giá, sửa cho khớp bối cảnh mới, và tổ chức phải đầu tư vào kho yêu cầu, chuẩn hoá cách viết, quản lý phiên bản. Vì vậy câu hỏi then chốt là lợi ích như tiết kiệm thời gian, nhất quán, giảm rủi ro có đủ lớn để bù chi phí đó không. "How much effort it will take to create new requirements" chỉ là một nửa của phép so sánh; công sức viết mới là một phần lợi ích, nhưng không cân với chi phí tái sử dụng thì chưa đủ để quyết định. "How many stakeholders are involved" sai vì số lượng bên liên quan không quyết định có nên dùng lại yêu cầu hay không. "How complex the new system is" sai vì độ phức tạp của hệ thống mới không trực tiếp cho biết yêu cầu cũ có dùng lại được, điều quan trọng là mức tương đồng và chi phí lợi ích.

Đáp án đúng: "Scalability". Architectural allocation (phân bổ yêu cầu vào kiến trúc) là việc gán yêu cầu cho các hệ thống con, thành phần phần cứng, phần mềm hay con người; những thuộc tính chất lượng tác động mạnh tới cấu trúc hệ thống như scalability (khả năng mở rộng), performance, availability hay security thường được xét nhiều nhất ở bước này, vì muốn đáp ứng chúng phải chọn cách chia thành phần và phân tải phù hợp. "Humor" không phải thuộc tính chất lượng phần mềm, không có ý nghĩa trong phân bổ kiến trúc. "Color selection" là quyết định trình bày giao diện, thuộc thiết kế giao diện chứ không ảnh hưởng tới cách chia thành phần hệ thống. "Typography" cũng là lựa chọn kiểu chữ trong thiết kế hình ảnh, không phải thuộc tính chất lượng được phân bổ vào kiến trúc.

Đáp án đúng: "Users who are familiar with how the system works today might like the changes they are about to encounter.". Câu hỏi tìm phát biểu sai về thách thức của dự án nâng cấp và thay thế hệ thống; thách thức thật là người dùng đã quen cách hệ thống đang chạy thường không thích thay đổi và có thể phản đối, nên nói họ có thể thích thay đổi không phải một thách thức. Phương án "degrade the performance to which users are accustomed" đúng vì thay đổi có thể làm chậm hệ thống so với điều người dùng đã quen. Phương án "Little or no requirements documentation might be available" đúng vì hệ thống cũ thường thiếu tài liệu yêu cầu. Phương án "unknowingly break or omit functionality that is vital" đúng vì dễ vô tình làm hỏng chức năng quan trọng với một nhóm. Phương án "request new functionality that seems like a good idea" đúng vì các bên dễ nhân dịp xin thêm tính năng không cần cho mục tiêu nghiệp vụ. Các phát biểu đúng này không được chọn.

Đáp án đúng: "Aligning the requirements with business objectives". Với packaged solution (giải pháp đóng gói, phần mềm mua sẵn như COTS), tổ chức không tự xây mà chọn và cấu hình sản phẩm có sẵn, nên yêu cầu người dùng cần tập trung vào việc người dùng phải làm được gì để đạt mục tiêu kinh doanh, rồi dùng chúng để đánh giá gói nào đáp ứng tốt nhất và xác định cần cấu hình, tích hợp hay mở rộng gì. Phương án "Focusing solely on user interface design" sai vì giao diện do nhà cung cấp quyết định phần lớn và không phải trọng tâm duy nhất. Phương án "Ensuring compatibility with the development platform" sai vì tổ chức không phát triển gói, dù khả năng tích hợp với môi trường hiện có vẫn cần xem xét. Phương án "Defining the technical architecture of the solution" sai vì kiến trúc kỹ thuật đã do nhà cung cấp xác định.

Đáp án đúng: "Request for Proposal (RFP), requirements specification, and product acceptance criteria.". Trong dự án thuê ngoài (outsourced project), bên đặt hàng không ngồi cạnh đội phát triển nên tài liệu là kênh truyền yêu cầu chính; ba sản phẩm nền tảng gửi cho nhà cung cấp là hồ sơ mời thầu để họ hiểu nhu cầu và đề xuất, đặc tả yêu cầu đủ chi tiết vì không thể hỏi lại thường xuyên, và tiêu chí chấp nhận sản phẩm để hai bên thống nhất khi nào sản phẩm được coi là đạt. "Project plan, progress reports, and contracts." là tài liệu quản lý dự án và pháp lý, không phải nền tảng yêu cầu. "Design specification, test plan, and user manuals." thường do nhà cung cấp tạo ra trong quá trình làm, không phải đầu vào gửi đi. "Meeting minutes, risk logs, and open issue lists." là tài liệu theo dõi phát sinh trong quá trình làm việc, không định nghĩa yêu cầu.

Đáp án đúng: "Estimate the effort required to implement the change". Thủ tục phân tích tác động thay đổi đi theo thứ tự: bước một là hiểu các hệ quả có thể có của thay đổi; bước hai là xác định các việc cần làm, dùng truy vết yêu cầu để tìm mọi yêu cầu, thiết kế, mã, ca kiểm thử, tài liệu bị ảnh hưởng; bước ba là ước lượng công sức để thực hiện từng việc đó, rồi cộng lại để thấy tác động lên chi phí và lịch. "Understand the implications of the change" sai vì đó là bước đầu tiên, phải hiểu thay đổi kéo theo gì rồi mới tìm việc cụ thể. "Identify tasks required to implement the change" sai vì đó là bước thứ hai, chỉ khi đã có danh sách việc mới ước lượng được công sức. "Communicate the change to stakeholders" sai vì báo kết quả phân tích cho ban kiểm soát thay đổi và bên liên quan là bước cuối, sau khi đã có ước lượng.

Đáp án đúng gồm hai ý: "To map requirements to other system elements like design and code" và "To identify missing or unnecessary requirements". Traceability matrix (ma trận truy vết) 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 thiết kế, mã nguồn, ca kiểm thử; nhìn vào ma trận, ô trống cho biết yêu cầu chưa được hiện thực hoặc chưa được kiểm thử, còn yêu cầu không truy về mục tiêu nghiệp vụ nào là dấu hiệu yêu cầu thừa, và thành phần thiết kế không gắn yêu cầu nào gợi ý yêu cầu còn thiếu. "To track project progress in real-time" sai vì ma trận có thể cho biết trạng thái hiện thực của yêu cầu nhưng không phải công cụ theo dõi tiến độ dự án theo thời gian thực, việc đó thuộc công cụ quản lý dự án. "To generate new requirements automatically" sai vì ma trận chỉ ghi lại liên kết, không tự sinh ra yêu cầu, yêu cầu mới phải qua khơi gợi và phân tích.

Đá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: "Involving customers throughout the development process to continuously refine and validate requirements.". Cách tiếp cận agile coi yêu cầu sẽ thay đổi và được hiểu dần, nên điều cốt lõi để sản phẩm đúng nhu cầu là khách hàng tham gia liên tục: làm rõ story trước mỗi vòng lặp, xem bản demo và phản hồi để điều chỉnh, tức là khơi gợi và thẩm định yêu cầu diễn ra suốt dự án. Phương án "Documenting all requirements in detail before development begins." sai vì đó là cách làm kiểu thác nước, trái với tinh thần agile là chi tiết hoá đúng lúc. Phương án "Prioritizing speed over accuracy to deliver functionality quickly." sai vì giao nhanh mà sai nhu cầu thì vô ích, agile giao nhanh để nhận phản hồi chứ không hy sinh độ đúng. Phương án "Focusing solely on the technical aspects." sai vì bỏ qua góc nhìn nghiệp vụ và người dùng.

Đáp án đúng: "To reveal insights and problems that no single view can provide.". Trong phân tích yêu cầu, biểu diễn cùng một nội dung bằng nhiều góc nhìn, như văn bản, sơ đồ luồng dữ liệu, sơ đồ trạng thái, mô hình dữ liệu hay prototype, giúp đối chiếu chéo: chỗ thiếu, mâu thuẫn hay mơ hồ khó thấy trong một dạng sẽ lộ ra khi so với dạng khác, và mỗi bên liên quan có thể hiểu tốt hơn qua dạng hợp với mình. Phương án "To increase the volume of project documentation." sai vì mục tiêu là hiểu sâu hơn, không phải tăng khối lượng giấy tờ. Phương án "To make the requirements more complex." sai vì nhiều góc nhìn giúp làm rõ, không làm rối yêu cầu. Phương án "To meet strict compliance regulations." sai vì có lĩnh vực đòi hỏi tài liệu theo quy định, nhưng đó không phải lý do cốt lõi để mô hình hóa yêu cầu bằng nhiều cách.

Đáp án đúng: "Analysis". Phát triển yêu cầu gồm bốn hoạt động: khơi gợi, phân tích, đặc tả và thẩm định. Phân tích (analysis) là lúc nhu cầu thô của khách hàng được xử lý: làm rõ, phân rã, mô hình hoá, phát hiện xung đột, ưu tiên và chuyển thành yêu cầu phần mềm cụ thể, có quan hệ truy vết với nhu cầu gốc. "Elicitation" là khơi gợi, thu thập nhu cầu từ bên liên quan qua phỏng vấn, workshop, quan sát; nó tạo ra đầu vào thô chứ chưa xử lý thành yêu cầu phần mềm. "Specification" là đặc tả, ghi các yêu cầu đã phân tích thành tài liệu có cấu trúc như SRS. "Validation" là thẩm định, kiểm tra các yêu cầu đã ghi có phản ánh đúng nhu cầu và đủ chất lượng chưa, diễn ra sau khi yêu cầu đã được phân tích và viết ra.

Đáp án đúng: "identify user classes". Ellen Gottesdiener đề xuất mẫu cộng tác expand then contract (mở rộng rồi thu hẹp) để xác định user classes (các lớp người dùng): trước tiên cả nhóm động não liệt kê càng nhiều loại người dùng tiềm năng càng tốt, sau đó gộp những loại giống nhau, loại bỏ trùng lặp để còn một tập lớp người dùng rõ ràng. Xác định lớp người dùng là bước đầu của khơi gợi, vì mỗi lớp có nhu cầu riêng và cần đại diện riêng. "identify user personas" sai vì persona là nhân vật mô tả chi tiết một người dùng điển hình, thường được dựng sau khi đã có các lớp người dùng. "identify user requirements" sai vì mẫu này nhắm tới việc tìm ra ai là người dùng, chưa phải điều họ cần. "identify product champion" sai vì product champion là người đại diện cho một lớp người dùng, được chọn sau khi đã xác định các lớp, không phải đối tượng của kỹ thuật động não này.

Đáp án đúng: "To serve as the primary interface between a single user class and the business analyst, gathering requirements and making binding decisions on behalf of their user class.". Product champion là đại diện chủ chốt của một user class (nhóm người dùng), làm đầu mối chính với người phân tích nghiệp vụ, thu thập yêu cầu từ những người cùng nhóm và được trao quyền ra quyết định ràng buộc thay cho nhóm của mình. "To write all requirements documents for the project." sai vì viết tài liệu yêu cầu là trách nhiệm của người phân tích nghiệp vụ, product champion chỉ cung cấp nội dung và review. "To approve all requirements changes." sai vì phê duyệt thay đổi là việc của change control board (ban kiểm soát thay đổi), product champion chỉ góp ý về thay đổi ảnh hưởng tới nhóm mình. "To train end-users on the new system." không phải kỳ vọng chính, dù product champion có thể giúp viết tài liệu hướng dẫn hay hỗ trợ đào tạo sau này.

Đá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: "An atomic business rule cannot be further subdivided, whereas a composite business rule is composed of multiple atomic rules.". Quy tắc nghiệp vụ (business rule) nguyên tử là quy tắc chỉ phát biểu một điều, không tách nhỏ được nữa; quy tắc phức hợp gộp nhiều quy tắc nguyên tử lại. Viết quy tắc ở dạng nguyên tử giúp mỗi quy tắc có định danh riêng, dễ truy vết tới yêu cầu chức năng, dễ tái sử dụng và dễ sửa khi chính sách đổi. Phương án "apply only to functional requirements, while composite rules apply to non-functional" sai vì tính nguyên tử nói về cấu trúc của quy tắc, không về loại yêu cầu nó ảnh hưởng. Phương án "used only in Agile projects, whereas composite rules are used in Waterfall" sai vì quy tắc nghiệp vụ tồn tại độc lập với mô hình phát triển. Phương án "Atomic business rules are always shorter than composite rules." sai vì độ dài câu chữ không phải tiêu chí; tiêu chí là quy tắc có tách được thành quy tắc nhỏ hơn hay không.

Đáp án đúng: "fact". Trong phân loại quy tắc nghiệp vụ, fact (sự kiện) là phát biểu luôn đúng về doanh nghiệp, mô tả quan hệ hoặc thuộc tính giữa các khái niệm nghiệp vụ mà không kèm điều kiện hay hành động; câu mọi đơn hàng đều có phí vận chuyển đúng dạng này. Phương án "constraint" sai vì ràng buộc giới hạn hành động được phép, thường có dạng phải hoặc không được, ví dụ khách dưới 18 tuổi không được mua rượu. Phương án "action enabler" sai vì quy tắc kích hoạt hành động có dạng nếu điều kiện thì hệ thống làm gì đó. Phương án "inference" sai vì quy tắc suy diễn tạo ra một sự thật mới từ điều kiện, ví dụ nếu khách chưa thanh toán sau 30 ngày thì tài khoản bị coi là quá hạn. Câu được hỏi không có điều kiện hay hành động nào, chỉ nêu một sự thật.

Đáp án đúng: "It helps collect issues from multiple requirements reviews, assign owners, track resolution history, and provide visibility into the status of all open issues". Trong quản lý yêu cầu, các vấn đề phát sinh từ rà soát như câu hỏi chưa trả lời, điểm mơ hồ hay mâu thuẫn rất dễ thất lạc nếu chỉ ghi rời rạc; công cụ theo dõi vấn đề (issue-tracking tool) gom chúng về một chỗ, giao người chịu trách nhiệm, lưu lịch sử xử lý và cho mọi người thấy vấn đề nào còn mở. "It eliminates the need for any requirements elicitation" sai vì công cụ chỉ theo dõi vấn đề, không thay được việc thu thập yêu cầu từ bên liên quan. "It guarantees that all project requirements will remain unchanged" sai vì không công cụ nào ngăn được thay đổi; yêu cầu vẫn thay đổi và được quản lý qua kiểm soát thay đổi. "It automatically writes acceptance tests for all requirements." sai vì kiểm thử chấp nhận phải do con người thiết kế dựa trên yêu cầu.

Đáp án đúng: "Project Planning Process". Yêu cầu phần mềm thực ra là đầu vào cho gần như mọi quy trình được liệt kê, nên đây là câu dễ gây tranh cãi; tuy vậy khi chỉ chọn một, lập kế hoạch dự án là đáp án hợp lý nhất vì đó là quy trình đầu tiên dùng tới yêu cầu: từ yêu cầu mới ước lượng được quy mô, công sức, chi phí và lịch, rồi các quy trình khác mới chạy theo kế hoạch đó. "Project Tracking and Control Process" cũng dùng yêu cầu, nhưng ở bước sau, để đo tiến độ so với phạm vi đã lập kế hoạch. "Change Control Process" cũng dùng yêu cầu, nhưng chỉ khi đã có đường cơ sở yêu cầu và phát sinh đề xuất thay đổi. "Acceptance & System Testing Process" cũng dùng yêu cầu để thiết kế ca kiểm thử, nhưng đó là giai đoạn muộn. "Construction Process" cũng dùng yêu cầu khi thiết kế và viết mã, nhưng diễn ra sau khi kế hoạch đã có. Vì vậy các quy trình này không sai về bản chất, chỉ không phải nơi yêu cầu đóng vai trò đầu vào trước tiên.

Đáp án đúng: "To make sure the product delivers the most critical or valuable functionality as early as possible". Xếp ưu tiên yêu cầu thuộc hoạt động phân tích: vì thời gian và nguồn lực luôn có hạn, nhóm cần biết yêu cầu nào mang lại giá trị cao nhất hoặc quan trọng nhất để làm trước, nhờ đó sản phẩm đem lại giá trị sớm và nếu phải cắt giảm thì phần bị cắt là phần ít giá trị. "To ensure all desired functionality is delivered by the initial target date." sai vì xếp ưu tiên chính là thừa nhận không thể làm hết mọi thứ cùng lúc. "To eliminate the need for any future requirements changes" sai vì ưu tiên không ngăn được thay đổi, danh sách ưu tiên còn được cập nhật liên tục khi có yêu cầu mới. "To reduce the overall project budget by cutting features." chỉ là một hệ quả có thể xảy ra, mục đích chính là sắp thứ tự giao giá trị chứ không phải cắt ngân sách.