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

Đá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 gồm ba ý: "Feasible", "Correct" và "Verifiable". Một phát biểu yêu cầu tốt cần các đặc tính như đầy đủ, đúng, khả thi, cần thiết, có ưu tiên, không mơ hồ và kiểm chứng được. Feasible (khả thi) nghĩa là có thể cài đặt được với công nghệ, ngân sách và thời gian của dự án. Correct (đúng) nghĩa là phát biểu mô tả chính xác điều bên liên quan cần, được xác nhận bởi nguồn của yêu cầu. Verifiable (kiểm chứng được) nghĩa là có thể thiết kế kiểm thử hay phép đo để biết yêu cầu đã được đáp ứng hay chưa. "Flexible" sai vì linh hoạt không phải đặc tính của một phát biểu yêu cầu tốt; một yêu cầu được viết lỏng để dễ diễn giải theo nhiều cách thực chất là mơ hồ, đi ngược tiêu chí không mơ hồ và kiểm chứng được. Linh hoạt có thể là một thuộc tính chất lượng của hệ thống, nhưng đó là nội dung yêu cầu chứ không phải phẩm chất của câu chữ.

Đáp án đúng: "Name each process using a concise verb-object action". Trong data flow diagram (sơ đồ luồng dữ liệu), mỗi tiến trình biến đổi dữ liệu vào thành dữ liệu ra, nên nó được đặt tên bằng một động từ hành động đi kèm đối tượng, ngắn gọn và rõ nghĩa, ví dụ Generate Inventory Report hay Validate Order; quy ước này giúp mô hình phân tích dễ đọc và khớp với yêu cầu chức năng. "Use a verb only" sai vì chỉ có động từ thì không biết tiến trình tác động lên dữ liệu nào, chẳng hạn Process hay Handle quá mơ hồ. "Use a noun only" sai vì danh từ dùng để đặt tên kho dữ liệu, luồng dữ liệu và thực thể ngoài, không diễn tả được hành động. "Name the process after its corresponding data store" sai vì tiến trình và kho dữ liệu là hai loại thành phần khác nhau, một tiến trình còn có thể đọc ghi nhiều kho.

Đáp án đúng: "business process". Sơ đồ làn bơi (swimlane diagram) chia quy trình thành các làn, mỗi làn là một vai trò, bộ phận hay hệ thống, rồi vẽ các bước và luồng chuyển giữa chúng; nó dùng để mô tả quy trình nghiệp vụ hiện tại hoặc tương lai, hay các thao tác của hệ thống phần mềm đề xuất, giúp tìm ra yêu cầu người dùng và yêu cầu chức năng ở từng bước. Phương án "design process" sai vì sơ đồ làn bơi trong phân tích yêu cầu mô tả công việc nghiệp vụ chứ không mô tả quy trình thiết kế phần mềm. Phương án "organizational activities" nghe gần nhưng quá chung, không chỉ ra chuỗi bước có thứ tự của một quy trình. Phương án "stakeholders" sai vì các bên liên quan có thể là chủ của các làn, nhưng sơ đồ thể hiện các bước của quy trình chứ không thể hiện bản thân các bên liên quan.

Đáp án đúng: "To visually depict the steps involved in a business process or the operations of a proposed software system, subdivided into lanes that represent different systems or actors.". Swimlane diagram (sơ đồ làn bơi) là mô hình phân tích quy trình: các bước của một quy trình nghiệp vụ hay hoạt động của hệ thống được vẽ thành luồng, chia vào các làn ngang hoặc dọc, mỗi làn là một tác nhân, phòng ban hay hệ thống, nhờ đó thấy rõ ai làm bước nào và chỗ chuyển giao giữa các bên, rất có ích để khơi gợi yêu cầu. Phương án "To represent detailed software architecture and coding structures." sai vì kiến trúc và cấu trúc mã thuộc mô hình thiết kế. Phương án "To exclusively model user interface interactions and design layouts." sai vì bố cục giao diện được thể hiện bằng wireframe hay prototype. Phương án "To show the organizational structure and management hierarchy within a company." mô tả sơ đồ tổ chức; làn có thể ứng với phòng ban nhưng sơ đồ thể hiện luồng công việc, không phải quan hệ cấp bậc.

Đáp án đúng: "Data model". Mô hình dữ liệu (data model), thường vẽ bằng sơ đồ thực thể quan hệ hoặc sơ đồ lớp, là biểu diễn trực quan các đối tượng dữ liệu, các tập hợp dữ liệu mà hệ thống xử lý và quan hệ giữa chúng; đây là phần cốt lõi khi phân tích yêu cầu dữ liệu. "Use case diagram" biểu diễn tác nhân và các use case, tức tương tác của người dùng với hệ thống, không phải dữ liệu. "Data dictionary" là kho định nghĩa chi tiết từng phần tử dữ liệu như kiểu, độ dài, miền giá trị, thường ở dạng bảng chữ, bổ sung cho mô hình dữ liệu nhưng không phải hình vẽ thể hiện quan hệ. "Reports" là đầu ra mà hệ thống tạo cho người dùng, được đặc tả riêng về nội dung và bố cục, không mô tả cấu trúc dữ liệu bên trong.

Đáp án đúng: "A summary page displaying key metrics and charts". Trong đặc tả yêu cầu về báo cáo, dashboard (bảng điều khiển) là một màn hình hay báo cáo tổng hợp gồm nhiều biểu diễn dạng chữ và đồ thị, cho người dùng thấy nhanh các chỉ số chính của một quy trình hay tổ chức; khi đặc tả cần ghi rõ nguồn dữ liệu, cách tính, tần suất làm mới và bố cục từng thành phần. "A user interface element to display a menu" sai vì thành phần hiển thị menu chỉ là cơ chế điều hướng, không tổng hợp dữ liệu. "A module for adding user accounts" sai vì đó là chức năng quản trị người dùng, thuộc yêu cầu chức năng nhập liệu chứ không phải báo cáo. "A document used for manual reporting" sai vì dashboard là màn hình tự động lấy và hiển thị dữ liệu, thường cập nhật gần thời gian thực, không phải tài liệu báo cáo làm bằng tay.

Đáp án đúng: "What reports are currently used?". Khi khơi gợi yêu cầu báo cáo, điểm xuất phát hợp lý là tìm hiểu hiện trạng: khách hàng đang dùng những báo cáo nào, ai dùng, để ra quyết định gì; từ đó người phân tích biết báo cáo nào cần giữ, sửa hay bỏ và nhu cầu thông tin thật sự là gì, trước khi đi vào chi tiết. "How often should the reports be printed?" là câu hỏi chi tiết về tần suất, chỉ có ý nghĩa sau khi đã xác định được báo cáo nào cần có. "How many users will need access to the report?" liên quan tới phân quyền và hiệu năng, cũng là câu hỏi đi sau, khi đã biết báo cáo đó phục vụ ai. "What is the preferred color scheme for the reports?" thuộc về trình bày, là chi tiết giao diện ít quan trọng và không nên hỏi đầu tiên khi chưa rõ nội dung báo cáo.

Đáp án đúng: "Efficiency". Thuộc tính chất lượng được chia thành bên ngoài (external), tức những gì người dùng cảm nhận được khi dùng hệ thống, và bên trong (internal), tức những gì quan trọng với nhóm phát triển và bảo trì. Hiệu quả (efficiency) là thước đo hệ thống dùng tài nguyên như bộ xử lý, bộ nhớ, đường truyền tốt tới mức nào, được xếp vào nhóm thuộc tính bên trong cùng khả năng sửa đổi, khả chuyển, tái sử dụng, khả năng mở rộng. Phương án "Usability" sai vì tính dễ dùng là trải nghiệm trực tiếp của người dùng nên thuộc nhóm bên ngoài. Phương án "Security" sai vì bảo mật ảnh hưởng trực tiếp tới người dùng và dữ liệu của họ, thuộc nhóm bên ngoài. Phương án "Availability" sai vì tính sẵn sàng là việc hệ thống có dùng được khi người dùng cần, cũng là thuộc tính bên ngoài.

Đáp án đúng: "Modifiability". Thuộc tính chất lượng nội tại (internal quality attribute) là thứ nhà phát triển và người bảo trì cảm nhận được chứ người dùng không trực tiếp thấy. Modifiability (khả năng sửa đổi) đo mức dễ dàng khi sửa lỗi, thay đổi và mở rộng hệ thống, bao trùm cả khả năng bảo trì, nên khớp đúng mô tả. Phương án "Efficiency" nói về việc dùng tài nguyên như bộ xử lý, bộ nhớ, băng thông một cách tiết kiệm. Phương án "Scalability" nói về khả năng phục vụ thêm người dùng, dữ liệu hay giao dịch mà vẫn giữ hiệu năng. Phương án "Reusability" nói về mức độ các thành phần có thể dùng lại ở hệ thống khác. Cả ba cũng là thuộc tính nội tại nhưng không trực tiếp diễn tả việc dễ bảo trì, thay đổi và nâng cấp.

Đáp án đúng: "Availability". Tính sẵn sàng (availability) là thuộc tính chất lượng đo mức độ dịch vụ của hệ thống có thể dùng được khi và ở nơi người dùng cần, thường đặc tả bằng tỉ lệ thời gian hoạt động trong các khung giờ quy định, ví dụ 99,5 phần trăm trong giờ làm việc. "Usability" là tính dễ dùng: người dùng học, thao tác và đạt mục tiêu dễ dàng, hiệu quả và ít lỗi đến đâu, không nói về việc hệ thống có hoạt động hay không. "Security" là khả năng bảo vệ hệ thống và dữ liệu khỏi truy cập trái phép và tấn công. "Performance" là hiệu năng, đo tốc độ phản hồi, thông lượng hay khả năng xử lý tải, tức hệ thống chạy nhanh đến đâu khi đang hoạt động, chứ không phải nó có sẵn để dùng hay không.

Đáp án đúng: "A mock-up prototype focuses on the user experience, while a proof-of-concept prototype explores the technical soundness of a proposed approach.". Xét về phạm vi, mock-up là prototype ngang, mô phỏng giao diện và trải nghiệm người dùng mà không có logic thật phía sau, dùng để làm rõ yêu cầu người dùng; proof-of-concept là prototype dọc, cài đặt một lát cắt qua mọi tầng kỹ thuật để kiểm tra cách tiếp cận kỹ thuật có đứng vững không. "A mock-up prototype focuses on technical feasibility, while a proof-of-concept prototype focuses on user experience." sai vì đảo ngược hai vai trò. "A mock-up prototype is always throwaway, while a proof-of-concept prototype is always evolutionary." sai vì vứt bỏ hay tiến hoá là cách phân loại theo mục đích sử dụng sau này, độc lập với phạm vi; prototype nào cũng có thể là loại vứt bỏ hoặc tiến hoá, và chữ always làm phát biểu sai. "A mock-up prototype is used for testing performance, while a proof-of-concept is used for testing functionality." sai vì mock-up không có xử lý thật nên không đo hiệu năng được; proof-of-concept thì lại hay dùng để thử hiệu năng của một kiến trúc. "None of the above." sai vì có một phát biểu mô tả đúng sự khác biệt.

Đáp án đúng: "To test architectural feasibility.". Mock-up là prototype mô phỏng giao diện người dùng, cho người dùng thấy và tương tác với màn hình nhưng phía sau không có xử lý thật; nó thuộc hoạt động khơi gợi và thẩm định yêu cầu. Kiểm tra tính khả thi của kiến trúc là mục đích của proof-of-concept prototype (nguyên mẫu chứng minh khái niệm), loại cài đặt một lát cắt kỹ thuật xuyên qua các tầng, nên đó không phải mục đích của mock-up. "To refine user interface design." là mục đích đúng, người dùng góp ý trên giao diện mô phỏng để làm mịn thiết kế. "To allow users to judge the overall workflow and requirements." cũng đúng, đi qua các màn hình giúp người dùng phát hiện thiếu sót trong luồng công việc và yêu cầu. "To simulate a user interface with no real functionality." đúng với chính định nghĩa của mock-up, giao diện giả không có chức năng thật.

Đáp án đúng: "Use paper prototypes or tools unrelated to actual development.". Bản mẫu bỏ đi (throwaway prototype) chỉ để khám phá yêu cầu, thường làm nhanh và không đủ chất lượng để chạy thật; nếu nó trông giống sản phẩm, khách hàng dễ nghĩ hệ thống sắp xong và gây áp lực đem dùng luôn. Làm bản mẫu trên giấy hoặc bằng công cụ khác hẳn công nghệ phát triển khiến không ai nhầm nó là sản phẩm. Phương án "Make the prototype appear as polished as possible." sai vì càng bóng bẩy càng tăng áp lực đưa vào sản xuất. Phương án "Provide detailed documentation for each prototype iteration." sai vì tài liệu chi tiết tốn công và không giảm ảo tưởng rằng bản mẫu đã dùng được. Phương án "Use functional prototypes that are nearly production-ready." sai vì bản mẫu gần như sẵn sàng sản xuất chính là thứ làm áp lực phát hành tăng lên.

Đáp án đúng: "In or out". Kỹ thuật In or out là cách ưu tiên hóa đơn giản nhất: nhóm bên liên quan xét từng yêu cầu và chỉ quyết định nhị phân là nó có vào bản phát hành này hay không, rất hợp khi danh sách ngắn hoặc cần chốt phạm vi nhanh. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu, cho thứ hạng chi tiết nhưng tốn công khi số yêu cầu lớn và không cho kết quả nhị phân. Phương án "MoSCoW" xếp yêu cầu vào bốn nhóm Must, Should, Could, Won’t, tức nhiều hơn hai mức. Phương án "The $100 method" yêu cầu bên liên quan chia một ngân sách tưởng tượng giữa các yêu cầu, cho ra mức quan trọng tương đối chứ không phải quyết định vào hay ra.

Đáp án đúng: "It categorizes requirements into Must-haves, Should-haves, Could-haves, and Won't-haves to guide prioritization". MoSCoW là kỹ thuật ưu tiên hoá yêu cầu chia yêu cầu thành bốn nhóm: Must là bắt buộc phải có, Should là quan trọng nên có, Could là có thì tốt, Won't là không làm trong đợt này; việc xếp nhóm dựa trên mức đóng góp của yêu cầu vào mục tiêu kinh doanh, giúp tập trung nguồn lực vào phần giá trị nhất. Phương án nói MoSCoW ưu tiên "solely based on stakeholder preferences" sai vì ý kiến bên liên quan chỉ là đầu vào, tiêu chí phải gắn với mục tiêu kinh doanh chứ không chỉ sở thích. Phương án "excludes business objectives from the prioritization process" đi ngược hẳn bản chất kỹ thuật này. Phương án "only considers technical specifications" sai vì MoSCoW xét giá trị nghiệp vụ, ràng buộc kỹ thuật chỉ là một yếu tố tham khảo.

Đáp án đúng: "defect checklist". Trong rà soát và inspection (thanh tra) yêu cầu, defect checklist (danh sách kiểm tra khiếm khuyết) liệt kê các loại lỗi hay gặp như yêu cầu mơ hồ, thiếu, mâu thuẫn, không kiểm chứng được; mỗi loại tài liệu yêu cầu nên có danh sách riêng để người rà soát tập trung tìm đúng kiểu lỗi đó. Phương án "error checklist" nghe gần nghĩa nhưng không phải tên gọi chuẩn của công cụ này; thuật ngữ được dùng là khiếm khuyết (defect) trong sản phẩm được rà soát. Phương án "inspection meeting" là một bước trong quy trình thanh tra, nơi nhóm cùng thảo luận các lỗi tìm được, chứ không phải công cụ phát triển trước cho từng loại tài liệu. Phương án "support documentation" là tài liệu hỗ trợ người dùng hoặc vận hành, không liên quan tới việc tìm lỗi khi rà soát.

Đáp án đúng: "They require more time to build and refine.". Prototype càng tinh vi, như mô phỏng (simulation) có tương tác gần như thật, càng tốn công xây dựng và sửa đổi; thời gian đó lẽ ra có thể dùng cho sản phẩm thật, và nếu prototype chỉ để làm rõ yêu cầu thì một bản phác hay wireframe đơn giản thường đủ. Vì vậy cần cân nhắc mức độ hoàn thiện vừa đủ cho câu hỏi cần trả lời. "They often create confusion about the system's features." không phải nhược điểm đặc trưng; rủi ro thường được nhắc lại là ngược lại, bản mô phỏng quá thật khiến khách hàng tưởng sản phẩm sắp xong, chứ không gây nhầm lẫn về tính năng. "They remove the need for stakeholder input." sai vì prototype tồn tại chính là để lấy phản hồi của bên liên quan. "They do not reflect real user behavior." sai vì prototype càng tinh vi thì càng gần hành vi thực của người dùng, đó là ưu điểm của nó.

Đáp án đúng: "By linking to them from a shared location such as a database or a requirements management tool.". Yêu cầu tái sử dụng nên được lưu một bản gốc ở nơi dùng chung, có tìm kiếm và quản lý phiên bản, như cơ sở dữ liệu hay công cụ quản lý yêu cầu; các dự án tham chiếu (reuse by reference) tới bản gốc thay vì sao chép, nhờ vậy khi bản gốc được cập nhật thì mọi nơi dùng nó đều nhất quán. "By storing them in a spreadsheet." có thể dùng ở quy mô nhỏ nhưng bảng tính khó liên kết, khó kiểm soát phiên bản và khó chia sẻ giữa nhiều dự án. "By copying them into every new project document." sai vì sao chép tạo ra nhiều bản rời rạc, sửa một nơi thì các nơi khác lệch nhau. "By creating new versions for every instance they are used." sai vì nhân bản theo từng lần dùng làm mất ý nghĩa của tái sử dụng và gây khó quản lý.

Đáp án đúng: "It categorizes requirements into Must-have, Should-have, Could-have, and Won’t-have to prioritize effectively". MoSCoW xếp yêu cầu vào bốn nhóm ưu tiên: bắt buộc phải có, nên có, có thể có và lần này sẽ không làm. Khi có yêu cầu mới hoặc thay đổi phạm vi, nhóm đặt nó vào một nhóm rõ ràng, nên dễ quyết định cái gì vào bản phát hành, cái gì bị đẩy ra sau mà không phá vỡ cam kết với nhóm bắt buộc. Phương án "It eliminates the need for stakeholder reviews" sai vì xếp nhóm MoSCoW cần chính các bên liên quan thảo luận và đồng ý. Phương án "It focuses only on technical requirements" sai vì MoSCoW áp cho mọi loại yêu cầu, chủ yếu theo giá trị nghiệp vụ. Phương án "It avoids scope creep entirely" sai vì không kỹ thuật nào loại bỏ hoàn toàn phình phạm vi; MoSCoW chỉ giúp kiểm soát nó bằng ưu tiên rõ ràng.