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

Đáp án đúng: "Have developers review requirements". Yêu cầu là đầu vào trực tiếp của thiết kế và viết mã, nên thực hành gắn với khâu này là để nhà phát triển rà soát yêu cầu sớm: họ phát hiện chỗ mơ hồ, không khả thi về kỹ thuật hay thiếu thông tin trước khi bắt tay thiết kế, tránh hiểu sai rồi phải làm lại. Một số bộ ôn tập xếp câu này khác, nhưng các phương án kia rõ ràng thuộc khâu khác. Phương án "Base estimates on product size" thuộc lập kế hoạch dự án, dùng kích thước yêu cầu để ước lượng công sức. Phương án "Use requirement priorities to drive iterations" cũng thuộc lập kế hoạch, chọn yêu cầu nào làm ở vòng lặp nào. Phương án "Start test design early" và phương án "Trace requirements to tests" thuộc kiểm thử: thiết kế ca kiểm thử sớm từ yêu cầu và truy vết mỗi yêu cầu tới ca kiểm thử của nó.

Đáp án đúng: "It is a project in which new capabilities are added to an existing system.". Dự án nâng cấp (enhancement project) bổ sung chức năng mới hoặc cải tiến cho một hệ thống đang vận hành; khi làm yêu cầu cho loại dự án này, chuyên viên phân tích phải hiểu hệ thống hiện tại, phân tích tác động lên chức năng cũ và giữ tương thích. Phương án mô tả việc "replaces an existing application with a new custom-built system" là định nghĩa dự án thay thế (replacement project), khi hệ cũ bị thay bằng hệ tự xây, sản phẩm thương mại mua sẵn hoặc kết hợp, chứ không phải nâng cấp hệ đang có. "It is a project which costs less than planned." chỉ nói về kết quả tài chính, không phải một loại dự án. "It is a project which generates more revenues." cũng là kết quả kinh doanh mong muốn chứ không định nghĩa đặc điểm của dự án nâng cấp.

Đáp án đúng: "Performance". Khi chọn một gói phần mềm có sẵn (package solution), BA cần đặc tả các thuộc tính chất lượng mà gói phải đáp ứng; Performance (hiệu năng) đo khả năng hệ thống đáp ứng tải, gồm số người dùng đồng thời, thông lượng giao dịch, thời gian phản hồi. Bảo đảm gói chịu được tải dự kiến về người dùng đồng thời và thông lượng giao dịch chính là yêu cầu hiệu năng. "Usability" sai vì tính dễ dùng nói về việc người dùng học và thao tác hiệu quả, không liên quan tới tải. "Integrity" sai vì tính toàn vẹn nói về việc bảo vệ dữ liệu khỏi sai lệch, mất mát hay truy cập trái phép, bảo đảm dữ liệu chính xác. "Modifiability" sai vì khả năng sửa đổi đo mức dễ dàng khi thay đổi, mở rộng hay sửa lỗi phần mềm, không đo khả năng chịu tải lúc vận hành.

Đáp án đúng: "To save money, or to accelerate development and access specialized expertise.". Doanh nghiệp thuê tổ chức gia công phần mềm (outsourcing) chủ yếu để giảm chi phí, rút ngắn thời gian phát triển nhờ có thêm nhân lực, hoặc tiếp cận chuyên môn mà nội bộ không có. Đổi lại, yêu cầu phải được đặc tả rõ và chi tiết hơn vì nhóm bên ngoài ít cơ hội hỏi lại. "To increase control and oversight project" sai vì thuê ngoài thường làm giảm khả năng kiểm soát trực tiếp, bên thuê phải bù bằng tiêu chí chấp nhận và giám sát chặt. "To minimize stakeholder involvement" sai vì dự án thuê ngoài vẫn cần các bên liên quan tham gia làm rõ và nghiệm thu yêu cầu. "To limit project scope" sai vì phạm vi do mục tiêu nghiệp vụ quyết định, việc thuê ngoài không phải công cụ để thu hẹp phạm vi.

Đáp án đúng: "Change control board". Ban kiểm soát thay đổi (change control board, CCB) là nhóm người, có thể chỉ một người hoặc gồm đại diện nhiều bên, được trao quyền quyết định chấp nhận, chấp nhận có sửa đổi hay từ chối từng yêu cầu thay đổi và yêu cầu mới; đây là phần cốt lõi của quy trình kiểm soát thay đổi trong quản lý yêu cầu. Phương án "Project management board" sai vì đó là cách gọi nhóm điều hành dự án nói chung, không phải tên chuẩn của nhóm quyết định thay đổi yêu cầu. Phương án "Project management office" sai vì văn phòng quản lý dự án (PMO) chuẩn hoá phương pháp, hỗ trợ nhiều dự án trong tổ chức. Phương án "Project management committee" sai vì không phải thuật ngữ chuẩn cho vai trò này. Phương án "Change control group" nghe gần nhưng không phải tên chuẩn; thuật ngữ được dùng là change control board.

Đá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 gồm ba ý: "Risk assessment", "Risk avoidance" và "Risk control". Quản lý rủi ro (risk management) trong dự án phần mềm gồm ba nhóm việc chính: risk assessment (đánh giá rủi ro) nhận diện, phân tích xác suất và tác động rồi xếp ưu tiên các rủi ro; risk avoidance (né tránh rủi ro) là chọn cách làm khác để rủi ro không còn xảy ra được, chẳng hạn không nhận một yêu cầu quá mạo hiểm; risk control (kiểm soát rủi ro) gồm lập kế hoạch đối phó, thực hiện biện pháp và theo dõi rủi ro suốt dự án. Phương án "Risk reduction" không sai về nghĩa vì giảm thiểu rủi ro là việc thường làm, nhưng nó là một biện pháp cụ thể nằm bên trong kiểm soát rủi ro, không phải một thành phần ngang hàng với ba nhóm trên.

Đáp án đúng: "They represent small, actionable pieces of functionality". Trong agile, câu chuyện người dùng (user story) là mô tả ngắn một nhu cầu từ góc nhìn người dùng, thường theo dạng tôi là ai, muốn gì, để làm gì; mỗi câu chuyện là một phần chức năng nhỏ, đủ cụ thể để ước lượng, làm xong và kiểm thử trong một vòng lặp, kèm tiêu chí chấp nhận. "They define the system architecture" sai vì kiến trúc là quyết định thiết kế kỹ thuật, không do câu chuyện người dùng xác định. "They specify project deadlines" sai vì hạn chót thuộc kế hoạch dự án và phát hành; câu chuyện chỉ được xếp vào vòng lặp theo ưu tiên. "They describe the business goals in detail" sai vì mục tiêu kinh doanh thuộc tầng yêu cầu kinh doanh như tầm nhìn và phạm vi, còn câu chuyện người dùng là yêu cầu ở mức người dùng, ngắn gọn chứ không chi tiết.

Đáp án đúng: "Identify requirement origins.". Phân tích yêu cầu là làm rõ, tinh chỉnh yêu cầu và soát lỗi, thiếu sót. Các thực hành tốt của phân tích gồm mô hình hoá môi trường ứng dụng, tạo prototype, phân tích tính khả thi, xếp ưu tiên và mô hình hoá yêu cầu. Ghi nhận nguồn gốc của từng yêu cầu, tức ai hay tài liệu nào sinh ra nó, là thực hành của bước đặc tả, gắn với việc gán nhãn và lập tài liệu yêu cầu, nên không phải kỹ thuật thường dùng trong phân tích. "Model the application environment." là thực hành phân tích, ví dụ sơ đồ ngữ cảnh cho thấy ranh giới hệ thống. "Create user interface and technical prototypes." là thực hành phân tích, prototype giúp bên liên quan hiểu và làm rõ yêu cầu. "Analyze requirement feasibility." là thực hành phân tích, đánh giá yêu cầu có cài đặt được với chi phí và rủi ro chấp nhận được. "Prioritize the requirements." là thực hành phân tích, quyết định thứ tự cài đặt. "Model the requirements." là thực hành phân tích, dùng mô hình như sơ đồ luồng dữ liệu, sơ đồ trạng thái để thấy yêu cầu thiếu hay mâu thuẫn.

Đáp án đúng gồm hai ý: "Defining the product vision and project scope early in the project to ensure all stakeholders have a shared understanding." và "Identifying user classes and their characteristics to ensure that all user needs are considered.". Đây là hai thực hành tốt của khơi gợi yêu cầu: xác định sớm tầm nhìn và phạm vi giúp mọi người cùng hướng tới một mục tiêu và có căn cứ để quyết định yêu cầu nào nằm trong phạm vi; xác định các user class (nhóm người dùng) cùng đặc điểm của họ giúp không bỏ sót nhu cầu của nhóm nào. "Focusing exclusively on nonfunctional requirements during initial elicitation while ignoring functional requirements to save time." sai vì khơi gợi phải bao quát cả yêu cầu chức năng lẫn phi chức năng, bỏ một nhóm sẽ gây thiếu sót. "Avoiding the use of prototypes in the early stages of requirements elicitation to prevent biasing stakeholders." sai vì prototype là kỹ thuật được khuyến khích để làm rõ yêu cầu từ sớm, chỉ cần dùng có chủ đích.

Đáp án đúng gồm ba ý: "The platform they will be using, such as desktop PCs, laptops, tablets, or smartphones.", "The frequency with which they use the product and the tasks they perform during business operations." và "Their access privileges or security levels, such as ordinary user, guest user, or administrator.". Phân lớp người dùng (user classes) là chia người dùng thành nhóm có nhu cầu khác nhau để khơi gợi yêu cầu đủ cho từng nhóm; tiêu chí thường dùng gồm thiết bị và nền tảng họ dùng, tần suất dùng cùng nhiệm vụ họ làm, mức quyền truy cập, ngoài ra còn trình độ, kinh nghiệm miền, vị trí địa lý. Mỗi tiêu chí này làm nhóm người dùng cần tính năng và giao diện khác nhau. Phương án "The specific languages used in the system’s backend processes." sai vì ngôn ngữ lập trình phía máy chủ là quyết định cài đặt của nhóm phát triển, người dùng không thấy và không tạo ra khác biệt về nhu cầu giữa các nhóm người dùng.

Đáp án đúng: "The persona must be representative of their user class". Persona (chân dung người dùng) là một nhân vật được dựng lên để đại diện cho một lớp người dùng (user class), có tên, mục tiêu, thói quen và bối cảnh; nó giúp nhóm khơi gợi và thiết kế nghĩ cụ thể về người sẽ dùng sản phẩm, nên điều quan trọng nhất là các đặc điểm của nó phản ánh đúng lớp người dùng đó. Phương án "The persona must be a real person" sai vì persona thường là nhân vật hư cấu tổng hợp từ nhiều người thật, dựa trên một cá nhân cụ thể dễ làm lệch đặc điểm chung. Phương án "The persona must be rich" sai vì dù hiểu là giàu có hay giàu chi tiết, đó không phải tiêu chí chính; chi tiết chỉ có ích khi phục vụ tính đại diện. Phương án "The persona must be beautiful" sai vì ngoại hình không liên quan tới nhu cầu và hành vi người dùng.

Đáp án đúng: "A superset of stakeholders". Bên liên quan (stakeholder) là mọi cá nhân hay tổ chức bị ảnh hưởng hoặc có ảnh hưởng tới dự án, nên tập này rộng nhất; khách hàng là một phần của bên liên quan, và người dùng lại là một phần trong đó. Vì vậy nói người dùng là tập bao của bên liên quan là sai, đây chính là phát biểu không đúng cần chọn. "A subset of the product’s customers in some cases" là đặc điểm đúng: có lúc người dùng cũng là khách hàng, như người mua phần mềm để tự dùng. "A subset of the product’s users" đúng theo nghĩa mỗi lớp người dùng (user class) chỉ là một nhóm con trong toàn bộ người dùng sản phẩm. "Includes direct users and indirect users" cũng đúng: người dùng trực tiếp thao tác hệ thống, còn người dùng gián tiếp nhận kết quả từ nó như báo cáo, nên cả hai đều phải được xét khi khơi gợi yêu cầu.

Đáp án đúng gồm ba ý: "“Common knowledge” from the organization, often collected from individuals who have worked with the business for a long time and know the details of how it operates.", "Legacy systems that embed business rules in their requirements and code." và "Analysis of existing documentation, including requirements specifications from earlier projects, regulations, industry standards, corporate policy documents, contracts, and business plans.". Business rule (quy tắc nghiệp vụ) là chính sách, quy định, tiêu chuẩn chi phối hoạt động của tổ chức, thường tồn tại độc lập với phần mềm. Người phân tích tìm chúng qua phỏng vấn những người làm lâu năm nắm kiến thức ngầm, qua việc phân tích hệ thống cũ nơi quy tắc đã được nhúng vào yêu cầu và mã, và qua đọc tài liệu sẵn có như đặc tả cũ, quy định, tiêu chuẩn ngành, chính sách công ty, hợp đồng. Phương án "Business laws" chỉ là một nhãn mơ hồ, không phải một nơi hay một cách tìm cụ thể; các quy định pháp luật liên quan đã nằm trong việc phân tích tài liệu sẵn có.

Đáp án đúng: "Use a word processor or a simple catalog". Business rules (quy tắc nghiệp vụ) là chính sách, quy định, công thức, ràng buộc áp lên hoạt động của tổ chức; nhiều hệ thống dùng chung một quy tắc nên cần lưu chúng ở một nơi. Cách đơn giản để bắt đầu là ghi chúng vào một danh mục quy tắc nghiệp vụ (business rules catalog) bằng trình soạn thảo hay bảng tính, mỗi quy tắc có mã, phát biểu, loại, nguồn. "Implement a full-scale business rule management tool" là bước về sau, khi tổ chức có rất nhiều quy tắc và muốn quản lý tập trung, chi phí và công sức lớn nên không phải cách bắt đầu đơn giản nhất. "Use a requirements management tool" là cách phức tạp hơn một bậc, hợp khi muốn liên kết và truy vết quy tắc tới yêu cầu, nhưng cần công cụ và cấu hình. "Write business rules directly in application code" sai vì nhúng quy tắc vào mã khiến chúng khó tìm, khó dùng lại và khó sửa khi chính sách đổi; đó không phải cách quản lý quy tắc.

Đáp án đúng: "They are short and simple, avoiding "or" logic on the left-hand side and "and" logic on the right-hand side of "if/then" constructs, to facilitate reuse and modification.". Atomic business rule (quy tắc nghiệp vụ nguyên tử) là quy tắc không thể tách nhỏ hơn mà vẫn giữ nghĩa; quy tắc dạng nếu thì có điều kiện nối bằng hoặc nên tách thành nhiều quy tắc, kết quả nối bằng và cũng vậy, nhờ đó mỗi quy tắc dễ tái sử dụng, dễ sửa và dễ truy vết. "They combine multiple details into a single complex rule" ngược hẳn với tính nguyên tử, gộp nhiều chi tiết là thứ cần tránh. "They are primarily used for computational logic" sai vì tính nguyên tử áp dụng cho mọi loại quy tắc, từ fact, constraint tới inference, không riêng computation. "They are specific to a single software application and cannot be reused." sai vì quy tắc nghiệp vụ thuộc về tổ chức chứ không thuộc một ứng dụng, và viết nguyên tử chính là để dễ tái sử dụng.

Đáp án đúng: "Customer who came up with the idea about this requirement". Thuộc tính yêu cầu (requirement attributes) là các trường thông tin đi kèm mỗi yêu cầu để quản lý, theo danh mục thuộc tính chuẩn như ngày tạo, số phiên bản, tác giả, độ ưu tiên, trạng thái, nguồn gốc, lý do, bản phát hành dự kiến, phương pháp kiểm chứng. Cần nói thẳng: nguồn gốc (origin hoặc source) của yêu cầu cũng là một thuộc tính, nên có thể thấy phương án này gần đúng; nhưng cách ghi theo kiểu người khách hàng đã nảy ra ý tưởng không phải tên thuộc tính chuẩn, thuộc tính chuẩn ghi nguồn của yêu cầu chứ không ghi ai nghĩ ra ý tưởng, nên đây vẫn là phương án cần chọn. Phương án "Date the requirement was created" là thuộc tính chuẩn để biết yêu cầu xuất hiện khi nào. Phương án "Author who wrote the requirement" là thuộc tính chuẩn để biết ai chịu trách nhiệm nội dung và hỏi lại khi cần. Phương án "Status" là thuộc tính chuẩn theo dõi yêu cầu đang ở bước đề xuất, đã duyệt, đã cài đặt hay đã kiểm chứng.

Đáp án đúng: "To evaluate their effectiveness on a small scale". Trong chu trình cải tiến quy trình yêu cầu, sau khi đánh giá hiện trạng và thiết kế quy trình mới, tổ chức nên chạy thử (pilot) trên một dự án hoặc nhóm nhỏ trước khi áp dụng rộng; việc này cho thấy quy trình có hiệu quả thật không, bộc lộ chỗ cần điều chỉnh với rủi ro thấp và tạo bằng chứng thuyết phục người khác. Phương án "To ensure they are perfect before implementation" sai vì không quy trình nào hoàn hảo, thí điểm nhằm học hỏi và cải tiến dần. Phương án "To skip feedback from participants" ngược lại hoàn toàn, vì phản hồi của người tham gia chính là đầu ra quý nhất của thí điểm. Phương án "To create an abstract understanding without practical testing" sai vì thí điểm chính là kiểm nghiệm thực tế, không phải hiểu biết trừu tượng.