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

Đá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: "There are matters that should be, but are not, elicited through the elicitation process. They exist, but they are not realized.". Yêu cầu ngầm (implicit requirements) là những điều người dùng mong đợi nhưng không nói ra; khi cả người dùng lẫn người phân tích đều không nhận ra chúng tồn tại thì chúng là ẩn số không biết (unknown unknowns): có thật, đáng lẽ phải khơi gợi được, nhưng chưa ai ý thức về chúng. Phương án "customers should always be required to spell out their unknown unknowns" sai vì không thể bắt khách hàng nêu điều chính họ không biết. Phương án "cannot be known and therefore we can not make them explicit requirements" sai vì qua khơi gợi kỹ, bản mẫu, rà soát, ẩn số vẫn có thể lộ ra và được viết thành yêu cầu tường minh. Phương án "They help us reveal both known unknowns and more unknown unknowns." sai vì yêu cầu ngầm không phải công cụ phát hiện, chúng là thứ cần được phát hiện.

Đá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.

Đáp án đúng: "By visualizing requirements and identifying inconsistencies or gaps". Mô hình phân tích như sơ đồ luồng dữ liệu, sơ đồ trạng thái, mô hình dữ liệu hay bảng quyết định biểu diễn yêu cầu dưới dạng hình ảnh, giúp người đọc thấy cấu trúc và quan hệ mà văn bản che khuất; khi vẽ mô hình, chỗ thiếu bước, trạng thái không có đường ra hay dữ liệu không ai tạo sẽ lộ ra, nên đây là công cụ mạnh của hoạt động phân tích. "By prioritizing coding over documentation" sai vì mô hình hoá chính là một dạng tài liệu phân tích, không liên quan tới việc ưu tiên viết mã. "By finalizing all functional requirements early" sai vì mô hình hỗ trợ làm rõ yêu cầu, không nhằm chốt sớm mọi thứ. "By reducing stakeholder engagement" sai vì mô hình còn là phương tiện để trao đổi và xác nhận với bên liên quan, làm họ tham gia nhiều hơn.

Đáp án đúng: "State-transition diagram". State-transition diagram (sơ đồ chuyển trạng thái) biểu diễn các trạng thái mà hệ thống hay một đối tượng có thể ở, các chuyển tiếp hợp lệ giữa chúng và sự kiện, điều kiện kích hoạt mỗi chuyển tiếp; ví dụ đơn hàng đi từ mới tạo sang đã thanh toán, đã giao, đã huỷ. Nó giúp phát hiện chuyển tiếp thiếu hay không được phép. "Entity-relationship diagram" sai vì sơ đồ thực thể quan hệ mô hình hoá dữ liệu và quan hệ giữa các thực thể, không thể hiện trạng thái. "Swimlane diagram" sai vì sơ đồ làn bơi mô tả các bước quy trình và ai thực hiện bước nào. "Data flow diagram" sai vì sơ đồ luồng dữ liệu cho thấy dữ liệu đi qua các tiến trình và kho dữ liệu ra sao, không nói về trạng thái. "Dialog map" sai vì dù cũng dùng ý tưởng trạng thái, sơ đồ hội thoại chỉ dành cho giao diện người dùng, mô tả các màn hình và cách điều hướng giữa chúng, không phải trạng thái của hệ thống và đối tượng nói chung.

Đáp án đúng: "Through a process bubble, not directly between data stores or between external entities and data stores.". Quy tắc của data flow diagram là dữ liệu chỉ được biến đổi bởi tiến trình, nên mỗi luồng dữ liệu phải có ít nhất một đầu là tiến trình; không được vẽ luồng trực tiếp giữa hai kho dữ liệu, giữa thực thể ngoài và kho dữ liệu, hay giữa hai thực thể ngoài. "Directly from one process to another." là luồng hợp lệ trong DFD, nhưng nó chỉ là một trường hợp riêng và không nêu được quy tắc chung mà câu hỏi muốn hỏi về cách luồng dữ liệu đi giữa tiến trình, kho dữ liệu và thực thể ngoài. "Directly from one data store to another." vi phạm quy tắc vì dữ liệu không thể tự di chuyển giữa hai kho mà không qua tiến trình nào xử lý. "Directly between external entities and data stores." cũng vi phạm, vì thực thể ngoài muốn đọc ghi kho dữ liệu phải đi qua một tiến trình của hệ thống.

Đáp án đúng: "A rectangle". Trong sơ đồ thực thể quan hệ (ERD), thực thể (entity) là một đối tượng hay khái niệm mà hệ thống cần lưu dữ liệu, như khách hàng, đơn hàng, sản phẩm, và được vẽ bằng hình chữ nhật mang tên thực thể; các ký pháp phổ biến như Chen hay chân chim (crow's foot) đều dùng hình chữ nhật cho thực thể. Phương án "A diamond shape" sai vì hình thoi trong ký pháp Chen biểu diễn mối quan hệ (relationship) giữa các thực thể. Phương án "An oval shape" sai vì hình bầu dục trong ký pháp Chen biểu diễn thuộc tính (attribute) của thực thể. Phương án "A hexagon shape" sai vì hình lục giác không phải ký hiệu chuẩn cho thực thể trong các ký pháp ERD thông dụng.

Đá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: "A condition that must be satisfied or a state the system must be in before a use case can begin.". Trong đặc tả ca sử dụng, pre-condition (tiền điều kiện) là điều phải đúng trước khi ca bắt đầu, ví dụ người dùng đã đăng nhập; hệ thống không kiểm tra lại nó trong luồng chính mà mặc định nó đã thỏa. Phương án "A condition that describes the state of a system after a use case is successfully completed." là định nghĩa post-condition (hậu điều kiện), mô tả trạng thái sau khi ca kết thúc thành công. Phương án "A condition that initiates execution of the use case" là trigger (sự kiện kích hoạt), thứ khiến ca bắt đầu chạy, khác với điều kiện phải có sẵn. Phương án "A condition that must be satisfied so that system run successful." quá chung chung, nói về việc hệ thống chạy thành công nói chung, không gắn với thời điểm trước khi một ca sử dụng bắt đầu.

Đáp án đúng: "It is a language with a rich set of keywords that permits precise statements of quality attributes and other project goals.". Planguage là ngôn ngữ đặc tả do Tom Gilb đề xuất, dùng các từ khoá như TAG, GIST, SCALE, METER, MUST, PLAN, WISH để viết thuộc tính chất lượng sao cho đo được: chỉ rõ đại lượng đo, cách đo, mức tối thiểu chấp nhận và mức mong muốn. Nó giúp tránh các câu mơ hồ kiểu "hệ thống phải nhanh". "It is a programming language." sai vì Planguage không biên dịch hay chạy được, nó chỉ dùng để viết yêu cầu. "It is a planning language used in project management." sai vì dù tên gợi chữ planning, nó không dùng để lập lịch hay phân bổ nguồn lực mà để đặc tả mục tiêu định lượng. "It is a language to express non functional requirements." chỉ đúng một phần: Planguage hay được dùng cho yêu cầu phi chức năng, nhưng phát biểu này thiếu điểm cốt lõi là bộ từ khoá phong phú cho phép viết chính xác, và nó còn áp dụng cho các mục tiêu dự án khác chứ không riêng yêu cầu phi chức năng, nên không phải mô tả đầy đủ nhất.

Đáp án đúng: "A more desirable performance objective than the minimum goal". Trong Planguage, ngôn ngữ đặc tả định lượng thuộc tính chất lượng, STRETCH là mức mục tiêu thách thức, đáng mong muốn hơn mức mục tiêu đã cam kết; đạt được thì tốt nhưng không bắt buộc, giúp đội biết hướng cải thiện thêm khi điều kiện cho phép. "The ideal performance level" gần với nghĩa của từ khoá WISH, tức mức lý tưởng nếu không có giới hạn chi phí hay thời gian, cao hơn và xa vời hơn STRETCH. "A benchmark for testing" không phải ý nghĩa của STRETCH; cách đo và kiểm chứng giá trị được mô tả bằng các từ khoá như SCALE và METER. "A failure condition" ứng với từ khoá FAIL, mức mà dưới đó sản phẩm bị coi là không chấp nhận được, ngược hẳn với một mục tiêu thách thức.

Đáp án đúng: "Order products.". Yêu cầu chức năng (functional requirement) mô tả hành vi hệ thống phải có, tức việc hệ thống làm hoặc cho phép người dùng làm; đặt mua sản phẩm là một chức năng cụ thể, có đầu vào, xử lý và kết quả. "Portability." là thuộc tính chất lượng, yêu cầu phi chức năng, nói về mức dễ chuyển hệ thống sang môi trường, nền tảng khác. "Maintainability." là thuộc tính chất lượng nói về mức dễ sửa lỗi, cải tiến, thay đổi phần mềm. "Security." là thuộc tính chất lượng nói về việc chống truy cập trái phép và bảo vệ dữ liệu; nó có thể sinh ra yêu cầu chức năng như đăng nhập, nhưng bản thân bảo mật là phi chức năng. "Robustness." là thuộc tính chất lượng nói về khả năng hệ thống tiếp tục hoạt động đúng khi gặp đầu vào sai hay điều kiện bất thường. Các thuộc tính này mô tả hệ thống làm tốt đến mức nào, không mô tả hệ thống làm gì.

Đáp án đúng: "Evolutionary prototypes". Prototype được phân loại theo ba chiều: phạm vi (mock-up hay proof of concept), mục đích sử dụng về sau (throwaway hay evolutionary) và hình thức (paper hay electronic, độ trung thực thấp hay cao). Theo chiều sử dụng về sau, nguyên mẫu được phát triển dần qua các vòng lặp để trở thành sản phẩm thật là evolutionary prototype (nguyên mẫu tiến hoá), hợp với nhu cầu nghiệp vụ thay đổi nhanh. "Throwaway mock-ups" bị bỏ đi sau khi đã làm rõ yêu cầu, không phát triển thành sản phẩm. "Paper prototypes" là hình thức vẽ trên giấy, thuộc chiều hình thức và không thể trở thành sản phẩm. "Proof-of-concept prototypes" thuộc chiều phạm vi, dùng để kiểm tra tính khả thi kỹ thuật. "High-fidelity prototypes" nói về độ trung thực so với giao diện thật, không trả lời câu hỏi về mục đích sử dụng về sau.

Đá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: "horizontal, vertical". Mock-up là prototype ngang (horizontal prototype): nó trải rộng trên giao diện người dùng, mô phỏng màn hình và cách điều hướng nhưng không có logic xử lý thật phía sau, dùng để khơi gợi và thẩm định yêu cầu về trải nghiệm người dùng. Proof of concept là prototype dọc (vertical prototype): nó cắt sâu qua mọi tầng kỹ thuật, từ giao diện tới xử lý và dữ liệu, cho một phần nhỏ chức năng, để chứng minh một cách tiếp cận kỹ thuật là khả thi. "vertical, horizontal" sai vì đảo ngược hai khái niệm trên. "primary, secondary" sai vì đây không phải cách phân loại prototype theo phạm vi; chính và phụ không nói lên prototype rộng hay sâu. "front-end, back-end" sai vì dù mock-up thiên về giao diện, proof of concept không chỉ làm phần back-end mà đi xuyên qua mọi tầng, nên cặp từ này không mô tả đúng.

Đáp án đúng: "investing excessive effort in prototypes". Bản mẫu có giá trị nhất khi tập trung vào phần chưa chắc chắn, rủi ro cao hoặc phức tạp; làm bản mẫu cho toàn bộ giải pháp nghĩa là dồn công sức vào cả những phần đã rõ, tốn thời gian và chi phí lẽ ra dành cho phát triển thật, đó là rủi ro đầu tư quá mức vào bản mẫu. Phương án "distraction by details" là rủi ro khi người xem sa vào chi tiết giao diện như màu sắc, phông chữ thay vì đánh giá yêu cầu, không phải hệ quả của làm cả hệ thống. Phương án "pressure to release the prototype" là rủi ro khi bản mẫu trông quá giống sản phẩm thật. Phương án "unrealistic performance expectations" là rủi ro khi người dùng thấy bản mẫu chạy nhanh (do không có xử lý thật) rồi kỳ vọng sản phẩm cũng vậy.

Đáp án đúng: "Validation ensures the product satisfies customer needs, while verification ensures the product meets its specifications.". Validation (thẩm định) trả lời câu hỏi có làm đúng sản phẩm không: yêu cầu hay sản phẩm có đáp ứng nhu cầu và mục tiêu kinh doanh của khách hàng. Verification (kiểm chứng) trả lời câu hỏi có làm sản phẩm đúng cách không: kết quả có khớp với đặc tả hay yêu cầu đã định. "Validation ensures that the product meets the user's needs, while verification ensures it is free from defects." sai ở vế sau: kiểm chứng là so với đặc tả, không bảo đảm sản phẩm hết lỗi; không hoạt động nào chứng minh được điều đó. "Validation occurs before the design phase, and verification occurs after." sai vì phân biệt hai khái niệm theo mục đích chứ không theo thời điểm; cả hai diễn ra suốt dự án, ví dụ rà soát yêu cầu cũng là kiểm chứng. "Validation is about internal testing, while verification is about external approval." sai vì đảo lộn ý nghĩa: thẩm định mới gắn với khách hàng bên ngoài, còn kiểm chứng thường là đối chiếu nội bộ với đặc tả.

Đáp án đúng gồm ba ý: "Scope creep", "Misaligned Expectations" và "Cost Overruns and Delays". Requirements validation (thẩm định yêu cầu) kiểm tra yêu cầu có đúng nhu cầu của bên liên quan và mục tiêu kinh doanh hay không. Khi bên liên quan cùng xác nhận yêu cầu, phạm vi được chốt rõ nên khó bị phình ra ngoài kiểm soát; kỳ vọng của khách hàng và nhóm phát triển khớp nhau; và lỗi yêu cầu được sửa sớm khi còn rẻ, tránh làm lại muộn gây vượt chi phí và trễ tiến độ. Phương án "Eliminating All Bugs" sai vì thẩm định yêu cầu chỉ giảm lỗi bắt nguồn từ yêu cầu; lỗi thiết kế, lỗi lập trình vẫn có thể phát sinh, và không hoạt động nào bảo đảm loại bỏ mọi lỗi, nên đây không phải vấn đề thẩm định ngăn được.

Đáp án đúng: "Across an enterprise: business rules, stakeholder profiles, user class descriptions, user personas, glossary, security requirements". Tái sử dụng yêu cầu (requirements reuse) có nhiều phạm vi, và mỗi phạm vi phù hợp với một loại tài sản riêng. Ở phạm vi toàn doanh nghiệp, những thứ dùng chung cho nhiều sản phẩm của cùng tổ chức là quy tắc nghiệp vụ, hồ sơ bên liên quan, mô tả lớp người dùng, persona, bảng thuật ngữ và yêu cầu bảo mật, vì chúng phản ánh chính tổ chức chứ không phụ thuộc một ứng dụng. Phương án bắt đầu bằng "Within a product or application" gán cho phạm vi hẹp nhất một danh sách quá rộng như mục tiêu kinh doanh, ecosystem map, yêu cầu chứng nhận, vốn là tài sản dùng chung cho cả họ sản phẩm. Phương án "Across a product line" lại liệt kê tài sản đặc trưng cho cả một lĩnh vực nghiệp vụ như mô hình quy trình nghiệp vụ, yêu cầu tuân thủ. Phương án "Across a business domain" ghép với ràng buộc, giao diện, hạ tầng chức năng như bộ sinh báo cáo, vốn gắn với môi trường hay nền tảng vận hành. Phương án "Within an operating environment or platform" ghép với yêu cầu chức năng cụ thể trong use case, yêu cầu hiệu năng, vốn chỉ tái dùng được trong cùng một sản phẩm.