Câu hỏi: SWR302 - Phần 6: Đặc tả yêu cầu và cách viết yêu cầu tốt

Đá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: "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: "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ứ đó.

Đáp án đúng: "Hardware Manufacturers". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là tài liệu nhiều đối tượng cùng dùng: khách hàng và marketing kiểm tra sản phẩm đúng nhu cầu, quản lý dự án lập kế hoạch, lập trình viên biết cần xây gì, kiểm thử viên viết ca kiểm thử, người viết tài liệu soạn hướng dẫn, nhân viên pháp lý rà các yêu cầu tuân thủ, nhà thầu phụ làm theo hợp đồng. Nhà sản xuất phần cứng không nằm trong nhóm đọc SRS của một sản phẩm phần mềm. "Project Managers" dùng SRS để ước lượng, lập lịch và kiểm soát phạm vi. "Testers" dựa vào SRS để thiết kế ca kiểm thử và xác nhận hệ thống. "Legal Staff" đọc SRS để bảo đảm yêu cầu tuân thủ luật và quy định. "Documentation Writers" dựa vào SRS để viết hướng dẫn sử dụng và tài liệu trợ giúp.

Đáp án đúng gồm ba ý: "It allows us to refer to specific requirements in a change request, modification history, cross-reference, or requirements traceability matrix.", "It enables reusing the requirements in multiple projects." và "It facilitates collaboration between team members when they’re discussing requirements.". Gán nhãn định danh duy nhất (unique identifier) cho từng yêu cầu trong SRS là thực hành của đặc tả và quản lý yêu cầu: có nhãn ổn định thì yêu cầu được trỏ tới chính xác trong yêu cầu thay đổi, lịch sử sửa đổi, tham chiếu chéo và ma trận truy vết; được gọi lại khi tái sử dụng ở dự án khác; và khi thảo luận mọi người nói cùng một yêu cầu mà không phải chép lại cả câu. Phương án "It makes the SRS look more professional." sai vì vẻ chuyên nghiệp không phải lý do kỹ thuật; nhãn có giá trị vì giúp truy vết và quản lý thay đổi, không phải để trang trí tài liệu.

Đáp án đúng: "Logical data model". Theo khuôn SRS (đặc tả yêu cầu phần mềm) chuẩn, mục Data requirements (yêu cầu dữ liệu) là phần cố định chứa logical data model (mô hình dữ liệu logic) và từ điển dữ liệu, nên đây là thành phần chắc chắn thuộc SRS. Có tài liệu ôn tập chọn "Usecase descripions", và mô tả ca sử dụng đôi khi được đính kèm SRS, nhưng theo cách tách tài liệu chuẩn chúng thường nằm ở tài liệu yêu cầu người dùng, còn SRS mô tả các yêu cầu chức năng dẫn xuất từ đó; vì vậy mô hình dữ liệu logic mới là mục cố định của SRS. Phương án "Vision statement", "Succes metrics" và "Limitations and exclusions" đều thuộc tài liệu tầm nhìn và phạm vi (vision and scope document): tuyên bố tầm nhìn nêu sản phẩm hướng tới đâu, chỉ số thành công đo mục tiêu kinh doanh, còn giới hạn và loại trừ xác định những gì không làm.

Đáp án đúng gồm hai ý: "Use a consistent format for documenting requirements to enhance clarity and understanding among all stakeholders." và "The software requirements specification (SRS) should be used to formally record the agreed-upon requirements and ensure all stakeholders have a shared understanding.". Trong hoạt động đặc tả (specification), yêu cầu nên được viết theo một khuôn và phong cách thống nhất để người đọc dễ tìm, dễ hiểu và dễ rà soát, và tài liệu SRS là nơi chính thức ghi lại các yêu cầu đã được thống nhất, làm cơ sở chung cho thiết kế, kiểm thử và quản lý thay đổi. Phương án đòi "documented in multiple places to increase visibility" sai vì ghi một yêu cầu ở nhiều nơi gây trùng lặp, khi sửa một chỗ mà quên chỗ khác sẽ sinh mâu thuẫn; nên ghi một lần rồi tham chiếu. Phương án "Avoid documenting requirements that involve complex logic" sai vì logic phức tạp càng cần đặc tả rõ, có thể dùng bảng quyết định hay cây quyết định để trình bày dễ hiểu.

Đáp án đúng: "Inconsistent behavior is implemented". Yêu cầu mơ hồ (ambiguous) cho phép nhiều cách hiểu; khi các nhà phát triển khác nhau hiện thực theo cách hiểu riêng của mình, các phần của hệ thống sẽ hành xử không nhất quán với nhau và có thể không khớp mong đợi của khách hàng, buộc phải làm lại. Vì thế yêu cầu tốt phải rõ ràng, chỉ có một cách hiểu. "The software works better" sai vì diễn giải khác nhau chỉ sinh lỗi và mâu thuẫn, không làm phần mềm tốt hơn. "Developers work faster" sai vì có thể nhanh lúc đầu nhưng sau đó tốn công sửa, tổng thời gian tăng. "Ambiguities go unnoticed" mô tả điều kiện dẫn tới vấn đề, tức mơ hồ không được phát hiện khi rà soát, chứ không phải hậu quả khi nhà phát triển đã hiện thực theo nhiều cách khác nhau.

Đáp án đúng: "To identify and address missing or unclear requirements". Một tài liệu đặc tả yêu cầu phần mềm (SRS) tốt phải đầy đủ; xử lý sự thiếu hoàn chỉnh nghĩa là tìm ra yêu cầu còn thiếu hoặc chưa rõ, đánh dấu chỗ chưa biết bằng TBD, giao người chịu trách nhiệm và giải quyết trước khi xây dựng, vì yêu cầu thiếu là nguồn lỗi tốn kém nhất. "To eliminate unnecessary requirements" là việc cắt bỏ yêu cầu ngoài phạm vi hoặc không mang giá trị, ngược hướng với bổ sung chỗ thiếu. "To finalize the system design" sai vì thiết kế là hoạt động sau đặc tả, không phải mục đích của việc rà soát độ đầy đủ yêu cầu. "To prepare for testing and validation" là lợi ích gián tiếp, vì SRS đầy đủ giúp viết kiểm thử tốt hơn, nhưng không phải mục đích trực tiếp của việc xử lý thiếu sót.

Đáp án đúng: "To outline the system’s requirements". Software Requirements Specification (SRS, đặc tả yêu cầu phần mềm) là tài liệu tập hợp các yêu cầu của hệ thống: yêu cầu chức năng, yêu cầu phi chức năng, giao diện ngoài, ràng buộc thiết kế và cài đặt. Nó trả lời câu hỏi hệ thống phải làm gì và tốt đến mức nào, làm cơ sở chung cho thiết kế, kiểm thử và quản lý dự án. "To define the software’s architecture" sai vì kiến trúc phần mềm là quyết định thiết kế, ghi trong tài liệu kiến trúc hay thiết kế, nằm sau SRS. "To provide a project management plan" sai vì kế hoạch dự án gồm lịch, nguồn lực, rủi ro là tài liệu riêng; SRS chỉ là đầu vào để lập kế hoạch đó. "To describe the system’s user interface" sai vì SRS có thể có mục giao diện người dùng, nhưng đó chỉ là một phần nhỏ, không phải mục đích của cả tài liệu; thiết kế màn hình chi tiết thường nằm ở tài liệu riêng.

Đáp án đúng: "Write in simple language, avoid jargon, and keep sentences short and direct.". Hướng dẫn viết yêu cầu rõ ràng khuyên dùng câu ngắn, ngôn ngữ đơn giản, tránh thuật ngữ khó hiểu với người đọc, mỗi câu diễn đạt một ý để ai đọc cũng hiểu như nhau; đây là kỹ năng của bước đặc tả. "Use long, descriptive sentences to cover all aspects of a requirement." sai vì câu dài dễ gộp nhiều yêu cầu và gây mơ hồ. "Avoid using “shall” or “must” in favor of softer terms like “could” and “may.”" sai vì từ mềm làm người đọc không biết yêu cầu có bắt buộc không; từ shall hay must dùng nhất quán mới thể hiện rõ mức bắt buộc. "Use multiple terms for the same concept to make the document more interesting." sai vì tài liệu yêu cầu cần dùng một thuật ngữ thống nhất cho mỗi khái niệm, đổi từ sẽ khiến người đọc tưởng là hai khái niệm khác nhau.

Đáp án đúng: ""User-friendly"". Một yêu cầu tốt phải kiểm chứng được (verifiable), tức có cách kiểm thử hoặc đo xem hệ thống có đáp ứng hay không. Từ "thân thiện với người dùng" là thuật ngữ mơ hồ điển hình vì mỗi người hiểu một kiểu; nên thay bằng tiêu chí đo được, ví dụ người dùng mới hoàn thành đặt hàng trong ba phút mà không cần hướng dẫn. Phương án "The system shall" là cụm chuẩn để viết yêu cầu chức năng, chỉ rõ hệ thống chịu trách nhiệm, không gây mơ hồ. Phương án "The user shall" mô tả việc người dùng làm, có thể không nên dùng để viết yêu cầu hệ thống nhưng bản thân nó không phải từ ngữ mơ hồ. Phương án "Error message" là một khái niệm cụ thể; nội dung thông báo lỗi cần được đặc tả rõ, nhưng thuật ngữ này không khiến yêu cầu không kiểm chứng được.