Chương 1 - Giới thiệu và Tổng quan

Trong chương này, bạn sẽ tìm hiểu Kỹ nghệ Yêu cầu (Requirements Engineering — RE) thực chất là gì và những giá trị mà RE mang lại.

1.1 Kỹ nghệ Yêu cầu: Là gì

Kể từ thuở bình minh của lịch sử loài người, con người đã bắt đầu xây dựng các hệ thống kỹ thuật lẫn các hệ thống tổ chức để hỗ trợ họ hoàn thành các nhiệm vụ hoặc đạt được các mục tiêu.

Cùng với sự phát triển của ngành kỹ thuật, con người cũng bắt đầu xây dựng các hệ thống tự động hóa các nhiệm vụ của con người.

Bất cứ khi nào con người quyết định xây dựng một hệ thống để hỗ trợ hoặc tự động hóa các nhiệm vụ đó, họ phải hình dung được cần xây dựng cái gì. Điều này có nghĩa là họ phải tìm hiểu về mong muốn và nhu cầu của những cá nhân hoặc tổ chức sẽ sử dụng hệ thống, hưởng lợi từ nó, hoặc bị ảnh hưởng bởi nó. Nói cách khác, họ cần biết về các yêu cầu dành cho hệ thống đó. Yêu cầu hình thành nền tảng cho bất kỳ sự phát triển hoặc tiến hóa nào của các hệ thống hoặc các thành phần của chúng. Yêu cầu luôn luôn tồn tại, ngay cả khi chúng không được nắm bắt và tài liệu hóa một cách tường minh.

📌 GHI CHÚ ÔN THI

(EO 1.1.1):** Câu in đậm trên là luận điểm nền tảng — thi hay hỏi. Requirements tồn tại ngay cả khi không ai ghi lại. Đây là lý do cốt lõi của RE.

Thuật ngữ yêu cầu (requirement) biểu thị ba khái niệm [Glin2025]:

🔑 THUẬT NGỮ

— Định nghĩa 1.1. Yêu cầu (Requirement):**

Một nhu cầu được nhận thức bởi một bên liên quan.
Một khả năng hoặc thuộc tính mà một hệ thống phải có.
Một biểu diễn được tài liệu hóa về một nhu cầu, khả năng hoặc thuộc tính.

EN: 1. A need perceived by a stakeholder. 2. A capability or property that a system shall have. 3. A documented representation of a need, capability, or property.

Một tập hợp các yêu cầu được biểu diễn có hệ thống — thường là cho một hệ thống — thỏa mãn các tiêu chí nhất định được gọi là một đặc tả yêu cầu (requirements specification).

🔑 THUẬT NGỮ

— Requirements specification:** A systematically represented collection of requirements—typically for a system—that satisfies given criteria.

Chúng ta phân biệt giữa ba loại yêu cầu:

Yêu cầu chức năng (Functional requirements) quan tâm đến một kết quả hoặc hành vi phải được cung cấp bởi một chức năng của hệ thống. Điều này bao gồm cả các yêu cầu về dữ liệu hoặc sự tương tác của hệ thống với môi trường của nó.
Yêu cầu chất lượng (Quality requirements) liên quan đến các mối quan tâm về chất lượng không được bao phủ bởi các yêu cầu chức năng — ví dụ: hiệu năng, tính khả dụng, bảo mật, hoặc độ tin cậy.
Ràng buộc (Constraints) là những yêu cầu giới hạn không gian giải pháp vượt quá những gì cần thiết để đáp ứng các yêu cầu chức năng và yêu cầu chất lượng đã cho.

📌 GHI CHÚ ÔN THI

(EO 1.1.2): Ba loại trên gộp lại gọi là system requirements**. “Non-functional requirements” = QR + Constraints (thuật ngữ umbrella, IREB ưa dùng QR và Constraint riêng biệt).

⚠️ BẪY ĐỀ THI

— Phân loại FR/QR/Constraint:** Đề thi thường ra câu phân loại yêu cầu. Xem chi tiết bên dưới.

Lưu ý rằng việc xử lý các yêu cầu đối với các dự án hoặc quy trình phát triển nằm ngoài phạm vi của sổ tay này.

📌 GHI CHÚ ÔN THI

RE chỉ xử lý system requirements. Requirements của dự án (project requirements) hay quy trình (process requirements) không thuộc phạm vi CPRE FL.

Việc phân biệt giữa yêu cầu chức năng, yêu cầu chất lượng và ràng buộc không phải lúc nào cũng đơn giản. Một cách đã được kiểm chứng để phân biệt chúng là hỏi về mối quan tâm (concern) mà một yêu cầu nhắm tới:

Nếu mối quan tâm là về các kết quả, hành vi, hoặc tương tác cần thiết → yêu cầu chức năng
Nếu đó là một mối quan tâm về chất lượng chưa được bao phủ bởi yêu cầu chức năng → yêu cầu chất lượng
Nếu mối quan tâm là về việc hạn chế không gian giải pháp nhưng không phải FR hay QR → ràng buộc

Quy tắc phổ biến “Hệ thống sẽ làm gì → yêu cầu chức năng / hệ thống sẽ làm điều đó như thế nào → yêu cầu chất lượng” thường dẫn đến việc phân loại sai, đặc biệt khi các yêu cầu được đặc tả rất chi tiết hoặc khi các yêu cầu chất lượng là rất quan trọng.

⚠️ BẪY ĐỀ THI

(EO 1.1.2):** Quy tắc “what → FR / how → QR” là bẫy kinh điển. Ví dụ:

“Biểu mẫu nhập thông tin khách hàng phải chứa các trường cho họ và tên của khách hàng, chiếm tới 32 ký tự mỗi trường, hiển thị ít nhất 24 ký tự, căn lề trái, với phông chữ sanserif 12 pt.”

→ Đây là Functional Requirement dù chứa rất nhiều thông tin về “how”. Concern của nó là về hành vi/kết quả của hệ thống, không phải về chất lượng hay giới hạn giải pháp.

Ví dụ ngược: “Hệ thống phải xử lý được khối lượng dữ liệu từ máy gia tốc hạt” — dù hỏi “làm gì”, đây là Quality Requirement (liên quan đến tốc độ xử lý/khối lượng dữ liệu).

Khi con người thực hiện một cách tiếp cận có hệ thống và kỷ luật đối với việc đặc tả và quản lý các yêu cầu, chúng ta gọi đây là Kỹ nghệ Yêu cầu (Requirements Engineering — RE). Định nghĩa sau đây cũng phản ánh lý do tại sao chúng ta thực hiện RE.

🔑 THUẬT NGỮ

— Định nghĩa 1.2. Kỹ nghệ Yêu cầu (Requirements Engineering — RE):**

Cách tiếp cận có hệ thống và kỷ luật đối với việc đặc tả và quản lý các yêu cầu, với mục tiêu 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 bàn giao một hệ thống không đáp ứng được những mong muốn và nhu cầu đó.

EN: “The systematic and disciplined approach to the specification and management of requirements with the goal of understanding the stakeholders’ desires and needs and minimizing the risk of delivering a system that does not meet these desires and needs.”

📌 GHI CHÚ ÔN THI

(EO 1.1.1): Hai từ khóa quan trọng trong định nghĩa RE: systematic (có hệ thống) và disciplined (có kỷ luật). Hai mục tiêu: understanding stakeholders’ desires and needs + minimizing risk**.

Khái niệm về các bên liên quan [GlWi2007] là một nguyên tắc nền tảng của Kỹ nghệ Yêu cầu (xem Chương 2).

🔑 THUẬT NGỮ

— Định nghĩa 1.3. Bên liên quan (Stakeholder):**

Một người hoặc tổ chức có ảnh hưởng đến các yêu cầu của một hệ thống hoặc bị tác động bởi hệ thống đó.

EN: “A person or organization who influences a system’s requirements or who is impacted by that system.”

Lưu ý rằng sự ảnh hưởng cũng có thể là gián tiếp. Ví dụ, một số bên liên quan có thể phải tuân theo các chỉ thị được ban hành bởi người quản lý hoặc tổ chức của họ.

📌 GHI CHÚ ÔN THI

Stakeholder ảnh hưởng hoặc bị tác động — không cần cả hai. Ảnh hưởng gián tiếp vẫn đủ điều kiện là stakeholder.

Theo định nghĩa trong bảng thuật ngữ CPRE RE [Glin2025], chúng tôi sử dụng thuật ngữ hệ thống theo nghĩa rộng trong sổ tay này:

🔑 THUẬT NGỮ

— Định nghĩa 1.4. Hệ thống (System):**

Nói chung: một nguyên tắc để sắp xếp và cấu trúc.
Trong kỹ thuật: một tập hợp nhất quán các yếu tố có thể phân định — thông qua hành động phối hợp — đạt được một mục đích nhất định.

EN: “1. In general: a principle for ordering and structuring. 2. In engineering: a coherent, delimitable set of elements that—by coordinated action—achieve some purpose.”

Lưu ý rằng một hệ thống có thể bao gồm các hệ thống khác hoặc các thành phần với tư cách là các hệ thống con (subsystems). Các mục đích mà một hệ thống đạt được có thể được thực hiện bằng cách:

Triển khai hệ thống tại (các) nơi nó được sử dụng (deploy)
Bán/cung cấp hệ thống cho người dùng của nó như một sản phẩm
Có các nhà cung cấp chào bán các khả năng của hệ thống cho người dùng như là các dịch vụ

Do đó, chúng tôi sử dụng thuật ngữ hệ thống như một thuật ngữ bao trùm (umbrella term), bao gồm các sản phẩm, dịch vụ, ứng dụng hoặc thiết bị.

1.2 Kỹ nghệ Yêu cầu: Tại sao

Phát triển hệ thống (xây dựng hệ thống mới cũng như tiến hóa các hệ thống hiện có) là một nỗ lực tốn kém và cấu thành rủi ro cao cho tất cả những người tham gia. Đồng thời, các hệ thống có tính thực tiễn thường quá lớn để một cá nhân có thể nắm bắt toàn bộ bằng trí tuệ. Do đó, các kỹ sư đã phát triển nhiều nguyên tắc và thực hành để xử lý rủi ro khi phát triển hệ thống và để giảm gánh nặng tư duy. Kỹ nghệ Yêu cầu cung cấp các nguyên tắc và thực hành cho khía cạnh yêu cầu.

RE được thực hiện đúng đắn [Glin2016], [Glin2008] mang lại giá trị cho quá trình phát triển hệ thống:

RE giảm thiểu rủi ro thất bại hoặc các chỉnh sửa tốn kém trong các giai đoạn phát triển sau này. Việc phát hiện và sửa chữa sớm các yêu cầu sai hoặc bị thiếu rẻ hơn nhiều so với việc sửa lỗi và làm lại do các yêu cầu bị thiếu hoặc sai trong các giai đoạn phát triển sau hoặc thậm chí sau khi triển khai (deployment) hệ thống.
RE làm giảm bớt sự phức tạp về mặt trí tuệ liên quan đến việc hiểu vấn đề mà hệ thống được kỳ vọng sẽ giải quyết và cân nhắc kỹ lưỡng về các giải pháp tiềm năng.
RE cung cấp một nền tảng thích hợp để ước tính nỗ lực và chi phí phát triển.
RE là điều kiện tiên quyết để kiểm thử hệ thống một cách đúng đắn.

📌 GHI CHÚ ÔN THI

(EO 1.2.1):** 4 giá trị của RE cần thuộc theo thứ tự:

Giảm thiểu rủi ro thất bại / chỉnh sửa tốn kém
Giảm phức tạp trí tuệ (hiểu vấn đề + cân nhắc giải pháp)
Cơ sở ước tính nỗ lực và chi phí
Điều kiện tiên quyết để kiểm thử

Các triệu chứng điển hình của RE không đầy đủ là các yêu cầu bị thiếu, không rõ ràng hoặc sai, nguyên nhân thường do:

Các nhóm phát triển vội vàng lao thẳng vào việc xây dựng/cài đặt (implementing) hệ thống do áp lực về tiến độ
Các vấn đề về giao tiếp giữa các bên liên quan — cụ thể là giữa các bên liên quan và các nhà phát triển hệ thống, và giữa chính các bên liên quan với nhau
Giả định rằng các yêu cầu là tự hiển nhiên, điều này là sai trong hầu hết các trường hợp
Những người thực hiện các hoạt động RE mà không có đào tạo và kỹ năng đầy đủ

📌 GHI CHÚ ÔN THI

(EO 1.2.2):** 4 nguyên nhân của RE không đầy đủ (EO yêu cầu liệt kê — L1):

Vội vàng lao vào xây dựng/cài đặt hệ thống
Vấn đề giao tiếp giữa các bên
Giả định requirements là tự hiển nhiên
Thiếu đào tạo và kỹ năng RE

⚠️ BẪY ĐỀ THI

Phân biệt implement và deploy: implement = xây dựng/code; deploy = triển khai/đưa vào vận hành. Đây là hai giai đoạn khác nhau — nhầm hai khái niệm này có thể dẫn đến sai câu hỏi thi về SDLC.

1.3 Kỹ nghệ Yêu cầu: Ở đâu

Kỹ nghệ Yêu cầu có thể được áp dụng cho các yêu cầu của bất kỳ loại hệ thống nào. Tuy nhiên, trường hợp ứng dụng chủ đạo của RE hiện nay liên quan đến các hệ thống trong đó phần mềm đóng một vai trò chính. Các hệ thống như vậy bao gồm các thành phần phần mềm, các yếu tố vật lý (sản phẩm kỹ thuật, phần cứng điện toán, thiết bị, cảm biến, v.v.), và các yếu tố tổ chức (con người, vị trí, quy trình nghiệp vụ, các vấn đề pháp lý và tuân thủ, v.v.).

Các hệ thống chứa cả thành phần phần mềm lẫn vật lý được gọi là hệ thống vật lý-mạng (cyber-physical systems). Các hệ thống bao trùm các khía cạnh phần mềm, phần cứng, con người và tổ chức được gọi là hệ thống kỹ thuật-xã hội (socio-technical systems).

Tùy thuộc vào góc nhìn được áp dụng, yêu cầu xuất hiện dưới nhiều hình thức khác nhau:

Yêu cầu hệ thống (System requirements) mô tả cách thức một hệ thống sẽ hoạt động và vận hành — như được quan sát tại giao diện giữa hệ thống và môi trường của nó — để hệ thống thỏa mãn mong muốn và nhu cầu của các bên liên quan. Trong trường hợp các hệ thống thuần phần mềm, chúng ta nói về các yêu cầu phần mềm.

Yêu cầu của bên liên quan (Stakeholder requirements) thể hiện mong muốn và nhu cầu của các bên liên quan cần được thỏa mãn thông qua việc xây dựng một hệ thống, nhìn từ góc độ của các bên liên quan.

Yêu cầu người dùng (User requirements) là một tập hợp con của yêu cầu của bên liên quan. Chúng bao phủ mong muốn và nhu cầu của người dùng đối với một hệ thống.

Yêu cầu miền (Domain requirements) xác định các thuộc tính miền bắt buộc của một hệ thống kỹ thuật-xã hội hoặc vật lý-mạng.

Yêu cầu nghiệp vụ (Business requirements) tập trung vào các mục tiêu, mục đích và nhu cầu nghiệp vụ của một tổ chức cần được đáp ứng thông qua việc sử dụng một hệ thống (hoặc một tập hợp các hệ thống).

📌 GHI CHÚ ÔN THI

(EO 1.3.1):** 5 hình thức yêu cầu theo thứ tự:

Hình thức	Tiếng Anh	Góc nhìn
Yêu cầu hệ thống	System requirements	Giao diện hệ thống–môi trường
Yêu cầu bên liên quan	Stakeholder requirements	Góc nhìn stakeholder
Yêu cầu người dùng	User requirements	Tập con của stakeholder req
Yêu cầu miền	Domain requirements	Thuộc tính miền
Yêu cầu nghiệp vụ	Business requirements	Mục tiêu tổ chức

RE chủ yếu xử lý system requirements. Stakeholder req và user req là input; business req là context.

Các hình thức xuất hiện được trình bày ở trên phù hợp với những hình thức được định nghĩa trong tiêu chuẩn [ISO29148], ngoại trừ yêu cầu miền. Do tầm quan trọng của chúng, IREB coi yêu cầu miền là một hình thức riêng biệt. Vai trò và tầm quan trọng của yêu cầu miền được thảo luận trong Mục 2.2, Nguyên tắc 4.

1.4 Kỹ nghệ Yêu cầu: Bằng cách nào

Các nhiệm vụ chính trong RE là thu thập/khơi gợi (elicitation — Chương 4), tài liệu hóa (documentation — Chương 3), kiểm định (validation — Mục 4.4), và quản lý (management — Chương 6) các yêu cầu. Sự hỗ trợ của công cụ (Chương 7) có thể giúp thực hiện các nhiệm vụ này. Phân tích yêu cầu và giải quyết xung đột yêu cầu được coi là một phần của quá trình thu thập.

📌 GHI CHÚ ÔN THI

(EO 1.4.1): 4 nhiệm vụ chính của RE (cần thuộc đúng tên tiếng Anh): Elicitation → Documentation → Validation → Management**

Requirements analysis và conflict resolution là một phần của elicitation, không phải nhiệm vụ độc lập.

⚠️ BẪY ĐỀ THI

(EO 1.4.1): Câu hỏi thi thực tế: “Which of the following is NOT a core task of the Requirements Engineer?” → Đáp án hay là “Formalizing requirements”** (không phải core task) trong khi eliciting, documenting, validating đều là core tasks.

Tuy nhiên, không có một quy trình phổ quát nào mô tả khi nào và bằng cách nào RE cần được thực hiện khi phát triển một hệ thống. Đối với mỗi dự án phát triển hệ thống cần các hoạt động RE, một quy trình RE phù hợp phải được điều chỉnh (tailored) từ nhiều khả năng đa dạng. Các yếu tố ảnh hưởng đến sự điều chỉnh này bao gồm:

Quy trình phát triển hệ thống tổng thể — cụ thể là tuyến tính và định hướng kế hoạch (plan-driven) so với lặp lại và linh hoạt (iterative và agile)
Bối cảnh phát triển — cụ thể là mối quan hệ giữa nhà cung cấp (supplier), (các) khách hàng và người dùng của một hệ thống
Sự sẵn có và năng lực của các bên liên quan

Ngoài ra còn có sự phụ thuộc lẫn nhau giữa các sản phẩm công việc yêu cầu sẽ được tạo ra (xem Mục 3.1) và quy trình RE được lựa chọn. Thông tin chi tiết hơn được đưa ra trong Chương 5.

📌 GHI CHÚ ÔN THI

Không có “one size fits all” trong RE — đây cũng là nội dung Nguyên tắc 9 (Systematic and disciplined work). RE process phải được tailored cho từng tình huống cụ thể.

1.5 Vai trò và Nhiệm vụ của một Kỹ sư Yêu cầu

Trong thực tế, rất ít người có chức danh công việc là Kỹ sư Yêu cầu. Chúng tôi coi những người đang hành động trong vai trò Kỹ sư Yêu cầu khi họ:

Thu thập, tài liệu hóa, kiểm định, và/hoặc quản lý các yêu cầu như một phần nhiệm vụ của họ
Có kiến thức chuyên sâu về RE, điều này cho phép họ xác định các quy trình RE, lựa chọn các thực hành RE thích hợp, và áp dụng các thực hành này một cách đúng đắn
Có khả năng bắc cầu giữa vấn đề và các giải pháp tiềm năng

📌 GHI CHÚ ÔN THI

(EO 1.5.1): Requirements Engineer là vai trò** (role), không phải chức danh (job title). Nhiều vị trí có thể đóng vai trò này: business analysts, application specialists, product owners, systems engineers, developers.

Vai trò Kỹ sư Yêu cầu là một phần của nhiều chức năng công việc được định nghĩa bởi các tổ chức. Ví dụ, các nhà phân tích nghiệp vụ, chuyên gia ứng dụng, chủ sở hữu sản phẩm, kỹ sư hệ thống, và thậm chí cả các nhà phát triển đều có thể đóng vai trò là Kỹ sư Yêu cầu. Việc có kiến thức và kỹ năng RE cũng hữu ích cho nhiều chuyên gia khác — ví dụ, các nhà thiết kế, người kiểm thử, kiến trúc sư hệ thống, hoặc giám đốc công nghệ (CTO).

1.6 Những điều cần học về Kỹ nghệ Yêu cầu

Tập hợp kỹ năng mà một Kỹ sư Yêu cầu phải học bao gồm nhiều yếu tố khác nhau. Các yếu tố nền tảng được đề cập trong các chương tiếp theo của sổ tay này.

Ngoài các kỹ năng kỹ thuật và phân tích, một Kỹ sư Yêu cầu còn cần những kỹ năng được gọi là kỹ năng mềm (soft skills): khả năng lắng nghe, điều hành (moderate), đàm phán (negotiate) và hòa giải (mediate), cũng như sự đồng cảm (empathy) đối với các bên liên quan và sự cởi mở với nhu cầu và ý tưởng của người khác.

📌 GHI CHÚ ÔN THI

(EO 1.6.1):** Lộ trình học của RE Engineer theo Handbook:

Chương	Nội dung
Ch. 2	Nguyên tắc nền tảng (Principles)
Ch. 3	Sản phẩm công việc và tài liệu hóa (Work products & documentation)
Ch. 4	Thực hành làm rõ yêu cầu (Elaboration practices)
Ch. 5	Quy trình và cấu trúc công việc (Process & working structure)
Ch. 6	Thực hành quản lý (Management practices)
Ch. 7	Hỗ trợ công cụ (Tool support)

RE bị 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 của RE. Những nguyên tắc này được trình bày trong Chương 2.

Các yêu cầu có thể được tài liệu hóa dưới nhiều hình thức khác nhau. Nhiều sản phẩm công việc (work products) khác nhau có thể được tạo ra ở các mức độ hoàn thiện và chi tiết khác nhau, từ những sản phẩm khá phi chính thức và tạm thời đến các sản phẩm công việc rất chi tiết và có cấu trúc tuân thủ các quy tắc biểu diễn nghiêm ngặt. Điều quan trọng là phải lựa chọn các sản phẩm công việc và hình thức tài liệu hóa phù hợp với tình huống hiện tại (adequate for the situation at hand) và tạo ra các sản phẩm công việc đã chọn một cách đúng đắn. Các sản phẩm công việc và thực hành tài liệu hóa được trình bày trong Chương 3.

Các yêu cầu có thể được xây dựng chi tiết (elaborate — tức là, thu thập và kiểm định) với nhiều thực hành khác nhau. Một Kỹ sư Yêu cầu phải có khả năng lựa chọn các thực hành phù hợp nhất trong một tình huống nhất định và áp dụng các thực hành này một cách đúng đắn. Các thực hành xây dựng chi tiết yêu cầu được trình bày trong Chương 4.

Việc hiểu các quy trình và cấu trúc công việc khả thi cho phép các Kỹ sư Yêu cầu xác định một phương cách làm việc phù hợp với các nhu cầu cụ thể của tình huống phát triển hệ thống hiện tại. Quy trình và cấu trúc công việc được trình bày trong Chương 5.

Các yêu cầu hiện có có thể được quản lý với nhiều thực hành khác nhau. Các Kỹ sư Yêu cầu cần có khả năng hiểu thực hành quản lý yêu cầu nào hỗ trợ họ cho nhiệm vụ nào. Các thực hành quản lý được trình bày trong Chương 6.

Các công cụ giúp RE hiệu quả hơn. Các Kỹ sư Yêu cầu cần biết các công cụ RE có thể hỗ trợ họ như thế nào và làm thế nào để lựa chọn một công cụ phù hợp với tình huống của họ. Sự hỗ trợ của công cụ được thảo luận ngắn gọn trong Chương 7.

1.7 Đọc thêm

Các thuật ngữ RE được sử dụng trong sổ tay này được định nghĩa trong Bảng Thuật ngữ CPRE về Kỹ nghệ Yêu cầu [Glin2025]. Glinz và Wieringa [GlWi2007] giải thích khái niệm về các bên liên quan. Lawrence, Wiegers và Ebert [LaWE2001] thảo luận ngắn gọn về các rủi ro và cạm bẫy của RE.

Gause và Weinberg [GaWe1989] đã viết một trong những cuốn sách giáo khoa đầu tiên về RE, cuốn sách vẫn rất đáng tham khảo. Pohl [Pohl2010], Robertson và Robertson [RoRo2012] và Wiegers cùng Beatty [WiBe2013] là những cuốn sách giáo khoa phổ biến về RE. Các ghi chú bài giảng của Glinz [Glin2019] cung cấp một phần giới thiệu dựa trên slide về RE. Cuốn sách giáo khoa của van Lamsweerde [vLam2009] trình bày cách tiếp cận định hướng mục tiêu đối với RE. Jackson [Jack1995] đóng góp một tuyển tập bài luận sâu sắc về các yêu cầu phần mềm.

Ngoài ra cũng có các cuốn sách giáo khoa bằng các ngôn ngữ khác ngoài tiếng Anh. Ví dụ, Badreau và Boulanger [BaBo2014] đã viết một cuốn sách giáo khoa RE bằng tiếng Pháp. Các cuốn sách của Ebert [Eber2022], Pohl và Rupp [PoRu2021], và Rupp [Rupp2020] là những cuốn sách giáo khoa RE phổ biến được viết bằng tiếng Đức. [CLSZ2021] là một cuốn sách giáo khoa bằng tiếng Hà Lan.

[PoRu2021] và [CLSZ2021] tương thích với phiên bản 3.2 của CPRE Foundation Level Syllabus. Lưu ý rằng [PoRu2015] — cuốn sách giáo khoa chính thức cho IREB CPRE Foundation Level phiên bản 2.2 — không còn tương thích với phiên bản hiện hành của CPRE Foundation Level Syllabus.