Bỏ qua

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

CPRE Foundation Level Handbook v1.3.0 — Bản dịch tiếng Việt

Quy ước ghi chú:

  • 📌 ÔN THI — điểm quan trọng cần nhớ khi thi
  • ⚠️ TRAP — bẫy hay gặp trong đề thi
  • 🔑 THUẬT NGỮ — định nghĩa chính thức, cần thuộc cả nguyên văn tiếng Anh

EO chương này: EO 1.1.1 (L1) · EO 1.1.2 (L2) · EO 1.2.1 (L2) · EO 1.2.2 (L1) · EO 1.3.1 (L1) · EO 1.4.1 (L1) · EO 1.5.1 (L1) · EO 1.6.1 (L1)

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

Từ buổi bình minh của lịch sử loài người, con người đã xây dựng các hệ thống kỹ thuật lẫn các hệ thống tổ chức để hỗ trợ thực hiện nhiệm vụ hoặc đạt đượ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òn bắt đầu xây dựng các hệ thống tự động hóa công việc.

Mỗi khi quyết định xây dựng một hệ thống như vậy, người ta phải trả lời được câu hỏi: cần xây cái gì? Để trả lời, họ phải tìm hiểu mong muốn và nhu cầu của những người và tổ chức sẽ sử dụng, hưởng lợi từ, hoặc bị ảnh hưởng bởi hệ thống đó. Nói ngắn gọn: họ cần biết yêu cầu đặt ra cho hệ thống là gì.

Yêu cầu là nền tảng của mọi quá trình phát triển hay tiến hóa hệ thống. Yêu cầu luôn tồn tại, dù chúng có được ghi lại hay không.

📌 ÔN THI (EO 1.1.1): Câu in đậm là luận điểm nền tảng — thi hay hỏi. Requirements tồn tại ngay cả khi không ai tài liệu hóa chúng. Đâ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):

  1. Một nhu cầu được nhận thức bởi một bên liên quan.
  2. Một khả năng hoặc thuộc tính mà một hệ thống phải có.
  3. Một biểu diễn được tài liệu hóa về 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.

Khi một tập hợp yêu cầu được biểu diễn có hệ thống — thường là cho một hệ thống — và thỏa mãn các tiêu chí nhất định, tập hợp đó được gọi là đặ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.

Trong RE, ta phân biệt ba loại yêu cầu:

  • Yêu cầu chức năng (Functional requirements): đặt ra kết quả hoặc hành vi mà một chức năng của hệ thống phải cung cấp. Bao gồm cả yêu cầu về dữ liệu và tương tác của hệ thống với môi trường bên ngoài.
  • Yêu cầu chất lượng (Quality requirements): đề cập đến những 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 — ví dụ: hiệu năng, tính khả dụng, bảo mật, độ tin cậy.
  • Ràng buộc (Constraints): giới hạn không gian giải pháp vượt ra ngoài những gì cần thiết để đáp ứng yêu cầu chức năng và yêu cầu chất lượng.

📌 ÔN THI (EO 1.1.2): Ba loại trên gộp lại là system requirements. “Non-functional requirements” là thuật ngữ umbrella = QR + Constraints. IREB ưa dùng QR và Constraint riêng biệt để chính xác hơn.

⚠️ TRAP — Phân loại FR/QR/Constraint: Xem chi tiết ngay bên dưới.

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

📌 ÔN THI: RE chỉ xử lý system requirements. Project requirements và process requirements không thuộc phạm vi CPRE FL.

Việc phân loại 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 rõ ràng. Cách phân biệt đã được kiểm chứng là đặt câu hỏi về mối quan tâm (concern) mà yêu cầu đó nhắm đến:

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

Quy tắc phổ biến “Hệ thống làm gì → FR / hệ thống làm thế nào → QR” thường dẫn đến phân loại sai, đặc biệt khi yêu cầu được đặc tả rất chi tiết hoặc khi yêu cầu chất lượng giữ vai trò quan trọng.

⚠️ TRAP (EO 1.1.2): Quy tắc “what → FR / how → QR” là bẫy kinh điển.

“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, tối đa 32 ký tự mỗi trường, hiển thị ít nhất 24 ký tự, căn lề trái, phông sanserif 12pt.” → Functional Requirement — dù mô tả rất nhiều “how”, mối quan tâm cốt lõi vẫn là hành vi/kết quả của hệ thống.

“Hệ thống phải xử lý được toàn bộ khối lượng dữ liệu từ máy gia tốc hạt.” → Quality Requirement — dù hỏi “làm gì”, mối quan tâm thực sự là về tốc độ xử lý và khối lượng dữ liệu.

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

🔑 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ý yêu cầu, nhằm hiểu được mong muốn và nhu cầu của các bên liên quan, đồng thời 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.”

📌 ÔN THI (EO 1.1.1): Hai từ khóa 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 trong những nguyên tắc nền tảng của RE (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 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 ý: ảnh hưởng có thể là gián tiếp. Ví dụ, một bên liên quan có thể phải tuân theo chỉ thị của cấp trên hoặc tổ chức của họ.

📌 Ô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 bảng thuật ngữ CPRE RE [Glin2025], sổ tay này dùng thuật ngữ hệ thống theo nghĩa rộng:

🔑 THUẬT NGỮ — Định nghĩa 1.4. Hệ thống (System):

  1. Nói chung: một nguyên tắc để sắp xếp và cấu trúc.
  2. 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.”

Một hệ thống có thể bao gồm các hệ thống con (subsystems). Mục đích của hệ thống có thể được thực hiện qua:

  • Triển khai hệ thống tại nơi sử dụng (deploy)
  • Bán hoặc cung cấp hệ thống như một sản phẩm
  • Cung cấp năng lực của hệ thống cho người dùng dưới dạng dịch vụ

Vì vậy, hệ thống được dùng như một thuật ngữ bao trùm (umbrella term), bao gồm sản phẩm, dịch vụ, ứng dụng và thiết bị.

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

Phát triển hệ thống — dù là xây mới hay tiến hóa hệ thống hiện có — đều tốn kém và chứa đựng rủi ro cao. Trong khi đó, các hệ thống thực tiễn thường quá phức tạp để một cá nhân có thể nắm bắt toàn bộ bằng tư duy của mình. Do đó, các kỹ sư đã xây dựng nhiều nguyên tắc và thực hành để kiểm soát rủi ro và làm chủ sự phức tạp đó. RE cung cấp những nguyên tắc và thực hành đó từ góc độ yêu cầu.

RE được thực hiện đúng đắn [Glin2016], [Glin2008] mang lại những giá trị cụ thể:

  • Giảm thiểu rủi ro thất bại và chi phí sửa đổi muộn. Phát hiện và sửa yêu cầu sai hoặc thiếu từ sớm rẻ hơn nhiều so với việc sửa lỗi và làm lại ở giai đoạn phát triển sau, hoặc tệ hơn là sau khi đã triển khai (deployment) hệ thống.
  • Giảm gánh nặng tư duy. RE giúp làm rõ vấn đề mà hệ thống cần giải quyết và hỗ trợ việc cân nhắc kỹ lưỡng các giải pháp tiềm năng.
  • Cơ sở ước tính nỗ lực và chi phí phát triển.
  • Điều kiện tiên quyết để kiểm thử hệ thống một cách đúng đắn.

📌 ÔN THI (EO 1.2.1): 4 giá trị của RE — cần thuộc đúng thứ tự:

  1. Giảm thiểu rủi ro thất bại / sửa đổi tốn kém
  2. Giảm gánh nặng tư duy (hiểu vấn đề + cân nhắc giải pháp)
  3. Cơ sở ước tính nỗ lực và chi phí
  4. Điều kiện tiên quyết để kiểm thử

Khi RE được thực hiện kém, triệu chứng điển hình là yêu cầu bị thiếu, không rõ ràng hoặc sai. Nguyên nhân thường gặp:

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

📌 ÔN THI (EO 1.2.2): 4 nguyên nhân của RE kém (L1 — liệt kê):

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

⚠️ TRAP: implement ≠ deploy. Implement = xây dựng/lập trình hệ thống. Deploy = triển khai/đưa hệ thống vào vận hành thực tế. Đây là hai giai đoạn khác nhau trong vòng đời phát triển.

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

RE có thể áp dụng cho yêu cầu của bất kỳ loại hệ thống nào. Tuy nhiên, ứng dụng chủ đạo hiện nay là các hệ thống có phần mềm đóng vai trò trung tâm. Các hệ thống này thường gồm ba nhóm thành phần: phần mềm; yếu tố vật lý (phần cứng, thiết bị, cảm biến…); và yếu tố tổ chức (con người, quy trình nghiệp vụ, vấn đề pháp lý…).

Hai loại hệ thống đặc biệt:

  • Hệ thống vật lý-mạng (cyber-physical systems): kết hợp phần mềm và thành phần vật lý.
  • Hệ thống kỹ thuật-xã hội (socio-technical systems): bao trùm cả phần mềm, phần cứng, con người và tổ chức.

Tùy theo góc nhìn, yêu cầu xuất hiện dưới các hình thức sau:

Yêu cầu hệ thống (System requirements): mô tả cách hệ thống hoạt động và vận hành — quan sát từ giao diện giữa hệ thống và môi trường — để thỏa mãn mong muốn, nhu cầu của các bên liên quan. Với hệ thống thuần phần mềm, ta gọi là 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 hệ thống, nhìn từ góc độ của họ.

Yêu cầu người dùng (User requirements): tập con của stakeholder requirements, tập trung vào mong muốn và nhu cầu của người dù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 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 mục tiêu và nhu cầu nghiệp vụ của tổ chức cần đạt được thông qua hệ thống.

📌 ÔN THI (EO 1.3.1): 5 hình thức yêu cầu:

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/user req là input; business req là context.

Các hình thức trên tương ứng với định nghĩa trong tiêu chuẩn [ISO29148], ngoại trừ domain requirements — IREB tách riêng loại này do tầm quan trọng của nó. Chi tiết ở Mục 2.2, Nguyên tắc 4.

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

Bốn nhiệm vụ chính của RE là thu thập (elicitation — Ch.4), tài liệu hóa (documentation — Ch.3), kiểm định (validation — Mục 4.4) và quản lý (management — Ch.6) yêu cầu. Ngoài ra, công cụ (Ch.7) có thể hỗ trợ 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.

📌 ÔN THI (EO 1.4.1): 4 nhiệm vụ chính (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.

⚠️ TRAP (EO 1.4.1): Đề hỏi: “Which of the following is NOT a core task of the Requirements Engineer?” → Đáp án thường là “Formalizing requirements” — đây không phải core task theo IREB.

Không có một quy trình RE phổ quát nào phù hợp cho mọi dự án. Với mỗi dự án, quy trình RE phải được điều chỉnh phù hợp (tailored) từ nhiều lựa chọn khác nhau, dựa trên các yếu tố như:

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

Ngoài ra, các sản phẩm công việc cần tạo ra (Mục 3.1) và quy trình RE cũng ảnh hưởng lẫn nhau. Chi tiết ở Chương 5.

📌 ÔN THI: Không có “one size fits all” trong RE — liên kết trực tiếp với Nguyên tắc 9 (Systematic and disciplined work). RE process phải được tailored cho từng tình huống.

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

Trong thực tế, rất ít người có chức danh Kỹ sư Yêu cầu. Một người được coi là đang đóng 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ý yêu cầu như một phần công việc của mình
  • Có kiến thức chuyên sâu về RE để xác định quy trình, lựa chọn và áp dụng đúng các thực hành RE
  • Có khả năng bắc cầu giữa vấn đề và các giải pháp tiềm năng

📌 ÔN THI (EO 1.5.1): Requirements Engineer là vai trò (role), không phải chức danh (job title). Các vị trí có thể đảm nhận vai trò này: business analysts, application specialists, product owners, systems engineers, developers.

Vai trò này cũng hữu ích cho nhiều chuyên gia khác như nhà thiết kế, người kiểm thử, kiến trúc sư hệ thống hay CTO.

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

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

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

Dưới đây là lộ trình học theo Handbook:

📌 ÔN THI (EO 1.6.1):

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)

Ch. 3 — Tài liệu hóa: Yêu cầu có thể được ghi lại theo nhiều hình thức, từ phi chính thức đến rất có cấu trúc. Điều quan trọng là chọn hình thức phù hợp với tình huống và tạo ra chúng một cách đúng đắn.

Ch. 4 — Làm rõ yêu cầu (elaborate): Kỹ sư Yêu cầu phải chọn và áp dụng đúng các thực hành thu thập và kiểm định phù hợp với từng tình huống.

Ch. 5 — Quy trình và cấu trúc công việc: Hiểu được các quy trình khả thi giúp Kỹ sư Yêu cầu thiết kế cách làm việc phù hợp với dự án cụ thể.

Ch. 6 — Quản lý yêu cầu: Kỹ sư Yêu cầu cần biết thực hành quản lý nào phù hợp với nhiệm vụ nào.

Ch. 7 — Công cụ: Giúp RE hiệu quả hơn. Cần biết cách chọn công cụ phù hợp với tình huống.

1.7 Đọc thêm

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

Gause và Weinberg [GaWe1989] viết một trong những sách giáo khoa RE đầu tiên, vẫn đáng đọc đến nay. Pohl [Pohl2010], Robertson và Robertson [RoRo2012], Wiegers và Beatty [WiBe2013] là những sách giáo khoa phổ biến về RE. Glinz [Glin2019] cung cấp tài liệu giới thiệu dạng slide. Van Lamsweerde [vLam2009] trình bày cách tiếp cận định hướng mục tiêu. Jackson [Jack1995] đóng góp tuyển tập bài luận sâu sắc về yêu cầu phần mềm.

Về tài liệu không phải tiếng Anh: Badreau và Boulanger [BaBo2014] viết bằng tiếng Pháp. Ebert [Eber2022], Pohl và Rupp [PoRu2021], Rupp [Rupp2020] là các sách tiếng Đức phổ biến. [CLSZ2021] là sách tiếng Hà Lan.

[PoRu2021] và [CLSZ2021] tương thích với CPRE Foundation Level Syllabus v3.2. Lưu ý: [PoRu2015] — sách giáo khoa chính thức cho CPRE FL v2.2 — không còn tương thích với phiên bản Syllabus hiện hành.

Bảng tổng hợp các chỗ đã sửa (so với bản Gemini gốc)

# Vị trí Bản Gemini gốc Bản đã sửa Lý do
1 1.1 — câu đầu “hệ thống kỹ thuật và tổ chức” “các hệ thống kỹ thuật lẫn các hệ thống tổ chức” Hai loại riêng biệt, không phải một loại hai tính chất
2 1.1 — Def 1.1 [Glin2020] [Glin2025] v1.3 đổi tham chiếu Glossary
3 1.1 — Def 1.4 thiếu “coherent” bổ sung “nhất quán” “coherent” = tính chất toàn tập hợp, bị bỏ sót
4 1.2 — đầu mục “RE đầy đủ” “RE được thực hiện đúng đắn” “Adequate” = phù hợp về chất lượng, không phải số lượng
5 1.2 — bullet 2 “phản ánh về” “cân nhắc kỹ lưỡng” “reflecting on” = suy nghĩ sâu, không phải mirror
6 1.2 — symptom 1 “triển khai hệ thống” “xây dựng/cài đặt hệ thống” implement ≠ deploy
7 1.2 — symptom 4 “sự giáo dục” “đào tạo” “education” trong bối cảnh chuyên môn
8 1.3 — Stakeholder req xóa nhầm phục hồi “cần được thỏa mãn…” câu này có trong cả v1.2 lẫn v1.3
9 1.5 — bullet 3 “thu hẹp khoảng cách” “bắc cầu” bridge = kết nối, không chỉ thu hẹp
10 1.7 — toàn bộ danh sách v1.2 cập nhật v1.3 thêm [Glin2025], [Ebert2022], [PoRu2021], [Rupp2020], [CLSZ2021]