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

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 tất cả các nhiệm vụ, hoạt động và thực hành trong RE.

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 một tập hợp các hành động mà một người hoặc một 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 khi khơi gợi yêu cầu).
Một thực hành (practice) là một cách thức đã được chứng minh để thực hiện một số loại nhiệm vụ hoặc hoạt động nhất định (ví dụ: sử dụng phỏng vấn để khơi gợi yêu cầu từ các bên liên quan).

🔑 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.

📌 GHI CHÚ Ô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/task. Ví dụ: “eliciting requirements” là task → “identifying stakeholders” là activity → “using interviews” là practice.

Các nguyên tắc được liệt kê 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 trong các chương tiếp theo của cuốn sổ tay này.

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

📌 GHI CHÚ ÔN THI

Phải thuộc tên tiếng Anh của cả 9 nguyên tắc. Câu hỏi thường gặp: “Which of the following is NOT a fundamental principle of RE?” — đáp án sai thường là “Regular retrospectives” hoặc “Risk management”.

⚠️ BẪY ĐỀ THI

Nguyên tắc 6 là Validation — KHÔNG phải Verification. Validation = “Are we building the right system?”; Verification = “Are we building the system right?”. 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

Hành động viết các yêu cầu không phải tự nó là một mục tiêu. Các yêu cầu chỉ hữu ích — và nỗ lực đầu tư vào Kỹ nghệ Yêu cầu chỉ được biện minh — nếu chúng gia tăng giá trị, tham chiếu Phần 1.2. Chúng tôi định nghĩa giá trị của một yêu cầu là lợi ích của nó trừ đi chi phí của nó.

Lợi ích (benefit): mức độ mà yêu cầu đóng góp vào việc xây dựng các hệ thống thành công (tức là các hệ thống thỏa mãn mong muốn và nhu cầu của các bên liên quan của chúng) và giảm thiểu rủi ro thất bại cũng như làm lại tốn kém trong quá trình phát triển hệ thống.
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 đó.

🔑 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.

📌 GHI CHÚ Ô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 thiểu rủi ro phải làm lại trong quá trình phát triển là một phần cấu thành lợi ích của một yêu cầu được soạn thảo tốt. Việc phát hiện và sửa chữa một yêu cầu bị thiếu hoặc sai trong quá trình triển khai hoặc khi hệ thống đã đi vào vận hành có thể dễ dàng tiêu tốn gấp mười hoặc một trăm lần chi phí so với việc đặc tả yêu cầu đó một cách đúng đắn ngay từ đầu. Hệ quả là, một lượng lớn lợi ích của các yêu cầu đến từ việc tiết kiệm chi phí trong quá trình triển khai và vận hành hệ thống.

Nói cách khác, lợi ích của RE thường là lợi ích dài hạn, trong khi chi phí là ngay trước mắt. Điều này phải được ghi nhớ khi thiết lập một dự án mới. Việc giảm chi phí trong ngắn hạn bằng cách chi ít hơn cho RE có một cái giá phải trả: nó làm tăng đáng kể rủi ro phải làm lại tốn kém trong các giai đoạn sau của dự án.

Giá trị của Kỹ nghệ Yêu cầu có thể được coi là giá trị tích lũy của các yêu cầu được đặc tả. Vì khách hàng thường trả tiền cho các hệ thống được triển khai, chứ không phải cho các yêu cầu cần thiết để làm điều đó, nên giá trị kinh tế của RE hầu hết là gián tiếp. Hiệu ứng này được củng cố bởi thực tế là lợi ích của các yêu cầu bắt nguồn từ việc giảm chi phí làm lại là một lợi ích gián tiếp: nó tiết kiệm chi phí trong quá trình triển khai và vận hành.

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í.

📌 GHI CHÚ Ô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 hóa giá trị của một yêu cầu, các Kỹ sư Yêu cầu phải tạo ra sự cân bằng hợp lý giữa lợi ích và chi phí của một yêu cầu. Ví dụ, việc khơi gợi và tài liệu hóa nhu cầu của một bên liên quan thành một yêu cầu giúp dễ dàng hơn việc truyền đạt nhu cầu này giữa tất cả các bên tham gia. Điều này làm tăng xác suất hệ thống được xây dựng cuối cùng sẽ thỏa mãn nhu cầu này, cấu thành nên một lợi ích. Yêu cầu càng ít mơ hồ và càng được phát biểu chính xác thì lợi ích của nó càng cao, bởi vì điều này làm giảm rủi ro phải làm lại tốn kém do diễn giải sai yêu cầu từ phía các kiến trúc sư hệ thống và đội ngũ phát triển. Mặt khác, việc tăng mức độ không mơ hồ và độ chính xác của một yêu cầu cũng làm tăng chi phí liên quan đến việc khơi gợi và tài liệu hóa yêu cầu đó.

Thực tế, khối lượng RE cần thiết để đạt được các yêu cầu với giá trị tối ưu phụ thuộc vào nhiều yếu tố được định hình bởi tình huống cụ thể mà các yêu cầu đang được tạo ra và sử dụng. Rõ ràng, rủi ro xây dựng một hệ thống cuối cùng không thỏa mãn mong muốn và nhu cầu của các bên liên quan — điều có thể dẫn đến thất bại hoặc làm lại tốn kém — là động lực thúc đẩy việc xác định khối lượng RE cần thiết. Trước hết, mức độ quan trọng của mỗi yêu cầu nên được đánh giá dựa trên tầm quan trọng của (các) bên liên quan đã phát biểu yêu cầu đó (xem Nguyên tắc 2) và tác động của việc bỏ sót yêu cầu (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 đây cần được xem xét:

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 độ nó đóng góp vào sự thành công của toàn bộ 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, cũng như giữa chính các bên liên quan với nhau
Sự tồn tại của các hệ thống tham chiếu (có thể đóng vai trò như một đặ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 một yêu cầu và lúc phát hiện ra lỗi)
Loại mối quan hệ khách hàng–nhà cung cấp
Sự tuân thủ quy định theo yêu cầu

📌 GHI CHÚ Ô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?”. “Length of feedback cycle” — chu trình phản hồi càng ngắn thì cần đặc tả ít hơn vì lỗi đượ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 cần đầu tư 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.

⚠️ BẪY ĐỀ THI

Rule of thumb thứ hai rất dễ đọc ngược. “Inversely proportional to the risk you are willing to take” = càng chấp nhận ít rủi ro → càng phải đầu tư nhiều RE. 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 của việc xây dựng một hệ thống là hệ thống đó, khi được sử dụng, sẽ giải quyết các vấn đề mà người dùng của nó cần giải quyết và thỏa mãn mong đợi của những người khác — ví dụ: những người đã đặt hàng và trả tiền cho hệ thống, hoặc những người chịu trách nhiệm về bảo mật trong tổ chức sử dụng hệ thống. Do đó, chúng ta phải tìm ra nhu cầu và mong đợi của những người có lợi ích liên quan đến hệ thống, tức là các bên liên quan (stakeholders) của hệ thống. Các mục tiêu cốt lõi của RE là hiểu được mong muốn và nhu cầu của các bên liên quan và giảm thiểu rủi ro chuyển giao một hệ thống không đáp ứng được những mong muốn và nhu cầu này; xem Định nghĩa 1.2 trong Phần 1.2.

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

⚠️ BẪY ĐỀ THI

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.

Đối với các vai trò bên liên quan có quá nhiều cá nhân hoặc khi không biết rõ các cá nhân đó, các personas (nhân vật hư cấu đại diện cho một nhóm người dùng có các đặc điểm tương tự) có thể được định nghĩa làm phương án thay thế. Đối với các hệ thống đã được sử dụng, những người dùng cung cấp phản hồi về hệ thống hoặc yêu cầu các tính năng mới cũng nên được coi là các bên liên quan.

Sẽ hợp lý khi phân loại các bên liên quan thành ba danh mục dựa trên mức độ ảnh hưởng của một bên liên quan đối với sự thành công của hệ thống:

Trọng yếu (Critical): việc không xem xét các bên liên quan này sẽ dẫn đến các vấn đề nghiêm trọng và có thể làm cho hệ thống thất bại hoặc trở nên vô dụng.
Chính (Major): việc không xem xét các bên liên quan này sẽ có tác động bất lợi đến sự thành công của hệ thống nhưng không làm nó thất bại.
Phụ (Minor): việc không xem xét các bên liên quan này sẽ không có ảnh hưởng hoặc chỉ có ảnh hưởng nhỏ đến sự thành công của hệ thống.

📌 GHI CHÚ ÔN THI

Ba mức phân loại (Critical / Major / Minor) được dùng cho 2 mục đích: (1) đánh giá 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 các yêu cầu của người dùng cuối và khách hàng là không đủ. Làm như vậy có nghĩa là chúng ta có thể bỏ lỡ các yêu cầu quan trọng từ các bên liên quan khác, điều này có thể dễ dàng dẫn đến các dự án phát triển bị thất bại hoặc vượt quá ngân sách và thời hạn của chúng.

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

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

⚠️ BẪY ĐỀ THI

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 ở mức độ thành thạo, không phải tần suất sử dụng.

Hệ quả là, chỉ thu thập các yêu cầu từ các bên liên quan thôi là chưa đủ. Điều quan trọng là phải xác định sự không nhất quán và các xung đột giữa các yêu cầu của các bên liên quan khác nhau và giải quyết chúng, cho dù đó là bằng cách tìm kiếm sự đồng thuận, bác bỏ (overruling) hoặc bằng cách đặc tả các biến thể hệ thống cho các bên liên quan thực tế 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, bao gồm cả RE, là một nỗ lực của nhiều người. Để làm cho nỗ lực đó thành công, những người liên quan cần có một sự hiểu biết chung về vấn đề và các yêu cầu phát sinh từ nó.

RE tạo ra, thúc đẩy và bảo đảm sự hiểu biết chung giữa và trong các bên tham gia: các bên liên quan, Kỹ sư Yêu cầu và các nhà phát triển. Chúng tôi phân biệt 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à đã được thỏa thuận. Đâ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 processes).
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 các yêu cầu không được đặc tả đầy đủ bằng văn bản, việc dựa vào hiểu biết chung ngầm định là chìa khóa. Điều này đặc biệt đúng trong mọi hình thức RE Agile.

🔑 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.

⚠️ BẪY ĐỀ THI

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. 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ả hiểu biết chung ngầm định lẫn tường minh đều có thể sai lầm (false), nghĩa là mọi người tin rằng họ có cùng hiểu biết chung về một vấn đề nhưng thực tế lại diễn giải vấn đề này theo những cách khác nhau. Do đó, chúng ta không bao giờ có thể mù quáng dựa dẫm vào hiểu biết chung. Thay vào đó, nhiệm vụ của RE là tạo ra và thúc đẩy hiểu biết chung đồng thời bảo đảm nó — nghĩa là đánh giá xem có thực sự tồn tại một sự hiểu biết chung đích thực hay không. Để giảm thiểu nỗ lực đạt được điều đó , điều sống còn là phải tập trung vào hiểu biết chung về những thứ có liên quan — nghĩa là, những khía cạnh nằm trong ranh giới bối cảnh của một hệ thống (tham chiếu Nguyên tắc 4).

Ngay cả với một sự hiểu biết chung hoàn hảo, các yêu cầu quan trọng vẫn có thể bị bỏ lỡ vì không ai nghĩ đến chúng. Hình 2.2 minh họa các tình huống khác nhau của hiểu biết chung với một ví dụ đơn giản về một cặp vợ chồng muốn lắp một chiếc xích đu trong vườn cho con cái của họ. Tờ giấy ghi chú ở giữa tượng trưng cho một 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 để đạt được hiểu biết chung bao gồm làm việc với các bảng thuật ngữ (Phần 3.5), tạo ra các nguyên mẫu (Phần 3.7), hoặc sử dụng một hệ thống hiện có làm điểm tham chiếu.

Phương tiện chính để đánh giá hiểu biết chung tường minh đích thực trong RE là thẩm định kỹ lưỡng tất cả các yêu cầu đã được đặc tả (tham chiếu Nguyên tắc 6 và Phần 4.4). Các thực hành để đánh giá hiểu biết chung ngầm định bao gồm việc cung cấp các ví dụ về kết quả mong đợi, xây dựng các 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 việc hiểu biết chung sai lầm là sử dụng một quy trình có các vòng lặp phản hồi ngắn (short feedback loops) (Chương 5).

Có những yếu tố cấu thành các tác nhân thúc đẩy (enablers) hoặc các trở ngại (obstacles) đối với sự 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 lĩnh vực
Sự cộng tác thành công trước đây
Sự tồn tại của các hệ thống tham chiếu được tất cả những người liên quan biết đến
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 bị chi phối bởi sự mất lòng tin lẫn nhau
Thuê ngoài
Các ràng buộc quy định
Các nhóm lớn và đa dạng
Tỷ lệ luân chuyển nhân sự cao giữa những người tham gia

📌 GHI CHÚ ÔN THI

Enablers và obstacles hay ra dạng chọn “cái nào là enabler / obstacle?”. Outsourcing và regulatory constraints là obstacle. Càng nhiều enabler và ít obstacle → càng có thể dựa vào implicit (cần đặc tả ít hơn).

⚠️ BẪY ĐỀ THI

Informed** (not blind!) mutual trust” là enabler — 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.

Xác suất và tác động của sự hiểu biết chung sai lầm càng thấp và tỷ lệ giữa các tác nhân thúc đẩy và trở ngại càng tốt, thì RE càng có thể dựa vào sự hiểu biết chung ngầm định. Ngược lại, càng ít tác nhân thúc đẩy và càng nhiều trở ngại đối với sự hiểu biết chung và rủi ro cũng như tác động của việc hiểu biết chung sai lầm đối với một yêu cầu càng cao, thì những yêu cầu đó càng 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

Các yêu cầu không bao giờ xuất hiện một cách cô lập. Chúng đề cập đến các hệ thống được nhúng trong một bối cảnh. Trong khi thuật ngữ bối cảnh nói chung biểu thị mạng lưới các suy nghĩ và ý nghĩa cần thiết để hiểu các hiện tượng hoặc phát ngôn, thì nó có một ý nghĩa đặc biệt trong RE.

🔑 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 của một hệ thống, 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. Có hai ranh giới phân định bối cảnh của một hệ thống: ranh giới hệ thống và ranh giới bối cảnh (xem Hình 2.3).

🔑 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 phân tách phần có liên quan của môi trường của một hệ thống sẽ được phát triển khỏi phần không liên quan — tức là, phần không ảnh hưởng đến hệ thống sẽ được phát triển và do đó không cần phải xem xét trong quá trình Kỹ nghệ Yêu cầu.

🔑 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ẽ hiện diện sau khi triển khai. Ranh giới hệ thống thường không rõ ràng ban đầu và nó 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 giữa một hệ thống và các yếu tố trong bối cảnh của nó là những nhiệm vụ RE đích thực.

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

🔑 THUẬT NGỮ

Định nghĩa 2.4. Scope “The range of things that can be shaped and designed when developing a system.”

⚠️ BẪY ĐỀ THI

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 có thể thiết kế lại → nằm trong scope**.

Tuy nhiên, đôi khi ranh giới hệ thống và phạm vi của nó không khớp nhau (xem Hình 2.3). Có thể có các thành phần nằm trong ranh giới hệ thống phải được tái sử dụng nguyên trạng (tức là chúng không thể được định hình hoặc thiết kế), điều này có nghĩa là chúng nằm ngoài phạm vi. Mặt khác, có thể có những thứ trong bối cảnh hệ thống có thể được thiết kế lại khi hệ thống được phát triển, điều này có nghĩa là chúng nằm trong phạm vi.

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

Do các 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 trong số các giao diện này nằm trong phạm vi (tức là có thể được định hình và thiết kế trong quá trình phát triển) và giao diện nào đã được cho sẵn và nằm ngoài phạm vi.

Chỉ xem xét các yêu cầu trong ranh giới hệ thống là không đủ.

Thứ nhất, khi phạm vi bao gồm các phần của bối cảnh hệ thống, như thể hiện trong Hình 2.3, những thay đổi bối cảnh trong phạm vi đó có thể tác động đến các yêu cầu của hệ thống. Ví dụ, khi một quy trình nghiệp vụ sẽ được tự động hóa một phần bởi một hệ thống, có thể sẽ hữu ích nếu điều chỉnh quy trình đó để đơn giản hóa việc tự động hóa nó. Rõ ràng, sự điều chỉnh như vậy sẽ tác động đến các yêu cầu của hệ thống.

Thứ hai, có thể có các hiện tượng trong thế giới thực trong bối cảnh hệ thống mà một hệ thống phải giám sát hoặc kiểm soát. Yêu cầu đối với các hiện tượng như vậy phải được phát biểu dưới dạng các yêu cầu miền (domain requirements) và phải được ánh xạ một cách thích hợp sang các yêu cầu hệ thống (system requirements). Ví dụ, hãy xem xét hệ thống phần mềm điều khiển hộp số tự động của một chiếc ô tô. Rõ ràng, bối cảnh của hệ thống này bao gồm chiếc ô tô được hệ thống điều khiển. Trong bất kỳ chiếc ô tô nào được trang bị hộp số tự động, có một yêu cầu là vị trí đỗ chỉ có thể được cài khi xe không di chuyển. Khi xem xét hệ thống điều khiển hộp số, yêu cầu này nằm trong bối cảnh hệ thống, tức là đây là một yêu cầu miền. Để thỏa mãn yêu cầu này, bộ điều khiển cần biết liệu xe có đang di chuyển hay không. Tuy nhiên, bộ điều khiển không thể cảm nhận hiện tượng này một cách trực tiếp. Do đó, hiện tượng thế giới thực “xe không di chuyển” phải được ánh xạ thành một hiện tượng mà hệ thống điều khiển có thể cảm nhận được — ví dụ, tín hiệu đầu vào từ một cảm biến tạo ra các xung khi bánh xe của ô tô đang quay. Yêu cầu miền liên quan đến việc cài vị trí đỗ sau đó được ánh xạ thành một yêu cầu hệ thống chẳng hạn như: “Hệ thống điều khiển hộp số sẽ chỉ cho phép cài vị trí đỗ nếu không nhận được xung nào từ các cảm biến quay của bánh xe.”

Thứ ba, có thể có các yêu cầu không thể được thỏa mãn bởi bất kỳ bản triển khai hệ thống nào trừ khi những yêu cầu miền và giả định miền (domain assumptions) nhất định trong bối cảnh của hệ thống được giữ vững. Giả định miền là các giả định về các hiện tượng trong thế giới thực trong bối cảnh của một hệ thống. Ví dụ, hãy xem xét một hệ thống kiểm soát không lưu (ATS). Yêu cầu “R1: ATS phải duy trì các vị trí chính xác cho tất cả các máy bay do hệ thống kiểm soát” là một yêu cầu hệ thống quan trọng. Tuy nhiên, yêu cầu này chỉ có thể được đáp ứng nếu radar trong bối cảnh của ATS thỏa mãn các yêu cầu về việc xác định chính xác tất cả các máy bay trong không phận do radar kiểm soát và xác định chính xác vị trí của chúng. Đến lượt nó, những yêu cầu này chỉ có thể được thỏa mãn nếu tất cả các máy bay được radar phát hiện phản hồi đúng các tín hiệu thẩm vấn do radar gửi.

Hơn nữa, yêu cầu R1 chỉ có thể được đáp ứng nếu một số giả định miền nhất định trong bối cảnh của ATS được giữ vững — ví dụ, radar không bị nhiễu bởi một kẻ tấn công ác ý và không có máy bay nào đang bay ở độ cao thấp hơn mức radar có thể phát hiện.

RE vượt ra ngoài việc xem xét các yêu cầu trong ranh giới hệ thống và xác định các giao diện bên ngoài tại ranh giới hệ thống. RE cũng phải xử lý các hiện tượng trong bối cảnh hệ thống.

Hệ quả là, RE cũng phải xem xét các vấn đề trong bối cảnh hệ thống:

Nếu những thay đổi trong bối cảnh có thể xảy ra, chúng tác động như thế nào đến các yêu cầu đối với hệ thống?
Những yêu cầu nào trong bối cảnh thế giới thực có liên quan đến hệ thống sẽ được phát triển?
Làm thế nào các yêu cầu trong thế giới thực như vậy có thể được ánh xạ một cách đầy đủ sang các yêu cầu đối với hệ thống?
Những giả định nào về bối cảnh phải được duy trì để hệ thống sẽ hoạt động bình thường và các yêu cầu trong thế giới thực sẽ được đáp ứng?

📌 GHI CHÚ ÔN THI

Domain assumptions phải được kiểm tra khi 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

Các vấn đề, giải pháp của chúng và các yêu cầu được đan xen chặt chẽ và không thể tránh khỏi. Mọi tình huống trong đó mọi người không hài lòng với cách họ đang làm việc đều có thể được coi là sự xuất hiện của một vấn đề. Để loại bỏ vấn đề đó, một hệ thống kỹ thuật–xã hội (socio-technical system) có thể được phát triển và triển khai. Các yêu cầu đối với hệ thống đó phải được nắm bắt để làm cho hệ thống trở thành một giải pháp hiệu quả cho vấn đề. Việc đặc tả các yêu cầu là vô nghĩa nếu không có vấn đề để giải quyết hoặc nếu không có giải pháp nào sẽ được phát triển. Tương tự như vậy, cũng không có ý nghĩa gì khi phát triển một giải pháp đang đi tìm một vấn đề để giải quyết hoặc tìm các yêu cầu để thỏa mãn.

Điều quan trọng cần lưu ý là các vấn đề, yêu cầu và giải pháp không nhất thiết phải xuất hiện theo trình tự này. Ví dụ, khi thiết kế một hệ thống mang tính đổi mới, các ý tưởng giải pháp tạo ra nhu cầu của người dùng, những nhu cầu này phải được xây dựng thành các yêu cầu và được thực hiện trong một giải pháp thực tế.

Các vấn đề, yêu cầu và giải pháp có thể được đan xen theo nhiều cách:

Đan xen phân cấp (Hierarchical intertwinement): khi phát triển các hệ thống lớn với hệ thống phân cấp nhiều mức gồm các hệ thống con và thành phần, các yêu cầu cấp cao dẫn đến các quyết định thiết kế cấp cao, điều này tiếp tục cung cấp thông tin cho các yêu cầu cấp thấp hơn dẫn đến các quyết định thiết kế cấp thấp hơn, v.v.
Tính khả thi về mặt kỹ thuật (Technical feasibility): việc đặc tả các yêu cầu không khả thi là sự lãng phí nỗ lực; tuy nhiên, việc đánh giá tính khả thi của một yêu cầu có thể chỉ thực hiện được khi khám phá các giải pháp kỹ thuật.
Thẩm định (Validation): các nguyên mẫu, vốn là một phương tiện mạnh mẽ để thẩm định các yêu cầu, cấu thành các giải pháp một phần của vấn đề.
Thiên kiến giải pháp (Solution bias): các bên liên quan khác nhau có thể hình dung các giải pháp khác nhau cho một vấn đề nhất định, với hậu quả là họ đặc tả các yêu cầu khác nhau, mâu thuẫn nhau cho vấn đề đó.

⚠️ BẪY ĐỀ THI

Solution bias” — stakeholder mô tả giải pháp thay vì vấn đề. RE Engineer phải nhận ra và đặt câu hỏi để khai thác vấn đề thực sự. Waterfall không hoạt động tốt vì giả định tách biệt hoàn toàn RE và design — mâu thuẫn với bản chất đan xen của bộ ba.

Sự đan xen của các vấn đề, yêu cầu và giải pháp cũng có hậu quả đối với quy trình phát triển cho một hệ thống:

Việc phân tách nghiêm ngặt RE khỏi các hoạt động thiết kế và triển khai hệ thống là hiếm khi khả thi. Do đó, các quy trình phát triển thác nước (waterfall) nghiêm ngặt không hoạt động tốt.
Tuy nhiên, các Kỹ sư Yêu cầu đặt mục tiêu tách biệt các vấn đề, yêu cầu và giải pháp khỏi nhau càng nhiều càng tốt khi suy nghĩ, giao tiếp và tài liệu hóa. Sự tách biệt các mối quan tâm này 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, các 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 một hệ thống được phát triển, hệ thống cuối cùng được triển khai phải thỏa mãn mong muốn và nhu cầu của các bên liên quan. Tuy nhiên, việc thực hiện kiểm tra này ở giai đoạn cuối của quá trình phát triển là rất rủi ro. Để kiểm soát rủi ro về việc các bên liên quan không hài lòng ngay từ đầu, việc thẩm định các yêu cầu phải bắt đầu trong quá trình RE (xem 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

🔑 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à quá trình xác nhận rằng các yêu cầu được tài liệu hóa phù hợp với nhu cầu của các bên liên quan; nói cách khác, xác nhận xem liệu các yêu cầu đúng (the right requirements) đã được đặc tả hay chưa.

Thẩm định là một hoạt động cốt lõi trong RE: không có sự đặc tả nào mà không có sự thẩm định.

Khi thẩm định các yêu cầu, chúng ta phải kiểm tra xem:

Sự thỏa thuận về các yêu cầu đã đạt được giữa các bên liên quan chưa (các xung đột đã được giải quyết, các ư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 đủ bởi các yêu cầu hay không.
Các giả định miền (xem Nguyên tắc 4 ở trên) có hợp lý hay không — nghĩa là, chúng ta có thể mong đợi rằng các giả định này có thể được đáp ứng khi hệ thống được triển khai và vận hành.

📌 GHI CHÚ Ô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 chờ đến cuối dự án.

⚠️ BẪY ĐỀ THI

Validation ≠ Verification. Validation = “Are we building the right system?”. Verification = “Are we building the system right**?”. 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 các 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 tuân theo sự tiến hóa. Các nhu cầu, hoạt động nghiệp vụ và các khả năng thay đổi liên tục. Như một hệ quả tự nhiên, các yêu cầu đối với các hệ thống được kỳ vọng sẽ thỏa mãn các nhu cầu, hỗ trợ hoạt động nghiệp vụ và sử dụng các khả năng kỹ thuật cũng sẽ thay đổi. Nếu không, các hệ thống đó và các yêu cầu của chúng sẽ mất dần giá trị và cuối cùng trở nên vô dụng.

Một yêu cầu có thể thay đổi trong khi các 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 triển khai, hoặc khi nó được triển khai và đang được sử dụng.

Có nhiều lý do dẫn đến yêu cầu thay đổi, ví dụ:

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

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

Hệ quả là, các Kỹ sư Yêu cầu phải theo đuổi hai mục tiêu dường như mâu thuẫn nhau:

Cho phép các yêu cầu thay đổi (Permit requirements to change): bởi vì cố gắng phớt lờ sự tiến hóa của các yêu cầu sẽ là vô ích.
Giữ cho các yêu cầu ổn định (Keep requirements stable): bởi vì nếu không có một số sự ổn định trong các yêu cầu, chi phí cho việc thay đổi có thể trở nên cao đến mức cấm kỵ. Hơn nữa, các đội ngũ phát triển không thể phát triển một cách có hệ thống nếu các yêu cầu thay đổi trên cơ sở hàng ngày.

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

📌 GHI CHÚ ÔN THI

Câu highlight này là câu 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).

⚠️ BẪY ĐỀ THI

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 cho các yêu cầu 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 đủ

Mặc dù RE quan tâm đến việc thỏa mãn mong muốn và nhu cầu của các bên liên quan, nhưng những Kỹ sư Yêu cầu chỉ đóng vai trò là chiếc máy ghi âm (voice recorder) của các bên liên quan, đặc tả chính xác những gì các bên liên quan nói với họ, là đang làm sai công việc. Cung cấp cho các bên liên quan chính xác những gì họ muốn có nghĩa là bỏ lỡ cơ hội làm những điều tốt hơn so với trước đây.

Ví dụ, hãy tưởng tượng kịch bản sau. Một công ty bảo hiểm muốn làm mới hệ thống báo cáo cho các đại lý của mình. Báo cáo được sử dụng thường xuyên nhất là một bảng có 18 cột, rộng khoảng gấp đôi màn hình khi được hiển thị trên máy tính xách tay của các đại lý. Do đó, việc xem báo cáo này đòi hỏi phải cuộn rất nhiều. Các bên liên quan vì vậy muốn có thể phóng to báo cáo, sử dụng các nút cộng và trừ trên màn hình. Trong tình huống này, những Kỹ sư Yêu cầu giỏi sẽ không chỉ ghi lại điều này như một yêu cầu. Thay vào đó, họ sẽ bắt đầu đặt câu hỏi. Hóa ra công ty sẽ thay thế máy tính xách tay của các đại lý bằng máy tính bảng. Do đó, việc triển khai các cử chỉ bằng hai ngón tay thay vì các nút được yêu cầu sẽ giúp việc phóng to dễ dàng hơn nhiều. Hơn nữa, hóa ra là ba cột trong báo cáo có thể được loại bỏ với một thay đổi nhỏ đối với các quy tắc báo cáo, điều mà công ty đồng ý thực hiện. Ngoài ra, chỉ có sáu cột của báo cáo là luôn cần thiết; các cột còn lại chỉ được sử dụng trong những trường hợp đặc biệt.

Có tính đến điều này, các Kỹ sư Yêu cầu sẽ đề xuất rằng các bên liên quan yêu cầu (1) báo cáo sẽ hiển thị thông tin giống như trong hệ thống hiện tại, trừ đi nội dung của ba cột đã bị loại bỏ; (2) khi báo cáo được mở, chỉ có sáu cột quan trọng được hiển thị ở toàn bộ chiều rộng, trong khi các cột khác được thu gọn lại thành chiều rộng tối thiểu; và (3) các đại lý có thể mở rộng một cột đã thu gọn bằng cách chạm vào tiêu đề của nó (và thu gọn lại bằng một lần chạm khác).

Bằng cách này, các đại lý sẽ nhận được một hệ thống không chỉ đơn thuần thêm vào một giải pháp tình thế để xem một báo cáo quá khổ. Thay vào đó, hệ thống sẽ giải quyết vấn đề của các đại lý với một tính năng mang tính đổi mới để lọc thông tin và cũng sẽ có một phương tiện phóng to trực quan.

Đây là cách mà sự đổi mới xuất hiện. Những Kỹ sư Yêu cầu giỏi luôn nhận thức về sự đổi mới: họ nỗ lực không chỉ để thỏa mãn các bên liên quan 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 cái bẫy của việc tin rằng họ biết mọi thứ tốt hơn các bên liên quan.

Những 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ọ.

📌 GHI CHÚ Ô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).

⚠️ BẪY ĐỀ THI

Innovation KHÔNG có nghĩa là RE Engineer á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 định hình các hệ thống đổi mới bằng cách cố gắng đạt được các tính năng mới thú vị và tính dễ sử dụng. Xa hơn thế, các Kỹ sư Yêu cầu cũng cần tìm kiếm bức tranh tổng thể, khám phá cùng với các bên liên quan xem liệu có bất kỳ cách thức đột phá nào để làm mọi việc hay không, dẫn đến sự đổi mới ở quy mô lớn. Phần 4.2 thảo luận về một số kỹ thuật để thúc đẩy sự đổ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à một nghệ thuật mà là một kỷ luật (discipline), điều này đòi hỏi RE phải được thực hiện một cách có hệ thống và có kỷ luật. Bất kể (các) quy trình nào được sử dụng để phát triển một hệ thống, chúng ta cần sử dụng các quy trình và thực hành RE phù hợp để khơi gợi, tài liệu hóa, thẩm định và quản lý các yêu cầu một cách có hệ thống. Ngay cả khi một hệ thống được phát triển theo kiểu ad-hoc (tùy cơ ứng biến), một cách tiếp cận có hệ thống và kỷ luật đối với RE (ví dụ, bằng cách thúc đẩy một cách có hệ thống sự hiểu biết chung, xem Nguyên tắc 3) sẽ cải thiện chất lượng của hệ thống tạo thành.

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

⚠️ BẪY ĐỀ THI

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.

Tuy nhiên, không có một quy trình RE vạn năng nào hay một bộ thực hành RE vạn năng nào hoạt động tốt trong mọi tình huống đã cho hoặc ít nhất là trong hầu hết các 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.

📌 GHI CHÚ ÔN THI

No one size fits all” là điểm mấu chốt — RE Engineer phải configure quy trình phù hợp với từng tình huống. 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à các Kỹ sư Yêu cầu:

Cấu hình một quy trình RE rất phù hợp với vấn đề đang giải quyết và khớp với quy trình được sử dụng để phát triển hệ thống (xem Chương 5).
Từ tập hợp các thực hành và sản phẩm công việc RE có sẵn, chọn 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 đã cho (xem Chương 3, 4 và 6).
Không luôn luôn sử dụng cùng một quy trình, các thực hành và sản phẩm công việc.
Không tái sử dụng các quy trình và thực hành từ công việc RE thành công trong quá khứ 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 các 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 các bên liên quan. Glinz và Fricker [GlFr2015] thảo luận về vai trò và tầm quan trọng của sự hiểu biết chung. Các bài báo của Jackson [Jack1995b] và Gunter cùng các cộng sự [GGJZ2000] là nền tảng cho vấn đề về các yêu cầu trong bối cảnh. Vai trò của bối cảnh trong RE cũng được Pohl [Pohl2010] thảo luận. Gause và Weinberg [GaWe1989] thảo luận về sự phụ thuộc lẫn nhau của các vấn đề và giải pháp. Swartout và Balzer [SwBa1982] là những người đầu tiên chỉ ra rằng việc tạo ra một bản đặc tả hoàn chỉnh trước khi bắt đầu triển khai là hiếm khi khả thi. Việc thẩm định được đề cập trong bất kỳ cuốn sách giáo khoa RE nào. Grünbacher và Seyff [GrSe2005] thảo luận về cách đạt được thỏa thuận bằng cách đàm phán về các yêu cầu. Kano cùng các cộng sự [KSTT1984] nằm trong số những người đầu tiên nhấn mạnh vai trò của sự đổi mới. Maalej, Nayebi, Johann, và Ruhe [MNJR2016] thảo luận về việc sử dụng phản hồi người dùng tường minh và ngầm định đối với RE. Maiden, Gitzikis, và Robertson [MaGR2004] thảo luận về cách sự sáng tạo có thể thúc đẩy sự đổi mới trong RE. Gorschek cùng các cộng sự [GFPK2010] phác thảo một 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 các bẫy trong đề 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 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 = RE Engineer á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
RE nhiều hơn khi rủi ro chấp nhận được cao hơn	Inversely proportional: chấp nhận ít rủi ro → RE nhiều hơn