Chương 4 - Các Thực hành Xây dựng Yêu cầu

Dịch từ CPRE Foundation Level Handbook v1.3.0 — Đã đối chiếu & hiệu đính toàn bộ so với bản gốc tiếng Anh

📋 Bảng thuật ngữ chuẩn (dùng xuyên suốt tài liệu)

Tiếng Anh	Tiếng Việt dùng trong bản dịch
Requirements Engineering (RE)	Kỹ nghệ Yêu cầu
Requirements Engineer	Kỹ sư Yêu cầu
Elaborate / Elaboration	Xây dựng chi tiết / Triển khai chi tiết
Elicitation	Khơi gợi
Stakeholder	Bên liên quan
Validation	Thẩm định
Conflict resolution	Giải quyết xung đột
Gathering techniques	Kỹ thuật thu thập
Delighters	Yếu tố phấn khích
Satisfiers	Yếu tố hài lòng
Dissatisfiers	Yếu tố bất mãn (yếu tố nền tảng)
Walkthrough	Rà soát có hướng dẫn
Inspection	Kiểm tra hình thức
Triangulation	Đối chiếu chéo
System archaeology	Khảo cổ hệ thống
Persona	Nhân vật đại diện
Apprenticing	Học việc

Phần mở đầu

Trong các chương trước, chúng ta đã tìm hiểu về bản chất của các yêu cầu — với tư cách là sự thể hiện những mong muốn và nhu cầu của con người và tổ chức đối với một thứ gì đó mới (ví dụ: một hệ thống sẽ được phát triển hoặc điều chỉnh) — về các nguyên tắc làm nền tảng cho việc sản sinh ra các yêu cầu, và về các cách thức ghi lại yêu cầu trong tài liệu. Chúng ta thiết lập yêu cầu trước khi xây dựng hoặc sửa đổi (một phần của) hệ thống nhằm đảm bảo rằng hệ thống đó hữu ích cho — và được chấp nhận bởi — những người hoặc tổ chức đã đặt ra yêu cầu đó. Những yêu cầu này sau đó đóng vai trò là đầu vào cho đội ngũ phát triển sẽ xây dựng và triển khai hệ thống.

Đây chính là Kỹ nghệ Yêu cầu tóm gọn; nó xảy ra, một cách tường minh hoặc thường là ngầm định, bất cứ khi nào và bất cứ nơi đâu con người cố gắng phát triển một thứ gì đó. Về nguyên tắc, chất lượng của các yêu cầu quyết định chất lượng đầu ra của quá trình phát triển tiếp theo. Không có các yêu cầu phù hợp, rất khó có khả năng hệ thống được tạo ra sẽ hữu ích. Do đó, điều quan trọng là phải xây dựng chi tiết các yêu cầu một cách chuyên nghiệp. Điều này đòi hỏi phải định nghĩa tường minh về cách thực hiện: các thực hành sẽ được sử dụng để đảm bảo chất lượng cao trong quá trình xây dựng yêu cầu.

Đó chính là nội dung của chương này: cung cấp cái nhìn tổng quan về các nhiệm vụ, hoạt động và thực hành liên quan đến bất kỳ ai tham gia vào Kỹ nghệ Yêu cầu. Chương bắt đầu với việc tìm kiếm các nguồn yêu cầu tiềm năng và kết thúc bằng việc chuyển giao một tập hợp yêu cầu duy nhất, nhất quán, dễ hiểu và đã được thống nhất, có thể đóng vai trò là đầu vào cho việc phát triển, bảo trì và vận hành hiệu quả một hệ thống đáp ứng đúng mục tiêu.

📌 GHI CHÚ ÔN THI

— Bốn nhiệm vụ chính của Chương 4 theo thứ tự:

Xác định nguồn yêu cầu (4.1)
Khơi gợi yêu cầu (4.2)
Giải quyết xung đột (4.3)
Thẩm định yêu cầu (4.4)

⚠️ BẪY ĐỀ THI

Đây không phải quy trình tuyến tính! Các bước có thể được thực hiện song song, theo vòng lặp, hoặc tuần tự. Đề thi hay hỏi: “RE là quy trình tuyến tính không?” → Câu trả lời: Không.

Nhiệm vụ đầu tiên trong mọi nỗ lực Kỹ nghệ Yêu cầu là xác định và phân tích các nguồn yêu cầu tiềm năng. Điều này có vẻ đơn giản và hiển nhiên, nhưng như chúng ta sẽ thấy ở Phần 4.1, có khá nhiều khía cạnh cần cân nhắc và phân tích. Bỏ sót một nguồn chắc chắn sẽ dẫn đến các yêu cầu kém chất lượng hoặc thậm chí bị thiếu, từ đó làm giảm chất lượng của hệ thống tạo thành.

Bước tiếp theo là khơi gợi các yêu cầu từ những nguồn này. Đây giống như việc kéo nước từ giếng: bạn không bao giờ biết có gì trong xô cho đến khi bạn kéo nó lên mặt đất. Trong Kỹ nghệ Yêu cầu, nhiệm vụ này được gọi là khơi gợi (elicitation); nó được giải thích ở Phần 4.2. Trong quá trình khơi gợi, chúng ta biến những mong muốn, ước muốn, nhu cầu, đòi hỏi, kỳ vọng ngầm định — và bất cứ thứ gì khác — thành các yêu cầu tường minh có thể được nhận biết và thấu hiểu bởi tất cả các bên liên quan.

Tuy nhiên, khi bạn hỏi hai người về yêu cầu của họ đối với một hệ thống nhất định, bạn sẽ hiếm khi nhận được những câu trả lời giống hệt nhau. Trong toàn bộ chuỗi yêu cầu được khơi gợi từ các nguồn khác nhau, gần như chắc chắn rằng một số trong đó sẽ mâu thuẫn với nhau. Vì không thể triển khai các yêu cầu mâu thuẫn trong cùng một hệ thống, giải quyết xung đột sẽ luôn là một nhiệm vụ quan trọng trong Kỹ nghệ Yêu cầu, như được mô tả ở Phần 4.3.

Phần 4.4 dành cho nhiệm vụ cuối cùng trong Kỹ nghệ Yêu cầu: thẩm định (validation) các yêu cầu. Mục đích của bước này là đảm bảo rằng chất lượng của tập hợp các yêu cầu đã được khơi gợi, cũng như của từng yêu cầu đơn lẻ trong tập hợp đó, đủ tốt để cho phép quá trình phát triển hệ thống tiếp theo diễn ra.

Qua mô tả trên, bạn có thể có ấn tượng rằng các nhiệm vụ này được thực hiện theo quy trình tuyến tính với trình tự các bước nghiêm ngặt. Tuy nhiên, đây chắc chắn không phải là ý định của mô tả này và hiếm khi đúng trong thực tế.

Hình 4.1 — Kỹ nghệ Yêu cầu không phải là quy trình tuyến tính

Điểm bắt đầu thường là một tập hợp giới hạn các nguồn hiển nhiên. Trong quá trình khơi gợi, các nguồn mới được xác định, kích hoạt thêm các nhiệm vụ khơi gợi bổ sung. Khi gặp xung đột, có thể cần khơi gợi chi tiết hơn. Trong quá trình thẩm định, có thể phát hiện ra nguồn bị bỏ sót, yêu cầu bị lỗi, hoặc xung đột chưa được phát hiện — dẫn đến một loạt hoạt động mới. Thậm chí trong quá trình phát triển hệ thống tiếp theo, hoàn cảnh có thể đòi hỏi thêm các hoạt động Kỹ nghệ Yêu cầu bổ sung.

Trong các dự án Agile, Kỹ nghệ Yêu cầu và phát triển hệ thống mang tính lặp lại và tăng dần đi đôi với nhau, với các yêu cầu được triển khai chi tiết ngay trước khi phát triển một phần tăng trưởng hệ thống (system increment) mới. Trong các dự án như vậy, dự án thường bắt đầu với một product backlog giới hạn gồm các yêu cầu cấp cao, và những yêu cầu này chỉ được tinh chỉnh và chi tiết hóa khi chúng là ứng viên cho vòng lặp tiếp theo.

4.1 Nguồn Yêu cầu

Sources for Requirements

🔑 THUẬT NGỮ

Requirements source — Nguồn yêu cầu Một thực thể (người, tài liệu hoặc hệ thống) mà từ đó có thể rút ra được các yêu cầu cho hệ thống sẽ phát triển. Chỉ những thực thể có tương tác, giao diện hoặc ảnh hưởng đến hệ thống tương lai, nhưng vẫn (tương đối) không thay đổi trong quá trình phát triển sắp tới, mới được xem là nguồn yêu cầu.

Yêu cầu không giống như những thanh kẹo nằm trên kệ để mọi người tùy ý lựa chọn. Trong phần giới thiệu chương này, chúng tôi đã so sánh yêu cầu với nước được múc từ giếng: cần rất nhiều công sức để đưa chúng lên mặt đất. Do đó, vấn đề đầu tiên mà một Kỹ sư Yêu cầu phải đối mặt là “Giếng ở đâu?” Vì không có yêu cầu nào tự xuất hiện mà không có nguồn, một trong những hoạt động đầu tiên trong khơi gợi yêu cầu là xác định các nguồn tiềm năng. Việc xác định các nguồn này chỉ một lần vào đầu dự án là chưa đủ; đây là một quy trình phải được lặp đi lặp lại liên tục.

Ngay từ đầu quá trình triển khai chi tiết yêu cầu, Kỹ sư Yêu cầu phải tích cực tham gia vào việc xác định, phân tích và thu hút tất cả các nguồn yêu cầu có liên quan, vì việc bỏ sót một nguồn có liên quan chắc chắn sẽ dẫn đến sự hiểu biết không đầy đủ về các yêu cầu liên quan. Và điều này sẽ tiếp diễn cho đến tận cuối: việc xác định các nguồn yêu cầu là một quy trình đòi hỏi phải xem xét lại liên tục.

Chương 2, Nguyên tắc 3 nhấn mạnh sự cần thiết của hiểu biết chung (tường minh và ngầm định) giữa và trong tất cả các bên tham gia. Việc hiểu bối cảnh của hệ thống sẽ được phát triển trong một lĩnh vực ứng dụng nhất định là điều kiện tiên quyết để có thể xác định các nguồn yêu cầu có liên quan. Kiến thức lĩnh vực, sự hợp tác thành công trong quá khứ, văn hóa và giá trị chung, cùng sự tin tưởng lẫn nhau là những yếu tố thúc đẩy (enablers) sự hiểu biết chung, trong khi khoảng cách địa lý, thuê ngoài, hoặc các đội ngũ lớn có tỷ lệ thay đổi nhân sự cao là những trở ngại (obstacles).

Trong Chương 2, Nguyên tắc 4, chúng tôi đã giới thiệu bối cảnh (context) như một khái niệm thiết yếu để hiểu và đặc tả một hệ thống và các yêu cầu của nó. Chúng tôi định nghĩa bối cảnh là phần của thực tế nằm giữa ranh giới hệ thống (system boundary) và ranh giới bối cảnh (context boundary). Các thực thể trong bối cảnh này sẽ có ảnh hưởng đến hệ thống hoặc thậm chí tương tác với nó nhưng sẽ không nằm bên trong bản thân hệ thống.

Điều này sẽ làm cho việc tìm kiếm nguồn yêu cầu trở nên đơn giản: chỉ cần nhìn xung quanh trong bối cảnh! Nhưng thực tế không dễ như vậy. Ở giai đoạn đầu của quá trình phát triển, bối cảnh chưa được xác định; ranh giới hệ thống và ranh giới bối cảnh vẫn cần được xác lập. Do đó, việc tìm kiếm nguồn yêu cầu là một quy trình lặp đi lặp lại và đệ quy (iterative, recursive process).

Các nguồn tiềm năng được phân tích về mối quan hệ với hệ thống tương lai:

Nếu không có mối quan hệ nào → là một phần của môi trường không liên quan (irrelevant environment) → không phân tích để tìm yêu cầu.
Nếu có vẻ là một phần của hệ thống tương lai → thuộc về các nhà phát triển, không phải mối quan tâm của Kỹ sư Yêu cầu.
Chỉ những thực thể có sự tương tác với / giao diện tới / ảnh hưởng đến hệ thống tương lai, nhưng vẫn (tương đối) không thay đổi trong quá trình phát triển sắp tới, mới xứng đáng là nguồn yêu cầu.

Khi bối cảnh trở nên rõ ràng hơn, việc xác định các nguồn mới cũng trở nên dễ dàng hơn, và chính các nguồn mới này lại giúp làm sắc nét thêm các ranh giới.

📌 GHI CHÚ ÔN THI

— Ba danh mục nguồn yêu cầu chính:

Stakeholders — Các bên liên quan (nguồn quan trọng nhất)
Documents — Tài liệu
(Other) Systems — Các hệ thống (khác)

⚠️ BẪY ĐỀ THI

— Trong đề thi, khi hỏi “hệ thống có thể là nguồn yêu cầu không?” → Có. Hệ thống tiền nhiệm (predecessor/legacy), hệ thống giao tiếp (interfacing), hệ thống cạnh tranh đều là nguồn hợp lệ.

4.1.1 Các bên liên quan

Stakeholders

🔑 THUẬT NGỮ

Stakeholder — Bên liên quan “A person or organization that influences a system’s requirements or is impacted by that system.” Một người hoặc tổ chức có ảnh hưởng đến các yêu cầu của hệ thống hoặc bị tác động bởi hệ thống đó.

Các bên liên quan của hệ thống là nguồn yêu cầu chính. Hơn bất kỳ nguồn nào khác, việc không bao gồm một bên liên quan có liên quan sẽ có tác động tiêu cực lớn đến chất lượng của tập hợp yêu cầu cuối cùng; phát hiện muộn các bên liên quan như vậy (hoặc bỏ sót họ hoàn toàn) có thể dẫn đến các sửa đổi rất tốn kém, hoặc đến cuối cùng là một hệ thống vô dụng (useless system).

Để tạo ra một hệ thống đáp ứng nhu cầu của tất cả các bên liên quan, việc xác định bên liên quan một cách có hệ thống phải bắt đầu ngay từ đầu bất kỳ nỗ lực phát triển nào và kết quả phải được quản lý xuyên suốt quá trình phát triển. Các bên liên quan có thể được tìm thấy trong một khu vực rộng lớn xung quanh hệ thống, từ người dùng trực tiếp và gián tiếp, nhà quản lý (kinh doanh), nhân viên IT như các nhà phát triển và vận hành viên, cho đến các đối thủ và cạnh tranh, các tổ chức chính phủ và cơ quan quản lý, và nhiều đối tượng khác.

Câu hỏi cốt lõi để xác định bên liên quan: “Có tồn tại mối quan hệ có liên quan giữa người/tổ chức đó với hệ thống không?”

Sẽ rất hữu ích nếu nhìn nhận các bên liên quan là những con người thực sự bằng xương bằng thịt. Nếu bạn xác định một tổ chức là bên liên quan, hãy tự hỏi: “Tôi có thể xác định một người chịu trách nhiệm cho tổ chức này không? Ai có thể được coi là đầu mối liên lạc chính? Ai đại diện cho tổ chức này trong công ty chúng ta?” Ví dụ, nếu chính phủ là bên liên quan vì liên quan đến một đạo luật nhất định, hãy tìm người đại diện cho phía chính phủ — không phải Thủ tướng, mà trưởng bộ phận pháp chế nội bộ sẽ là lựa chọn tốt hơn.

Mô hình hành tây của Alexander (Alexander’s onion model) [Alex2005] có thể là điểm khởi đầu tốt. Mô hình này cho thấy cách một hệ thống (phần mềm) được bao quanh bởi ba lớp các hệ thống kỹ thuật xã hội và xã hội cấp cao hơn, mỗi lớp có các bên liên quan riêng:

Stakeholders of the business system — Bên liên quan của hệ thống nghiệp vụ
Stakeholders of the containing system — Bên liên quan của hệ thống bao chứa
Stakeholders of the wider environment — Bên liên quan của môi trường rộng hơn

📌 GHI CHÚ ÔN THI

— Nguyên tắc quả cầu tuyết (Snowball principle) [Good1961]: Càng tìm được nhiều bên liên quan, việc tìm thêm người mới càng trở nên dễ dàng hơn. Tuy nhiên, khi đã đến các bên liên quan trong môi trường rộng hơn của Alexander (wider environment), các mối quan hệ hướng ra ngoài sẽ rơi vào môi trường không liên quan (irrelevant environment) — sẽ không tiết lộ thêm nguồn mới.

Ngoài việc các bên liên quan dẫn đến bên liên quan khác, tài liệu thường cũng phát lộ thêm bên liên quan. Các ví dụ điển hình: sơ đồ tổ chức, mô tả quy trình, báo cáo marketing, tài liệu quy định. Danh sách kiểm tra về các nhóm và vai trò bên liên quan điển hình cũng là công cụ hữu ích.

Với tư cách là Kỹ sư Yêu cầu, bạn sẽ thu thập nhiều dữ liệu về các bên liên quan và duy trì dữ liệu này cho đến khi công việc hoàn thành: ai là họ, cách liên hệ, khi nào và ở đâu họ có thể tiếp cận, chuyên môn, mức độ liên quan với tư cách là nguồn, thái độ đối với dự án, ảnh hưởng, vai trò trong công ty, trong dự án và trong mối quan hệ với hệ thống, v.v.

Thông tin này được lưu giữ trong danh sách các bên liên quan (stakeholders list), và phải được cập nhật thường xuyên:

Tên	Phòng ban	Điện thoại	Khả dụng	Vai trò	Ảnh hưởng	Mức quan tâm
Marlene	Chủ sở hữu	482263	Chỉ thứ Hai	Nhà tài trợ	++	o
Peter	Kinh doanh	481225	Thường trực	Product owner	++	+
Eva	Pháp lý	481237	Không có trong tháng 6	Tư vấn	+	-
Hassan	Logistics	242651	Thường trực	Người dùng	o	++
Mira	Bàn hỗ trợ	242424	Sau 4 giờ chiều	Người dùng	-	+
Natalia*	—	481226	Thường trực	Khách hàng	++	++

** Persona, được tạo, duy trì và đại diện bởi nhóm ban tư vấn khách hàng*

📌 GHI CHÚ ÔN THI

— Hai thuộc tính quan trọng nhất trong danh sách bên liên quan (theo đề thi thực hành):

Relevance — Mức độ liên quan (vai trò là nguồn yêu cầu)
Function/Role — Chức năng/Vai trò

Duy trì mối quan hệ tốt, cởi mở với các bên liên quan là chìa khóa để nhận được thông tin có liên quan từ họ. Điều này chủ yếu dựa trên tính chính trực, trung thực và tôn trọng. Giao tiếp cởi mở và thường xuyên về kế hoạch, hoạt động và kết quả là điều thiết yếu. Bạn có thể phải chuyển hóa các bên liên quan từ đối thủ ban đầu thành cộng tác viên.

Các vấn đề với bên liên quan thường phát sinh khi quyền và nghĩa vụ của Kỹ sư Yêu cầu và các bên liên quan không rõ ràng. Nếu gặp phải vấn đề, một dạng thỏa thuận bên liên quan (stakeholder agreement) hoặc hợp đồng bên liên quan (stakeholder contract) có thể giúp cung cấp sự rõ ràng cho tất cả các bên. Khi điều này xảy ra trong nội bộ tổ chức, sự ủng hộ của quản lý cấp cao có thể gia tăng thành công.

4.1.1.1 Một Bên liên quan Đặc biệt: Người dùng

A Special Stakeholder: The User

Mọi hệ thống mà chúng ta phát triển đều có một số tương tác với những người dùng nhất định; nếu không thì tại sao bạn lại phát triển nó? Tất nhiên, khi bạn làm việc về yêu cầu cho một hệ thống con kỹ thuật nhúng ẩn bên trong một loại máy móc phức tạp nào đó, người dùng sẽ chỉ tương tác với nó gián tiếp thông qua nhiều lớp hệ thống bao quanh. Trong những trường hợp như vậy, những người dùng này sẽ không phải là nguồn yêu cầu quan trọng nhất của bạn. Tuy nhiên, trong nhiều hệ thống, những con người cụ thể sẽ có giao diện trực tiếp với hệ thống: đó là (end-)users — người dùng (cuối). Sự chấp nhận của hệ thống từ phía họ là yếu tố sống còn cho sự thành công của dự án.

Hai loại người dùng chính:

Người dùng nội bộ (Internal users): Có liên quan trực tiếp đến tổ chức mà hệ thống đang được phát triển — nhân viên, quản lý, nhà thầu phụ. Số lượng hạn chế, ít nhiều được biết đến cá nhân, đã tham gia vào dự án. Tương đối dễ liên hệ và có thể tiếp cận, ảnh hưởng, thúc đẩy thông qua các kênh chính thức hiện có.

Người dùng bên ngoài (External users): Nằm ngoài công ty — khách hàng, đối tác kinh doanh, người dân. Số lượng có thể (rất) lớn, trong nhiều trường hợp không được biết đến từng cá nhân, và họ có thể hoàn toàn không biết hoặc thờ ơ với dự án. Không thể ảnh hưởng qua các kênh chính thức. Để liên hệ với họ, bạn có thể cần quảng cáo, hứa phần thưởng, hoặc cho phép truy cập miễn phí vào phiên bản beta. Thành lập nhóm người dùng hoặc tiếp cận đám đông (đôi khi có trả phí) có thể là cách hữu ích.

⚠️ BẪY ĐỀ THI

— Cần lưu ý đến người sử dụng sai mục đích (misusers): những người cố tình cố gắng tương tác với hệ thống theo cách gây hại, như tin tặc hoặc đối thủ cạnh tranh. Hiếm khi có thể liên hệ hoặc ảnh hưởng đến họ, nhưng bạn có thể cố gắng phát triển các biện pháp để ngăn cản, ngăn chặn hoặc phát hiện các nỗ lực lạm dụng có thể dự đoán trước.

Nếu bạn có hiểu biết tốt về cơ sở người dùng, hãy phân biệt giữa các vai trò người dùng khác nhau. Các vai trò riêng biệt thường có nhu cầu thông tin khác nhau, sẽ sử dụng hệ thống theo cách riêng và có thể có quyền truy cập phân biệt vào các chức năng và dữ liệu — ví dụ, người dùng nhập dữ liệu so với người giám sát kiểm tra dữ liệu nhập. Hãy đảm bảo rằng bạn bao gồm đại diện của tất cả các vai trò có liên quan trong quá trình khơi gợi.

Điều quan trọng cần nhận ra: không có cái gọi là “Người dùng” (The User) với tư cách là một khái niệm trừu tượng duy nhất. Người dùng không phải là một khối đồng nhất không hình dạng gồm những con người giống hệt nhau, mà là tập hợp các cá nhân, mỗi người có thói quen, mong muốn và nhu cầu riêng. Trong những trường hợp như vậy, việc phân biệt một số loại hoặc nhóm người dùng có những điểm tương đồng nhất định sẽ rất hữu ích. Trong thực tế, có khoảng ba đến bảy nhóm thường hoạt động tốt nhất. Khi đó, với tư cách là Kỹ sư Yêu cầu, bạn sẽ coi mỗi nhóm là một nguồn yêu cầu riêng biệt.

Một kỹ thuật tốt là sử dụng nhân vật đại diện (personas) [Hump2017]. Personas là những cá nhân hư cấu mô tả các nhóm người dùng điển hình của hệ thống với nhu cầu, mục tiêu, hành vi hoặc thái độ tương tự.

4.1.1.2 Nhân vật đại diện (Personas)

Có hai cách tiếp cận chính để tạo persona:

Dựa trên dữ liệu (Data-driven): Persona được phát triển bằng các kỹ thuật marketing như phỏng vấn, nhóm tiêu điểm (focus groups) và các kỹ thuật thu thập dữ liệu dân tộc học khác. Chúng được gọi là persona định tính (qualitative personas). Nếu được phát triển qua phân tích thống kê trên mẫu lớn, chúng được gọi là persona định lượng (quantitative personas).

Dựa trên tưởng tượng (Imagination): Persona được phát triển bằng tưởng tượng — ví dụ trong một buổi brainstorming với nhóm dự án. Chúng được gọi là persona ngẫu hứng (ad hoc personas) hoặc proto-personas. Kỹ sư Yêu cầu phải nhận thức rằng ad hoc personas dựa trên tưởng tượng và các giả định và những giả định này phải được kiểm tra và xác nhận trong suốt quá trình Kỹ nghệ Yêu cầu.

Về cơ bản, mô tả persona chứa thông tin liên quan đến việc phát triển hệ thống hiện tại. Thông thường, thông tin này sẽ được bổ sung thêm dữ liệu khác, chẳng hạn như tên, địa chỉ, sở thích và một bức tranh hoặc ảnh chân dung. Điều này mang lại khuôn mặt con người cho khái niệm trừu tượng của persona. Nó có thể giúp bạn hiểu rằng công việc của bạn với tư cách là Kỹ sư Yêu cầu không chỉ liên quan đến sự thật mà còn liên quan đến cảm xúc.

Hình 4.3 — Ví dụ về mô tả persona

Nếu bạn sử dụng persona trong dự án, có thể sẽ hữu ích khi tìm kiếm một vài cá nhân phù hợp với mô tả persona và coi họ là đại diện của mỗi nhóm. Trong trường hợp đó, bạn có các bên liên quan thực sự mà bạn có thể giao tiếp.

⚠️ BẪY ĐỀ THI

— Persona không phải là bên liên quan thực tế. Nhóm mà một persona đại diện là một nhóm nhân tạo không tồn tại trong thế giới thực mà chỉ tồn tại trong bối cảnh của hệ thống hoặc dự án. Tuy nhiên, bạn có thể tìm kiếm các cá nhân thực tế phù hợp với mô tả persona để coi họ là đại diện và giao tiếp thực tế với họ.

4.1.2 Tài liệu

Documents

Tài liệu cũng có thể là một nguồn yêu cầu quan trọng. Với tư cách là Kỹ sư Yêu cầu, bạn thường phải đọc rất nhiều, đặc biệt là vào đầu dự án. Tất cả các loại tài liệu đều có thể liên quan: tài liệu liên quan đến công ty, lĩnh vực và dự án, mô tả sản phẩm và quy trình, tài liệu pháp lý và quy định, v.v.

Cũng như với các bên liên quan, bạn có thể phân biệt giữa tài liệu nội bộ và tài liệu bên ngoài:

Tài liệu nội bộ: Dễ lấy nhưng có thể mang tính bảo mật; thường cần ký NDA (Non-Disclosure Agreement) trước khi được cấp quyền truy cập.
Tài liệu bên ngoài: Có thể khó tìm nhưng thường là công khai; nếu không, hãy đảm bảo bạn được phép truy cập và sử dụng.

Tài liệu có thể:

Là cách tuyệt vời để tìm kiếm các nguồn khác (ví dụ: mô tả quy trình nội bộ có thể đề cập đến các vai trò, dẫn đến bên liên quan tiềm năng mới).
Là nguồn yêu cầu trực tiếp, đặc biệt là những yêu cầu dễ bị bỏ sót: ràng buộc trong tiêu chuẩn, hướng dẫn của công ty, tài liệu pháp lý; yêu cầu chi tiết trong các thủ tục và hướng dẫn công việc; ý tưởng mới trong tài liệu marketing từ đối thủ cạnh tranh.

Bạn nên nhận thức rằng một tài liệu luôn liên quan đến một số người: (các) tác giả, đối tượng (mục tiêu), người quản lý chịu trách nhiệm hoặc kiểm toán viên, người đã chỉ cho bạn sự tồn tại của nó, v.v. Tất cả những người đó có thể có vai trò như một bên liên quan. Bạn nên luôn kiểm tra tính hợp lệ và sự liên quan của một tài liệu và thường cần các bên liên quan xác nhận điều này. Nếu bạn rút ra yêu cầu từ một tài liệu không hợp lệ hoặc lỗi thời, hệ thống được phát triển từ những yêu cầu này nhiều khả năng sẽ thất bại.

Các tài liệu được sử dụng làm nguồn yêu cầu phải được quản lý (tương tự như danh sách bên liên quan):

Lưu giữ trong thư viện chung có lập chỉ mục với định danh duy nhất
Ngày tháng và số phiên bản là quan trọng để tránh làm việc với phiên bản lỗi thời
Ưu tiên làm việc với phiên bản cuối cùng (final versions); nếu phải làm việc với bản nháp, phải ghi lại trạng thái
Lưu giữ các phiên bản cũ trong kho lưu trữ (archive)
Thiết lập quản lý tài liệu phù hợp ngay từ đầu → điểm khởi đầu tốt để thiết lập khả năng truy xuất nguồn gốc ngược (backward traceability) (xem Phần 6.6)

4.1.3 Các Hệ thống Khác

(Other) Systems

Bạn cũng có thể xem xét các hệ thống khác là nguồn yêu cầu cho hệ thống mà bạn đang quan tâm. Cũng có thể phân biệt giữa hệ thống nội bộ và bên ngoài, với những cân nhắc tương tự về quyền truy cập và tính bảo mật.

Phân biệt quan trọng: hệ thống tương tự (similar systems) vs hệ thống giao tiếp (interfacing systems):

Hệ thống tương tự (Similar systems): Có một số chức năng chung với hệ thống cần phát triển — hệ thống tiền nhiệm hoặc legacy, hệ thống của đối thủ cạnh tranh, hệ thống tương đương ở các tổ chức khác, v.v. Bạn thường nghiên cứu chúng qua tài liệu, nhưng đôi khi có thể quan sát chúng trong hoạt động hoặc thử dùng chúng như một dạng nguyên mẫu. Hệ thống tiền nhiệm hoặc legacy thường là nguồn tốt để xác định các yêu cầu chi tiết (chức năng và chất lượng) và ràng buộc.

⚠️ BẪY ĐỀ THI

— Hãy lưu ý rằng các ràng buộc kỹ thuật từ quá khứ có thể không còn liên quan và có thể không còn hạn chế không gian giải pháp hiện tại của bạn nữa. Hệ thống cạnh tranh và tương đương có thể là nguồn tốt để xác định các yếu tố phấn khích (delighters) (xem Phần 4.2.1).

Hệ thống giao tiếp (Interfacing systems): Có mối quan hệ trực tiếp với hệ thống mà bạn đang phát triển yêu cầu. Chúng sẽ trao đổi dữ liệu với hệ thống của bạn dưới dạng nguồn (source) và/hoặc đích (sink) thông qua một số giao diện (đồng bộ hoặc bất đồng bộ, theo thời gian thực hoặc theo lô). Cấu hình, nội dung và hành vi chính xác của giao diện như vậy thường là yếu tố sống còn để đảm bảo hệ thống của bạn hoạt động được. Đối với các hệ thống cũ hoặc legacy nói riêng, bạn không thể tin tưởng rằng tài liệu của chúng luôn được cập nhật — bạn sẽ cần bằng chứng thực tế.

Hãy lưu ý rằng một hệ thống giao tiếp tự nó cũng sẽ có người dùng; có thể sẽ rất thú vị khi xem xét những người dùng này là các bên liên quan trong môi trường rộng hơn của Alexander đối với hệ thống chính của bạn.

4.2 Khơi gợi Yêu cầu

Elicitation of Requirements

🔑 THUẬT NGỮ

Elicitation — Khơi gợi “The effort expended by the Requirements Engineer to turn implicit desires, demands, wishes, needs, expectations — which until now were hidden in their sources — into explicit, understandable, recognizable, and verifiable requirements.” Nỗ lực mà Kỹ sư Yêu cầu bỏ ra để biến những mong muốn, đòi hỏi, ước muốn, nhu cầu, kỳ vọng ngầm định — cho đến nay vẫn còn ẩn trong các nguồn của chúng — thành các yêu cầu tường minh, dễ hiểu, có thể nhận biết và có thể kiểm chứng.

Nếu tiếp tục phép loại suy về việc kéo nước từ giếng, chúng ta hiện đang ở thời điểm đã tìm thấy giếng và bắt đầu kéo dây để đưa xô đầy nước (hay trong trường hợp này là yêu cầu) lên mặt đất. Tất nhiên, chúng ta sẽ phải sử dụng tất cả các “giếng” để đạt được sự đầy đủ và kéo dây đúng cách để đảm bảo đưa được tất cả nước lên mặt. Trong thuật ngữ Kỹ nghệ Yêu cầu, chúng ta nói rằng chúng ta nên áp dụng đúng các kỹ thuật khơi gợi.

📌 GHI CHÚ ÔN THI

— Hai danh mục lớn của kỹ thuật khơi gợi:

Gathering techniques — Kỹ thuật thu thập (chủ yếu mang lại satisfiers & dissatisfiers)
Design and idea-generating techniques — Kỹ thuật thiết kế và tạo ý tưởng (chủ yếu mang lại delighters)

Năng lực then chốt của Kỹ sư Yêu cầu là khả năng chọn đúng (tổ hợp) kỹ thuật trong hoàn cảnh cụ thể. Việc chọn đúng phụ thuộc vào nhiều yếu tố:

Loại hệ thống: Hệ thống mới, đổi mới → kỹ thuật thiết kế và tạo ý tưởng; hệ thống thay thế trong môi trường an toàn trọng yếu → kỹ thuật đặt câu hỏi và khảo cổ hệ thống.
Mô hình vòng đời phát triển phần mềm: Waterfall → học việc hoặc loại suy; Agile → brainstorming, storyboarding và tạo nguyên mẫu.
Những người tham gia: Quan sát thực địa có thể không được hoan nghênh trong các doanh nghiệp có tính bảo mật cao; khảo sát toàn diện có thể được ưu tiên hơn nhiều phỏng vấn cá nhân.
Cơ cấu tổ chức: Tổ chức chính phủ vs startup; công ty phân tán vs tập trung.

⚠️ BẪY ĐỀ THI

— Kết quả tốt nhất thường đạt được khi kết hợp nhiều kỹ thuật khơi gợi khác nhau — không phải chỉ một kỹ thuật đơn lẻ. Ngoài ra, trong thực tế RE, các yêu cầu chức năng tường minh thường được đánh giá quá cao, trong khi các yêu cầu chất lượng và ràng buộc ngầm định ít được chú ý hơn. Điều này có thể dẫn đến hệ thống không được chấp nhận dù đáp ứng đủ yêu cầu chức năng.

4.2.1 Mô hình Kano

The Kano Model

🔑 THUẬT NGỮ

— Ba danh mục Kano:**

Delighters (synonyms: excitement factors, unconscious requirements) — Yếu tố phấn khích (yếu tố kích thích, yêu cầu vô thức) Tính năng mà khách hàng không biết đến. Họ không yêu cầu nó vì họ không biết rằng nó có thể tồn tại trong hệ thống. Nếu vắng mặt → không ai phàn nàn; nếu hiện diện → khách hàng ngạc nhiên thích thú và đây có thể là tính năng tạo sự khác biệt.

Satisfiers (synonyms: performance factors, conscious requirements) — Yếu tố hài lòng (yếu tố hiệu suất, yêu cầu có ý thức) Tính năng mà khách hàng yêu cầu tường minh. Càng nhiều satisfiers trong hệ thống → sự hài lòng của khách hàng càng cao. Vì thêm chúng thường đồng nghĩa với chi phí cao hơn → cần phân tích chi phí/lợi ích.

Dissatisfiers (synonyms: basic factors, subconscious requirements) — Yếu tố bất mãn / Yếu tố nền tảng (yếu tố cơ bản, yêu cầu tiềm thức) Tính năng mà khách hàng cũng không yêu cầu, nhưng lý do là vì nó quá hiển nhiên (tiềm thức) — khách hàng không thể tưởng tượng hệ thống thiếu nó; chúng mặc nhiên được coi là must-haves. Nếu hiện diện → khách hàng không để ý; nếu vắng mặt → khách hàng rất tức giận và từ chối sử dụng hệ thống.

Mô hình Kano nhìn nhận yêu cầu từ góc độ của khách hàng. Nó tập trung vào việc phân biệt các tính năng (features), trái ngược với những nhu cầu được bày tỏ (expressed needs).

⚠️ BẪY ĐỀ THI

— Bẫy cực kỳ phổ biến trong đề thi CPRE:**

Delighters: Không được hỏi vì khách hàng không biết nó có thể có → kỹ thuật tốt nhất: field observation, prototyping, brainstorming, analogies (kỹ thuật sáng tạo và thiết kế)
Dissatisfiers: Không được hỏi vì khách hàng coi là hiển nhiên → kỹ thuật tốt nhất: field observation (quan sát thực địa)
Satisfiers: Được hỏi tường minh → kỹ thuật tốt nhất: interviews, questionnaires, workshops (kỹ thuật thu thập)

Bản thân các bên liên quan chủ yếu sẽ chỉ nói về satisfiers — yêu cầu có ý thức mà họ yêu cầu tường minh. Phát hiện dissatisfiers và delighters khó khăn hơn nhiều.

⚠️ BẪY ĐỀ THI

— Kano thay đổi theo thời gian: Delighter → Satisfier → Dissatisfier (theo vòng đời sản phẩm) Ví dụ camera điện thoại: Ban đầu là delighter (không ai yêu cầu), rồi thành satisfier (càng tốt càng hài lòng), nay là dissatisfier** (thiếu camera = hệ thống vô dụng).

Mô hình Kano gốc còn chứa thêm hai danh mục: yêu cầu thờ ơ (indifferent / “I don’t care”) và yêu cầu ngược (reverse / “I hate”). Nếu sau phân tích, khách hàng thờ ơ với một tính năng → an toàn khi thêm vào. Nếu là yêu cầu ngược → hãy cho các nhà phát triển biết để tìm phương án thay thế ít gây hại hơn.

Phân tích Kano (Kano Analysis): Đặt hai câu hỏi cho nhóm người dùng tiềm năng đại diện:

“What would you feel if this feature were present in the system?” — Bạn cảm thấy thế nào nếu tính năng này có mặt?
“What would you feel if this feature were absent from the system?” — Bạn cảm thấy thế nào nếu tính năng này vắng mặt?

Đánh điểm trên thang 5 điểm từ “I love it” đến “I hate it” → vẽ lên ma trận phân tích Kano → ô xuất hiện cho phân loại Kano của tính năng đó.

4.2.2 Kỹ thuật Thu thập

Gathering Techniques

📌 GHI CHÚ ÔN THI

— Kỹ thuật thu thập chủ yếu mang lại satisfiers và dissatisfiers. Bốn danh mục con:

Questioning techniques — Kỹ thuật đặt câu hỏi
Collaboration techniques — Kỹ thuật cộng tác
Observation techniques — Kỹ thuật quan sát
Artifact-based techniques — Kỹ thuật dựa trên tạo tác

Với kỹ thuật thu thập, bạn xem xét các nguồn khác nhau mà bạn đã xác định và khơi gợi yêu cầu từ đó. Các kỹ thuật đã được thiết lập này được sử dụng phổ biến trong Kỹ nghệ Yêu cầu và chủ yếu mang lại các yếu tố hài lòng và yếu tố bất mãn.

A. Kỹ thuật đặt câu hỏi (Questioning techniques)

Luôn được sử dụng trong tương tác với các bên liên quan. Kỹ sư Yêu cầu đặt ra các câu hỏi thích hợp để cho phép bên liên quan suy nghĩ và nhận được các câu trả lời từ đó có thể rút ra yêu cầu.

Phỏng vấn (Interviews)

Kỹ thuật linh hoạt nhất và được dùng thường xuyên nhất
Không yêu cầu các công cụ cụ thể
Thường là buổi làm việc một-một giữa Kỹ sư Yêu cầu và một bên liên quan cá nhân
Thường mang lại satisfiers (thông tin có ý thức từ người được phỏng vấn)
Cần mục tiêu rõ ràng và chuẩn bị tốt để thu được kết quả hữu ích
Tiết lộ thông tin chi tiết; tốn thời gian → ít phù hợp khi cần tiếp cận số lượng lớn bên liên quan

Bảng câu hỏi (Questionnaires)

Một nhóm lớn hơn các bên liên quan được yêu cầu trả lời cùng một bộ câu hỏi có cấu trúc
Định lượng: câu hỏi đóng → xác nhận giả thuyết, đánh giá nhanh, thông tin thống kê
Định tính: câu hỏi mở → tìm ra yêu cầu mới; kết quả phức tạp, tốn thời gian chuẩn bị và đánh giá
Kỹ thuật được ưu tiên cho các nhóm lớn; thiết kế bảng câu hỏi tốt đòi hỏi nhiều công sức
Thường là bước tiếp theo sau một loạt phỏng vấn để xác nhận ý tưởng trong nhóm lớn hơn

B. Kỹ thuật cộng tác (Collaboration techniques)

Bao gồm tất cả các loại hình cộng tác giữa Kỹ sư Yêu cầu và những người khác (bên liên quan, chuyên gia, người dùng, khách hàng, v.v.).

Hội thảo (Workshops)

Thuật ngữ bao hàm các kỹ thuật theo nhóm, từ các cuộc họp nhỏ không chính thức đến các sự kiện với hàng chục hoặc hàng trăm bên liên quan
Định nghĩa: “A structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach a closure on deliverables that represent user requirements” [Gott2002]
Cho phép cái nhìn tổng thể tốt trong thời gian ngắn nhờ tận dụng sự tương tác giữa người tham gia
Nếu cần thêm chi tiết → tiếp tục bằng phỏng vấn hoặc bảng câu hỏi
Có thể phục vụ như kỹ thuật thu thập và cả kỹ thuật sáng tạo

Kỹ nghệ Yêu cầu huy động cộng đồng (Crowd-based Requirements Engineering)

Khơi gợi trở thành nỗ lực có sự tham gia của cộng đồng bên liên quan, đặc biệt là người dùng
Sức mạnh của cộng đồng: sự đa dạng về tài năng và chuyên môn
Vì lượng dữ liệu thu được rất lớn, cần nền tảng tự động để xử lý dữ liệu
Nền tảng phải cung cấp các tính năng định hướng cộng đồng và hỗ trợ sự hợp tác, chia sẻ kiến thức; thúc đẩy sự tham gia của các nhóm bên liên quan lớn hơn trong thu thập, phân tích, phát triển, thẩm định và ưu tiên hóa yêu cầu theo cách năng động, do người dùng thúc đẩy

C. Kỹ thuật quan sát (Observation techniques)

Các bên liên quan được quan sát trong khi họ tham gia vào các quy trình (nghiệp vụ) thông thường của mình trong bối cảnh thường ngày mà không có sự can thiệp trực tiếp từ Kỹ sư Yêu cầu. Kỹ thuật quan sát đặc biệt hữu ích để xác định dissatisfiers — những hành động quá phổ biến đến mức bên liên quan không đề cập đến chúng.

📌 GHI CHÚ ÔN THI

— Theo đề thi thực hành CPRE: Kỹ thuật hiệu quả nhất để khơi gợi dissatisfiers là field observation (quan sát thực địa). Đây là điểm hay bị nhầm.

Quan sát thực địa (Field observation)

Kỹ sư Yêu cầu quan sát (chủ yếu là) người dùng cuối trong môi trường của họ trong khi thực hiện các hoạt động mà hệ thống sẽ được phát triển
Được sử dụng trong tình huống mà sự tương tác sẽ làm sao lãng người dùng hoặc can thiệp vào quy trình
Có thể áp dụng mà không thông báo cho các đối tượng được quan sát (ví dụ: ngồi cùng bệnh nhân trong phòng chờ nha sĩ)
Phát hiện yêu cầu (thường là chi tiết) mà không dễ tìm thấy bằng các kỹ thuật khác — vì hành động quá phức tạp để diễn đạt thành lời
Yêu cầu nhiều chuẩn bị, con mắt tinh tường và rất nhiều thời gian. Video rất hữu ích

Học việc (Apprenticing)

Khác với quan sát thực địa ở chỗ nó mang tính tham gia
Kỹ sư Yêu cầu (người học việc — apprentice) thực hiện một dạng thực tập trong môi trường mà hệ thống sẽ được sử dụng
Những người dùng có kinh nghiệm (bậc thầy — masters) dạy cho người học việc cách mọi thứ hoạt động
Người học việc tham gia nhưng không can thiệp; được phép mắc lỗi và đặt câu hỏi “ngớ ngẩn”
Mục đích: tạo ra sự thấu hiểu sâu sắc về lĩnh vực, nghiệp vụ và các quy trình trước khi quá trình khơi gợi yêu cầu thực sự bắt đầu
Thường cần tiếp nối bằng phỏng vấn và bảng câu hỏi để xác minh các ý tưởng ban đầu
Thời gian: phụ thuộc vào nhiều yếu tố, thường từ một ngày đến vài tuần
Có thể khó hoặc không thể tổ chức trong một số lĩnh vực: y học, hàng không, quân sự

⚠️ BẪY ĐỀ THI

— Phân biệt Apprenticing vs Field observation:

Field observation: chỉ quan sát, không can thiệp, không tham gia
Apprenticing: tham gia thực tế như người học việc, là kỹ thuật observation nhưng mang tính tham gia
Theo đề thi CPRE: Apprenticing được phân loại là observation technique (không phải collaboration technique)

D. Kỹ thuật dựa trên tạo tác (Artifact-based techniques)

Không sử dụng trực tiếp các bên liên quan mà sử dụng các sản phẩm công việc như tài liệu và hệ thống, hoặc thậm chí hình ảnh, tệp âm thanh và video, làm nguồn yêu cầu. Có thể tìm thấy (đôi khi rất chi tiết) satisfiers và dissatisfiers. Hữu ích đặc biệt khi bên liên quan không dễ dàng sẵn sàng.

Khảo cổ hệ thống (System archaeology)

Yêu cầu được trích xuất từ các hệ thống hiện có (legacy, đối thủ cạnh tranh, hệ thống tương tự) bằng cách phân tích tài liệu (thiết kế, hướng dẫn sử dụng) hoặc triển khai (mã nguồn, chú thích, script, user stories, test cases) của chúng
Chủ yếu dùng khi hệ thống hiện có đã được dùng nhiều năm và cần được thay thế
Mất nhiều thời gian nhưng tiết lộ yêu cầu và ràng buộc chi tiết không dễ phát hiện theo cách khác
Cần thêm thời gian để kiểm tra các yêu cầu trích xuất còn hợp lệ và liên quan hay không

Phân tích tài liệu (Document analysis) Phương pháp nghiên cứu định tính để thu nhận kiến thức qua nghiên cứu và giải thích có cấu trúc các văn bản và hình thức thông tin khác. Bốn bước:

Thu thập tài liệu — Phỏng vấn khách hàng và bên liên quan; tài liệu đã phân tích có thể dẫn đến tài liệu khác → quy trình lặp
Lựa chọn tài liệu — Xác định tài liệu nào liên quan; cân nhắc tính hợp lệ, xác thực và nội dung
Phân tích tài liệu — Xem xét để trích xuất yêu cầu (chức năng, chất lượng và ràng buộc)
Giải thích kết quả — Tập hợp yêu cầu trích xuất hiếm khi không mơ hồ → thông qua đối chiếu chéo (triangulation) — so sánh yêu cầu từ các nguồn khác nhau — để đạt được tập hợp nhất quán

Phân tích phản hồi (Feedback analysis)

Thu thập phản hồi từ người dùng và khách hàng (tiềm năng) trên hệ thống hiện có hoặc nguyên mẫu
Dữ liệu có thể có cấu trúc (đánh giá 5 sao) hoặc phi cấu trúc (nhận xét)
Thu thập qua: khảo sát web, biểu mẫu liên hệ, kiểm thử beta/A/B, mạng xã hội, trung tâm hỗ trợ
Điểm số thấp và nhận xét phê bình → phát hiện dissatisfiers; điểm số cao → thêm thông tin về satisfiers; nhận xét đổi mới → tiềm năng thành delighters
Có thể dẫn đến điều chỉnh yêu cầu hiện có VÀ khám phá yêu cầu mới

Tái sử dụng yêu cầu (Reuse of requirements)

Nhiều tổ chức đã có bộ sưu tập lớn yêu cầu từ các hệ thống trước đó → có thể áp dụng cho hệ thống mới
Tiết kiệm nhiều thời gian và tiền bạc (bỏ qua khơi gợi)
Điều kiện để hoạt động: bộ sưu tập phải được cập nhật, quản lý hiệu quả, dễ tiếp cận và được tài liệu hóa đầy đủ — điều không may là không thường xảy ra
Dù tái sử dụng được, vẫn phải thẩm định với bên liên quan xem yêu cầu đó còn liên quan và hợp lệ trong tình huống mới không

4.2.3 Kỹ thuật Thiết kế và Tạo ý tưởng

Design and Idea-Generating Techniques

Trong quá khứ, Kỹ nghệ Yêu cầu đã tập trung vào việc thu thập và tài liệu hóa yêu cầu từ tất cả các bên liên quan có liên quan bằng cách áp dụng các kỹ thuật thu thập. Ảnh hưởng ngày càng tăng của phần mềm như một động lực đổi mới sáng tạo trong nhiều doanh nghiệp hiện nay đang đòi hỏi một định vị mới cho Kỹ nghệ Yêu cầu như một hoạt động sáng tạo, giải quyết vấn đề. Điều này liên quan đến việc áp dụng các kỹ thuật khác không còn coi các bên liên quan (và tài liệu và hệ thống của họ) là nguồn yêu cầu duy nhất và tối thượng. Các hệ thống đổi mới cần những tính năng mới, có thể mang tính đột phá mà các bên liên quan hiện tại (chưa) có thể hình dung ra.

📌 GHI CHÚ ÔN THI

— Hai danh mục con của kỹ thuật thiết kế và tạo ý tưởng:

Creativity techniques — Kỹ thuật sáng tạo (brainstorming, analogy technique)
Design techniques — Kỹ thuật thiết kế (prototyping, scenarios/storyboards)

Ngoài ra còn có: Design thinking — Tư duy thiết kế (khái niệm rộng hơn)

Các kỹ thuật này nhằm mục đích kích thích sự sáng tạo, chủ yếu trong các nhóm, để tạo ra ý tưởng và có thể cung cấp thêm cách thức để phát triển một ý tưởng đã cho. Các kỹ thuật này có thể tạo ra yêu cầu mới và đổi mới — thường là delighters.

Điều kiện tiên quyết để sự sáng tạo xuất hiện:

Cơ hội — và do đó là thời gian — để một ý tưởng nảy sinh
Kiến thức về chủ đề, nâng cao khả năng có ý tưởng tạo ra sự khác biệt
Động lực, vì bộ não chỉ có thể sáng tạo nếu có lợi ích trực tiếp cho chủ nhân
An toàn và bảo đảm, vì những ý tưởng vô ích không được có hậu quả tiêu cực

Kỹ thuật sáng tạo (Creativity techniques)

Kích thích sự sáng tạo để tìm hoặc tạo ra yêu cầu mới mà không thể thu thập trực tiếp từ bên liên quan vì họ không biết về tính khả thi của một số tính năng mới hoặc đổi mới (kỹ thuật) nhất định. Các kỹ thuật này thường được áp dụng trong các nhóm đa dạng, đa ngành.

Động não (Brainstorming) [Osbo1948] Hỗ trợ phát triển ý tưởng mới cho câu hỏi hoặc vấn đề cụ thể. Điểm mấu chốt: trì hoãn phán xét — tách việc tìm ý tưởng khỏi việc phân tích ý tưởng. Hướng dẫn:

Số lượng ưu tiên hơn chất lượng
Liên tưởng tự do và tư duy viễn kiến được khuyến khích
Việc tiếp nhận và kết hợp các ý tưởng đã được đưa ra là được phép và mong muốn
Việc phê bình ý tưởng của người tham gia khác bị cấm — ngay cả khi ý tưởng có vẻ vô lý

Sau buổi động não → các ý tưởng được phân loại, đánh giá và ưu tiên → được chọn đóng vai trò là đầu vào cho các hoạt động khơi gợi tiếp theo.

Kỹ thuật loại suy (Analogy technique) [Robe2001] Giúp phát triển ý tưởng cho các chủ đề quan trọng và phức tạp bằng cách sử dụng các loại suy để hỗ trợ tư duy. Thành công hay thất bại chủ yếu bị ảnh hưởng bởi việc lựa chọn loại suy phù hợp. Loại suy có thể gần (cùng vấn đề trong lĩnh vực kinh doanh khác) hoặc xa (so sánh tổ chức với sinh vật sống) so với vấn đề gốc. Hai bước:

Phát triển chi tiết các khía cạnh của loại suy đã chọn mà không đề cập đến vấn đề gốc
Chuyển tất cả các khía cạnh đã xác định của loại suy trở lại vấn đề gốc

Kỹ thuật thiết kế (Design techniques)

Giúp khám phá và phát triển chi tiết các ý tưởng từ kỹ thuật sáng tạo, đồng thời làm rõ và cụ thể hóa các nhu cầu mơ hồ của bên liên quan. Phụ thuộc nhiều vào các tạo tác trực quan hoặc có thể sờ mó được, sự hợp tác nhóm và phản hồi của khách hàng.

Tạo nguyên mẫu (Prototyping) (trong ngữ cảnh khơi gợi — xem thêm Phần 3.7) Là một dạng sản phẩm công việc trung gian được tạo ra hoặc phát hành để tạo ra phản hồi. Nguyên mẫu có thể từ bản phác thảo trên giấy đến các phiên bản tiền phát hành hoạt động được của hệ thống. Chúng cho phép người dùng tương lai thử nghiệm hệ thống và điều tra các đặc điểm còn chưa rõ ràng trước khi triển khai thực tế.

📌 GHI CHÚ ÔN THI

— Nguyên mẫu có thể dùng cho cả hai mục đích:

Khơi gợi (elicitation): Đặc biệt hữu ích để phát hiện non-functional requirements, dissatisfiers và constraints — những thứ khó hiểu hoặc xác định trước trong mô hình và tài liệu
Thẩm định (validation): Chủ yếu để kiểm tra xem yêu cầu đã được triển khai chính xác chưa (xem 4.4.2)

Kịch bản và bảng phân cảnh (Scenarios and storyboards)

Kịch bản (scenario): Mô tả một luồng hành động cho hệ thống, bao gồm các tác nhân liên quan. Khám phá các cách thay thế để thực hiện một quy trình trong hệ thống.
Bảng phân cảnh (storyboard): Hình thức trực quan của kịch bản — dạng truyện tranh với một loạt các ô hình cho thấy sự tương tác của một số persona với hệ thống.
Hữu ích để triển khai chi tiết sớm các ý tưởng về quy trình và hoạt động
Có thể áp dụng trong cả khơi gợi (sớm) lẫn thẩm định (muộn hơn) yêu cầu

Tư duy thiết kế (Design thinking)

Không phải là một kỹ thuật riêng lẻ mà là một khái niệm, thái độ, triết lý, một họ các quy trình, thường là một hộp công cụ đầy các kỹ thuật. Trọng tâm: đổi mới sáng tạo và giải quyết vấn đề. Hai nguyên tắc cơ bản:

Sự đồng cảm (Empathy): Bước đầu tiên là tìm ra vấn đề thực sự đằng sau vấn đề được đưa ra — hiểu những gì bên liên quan thực sự nghĩ, cảm nhận và làm khi tương tác với hệ thống. Thường gọi là thiết kế lấy con người làm trung tâm (human-centered design). Persona, bản đồ đồng cảm và đồng sáng tạo với khách hàng là các kỹ thuật phổ biến.

Sự sáng tạo (Creativity): Đặc điểm chung là mô hình kim cương đôi (double diamond model) [DeCo2007]: sự xen kẽ giữa tư duy phân kỳ (divergent) — khám phá rộng hơn và sâu hơn, tạo nhiều ý tưởng — và tư duy hội tụ (convergent) — tập trung, lựa chọn, loại bỏ, kết hợp các ý tưởng thành một kết quả cuối cùng.

Việc trình bày chi tiết về tư duy thiết kế nằm ngoài phạm vi của Sổ tay Foundation Level này.

4.3 Giải quyết Xung đột liên quan đến Yêu cầu

Resolving Conflicts regarding Requirements

🔑 THUẬT NGỮ

Requirements conflict — Xung đột yêu cầu “An interaction between agents (individuals, groups, organizations, etc.), where at least one agent perceives incompatibilities between her thinking/ideas/perceptions and/or feelings and/or will and that of the other agent (or agents), and feels restricted by the other’s action.” [Glas1999] Trong xung đột yêu cầu: hai hoặc nhiều bên liên quan có ý kiến khác nhau hoặc thậm chí mâu thuẫn về một yêu cầu nhất định, hoặc các yêu cầu của họ không thể được triển khai trong cùng một hệ thống cùng một lúc.

Trong quá trình khơi gợi, bạn thu thập một bộ sưu tập rộng lớn các yêu cầu từ các nguồn khác nhau, với các kỹ thuật khác nhau và ở các mức độ trừu tượng và chi tiết khác nhau. Bản thân các kỹ thuật khơi gợi không đảm bảo rằng bộ sưu tập này như một tổng thể tạo thành một tập hợp yêu cầu duy nhất, nhất quán, đã được đồng thuận.

Ví dụ về xung đột:

Yêu cầu mâu thuẫn nhau: “tất cả văn bản phải là chữ đen trên nền trắng” vs “tất cả thông báo lỗi phải màu đỏ”
Bên liên quan có ý kiến khác nhau: “tất cả thông báo lỗi phải màu đỏ” vs “thông báo lỗi người dùng phải màu đỏ, tất cả thông báo lỗi khác màu xanh”

Vì chúng ta không thể phát triển (một phần cụ thể của) hệ thống dựa trên các yêu cầu mâu thuẫn, các xung đột phải được giải quyết trước khi phát triển có thể bắt đầu. Với tư cách là Kỹ sư Yêu cầu, bạn là người phải đảm bảo rằng tất cả các bên liên quan đạt được sự hiểu biết chung (xem Chương 2, Nguyên tắc 3) về toàn bộ tập hợp yêu cầu trong phạm vi liên quan đến họ và họ đồng ý với tập hợp này.

⚠️ BẪY ĐỀ THI

— “Việc phủ nhận hoặc bỏ qua xung đột KHÔNG phải là một lựa chọn”. Bạn không cần phải sợ xung đột yêu cầu — chúng sẽ luôn xảy ra. Trong thực tế, bạn nên lo lắng nếu không phát hiện ra bất kỳ xung đột nào — nghĩa là bạn có thể đã bỏ sót một số. Và theo Boehm [Boeh1981]: càng muộn bạn phát hiện ra vấn đề, việc giải quyết nó sẽ càng tốn kém.

4.3.1 Làm thế nào để Giải quyết Xung đột Yêu cầu?

How Do You Resolve a Requirements Conflict?

📌 GHI CHÚ ÔN THI

— Bốn bước giải quyết xung đột yêu cầu (theo thứ tự):

Conflict identification — Xác định xung đột
Conflict analysis — Phân tích xung đột
Conflict resolution — Giải quyết xung đột
Documentation of conflict resolution — Ghi lại giải quyết xung đột

Bước 1 — Xác định xung đột (Conflict identification)

Xung đột thường bị ẩn và chỉ có thể phát hiện bằng cách quan sát cẩn thận. Nhiều dấu hiệu có thể chú ý:

Trong giao tiếp: Phủ nhận, thờ ơ, cầu kỳ, liên tục yêu cầu thêm chi tiết, cố tình giải thích sai, che giấu hoặc ủy thác.
Trong tài liệu: Các tuyên bố mâu thuẫn của bên liên quan, kết quả mâu thuẫn từ phân tích tài liệu hoặc hệ thống, sự không nhất quán ở các mức chi tiết khác nhau, sử dụng thuật ngữ không nhất quán.

Nếu quan sát thấy những dấu hiệu này → không nhất thiết có xung đột yêu cầu, nhưng nên nghi ngờ. Thảo luận kỹ lưỡng với bên liên quan có thể đưa xung đột ẩn ra ánh sáng.

Bước 2 — Phân tích xung đột (Conflict analysis)

Kỹ sư Yêu cầu trước tiên phải làm rõ liệu đây có phải là xung đột yêu cầu hay không. Xung đột yêu cầu là trách nhiệm chính của Kỹ sư Yêu cầu; các xung đột khác có thể được giải quyết bởi những người tham gia khác (quản lý bộ phận, trưởng nhóm). Phải hiểu đầy đủ bản chất của xung đột trước khi cố gắng giải quyết nó.

Nhiều khía cạnh đáng được chú ý:

Chủ đề: phạm vi, vấn đề hoặc vấn đề thực sự đằng sau xung đột
Các yêu cầu bị ảnh hưởng: những yêu cầu cụ thể nào bị ảnh hưởng?
Các bên liên quan tham gia: ai không đồng ý với ai về vấn đề gì?
Ý kiến của các bên liên quan: để họ trình bày quan điểm rõ ràng nhất có thể
Nguyên nhân của xung đột: lý do đằng sau sự khác biệt trong ý kiến là gì?
Lịch sử của xung đột: điều gì đã xảy ra trước đó ảnh hưởng đến những ý kiến này bây giờ?
Hậu quả: chi phí và rủi ro ước tính liên quan đến việc giải quyết hoặc không giải quyết xung đột
Ràng buộc dự án: ràng buộc về mặt cá nhân, tổ chức, nội dung cụ thể hoặc đặc thù miền

Bước 3 — Giải quyết xung đột (Conflict resolution)

Một khi đã đạt được sự thấu hiểu sâu sắc về bản chất của xung đột, thái độ của các bên liên quan và các ràng buộc dự án, Kỹ sư Yêu cầu sẽ chọn kỹ thuật giải quyết phù hợp.

Bước đầu tiên phải luôn là làm cho kỹ thuật được chọn được chấp nhận bởi các bên liên quan tham gia trước khi áp dụng nó. Nếu một số bên liên quan không đồng ý ngay từ đầu với việc áp dụng kỹ thuật nhất định, họ chắc chắn sẽ không chấp nhận kết quả của nó.

📌 GHI CHÚ ÔN THI

— Về nguyên tắc, Kỹ sư Yêu cầu không phải là một trong các bên liên quan tham gia → bạn có thể và nên áp dụng kỹ thuật giải quyết được chọn theo cách khách quan, trung lập hoàn toàn, và hoan nghênh bất kỳ kết quả nào từ việc áp dụng kỹ thuật đó.

Bước 4 — Ghi lại giải quyết xung đột (Documentation of conflict resolution)

Giải quyết xung đột có thể ảnh hưởng đến các yêu cầu theo cách không hiển nhiên với người không tham gia. Tập hợp kết quả có thể trông không hợp lý hoặc kém hiệu quả. Cần ghi lại và truyền đạt về:

Các giả định liên quan đến xung đột và việc giải quyết nó
Các phương án thay thế tiềm năng được cân nhắc
Các ràng buộc ảnh hưởng đến kỹ thuật và/hoặc giải pháp được chọn
Cách xung đột được giải quyết, bao gồm lý do cho giải pháp được chọn
Người ra quyết định và những người đóng góp khác

Nếu không ghi lại → sau một thời gian, bên liên quan có thể quên hoặc bỏ qua các quyết định đã được đưa ra; và sau này, nhà phát triển có thể không hiểu lý do đằng sau một thiết kế hệ thống cụ thể và có thể triển khai nó theo cách khác.

4.3.2 Các Loại Xung đột

Conflict Types

📌 GHI CHÚ ÔN THI

— Sáu loại xung đột (thuộc lòng):

Subject matter conflict — Xung đột chủ đề
Data conflict — Xung đột dữ liệu
Interest conflict — Xung đột lợi ích
Value conflict — Xung đột giá trị
Relationship conflict — Xung đột quan hệ
Structural conflict — Xung đột cơ cấu

1. Xung đột chủ đề (Subject matter conflict) Xảy ra khi các bên xung đột thực sự có nhu cầu thực tế khác nhau, thường do hệ thống được dự định sử dụng trong các môi trường khác nhau (ví dụ: hệ thống dùng ở các quốc gia khác nhau, mỗi nước có luật pháp riêng). Khó giải quyết vì các sự kiện cơ bản không thể thay đổi. Điều đầu tiên: phân tích và ghi lại các sự kiện chi tiết và để các bên đồng ý về bản chất chính xác của xung đột.

2. Xung đột dữ liệu (Data conflict) Xảy ra khi một số bên tham chiếu đến dữ liệu không nhất quán từ các nguồn khác nhau hoặc giải thích cùng một dữ liệu theo cách khác nhau. Nguyên nhân: giao tiếp kém, thiếu dữ liệu nền, khác biệt văn hóa, thành kiến hiện có, v.v. Đặc biệt là ước tính như doanh số tương lai hay gây ra loại này. Phát hiện khó vì Kỹ sư Yêu cầu có thể nghĩ nguồn của mình là đúng → do sự thiên lệch này, thường nghi ngờ loại xung đột khác trước. Giao tiếp — lặp đi lặp lại — là chìa khóa để cả phát hiện và giải quyết loại này.

3. Xung đột lợi ích (Interest conflict) Dựa trên các quan điểm khác nhau của các bên xung đột, được hình thành bởi mục tiêu cá nhân, mục tiêu liên quan đến nhóm, hoặc mục tiêu liên quan đến vai trò. Trong trường hợp lợi ích cá nhân, bên liên quan thường không tiết lộ động cơ thực sự và đưa ra các lập luận có vẻ thực tế nhưng về bản chất là nhân tạo. Có thể quan sát thấy các bên cố gắng thuyết phục nhau. Giải quyết có thể được hưởng lợi từ việc xác định và củng cố các lợi ích chung.

4. Xung đột giá trị (Value conflict) Dựa trên sự khác biệt về giá trị và nguyên tắc của các bên liên quan. So với xung đột lợi ích, mang tính cá nhân hơn và liên quan đến quan điểm toàn cầu và dài hạn. Các giá trị ổn định hơn lợi ích và hiếm khi thay đổi trong ngắn hạn. Các bên có xu hướng khăng khăng với lập luận và không muốn từ bỏ. Để giải quyết: tìm kiếm các giá trị cao hơn gắn kết các bên. Loại này nổi tiếng là khó giải quyết.

5. Xung đột quan hệ (Relationship conflict) Thường dựa trên kinh nghiệm tiêu cực với bên kia trong quá khứ. Cảm xúc và sự hiểu lầm có liên quan → làm xung đột khó giải quyết hơn nhiều. Các bên lạm dụng cuộc thảo luận về yêu cầu để bày tỏ sự tức giận, quên đi sự thật, số liệu và sự công bằng. Đưa cuộc thảo luận trở lại yêu cầu hiếm khi giúp ích. Trong hầu hết các trường hợp, phải leo thang vấn đề lên cấp thẩm quyền cao hơn; thay đổi người là giải pháp tiềm năng. Xung đột quan hệ thường đồng thời xảy ra với các loại xung đột khác (ví dụ: xung đột lợi ích).

6. Xung đột cơ cấu (Structural conflict) Liên quan đến bất bình đẳng về quyền lực, cạnh tranh về nguồn lực hạn chế, hoặc các phụ thuộc cơ cấu giữa các bên. Sự mất cân bằng kết quả (thường chỉ được nhận thấy bởi một trong các bên) gây ra các vấn đề trong giao tiếp và ra quyết định. Hệ thống phân cấp có thể bị lạm dụng để áp đặt quyết định. Đối với loại này, leo thang vấn đề lên cấp thẩm quyền cao hơn cũng thường là cần thiết.

📌 GHI CHÚ ÔN THI

— Quan trọng: *“Hầu hết các xung đột yêu cầu có thể được phân loại là subject matter, data, interest, hoặc value conflict. Xung đột quan hệ và cơ cấu thường không liên quan trực tiếp đến yêu cầu và do đó Kỹ sư Yêu cầu có thể không phải là bên phù hợp để giải quyết chúng*.”

Tuy nhiên, trong thực tế, hầu hết các xung đột rơi vào nhiều hơn một danh mục vì các nguyên nhân khác nhau tương tác.

⚠️ BẪY ĐỀ THI

— Nếu một người khác nên giải quyết xung đột, hãy đảm bảo rằng điều đó xảy ra. Chừng nào xung đột chưa được giải quyết, nó sẽ tiếp tục có tác động tiêu cực đến công việc của bạn với tư cách là Kỹ sư Yêu cầu.

4.3.3 Các Kỹ thuật Giải quyết Xung đột

Conflict Resolution Techniques

📌 GHI CHÚ ÔN THI

— Năm kỹ thuật giải quyết xung đột chính:

Agreement — Thỏa thuận (phù hợp: data conflicts)
Compromise — Thỏa hiệp (phù hợp: subject matter, interest, structural conflicts)
Voting — Bỏ phiếu (phù hợp: subject matter, interest conflicts)
Overruling — Áp đặt quyết định (phù hợp: interest, structural conflicts)
Definition of variants — Định nghĩa các biến thể (phù hợp: subject matter, interest, value conflicts)

Và các kỹ thuật hỗ trợ (auxiliary): Consider-All-Facts (CAF), Plus-Minus-Interesting (PMI), Decision matrix

Thỏa thuận (Agreement)

Đạt được từ cuộc thảo luận giữa các bên liên quan, tiếp tục cho đến khi họ hoàn toàn hiểu quan điểm của nhau và đồng ý với một lựa chọn được tất cả ưa thích
Có thể rất tốn thời gian, đặc biệt khi nhiều bên tham gia
Nếu thành công → cung cấp thêm động lực cho bên liên quan → kết quả có khả năng tồn tại lâu dài
Phổ biến trong data conflicts
Nếu không thành công trong khoảng thời gian chấp nhận được → chuyển sang kỹ thuật khác

Thỏa hiệp (Compromise)

Khá giống với thỏa thuận, nhưng các bên đồng ý với một lựa chọn không phải là ưu tiên của họ nhưng họ có thể chấp nhận được vì chấp nhận thỏa hiệp được coi là tốt hơn là tiếp tục xung đột
Thỏa hiệp có thể chứa các yếu tố mới không có trong sở thích ban đầu của bên liên quan, có thể được Kỹ sư Yêu cầu đưa vào
Một thỏa hiệp tốt là lựa chọn mà tất cả các bên đều cảm thấy thoải mái với sự cân bằng giữa việc từ bỏ một số thứ và nhận lại thứ khác
Thường là lựa chọn tiếp theo nếu không thể đạt được thỏa thuận kịp thời
Phù hợp với subject matter conflicts và cũng có thể hiệu quả với interest và structural conflicts

Bỏ phiếu (Voting)

Hoạt động tốt nhất khi phải đưa ra lựa chọn tương đối đơn giản giữa một tập hợp rõ ràng các yêu cầu mâu thuẫn
Bên liên quan tham gia bỏ phiếu (không chỉ các bên xung đột mà tất cả bên liên quan) phải hiểu đầy đủ các lựa chọn và hậu quả
Để tránh ảnh hưởng từ phụ thuộc hoặc mất cân bằng quyền lực: bỏ phiếu ẩn danh và có người điều hành trung lập
Quy trình bỏ phiếu phải được thỏa thuận trước khi bỏ phiếu thực tế
Nhanh và dễ, nhưng bên thua phiếu sẽ thất vọng và có thể cần sự chú ý

Áp đặt quyết định (Overruling)

Nếu không thể đạt thỏa thuận/thỏa hiệp và ít nhất một bên từ chối tham gia bỏ phiếu
Thường được áp dụng dưới áp lực, khi không đủ thời gian để dùng kỹ thuật thuận tiện hơn
Thường được thực hiện bằng cách chuyển lựa chọn cho người ra quyết định cao hơn trong thẩm quyền hoặc cấp bậc so với tất cả các bên xung đột
Một biến thể: thuê ngoài quyết định cho bên thứ ba (ví dụ: chuyên gia bên ngoài) — phải đạt thỏa thuận trước về người ra quyết định
Tốt để giải quyết interest và structural conflicts

Định nghĩa các biến thể (Definition of variants)

Thường được cân nhắc cho subject matter, interest và value conflicts
Nghĩa là xây dựng các giải pháp riêng biệt cho tất cả các yêu cầu mâu thuẫn
Thường triển khai bằng cách phát triển hệ thống có thể được cấu hình qua tham số
Đi kèm với cái giá: cần nhiều thời gian để định nghĩa giải pháp; sự phức tạp ngày càng tăng và chi phí bổ sung — cả cho phát triển lẫn vận hành và bảo trì
Chỉ khả thi nếu có đủ thời gian và ngân sách

⚠️ BẪY ĐỀ THI

— Trong đề thi CPRE, câu hỏi về xung đột hay hỏi: “Kỹ thuật nào KHÔNG phù hợp để giải quyết xung đột yêu cầu?” — Đáp án thường là Sampling hoặc Prototyping (các kỹ thuật này là kỹ thuật thẩm định/khơi gợi, không phải kỹ thuật giải quyết xung đột).

Kỹ thuật hỗ trợ (Auxiliary techniques)

Không thường được sử dụng đơn lẻ mà để trợ giúp các kỹ thuật đã đề cập ở trên:

Consider-All-Facts (CAF): Xem xét các giải pháp thay thế cho một số tiêu chí được xác định trước — chi phí, thời gian, rủi ro, nguồn lực sẵn có. Việc cân nhắc các tiêu chí này cung cấp thêm sự rõ ràng về ưu và nhược điểm.
Plus-Minus-Interesting (PMI) [DeBo2005]: Công cụ ra quyết định và brainstorming. Khuyến khích xem xét ý tưởng và khái niệm từ nhiều góc độ. Người tham gia (thường là tất cả bên liên quan tham gia) xác định: tất cả khía cạnh tích cực (plus) → khía cạnh tiêu cực (minus) → các điểm thú vị cần điều tra thêm. Lựa chọn có nhiều plus nhất và ít minus nhất là lựa chọn được ưu tiên.
Ma trận quyết định (Decision matrix): Cả CAF và PMI đều là biến thể của ma trận quyết định — các yêu cầu xung đột được đánh giá dựa trên một số tiêu chí, điểm số được sử dụng để tính điểm cuối cùng (có trọng số). Lựa chọn có điểm cao nhất thắng.

Các kỹ thuật hỗ trợ này thường được coi là hỗ trợ: tạo ra cái nhìn sâu sắc hơn về các lựa chọn thay thế và giúp ích cho kỹ thuật giải quyết được chọn. Chúng có thể được dùng như kỹ thuật đơn lẻ nếu tất cả bên liên quan đồng ý chấp nhận kết quả.

4.4 Thẩm định Yêu cầu

Validation of Requirements

🔑 THUẬT NGỮ

Validation — Thẩm định Đảm bảo chất lượng của tập hợp các yêu cầu đã được khơi gợi và của từng yêu cầu đơn lẻ trong tập hợp đó đủ tốt để cho phép quá trình phát triển hệ thống tiếp theo diễn ra thành công.

Phân biệt với Verification (xác minh): - Validation kiểm tra xem chúng ta có đang xây dựng đúng hệ thống không; - Verification kiểm tra xem chúng ta có đang xây dựng hệ thống đúng cách không.

Trong Chương 2, Nguyên tắc 6, chúng tôi đã nhấn mạnh tầm quan trọng của việc thẩm định yêu cầu để tránh tình trạng các bên liên quan không hài lòng. Vì các yêu cầu tạo thành đầu vào cho quá trình phát triển hệ thống tiếp theo, chúng ta phải đảm bảo chất lượng của chúng ngay từ đầu để giảm thiểu lãng phí công sức ở các giai đoạn sau (downstream), cả ở cấp độ các yêu cầu đơn lẻ lẫn các sản phẩm công việc chứa đựng chúng.

Chúng ta nên thẩm định:

Mức độ tài liệu bao phủ nhu cầu của bên liên quan
Mức độ đồng thuận giữa tất cả bên liên quan
Khả năng xảy ra của các giả định về bối cảnh hệ thống

…trước khi bàn giao yêu cầu cho các nhà phát triển hoặc nhà cung cấp. Mặc dù mức độ chi tiết có thể khác nhau, điều này áp dụng tốt cho cả cách tiếp cận lặp lại lẫn tuần tự.

Thẩm định bổ sung thêm thời gian và chi phí cho dự án. Do đó, điều quan trọng là phải liên tục theo dõi và phân tích các lỗi xảy ra trong quá trình phát triển và vận hành. Nếu nguyên nhân gốc rễ (root cause) của những lỗi như vậy có vẻ nằm ở các yêu cầu, thì quy trình thẩm định yêu cầu đã thất bại theo một cách nào đó.

4.4.1 Các Khía cạnh Quan trọng cho Thẩm định

Important Aspects for Validation

📌 GHI CHÚ ÔN THI

— Bốn khía cạnh quan trọng để đạt được giá trị tối đa từ thẩm định:

Involving the correct stakeholders — Thu hút đúng các bên liên quan
Separating the identification and the correction of defects — Tách biệt việc xác định và sửa lỗi
Validation from different views — Thẩm định từ các góc nhìn khác nhau
Repeated validation — Thẩm định lặp lại

1. Thu hút đúng các bên liên quan (Involving the correct stakeholders)

Cần quyết định ai bạn muốn mời tham gia thẩm định. Khía cạnh quan trọng: mức độ độc lập (degree of independence) giữa người tham gia khơi gợi và người thẩm định:

Độc lập thấp (mời bên liên quan đã tham gia khơi gợi): rẻ và dễ tổ chức, nhưng có thể bỏ sót một số lỗi do sự tập trung riêng, điểm mù, lợi ích xung đột hoặc giả định sai lầm.
Độc lập cao (mời người soát xét hoặc kiểm toán viên bên ngoài): tốn nhiều thời gian, công sức và chi phí (ban đầu) cao hơn, nhưng về lâu dài có thể hiệu quả hơn trong việc tìm ra nhiều lỗi nghiêm trọng hơn.

→ Rủi ro cao hơn trong dự án → yêu cầu mức độ độc lập cao hơn.

2. Tách biệt việc xác định và sửa lỗi (Separating the identification and the correction of defects)

Có thể hấp dẫn khi sửa mọi lỗi ngay khi phát hiện. Tuy nhiên, điều này thường không phải là cách làm việc hiệu quả vì:

Các lỗi có thể ảnh hưởng lẫn nhau
Một lỗi tìm thấy sau có thể vô hiệu hóa việc sửa lỗi trước đó
Một yêu cầu ban đầu bị đánh dấu lỗi có thể chứng minh là đúng khi nghiên cứu toàn bộ tập hợp
Người tham gia thẩm định nên tập trung vào việc tìm lỗi, không phải phát triển ý tưởng về cách sửa

Khuyến nghị: Trước tiên chọn tập hợp yêu cầu để thẩm định, và quyết định có sửa lỗi nào không chỉ sau khi kiểm tra toàn bộ tập hợp.

3. Thẩm định từ các góc nhìn khác nhau (Validation from different views)

Thẩm định đúng đắn luôn là nỗ lực nhóm, không phải hoạt động do Kỹ sư Yêu cầu tự thực hiện. Kết quả tốt nhất khi thẩm định được thực hiện bởi nhóm liên ngành. Nhìn chung, đầu vào (input), đầu ra (output) và đồng nghiệp (peers) nên được đại diện.

Dự án lặp lại: Nhóm agile hiện tại là lựa chọn hợp lý, nhưng mức độ độc lập có thể thấp → cần mời thêm người thẩm định
Dự án tuần tự: Một nhóm cụ thể có thể được thành lập cho mỗi nỗ lực thẩm định riêng biệt

Tùy theo giai đoạn dự án: đầu vào từ nghiệp vụ, người dùng, nhà phát triển, kiểm thử viên, vận hành viên và quản trị viên ứng dụng là hữu ích; đôi khi có thể thêm các chuyên gia về hiệu suất, bảo mật, khả năng sử dụng.

4. Thẩm định lặp lại (Repeated validation)

Dự án tuần tự: Hầu hết yêu cầu được khơi gợi trong giai đoạn ban đầu và thẩm định kỹ lưỡng vào cuối giai đoạn đó. Nhưng đây không nên là thời điểm thẩm định duy nhất. Các thẩm định bổ sung thường được lên kế hoạch tại các cột mốc dự án.
Dự án lặp lại: Nhiều nghi lễ agile bao gồm các nỗ lực thẩm định: Sprint planning, backlog refinement, sprint reviews, và cả daily standups. Nhưng những nỗ lực này thường tập trung vào yêu cầu cá nhân, chi tiết → bức tranh tổng thể có thể bị bỏ qua.
Thẩm định ban đầu toàn bộ product backlog vào đầu dự án hoặc một tăng trưởng (increment) là khởi đầu tốt
Các hardening sprints lặp lại và thẩm định tổng thể tại các thời điểm phát hành cũng hữu ích

4.4.2 Các Kỹ thuật Thẩm định

Validation Techniques

📌 GHI CHÚ ÔN THI

— Ba danh mục kỹ thuật thẩm định:

Review techniques — Kỹ thuật soát xét → tĩnh (static)
Exploratory techniques — Kỹ thuật khám phá → động (dynamic)
Sample development — Phát triển mẫu → tĩnh (static)

⚠️ BẪY ĐỀ THI

— Phân biệt kỹ thuật tĩnh vs động:

Tĩnh (static): Phân tích đặc tả của hệ thống — không thực thi hệ thống → Review techniques và Sample development
Động (dynamic): Thẩm định tập trung vào hành vi thực tế (hoặc mô phỏng) của hệ thống trong lúc vận hành → Exploratory techniques

Nhiều yếu tố ảnh hưởng đến việc lựa chọn kỹ thuật thẩm định: mô hình vòng đời phát triển phần mềm, mức độ trưởng thành của quy trình phát triển, độ phức tạp và mức độ rủi ro của hệ thống, các yêu cầu pháp lý hoặc quy định, và nhu cầu về dấu vết kiểm toán (audit trail).

Trong tiến trình của một dự án:

Đầu dự án: Các chu kỳ thẩm định và phản hồi thường xuyên, ngắn, nhẹ nhàng → phổ biến trong agile
Cuối dự án: Các kỹ thuật thực hiện một lần (one-off) mang tính hình thức hơn và tốn thời gian hơn sẽ chiếm ưu thế

Ngoài ra, có thể quan sát sự thay đổi trong trọng tâm:

Giai đoạn đầu: Thẩm định đặc tả của yêu cầu
Giai đoạn sau: Trọng tâm chuyển sang thẩm định việc triển khai của yêu cầu

A. Kỹ thuật soát xét (Review techniques) — Tĩnh

Đặc điểm chung: dựa trên việc nghiên cứu bằng mắt đối với các sản phẩm công việc ở giai đoạn đầu và trung gian. Từ không hình thức đến rất hình thức. Để biết thêm thông tin về soát xét, xem [OleA2018].

Soát xét không hình thức (Informal reviews)

Theo chu kỳ tác giả-người soát xét. Tác giả gửi sản phẩm công việc cho một nhóm nhỏ (thành viên nhóm, đồng nghiệp, người dùng)
Thực hành tốt là ghi lại các nhận xét trong sổ đăng ký soát xét (review register) và theo dõi cách chúng được xử lý; tuy nhiên, do tính không hình thức, tác giả được tự do quyết định có và làm thế nào để sử dụng các nhận xét
Thường lặp lại qua nhiều phiên bản nháp cho đến khi tác giả hài lòng với chất lượng
Dễ dàng, rẻ tiền và dễ tiếp cận — phổ biến cho các bản nháp ban đầu
Cho phiên bản cuối cùng của sản phẩm công việc → nên dùng kỹ thuật hình thức hơn

Soát xét hình thức (Formal reviews) — theo hai nhóm chính:

Rà soát có hướng dẫn (Walkthroughs)

Bản chất: tác giả của sản phẩm công việc giải thích nó từng bước cho khán giả trong một phiên tương tác
Hai biến thể:
Người soát xét tham gia mà không chuẩn bị và nghe tác giả, đặt câu hỏi ngẫu hứng
Họ nhận được sản phẩm công việc trước cuộc họp và chuẩn bị câu hỏi cho tác giả
Người tham gia có thể đưa ra nhận xét, xác định thiếu sót và gợi ý lựa chọn thay thế
Hai dịp tốt nhất để áp dụng:
(a) Giai đoạn đầu dự án: thảo luận tính khả thi của một khái niệm hệ thống hoặc đề cương giải pháp
(b) Khi bàn giao sản phẩm công việc trung gian cho bên khác làm đầu vào cho phát triển tiếp theo
Trong dự án lặp lại: thường hiện diện dưới dạng buổi tinh chỉnh (refinement sessions) trước vòng lặp và đánh giá sprint (sprint reviews) vào cuối vòng lặp

Kiểm tra hình thức (Inspections)

📌 GHI CHÚ ÔN THI

— Inspection là kỹ thuật soát xét hình thức nhất, phù hợp nhất cho các hệ thống an toàn trọng yếu (safety-critical systems). Theo đề thi thực hành CPRE: kỹ thuật thẩm định phù hợp nhất cho hệ thống phanh tàu cao tốc là Inspection.

Trách nhiệm soát xét không thuộc về tác giả mà là trưởng soát xét độc lập (moderator)
Thực hiện dưới dạng cuộc họp với moderator, tác giả và nhóm thanh tra viên (inspectors)
Thanh tra viên: được chọn từ đồng nghiệp, nghiệp vụ, người dùng, chuyên gia
Họ kiểm tra sản phẩm công việc dựa trên chuyên môn cụ thể, xác minh tuân thủ tiêu chuẩn, đánh giá theo mục tiêu thỏa thuận
Thường: thanh tra viên chuẩn bị cá nhân kỹ lưỡng trước cuộc họp, được hướng dẫn bởi danh sách kiểm tra (checklists) chi tiết
Trong cuộc họp soát xét: tác giả tham gia với vai trò người lắng nghe — giải thích những thứ chưa rõ ràng
Inspection theo quy trình nghiêm ngặt và được ghi lại, tập trung vào tìm lỗi và đo lường các khía cạnh chất lượng được định nghĩa → cung cấp dấu vết kiểm toán (audit trail) chi tiết
Thường dùng để quyết định về việc phát hành sản phẩm công việc cho bước tiếp theo hoặc cho triển khai cuối cùng
Chủ yếu áp dụng trong (safety-)critical systems và business processes
Trong agile: cách soát xét hình thức này được tích hợp vào nghi lễ Scrum (refinement, planning, sprint review)

⚠️ BẪY ĐỀ THI

— Phân biệt Walkthrough vs Inspection:

Walkthrough: Tác giả chủ động giải thích → người tham gia là khán giả
Inspection: Moderator chủ trì, tác giả là người lắng nghe (listener) — không chủ động
Inspection hình thức hơn và yêu cầu chuẩn bị cá nhân trước cuộc họp

B. Kỹ thuật khám phá (Exploratory techniques) — Động

Cung cấp cho một nhóm bên liên quan và người dùng tiềm năng cơ hội có được kinh nghiệm thực tế với phiên bản trung gian của (một phần của) hệ thống đang phát triển. Trái ngược với soát xét, kỹ thuật khám phá là động: xem xét hành vi thực tế (hoặc mô phỏng) của hệ thống đang vận hành mà người dùng trải nghiệm qua giao diện người dùng.

Phổ biến trong phát triển lặp lại và tư duy thiết kế. Quá trình phát triển tăng dần thông thường (bắt đầu với MVP, thêm chức năng từng bước, đo lường phản ứng thị trường, điều chỉnh) có thể được coi là thẩm định khám phá trong môi trường sản xuất.

Tạo nguyên mẫu (Prototyping)

Phiên bản cụ thể ban đầu của hệ thống được trao cho nhóm bên liên quan để đánh giá
Throwaway/exploratory prototype: Xây dựng rõ ràng cho mục đích thẩm định, sau đó bị loại bỏ
Evolutionary prototype: Liên tục cập nhật và mở rộng cho đến khi trở thành sản phẩm cuối cùng → cũng có thể dùng để thẩm định trong quá trình phát triển
Bản chất: từ bên ngoài, trông giống như hệ thống dự định → bên liên quan có kinh nghiệm thực tế dù cấu trúc bên trong có thể còn chưa hoàn thiện, không hoạt động, hoặc hoàn toàn còn thiếu

Khơi gợi và thẩm định đi đôi với nhau: Prototyping và storyboarding có thể dùng cho cả hai: khi thẩm định yêu cầu đã được khơi gợi trước đó, bạn gần như chắc chắn sẽ phát hiện thêm yêu cầu mới trong phản hồi từ người tham gia. Cả hai khía cạnh của tạo nguyên mẫu đều rất nổi bật trong các cách tiếp cận tư duy thiết kế (xem [LiOg2011]).

Kiểm thử alpha và kiểm thử beta (Alpha testing and beta testing)

Phiên bản tiền sản xuất đầy đủ tính năng, hoàn toàn hoạt động được cung cấp cho người dùng cuối để vận hành với các quy trình nghiệp vụ dự định trong môi trường thực tế
Alpha testing: Tại địa điểm nhà phát triển trong môi trường mô phỏng. Nhóm tương đối nhỏ, có thể quan sát trong usability lab, và có thể đưa ra một số hướng dẫn nhất định.
Beta testing: Tại địa điểm người dùng cuối trong môi trường sản xuất thực tế (hoặc bất kỳ môi trường nào người dùng cuối quyết định). Hệ thống được cung cấp (thường miễn phí) cho nhóm người dùng (đôi khi được lựa chọn nhưng thường không xác định). Phân tích phản hồi sau thời gian sử dụng kéo dài → đặc biệt hữu ích để kiểm tra các giả định được đưa ra trong quá trình khơi gợi và phát triển.

Kiểm thử A/B (A/B testing)

Hệ thống được cung cấp cho các nhóm người dùng khác nhau (chủ yếu được chọn ngẫu nhiên) trong hai biến thể khác nhau về thiết kế hoặc chức năng và thực hiện mục tiêu người dùng theo cách khác nhau
Phản ứng của cả hai nhóm được đo lường và so sánh; hoạt động tốt nhất khi các nhóm đủ lớn để cho phép phân tích thống kê
Phân tích cung cấp thông tin về chất lượng của yêu cầu cơ bản và tính đúng đắn của các giả định trước đó
Có vai trò nổi bật trong The Lean Startup [Ries2011]

C. Phát triển mẫu (Sample development) — Tĩnh

Cung cấp một tập hợp yêu cầu như đầu vào cho các nhà phát triển; họ thử tạo ra một số sản phẩm công việc trung gian phổ biến (thiết kế, mã nguồn, ca kiểm thử, hướng dẫn sử dụng) dựa trên đầu vào này. Bản thân hệ thống chưa hoạt động → loại thẩm định tĩnh, giống như trong soát xét.

Trong nỗ lực này, nhà phát triển có thể phát hiện các thiếu sót (flaws) như điểm không rõ ràng, thiếu sót và không nhất quán ngăn cản họ tạo ra đầu ra dự kiến → những thiếu sót này sẽ được sửa chữa. Đồng thời, số lượng và mức độ nghiêm trọng của các thiếu sót được phát hiện là chỉ báo về chất lượng của các yêu cầu.

Một sự thẩm định tương tự có thể được thực hiện bởi chính các Kỹ sư Yêu cầu: cố gắng ghi lại một tập hợp yêu cầu dưới một hình thức biểu diễn khác với loại ban đầu (thường là chuyển đổi đặc tả ngôn ngữ tự nhiên thành mô hình, hoặc ngược lại). Bài tập này đặc biệt hữu ích trong việc phát hiện những sự bỏ sót (omissions).

⚠️ BẪY ĐỀ THI

— Phân biệt ba danh mục kỹ thuật thẩm định:

Kỹ thuật	Loại	Ai thực hiện	Đặc điểm
Informal/Formal reviews	Tĩnh	Kỹ sư YC + bên liên quan	Nghiên cứu bằng mắt
Walkthrough	Tĩnh	Tác giả giải thích cho khán giả	Semi-formal
Inspection	Tĩnh	Moderator + Inspectors	Hình thức nhất
Prototyping	Động	Bên liên quan dùng prototype	Thực thi hệ thống
Alpha/Beta testing	Động	Người dùng cuối	Trong môi trường thực
A/B testing	Động	Hai nhóm người dùng ngẫu nhiên	Phân tích thống kê
Sample development	Tĩnh	Nhà phát triển viết code/thiết kế	Không thực thi hệ thống

4.5 Tài liệu Đọc thêm

📊 Bảng tổng hợp ôn thi nhanh — Chương 4

Mô hình Kano

Loại	Tên tiếng Anh	Từ đồng nghĩa	Khách hàng	Khi vắng mặt	Khi hiện diện	Kỹ thuật khơi gợi
Yếu tố phấn khích	Delighters	Excitement factors, unconscious requirements	Không biết đến	Không ai phàn nàn	Ngạc nhiên thích thú	Brainstorming, analogies, prototyping, field observation
Yếu tố hài lòng	Satisfiers	Performance factors, conscious requirements	Yêu cầu tường minh	Không hài lòng	Hài lòng tăng theo	Interviews, questionnaires, workshops
Yếu tố bất mãn	Dissatisfiers	Basic factors, subconscious requirements	Coi là hiển nhiên	Rất tức giận, từ chối dùng	Không để ý	Field observation (hiệu quả nhất)

Kỹ thuật khơi gợi

Danh mục	Kỹ thuật	Đặc điểm chính
Questioning	Interviews	Linh hoạt, một-một, tốn thời gian
Questioning	Questionnaires	Nhóm lớn, định lượng/định tính
Collaboration	Workshops	Nhóm, tương tác, insight tổng thể
Collaboration	Crowd-based RE	Đám đông, cần nền tảng tự động
Observation	Field observation	Quan sát không can thiệp, tốt nhất cho dissatisfiers
Observation	Apprenticing	Tham gia như người học việc
Artifact-based	System archaeology	Phân tích hệ thống hiện có
Artifact-based	Document analysis	4 bước: thu thập → lựa chọn → phân tích → giải thích
Artifact-based	Feedback analysis	Phản hồi người dùng, A/B test, app store
Artifact-based	Reuse of requirements	Tái sử dụng yêu cầu cũ
Creativity	Brainstorming	Hoãn phán xét, số lượng > chất lượng
Creativity	Analogy technique	Loại suy gần hoặc xa với vấn đề
Design	Prototyping	Phản hồi, dùng cho cả elicitation lẫn validation
Design	Scenarios/Storyboards	Luồng hành động, comic strip

Sáu loại xung đột

Loại	Đặc trưng	Kỹ thuật giải quyết phù hợp
Subject matter	Nhu cầu thực tế khác nhau (khác môi trường/luật pháp)	Agreement, Compromise, Voting, Variants
Data	Dữ liệu không nhất quán hoặc giải thích khác nhau	Agreement
Interest	Mục tiêu cá nhân/nhóm/vai trò khác nhau	Compromise, Voting, Overruling
Value	Giá trị và nguyên tắc khác nhau	Variants (tìm giá trị cao hơn gắn kết)
Relationship	Kinh nghiệm tiêu cực trong quá khứ, cảm xúc	Leo thang (escalation)
Structural	Bất bình đẳng quyền lực, tranh giành nguồn lực	Overruling, Leo thang

Kỹ thuật thẩm định

Kỹ thuật	Loại	Hình thức	Phù hợp nhất khi
Informal review	Tĩnh	Thấp	Bản nháp ban đầu
Walkthrough	Tĩnh	Trung bình	Đầu dự án, bàn giao sản phẩm
Inspection	Tĩnh	Cao nhất	Safety-critical, cần audit trail
Prototyping	Động	Trung bình	Khi cần feedback thực tế
Alpha/Beta testing	Động	Cao	Phiên bản gần hoàn thiện
A/B testing	Động	Trung bình	So sánh hai biến thể
Sample development	Tĩnh	Trung bình	Phát hiện omissions và inconsistencies

Bản dịch hoàn chỉnh Chương 4 — CPRE Foundation Level Handbook v1.3.0 Đã đối chiếu 100% với bản gốc tiếng Anh, bổ sung ghi chú ôn thi CPRE Foundation Level

Chương 4 - Các Thực hành Xây dựng Yêu cầu

📋 Bảng thuật ngữ chuẩn (dùng xuyên suốt tài liệu)

Phần mở đầu

4.1 Nguồn Yêu cầu

Sources for Requirements

4.1.1 Các bên liên quan

Stakeholders

4.1.1.1 Một Bên liên quan Đặc biệt: Người dùng

A Special Stakeholder: The User

4.1.1.2 Nhân vật đại diện (Personas)

4.1.2 Tài liệu

Documents

4.1.3 Các Hệ thống Khác

(Other) Systems

4.2 Khơi gợi Yêu cầu

Elicitation of Requirements

4.2.1 Mô hình Kano

The Kano Model

4.2.2 Kỹ thuật Thu thập

Gathering Techniques

A. Kỹ thuật đặt câu hỏi (Questioning techniques)

B. Kỹ thuật cộng tác (Collaboration techniques)

C. Kỹ thuật quan sát (Observation techniques)

D. Kỹ thuật dựa trên tạo tác (Artifact-based techniques)

4.2.3 Kỹ thuật Thiết kế và Tạo ý tưởng

Design and Idea-Generating Techniques

Kỹ thuật sáng tạo (Creativity techniques)

Kỹ thuật thiết kế (Design techniques)

Tư duy thiết kế (Design thinking)

4.3 Giải quyết Xung đột liên quan đến Yêu cầu

Resolving Conflicts regarding Requirements

4.3.1 Làm thế nào để Giải quyết Xung đột Yêu cầu?

How Do You Resolve a Requirements Conflict?

4.3.2 Các Loại Xung đột

Conflict Types

4.3.3 Các Kỹ thuật Giải quyết Xung đột

Conflict Resolution Techniques

4.4 Thẩm định Yêu cầu

Validation of Requirements

4.4.1 Các Khía cạnh Quan trọng cho Thẩm định

Important Aspects for Validation

4.4.2 Các Kỹ thuật Thẩm định

Validation Techniques

A. Kỹ thuật soát xét (Review techniques) — Tĩnh

B. Kỹ thuật khám phá (Exploratory techniques) — Động

C. Phát triển mẫu (Sample development) — Tĩnh

4.5 Tài liệu Đọc thêm

Further Reading

📊 Bảng tổng hợp ôn thi nhanh — Chương 4

Mô hình Kano

Kỹ thuật khơi gợi

Sáu loại xung đột

Kỹ thuật thẩm định