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

Đáp án đúng: "Eliciting, analyzing, documenting, and validating the needs of project stakeholders.". Business Analyst (BA, chuyên viên phân tích nghiệp vụ), còn gọi là requirements analyst, là người giữ vai trò chính trong kỹ nghệ yêu cầu: khơi gợi (elicitation) nhu cầu từ các bên liên quan, phân tích để làm rõ và phát hiện xung đột, viết thành đặc tả rồi thẩm định (validation) để chắc rằng yêu cầu phản ánh đúng điều họ cần. BA là cầu nối giữa phía khách hàng và đội phát triển, tập trung vào câu hỏi hệ thống phải làm gì. "Programming and testing software." là việc của lập trình viên và kiểm thử viên; BA có thể góp tiêu chí chấp nhận nhưng không viết mã hay chạy kiểm thử. "Designing system architecture and databases." thuộc về kiến trúc sư và người thiết kế, tức là quyết định hệ thống được xây như thế nào, một bước nằm sau khi yêu cầu đã rõ. "Managing project budget and schedule." là trách nhiệm của quản lý dự án (project manager); BA chỉ cung cấp yêu cầu làm đầu vào cho việc ước lượng và lập lịch chứ không nắm ngân sách hay tiến độ.

Đáp án đúng: "To define data items and structures with consistent definitions for all project stakeholders.". Data dictionary (từ điển dữ liệu) là kho tập trung định nghĩa từng phần tử dữ liệu và cấu trúc dữ liệu của miền bài toán: tên, ý nghĩa, kiểu, độ dài, miền giá trị, các thành phần cấu tạo nên nó. Công cụ này thuộc hoạt động phân tích và đặc tả yêu cầu dữ liệu, giúp khách hàng, người phân tích nghiệp vụ, lập trình viên và kiểm thử viên cùng hiểu một nghĩa duy nhất cho mỗi thuật ngữ dữ liệu, tránh mỗi nơi định nghĩa một kiểu. "To list all functional requirements in a project" sai vì danh sách yêu cầu chức năng nằm trong SRS hay product backlog, không phải trong từ điển dữ liệu. "To depict the sequence of process flows within a system" là việc của sơ đồ quy trình như activity diagram hay swimlane diagram. "To model user interface interactions." thuộc về mô hình giao diện như dialog map, wireframe hay prototype, không liên quan tới việc định nghĩa dữ liệu.

Đáp án đúng gồm hai ý: "More detail should be included when the work is being done for an external client or when system testing will be based on the requirements." và "Less detail can be included if the work is being done internally for your company and developers have considerable domain experience." Mức chi tiết của yêu cầu (level of detail) không cố định mà tuỳ bối cảnh: càng nhiều người đọc ở xa, càng ít cơ hội hỏi lại trực tiếp và càng nhiều thứ dựa vào tài liệu thì càng phải viết chi tiết. Khách hàng bên ngoài cần yêu cầu đủ rõ để làm căn cứ nghiệm thu và hợp đồng, còn kiểm thử hệ thống dựa trên yêu cầu thì cần đủ chi tiết để thiết kế ca kiểm thử. Ngược lại, dự án nội bộ với đội phát triển giàu kiến thức miền (domain experience) và gần người dùng có thể viết gọn hơn vì khoảng trống được lấp bằng trao đổi trực tiếp. Phương án "always necessary to specify all requirements at the same high level of detail" sai vì ép một mức chi tiết đồng nhất cho mọi yêu cầu, trong khi yêu cầu rủi ro cao mới cần chi tiết nhất. Phương án "fine-grained level is always better, regardless of the project’s context" sai vì chi tiết quá mức tốn công viết, khó bảo trì và không thêm giá trị khi người đọc đã hiểu rõ.

Đá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: "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: "A requirements effort estimation spreadsheet.". Seilevel, một công ty tư vấn chuyên về kỹ nghệ yêu cầu, xây dựng một bảng tính ước lượng công sức phát triển yêu cầu: người dùng nhập các đại lượng như số tác nhân, số quy trình nghiệp vụ, số màn hình hay số báo cáo dự kiến, bảng tính quy đổi ra số giờ cần cho khơi gợi, phân tích, đặc tả và thẩm định. Công cụ này phục vụ lập kế hoạch cho chính hoạt động phát triển yêu cầu, giúp BA và quản lý dự án dành đủ thời gian cho yêu cầu thay vì đoán mò. "A coding tool for developers." sai vì công cụ không liên quan tới viết mã, nó dùng ở giai đoạn yêu cầu. "A time-tracking tool for project managers." sai vì công cụ ghi giờ chỉ đo thời gian đã tiêu, còn bảng tính của Seilevel dự báo công sức trước khi làm. "A documentation tool for stakeholders." sai vì nó không dùng để soạn hay lưu tài liệu yêu cầu mà chỉ để ước lượng khối lượng việc.

Đáp án đúng: "By using clear, precise terms and avoiding vague language". Ambiguity (tính mơ hồ) xảy ra khi một yêu cầu có thể được hiểu theo nhiều cách khác nhau; một yêu cầu tốt phải unambiguous (không mơ hồ), nên khi đặc tả cần dùng từ chính xác, định lượng được, thống nhất với bảng thuật ngữ, và tránh các từ mơ hồ như nhanh, thân thiện, dễ dùng, hỗ trợ. Lỗi mơ hồ thường được phát hiện ở bước thẩm định qua review. "By including as many possible options as possible" sai vì đưa thêm nhiều lựa chọn chỉ khiến yêu cầu khó hiểu và khó kiểm thử hơn. "By being flexible in interpretation" đi ngược mục tiêu, vì cho phép diễn giải linh hoạt chính là bản chất của sự mơ hồ. "By relying on user preferences" không giải quyết chuyện cách viết: sở thích người dùng là nguồn của yêu cầu, còn yêu cầu vẫn phải được viết rõ ràng để mọi người hiểu như nhau.

Đáp án đúng: "Extent of assets, extent of modification, and mechanism of reuse.". Tái sử dụng yêu cầu (requirements reuse) được mô tả theo ba chiều: phạm vi tài sản được dùng lại (từ một câu yêu cầu lẻ tới cả bộ yêu cầu kèm mô hình, thiết kế, mã và ca kiểm thử), mức độ phải sửa đổi khi dùng lại (giữ nguyên hay chỉnh cho dự án mới) và cơ chế tái sử dụng (sao chép rồi dán vào tài liệu mới hay tham chiếu tới một kho yêu cầu dùng chung). Phương án "Scope, cost, and risk." là các yếu tố quản lý dự án, dùng để cân nhắc có nên tái sử dụng hay không chứ không phải chiều phân loại cách tái sử dụng. Phương án "Technical, business, and user levels" gợi tới các tầng yêu cầu (business, user, functional), tức là phân loại bản thân yêu cầu chứ không mô tả việc dùng lại chúng. Phương án "Elicitation, analysis, and validation." là các hoạt động của phát triển yêu cầu (khơi gợi, phân tích, thẩm định), không phải chiều của tái sử dụng.

Đáp án đúng: "To provide a consistent structure for recording various groups of requirements-related information and to serve as a reminder of information to explore". Khuôn mẫu SRS (Software Requirements Specification, đặc tả yêu cầu phần mềm) chuẩn chia tài liệu thành các mục cố định như giới thiệu, mô tả tổng quát, tính năng hệ thống, yêu cầu dữ liệu, giao diện ngoài, thuộc tính chất lượng, nhờ đó mọi dự án ghi thông tin yêu cầu theo cùng một cấu trúc dễ tra cứu, đồng thời mỗi mục trống nhắc người phân tích còn chủ đề nào chưa khơi gợi. Phương án "To enforce a rigid document structure that cannot be changed" sai vì khuôn mẫu cần được điều chỉnh theo quy mô và loại dự án, được phép bỏ hoặc thêm mục. Phương án "To eliminate the need for any analysis activities" sai vì khuôn mẫu chỉ là nơi chứa kết quả, việc phân tích yêu cầu vẫn phải làm để có nội dung điền vào. Phương án "To ensure that the SRS is always a traditional paper document." sai vì SRS có thể nằm trong công cụ quản lý yêu cầu, wiki hay cơ sở dữ liệu, khuôn mẫu không ràng buộc hình thức lưu trữ.

Đáp án đúng gồm ba ý: "Primitive", "Structure" và "Repeating group". Từ điển dữ liệu (data dictionary) là kho định nghĩa tập trung các phần tử dữ liệu của hệ thống, dùng trong phân tích và đặc tả yêu cầu dữ liệu. Mỗi mục thuộc một trong các loại: phần tử nguyên thuỷ là đơn vị không chia nhỏ được nữa, như mã khách hàng, kèm kiểu, độ dài và miền giá trị; cấu trúc là phần tử ghép từ nhiều phần tử khác, như địa chỉ gồm số nhà, đường, thành phố; nhóm lặp là danh sách nhiều thể hiện của một phần tử hay cấu trúc, như nhiều dòng hàng trong một đơn hàng, thường ghi kèm số lần lặp tối thiểu và tối đa. "Virtual" không phải một loại mục của từ điển dữ liệu; khái niệm ảo như bảng ảo (view) thuộc thiết kế cơ sở dữ liệu, không phải cách phân loại phần tử dữ liệu ở mức yêu cầu.

Đáp án đúng: "subset". Stakeholder (bên liên quan) là bất kỳ cá nhân, nhóm hay tổ chức nào bị ảnh hưởng bởi dự án hoặc có ảnh hưởng tới nó: khách hàng, người dùng cuối, nhà tài trợ, đội phát triển, kiểm thử, cơ quan quản lý, bộ phận hỗ trợ. Customer (khách hàng) là những bên liên quan trực tiếp hoặc gián tiếp nhận lợi ích từ sản phẩm, như người trả tiền, người chọn mua hay người dùng; vì vậy mọi khách hàng đều là bên liên quan nhưng không phải bên liên quan nào cũng là khách hàng, tức khách hàng là một tập con của bên liên quan. "representative" sai vì đại diện là người được chọn để nói thay cho một nhóm người dùng, ví dụ product champion, đó là vai trò khi khơi gợi chứ không phải quan hệ tập hợp. "partner" sai vì đối tác chỉ quan hệ hợp tác, không nói được rằng khách hàng nằm bên trong nhóm bên liên quan. "equivalent" sai vì hai khái niệm không trùng nhau: lập trình viên hay cơ quan quản lý là bên liên quan nhưng không phải khách hàng.

Đáp án đúng: "External: Usability; Internal: Verifiability.". Thuộc tính chất lượng bên ngoài (external quality attribute) là thứ người dùng cảm nhận được khi vận hành hệ thống, như availability, installability, integrity, interoperability, performance, reliability, robustness, safety, security, usability; thuộc tính bên trong (internal) chủ yếu nhà phát triển và người bảo trì cảm nhận, như efficiency, modifiability, portability, reusability, scalability, verifiability. Usability là bên ngoài và verifiability (khả năng kiểm chứng) là bên trong nên cặp này đúng. "External: Performance; Internal: Security." sai vì security cũng là thuộc tính bên ngoài. "External: Reliability; Internal: Installability." sai vì installability là trải nghiệm cài đặt người dùng thấy trực tiếp, thuộc nhóm bên ngoài. "External: Portability; Internal: Scalability." sai vì portability là thuộc tính bên trong, đảo vị trí so với cách phân loại.

Đáp án đúng: "They are often ambiguous and difficult to quantify.". Yêu cầu phi chức năng (non-functional requirements), nhất là thuộc tính chất lượng như hiệu năng, khả dụng, bảo mật, thường được người dùng nói bằng lời mơ hồ kiểu "phải nhanh", "phải dễ dùng"; khó khăn chính khi khơi gợi (elicitation) là biến những mong muốn đó thành tiêu chí đo được, có thang đo và ngưỡng chấp nhận để kiểm chứng. Phương án "They are less important than functional requirements." sai vì thuộc tính chất lượng thường quyết định người dùng có chấp nhận hệ thống hay không. Phương án "They focus only on system design." sai vì chúng mô tả hệ thống phải tốt tới mức nào khi vận hành, còn thiết kế là cách đáp ứng chúng. Phương án "They do not require stakeholder input." sai vì chỉ các bên liên quan mới biết mức chất lượng nào chấp nhận được, nên phải hỏi họ.

Đáp án đúng gồm ba ý: "It is a partial implementation of a proposed new product.", "It is a possible implementation of a proposed new product." và "It is a preliminary implementation of a proposed new product.". Software prototype (bản mẫu phần mềm) là một hiện thực hóa mang tính thăm dò của sản phẩm định làm: nó chỉ dựng một phần (partial) như vài màn hình hay một luồng xử lý, nó là một cách hiện thực khả dĩ (possible) để người dùng nhìn thấy và phản hồi, và nó là bản sơ bộ (preliminary) làm trước khi phát triển thật. Prototype được dùng trong khơi gợi và thẩm định yêu cầu, giúp làm rõ chỗ mơ hồ và giảm rủi ro hiểu sai. Phương án "It is a complete implementation of a proposed new product." sai vì nếu đã hiện thực đầy đủ thì đó là sản phẩm chứ không còn là bản mẫu; giá trị của prototype nằm ở chỗ làm nhanh, rẻ, chỉ đủ để học hỏi, có thể vứt bỏ hoặc tiến hóa dần.

Đáp án đúng: "Decisions in a Decision Tree". Khi đọc văn bản yêu cầu để chọn mô hình phân tích, các từ chỉ điều kiện như if, when, unless báo hiệu logic rẽ nhánh, nên ánh xạ tự nhiên sang nút quyết định trong cây quyết định (decision tree) hoặc bảng quyết định (decision table), nơi mỗi nhánh ứng với một tổ hợp điều kiện và hành động kèm theo. "Processes in a DFD" sai vì tiến trình trong sơ đồ luồng dữ liệu thường ứng với động từ chỉ hành động biến đổi dữ liệu, như tính toán hay ghi nhận. "Entities in an ERD" ứng với danh từ chỉ đối tượng dữ liệu cần lưu, như hoá chất hay nhà cung cấp. "Transitions in a State Transition Diagram" ứng với sự kiện làm một đối tượng đổi trạng thái; điều kiện chỉ xuất hiện ở đó dưới dạng điều kiện canh (guard) gắn trên một chuyển trạng thái, còn một điều kiện nghiệp vụ đứng riêng như ví dụ thì cây quyết định biểu diễn trực tiếp hơn.

Đáp án đúng: "Use Cases describe the interactions between the system and external entities.". Use case (ca sử dụng) mô tả một chuỗi tương tác giữa tác nhân (actor) bên ngoài, có thể là người dùng hay hệ thống khác, với hệ thống để đạt được một mục tiêu có giá trị cho tác nhân. Đây là kỹ thuật thu nhận yêu cầu người dùng (user requirements), dùng trong khơi gợi và phân tích. "Use Cases are static and do not evolve throughout the software development process." sai vì ca sử dụng được tinh chỉnh dần: ban đầu chỉ có tên và mô tả ngắn, sau đó thêm luồng chính, luồng thay thế, ngoại lệ và có thể đổi khi hiểu biết thay đổi. "Use case diagrams are the primary tool to document requirements" sai vì sơ đồ ca sử dụng chỉ là bức tranh tổng quan về phạm vi và các tác nhân; giá trị nằm ở phần đặc tả bằng văn bản, và yêu cầu chức năng chi tiết vẫn phải ghi trong SRS. "Use Cases are not useful in capturing user requirements." sai vì thu nhận yêu cầu người dùng chính là công dụng chủ yếu của ca sử dụng, giúp tập trung vào việc người dùng cần làm thay vì vào tính năng rời rạc.

Đáp án đúng: "Data dictionary". Định nghĩa trong câu hỏi, tập hợp các định nghĩa cho phần tử dữ liệu và cấu trúc dữ liệu liên quan tới miền bài toán, chính là từ điển dữ liệu: nơi ghi tên, ý nghĩa, kiểu, độ dài, miền giá trị và thành phần của từng mục dữ liệu, dùng trong phân tích và đặc tả yêu cầu dữ liệu để mọi bên hiểu thống nhất. "Data flow diagram" là sơ đồ luồng dữ liệu, mô tả dữ liệu đi qua các tiến trình, kho dữ liệu và thực thể ngoài, tức là hành vi xử lý chứ không phải định nghĩa từng mục dữ liệu. "Database" là nơi lưu trữ dữ liệu thật khi hệ thống chạy, thuộc thiết kế và cài đặt, không phải tài liệu định nghĩa yêu cầu. "Relationship" chỉ là mối quan hệ giữa các thực thể trong sơ đồ ERD, một thành phần nhỏ của mô hình dữ liệu chứ không phải tập định nghĩa.

Đá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: "To ensure requirements align with business objectives and user needs". Requirements validation (thẩm định yêu cầu) trả lời câu hỏi chúng ta có đang làm đúng sản phẩm hay không, tức yêu cầu có thật sự phản ánh mục tiêu kinh doanh và nhu cầu người dùng. Chỉ các bên liên quan mới xác nhận được điều đó, nên phản hồi của họ qua rà soát, prototype hay acceptance test là trung tâm của hoạt động này. Phương án "To finalize coding strategies" sai vì chiến lược viết mã là việc của thiết kế và hiện thực, không phải mục đích lấy ý kiến bên liên quan. Phương án "To skip ambiguous requirements" sai vì yêu cầu mơ hồ phải được làm rõ hoặc sửa, không được bỏ qua. Phương án "To prioritize testing phases" sai vì sắp xếp các pha kiểm thử là việc lập kế hoạch kiểm thử; phản hồi của bên liên quan có thể giúp ưu tiên yêu cầu nhưng không nhằm mục đích này.

Đáp án đúng: "GOAL". Planguage là ngôn ngữ do Tom Gilb đề xuất để đặc tả định lượng thuộc tính chất lượng bằng các từ khoá. Trong cách dùng Planguage cho yêu cầu chất lượng, từ khoá GOAL ghi mức đạt tối thiểu chấp nhận được của thuộc tính trên thang đo đã định, tức là mức sản phẩm bắt buộc phải đạt để được chấp nhận; bên trên nó là STRETCH cho mức mong muốn hơn và WISH cho mức lý tưởng. "SCALE" sai vì nó định nghĩa thang đo của thuộc tính, chẳng hạn số giây hay phần trăm giao dịch, chứ không đặt ra mức cần đạt. "AMBITION" chỉ là phát biểu định tính ngắn về ý định cải thiện, chưa có con số. "WISH" là mức mong muốn lý tưởng nếu không bị giới hạn chi phí hay thời gian, cao hơn mức cam kết nên không thể là mức tối thiểu.