SWR302 - Phần 12: Thẩm định yêu cầu

Validation (xác thực) là một khái niệm quan trọng trong quy trình phát triển phần mềm. Nó giúp xác định xem sản phẩm của một hoạt động phát triển có đáp ứng được yêu cầu của nó hay không. Trong đó, có hai khái niệm liên quan đến xác thực là Verification và Validation. Verification (kiểm tra) liên quan đến việc xác thực xem sản phẩm có đáp ứng được yêu cầu hay không, còn Validation (xác thực) liên quan đến việc xác thực xem sản phẩm có đáp ứng được mục tiêu kinh doanh hay không. Trong câu hỏi này, câu trả lời đúng là "Validation of requirements assesses whether you have written the right requirements: they trace back to business objectives.". Điều này có nghĩa là xác thực yêu cầu giúp xác định xem các yêu cầu đã được viết đúng chưa và chúng có liên quan đến mục tiêu kinh doanh hay không.

Trong quá trình tạo ra tài liệu yêu cầu kiểm tra, hoạt động cơ bản cuối cùng là 'Follow-up'. Đây là bước cuối cùng trong chuỗi hoạt động kiểm tra, bao gồm các bước khác như chuẩn bị, cuộc họp kiểm tra, sản phẩm kiểm tra ban đầu, sản phẩm kiểm tra cuối cùng và sửa đổi. Hoạt động 'Follow-up' liên quan đến việc kiểm tra lại sản phẩm sau khi đã được sửa đổi để đảm bảo rằng các vấn đề đã được giải quyết và sản phẩm đáp ứng được yêu cầu.

Câu hỏi này yêu cầu bạn xác định hoạt động không liên quan đến xác minh yêu cầu. Trong quá trình phát triển yêu cầu, có bốn thành phần chính: xác định yêu cầu, phân tích yêu cầu, xác minh yêu cầu và xác định yêu cầu. Xác minh yêu cầu là một hoạt động quan trọng để đảm bảo yêu cầu có tất cả các tính chất mong muốn của yêu cầu chất lượng cao. Nó cũng đảm bảo rằng yêu cầu đã được viết đúng và có liên quan đến mục tiêu kinh doanh. Tuy nhiên, câu trả lời không chính xác trong lựa chọn này là "Itis the fourth component of requirements development." vì nó chỉ là một phần của quá trình phát triển yêu cầu, không phải là hoạt động xác minh yêu cầu.

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

Quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không được gọi là Verification. Validation là quá trình xác định xem sản phẩm dự án có đáp ứng yêu cầu của khách hàng hay không. Checklist là một công cụ được sử dụng để đánh giá sản phẩm dự án. Testing là quá trình kiểm tra sản phẩm dự án để xác định xem nó có hoạt động đúng hay không. Tuy nhiên, Testing không phải là quá trình đánh giá sản phẩm dự án để xác định xem nó có đáp ứng nhu cầu của khách hàng hay không. Vì vậy, Testing là lựa chọn không đúng.

Xác minh yêu cầu là quá trình đánh giá xem bạn đã viết ra những yêu cầu chính xác hay chưa. Điều này liên quan đến việc đảm bảo rằng yêu cầu của bạn phản ánh đúng nhu cầu thực tế của dự án. Trong quá trình xác minh yêu cầu, bạn cần xem xét lại các yêu cầu đã được viết và đảm bảo rằng chúng không bị thiếu sót hoặc không chính xác. Điều này giúp tránh những sai sót trong quá trình phát triển dự án và đảm bảo rằng dự án được triển khai đúng như mong muốn. Xác minh yêu cầu là một bước quan trọng trong quy trình phát triển dự án và giúp đảm bảo rằng dự án được thực hiện một cách hiệu quả và đạt được mục tiêu mong muốn.

Phương pháp đánh giá yêu cầu liên quan đến việc tác giả mô tả một sản phẩm và thu thập ý kiến về nó được gọi là phương pháp Peer deskcheck. Trong phương pháp này, tác giả sẽ mô tả chi tiết về sản phẩm và gửi cho các thành viên khác trong nhóm để họ có thể đưa ra ý kiến và góp ý. Điều này giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu và nhu cầu của khách hàng. Phương pháp này thường được sử dụng khi nhóm cần phải có sự tham gia và ý kiến của nhiều người để có thể tạo ra một sản phẩm tốt nhấ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.

Chủ đề chính của việc xác minh các yêu cầu không chức năng là chúng thường mang tính chủ quan và khó đo lường chính xác. Các yêu cầu không chức năng bao gồm các tính chất như hiệu suất, độ tin cậy, bảo mật, khả năng mở rộng, v.v. Những yêu cầu này thường không có định nghĩa rõ ràng và không thể đo lường bằng các phương pháp truyền thống. Điều này khiến cho việc xác minh chúng trở nên phức tạp và khó khăn. Ngoài ra, các yêu cầu không chức năng thường phụ thuộc vào các yếu tố như kinh nghiệm, quan điểm và mục tiêu của người dùng, khiến cho việc đo lường và xác minh chúng trở nên khó khăn hơn.

Khi sử dụng thử nghiệm chấp nhận trong quá trình xác minh, lợi ích chính là đảm bảo tất cả các yêu cầu đều đo lường được và có thể kiểm tra. Điều này giúp đảm bảo rằng sản phẩm cuối cùng đáp ứng được tất cả các yêu cầu của khách hàng và các bên liên quan. Việc đo lường được yêu cầu giúp dễ dàng xác định và sửa lỗi, từ đó cải thiện chất lượng sản phẩm. Ngoài ra, việc sử dụng thử nghiệm chấp nhận cũng giúp đảm bảo rằng tất cả các yêu cầu đều được xem xét và ưu tiên đúng mức, giúp tránh được các vấn đề phát sinh trong quá trình phát triển sản phẩm.

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

Quá trình đánh giá ngang hàng là một phần quan trọng trong việc xác định và giải quyết những bất đồng trong các tuyên bố yêu cầu. Để thực hiện điều này, chúng ta nên tổ chức một cuộc họp đánh giá ngang hàng chính thức, nơi các thành viên so sánh và thảo luận về cách hiểu của họ đối với từng yêu cầu và bất kỳ bất đồng nào. Điều này cho phép các thành viên chia sẻ ý kiến và quan điểm của mình, từ đó giúp xác định và giải quyết những bất đồng trong các tuyên bố yêu cầu. Quá trình này giúp đảm bảo rằng tất cả các thành viên hiểu rõ và đồng thuận về các yêu cầu, từ đó giúp tránh những hiểu lầm và sai sót trong quá trình phát triển.

Khi phát triển kịch bản kiểm thử dựa trên yêu cầu, kiểm thử viên có thể phát hiện nhiều lỗi liên quan đến yêu cầu. Tuy nhiên, trong các lựa chọn trên, kiểm thử viên không nên tập trung vào việc kiểm tra các quy ước lập trình. Điều này vì quy ước lập trình là các quy định về cách viết mã, không phải là yêu cầu chức năng của hệ thống. Kiểm thử viên nên tập trung vào việc xác định các yêu cầu chức năng không rõ ràng, mâu thuẫn hoặc không thể đo lường được, vì những lỗi này có thể ảnh hưởng đến chất lượng của hệ thống.

Để giúp các nhà phê bình tìm kiếm các loại lỗi thông thường trong sản phẩm họ đánh giá, hãy tạo một danh sách kiểm tra cho mỗi loại tài liệu yêu cầu mà các dự án của bạn tạo ra. Điều này sẽ giúp họ có thể nhanh chóng xác định và khắc phục các lỗi trong sản phẩm. Ví dụ, nếu dự án của bạn tạo ra tài liệu yêu cầu chức năng, thì danh sách kiểm tra có thể bao gồm các lỗi như lỗi logic, lỗi nhập dữ liệu, lỗi giao diện người dùng v.v. Điều này sẽ giúp các nhà phê bình có thể tập trung vào các lỗi cụ thể và đánh giá sản phẩm một cách hiệu quả hơn.

Đá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: "Discovery of requirement gaps". Conceptual testing (kiểm thử khái niệm) là việc viết ca kiểm thử ở mức khái niệm ngay từ yêu cầu, trước khi có mã, thuộc hoạt động thẩm định yêu cầu. Khi cố nghĩ cách kiểm thử một yêu cầu, người viết sẽ thấy chỗ thiếu, chỗ mơ hồ hay mâu thuẫn, nên kỹ thuật này giúp phát hiện lỗ hổng yêu cầu từ sớm, khi sửa còn rẻ. "Interface design" sai vì thiết kế giao diện là hoạt động sau và kiểm thử khái niệm không nhằm tạo ra giao diện. "Team building" không phải mục tiêu của kỹ thuật thẩm định này, dù làm việc chung có thể giúp nhóm gắn kết hơn. "Detailed coding" sai vì kiểm thử khái niệm chủ động tránh phụ thuộc vào cài đặt, nó làm việc với yêu cầu trước khi viết mã.

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