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

Đá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: "Some important user needs or perspectives will not be met, leading to product dissatisfaction". Nhận diện đầy đủ các bên liên quan (stakeholder) và lớp người dùng là bước đầu của khơi gợi yêu cầu; bỏ sót một nhóm nghĩa là không ai nói thay nhu cầu của họ, nên yêu cầu thiếu và sản phẩm làm ra không thoả mãn nhóm đó, thường chỉ lộ ra khi đã quá muộn. "The project budget will inevitably increase due to unforeseen demands" sai ở chữ inevitably: chi phí có thể tăng nếu phải bổ sung muộn, nhưng đó không phải hệ quả tất yếu và không phải rủi ro cốt lõi. "The project manager will struggle to define a clear project scope." không đúng vì phạm vi được xác định từ mục tiêu kinh doanh, vẫn có thể rõ ràng dù thiếu người. "Developers will implement too many features, leading to gold plating." mô tả việc nhà phát triển tự thêm tính năng không ai yêu cầu, ngược với tình trạng thiếu yêu cầu do bỏ sót bên liên quan.

Đáp án đúng: "Promptly communicate changes to the requirements.". Quan hệ khách hàng và BA được mô tả bằng hai danh sách: Bill of Rights (các quyền của khách hàng) và Bill of Responsibilities (các trách nhiệm của khách hàng). Báo ngay cho BA khi yêu cầu thay đổi là trách nhiệm của khách hàng, vì họ phải giúp đội phát triển kịp điều chỉnh, nên nó không thuộc danh sách quyền. "Expect BAs to speak your language." là quyền, vì BA phải trao đổi bằng ngôn ngữ nghiệp vụ của khách hàng. "Expect BAs to learn about your business and your objectives." là quyền, vì BA cần hiểu nghiệp vụ và mục tiêu để nắm đúng yêu cầu. "Receive explanations of requirements practices and deliverables." là quyền, khách hàng được giải thích các mô hình, tài liệu và cách làm việc về yêu cầu. "Change your requirements." là quyền, vì thay đổi là bình thường khi hiểu biết tăng lên, dù phải qua kiểm soát thay đổi. "Expect an environment of mutual respect." là quyền, cả hai bên phải tôn trọng thời gian và ý kiến của nhau.

Đáp án đúng gồm ba ý: "expect business analysts to learn about their business and their objectives", "describe characteristics that will make the product easy to use" và "receive a system that meets their functional needs and quality expectations". Quan hệ khách hàng với người phân tích nghiệp vụ thường được mô tả bằng hai danh sách: quyền (rights) của khách hàng và trách nhiệm (responsibilities) của khách hàng trong phát triển yêu cầu. Ba ý được chọn đều nằm ở danh sách quyền: được người phân tích tìm hiểu nghiệp vụ và mục tiêu của mình, được mô tả các đặc điểm giúp sản phẩm dễ dùng, và được nhận một hệ thống đáp ứng nhu cầu chức năng cùng kỳ vọng chất lượng. "promptly communicate changes to the requirements" là trách nhiệm chứ không phải quyền: khách hàng phải báo thay đổi yêu cầu kịp thời cho người phân tích để nhóm đánh giá tác động, tránh làm lại tốn kém.

Đáp án đúng: "To facilitate ongoing collaboration and ensure the team understands the requirements.". Yêu cầu chỉ có giá trị khi người thiết kế, lập trình, kiểm thử và khách hàng hiểu giống nhau; chuyên viên phân tích nghiệp vụ (business analyst) truyền đạt yêu cầu rõ ràng và đúng lúc để duy trì cộng tác liên tục, giảm hiểu sai và làm lại. Phương án "To ensure that requirements are documented only once." sai vì ghi một lần ở một nơi là chuyện tổ chức tài liệu, không phải mục đích của giao tiếp. Phương án "To avoid the need for visual analysis models." sai vì mô hình trực quan chính là một công cụ giao tiếp hiệu quả, giao tiếp tốt không làm chúng thừa đi. Phương án "To reduce the number of requirements." sai vì số lượng yêu cầu do phạm vi và nhu cầu quyết định, giao tiếp tốt giúp hiểu đúng chứ không nhằm cắt bớt yêu cầu.

Đáp án đúng gồm hai ý: "Defining business requirements and helping project sponsors express the project’s vision clearly." và "Ensuring that all team members fully understand the requirements being communicated.". Business analyst (chuyên viên phân tích nghiệp vụ) là người chịu trách nhiệm chính về yêu cầu: giúp nhà tài trợ dự án nêu rõ tầm nhìn và yêu cầu nghiệp vụ, khơi gợi và phân tích yêu cầu người dùng, đặc tả, thẩm định và truyền đạt chúng để nhà phát triển, kiểm thử viên và các bên khác hiểu như nhau. Phương án "Focusing only on textual documentation and avoiding the use of visual aids like diagrams and prototypes." sai vì người phân tích giỏi kết hợp văn bản với sơ đồ, mô hình phân tích và prototype để làm lộ chỗ thiếu sót mà văn bản đơn thuần khó thấy. Phương án "Managing the entire software development life cycle, from inception to deployment." mô tả vai trò quản lý dự án; người phân tích tham gia nhiều giai đoạn nhưng không điều hành toàn bộ vòng đời phát triển.

Đáp án đúng: "All of the mentioned". Chuyên viên phân tích nghiệp vụ (business analyst) cần một bộ kỹ năng rộng vì phải vừa làm việc với con người vừa xử lý thông tin: lắng nghe, phỏng vấn, đặt câu hỏi, điều phối buổi làm việc, giao tiếp và quan hệ cá nhân để khơi gợi yêu cầu; tư duy phân tích, tư duy hệ thống, mô hình hoá, quan sát để phân tích; cùng khả năng học nhanh, phản ứng tại chỗ, tổ chức, lãnh đạo và sáng tạo. Mỗi phương án đơn lẻ chỉ liệt kê một phần của bộ kỹ năng đó, nên chọn riêng phương án nào cũng thiếu. "Listening skills, Systems thinking skills" đúng nhưng chưa đủ. "Interviewing and questioning skills, Learning skills, Interpersonal skills" là nhóm kỹ năng khơi gợi, vẫn chưa đủ. "Thinking on your feet, Facilitation skills," là kỹ năng điều phối và ứng biến, chỉ một phần. "Analytical skills, Leadership skills, Organizational skills, Creativity" thiếu nhóm giao tiếp. "Observational skills, Communication skills, Modeling skills" cũng chỉ là một phần, nên đáp án gộp toàn bộ là đúng nhất.

Đáp án đúng: "To represent the system as a whole and its interaction with external entities". Context diagram (sơ đồ ngữ cảnh) là mô hình phạm vi: cả hệ thống được vẽ thành một khối duy nhất ở giữa, xung quanh là các thực thể bên ngoài như người dùng, tổ chức, hệ thống khác, nối với hệ thống bằng các luồng dữ liệu. Nó cho thấy ranh giới giữa cái thuộc hệ thống và cái nằm ngoài, thường đặt trong tài liệu tầm nhìn và phạm vi. "To list system features" sai vì sơ đồ ngữ cảnh không cho thấy bên trong hệ thống; liệt kê tính năng là việc của danh sách tính năng hay feature tree. "To define user stories" sai vì user story là cách viết yêu cầu người dùng trong agile, không phải mục đích của mô hình phạm vi. "To prioritize requirements" sai vì sơ đồ ngữ cảnh không chứa thông tin ưu tiên; xếp ưu tiên là hoạt động phân tích riêng, dùng các kỹ thuật như MoSCoW.

Đáp án đúng: "Product vision describes the ultimate product, while project scope identifies the portion of that vision to be addressed by the current project.". Product vision (tầm nhìn sản phẩm) mô tả sản phẩm cuối cùng sẽ là gì và đạt mục tiêu nghiệp vụ nào, ổn định trong dài hạn; project scope (phạm vi dự án) xác định phần nào của tầm nhìn đó được làm trong dự án hay đợt phát hành hiện tại. Cả hai nằm trong tài liệu vision and scope, thuộc tầng yêu cầu nghiệp vụ. "Product vision and project scope are interchangeable terms." sai vì hai khái niệm khác tầm: một là đích dài hạn, một là phần việc trước mắt. "Project scope defines business objectives, while product vision defines functional requirements." sai vì mục tiêu nghiệp vụ gắn với tầm nhìn, còn yêu cầu chức năng ở tầng chi tiết hơn, không phải nội dung của tầm nhìn. "Product vision is a subset of project scope for each release." đảo ngược quan hệ, vì phạm vi mới là tập con của tầm nhìn.

Đáp án đúng gồm hai ý: "Ecosystem map" và "Context diagram". Phạm vi (scope) của dự án là ranh giới giữa những gì hệ thống làm và những gì nằm ngoài nó, thường thể hiện trong tài liệu tầm nhìn và phạm vi. Sơ đồ ngữ cảnh (context diagram) vẽ hệ thống như một khối duy nhất cùng các thực thể bên ngoài và luồng dữ liệu qua ranh giới; bản đồ hệ sinh thái (ecosystem map) cho thấy hệ thống nằm trong mạng lưới các hệ thống liên quan, kể cả hệ thống không trao đổi trực tiếp. Phương án "Use case" mô tả tương tác giữa tác nhân và hệ thống để đạt một mục tiêu, thuộc tầng yêu cầu người dùng; danh sách use case giúp chia nhỏ chức năng trong phạm vi chứ không phải kỹ thuật chính để vẽ ranh giới phạm vi. Phương án "ERD" là mô hình dữ liệu, mô tả thực thể và quan hệ giữa chúng, phục vụ phân tích yêu cầu dữ liệu chứ không thể hiện ranh giới hệ thống.

Đáp án đúng: "Creating a checklist of required documents and systems.". Khơi gợi độc lập (independent elicitation) là khi chuyên viên phân tích tự nghiên cứu tài liệu, hệ thống hiện có, báo cáo, quy trình mà không cần các bên liên quan có mặt; để chắc chắn không sót nguồn nào, trọng tâm là lập danh sách kiểm (checklist) mọi tài liệu và hệ thống cần có rồi đối chiếu. Phương án "Assigning a team member to gather all necessary materials." là một bước thực hiện, nhưng không có danh sách thì người đó cũng không biết phải gom những gì. Phương án "Setting up a shared repository for document access." giúp lưu và truy cập tài liệu, phục vụ sau khi đã biết cần tài liệu nào chứ không đảm bảo đủ. Phương án "Scheduling regular audits to ensure document availability." là kiểm tra định kỳ về sau, tốn công và vẫn cần một danh sách làm chuẩn để kiểm.

Đáp án đúng: "Draft straw man models". Khi chuẩn bị phỏng vấn trong hoạt động khơi gợi yêu cầu, người phân tích nên phác sẵn straw man model (mô hình nháp để người khác góp ý), như một sơ đồ quy trình hay danh sách tính năng thô; người được phỏng vấn thường dễ chỉ ra chỗ sai trong một bản nháp cụ thể hơn là trả lời câu hỏi trừu tượng từ trang giấy trắng. Phương án "Avoid preparing questions" sai vì chuẩn bị bộ câu hỏi giúp buổi phỏng vấn đi đúng mục tiêu và không bỏ sót chủ đề. Phương án "Focus only on UI design" sai vì phỏng vấn cần tìm hiểu mục tiêu, nhiệm vụ, quy tắc nghiệp vụ và yêu cầu chất lượng, giao diện chỉ là một phần nhỏ. Phương án "Skip meeting stakeholders" đi ngược bản chất phỏng vấn, vốn là trao đổi trực tiếp với bên liên quan.

Đáp án đúng: "Focus groups". Nhóm tập trung (focus group) tập hợp một nhóm người dùng đại diện, thường cho từng lớp người dùng, để thảo luận có điều phối về nhu cầu và kỳ vọng; với dự án lớn có rất nhiều người dùng, kỹ thuật khơi gợi này thu được quan điểm của số đông một cách hiệu quả hơn so với làm việc từng người. "Observation" là quan sát người dùng làm việc thật, rất tốt để hiểu quy trình ngầm nhưng tốn thời gian và chỉ phủ được ít người. "Brainstorming sessions" nhằm sinh nhiều ý tưởng mới, phù hợp khi tìm giải pháp chứ không nhằm thu thập nhu cầu đại diện của đông đảo bên liên quan. "Stakeholder interviews" là phỏng vấn một-một, cho thông tin sâu nhưng khó mở rộng khi số bên liên quan quá lớn, nên thường dùng cho người chủ chốt.

Đáp án đúng: "Business requirements". Business requirements (yêu cầu nghiệp vụ) nêu lý do tổ chức làm dự án và lợi ích kinh doanh mong đợi, thường là mục tiêu đo được về tài chính hay vận hành; câu tiết kiệm X đô la mỗi năm tiền điện đang lãng phí là đúng loại mục tiêu tài chính của tổ chức. Dù chính khách hàng nói ra, nó không mô tả việc người dùng cần làm, nên không phải yêu cầu người dùng. "User requirements" sai vì yêu cầu người dùng mô tả nhiệm vụ người dùng thực hiện với hệ thống, ví dụ theo dõi mức tiêu thụ điện của từng thiết bị. "Business rules" sai vì quy tắc nghiệp vụ là chính sách, quy định, công thức tính áp lên hoạt động, không phải mục tiêu lợi ích. "Quality attributes" sai vì thuộc tính chất lượng mô tả hệ thống tốt đến mức nào như hiệu năng, khả dụng, không phải số tiền tiết kiệm. "Solution ideas" sai vì phát biểu không đề xuất cách giải nào, như thay thiết bị hay lắp cảm biến, mà chỉ nêu kết quả kinh doanh cần đạ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.

Đáp án đúng: "A User Story is a brief description of a user’s need, typically written in the format “As a [user], I want [goal] so that [benefit].”". User story là một câu ngắn ghi nhu cầu của người dùng theo mẫu vai trò, mục tiêu, lợi ích; nó là lời hứa cho một cuộc trao đổi sau, chi tiết được bổ sung bằng tiêu chí chấp nhận. Khác biệt chính với use case: use case mô tả chi tiết chuỗi tương tác giữa tác nhân và hệ thống, có luồng chính, luồng thay thế và ngoại lệ. "A User Story is a detailed step-by-step description of the user’s interaction with the system." mô tả use case chứ không phải user story. "A User Story focuses on the system’s non-functional requirements." sai vì user story chủ yếu diễn đạt nhu cầu chức năng của người dùng. "A User Story is used to completely replace a Use Case in all situations." sai vì nhiều dự án dùng cả hai, use case hợp khi cần đặc tả chi tiết. "A User Story is a tool for test planning, while a Use Case is only for designing the interface." sai cả hai vế: cả hai đều là cách diễn đạt yêu cầu người dùng.

Đáp án đúng: "Skipping the identification of alternative flows". Một use case tốt gồm luồng chính (normal flow) cùng các luồng thay thế (alternative flows) và ngoại lệ (exceptions); bẫy thường gặp là chỉ viết con đường suôn sẻ rồi bỏ qua các biến thể, khiến hệ thống không xử lý được tình huống lệch khỏi luồng chính và lập trình viên phải tự đoán. Phương án "Including too many preconditions" không phải bẫy điển hình, vì tiền điều kiện (preconditions) là thành phần bình thường và cần thiết của use case, chỉ cần đúng và đủ. Phương án "Writing the use case without validation" là thiếu sót chung của thẩm định yêu cầu, áp cho mọi loại yêu cầu, không phải bẫy riêng của cách viết use case. Phương án "Ignoring business rules" cũng là thiếu sót chung của phân tích; use case chỉ tham chiếu tới quy tắc nghiệp vụ còn quy tắc được ghi riêng.

Đáp án đúng: "Creating highly complex use cases with many embedded logic and branching conditions, making them incomprehensible". Một cái bẫy kinh điển khi viết use case là nhồi quá nhiều logic, điều kiện rẽ nhánh và ngoại lệ vào một ca sử dụng, khiến người dùng lẫn nhà phát triển đọc không hiểu và khó thẩm định; cách chữa là giữ luồng chính ngắn gọn, tách luồng thay thế và ngoại lệ, đưa logic phức tạp sang quy tắc nghiệp vụ hoặc bảng quyết định. Phương án "Only creating a few very high-level use cases" là vấn đề khác: ca sử dụng quá chung chung thiếu chi tiết, nhưng câu hỏi hỏi về bẫy độ phức tạp. Phương án "Separating normal flows from alternative flows" là thực hành tốt được khuyến khích, không phải bẫy. Phương án "Using use case diagrams to visualize relationships." cũng là thực hành tốt, giúp nhìn tổng thể các tác nhân và ca sử dụng cùng quan hệ giữa chúng.

Đáp án đúng: "Design features". Khuôn đặc tả yêu cầu phần mềm (SRS) mô tả hệ thống phải làm gì chứ không mô tả nó được thiết kế ra sao, nên không có mục đặc điểm thiết kế; thiết kế chỉ xuất hiện dưới dạng ràng buộc thiết kế và triển khai mà khách hàng áp đặt. Các mục điển hình của khuôn SRS gồm giới thiệu, mô tả tổng quan, tính năng hệ thống, yêu cầu dữ liệu, yêu cầu giao diện bên ngoài và thuộc tính chất lượng. "Quality Attributes" là mục ghi yêu cầu phi chức năng như hiệu năng, bảo mật, khả dụng. "External interface" là mục mô tả giao diện người dùng, phần mềm, phần cứng và giao tiếp với bên ngoài. "Data requirements" mô tả mô hình dữ liệu logic, từ điển dữ liệu, báo cáo. "System features" là phần chính chứa các yêu cầu chức năng nhóm theo tính năng.

Đáp án đúng: "To state the functions, capabilities, characteristics, and constraints a software system must provide.". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là sản phẩm của hoạt động đặc tả, ghi lại các yêu cầu chức năng, yêu cầu phi chức năng, giao diện ngoài và ràng buộc mà hệ thống phải đáp ứng; nó là cơ sở chung cho thiết kế, xây dựng, kiểm thử và quản lý dự án. "To document design, construction, and testing details for developers." sai vì SRS nói hệ thống phải làm gì, còn chi tiết thiết kế, cách lập trình và kế hoạch kiểm thử nằm ở tài liệu thiết kế và tài liệu kiểm thử riêng. "To serve as a marketing brochure for the new software product." sai vì SRS là tài liệu kỹ thuật chính xác cho đội dự án, không nhằm quảng bá sản phẩm. "To track project management schedules and resource allocation." sai vì lịch trình và phân bổ nguồn lực thuộc kế hoạch dự án; SRS chỉ là đầu vào để ước lượng các thứ đó.