Chương 2 – Các Nguyên tắc Cơ bản của Kỹ nghệ Yêu cầu

Bản dịch tiếng Việt — CPRE FL Handbook v1.3.0, April 2026

Ký hiệu ghi chú: 📌 ÔN THI · ⚠️ TRAP · 🔑 THUẬT NGỮ

Trong chương này, bạn sẽ tìm hiểu về chín nguyên tắc cơ bản của Kỹ nghệ Yêu cầu (RE).

2.1 Tổng quan về các Nguyên tắc

RE được chi phối bởi một tập hợp các nguyên tắc cơ bản áp dụng cho mọi nhiệm vụ, hoạt động và thực hành trong lĩnh vực này.

Một nhiệm vụ (task) là một khối công việc nhất quán cần được thực hiện — ví dụ: khơi gợi yêu cầu.
Một hoạt động (activity) là một hành động (hoặc tập hợp các hành động) mà một người hoặc nhóm thực hiện để hoàn thành một nhiệm vụ — ví dụ: xác định các bên liên quan trong quá trình khơi gợi yêu cầu.
Một thực hành (practice) là cách thức đã được chứng minh để thực hiện các nhiệm vụ hoặc hoạt động nhất định — ví dụ: dùng phỏng vấn để khơi gợi yêu cầu từ các bên liên quan.

!!! abstract “🔑 THUẬT NGỮ” - Task: A coherent chunk of work to be done. - Activity: An action or a set of actions that a person or group performs to accomplish a task. - Practice: A proven way of how to carry out certain types of tasks or activities.

!!! note “📌 ÔN THI” Quan hệ phân cấp: task → activity → practice. Task là đơn vị lớn nhất; activity là hành động để hoàn thành task; practice là cách đã được chứng minh để thực hiện activity hoặc task.

Ví dụ: "eliciting requirements" là **task** → "identifying stakeholders" là **activity** → "using interviews" là **practice**.

Các nguyên tắc trong Bảng 2.1 tạo thành nền tảng cho các thực hành được trình bày ở các chương sau.

Bảng 2.1 – Chín nguyên tắc cơ bản của Kỹ nghệ Yêu cầu

#	Tên nguyên tắc (EN)	Tên nguyên tắc (VI)
1	Value orientation	Định hướng giá trị
2	Stakeholders	Các bên liên quan
3	Shared understanding	Hiểu biết chung
4	Context	Bối cảnh
5	Problem, requirement, solution	Vấn đề, yêu cầu, giải pháp
6	Validation	Thẩm định
7	Evolution	Sự tiến hóa
8	Innovation	Đổi mới
9	Systematic and disciplined work	Làm việc có hệ thống và kỷ luật

!!! note “📌 ÔN THI” Phải thuộc tên tiếng Anh của cả 9 nguyên tắc vì đề thi dùng thuật ngữ tiếng Anh. Câu hỏi thường gặp: “Which of the following is NOT a fundamental principle of RE?” — đáp án bẫy thường là “Regular retrospectives” hoặc “Risk management”.

!!! danger “⚠️ TRAP” Nguyên tắc 6 là Validation — KHÔNG phải Verification.

- Validation = "Are we building the **right** system?" (đúng yêu cầu không?)
- Verification = "Are we building the system **right**?" (xây đúng spec không?)

IREB chỉ đưa Validation vào 9 nguyên tắc.

2.2 Giải thích các Nguyên tắc

2.2.1 Nguyên tắc 1 – Định hướng giá trị: Yêu cầu là phương tiện để đạt được mục đích, không phải là mục đích tự thân

Viết yêu cầu không phải là mục tiêu tự thân. Các yêu cầu chỉ có ý nghĩa — và đầu tư vào RE chỉ được biện minh — khi chúng thực sự tạo ra giá trị (xem Phần 1.2). Giá trị của một yêu cầu = lợi ích trừ đi chi phí.

Lợi ích (benefit): mức độ yêu cầu góp phần xây dựng hệ thống thành công — tức hệ thống thỏa mãn mong muốn và nhu cầu của các bên liên quan — đồng thời giảm rủi ro thất bại và làm lại tốn kém.
Chi phí (cost): chi phí để khơi gợi, thẩm định, tài liệu hóa và quản lý yêu cầu đó.

!!! abstract “🔑 THUẬT NGỮ” “We define the value of a requirement as being its benefit minus its cost.”

- **Benefit** = degree to which it contributes to (1) building successful systems + (2) reducing the risk of failure and costly rework.
- **Cost** = cost for **eliciting, validating, documenting, and managing** it.

!!! note “📌 ÔN THI” Benefit có 2 thành phần, Cost có 4 thành phần (eliciting + validating + documenting + managing). Đề thi hay hỏi “yếu tố nào cấu thành benefit/cost?” hoặc cho danh sách và hỏi cái nào KHÔNG thuộc cost.

Việc giảm rủi ro làm lại là một phần quan trọng trong lợi ích của một yêu cầu được soạn thảo tốt. Phát hiện và sửa một yêu cầu sai hoặc thiếu khi đang triển khai — hay tệ hơn, sau khi hệ thống đã vận hành — có thể tốn gấp 10 đến 100 lần so với việc đặc tả đúng ngay từ đầu. Vì vậy, phần lớn lợi ích của RE nằm ở việc tiết kiệm chi phí trong giai đoạn triển khai và vận hành.

Nói cách khác: lợi ích của RE là dài hạn, còn chi phí là ngay trước mắt. Điều này cần được tính đến khi khởi động dự án. Cắt giảm chi phí RE trong ngắn hạn sẽ phải trả giá bằng rủi ro làm lại cao hơn ở các giai đoạn sau.

Giá trị của RE có thể xem là tổng giá trị tích lũy của các yêu cầu được đặc tả. Vì khách hàng trả tiền cho hệ thống được xây dựng, chứ không phải cho các yêu cầu, nên giá trị kinh tế của RE hầu hết là gián tiếp. Lợi ích chính đến từ việc tiết kiệm chi phí làm lại — không phải từ bản thân tài liệu yêu cầu.

Các tác động kinh tế của Kỹ nghệ Yêu cầu hầu hết là gián tiếp; bản thân RE chỉ tốn chi phí.

!!! note “📌 ÔN THI” Câu highlight này hay ra dạng đúng/sai. RE mang giá trị gián tiếp vì: (1) khách hàng trả tiền cho hệ thống, không phải cho yêu cầu; (2) lợi ích chủ yếu đến từ giảm chi phí làm lại ở các giai đoạn sau.

Để tối ưu giá trị, Kỹ sư Yêu cầu phải cân bằng hợp lý giữa lợi ích và chi phí của từng yêu cầu. Ví dụ: tài liệu hóa nhu cầu của một bên liên quan thành yêu cầu giúp truyền đạt nhu cầu đó dễ hơn cho tất cả các bên, từ đó tăng xác suất hệ thống sẽ thỏa mãn nhu cầu đó — đây là lợi ích.

Yêu cầu càng ít mơ hồ và càng chính xác thì lợi ích càng cao — vì nó giảm nguy cơ kiến trúc sư và đội phát triển hiểu sai, dẫn đến làm lại tốn kém. Tuy nhiên, tăng độ chính xác cũng đồng nghĩa tăng chi phí khơi gợi và tài liệu hóa.

Khối lượng RE cần thiết để đạt giá trị tối ưu phụ thuộc vào nhiều yếu tố tình huống. Động lực chính để xác định mức đầu tư RE là rủi ro: rủi ro hệ thống không đáp ứng nhu cầu stakeholder, dẫn đến thất bại hoặc làm lại tốn kém. Để đánh giá mức độ quan trọng của từng yêu cầu, cần xem xét tầm quan trọng của stakeholder đã đưa ra yêu cầu đó (xem Nguyên tắc 2) và hậu quả nếu yêu cầu bị bỏ sót (Hình 2.1).

Hình 2.1 — Tầm quan trọng của yêu cầu theo vai trò bên liên quan và tác động khi bỏ sót

Ngoài ra, các yếu tố ảnh hưởng (influencing factors) sau cần được cân nhắc:

Nỗ lực cần thiết để đặc tả yêu cầu
Tính khác biệt của yêu cầu (mức độ đóng góp vào thành công của toàn hệ thống)
Mức độ hiểu biết chung giữa các bên liên quan và nhà phát triển
Sự tồn tại của các hệ thống tham chiếu (có thể đóng vai trò như đặc tả bằng ví dụ)
Chiều dài của chu trình phản hồi (khoảng thời gian giữa lúc hiểu sai và lúc phát hiện ra lỗi)
Loại mối quan hệ khách hàng–nhà cung cấp
Yêu cầu tuân thủ quy định

!!! note “📌 ÔN THI” 7 influencing factors hay ra dạng “yếu tố nào ảnh hưởng đến khối lượng RE?” hoặc “yếu tố nào KHÔNG phải influencing factor?”. Cần nhớ đủ cả 7.

Riêng "length of feedback cycle": chu trình phản hồi càng ngắn → cần đặc tả ít hơn, vì sai sót được phát hiện nhanh.

Hai quy tắc theo kinh nghiệm (rules of thumb):

Khối lượng RE tối ưu phụ thuộc vào tình huống cụ thể và được quyết định bởi nhiều yếu tố ảnh hưởng.

Nỗ lực đầu tư vào RE phải tỷ lệ nghịch với rủi ro mà bạn sẵn sàng chấp nhận.

!!! danger “⚠️ TRAP” Rule of thumb thứ hai rất dễ đọc ngược. “Inversely proportional to the risk you are willing to take” có nghĩa là: càng chấp nhận ít rủi ro → càng phải đầu tư nhiều cho RE.

- Hệ thống safety-critical (không chấp nhận rủi ro) → RE tối đa.
- Prototype nội bộ (chấp nhận rủi ro cao) → RE tối thiểu.

2.2.2 Nguyên tắc 2 – Các bên liên quan: RE là về việc thỏa mãn mong muốn và nhu cầu của các bên liên quan

Mục tiêu cuối cùng khi xây dựng một hệ thống là hệ thống đó phải giải quyết được vấn đề của người dùng và thỏa mãn mong đợi của các bên liên quan khác — chẳng hạn người đặt hàng, người trả tiền, hay người chịu trách nhiệm bảo mật trong tổ chức. RE có hai mục tiêu cốt lõi: hiểu đúng mong muốn và nhu cầu của các bên liên quan, và giảm thiểu rủi ro bàn giao một hệ thống không đáp ứng được điều đó (xem Định nghĩa 1.2, Phần 1.2).

Mỗi bên liên quan có một vai trò trong bối cảnh hệ thống sẽ được xây dựng — ví dụ: người dùng, khách hàng (client/customer), người vận hành, hoặc cơ quan quản lý. Tùy vào quy trình RE được dùng, các nhà phát triển cũng có thể là bên liên quan — điều này thường xảy ra trong Agile và phát triển định hướng thị trường. Một bên liên quan có thể đảm nhiệm nhiều hơn một vai trò cùng lúc. Với mỗi vai trò có liên quan, cần chọn những người phù hợp làm đại diện (representatives).

!!! danger “⚠️ TRAP” Developer CÓ THỂ là stakeholder — xảy ra trong Agile và market-oriented development. Không được mặc định developer = không phải stakeholder.

Khi một vai trò có quá nhiều cá nhân, hoặc không xác định được cụ thể ai, có thể dùng personas (nhân vật hư cấu đại diện cho nhóm người dùng có đặc điểm tương tự) thay thế. Với các hệ thống đang vận hành, những người dùng gửi phản hồi hoặc yêu cầu tính năng mới cũng nên được coi là bên liên quan.

Nên phân loại bên liên quan thành ba mức dựa trên mức độ ảnh hưởng đến sự thành công của hệ thống:

Trọng yếu (Critical): bỏ qua nhóm này sẽ gây vấn đề nghiêm trọng, có thể khiến hệ thống thất bại hoặc trở nên vô dụng.
Chính (Major): bỏ qua nhóm này sẽ ảnh hưởng bất lợi đến thành công của hệ thống, nhưng không đến mức thất bại.
Phụ (Minor): bỏ qua nhóm này hầu như không ảnh hưởng đến thành công của hệ thống.

!!! note “📌 ÔN THI” Ba mức phân loại (Critical / Major / Minor) được dùng cho 2 mục đích: (1) đánh giá mức độ quan trọng (criticality) của một yêu cầu, (2) đàm phán xung đột giữa các bên liên quan. Cần nhớ cả 2.

Chỉ xem xét yêu cầu của người dùng cuối và khách hàng là không đủ — bỏ sót các bên liên quan khác dễ dẫn đến dự án thất bại hoặc vượt ngân sách và thời hạn.

Việc thu hút đúng người vào đúng vai trò là yếu tố quyết định để RE thành công. Các thực hành để xác định, ưu tiên và làm việc với bên liên quan được thảo luận trong Chương 4.

Các bên liên quan ở các vai trò khác nhau tự nhiên sẽ có quan điểm khác nhau về hệ thống. Ví dụ: người dùng muốn hệ thống hỗ trợ tác vụ của họ tốt nhất, nhà quản lý muốn chi phí hợp lý, còn giám đốc an ninh quan tâm đến bảo mật. Ngay cả trong cùng một vai trò cũng có thể có nhu cầu khác nhau — ví dụ, người dùng không chuyên (casual users) có yêu cầu giao diện khác biệt đáng kể so với người dùng chuyên nghiệp (professional users).

!!! danger “⚠️ TRAP” “Casual users” ≠ “người dùng thỉnh thoảng” (occasional users). Casual = không chuyên, đối lập với professional. Sự khác biệt nằm ở mức độ thành thạo, không phải tần suất sử dụng.

Vì vậy, chỉ thu thập yêu cầu thôi là chưa đủ. Phải xác định và xử lý các mâu thuẫn giữa yêu cầu của các bên liên quan khác nhau — bằng cách tìm sự đồng thuận, bác bỏ (overruling), hoặc đặc tả các biến thể hệ thống cho từng nhóm có nhu cầu khác nhau (xem Phần 4.3).

2.2.3 Nguyên tắc 3 – Hiểu biết chung: Việc phát triển hệ thống thành công là không thể nếu thiếu một cơ sở chung

Phát triển hệ thống là nỗ lực tập thể. Để thành công, những người tham gia cần có hiểu biết chung về vấn đề và các yêu cầu phát sinh từ nó.

RE có nhiệm vụ tạo ra, thúc đẩy và bảo đảm hiểu biết chung giữa tất cả các bên: stakeholder, Kỹ sư Yêu cầu và đội phát triển. Có hai hình thức hiểu biết chung:

Hiểu biết chung tường minh (Explicit shared understanding): đạt được thông qua các yêu cầu được khơi gợi, tài liệu hóa cẩn thận và thỏa thuận rõ ràng. Đây là mục tiêu chính của RE trong các quy trình theo hướng kế hoạch (plan-driven).
Hiểu biết chung ngầm định (Implicit shared understanding): dựa trên kiến thức chung về nhu cầu, tầm nhìn, bối cảnh, v.v. Khi yêu cầu không được đặc tả đầy đủ bằng văn bản, sự hiểu biết ngầm định trở thành yếu tố then chốt. Điều này đặc biệt đúng trong mọi hình thức RE Agile.

!!! abstract “🔑 THUẬT NGỮ” - Explicit shared understanding: achieved through carefully elicited, documented, and agreed requirements. - Implicit shared understanding: based on shared knowledge about needs, visions, context, etc.

!!! danger “⚠️ TRAP” “Explicit” = tường minh — KHÔNG phải “hiện nổi”. “Hiện nổi” là salient/emerging, sai nghĩa hoàn toàn.

Ngoài ra: cả implicit lẫn explicit đều có thể **sai lầm (false)** — đây là chi tiết dễ bị bỏ qua khi ôn thi.

Cả hai hình thức đều có thể sai lầm: mọi người tin rằng họ hiểu nhau, nhưng thực tế lại diễn giải theo cách khác nhau. Vì vậy, không bao giờ được mù quáng dựa vào hiểu biết chung. Nhiệm vụ của RE là vừa tạo ra và thúc đẩy hiểu biết chung, vừa kiểm chứng xem hiểu biết chung đó có thực sự tồn tại không. Để không lãng phí nỗ lực, cần tập trung vào những khía cạnh thực sự liên quan — tức những gì nằm trong ranh giới bối cảnh của hệ thống (xem Nguyên tắc 4).

Kể cả khi có hiểu biết chung hoàn hảo, các yêu cầu quan trọng vẫn có thể bị bỏ sót đơn giản vì không ai nghĩ đến. Hình 2.2 minh họa điều này qua ví dụ về cặp vợ chồng muốn lắp xích đu trong vườn cho con — tờ giấy ghi chú ở giữa tượng trưng cho bản đặc tả bằng văn bản.

Hình 2.2 — Minh họa hiểu biết chung qua ví dụ xích đu

Các thực hành đã được chứng minh để xây dựng hiểu biết chung: làm việc với bảng thuật ngữ (Phần 3.5), tạo nguyên mẫu (Phần 3.7), hoặc dùng hệ thống hiện có làm điểm tham chiếu.

Để kiểm chứng hiểu biết chung tường minh, công cụ chính là thẩm định kỹ lưỡng tất cả yêu cầu đã đặc tả (xem Nguyên tắc 6 và Phần 4.4). Để kiểm chứng hiểu biết chung ngầm định, các thực hành thường dùng là: đưa ra ví dụ về kết quả mong đợi, xây nguyên mẫu, hoặc ước tính chi phí triển khai một yêu cầu. Thực hành quan trọng nhất để giảm thiểu tác động của hiểu biết chung sai lầm là dùng quy trình có vòng lặp phản hồi ngắn (short feedback loops) (Chương 5).

Có những yếu tố là tác nhân thúc đẩy (enablers) hoặc trở ngại (obstacles) cho hiểu biết chung:

Tác nhân thúc đẩy:

Kiến thức lĩnh vực
Các tiêu chuẩn đặc thù của ngành
Sự cộng tác thành công trước đây
Hệ thống tham chiếu mà tất cả các bên đều biết
Văn hóa và giá trị chung
Sự tin tưởng lẫn nhau có hiểu biết — không mù quáng!

Trở ngại:

Khoảng cách địa lý
Mối quan hệ nhà cung cấp–khách hàng có sự mất lòng tin
Thuê ngoài
Các ràng buộc quy định
Nhóm lớn và đa dạng
Tỷ lệ luân chuyển nhân sự cao

!!! note “📌 ÔN THI” Enablers và obstacles hay ra dạng “cái nào là enabler / obstacle?”. Outsourcing và regulatory constraints là obstacle. Càng nhiều enabler, ít obstacle → càng có thể dựa vào implicit shared understanding, và cần đặc tả ít hơn.

!!! danger “⚠️ TRAP” Enabler là “informed (not blind!) mutual trust” — chữ “informed” là chi tiết bẫy. Tin tưởng mù quáng KHÔNG phải enabler. Đề thi có thể viết “mutual trust” mà bỏ “informed” để xem thí sinh có để ý không.

Khi xác suất và tác động của hiểu biết chung sai lầm thấp, và enablers nhiều hơn obstacles, RE có thể dựa nhiều hơn vào hiểu biết chung ngầm định. Ngược lại, khi rủi ro sai lầm cao và obstacles chiếm ưu thế, các yêu cầu phải được đặc tả và thẩm định một cách tường minh.

2.2.4 Nguyên tắc 4 – Bối cảnh: Các hệ thống không thể được hiểu một cách cô lập

Yêu cầu không bao giờ xuất hiện cô lập. Chúng gắn với các hệ thống được nhúng trong một bối cảnh. Trong RE, “bối cảnh” có một nghĩa cụ thể:

!!! abstract “🔑 THUẬT NGỮ — Định nghĩa 2.1. Context (in RE)” “The part of a system’s environment being relevant for understanding the system and its requirements.”

Khi xác định bối cảnh, chúng ta giới hạn phạm vi xem xét trong miền ứng dụng (application domain) mà hệ thống được nhúng vào. Bối cảnh được xác định bởi hai ranh giới: ranh giới hệ thống và ranh giới bối cảnh (Hình 2.3).

!!! abstract “🔑 THUẬT NGỮ — Định nghĩa 2.2. Context boundary” “The boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements.”

Ranh giới bối cảnh tách phần môi trường có liên quan (cần xem xét trong RE) khỏi phần không liên quan (không ảnh hưởng đến hệ thống, không cần xem xét).

!!! abstract “🔑 THUẬT NGỮ — Định nghĩa 2.3. System boundary” “The boundary between a system and its surrounding context.”

Ranh giới hệ thống phân định hệ thống như nó sẽ tồn tại sau khi triển khai. Ban đầu ranh giới này thường chưa rõ và có thể thay đổi theo thời gian. Làm rõ ranh giới hệ thống và xác định các giao diện bên ngoài là nhiệm vụ RE thực sự.

Ranh giới hệ thống thường trùng với phạm vi phát triển hệ thống.

!!! abstract “🔑 THUẬT NGỮ — Định nghĩa 2.4. Scope” “The range of things that can be shaped and designed when developing a system.”

!!! danger “⚠️ TRAP” System boundary ≠ Scope. Chúng thường trùng nhau nhưng không phải lúc nào cũng vậy:

- Thành phần **trong** system boundary nhưng phải tái sử dụng nguyên trạng → nằm **ngoài scope**.
- Thứ **trong context** nhưng có thể thiết kế lại khi phát triển → nằm **trong scope**.

Đôi khi system boundary và scope không khớp nhau (Hình 2.3). Ví dụ: thành phần nằm trong system boundary nhưng phải tái sử dụng nguyên trạng — không thể định hình hay thiết kế lại — thì nằm ngoài scope. Ngược lại, thứ nằm trong context nhưng có thể được thiết kế lại khi phát triển hệ thống thì nằm trong scope.

Hình 2.3 — Ranh giới hệ thống, ranh giới bối cảnh và phạm vi

Do giao diện bên ngoài nằm ở ranh giới hệ thống, RE phải xác định giao diện nào nằm trong scope (có thể thiết kế) và giao diện nào đã cố định, nằm ngoài scope.

Chỉ xem xét yêu cầu trong ranh giới hệ thống là chưa đủ. Có ba lý do:

Thứ nhất: Khi scope bao gồm một phần context, thay đổi trong phần context đó có thể tác động đến yêu cầu của hệ thống. Ví dụ: tự động hóa một phần quy trình nghiệp vụ đôi khi đòi hỏi điều chỉnh chính quy trình đó — và điều chỉnh này sẽ ảnh hưởng đến yêu cầu hệ thống.

Thứ hai: Có thể có các hiện tượng trong thế giới thực mà hệ thống cần giám sát hoặc kiểm soát. Những hiện tượng này cần được phát biểu thành yêu cầu miền (domain requirements) và ánh xạ sang yêu cầu hệ thống (system requirements). Ví dụ: xét hệ thống điều khiển hộp số tự động của một chiếc ô tô. Bối cảnh của hệ thống này bao gồm chính chiếc ô tô. Trong bất kỳ ô tô nào có hộp số tự động, có một yêu cầu: vị trí đỗ chỉ được cài khi xe đứng yên. Đây là yêu cầu miền. Nhưng bộ điều khiển không thể cảm nhận trực tiếp “xe đứng yên” — nó phải được ánh xạ thành hiện tượng đo được, chẳng hạn tín hiệu từ cảm biến quay bánh xe. Yêu cầu hệ thống tương ứng: “Hệ thống chỉ cho phép cài vị trí đỗ khi không nhận được xung nào từ cảm biến quay của bánh xe.”

Thứ ba: Một số yêu cầu chỉ thỏa mãn được nếu các giả định miền (domain assumptions) nhất định trong context được giữ vững. Giả định miền là các giả định về hiện tượng trong thế giới thực. Ví dụ: hệ thống kiểm soát không lưu (ATS) có yêu cầu R1 — “ATS phải duy trì vị trí chính xác của tất cả máy bay đang được kiểm soát.” Yêu cầu này chỉ thỏa mãn được nếu radar hoạt động đúng và các máy bay phản hồi đúng tín hiệu. Hơn nữa, R1 còn phụ thuộc vào các giả định miền như: radar không bị gây nhiễu bởi kẻ tấn công, và không có máy bay nào bay thấp hơn tầm phát hiện của radar.

RE phải xem xét các hiện tượng trong context hệ thống, không chỉ dừng ở ranh giới hệ thống. Cụ thể, cần trả lời:

Thay đổi trong context tác động như thế nào đến yêu cầu của hệ thống?
Yêu cầu thực tế nào trong context liên quan đến hệ thống sẽ phát triển?
Làm thế nào ánh xạ đúng các yêu cầu thực tế đó sang yêu cầu hệ thống?
Giả định miền nào phải được giữ vững để hệ thống hoạt động đúng?

!!! note “📌 ÔN THI” Domain assumptions phải được kiểm tra trong quá trình validation (Nguyên tắc 6 — điểm 3 trong checklist). Ví dụ ATS: “radar không bị jam” và “không có máy bay bay thấp hơn tầm phát hiện” là domain assumptions, không phải system requirements.

2.2.5 Nguyên tắc 5 – Vấn đề, yêu cầu, giải pháp: Một bộ ba đan xen không thể tránh khỏi

Vấn đề, yêu cầu và giải pháp luôn đan xen nhau — đây là điều không thể tránh khỏi. Bất kỳ khi nào người dùng không hài lòng với cách mọi thứ đang vận hành, đó là dấu hiệu của một vấn đề. Để giải quyết vấn đề đó, có thể phát triển và triển khai một hệ thống kỹ thuật–xã hội (socio-technical system). Các yêu cầu đối với hệ thống phải được nắm bắt để hệ thống trở thành giải pháp hiệu quả.

Đặc tả yêu cầu mà không có vấn đề cần giải quyết — hoặc không có giải pháp được phát triển — là vô nghĩa. Tương tự, phát triển giải pháp mà không biết nó giải quyết vấn đề gì cũng vậy.

Quan trọng: vấn đề, yêu cầu và giải pháp không nhất thiết xuất hiện theo thứ tự này. Khi thiết kế hệ thống đổi mới, các ý tưởng giải pháp có thể tạo ra nhu cầu người dùng — những nhu cầu này sau đó được xây dựng thành yêu cầu và triển khai trong giải pháp thực tế.

Bộ ba này đan xen theo nhiều cách:

Đan xen phân cấp (Hierarchical intertwinement): trong hệ thống lớn, yêu cầu cấp cao dẫn đến quyết định thiết kế cấp cao, quyết định đó lại thông tin cho yêu cầu cấp thấp hơn, và tiếp tục như vậy.
Tính khả thi kỹ thuật (Technical feasibility): đặc tả yêu cầu không khả thi là lãng phí; nhưng đánh giá tính khả thi thường đòi hỏi phải khám phá giải pháp kỹ thuật trước.
Thẩm định (Validation): các nguyên mẫu — công cụ mạnh để thẩm định yêu cầu — bản thân cũng là giải pháp một phần.
Thiên kiến giải pháp (Solution bias): các bên liên quan khác nhau hình dung các giải pháp khác nhau cho cùng một vấn đề, dẫn đến yêu cầu mâu thuẫn nhau.

!!! danger “⚠️ TRAP” “Solution bias” là bẫy phổ biến: stakeholder mô tả giải pháp thay vì vấn đề. RE Engineer phải nhận ra điều này và đặt câu hỏi để khai thác vấn đề thực sự đằng sau.

Waterfall không hoạt động tốt vì nó giả định có thể tách hoàn toàn RE khỏi design — điều mâu thuẫn với bản chất đan xen của bộ ba này.

Sự đan xen này có hệ quả với quy trình phát triển:

Tách hoàn toàn RE khỏi thiết kế và triển khai là hiếm khi khả thi. Quy trình waterfall nghiêm ngặt không hoạt động tốt vì lý do này.
Dù vậy, Kỹ sư Yêu cầu vẫn cố gắng tách biệt các mối quan tâm về yêu cầu khỏi các mối quan tâm về giải pháp khi suy nghĩ, giao tiếp và tài liệu hóa — vì điều đó giúp các nhiệm vụ RE dễ xử lý hơn.

Bất chấp sự đan xen không thể tránh khỏi của các vấn đề, yêu cầu và giải pháp, Kỹ sư Yêu cầu vẫn nỗ lực tách biệt các mối quan tâm về yêu cầu khỏi các mối quan tâm về giải pháp khi suy nghĩ, giao tiếp và tài liệu hóa.

2.2.6 Nguyên tắc 6 – Thẩm định: Các yêu cầu chưa được thẩm định là vô dụng

Khi phát triển hệ thống, hệ thống cuối cùng được triển khai phải thỏa mãn nhu cầu của các bên liên quan. Nhưng kiểm tra điều này vào cuối dự án là rất rủi ro. Để kiểm soát rủi ro ngay từ sớm, thẩm định yêu cầu phải bắt đầu ngay trong quá trình RE (Hình 2.4).

Hình 2.4 — Thẩm định phải bắt đầu trong quá trình RE, không chờ đến cuối dự án

!!! abstract “🔑 THUẬT NGỮ — Định nghĩa 2.5. Validation” “The process of confirming that an item (a system, a work product, or a part thereof) matches its stakeholders’ needs.”

Trong RE, thẩm định là xác nhận rằng các yêu cầu đã đặc tả phù hợp với nhu cầu của bên liên quan — hay nói cách khác: xác nhận xem đúng yêu cầu (the right requirements) đã được đặc tả chưa.

Thẩm định là hoạt động cốt lõi trong RE: không thể có đặc tả mà thiếu thẩm định.

Khi thẩm định yêu cầu, cần kiểm tra ba điều:

Các bên liên quan đã đạt được thỏa thuận về yêu cầu chưa — xung đột đã được giải quyết, ưu tiên đã được thiết lập?
Mong muốn và nhu cầu của các bên liên quan có được bao phủ đầy đủ không?
Các giả định miền (xem Nguyên tắc 4) có hợp lý không — tức là có thể kỳ vọng rằng chúng sẽ được đáp ứng khi hệ thống vận hành?

!!! note “📌 ÔN THI” Ba điểm kiểm tra khi validation phải nhớ đủ cả 3. Điểm 3 (domain assumptions) thường bị bỏ sót nhất. Validation phải bắt đầu trong quá trình RE — không phải chờ đến cuối dự án.

!!! danger “⚠️ TRAP” Validation ≠ Verification.

- Validation = "Are we building the **right** system?" (đúng yêu cầu stakeholder không?)
- Verification = "Are we building the system **right**?" (xây đúng spec không?)

IREB dùng "validation" rất nhất quán cho Nguyên tắc 6 — không được nhầm sang verification trong bài thi.

Các thực hành để thẩm định yêu cầu được thảo luận trong Phần 4.4.

2.2.7 Nguyên tắc 7 – Sự tiến hóa: Thay đổi yêu cầu không phải là tai nạn, mà là trường hợp bình thường

Mọi hệ thống kỹ thuật đều phải tiến hóa. Nhu cầu, quy trình nghiệp vụ và khả năng công nghệ thay đổi liên tục. Kéo theo đó, yêu cầu đối với hệ thống cũng sẽ thay đổi. Nếu không, hệ thống và các yêu cầu của nó sẽ dần mất giá trị và trở nên vô dụng.

Yêu cầu có thể thay đổi trong khi Kỹ sư Yêu cầu vẫn đang khơi gợi các yêu cầu khác, khi hệ thống đang được xây dựng, hoặc sau khi đã triển khai.

Các lý do phổ biến khiến yêu cầu thay đổi:

Quy trình nghiệp vụ bị thay đổi
Đối thủ ra mắt sản phẩm hoặc dịch vụ mới
Khách hàng thay đổi ưu tiên hoặc ý kiến
Thay đổi công nghệ
Người dùng phản hồi yêu cầu tính năng mới hoặc thay đổi
Phát hiện lỗi trong yêu cầu hoặc giả định miền

Yêu cầu cũng thay đổi do phản hồi từ bên liên quan khi thẩm định, phát hiện lỗi trong các yêu cầu đã khơi gợi trước đó, hoặc do nhu cầu thực tế đã thay đổi.

Điều này đặt Kỹ sư Yêu cầu vào thế phải cân bằng hai mục tiêu tưởng chừng mâu thuẫn:

Cho phép yêu cầu thay đổi (Permit requirements to change): phớt lờ sự tiến hóa của yêu cầu là vô ích.
Giữ yêu cầu ổn định (Keep requirements stable): không có sự ổn định nhất định, chi phí thay đổi sẽ tăng đến mức không kiểm soát được. Hơn nữa, đội phát triển không thể làm việc có hệ thống khi yêu cầu thay đổi hàng ngày.

Kỹ sư Yêu cầu cần quản lý sự tiến hóa của yêu cầu. Nếu không, sự tiến hóa sẽ quản lý họ.

!!! note “📌 ÔN THI” Câu highlight này hay ra đề nhất của Nguyên tắc 7. Giải pháp cho tension giữa “permit change” và “keep stable” là change processes (Phần 6.7) — không phải chọn một trong hai.

!!! danger “⚠️ TRAP” “Permit change” và “keep stable” KHÔNG phải mâu thuẫn cần chọn một — đây là tension cần quản lý đồng thời. “Requirements Engineers must choose between permitting change OR keeping stable” → SAI.

Các quy trình thay đổi giải quyết cả hai mục tiêu này được thảo luận trong Phần 6.7.

2.2.8 Nguyên tắc 8 – Đổi mới: Chỉ làm nhiều hơn những điều cũ là không đủ

RE quan tâm đến việc thỏa mãn nhu cầu của các bên liên quan — nhưng Kỹ sư Yêu cầu chỉ đóng vai “máy ghi âm”, ghi lại đúng y những gì stakeholder nói, là đang làm sai việc. Cung cấp cho stakeholder chính xác những gì họ yêu cầu có nghĩa là bỏ lỡ cơ hội làm tốt hơn.

Ví dụ: một công ty bảo hiểm muốn làm mới hệ thống báo cáo cho đại lý. Báo cáo phổ biến nhất là bảng 18 cột — rộng gấp đôi màn hình laptop, phải cuộn rất nhiều để xem. Stakeholder yêu cầu thêm nút phóng to (cộng/trừ) trên màn hình.

Kỹ sư Yêu cầu giỏi sẽ không chỉ ghi lại điều này — họ sẽ đặt câu hỏi. Kết quả: công ty chuẩn bị thay laptop bằng tablet, nên gesture hai ngón tay sẽ tốt hơn nút bấm. Hơn nữa, ba cột có thể loại bỏ với thay đổi nhỏ về quy tắc báo cáo — công ty đồng ý. Chỉ có sáu cột là luôn cần thiết; các cột còn lại chỉ dùng trong trường hợp đặc biệt.

Từ đó, Kỹ sư Yêu cầu đề xuất: (1) báo cáo hiển thị thông tin như hệ thống cũ, trừ ba cột đã bỏ; (2) khi mở báo cáo, sáu cột quan trọng hiển thị đầy đủ chiều rộng, các cột còn lại thu gọn về chiều rộng tối thiểu; (3) đại lý mở rộng cột thu gọn bằng cách chạm vào tiêu đề.

Kết quả: đại lý nhận được hệ thống thực sự giải quyết vấn đề của họ — không chỉ là một vá víu tạm thời cho báo cáo quá khổ.

Đây là cách đổi mới xuất hiện. Kỹ sư Yêu cầu giỏi luôn hướng đến đổi mới: không chỉ thỏa mãn stakeholder mà còn làm cho họ hạnh phúc, phấn khích hoặc cảm thấy an toàn. Đồng thời, họ tránh bẫy của việc nghĩ rằng mình biết mọi thứ hơn stakeholder.

Kỹ sư Yêu cầu giỏi đi xa hơn những gì các bên liên quan nói với họ.

!!! note “📌 ÔN THI” Ba trạng thái “happy, excited, or feel safe” liên kết với Mô hình Kano (Phần 4.2.1). Nguyên tắc 8 có hai chiều: quy mô nhỏ (exciting features, ease of use) và quy mô lớn (disruptive innovation).

!!! danger “⚠️ TRAP” Innovation KHÔNG có nghĩa là Kỹ sư Yêu cầu áp đặt quan điểm lên stakeholder. “Good RE Engineers should override stakeholder preferences to achieve innovation” → SAI.

Câu "avoid the trap of believing that they know everything better than the stakeholders" là điểm cân bằng bắt buộc.

Ở quy mô nhỏ, RE thúc đẩy đổi mới bằng cách hướng đến các tính năng mới thú vị và tính dễ dùng. Ở quy mô lớn, Kỹ sư Yêu cầu cần cùng stakeholder khám phá xem có cách đột phá nào để làm mọi việc tốt hơn không. Phần 4.2 thảo luận về các kỹ thuật thúc đẩy đổi mới trong RE.

2.2.9 Nguyên tắc 9 – Làm việc có hệ thống và kỷ luật: Chúng ta không thể thiếu điều này trong RE

RE không phải là nghệ thuật — đây là kỷ luật (discipline), đòi hỏi phải thực hiện có hệ thống. Dù dùng quy trình phát triển nào, RE vẫn cần được thực hiện có hệ thống — từ khơi gợi, tài liệu hóa, thẩm định đến quản lý yêu cầu. Ngay cả trong dự án ad-hoc, một cách tiếp cận RE có hệ thống — ví dụ: chủ động thúc đẩy hiểu biết chung (xem Nguyên tắc 3) — vẫn sẽ cải thiện chất lượng hệ thống tạo thành.

Tính Agile và tính linh hoạt không phải là lý do chính đáng cho phong cách làm việc thiếu hệ thống, đặc ứng trong RE.

!!! danger “⚠️ TRAP” Nguyên tắc 9 KHÔNG phủ nhận Agile. Nó khẳng định: ngay cả trong Agile, RE vẫn phải có hệ thống và kỷ luật. “In agile projects, RE does not need to be systematic” → SAI.

Không có quy trình RE hay bộ thực hành RE nào hoạt động tốt trong mọi tình huống: không có “một kích cỡ vừa cho tất cả” (no one size fits all) trong RE.

!!! note “📌 ÔN THI” “No one size fits all” là điểm mấu chốt — Kỹ sư Yêu cầu phải cấu hình quy trình phù hợp với từng tình huống, không áp dụng cùng một quy trình cho mọi dự án.

RE là discipline (kỷ luật) chứ không phải art (nghệ thuật): có phương pháp, có nguyên tắc, nhưng phải linh hoạt áp dụng.

Làm việc có hệ thống và kỷ luật có nghĩa là Kỹ sư Yêu cầu:

Cấu hình quy trình RE phù hợp với vấn đề đang giải quyết và khớp với quy trình phát triển hệ thống (xem Chương 5).
Chọn từ tập hợp các thực hành và sản phẩm công việc RE sẵn có, những thứ phù hợp nhất với vấn đề, bối cảnh và môi trường làm việc (xem Chương 3, 4 và 6).
Không luôn dùng cùng một quy trình và thực hành cho mọi dự án.
Không tái sử dụng quy trình từ dự án RE thành công trước đó mà không có sự phản tư.

2.3 Tài liệu đọc thêm

Glinz [Glin2008] thảo luận về giá trị của các yêu cầu chất lượng và của yêu cầu nói chung [Glin2016]. Glinz và Wieringa [GlWi2007] giải thích khái niệm và tầm quan trọng của bên liên quan. Glinz và Fricker [GlFr2015] thảo luận về hiểu biết chung. Jackson [Jack1995b] và Gunter et al. [GGJZ2000] là nền tảng cho vấn đề yêu cầu trong bối cảnh. Pohl [Pohl2010] cũng thảo luận về vai trò của bối cảnh trong RE. Gause và Weinberg [GaWe1989] thảo luận về sự phụ thuộc lẫn nhau của vấn đề và giải pháp. Swartout và Balzer [SwBa1982] là những người đầu tiên chỉ ra rằng tạo bản đặc tả hoàn chỉnh trước khi triển khai là hiếm khi khả thi. Grünbacher và Seyff [GrSe2005] thảo luận về đàm phán yêu cầu để đạt thỏa thuận. Kano et al. [KSTT1984] là những người đầu tiên nhấn mạnh vai trò của đổi mới. Maalej et al. [MNJR2016] thảo luận về phản hồi người dùng tường minh và ngầm định trong RE. Maiden et al. [MaGR2004] thảo luận về sáng tạo và đổi mới trong RE. Gorschek et al. [GFPK2010] phác thảo quy trình đổi mới có hệ thống.

Phụ lục

🔑 Tổng hợp thuật ngữ cần thuộc nguyên văn tiếng Anh

Thuật ngữ	Định nghĩa nguyên văn EN
Task	A coherent chunk of work to be done.
Activity	An action or a set of actions that a person or group performs to accomplish a task.
Practice	A proven way of how to carry out certain types of tasks or activities.
Value of a requirement	Its benefit minus its cost.
Explicit shared understanding	Achieved through carefully elicited, documented, and agreed requirements.
Implicit shared understanding	Based on shared knowledge about needs, visions, context, etc.
Context (in RE)	The part of a system’s environment being relevant for understanding the system and its requirements.
Context boundary	The boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements.
System boundary	The boundary between a system and its surrounding context.
Scope	The range of things that can be shaped and designed when developing a system.
Validation	The process of confirming that an item (a system, a work product, or a part thereof) matches its stakeholders’ needs.

⚠️ Tổng hợp bẫy đề thi

Bẫy	Sự thật
Nguyên tắc 6 là “Verification”	Phải là Validation
Developer không phải stakeholder	Trong Agile và market-oriented, developer có thể là stakeholder
Casual user = người dùng thỉnh thoảng	Casual = không chuyên, đối lập với professional
Explicit = “hiện nổi”	Explicit = tường minh
Mutual trust là enabler vô điều kiện	Phải là informed (not blind!) mutual trust
System boundary = Scope	Hai khái niệm khác nhau, chỉ thường trùng nhau
“Permit change” hoặc “keep stable” — chọn một	Phải quản lý đồng thời cả hai
Innovation = Kỹ sư Yêu cầu áp đặt quan điểm	Vẫn phải tránh bẫy “biết tốt hơn stakeholder”
Agile không cần RE có hệ thống	Nguyên tắc 9 áp dụng cho mọi phương pháp phát triển
RE nhiều hơn khi rủi ro chấp nhận được cao hơn	Inversely proportional: ít chấp nhận rủi ro → RE nhiều hơn