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

Đá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: "Conduct peer review". Rà soát đồng nghiệp (peer review) thuộc hoạt động thẩm định yêu cầu: người khác đọc yêu cầu với góc nhìn của mình (lập trình, kiểm thử, người dùng) nên dễ nhận ra giả định ngầm mà người viết coi là hiển nhiên, cũng như logic thiếu nhánh hay điều kiện chưa xử lý. Phương án "Use only bullet points" sai vì định dạng gạch đầu dòng không giúp phát hiện giả định, thậm chí còn làm mất ngữ cảnh và quan hệ giữa các ý. Phương án "Include lengthy background" sai vì thêm phần nền dài dòng không chỉ ra chỗ thiếu logic mà còn làm yêu cầu khó đọc hơn. Phương án "Prioritize with MoSCoW" sai vì MoSCoW là kỹ thuật xếp ưu tiên (Must, Should, Could, Won’t), giúp chọn yêu cầu làm trước chứ không kiểm tra chất lượng nội dung từng yêu cầ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: "External interface requirements". Trong khuôn mẫu SRS (đặc tả yêu cầu phần mềm) phổ biến, mục External interface requirements (yêu cầu giao diện ngoài) mô tả mọi điểm hệ thống tiếp xúc với bên ngoài, chia thành giao diện người dùng, giao diện phần mềm, giao diện phần cứng và giao diện truyền thông; vì vậy user interfaces (giao diện người dùng) thuộc mục này. Phương án "Overall description" sai vì mục này trình bày bối cảnh: góc nhìn sản phẩm, các lớp người dùng, môi trường vận hành, ràng buộc và giả định. Phương án "System features" chứa các yêu cầu chức năng được nhóm theo tính năng, không đặc tả giao diện. Phương án "Data requirements" chứa mô hình dữ liệu logic, từ điển dữ liệu, báo cáo và yêu cầu toàn vẹn, lưu trữ dữ liệu.

Đáp án đúng gồm hai ý: "Entity-relationship diagram" và "Class diagram". Để biểu diễn các đối tượng dữ liệu và quan hệ giữa chúng, mô hình dữ liệu (data model) thường được vẽ bằng sơ đồ thực thể quan hệ, thể hiện thực thể, thuộc tính và bản số của quan hệ, hoặc bằng sơ đồ lớp UML, nơi lớp cùng các liên kết, bội số cũng diễn tả đúng loại thông tin đó trong phân tích hướng đối tượng. "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ị, dạng bảng hoặc văn bản, bổ sung cho mô hình dữ liệu nhưng không vẽ quan hệ giữa các đối tượng. "Context diagram" thể hiện ranh giới hệ thống và luồng dữ liệu với các thực thể bên ngoài, không đi vào cấu trúc và quan hệ của dữ liệu bên trong.

Đáp án đúng: "rectangles". Swimlane diagram (sơ đồ làn bơi) mô tả quy trình nghiệp vụ hoặc luồng xử lý, chia thành các làn ngang hay dọc, mỗi làn ứng với một vai trò, bộ phận hay hệ thống. Trong sơ đồ này, mỗi bước xử lý được vẽ bằng hình chữ nhật đặt trong làn của bên thực hiện, giống ký hiệu bước xử lý trong lưu đồ. "arrows connecting pairs of rectangles" sai vì mũi tên nối các hình chữ nhật biểu diễn sự chuyển tiếp, tức thứ tự từ bước này sang bước kế, chứ không phải bản thân bước xử lý. "diamonds" sai vì hình thoi biểu diễn điểm quyết định, nơi luồng rẽ nhánh theo điều kiện. "ovals" sai vì trong nhiều lối vẽ lưu đồ hình bầu dục dùng cho điểm bắt đầu hoặc kết thúc của quy trình, không dùng cho các bước xử lý ở giữa. Sơ đồ làn bơi hay được dùng khi phân tích quy trình hiện tại và tương lai để tìm ra yêu cầu.

Đáp án đúng: "A DFD details the flow of data, processing, and data storage within the system, whereas a Context Diagram only defines the system boundary and its external entities.". Context diagram (sơ đồ ngữ cảnh) coi cả hệ thống là một tiến trình duy nhất, chỉ cho thấy ranh giới hệ thống, các thực thể bên ngoài và luồng dữ liệu vào ra; data flow diagram ở các mức thấp hơn phân rã tiến trình đó thành tiến trình con, kho dữ liệu và luồng dữ liệu bên trong. Cả hai là mô hình phân tích. "A DFD only describes incoming data, while a Context Diagram only describes outgoing data." sai vì cả hai đều thể hiện dữ liệu vào lẫn ra. "A DFD is used for designing user interfaces, while a Context Diagram is used for business analysis." sai vì DFD không mô hình giao diện. "A DFD appears only in the testing phase, whereas a Context Diagram is only used during requirements analysis." sai vì cả hai dùng trong phân tích yêu cầu. "Both DFD and Context Diagram only show external entities." sai vì DFD còn có tiến trình và kho dữ liệu.

Đáp án đúng: "Determine what information the dashboard users need for making specific decisions or choices.". Bảng điều khiển (dashboard) và báo cáo tồn tại để hỗ trợ ra quyết định, nên bước khơi gợi quan trọng nhất là hỏi người dùng sẽ đưa ra quyết định gì và cần thông tin nào để quyết định; từ đó mới suy ra chỉ số, cách trình bày và dữ liệu nguồn. Phương án "exact number of charts and graphs to be displayed" sai vì số biểu đồ là chi tiết trình bày, chỉ chốt được sau khi biết cần hiển thị thông tin gì. Phương án "Identify the specific data sources that will feed the dashboard." là việc cần làm nhưng đi sau, vì phải biết cần thông tin gì mới biết lấy từ nguồn nào. Phương án "Select the software tool for building the dashboard." là quyết định thiết kế và cài đặt, không phải bước khơi gợi yêu cầu đầu tiên.

Đáp án đúng: "Entity-relationship diagram". Entity-relationship diagram (ERD, sơ đồ thực thể quan hệ) là mô hình phân tích dữ liệu: nó biểu diễn các thực thể dữ liệu, thuộc tính của chúng và quan hệ cùng bản số (một một, một nhiều, nhiều nhiều) giữa các thực thể, thường đi kèm từ điển dữ liệu trong phần yêu cầu dữ liệu. Phương án "Class diagram" có thể thể hiện quan hệ giữa các lớp trong phân tích và thiết kế hướng đối tượng, nhưng nó mô hình hóa cả hành vi và cấu trúc lớp, không phải công cụ điển hình để mô hình hóa thực thể dữ liệu. Phương án "Data flow diagram" thể hiện dữ liệu chảy giữa tiến trình, kho dữ liệu và thực thể ngoài, không thể hiện quan hệ giữa các thực thể. Phương án "Use case diagram" thể hiện tác nhân và ca sử dụng, thuộc mô hình hóa hành vi.

Đáp án đúng: "Entity-Relationship Diagram (ERD)". Sơ đồ thực thể quan hệ là mô hình dữ liệu trực quan: thực thể biểu diễn đối tượng dữ liệu hệ thống cần lưu và xử lý, đường nối biểu diễn quan hệ kèm bản số như một-nhiều, nên đây là công cụ phân tích phù hợp nhất cho yêu cầu dữ liệu. "Data Flow Diagram (DFD)" cho thấy dữ liệu chảy giữa các tiến trình, kho dữ liệu và thực thể ngoài, tập trung vào biến đổi dữ liệu chứ không vào cấu trúc và quan hệ của chúng. "State-Transition Diagram (STD)" mô tả các trạng thái của một đối tượng và sự kiện làm nó chuyển trạng thái, tức hành vi theo thời gian. "Swimlane Diagram" mô tả các bước của một quy trình nghiệp vụ chia theo vai trò hoặc bộ phận thực hiện, không mô hình hoá dữ liệu.

Đáp án đúng: "Scalability". Scalability (khả năng mở rộng) là thuộc tính chất lượng cho biết hệ thống có thể tăng năng lực để phục vụ nhiều người dùng, nhiều giao dịch hay nhiều dữ liệu hơn mà không phải thiết kế lại và không suy giảm hiệu năng quá mức. Tình huống yêu cầu xử lý gấp 10 lần số giao dịch, và hệ thống không làm được vì tiến trình nguyên khối, logic gắn chặt, chính là vấn đề khả năng mở rộng; yêu cầu loại này nên được nêu rõ từ đầu kèm con số tăng trưởng. "Availability" sai vì tính sẵn sàng đo tỉ lệ thời gian hệ thống hoạt động được khi cần, ở đây hệ thống vẫn chạy đúng như dự định. "Usability" sai vì tính dễ dùng nói về việc người dùng học và thao tác dễ hay khó, không liên quan tới khối lượng giao dịch. "Robustness" sai vì tính bền vững nói về khả năng hệ thống xử lý đúng khi gặp đầu vào không hợp lệ, lỗi hay điều kiện bất thường, không phải khi tải tăng có kế hoạch.

Đáp án đúng: "Performance requirements include the responsiveness of the system to user inquiries, such as the number of seconds to display a webpage.". Performance (hiệu năng) là một thuộc tính chất lượng bên ngoài, đặc tả hệ thống đáp ứng nhanh và tốt tới đâu: thời gian phản hồi, thông lượng, số người dùng đồng thời, độ trễ; yêu cầu tốt phải định lượng được, như tải trang trong bao nhiêu giây. "Performance requirements focus solely on the visual design and user interface of the system." sai vì giao diện thuộc usability, không phải hiệu năng. "Performance requirements are concerned only with the physical storage capacity of the system's database." sai vì dung lượng chỉ là một khía cạnh, hiệu năng chủ yếu nói về tốc độ và khả năng xử lý. "Performance requirements are unrelated to the external factors like network connections and hardware components." sai vì hiệu năng phụ thuộc trực tiếp vào mạng và phần cứng, nên yêu cầu thường phải nêu rõ điều kiện đo.

Đáp án đúng: "Interoperability". Khả năng liên tác (interoperability) là thuộc tính chất lượng bên ngoài cho biết hệ thống trao đổi dữ liệu và dịch vụ với các hệ thống, ứng dụng khác dễ tới mức nào; yêu cầu nhập được cấu trúc hoá học hợp lệ từ ChemDraw và MarvinSketch ở các phiên bản nêu rõ chính là đặc tả khả năng làm việc với công cụ bên ngoài. Phương án "Availability" sai vì tính sẵn sàng đo tỷ lệ thời gian hệ thống hoạt động được khi cần dùng. Phương án "Installability" sai vì khả năng cài đặt nói về việc cài, cấu hình, gỡ bỏ phần mềm dễ và đúng tới mức nào. Phương án "Integrity" sai vì tính toàn vẹn nói về bảo vệ dữ liệu khỏi bị sửa sai, mất mát hay truy cập trái phép, không phải trao đổi dữ liệu với công cụ khác.

Đáp án đúng: "$100". Kỹ thuật $100 (chia 100 đô la) cho mỗi bên liên quan một ngân sách tưởng tượng 100 đô để phân bổ cho các yêu cầu; yêu cầu nào nhận nhiều tiền hơn thì được ưu tiên cao hơn, nhờ đó mức quan trọng tương đối được lượng hóa bằng giá trị tiền tệ và người tham gia buộc phải đánh đổi. Phương án "Pairwise comparison" so sánh từng cặp yêu cầu để xem cái nào quan trọng hơn, không gán giá trị tiền. Phương án "MoSCoW" xếp yêu cầu vào các nhóm Must, Should, Could, Won’t theo mức cần thiết. Phương án "Three-level scale" chia yêu cầu thành ba mức như cao, trung bình, thấp dựa trên tầm quan trọng và độ khẩn cấp. Cả ba đều là kỹ thuật ưu tiên hóa hợp lệ nhưng không dùng giá trị tiền tệ.

Đáp án đúng: "Leaving the prototype looking rough and unpolished.". Bản mẫu bỏ đi (throwaway prototype) chỉ dùng để làm rõ yêu cầu rồi bỏ, không được viết với chất lượng sản phẩm; rủi ro lớn là bên liên quan thấy nó trông hoàn chỉnh rồi cho rằng sản phẩm gần xong. Giữ bản mẫu thô, như phác thảo giấy hay khung dây (wireframe), nhắc mọi người rằng đây chỉ là công cụ thảo luận. "Using high-fidelity tools that resemble the final product." làm tăng rủi ro vì bản mẫu càng giống thật càng khiến người xem kỳ vọng nó sẵn sàng đưa vào dùng. "Making the prototype available for immediate release." đi ngược bản chất bản mẫu bỏ đi, vốn không đủ chất lượng để phát hành. "Giving detailed descriptions of every feature." không giải quyết kỳ vọng về độ hoàn thiện, lại làm bản mẫu trông như đặc tả đầy đủ.

Đá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: "Must, Should, Could, Won’t". MoSCoW là kỹ thuật xếp ưu tiên yêu cầu thuộc hoạt động phân tích, chia yêu cầu vào bốn nhóm: Must (bắt buộc có, thiếu thì đợt phát hành thất bại), Should (quan trọng nhưng có thể hoãn), Could (có thì tốt, làm nếu còn nguồn lực) và Won’t (lần này không làm, có thể xét ở đợt sau); hai chữ o viết thường chỉ để đọc thành tiếng. "Must, Should, Could, Will" sai ở chữ cuối: nhóm W là những thứ sẽ không làm trong đợt này, không phải sẽ làm. "Must, Should, Can, Will" sai cả hai chữ cuối, Can không phải tên nhóm và Will lại đảo nghĩa nhóm loại trừ. "Must, Shall, Could, Won’t" sai vì nhóm thứ hai là Should, thể hiện mức ưu tiên thấp hơn Must, còn shall trong văn bản yêu cầu thường mang nghĩa bắt buộc như Must.

Đáp án đúng: "Enhanced focus on high-value features". Xếp ưu tiên yêu cầu (requirements prioritization) là quyết định yêu cầu nào làm trước dựa trên giá trị, chi phí và rủi ro, để khi thời gian và nguồn lực có hạn nhóm vẫn giao được những tính năng mang lại nhiều giá trị nhất trước. Phương án "Improved project management" là hệ quả gián tiếp và quá chung, ưu tiên có hỗ trợ lập kế hoạch nhưng lợi ích trực tiếp của nó là tập trung vào giá trị. Phương án "Decreased stakeholder involvement" sai vì xếp ưu tiên đòi hỏi các bên liên quan tham gia nhiều hơn để cân nhắc giá trị. Phương án "Reduced scope creep" không phải lợi ích trực tiếp: phình phạm vi (scope creep) được kiểm soát chủ yếu bằng quy trình kiểm soát thay đổi, ưu tiên chỉ giúp quyết định yêu cầu mới thay chỗ yêu cầu nà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: "Proof-of-concept prototype.". Bản mẫu chứng minh khái niệm (proof of concept), thường là bản mẫu dọc (vertical prototype) đi xuyên qua các tầng kỹ thuật cho một phần nhỏ chức năng, dùng để kiểm chứng một yêu cầu hay cách tiếp cận kỹ thuật có khả thi không, chẳng hạn hiệu năng hay khả năng tích hợp, trước khi cam kết xây thật. "Mock-up prototype." là bản mẫu ngang (horizontal) mô phỏng giao diện người dùng, giúp làm rõ yêu cầu và trải nghiệm chứ không chứng minh tính khả thi kỹ thuật. "Evolutionary prototype." được xây với chất lượng tốt rồi phát triển dần thành sản phẩm thật, mục đích là tiến hoá chứ không phải thử khả thi. "Simulation prototype." mô phỏng cách hệ thống vận hành hoặc tương tác để người dùng đánh giá hành vi, không nhằm kiểm chứng khả năng hiện thực hoá yêu cầu.