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

Đáp án đúng: "To save time, improve consistency, and reduce risks". Requirements reuse (tái sử dụng yêu cầu) là dùng lại những yêu cầu đã viết, đã rà soát, có khi đã kiểm chứng trên hệ thống trước, cho dự án mới; ví dụ yêu cầu bảo mật, đăng nhập, hay quy tắc nghiệp vụ chung. Lợi ích là bớt công khơi gợi và viết lại, các sản phẩm trong cùng tổ chức nhất quán hơn, và rủi ro thấp hơn vì yêu cầu đã được chứng minh chất lượng. "To eliminate stakeholder reviews" sai vì yêu cầu dùng lại vẫn phải được bên liên quan xem xét xem có phù hợp với bối cảnh mới không. "To finalize the coding phase" sai vì tái sử dụng yêu cầu thuộc phát triển yêu cầu, không nhằm chốt giai đoạn viết mã, dù đôi khi kéo theo dùng lại thiết kế và mã. "To reduce prototyping efforts" sai vì giảm làm prototype không phải mục đích chính; prototype vẫn có thể cần để thẩm định yêu cầu mới.

Đáp án đúng: "Junior business analyst". Requirements pattern (mẫu yêu cầu) là khuôn có sẵn cho một loại yêu cầu hay gặp, chỉ ra những thông tin cần có, cách diễn đạt và ví dụ, giúp viết yêu cầu đầy đủ, nhất quán ở bước đặc tả. Người hưởng lợi nhiều nhất là người phân tích nghiệp vụ còn ít kinh nghiệm, vì mẫu bù cho phần kinh nghiệm họ chưa có và nhắc họ những chi tiết dễ bỏ sót. "Project manager" chủ yếu lập kế hoạch và điều phối dự án, không trực tiếp viết yêu cầu nên ít dùng tới mẫu. "Deployment engineer" làm việc ở khâu triển khai, nhận yêu cầu đã hoàn chỉnh chứ không soạn chúng. "Marketing director" đóng góp góc nhìn thị trường và mục tiêu kinh doanh, có thể là nguồn yêu cầu nhưng không phải người dùng mẫu để đặc tả.

Đáp án đúng: "Baselined requirements". Đường cơ sở yêu cầu (requirements baseline) là tập yêu cầu đã được rà soát, thống nhất và cam kết cho một bản phát hành; nó trở thành trung tâm dẫn dắt mọi hoạt động khác: kế hoạch dự án ước lượng dựa trên nó, thiết kế và mã hiện thực nó, kiểm thử kiểm chứng theo nó, và mọi thay đổi đi qua kiểm soát thay đổi so với nó. Phương án "Project plans" sai vì kế hoạch được lập dựa trên yêu cầu, tức là sản phẩm phía sau. Phương án "Designs and code" sai vì thiết kế và mã được tạo ra để đáp ứng yêu cầu, không phải thứ dẫn dắt yêu cầu. Phương án "Tests" sai vì ca kiểm thử được suy ra từ yêu cầu để kiểm tra hệ thống có đúng yêu cầu hay không, nên cũng phụ thuộc vào yêu cầu đã chốt.

Đáp án đúng: "It t is one in which new capabilities are added to an existing system.". Enhancement project (dự án nâng cấp) bổ sung khả năng mới vào hệ thống đang chạy; yêu cầu ở đây tập trung vào tính năng mới, tác động tới phần đang có và việc tránh làm hỏng chức năng cũ. Phương án "It replaces an existing application with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those." mô tả replacement project (dự án thay thế), khi ứng dụng cũ bị thay bằng hệ thống tự xây, phần mềm đóng gói hoặc kết hợp. Phương án "It is most commonly implemented to improve performance, cut costs" nêu các lý do thường gặp để tiến hành dự án thay thế, không định nghĩa dự án nâng cấp. Phương án "It is building new releases of established commercial products." mô tả bối cảnh phát triển sản phẩm thương mại theo từng bản phát hành; các bản này có thể chứa cải tiến, nhưng dự án nâng cấp được xác định bởi việc thêm khả năng mới vào một hệ thống hiện có.

Đáp án đúng: "Data sources, formats, and integration points". Khi chọn một giải pháp đóng gói (packaged solution, tức phần mềm thương mại mua sẵn), việc phân tích yêu cầu dữ liệu phải trả lời dữ liệu đến từ đâu, ở định dạng nào và giải pháp phải trao đổi dữ liệu với hệ thống nào khác, vì gói phần mềm có mô hình dữ liệu riêng nên cần ánh xạ, chuyển đổi, di trú và tích hợp với dữ liệu sẵn có của tổ chức. "Only the storage capacity of the solution" sai vì chữ only thu hẹp vào dung lượng lưu trữ, một ràng buộc kỹ thuật nhỏ chứ không phải toàn bộ nhu cầu dữ liệu. "User access permissions" thuộc yêu cầu bảo mật (security), quan trọng khi cấu hình gói nhưng không cho biết dữ liệu nào cần có và luân chuyển ra sao. "The cost of data storage" là yếu tố chi phí trong quyết định mua, không mô tả bản thân nhu cầu dữ liệu.

Đáp án đúng: "Supplement written specifications with visual requirements models and prototypes.". Khi làm việc với đội thuê ngoài khác văn hoá và ngôn ngữ, văn bản dễ bị hiểu theo nhiều cách; bổ sung mô hình yêu cầu trực quan như sơ đồ, bảng quyết định và bản mẫu giúp truyền đạt ý nghĩa ít phụ thuộc vào câu chữ, nhờ đó giảm hiểu lầm. "Rely solely on written communication." sai vì chỉ dựa vào chữ viết chính là nguồn gây hiểu lầm lớn nhất khi người đọc không dùng tiếng mẹ đẻ. "Avoid face-to-face meetings to save travel costs." sai vì gặp mặt trực tiếp, nhất là giai đoạn đầu, giúp xây dựng quan hệ và làm rõ yêu cầu; tiết kiệm chi phí đi lại không bù được thiệt hại do hiểu sai. "Use only the native language of the outsourced party." khiến bên đặt hàng diễn đạt yêu cầu bằng ngôn ngữ mình không thạo, chỉ đẩy rủi ro hiểu lầm sang phía ngược lại.

Đáp án đúng gồm ba ý: "Understand the possible implications of the change", "Identify all affected requirements and documents" và "Estimate the effort needed for the change". Change impact analysis (phân tích tác động thay đổi) là bước trong kiểm soát thay đổi giúp ban kiểm soát thay đổi quyết định chấp nhận hay từ chối một yêu cầu thay đổi: trước hết hiểu các hệ quả có thể có của thay đổi, kể cả xung đột với yêu cầu khác; tiếp đó dùng truy vết yêu cầu để xác định mọi yêu cầu, thiết kế, mã, ca kiểm thử, tài liệu bị ảnh hưởng; sau đó ước lượng công sức để cài đặt thay đổi, làm cơ sở đánh giá chi phí và lịch. "Implement the change without stakeholder approval" sai vì đi ngược bản chất kiểm soát thay đổi: phân tích tác động diễn ra trước khi quyết định, và thay đổi chỉ được làm sau khi người có thẩm quyền phê duyệt.

Đáp án đúng: "Change impact analysis". Requirements tracing (truy vết yêu cầu) liên kết mỗi yêu cầu với nguồn gốc, với các yêu cầu liên quan và với thiết kế, mã, ca kiểm thử. Động lực chính là khi một yêu cầu cần sửa, nhờ các liên kết đó người ta lần ra được mọi sản phẩm bị ảnh hưởng để ước lượng công sức và rủi ro, tức là phân tích tác động thay đổi, một phần của quản lý yêu cầu và kiểm soát thay đổi. "Requirements elicitation" là khơi gợi yêu cầu ở đầu dự án, khi chưa có gì để truy vết. "User interface design" là hoạt động thiết kế, có thể nằm trong chuỗi truy vết nhưng không phải lý do cần truy vết. "Project budgeting" là lập ngân sách, có thể dùng kết quả phân tích tác động nhưng không phải hoạt động mà truy vết trực tiếp phục vụ khi sửa yêu cầu.

Đáp án đúng: "By considering both the likelihood of occurrence and potential impact of risks". Trong quản lý rủi ro, mỗi rủi ro được đánh giá theo xác suất xảy ra và mức tác động nếu xảy ra; tích của hai đại lượng (độ phơi nhiễm rủi ro, risk exposure) dùng để xếp hạng, nhờ đó nhóm tập trung giảm thiểu những rủi ro vừa dễ xảy ra vừa gây hại lớn. Phương án "By focusing on risks that are least likely to occur" sai vì dồn sức vào rủi ro ít xảy ra là ngược với mục đích ưu tiên. Phương án "By ignoring potential impact and only considering likelihood" sai vì một rủi ro ít khả năng nhưng hậu quả nặng vẫn có thể cần ưu tiên cao, bỏ qua tác động sẽ đánh giá lệch. Phương án "By assuming that all risks are equally important" sai vì coi mọi rủi ro như nhau là không xếp ưu tiên gì cả, nguồn lực giảm thiểu bị dàn trải.

Đáp án đúng: "Opportunity". Phương pháp Agile coi thay đổi yêu cầu là điều tất yếu và là cơ hội để sản phẩm sát với nhu cầu thật hơn; tuyên ngôn Agile đề cao phản hồi với thay đổi hơn bám theo kế hoạch, nên yêu cầu được làm mịn dần, ưu tiên lại ở mỗi vòng lặp qua product backlog. Phương án "Disruption" phản ánh góc nhìn coi thay đổi là sự xáo trộn cần ngăn chặn, ngược với tinh thần Agile. Phương án "Risk" sai vì dù thay đổi không kiểm soát có thể gây rủi ro, Agile chủ động đón nhận nó thông qua vòng lặp ngắn thay vì coi là mối đe dọa. Phương án "Expense" sai vì Agile giữ chi phí thay đổi thấp bằng cách giao từng phần nhỏ và nhận phản hồi sớm, không xem thay đổi chủ yếu là khoản tốn kém.

Đáp án đúng gồm ba ý: "Passing a defined set of acceptance tests based on user requirements", "Demonstrating satisfaction of specific nonfunctional requirements" và "Tracking open defects and issues". Acceptance criteria (tiêu chí chấp nhận) là các điều kiện khách quan để khách hàng hoặc người dùng quyết định sản phẩm đã đủ tốt để đưa vào vận hành hay chưa, gắn với hoạt động thẩm định (validation) yêu cầu. Vượt qua bộ acceptance test dựng từ yêu cầu người dùng chứng minh hệ thống làm được các nhiệm vụ người dùng cần; chứng minh thỏa mãn các yêu cầu phi chức năng cụ thể như hiệu năng, bảo mật, tính khả dụng cho thấy chất lượng đạt mức đã cam kết; còn theo dõi các lỗi và vấn đề còn mở giúp khẳng định không còn lỗi nghiêm trọng nào chặn việc phát hành. Phương án "Having a trendy user interface" không phải tiêu chí chấp nhận vì sự hợp thời là cảm nhận chủ quan, không kiểm chứng được và không xuất phát từ yêu cầu nghiệp vụ hay yêu cầu người dùng nào.

Đá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: "Making them too vague or unmeasurable". Yêu cầu phi chức năng, nhất là thuộc tính chất lượng, hay bị viết chung chung kiểu hệ thống phải thân thiện hoặc phải nhanh; câu như vậy không kiểm chứng được và mỗi người hiểu một kiểu. Cách khắc phục là định lượng: nêu đại lượng đo, cách đo và ngưỡng, ví dụ thời gian phản hồi dưới 2 giây cho 95% yêu cầu, hoặc dùng Planguage. "Prioritizing them over functional requirements" sai vì không có quy tắc nào cấm ưu tiên yêu cầu phi chức năng; tuỳ bối cảnh, bảo mật hay khả dụng có thể quan trọng hơn một chức năng phụ. "Writing them without stakeholder input" là một lỗi có thể xảy ra với mọi loại yêu cầu, không phải cạm bẫy đặc trưng của yêu cầu phi chức năng. "Skipping them in the documentation process" cũng là sai lầm có thật, nhưng câu hỏi hỏi lỗi khi viết chúng; khi đã viết, lỗi phổ biến nhất là mơ hồ và không đo được.

Đáp án đúng gồm hai ý: "They gather requirements from other members of the user classes they represent and reconcile inconsistencies." và "They serve as the primary interface between members of a single user class and the project’s business analyst.". Product champion (người đại diện sản phẩm) là người dùng chủ chốt được chọn để đại diện cho một user class (nhóm người dùng); họ là đầu mối chính giữa nhóm người dùng đó và người phân tích nghiệp vụ, thu thập yêu cầu từ những người dùng khác trong nhóm và hoà giải những ý kiến mâu thuẫn trước khi đưa cho nhóm dự án. "They implement the coding standards." sai vì tiêu chuẩn lập trình là việc của lập trình viên, product champion đứng ở phía người dùng. "They write requirements documents." không phải vai trò định nghĩa của họ: viết tài liệu yêu cầu chính thức là trách nhiệm của người phân tích nghiệp vụ, product champion chỉ cung cấp thông tin, góp ý và review.

Đáp án đúng: "A User Representative is a real individual from the user base who participates directly in the development process, while a User Persona is a fictional composite based on real data.". Người đại diện người dùng (user representative, như product champion) là một người thật thuộc một nhóm người dùng, tham gia trực tiếp để cung cấp và thẩm định yêu cầu thay mặt nhóm đó; chân dung người dùng (persona) là nhân vật hư cấu tổng hợp từ dữ liệu thật, dùng khi không tiếp cận được người dùng thật. Phương án "used only in testing, while a User Persona is used solely" sai vì cả hai đều phục vụ khơi gợi và thẩm định suốt dự án. Phương án "are exactly the same" sai vì một bên là người thật, một bên là nhân vật giả định. Phương án "employed to document technical requirements" sai vì người đại diện không viết yêu cầu kỹ thuật và persona không chỉ dùng thiết kế giao diện. Phương án "represents one individual only, while a User Persona represents an entire organization" sai vì người đại diện nói thay cả một nhóm người dùng, còn persona đại diện cho một nhóm người dùng chứ không phải cả tổ chức.

Đá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: "The business analyst". Quản lý yêu cầu (requirements management) gồm lập đường cơ sở (baseline), kiểm soát thay đổi, theo dõi trạng thái và truy vết yêu cầu; người thường giữ trách nhiệm dẫn dắt mảng này là chuyên viên phân tích nghiệp vụ, vì đó là người hiểu yêu cầu sâu nhất và đã làm chúng ra. "The project manager" phối hợp chặt và thường tham gia ban kiểm soát thay đổi, nhưng trách nhiệm chính của quản lý dự án là kế hoạch, lịch trình, nguồn lực và rủi ro, không phải duy trì bộ yêu cầu. "The developer" là người hiện thực hoá yêu cầu, góp ý về tác động kỹ thuật khi có thay đổi chứ không quản lý yêu cầu. "The quality assurance team" dùng yêu cầu để thiết kế kiểm thử và góp phần thẩm định, nhưng không dẫn dắt việc quản lý chúng.

Đáp án đúng: "To identify underlying issues in current practices". Root cause analysis (phân tích nguyên nhân gốc) là kỹ thuật dùng khi cải tiến quy trình yêu cầu: từ một vấn đề quan sát được, như nhiều lỗi do yêu cầu hay thay đổi liên tục, hỏi tiếp tại sao nhiều lần hoặc vẽ sơ đồ xương cá để tìm nguyên nhân sâu xa trong cách làm hiện tại, rồi chọn thực hành mới nhắm đúng nguyên nhân đó thay vì chữa triệu chứng. "To prioritize changes" sai vì xếp ưu tiên thay đổi là việc của ban kiểm soát thay đổi, dựa trên giá trị và chi phí, không phải mục đích của phân tích nguyên nhân gốc. "To assess stakeholder satisfaction" sai vì đo mức hài lòng dùng khảo sát hay phản hồi; kết quả đó có thể là triệu chứng đầu vào nhưng không phải điều kỹ thuật này tìm ra. "To define the scope of the project" sai vì phạm vi dự án được xác định qua tầm nhìn, sơ đồ ngữ cảnh, danh sách tính năng, không liên quan tới cải tiến quy trình.

Đáp án đúng: "Process Flows". Phân loại đơn giản về business rule (quy tắc nghiệp vụ) có năm loại: fact (sự thật đúng về nghiệp vụ), constraint (ràng buộc giới hạn hành động), action enabler (quy tắc kích hoạt hành động khi điều kiện thoả), inference (suy diễn ra tri thức mới từ điều kiện) và computation (công thức tính toán). Luồng quy trình mô tả trình tự công việc, là mô hình quy trình chứ không phải một loại quy tắc nghiệp vụ. "Facts" là loại đầu tiên, như mỗi đơn hàng có một mã duy nhất. "Constraints" là loại giới hạn, như sinh viên chỉ được đăng ký tối đa một số tín chỉ nhất định. "Computations" là quy tắc tính toán, như công thức chiết khấu theo số lượng. "Inferences" là quy tắc suy ra kết luận, như khách quá hạn thanh toán ba mươi ngày thì bị coi là tài khoản nợ xấu.