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

Practices for Requirements Elaboration

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

Tiếng Anh	Tiếng Việt
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
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 (đào sâu phân tích hệ thống cũ)
Persona	Nhân vật đại diện
Apprenticing	Học việc

Phần mở đầu

Các chương trước đã trình bày bản chất của yêu cầu — là sự thể hiện 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 — cùng với các nguyên tắc nền tảng và các cách ghi lại yêu cầu trong tài liệu. Yêu cầu được xác lập trước khi xây dựng hoặc sửa đổi hệ thống — để đảm bảo hệ thống đó thực sự hữu ích và được chấp nhận bởi những người đặt ra nó. Sau đó, chính các yêu cầu này là đầu vào cho đội ngũ phát triển.

Đó là Kỹ nghệ Yêu cầu được tóm gọn trong một câu. Quá trình này diễn ra — tường minh hoặc ngầm định — bất cứ khi nào con người cố gắng xây dựng một thứ gì đó. Chất lượng yêu cầu quyết định chất lượng đầu ra của quá trình phát triển. Nếu thiếu đi các yêu cầu chuẩn xác, hệ thống được tạo ra sẽ khó có giá trị thực tiễn. Do đó, phải xây dựng chi tiết yêu cầu một cách chuyên nghiệp — và điều đó đòi hỏi định nghĩa rõ ràng cách làm: các thực hành cần áp dụng.

Chương này cung cấp cái nhìn tổng quan về các nhiệm vụ và thực hành liên quan đến bất kỳ ai tham gia vào Kỹ nghệ Yêu cầu. Bắt đầu từ việc tìm kiếm nguồn yêu cầu tiềm năng, kết thúc bằng việc bà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 — đủ để làm đầu vào cho việc phát triển, bảo trì và vận hành hệ thống hiệu quả.

📌 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ể thực hiện song song, theo vòng lặp, hoặc tuần tự tùy tình huống. Đề 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 là xác định và phân tích các nguồn yêu cầu tiềm năng. Tưởng đơn giản, nhưng như Phần 4.1 sẽ cho thấy, có nhiều khía cạnh cần cân nhắc. Bỏ sót một nguồn chắc chắn dẫn đến yêu cầu kém chất lượng hoặc bị thiếu — và hậu quả là hệ thống đầu ra cũng kém theo.

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

Khi hỏi hai người về yêu cầu của họ cho cùng một hệ thống, bạn hiếm khi nhận được câu trả lời giống nhau. Gần như chắc chắn sẽ có mâu thuẫn trong tập hợp yêu cầu thu được. 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 luôn là nhiệm vụ trọng yếu — xem Phần 4.3.

Nhiệm vụ cuối cùng là thẩm định (validation) yêu cầu (Phần 4.4): đảm bảo chất lượng của cả tập hợp yêu cầu lẫn từng yêu cầu đơn lẻ đủ tốt để cho phép phát triển hệ thống tiếp theo.

Qua mô tả trên, có thể có ấn tượng rằng các nhiệm vụ này là một quy trình tuyến tính. Thực tế không phải vậy. Điểm bắt đầu thường là một tập hợp nhỏ các nguồn hiển nhiên. Trong khi khơi gợi, các nguồn mới xuất hiện và kích hoạt thêm nhiệm vụ khơi gợi. Khi gặp xung đột, có thể cần khơi gợi thêm chi tiết. Trong khi thẩm định, có thể phát hiện nguồn bị bỏ sót hoặc xung đột chưa được phát hiện — và toàn bộ chu trình lại bắt đầu. Thậm chí trong quá trình phát triển hệ thống sau đó, hoàn cảnh có thể đòi hỏi thêm hoạt động Kỹ nghệ Yêu cầu.

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

Trong 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. Yêu cầu được xây dựng chi tiết ngay trước khi phát triển mỗi tăng trưởng (increment) mới. Thường thì dự án 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à các yêu cầu chỉ được tinh chỉnh 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

Thực thể (người, tài liệu hoặc hệ thống) mà từ đó có thể rút ra yêu cầu. 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 bản thân (tương đối) không thay đổi trong quá trình phát triển sắp tới, mới được coi là nguồn yêu cầu.

Yêu cầu không tự xuất hiện. Câu hỏi đầu tiên một Kỹ sư Yêu cầu phải trả lời là: “Giếng ở đâu?” — tức là, các nguồn yêu cầu nằm ở đâu? Xác định nguồn không phải việc làm một lần ở đầu dự án. Đây là quy trình phải lặp đi lặp lại liên tục cho đến tận cuối.

Ngay từ đầu, Kỹ sư Yêu cầu phải tích cực tìm kiếm, phân tích và thu hút tất cả các nguồn có liên quan. Bỏ sót một nguồn chắc chắn dẫn đến hiểu biết không đầy đủ về các yêu cầu liên quan.

Chương 2, Nguyên tắc 3 nhấn mạnh sự cần thiết của hiểu biết chung giữa tất cả các bên tham gia. Để xác định đúng nguồn yêu cầu, cần hiểu bối cảnh của hệ thống trong lĩnh vực ứng dụng cụ thể. Những yếu tố giúp xây dựng hiểu biết chung — gọi là enablers — gồm: kiến thức lĩnh vực, kinh nghiệm hợp tác trong quá khứ, văn hóa và giá trị chung, sự tin tưởng lẫn nhau. Những thứ cản trở nó — obstacles — gồm: khoảng cách địa lý, thuê ngoài, đội ngũ lớn với tỷ lệ thay đổi nhân sự cao.

Chương 2, Nguyên tắc 4 đã giới thiệu bối cảnh (context) là phần 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 ảnh hưởng đến hoặc tương tác với hệ thống nhưng không nằm bên trong hệ thống.

Trên lý thuyết, tìm nguồn yêu cầu rất đơn giản: chỉ cần nhìn vào bối cảnh! Nhưng thực tế phức tạp hơn. Ở giai đoạn đầu, 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 nguồn là một quy trình lặp đi lặp lại và đệ quy.

Khi phân tích một nguồn tiềm năng:

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

Khi bối cảnh dần rõ hơn, việc tìm nguồn mới cũng dễ hơn — và các nguồn mới đó lại tiếp tục làm sắc nét các ranh giới. Quá trình tìm nguồn thường bắt đầu từ vài nguồn hiển nhiên do khách hàng cung cấp. Trong quá trình khơi gợi từ những nguồn này, lại xuất hiện thêm các nguồn tiềm năng khác. Mục tiêu là xác định sớm các nguồn chính và quan trọng nhất — vì mọi hoạt động Kỹ nghệ Yêu cầu tiếp theo đều phụ thuộc vào điều này.

📌 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

Khi đề thi 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.”

Người hoặc tổ chức có ảnh hưởng đến 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 là nguồn yêu cầu chính và quan trọng nhất. Bỏ sót một bên liên quan sẽ ảnh hưởng nghiêm trọng đến chất lượng tập hợp yêu cầu cuối cùng. Phát hiện muộn — hoặc bỏ sót hoàn toàn — dẫn đến các sửa đổi rất tốn kém, hoặc tệ hơn là một hệ thống vô dụng (useless system).

Để hệ thống đáp ứng nhu cầu của tất cả các bên, việc xác định một cách có hệ thống các bên liên quan phải bắt đầu ngay từ đầu dự án, và kết quả phải được quản lý xuyên suốt quá trình phát triển. Bên liên quan có thể xuất hiện ở nhiều vị trí: 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à phát triển, vận hành viên), đối thủ cạnh tranh, cơ quan chính phủ và 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ó mối quan hệ có liên quan nào giữa người/tổ chức đó với hệ thống không?”

Hãy nhìn bên liên quan như những con người thực sự. Nếu xác định một tổ chức là bên liên quan, hãy hỏi: “Ai là đầu mối liên lạc? 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 do một đạo luật nhất định, đừng xác định Thủ tướng — hãy tìm trưởng bộ phận pháp chế nội bộ, người thực sự có thể cung cấp yêu cầu.

Không có một kỹ thuật tiêu chuẩn để xác định các bên liên quan nhưng mô hình hành tây của Alexander (Alexander’s onion model) [Alex2005] là điểm khởi đầu tốt. Mô hình này mô tả ba lớp bên liên quan bao quanh hệ thố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

Vào giai đoạn đầu của quá trình xây dựng yêu cầu, một số bên liên quan sẽ lộ diện rất rõ ràng — thường nằm ở lớp đầu tiên của mô hình hành tây, ví dụ như người dùng cuối (end users) hoặc quản trị viên ứng dụng (application managers). Họ có thể được lấy làm điểm xuất phát cho việc tìm kiếm các bên liên quan khác. Sau khi xác định họ là các nguồn hợp lệ, Kỹ sư Yêu cầu sẽ phân tích các mối quan hệ của họ ở cả những lớp bao quanh bên trong lẫn bên ngoài. Thông qua quá trình phân tích này, các bên liên quan mới sẽ được phát hiện, và chính họ lại có những mối quan hệ khác (thậm chí nhiều hơn) cần được tiếp tục mổ xẻ. Bạn có thể gọi đây là 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 phát hiện thêm người mới càng trở nên dễ dàng. Tuy nhiên, khi đã chạm đến các bên liên quan ở lớp môi trường rộng hơn (wider environment) của Alexander, mọi 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), đồng nghĩa với việc chúng sẽ không tiết lộ thêm nguồn mới nào nữa.

Bên cạnh việc từ một bên liên quan tìm ra các bên liên quan khác, tài liệu cũng thường xuyên hé lộ những bên liên quan mới. Các ví dụ điển hình bao gồm sơ đồ tổ chức, mô tả quy trình, báo cáo marketing và các tài liệu quy định. Để biết thêm thông tin về việc sử dụng tài liệu như một nguồn yêu cầu, xem Phần 4.1.2. Các danh sách kiểm tra (checklists) liệt kê những nhóm và vai trò điển hình của các bên liên quan có thể là một công cụ hữu ích để tránh bỏ sót những bên liên quan tiềm năng nhưng không dễ nhận thấy (inconspicuous). Ngoài ra, việc phân tích tệp các bên liên quan từ những hệ thống cũ (legacy) hoặc hệ thống tương tự cũng có thể mang lại nhiều sự trợ giúp đắc lực.

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

Thông tin này được lưu trong danh sách các bên liên quan (stakeholders list) — phải 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	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	Vắng mặt 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 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ột mối quan hệ tốt đẹp và cởi mở với các bên liên quan là chìa khóa để thu thập được những thông tin hữu ích từ họ. Điều này phụ thuộc chủ yếu vào các phẩm chất hành vi như tính chính trực, sự trung thực và lòng tôn trọng.

Việc giao tiếp cởi mở và thường xuyên về các kế hoạch, hoạt động và kết quả của bạn là điều thiết yếu. Đôi khi, bạn sẽ phải thuyết phục và chuyển hóa các bên liên quan từ thế đối đầu ban đầu trở thành những cộng tác viên. Với vai trò là Kỹ sư Yêu cầu, bạn phải hiểu rõ các bên liên quan kỳ vọng điều gì ở mình. Bạn cũng cần phải "tiếp thị" thuyết phục về giá trị công việc của mình (sell your work) bằng cách chỉ ra những lợi ích mà giải pháp mang lại, đồng thời tháo gỡ những trở ngại mà các bên liên quan đang gặp phải (hoặc dự đoán sẽ gặp phải) trên tiến trình hướng tới giải pháp đó.

Đáng tiếc là, không hiếm trường hợp một số bên liên quan (chủ yếu là nội bộ) lường trước được, hoặc thực tế đang phải gánh chịu, những tác động tiêu cực từ các thay đổi do dự án mang lại. Trong những tình huống như vậy, sẽ rất khó để nhận được sự hợp tác của họ, mặc dù bạn chắc chắn rất cần điều đó. Khi đó, việc leo thang (escalation) lên các cấp quản lý cao hơn trong tổ chức có thể là con đường duy nhất để tiếp tục, mặc dù mối quan hệ đạt được sau đó sẽ không hề lý tưởng. Quản trị mối quan hệ với các bên liên quan [Bour2009] là một phương pháp hiệu quả để đối phó với những vấn đề phát sinh từ họ.

Điều này đòi hỏi một quá trình liên tục nhằm giành được và duy trì sự ủng hộ cũng như cam kết của các bên liên quan, bằng cách thu hút đúng người vào đúng thời điểm, đồng thời thấu hiểu và quản lý các kỳ vọng của họ.

Để lôi cuốn các bên liên quan tham gia vào quá trình khơi gợi yêu cầu (elicitation), bạn phải đảm bảo họ hiểu rõ dự án đang làm về cái gì và vai trò của họ trong đó là gì. Bạn phải thấu hiểu nhu cầu của họ và cố gắng giải quyết những nhu cầu này ở mức tối đa có thể trong phạm vi thẩm quyền của bạn tại dự án. Mặc dù các bên liên quan xứng đáng được đối xử với sự tôn trọng, bạn cũng hoàn toàn có quyền yêu cầu điều tương tự từ họ, ít nhất là từ những người đang trực tiếp tham gia vào dự án. Điều này có nghĩa là họ phải sắp xếp thời gian cho bạn khi bạn cần. Họ nên cung cấp các thông tin mà bạn yêu cầu, cũng như những thông tin khác mà họ biết là có liên quan. Họ cần đưa ra phản hồi về các sản phẩm công việc của bạn một cách kịp thời và tránh việc đồn thổi (gossip) về dự án, v.v.

Các vấn đề với các bên liên quan thường nảy sinh khi quyền lợi và nghĩa vụ của Kỹ sư Yêu cầu và các bên liên quan (đối với hệ thống đề xuất hoặc dự án hiện tại) không được xác định rõ ràng, hoặc khi các nhu cầu tương ứng không được giải quyết thỏa đáng. Nếu gặp phải các vấn đề này, một dạng thỏa thuận với các bên liên quan (stakeholder agreement) hoặc hợp đồng bên liên quan (stakeholder contract) có thể giúp mang lại sự minh bạch cần thiết cho tất cả các bên. Khi việc này diễn ra trong nội bộ một tổ chức, sự hậu thuẫn (endorsement) từ ban quản lý cấp cao có thể góp phần làm tăng tỷ lệ thành công cho cách tiếp cận này.

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 đều có tương tác với người dùng — nếu không thì phát triển để làm gì? Tất nhiên, với các hệ thống con nhúng bên trong máy móc phức tạp, người dùng chỉ tương tác gián tiếp qua nhiều lớp hệ thống — và trong trường hợp đó, họ không phải là nguồn yêu cầu quan trọng nhất. Nhưng với nhiều hệ thống khác, người dùng sẽ tương tác 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ọ là yếu tố sống còn cho 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: 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. Dễ liên hệ và có thể tiếp cận, ảnh hưởng, thúc đẩy qua các kênh chính thứ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, thường không được biết đến cá nhân, và có thể không biết gì về dự án. Không thể tiếp cận qua kênh chính thức — cần quảng cáo, phần thưởng, hoặc 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í) là những cách hữu ích.

⚠️ BẪY ĐỀ THI

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

Phân loại nội bộ/bên ngoài không cần áp dụng cứng nhắc. Trong một số dự án, người dùng bên ngoài ít về số lượng và dễ tiếp cận nên có thể xử lý như nội bộ. Ngược lại, trong công ty lớn, khoảng cách đến người dùng nội bộ có thể rất lớn — và cần xử lý gần như người dùng bên ngoài.

Khi đã hiểu rõ cơ sở người dùng, hãy phân biệt 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 khác nhau, dùng hệ thống theo cách khác nhau, và có thể có quyền truy cập phân biệt — ví dụ: người nhập dữ liệu vs người giám sát kiểm tra dữ liệu. Hãy đảm bảo bao gồm đại diện của tất cả các vai trò trong quá trình khơi gợi.

Không có cái gọi là “Người dùng” đồng nhất. Người dùng không phải là một khối đồng chất gồm những người giống hệt nhau, mà là tập hợp các cá nhân với thói quen, mong muốn và nhu cầu riêng. Khi hệ thống có hàng nghìn người dùng, không thể tinh chỉnh yêu cầu cho từng người — nhưng cũng không nên nhắm vào “người dùng trung bình” vì cách đó thường không hiệu quả.

Thay vào đó, hãy phân biệt một số nhóm người dùng có điểm tương đồng nhất định. Trong thực tế, khoảng ba đến bảy nhóm thường hoạt động tốt nhất. 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.

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

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

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

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

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

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 được bổ sung thêm tên, địa chỉ, sở thích và ảnh chân dung — nhằm nhân cách hóa khái niệm trừu tượng đó, mang lại yếu tố con người cho nó. Điều này nhắc nhở rằng công việc của Kỹ sư Yêu cầu không chỉ là về sự thật mà còn về cảm xúc.

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

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

⚠️ BẪY ĐỀ THI

Nhóm mà persona đại diện là nhóm nhân tạo, không tồn tại trong thế giới thực mà chỉ trong bối cảnh của hệ thống hoặc dự án. Persona không phải là bên liên quan thực tế, chỉ là công cụ để cấu trúc hóa nhóm người dùng.

4.1.2 Tài liệu

Documents

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

Tài liệu nội bộ — Thường dễ lấy nhưng có thể bảo mật; thường cần ký NDA trước khi được truy cập.

Tài liệu bên ngoài — Thường khó tìm hơn nhưng thường là công khai; nếu không, phải đảm bảo được phép truy cập và sử dụng.

Tài liệu có thể đóng hai vai trò:

Dẫn đến nguồn khác: Ví dụ, một mô tả quy trình nội bộ có thể đề cập đến các vai trò liên quan — và đó là đầu mối dẫn đến bên liên quan mới.
Nguồn yêu cầu trực tiếp: Đặc biệt là các yêu cầu dễ bị bỏ sót — ràng buộc trong tiêu chuẩn và hướng dẫn công ty; yêu cầu trong thủ tục và hướng dẫn công việc; ý tưởng mới từ tài liệu marketing của đối thủ.

Cần nhớ rằng một tài liệu luôn liên quan đến một số người: tác giả, đối tượng mục tiêu, người quản lý kiểm tra sự tuân thủ, người chỉ ra sự tồn tại của nó, v.v. Tất cả những người đó đều có thể là bên liên quan tiềm năng.

Luôn kiểm tra tính hợp lệ và sự liên quan của tài liệu — thường cần bên liên quan xác nhận. Nếu rút ra yêu cầu từ tài liệu lỗi thời hoặc không còn hiệu lực, hệ thống xây dựng từ đó nhiều khả năng sẽ thất bại.

Quản lý tài liệu — Tương tự như quản lý bên liên quan:

Lưu 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à bắt buộc — để tránh làm việc với bản lỗi thời
Ưu tiên phiên bản cuối cùng (final versions); nếu phải dùng 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) — cần thiết để hiểu sự tiến hóa của hệ thống
Thiết lập quản lý tài liệu sớm là nền tảng tốt để xây dựng khả năng truy xuất nguồn gốc ngược (backward traceability) (Phần 6.6)

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

(Other) Systems

Các hệ thống khác cũng có thể là nguồn yêu cầu. Cũng có thể phân biệt nội bộ/bên ngoài với những cân nhắc tương tự về quyền truy cập và bảo mật.

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

⚠️ BẪY ĐỀ THI

Ràng buộc kỹ thuật từ quá khứ có thể không còn liên quan với hiện tại. Hệ thống cạnh tranh và tương đương thường là nguồn tốt để tìm delighters (xem 4.2.1). Đôi khi hệ thống mới và legacy phải cùng tồn tại trong một thời gian — dẫn đến yêu cầu bổ sung, ví dụ về chia sẻ dữ liệu.

Hệ thống giao tiếp (Interfacing systems) — Có mối quan hệ trực tiếp với hệ thống đang phát triển, trao đổi dữ liệu qua giao diện (đồng bộ hoặc bất đồng bộ, 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 đó thường là yếu tố sống còn — vì vậy cần hiểu hệ thống giao tiếp một cách chi tiết.

Đối với hệ thống cũ hoặc legacy, đừng tin tưởng hoàn toàn vào tài liệu — cần bằng chứng thực tế. Việc liên hệ với quản trị viên ứng dụng, kiến trúc sư hoặc nhà thiết kế của các hệ thống đó sẽ rất hữu ích, đặc biệt khi chính hệ thống giao tiếp cũng cần được cập nhật để cho phép giao diện mới.

Lưu ý: hệ thống giao tiếp tự nó cũng có người dùng — những người dùng đó có thể xứng đáng được xem xét là bên liên quan trong môi trường rộng hơn của Alexander cho 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 biến những mong muốn, nhu cầu, kỳ vọng ngầm định — vốn ẩn trong các nguồn — thành yêu cầu tường minh, dễ hiểu, có thể nhận biết và kiểm chứng.

Tiếp tục phép loại suy về giếng nước: đã tìm được giếng, bây giờ bắt đầu kéo dây để đưa nước lên. Phải dùng tất cả các giếng và kéo đúng cách để đảm bảo đầy đủ. Trong RE, điều này có nghĩa là phải chọn đúng kỹ thuật khơi gợi.

📌 GHI CHÚ ÔN THI

Hai nhóm 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 cốt lõi của Kỹ sư Yêu cầu là biết chọn đúng tổ hợp kỹ thuật trong từng hoàn cảnh. Việc chọn phụ thuộc vào nhiều yếu tố:

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

⚠️ 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ông phải chỉ một. Ngoài ra, trong thực tế RE, yêu cầu chức năng tường minh thường được chú ý quá mức, trong khi yêu cầu chất lượng và ràng buộc — vốn ngầm định hơn — lại bị bỏ qua. Hậu quả: hệ thống đáp ứng đủ yêu cầu chức năng nhưng lại kém hiệu suất, khó dùng, không tuân thủ kiến trúc hoặc vi phạm các ràng buộc — và không được chấp nhận.

Để khơi gợi yêu cầu chất lượng, có thể dùng danh sách kiểm tra dựa trên tiêu chuẩn ISO 25010 — ví dụ, chuẩn bị trước một buổi phỏng vấn. Với ràng buộc, hãy xem xét các hạn chế có thể có trong không gian giải pháp: kỹ thuật, kiến trúc, pháp lý, tổ chức, văn hóa, môi trường. Tài liệu liên quan thường có thể tìm thấy qua nhân viên nội bộ.

4.2.1 Mô hình Kano

The Kano Model

Một yếu tố quan trọng khi chọn kỹ thuật khơi gợi là hiểu bản chất và tầm quan trọng của yêu cầu đang cố gắng khám phá. Mô hình Kano [Verd2014] là công cụ hữu ích cho mục đích này.

🔑 THUẬT NGỮ — Ba danh mục Kano

Delighters (Excitement factors / Unconscious requirements) — Yếu tố phấn khích

Tính năng mà khách hàng không biết là có thể tồn tại — do đó không ai yêu cầu. Ví dụ: smartphone có thể dùng như máy chiếu. 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à điểm khác biệt thu hút rất nhiều người.

Satisfiers (Performance factors / Conscious requirements) — Yếu tố hài lòng

Tính năng mà khách hàng yêu cầu tường minh. Càng nhiều satisfiers → sự hài lòng càng cao. Nhưng 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 để quyết định.

Dissatisfiers (Basic factors / Subconscious requirements) — Yếu tố bất mãn / Yếu tố nền tảng

Tính năng mà khách hàng cũng không yêu cầu — nhưng lý do ngược lại: nó quá hiển nhiên, khách hàng không thể tưởng tượng hệ thống thiếu nó. Ví dụ: smartphone không có GPS. 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 dùng.

Mô hình Kano nhìn yêu cầu từ góc độ khách hàng, tập trung vào phân biệt các tính năng thay vì chỉ những nhu cầu được bày tỏ.

⚠️ BẪY ĐỀ THI — Bẫy quan trọng nhất về Kano

Delighters: Không được hỏi vì khách hàng không biết tính năng đó có thể có → kỹ thuật tốt nhất: field observation, prototyping, brainstorming, analogies.

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.

Satisfiers: Được hỏi tường minh → kỹ thuật tốt nhất: interviews, questionnaires, workshops.

Bên liên quan tự mình chủ yếu chỉ nói về satisfiers. Phát hiện dissatisfiers và delighters đòi hỏi kỹ thuật khác.

⚠️ BẪY ĐỀ THI — Kano thay đổi theo thời gian

Delighter → Satisfier → Dissatisfier (theo vòng đời sản phẩm).

Ví dụ điển hình: camera điện thoại — ban đầu không ai yêu cầu (delighter); rồi trở thành tính năng được yêu cầu và so sánh (satisfier); nay không có là không mua (dissatisfier).

Mô hình Kano gốc còn có thêm hai danh mục: yêu cầu vô thưởng vô phạt (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 báo nhà phát triển tìm phương án khác.

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

“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ẽ kết quả trung bình lên ma trận phân tích Kano → ô xuất hiện cho biết phân loại 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

Kỹ thuật thu thập xem xét các nguồn đã xác định và khơi gợi yêu cầu từ đó. Đây là những kỹ thuật phổ biến nhất trong RE.

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

Luôn được dùng trong tương tác với bên liên quan: Kỹ sư Yêu cầu đặt câu hỏi phù hợp để bên liên quan suy nghĩ và cung cấp thông tin từ đó rút ra yêu cầu.

Phỏng vấn (Interviews)

Kỹ thuật linh hoạt và phổ biến nhất; không cần công cụ đặc biệt
Thường là buổi một-một giữa Kỹ sư Yêu cầu và bên liên quan; có thể có nhóm nhỏ người được phỏng vấn
Thường cho ra satisfiers — thông tin có ý thức mà bên liên quan nói ra
Cần mục tiêu rõ ràng và chuẩn bị tốt; tiết lộ thông tin chi tiết và linh hoạt theo câu trả lời
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 bên liên quan trả lời cùng bộ câu hỏi có cấu trúc (trực tiếp, văn bản, hoặc trực tuyến)
Định lượng: câu hỏi đóng → xác nhận giả thuyết đã có, đánh giá nhanh, thống kê
Định tính: câu hỏi mở → tìm yêu cầu mới; kết quả phức tạp hơn, tốn thời gian hơn để chuẩn bị và đánh giá
Phù hợp nhất cho 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 rộng hơn

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

Tất cả các hình thức cộng tác giữa Kỹ sư Yêu cầu và những người khác.

Hội thảo (Workshops)

Thuật ngữ bao hàm nhiều hình thức nhóm — từ cuộc họp nhỏ không chính thức đến sự kiện hàng trăm người
Đị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 closure on deliverables that represent user requirements” [Gott2002]
Nắm bắt cái nhìn tổng thể nhanh nhờ tận dụng tương tác giữa người tham gia; nếu cần chi tiết hơn → tiếp tục bằng phỏng vấn hoặc bảng câu hỏi
Có thể dùng như kỹ thuật thu thập lẫn kỹ thuật sáng tạo

Crowd-based Requirements Engineering (Kỹ nghệ Yêu cầu dựa trên đám đông)

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

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

Bên liên quan được quan sát trong khi thực hiện quy trình thường ngày, không có sự can thiệp trực tiếp từ Kỹ sư Yêu cầu. Đặc biệt hiệu quả để tìm dissatisfiers — những thứ quá hiển nhiên đến mức bên liên quan không nghĩ đến việc đề cập.

📌 GHI CHÚ ÔN THI

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 trong đề thi.

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

Kỹ sư Yêu cầu quan sát người dùng cuối trong môi trường làm việc thực tế khi họ thực hiện các hoạt động liên quan
Thích hợp khi tương tác trực tiếp sẽ làm sao lãng người dùng hoặc làm sai lệch quy trình
Có thể áp dụng mà không thông báo cho đối tượng 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 chi tiết mà không dễ tìm bằng cách khác — vì hành động quá phức tạp để diễn đạt thành lời
Đòi hỏi nhiều chuẩn bị, con mắt tinh tường và nhiều thời gian; video rất hữu ích để ghi lại và xử lý sau

Học việc (Apprenticing)

Khác với field observation ở chỗ mang tính tham gia
Kỹ sư Yêu cầu (người học việc — apprentice) thực tập trong môi trường sẽ dùng hệ thống
Người dùng có kinh nghiệm (bậc thầy — masters) hướng dẫn người học việc
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: xây dựng sự thấu hiểu sâu sắc về lĩnh vực, nghiệp vụ và quy trình trước khi bắt đầu khơi gợi thực sự
Thường cần tiếp nối bằng phỏng vấn/bảng câu hỏi để xác minh ý tưởng ban đầu
Thời gian: thường từ một ngày đến vài tuần; có thể khó hoặc không thể tổ chức trong 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 tham gia

Apprenticing: tham gia thực tế như người học việc — nhưng vẫn 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 dùng bên liên quan trực tiếp mà dùng các sản phẩm công việc: tài liệu, hệ thống, hình ảnh, file âm thanh/video làm nguồn yêu cầu. Hữu ích đặc biệt khi bên liên quan không dễ tiếp cận. Thường tốn thời gian nhưng có thể tìm ra satisfiers và dissatisfiers rất chi tiết.

Khảo cổ hệ thống — System archaeology (đào sâu phân tích hệ thống cũ)

Trích xuất yêu cầu từ 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)
Chủ yếu dùng khi thay thế hệ thống đã dùng nhiều năm bằng hệ thống mới
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 cách khác
Cần thêm thời gian để xác nhận qua các kênh khác xem yêu cầu trích xuất còn hợp lệ không

Phân tích tài liệu (Document analysis) [Bowe2009]

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. 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 đã xem có thể dẫn đến tài liệu khác → quy trình lặp
Lựa chọn tài liệu — Từ tập lớn, 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, 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 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 trên hệ thống hiện có hoặc prototype
Dữ liệu có cấu trúc (đánh giá 5 sao trên app store) 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ệ, beta/A/B testing, mạng xã hội, call center
Điểm thấp và nhận xét tiêu cực → tìm dissatisfiers; điểm 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ó lẫn phát hiện 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 — nhiều yêu cầu vẫn áp dụng được cho hệ thống mới, tiết kiệm đáng kể thời gian và tiền
Đ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 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 các yêu cầu đó còn phù hợp 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

Trước đây, RE chủ yếu tập trung vào thu thập yêu cầu từ bên liên quan. Nhưng phần mềm ngày càng trở thành động lực đổi mới trong doanh nghiệp — điều này đòi hỏi RE phải chuyển sang vai trò mới hơn: hoạt động sáng tạo và giải quyết vấn đề. Bên liên quan không còn là nguồn yêu cầu duy nhất. Các hệ thống đổi mới cần tính năng mà bên liên quan hiện tại chưa thể hình dung ra.

Các kỹ thuật thiết kế và tạo ý tưởng ra đời để đáp ứng nhu cầu này — kích thích sáng tạo trong nhóm, tạo ra ý tưởng mới và phát triển thêm từ ý tưởng đã có. Chúng thường tạo ra yêu cầu đổi mới — thường là delighters.

📌 GHI CHÚ ÔN THI

Hai danh mục con:

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, không phải kỹ thuật đơn lẻ)

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

Thời gian và cơ hội để ý tưởng nảy sinh
Kiến thức về chủ đề — tăng khả năng có ý tưởng tạo sự khác biệt
Động lực — bộ não chỉ sáng tạo khi có lợi ích trực tiếp cho chủ nhân
An toàn — ý 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áng tạo để tìm hoặc tạo 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ề khả năng của các tính năng đổi mới nhất định. Thường áp dụng trong 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ể. Nguyên tắc cốt lõi: trì hoãn phán xét — tách tìm ý tưởng khỏi phân tích ý tưởng. Các quy tắc:

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
Tiếp nhận và kết hợp ý tưởng người khác là được phép và mong muốn
Phê bình ý tưởng của người khác bị cấm — dù ý tưởng đó có vẻ vô lý

Sau phiên: phân loại, đánh giá, ưu tiên hóa các ý tưởng → đầ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ủ đề phức tạp bằng cách dùng loại suy để hỗ trợ tư duy. Thành công phụ thuộc vào việc chọn đúng loại suy. Loại suy có thể gần (cùng vấn đề trong lĩnh vực khác) hoặc xa (ví dụ: so sánh tổ chức với sinh vật sống). 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 đó trở lại vấn đề gốc

Kết quả là các khái niệm và ý tưởng làm đầu vào cho khơi gợi tiếp theo.

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õ các nhu cầu mơ hồ của bên liên quan. Phụ thuộc nhiều vào tạo tác trực quan hoặc có thể sờ mó, hợp tác nhóm và phản hồi 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)

Nguyên mẫu là sản phẩm công việc trung gian tạo ra để sinh ra phản hồi — từ phác thảo trên giấy đến phiên bản tiền phát hành hoạt động được. Cho phép người dùng thử nghiệm hệ thống và điều tra các đặc điểm chưa rõ.

📌 GHI CHÚ ÔN THI

Prototyping dùng cho cả hai mục đích:

Khơi gợi (elicitation): Đặc biệt hiệu quả để tìm non-functional requirements, dissatisfiers và constraints — những thứ khó hiểu 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 trong hệ thống, bao gồm các tác nhân liên quan. Giúp khám phá các cách thực hiện quy trình thay thế nhau. Cấu trúc nhẹ nên dễ phát triển và thay đổi nhanh.
Bảng phân cảnh (storyboard): Dạng trực quan của kịch bản — thường là truyện tranh với các ô hình cho thấy persona tương tác với hệ thống.
Hữu ích để triển khai sớm ý tưởng về quy trình và hoạt động; áp dụng được trong cả khơi gợi (sớm) lẫn thẩm định (muộn)

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

Không phải một kỹ thuật đơn lẻ mà là khái niệm, triết lý, họ quy trình và hộp công cụ — tập trung vào đổi mới và giải quyết vấn đề. Hai nguyên tắc cơ bản trong mọi biến thể:

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, và làm. Vì vậy, tư duy thiết kế 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] — xen kẽ giữa tư duy phân kỳ (divergent) (khám phá rộng và sâu, tạo nhiều ý tưởng) và tư duy hội tụ (convergent) (tập trung, lọc, kết hợp thành kết quả cuối cùng).

Trình bày chi tiết về tư duy thiết kế nằm ngoài phạm vi 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 mâu thuẫn về một yêu cầu, hoặc các yêu cầu của họ không thể cùng tồn tại trong một hệ thống.

Kỹ thuật khơi gợi không đảm bảo tập hợp yêu cầu thu được là nhất quán. Trong và sau quá trình khơi gợi, gần như chắc chắn sẽ xuất hiện mâu thuẫn. Ví dụ:

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 bất đồng: “tất cả thông báo lỗi phải màu đỏ” vs “thông báo lỗi người dùng màu đỏ, loại khác màu xanh”

Vì không thể phát triển hệ thống trên nền tảng các yêu cầu mâu thuẫn, xung đột phải được giải quyết trước khi phát triển bắt đầu. Kỹ sư Yêu cầu phải đảm bảo tất cả bên liên quan đạt được sự hiểu biết chung và đồng ý với toàn bộ tập hợp yêu cầu trong phạm vi liên quan đến họ.

⚠️ BẪY ĐỀ THI

Phủ nhận hoặc bỏ qua xung đột không phải là lựa chọn. Ngược lại, nếu không phát hiện bất kỳ xung đột nào, bạn nên lo lắng — có thể bạn đã bỏ sót. Theo Boehm [Boeh1981]: càng phát hiện muộn, việc sửa 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 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 kết quả giải quyết

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

Xung đột thường bị ẩn, chỉ phát hiện được qua quan sát cẩn thận. Hai nơi cần để ý:

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: Tuyên bố mâu thuẫn giữa các bên liên quan, kết quả phân tích không nhất quán, thuật ngữ dùng không thống nhất.

Nhìn thấy những dấu hiệu trên không nhất thiết có nghĩa là có xung đột — nhưng nên nghi ngờ và thảo luận kỹ với bên liên quan để đưa xung đột ẩn ra ánh sáng.

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

Trước tiên phải xác định đây có phải là xung đột yêu cầu 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 loại xung đột khác do người khác giải quyết (quản lý bộ phận, trưởng nhóm).

Phải hiểu đầy đủ bản chất xung đột trước khi hành động. Cần thu thập thông tin về:

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

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

Sau khi hiểu rõ bản chất xung đột, thái độ các bên và ràng buộc dự án, Kỹ sư Yêu cầu chọn kỹ thuật giải quyết phù hợp (xem 4.3.3).

Bước đầu tiên luôn là các bên liên quan phải đồng ý với kỹ thuật được chọn trước khi áp dụng. Nếu một bên không chấp nhận kỹ thuật từ đầu, họ sẽ không chấp nhận kết quả — xung đột sẽ không được giải quyết.

📌 GHI CHÚ ÔN THI

Kỹ sư Yêu cầu không phải là một trong các bên xung đột → có thể và nên áp dụng kỹ thuật theo cách khách quan, trung lập hoàn toàn, chào đón bất kỳ kết quả nào.

Bước 4 — Ghi lại kết quả (Documentation of conflict resolution)

Cách giải quyết xung đột có thể ảnh hưởng đến 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 yêu cầu kết quả có thể trông bất hợp lý. Vì vậy cần ghi lại và truyền đạt:

Các giả định liên quan đến xung đột và việc giải quyết
Các phương án thay thế đã được cân nhắ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 và lý do
Người ra quyết định và những người đóng góp

Không ghi lại → sau một thời gian, bên liên quan có thể quên các quyết định đã đưa ra; nhà phát triển về sau có thể không hiểu lý do thiết kế và triển khai 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 bản chất nghiệp vụ

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 bản chất nghiệp vụ (Subject matter conflict) Xảy ra khi các bên thực sự có nhu cầu thực tế khác nhau do đặc thù nghiệp vụ của họ khác nhau — thường vì hệ thống được dùng trong các môi trường khác nhau (ví dụ: triển khai ở nhiều quốc gia với luật pháp khác nhau). Khó giải quyết vì các sự thật cơ bản không thay đổi được. Bước đầu: phân tích và ghi lại chi tiết các sự thật đó, để 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 các bên dùng dữ liệu không nhất quán hoặc giải thích cùng dữ liệu theo cách khác nhau — do giao tiếp kém, thiếu thông tin nền, khác biệt văn hóa, thành kiến. Ước tính như doanh số tương lai đặc biệt dễ gây loại này. Khó phát hiện vì Kỹ sư Yêu cầu thường nghĩ nguồn của mình là đúng — do thiên lệch này, thường nghi ngờ loại xung đột khác trước. Giao tiếp liên tục là chìa khóa để cả phát hiện lẫn giải quyết.

3. Xung đột lợi ích (Interest conflict) Dựa trên quan điểm khác nhau được hình thành bởi mục tiêu cá nhân, nhóm, hoặc vai trò. Với lợi ích cá nhân, bên liên quan thường không tiết lộ động cơ thực sự mà đưa ra lập luận có vẻ thực tế nhưng thực chất là nhân tạo. Giải quyết được hưởng lợi từ việc xác định và củng 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á nhân hơn và liên quan đến quan điểm dài hạn, toàn cầu. Giá trị ổn định hơn lợi ích, hiếm khi thay đổi. Các bên thường khăng khăng và không muốn nhượng bộ. Để giải quyết: tìm giá trị cao hơn gắn kết các bên. Loại này nổi tiếng khó giải quyết nhất.

5. Xung đột quan hệ (Relationship conflict) Thường bắt nguồn từ kinh nghiệm tiêu cực trong quá khứ với bên kia. Cảm xúc và hiểu lầm 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 và sự công bằng. Đưa thảo luận trở lại yêu cầu thường không giúp ích. Thường phải leo thang lên cấp thẩm quyền cao hơn; thay đổi người là giải pháp khả thi. Loại này thường đồng hành với loại xung đột khác (ví dụ: lợi ích).

6. Xung đột cơ cấu (Structural conflict) Liên quan đến bất bình đẳng quyền lực, cạnh tranh nguồn lực hạn chế, hoặc phụ thuộc cơ cấu. Sự mất cân bằng (thường chỉ một bên nhận thấy) gây 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. Cũng thường cần leo thang lên cấp thẩm quyền cao hơn.

📌 GHI CHÚ ÔN THI

Subject matter, data, interest và value conflict thường liên quan trực tiếp đến yêu cầu → Kỹ sư Yêu cầu nên giải quyết. Relationship và structural conflict thường không liên quan trực tiếp → Kỹ sư Yêu cầu có thể không phải bên phù hợp nhất để giải quyết.

Tuy nhiên trong thực tế, hầu hết xung đột rơi vào nhiều danh mục cùng lúc. Dù ai giải quyết, hãy đảm bảo nó được giải quyết — xung đột tồn đọng tiếp tục ảnh hưởng tiêu cực đến công việc của Kỹ sư Yêu cầu.

⚠️ 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 nhất: data conflicts)

Compromise — Thỏa hiệp (phù hợp: subject matter, interest, structural)

Voting — Bỏ phiếu (phù hợp: subject matter, interest)

Overruling — Áp đặt quyết định (phù hợp: interest, structural)

Definition of variants — Định nghĩa biến thể (phù hợp: subject matter, interest, value)

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

Thỏa thuận (Agreement)

Thảo luận tiếp tục cho đến khi tất cả các bên hiểu hoàn toàn quan điểm của nhau và đồng ý với một lựa chọn tất cả đều thích. Tốn thời gian nhưng nếu thành công → kết quả bền vững, tăng thêm động lực cho bên liên quan. Phổ biến trong data conflicts. Nếu không thành công trong khoảng thời gian hợp lý → chuyển sang kỹ thuật khác.

Thỏa hiệp (Compromise)

Tương tự thỏa thuận, nhưng các bên chấp nhận một lựa chọn không phải ưu tiên hàng đầu — vì duy trì xung đột còn tệ hơn nhượng bộ. Thỏa hiệp có thể chứa yếu tố mới do Kỹ sư Yêu cầu đưa vào. Một thỏa hiệp tốt là khi tất cả các bên đều cảm thấy sự cân bằng giữa những gì họ phải đánh đổi và những gì họ đạt được. Phù hợp với subject matter conflicts, và cũng hiệu quả với interest và structural.

Bỏ phiếu (Voting)

Tốt nhất khi cần 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. Tất cả bên liên quan tham gia — không chỉ các bên xung đột — phải hiểu đầy đủ các lựa chọn và hậu quả. Để tránh ảnh hưởng từ quyền lực: bỏ phiếu ẩn danh với người điều hành trung lập. Quy trình bỏ phiếu phải được thỏa thuận trước. Nhanh và dễ, nhưng bên thua sẽ thất vọng và cần được chú ý.

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

Khi 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 dùng dưới áp lực thời gian. Chuyển quyết định cho người có thẩm quyền cao hơn tất cả các bên xung đột. Một biến thể: thuê chuyên gia bên ngoài ra quyết định — nhưng phải đạt thỏa thuận trước về người đó. Tốt để giải quyết interest và structural conflicts.

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

Thay vì chọn một yêu cầu, 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 bằng cách phát triển hệ thống có thể cấu hình qua tham số. Trông như giải pháp hoàn hảo, nhưng đi kèm với cái giá: sự phức tạp tăng lên và chi phí tăng thêm cả cho phát triển lẫn vận hành và bảo trì. Chỉ khả thi khi có đủ thời gian và ngân sách.

⚠️ BẪY ĐỀ THI

Đề thi hay hỏi kỹ thuật nào KHÔNG phải là kỹ thuật giải quyết xung đột → Prototyping và Sampling là kỹ thuật khơi gợi/thẩm định, không phải giải quyết xung đột.

Kỹ thuật hỗ trợ (Auxiliary techniques) — không dùng đơn lẻ mà để hỗ trợ các kỹ thuật chính:

Consider-All-Facts (CAF): Xem xét các giải pháp theo một số tiêu chí định trước (chi phí, thời gian, rủi ro, nguồn lực) → làm rõ ưu nhược điểm của từng lựa chọn.
Plus-Minus-Interesting (PMI) [DeBo2005]: Xem xét ý tưởng từ nhiều góc độ. Người tham gia xác định: khía cạnh tích cực (plus) → tiêu cực (minus) → thú vị cần điều tra thêm. Lựa chọn nhiều plus nhất và ít minus nhất đượ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 — đánh giá các lựa chọn theo nhiều tiêu chí và tính điểm có trọng số. Lựa chọn điểm cao nhất thắng.

Các kỹ thuật hỗ trợ tạo ra cái nhìn sâu hơn về các lựa chọn. Chúng có thể dùng như kỹ thuật độc lập 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 yêu cầu đã được khơi gợi, cũng như từng yêu cầu đơn lẻ, đủ tốt để phát triển hệ thống tiếp theo.

Phân biệt với Verification (xác minh):

Validation kiểm tra đang xây đúng hệ thống không;

Verification kiểm tra đang xây hệ thống đúng cách không.

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

Cần thẩm định ba thứ trước khi bàn giao yêu cầu cho nhà phát triển hoặc nhà cung cấp:

Tài liệu bao phủ nhu cầu của bên liên quan đến đâu
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

Điều này áp dụng cho cả cách tiếp cận lặp lại (iterative) lẫn tuần tự (sequential) — dù mức độ chi tiết có thể khác nhau.

Thẩm định tốn thêm thời gian và chi phí. Điều quan trọng là phải theo dõi liên tục các lỗi xảy ra trong phát triển và vận hành. Nếu nguyên nhân gốc rễ (root cause) của lỗi nằm ở yêu cầu → quy trình thẩm định đã thất bại theo cách nào đó. Kỹ sư Yêu cầu phải liên tục và chủ động tìm cơ hội cải thiện quy trình thẩm định.

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 tham gia thẩm định. Khía cạnh then chốt: mức độ độc lập (degree of independence) giữa người khơi gợi và người thẩm định.

Độc lập thấp (mời người đã tham gia khơi gợi): rẻ và dễ tổ chức, nhưng có thể bỏ sót lỗi do đ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 hơn, nhưng thường hiệu quả hơn trong tìm ra lỗi nghiêm trọng.

→ 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 identification and correction)

Hấp dẫn là sửa ngay mỗi lỗi vừa tìm thấy — nhưng thường không hiệu quả vì:

Các lỗi có thể ảnh hưởng lẫn nhau; lỗi tìm sau có thể vô hiệu hóa cách sửa lỗi trước
Một yêu cầu bị đánh dấu là lỗi có thể chứng minh là đúng khi xem xét toàn bộ
Người thẩm định nên tập trung tìm lỗi, không phải nghĩ cách sửa

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

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

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

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.
Dự án tuần tự: Có thể thành lập nhóm riêng cho mỗi đợt thẩm định.

Tùy giai đoạ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, quản trị viên ứng dụng đều hữu ích. Đôi khi cần thêm 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ự: Phần lớn yêu cầu được thẩm định kỹ vào cuối giai đoạn ban đầu — nhưng đây không nên là lần duy nhất. Khi yêu cầu thay đổi hoặc mở rộng, chất lượng và tính nhất quán có thể bị ảnh hưởng → cần 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: Sprint planning, backlog refinement, sprint reviews, daily standups đều là cơ hội để thẩm định — nhưng thường chỉ tập trung vào yêu cầu chi tiết, dễ bỏ qua bức tranh tổng thể. Nên bắt đầu bằng thẩm định toàn bộ product backlog ngay đầu dự án hoặc một tăng trưởng (increment). Ngoài ra, hardening sprints (sprint củng cố/hoàn thiện trước khi release) 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 rất 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 lựa chọn kỹ thuật thẩm định: mô hình vòng đời, mức độ trưởng thành quy trình, độ phức tạp và rủi ro của hệ thống, yêu cầu pháp lý, nhu cầu về dấu vết kiểm toán (audit trail).

Trong tiến trình dự án:

Đầu dự án: Chu kỳ ngắn, nhẹ nhàng, thường xuyên → phổ biến trong agile
Cuối dự án: Kỹ thuật hình thức hơn, thực hiện một lần

Ngoài ra, trọng tâm cũng thay đổi:

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

Dựa trên 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 về soát xét, xem [OleA2018].

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

Tác giả gửi sản phẩm công việc cho nhóm nhỏ (thành viên nhóm, đồng nghiệp, người dùng) với yêu cầu thẩm định. Thực hành tốt là ghi lại nhận xét trong sổ đăng ký soát xét (review register). Tuy nhiên, do tính không hình thức, tác giả có thể tự quyết định dùng hay không dùng các nhận xét. Thường lặp qua nhiều bản nháp cho đến khi chất lượng đạt yêu cầu.

Nếu tất cả tham gia cam kết với chất lượng và dành đủ thời gian, informal reviews là cách rẻ, dễ và hiệu quả cho bản nháp đầu. Cho phiên bản cuối cùng → nên dùng kỹ thuật hình thức hơn.

Soát xét hình thức (Formal reviews) — 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ị trước, nghe và đặt câu hỏi ngẫu hứng
Nhận sản phẩm công việc trước cuộc họp để chuẩn bị câu hỏi
Khán giả 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 refinement trước vòng lặp và sprint review 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)
Cuộc họp gồm: moderator, tác giả và nhóm thanh tra viên (inspectors)
Inspectors được chọn từ đồng nghiệp, nghiệp vụ, người dùng, chuyên gia — kiểm tra dựa trên chuyên môn riêng, xác minh tuân thủ tiêu chuẩn/quy định, đánh giá theo mục tiêu đã thỏa thuận
Inspectors chuẩn bị kỹ 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: tác giả tham gia với vai trò người lắng nghe — giải thích những chỗ chưa rõ
Inspection theo quy trình nghiêm ngặt và có ghi chép — tập trung vào tìm lỗi, đo lường chất lượng, cung cấp dấu vết kiểm toán (audit trail) chi tiết
Thường dùng để quyết định phát hành sản phẩm công việc cho bước tiếp theo hoặc triển khai cuối cùng
Chủ yếu áp dụng trong (safety-)critical systems và business processes
Trong agile: đượ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 cho 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 bên liên quan và người dùng cơ hội có kinh nghiệm thực tế với phiên bản trung gian của hệ thống. Trái với soát xét tĩnh, kỹ thuật khám phá là động: nhìn vào hành vi thực tế (hoặc mô phỏng) của hệ thống qua giao diện người dùng. Người tham gia dùng hệ thống theo cách gần giống dự kiến trong môi trường sản xuất — tương đối tự do, đôi khi có hướng dẫn nhất định. Sau đó họ báo cáo kinh nghiệm và phản hồi về hành vi hiện tại của hệ thống.

Phổ biến trong phát triển lặp lại và tư duy thiết kế. Thực ra, toàn bộ 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ể coi là thẩm định khám phá liên tục 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 như hệ thống dự định — nhưng bên trong có thể chưa hoàn thiện, không hoạt động, hoặc hoàn toàn thiếu

Khơi gợi và thẩm định đi đôi với nhau

Prototyping và storyboarding hỗ trợ cả hai mục đích. Khi thẩm định yêu cầu đã khơi gợi trước đó, hầu 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 prototyping đều 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à beta (Alpha and beta testing)

Phiên bản tiền sản xuất đầy đủ tính năng được cung cấp cho người dùng cuối để vận hành với quy trình nghiệp vụ 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 nhỏ, có thể quan sát trong usability lab, có thể có hướng dẫn nhất định.
Beta testing: Tại địa điểm người dùng cuối trong sản xuất thực tế (hoặc môi trường người dùng tự chọn). Hệ thống cung cấp (thường miễn phí) cho nhóm người dùng (đôi khi được chọn, thường không xác định). Phân tích phản hồi sau thời gian dài đặc biệt hữu ích để kiểm tra các giả định từ 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 (thường đượ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, 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 nhóm đủ lớn để phân tích thống kê. Kết quả cho thấy chất lượng 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 tập hợp yêu cầu cho nhà phát triển; họ thử tạo ra các sản phẩm công việc trung gian — thiết kế, mã nguồn, test cases, hướng dẫn sử dụng. Hệ thống chưa hoạt động → đây là kỹ thuật tĩnh.

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

Một dạng tương tự có thể do chính Kỹ sư Yêu cầu thực hiện: ghi lại tập hợp yêu cầu dưới một hình thức biểu diễn khác — thường là chuyển đặ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 hiệu quả để phát hiện các sự bỏ sót (omissions). Nếu gặp vấn đề nghiêm trọng trong chuyển đổi → đó là dấu hiệu cần thẩm định thêm.

⚠️ 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 EN	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 (crowd), 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 do đặc thù nghiệp vụ khác nhau	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 Phiên bản cuối — hành văn thoát ý, blockquote callouts, bổ sung ghi chú ôn thi CPRE Foundation Level

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