Bỏ qua

Chương 5 — Cấu trúc Quy trình và Làm việc

(Process and Working Structure)

Khi công việc cần được thực hiện có hệ thống, ta cần một quy trình để định hình cách làm việc và cách tạo ra các sản phẩm công việc.

Định nghĩa 5.1. Quy trình (Process): Một tập hợp các hoạt động có liên quan với nhau, được thực hiện theo một trình tự nhất định để xử lý thông tin hoặc vật liệu.

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN] Process (Định nghĩa 5.1): “A set of related activities performed in a certain sequence to process information or material.” Đây là định nghĩa chính thức của IREB. Lưu ý: “process information or material” — không chỉ thông tin mà còn cả vật liệu, phản ánh RE áp dụng cho cả hệ thống phần cứng/nhúng, không chỉ phần mềm thuần túy.

Một quy trình RE tổ chức cách thực hiện các nhiệm vụ RE — thông qua các thực hành phù hợp và tạo ra các sản phẩm công việc cần thiết. Không có quy trình RE nào phù hợp với mọi trường hợp (xem Mục 1.4). Do đó, Kỹ sư Yêu cầu phải cấu hình quy trình RE riêng cho từng tình huống.

Quy trình RE xác định luồng thông tin và mô hình giao tiếp giữa các bên tham gia — khách hàng, người dùng, Kỹ sư Yêu cầu, nhà phát triển, kiểm thử viên. Quy trình cũng chỉ định các sản phẩm công việc RE cần tạo ra hoặc sử dụng. Một quy trình RE tốt là khung để Kỹ sư Yêu cầu thực hiện bốn nhiệm vụ cốt lõi: khơi gợi, tài liệu hóa, thẩm định và quản lý yêu cầu.

📌 [GHI CHÚ ÔN THI] Câu này định nghĩa hai vai trò then chốt của quy trình RE: (1) định hình luồng thông tin + mô hình giao tiếp, (2) xác định sản phẩm công việc. Đây là nội dung hay xuất hiện trong câu hỏi dạng “RE process provides the framework for…” — đáp án luôn bao gồm cả 4 động từ: elicit, document, validate, manage.

Trong chương này, bạn sẽ tìm hiểu về các yếu tố ảnh hưởng đến quy trình RE và cách cấu hình một quy trình phù hợp từ một tập hợp các khía cạnh (facets) quy trình.

5.1 Các Yếu Tố Ảnh Hưởng

(Influencing Factors)

Có nhiều yếu tố ảnh hưởng cần xem xét khi cấu hình một quy trình RE. Trước khi bắt đầu cấu hình, các yếu tố này cần được điều tra và phân tích.

Phân tích các yếu tố này có hai tác dụng. Một mặt, nó cho biết nên cấu hình quy trình RE theo hướng nào — chẳng hạn, khi bên liên quan chưa rõ yêu cầu của mình, cần chọn quy trình RE hỗ trợ việc khám phá yêu cầu. Mặt khác, các yếu tố ảnh hưởng còn giới hạn phạm vi cấu hình khả dĩ — chẳng hạn, nếu bên liên quan chỉ có mặt ở giai đoạn đầu dự án, không thể chọn quy trình đòi hỏi phản hồi liên tục từ họ. Dưới đây là các yếu tố quan trọng cần xem xét.

📌 [GHI CHÚ ÔN THI — THUỘC LÒNG] 9 yếu tố ảnh hưởng trong mục 5.1 — ghi nhớ theo cụm:

  1. Overall process fit — Phải khớp với quy trình phát triển tổng thể
  2. Development context — 4 khía cạnh con: (a) quan hệ khách hàng-nhà cung cấp-người dùng, (b) loại hình phát triển, (c) hợp đồng, (d) sự tin tưởng
  3. Stakeholder availability & capability — Sẵn có + năng lực
  4. Shared understanding — Hiểu biết chung ↑ → RE process nhẹ hơn
  5. Complexity & criticality — Phức tạp/trọng yếu cao → spec chi tiết + formal models
  6. Constraints — Ràng buộc tường minh từ khách hàng hoặc cơ quan quản lý
  7. Time & budget — Ngân sách eo → iterative, ưu tiên yêu cầu quan trọng nhất
  8. Volatility of requirements — Thay đổi nhiều → iterative + change-friendly
  9. Experience of Requirements Engineers — Ít kinh nghiệm → quy trình đơn giản hơn

⚠️ Đề thi thường cho một tình huống và hỏi yếu tố nào đang tác động, hoặc nên chọn quy trình nào dựa trên yếu tố đó. Development context là yếu tố có nhiều sub-factor nhất, dễ bị hỏi chi tiết nhất.

Sự phù hợp với quy trình tổng thể (Overall process fit)

Khi định nghĩa hoặc cấu hình quy trình RE, điều kiện tiên quyết là phải nắm rõ quy trình phát triển tổng thể — định nghĩa một quy trình RE không khớp với quy trình tổng thể là vô nghĩa. Quy trình tổng thể có thể yêu cầu những sản phẩm công việc nhất định mà quy trình RE phải tạo ra. Ngoài ra, thuật ngữ trong quy trình RE phải căn chỉnh thống nhất với thuật ngữ của quy trình tổng thể — đặc biệt là tên gọi các sản phẩm công việc. Sự thống nhất này giúp tránh nhầm lẫn, đồng thời giúp việc triển khai quy trình và đào tạo nhân sự dễ dàng hơn. Ví dụ: nếu hệ thống được phát triển theo quy trình tuyến tính có kế hoạch sẵn (plan-driven), và quy trình đó yêu cầu phải có một đặc tả yêu cầu hệ thống toàn diện cùng bảng thuật ngữ hệ thống vào cuối giai đoạn yêu cầu — thì quy trình RE phải phù hợp với giai đoạn đó và tạo ra đúng hai sản phẩm công việc trên.

📌 [GHI CHÚ ÔN THI] Overall process fit nhấn mạnh hai điều phải căn chỉnh giữa RE process và overall process: (1) work products — RE phải tạo ra đúng sản phẩm mà quy trình tổng thể cần, (2) thuật ngữ — đặc biệt tên của các work products phải thống nhất để tránh nhầm lẫn. Đây là lý do thuật ngữ (terminology/glossary) được nhấn mạnh trong IREB.

Bối cảnh phát triển (Development context)

Bối cảnh phát triển cũng ảnh hưởng đến quy trình RE. Cần xem xét bốn khía cạnh: quan hệ khách hàng–nhà cung cấp–người dùng, loại hình phát triển, hợp đồng, và sự tin tưởng giữa các bên. Khi phân tích bối cảnh phát triển, cần trả lời các câu hỏi sau:

  • Quan hệ khách hàng–nhà cung cấp–người dùng: Có một khách hàng đặt hàng và trả tiền, và một nhà cung cấp phát triển hệ thống không? Hai bên thuộc cùng hay khác tổ chức? Nếu cùng tổ chức, ai đóng vai khách hàng, ai đóng vai nhà cung cấp? Người dùng hệ thống là ai — họ có thuộc tổ chức khách hàng không? Nếu không, họ dùng hệ thống để tương tác với khách hàng (ví dụ: thương mại điện tử), hay mua hệ thống như một sản phẩm/dịch vụ từ khách hàng (ví dụ: ứng dụng di động)?
  • Loại hình phát triển: Khuôn khổ tổ chức cho việc phát triển hệ thống là gì? Các loại hình điển hình bao gồm:
  • Nhà cung cấp đặc tả và phát triển hệ thống cho một khách hàng cụ thể, người sẽ sử dụng hệ thống đó.
  • Tổ chức phát triển hệ thống với ý định bán nó như một sản phẩm hoặc dịch vụ cho nhiều khách hàng trong một phân khúc thị trường nhất định.
  • Nhà cung cấp cấu hình hệ thống cho khách hàng từ một tập hợp các thành phần có sẵn.
  • Nhà cung cấp nâng cấp và phát triển tiếp một sản phẩm hiện có.
  • Hợp đồng: Có hợp đồng hoặc thỏa thuận nào chính thức xác định sản phẩm bàn giao, chi phí, thời hạn và trách nhiệm không? Hợp đồng có thể là hợp đồng giá cố định (chức năng, thời hạn, chi phí đều cố định), hoặc chỉ xác định khuôn khổ tài chính trong khi chức năng được xác định theo từng vòng lặp.
  • Sự tin tưởng: Các bên tham gia có tin tưởng nhau không? Ví dụ, nếu khách hàng và nhà cung cấp không tin tưởng nhau, các yêu cầu phải được đặc tả chi tiết hơn so với mức cần thiết trong một mối quan hệ dựa trên sự tin tưởng.

📌 [GHI CHÚ ÔN THI] Quan hệ giữa trust và mức độ chi tiết của spec là một logic hay bị hỏi dạng suy luận: tin tưởng thấp → cần spec chi tiết hơn (để làm cơ sở pháp lý rõ ràng). Ngược lại, tin tưởng cao → có thể dùng quy trình nhẹ hơn. Đây cũng là lý do outsourcing (thuê ngoài) với bên thứ ba thường cần quy trình prescriptive hơn (xem 5.2.4).

Tính sẵn có và năng lực của các bên liên quan (Stakeholder availability and capability)

Sự sẵn có của bên liên quan giới hạn các lựa chọn cấu hình quy trình RE. Ví dụ: nếu bên liên quan cốt lõi chỉ có mặt ngắn ngủi ở đầu dự án, không thể chọn quy trình đòi hỏi tương tác liên tục với họ.

Năng lực của bên liên quan cũng ảnh hưởng đến quy trình: bên liên quan càng kém khả năng diễn đạt nhu cầu, và càng ít hiểu rõ nhu cầu thực sự của mình, thì quy trình RE càng phải nghiêng về phía khám phá yêu cầu.

📌 [GHI CHÚ ÔN THI] Hai tác động khác nhau cần phân biệt:

  • Availability thấp (stakeholder chỉ có mặt đầu dự án) → ràng buộc cấu hình: không thể chọn quy trình cần feedback liên tục
  • Capability thấp (stakeholder không biết rõ nhu cầu) → định hướng chọn: phải chọn quy trình explorative để khám phá yêu cầu

Hai yếu tố này tác động theo chiều khác nhau — availability ràng buộc, capability định hướng. Đề thi hay ghép hai tình huống này vào một scenario để kiểm tra khả năng phân biệt.

Hiểu biết chung (Shared understanding)

Chỉ cần ít công sức RE khi có mức độ hiểu biết chung cao (xem Chương 2, Nguyên tắc 3) giữa các bên liên quan, Kỹ sư Yêu cầu, nhà thiết kế và nhà phát triển về bài toán và các yêu cầu. Do đó, hiểu biết chung càng tốt thì quy trình RE có thể càng gọn nhẹ (lightweight) [GIFr2015].

📌 [GHI CHÚ ÔN THI] Shared understanding là Nguyên tắc 3 trong EU2. Mối quan hệ trực tiếp: shared understanding cao → RE process gọn nhẹ hơn. Đây là logic thường xuất hiện trong câu hỏi tình huống: “Trong trường hợp nào có thể dùng quy trình RE nhẹ nhất?” → Khi shared understanding cao và criticality thấp (xem thêm 5.2.5).

Độ phức tạp và tính trọng yếu (Complexity and criticality)

Mức độ chi tiết cần thiết khi đặc tả yêu cầu phụ thuộc mạnh vào độ phức tạp và tính trọng yếu của hệ thống. Khi hệ thống phức tạp và/hoặc trọng yếu về an toàn hay bảo mật, quy trình RE phải đáp ứng hai yêu cầu: (1) đặc tả chi tiết các yêu cầu trọng yếu bằng mô hình hình thức hoặc bán hình thức, và (2) thẩm định chặt chẽ — ví dụ bằng cách xác minh các mô hình hành vi hoặc xây dựng nguyên mẫu.

📌 [GHI CHÚ ÔN THI] Công thức cần nhớ:

  • Complexity/criticality cao → formal/semi-formal models + rigorous validation (verification of behavioral models, prototyping)
  • Complexity/criticality thấp + shared understanding cao → RE process lightweight

“Safety-critical” và “security-critical” là hai ví dụ cụ thể về high-criticality mà IREB hay dùng trong đề. Khi thấy từ khóa này → biết ngay phải chọn quy trình RE có formal models và validation mạnh.

Ràng buộc (Constraints)

Tất cả các yếu tố ảnh hưởng đều giới hạn không gian cấu hình quy trình RE. Riêng khi nói đến “ràng buộc”, ý là những ràng buộc được áp đặt tường minh — ví dụ, từ phía khách hàng hoặc cơ quan quản lý. Các ràng buộc này có thể bắt buộc phải tạo ra một số sản phẩm công việc cụ thể và tuân theo một quy trình nhất định để tạo ra chúng. Đôi khi khách hàng hoặc cơ quan quản lý còn yêu cầu quy trình RE phải tuân thủ một tiêu chuẩn cụ thể.

📌 [GHI CHÚ ÔN THI] Tiêu chuẩn hay được nhắc đến trong IREB: ISO/IEC/IEEE 29148 — tiêu chuẩn quốc tế cho RE và system/software requirements. Khi đề thi đề cập “regulatory constraints” hoặc “compliance with a standard” → đây là dấu hiệu có thể phải tạo quy trình RE từ đầu (xem thêm mục 5.3.2). Constraint là yếu tố ràng buộc cứng nhất trong 9 yếu tố ảnh hưởng — không thể bỏ qua hay thương lượng.

Thời gian và ngân sách có sẵn (Time and budget available)

Khi tiến độ và ngân sách eo hẹp, nguồn lực dành cho RE phải được dùng thật khôn ngoan — thường nghĩa là chọn quy trình gọn nhẹ. Quy trình lặp lại giúp ưu tiên và triển khai những yêu cầu quan trọng nhất trong phạm vi đã định.

📌 [GHI CHÚ ÔN THI] Logic thi: ngân sách eo + tiến độ chặt → iterative (không phải linear). Lý do: iterative cho phép ưu tiên yêu cầu quan trọng nhất trước, deliver từng phần trong budget. Linear đòi hỏi toàn bộ spec trước → lãng phí nguồn lực nếu sau đó phải thay đổi. Đây là điểm phản trực giác: nhiều người nghĩ “ngân sách eo thì phải làm nhanh → linear” nhưng IREB nói ngược lại.

Tính biến động của yêu cầu (Volatility of requirements)

Nếu nhiều yêu cầu có khả năng thay đổi, nên chọn một quy trình RE lặp lại và thân thiện với sự thay đổi (change-friendly).

📌 [GHI CHÚ ÔN THI] Volatility cao → iterative + change-friendly. Đây là một trong những tiêu chí chọn iterative đơn giản và trực tiếp nhất. Trong đề thi, từ khóa nhận biết: “requirements are likely to change”, “requirements are not stable”, “evolving requirements” → chọn iterative.

Kinh nghiệm của Kỹ sư Yêu cầu (Experience of Requirements Engineers)

Quy trình RE phải khớp với năng lực và kinh nghiệm của Kỹ sư Yêu cầu. Nếu không, phải phân bổ thêm thời gian và ngân sách để đào tạo và huấn luyện. Tốt hơn là chọn quy trình đơn giản mà đội ngũ có thể thực thi đúng, thay vì quy trình tinh vi làm họ quá tải.

📌 [GHI CHÚ ÔN THI] Nguyên tắc: fit the process to the people, not the other way around. Một quy trình tốt trên lý thuyết nhưng đội ngũ không thực thi được = vô dụng. Đây cũng là lý do trong thực tế nhiều team dùng quy trình đơn giản hơn mức cần thiết — IREB chấp nhận điều này là hợp lý.

5.2 Các Khía Cạnh của Quy Trình Kỹ Nghệ Yêu Cầu

(Requirements Engineering Process Facets)

Định nghĩa quy trình RE từ đầu cho mỗi dự án là lãng phí. Khi các yếu tố ảnh hưởng cho phép, nên cấu hình quy trình từ các thành phần có sẵn. Để hỗ trợ việc này, chúng tôi mô tả ba khía cạnh (facets), mỗi khía cạnh có hai thể hiện (instances) và kèm tiêu chí lựa chọn [Glin2019]. Mục 5.3 sẽ dùng các khía cạnh này để cấu hình quy trình RE cụ thể. Hình 5.1 tóm tắt tổng quan.

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN]

  • Facet (khía cạnh): Một chiều cấu hình của quy trình RE, mỗi facet có hai thể hiện (instances) đối lập nhau. Ba facets tạo thành một không gian cấu hình 3 chiều.
  • Instance (thể hiện): Một trong hai lựa chọn cụ thể của một facet — ví dụ: Linear và Iterative là hai instances của Time Facet.
  • Cụm từ chính thức trong đề thi: “three facets, each with two instances” — thuộc cụm này để nhận ra ngay câu hỏi về cấu trúc của 5.2.

[Hình 5.1 — Các khía cạnh của quy trình RE]

Ba khía cạnh tạo thành một không gian cấu hình ba chiều. Mỗi thể hiện đi kèm các tiêu chí lựa chọn bắt nguồn từ phân tích các yếu tố ảnh hưởng trong Mục 5.1. Lưu ý: không cần đáp ứng tất cả tiêu chí mới được chọn một thể hiện.

📌 [GHI CHÚ ÔN THI — TRỌNG TÂM] Ba khía cạnh cần thuộc lòng (đề thi hỏi thẳng — câu P3504):

  • Khía cạnh Thời gian: Linear vs Iterative
  • Khía cạnh Mục đích: Prescriptive vs Explorative
  • Khía cạnh Mục tiêu: Customer-Specific vs Market-Oriented

Lưu ý quan trọng: “Không phải tất cả tiêu chí đều cần được đáp ứng” — đây là chi tiết hay bị bỏ sót khi trả lời câu hỏi về cách chọn facet instance.

5.2.1 Khía Cạnh Thời Gian: Tuyến Tính so với Lặp Lại

(Time Facet: Linear versus Iterative)

Khía cạnh thời gian xem xét cách tổ chức các hoạt động RE trên trục thời gian. Ta phân biệt hai dạng: tuyến tính (linear) và lặp lại (iterative).

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN]

  • Linear RE process: “requirements are specified up front in a single phase of the process” — đặc tả toàn bộ yêu cầu từ đầu trong một giai đoạn duy nhất.
  • Iterative RE process: “requirements are specified incrementally, starting from general goals and some initial requirements, adding or adjusting requirements in each iteration” — đặc tả yêu cầu theo từng bước tăng dần, bắt đầu từ mục tiêu chung.
  • Heavyweight process (quy trình nặng): gắn với Linear — đòi hỏi spec toàn diện từ đầu.
  • Lightweight process (quy trình nhẹ): gắn với Iterative — nhờ vòng phản hồi ngắn, có thể gọn nhẹ hơn.

Trong một quy trình RE tuyến tính, toàn bộ yêu cầu được đặc tả từ đầu (up front) trong một giai đoạn duy nhất. Mục tiêu là tạo ra một đặc tả toàn diện, không cần hoặc chỉ cần điều chỉnh tối thiểu trong suốt quá trình thiết kế và triển khai. Vì yêu cầu về sự toàn diện đó đòi hỏi một quy trình đầy đủ tương ứng, hầu hết quy trình RE tuyến tính là các quy trình nặng (heavyweight).

📌 [GHI CHÚ ÔN THI] Từ khóa đặc trưng của Linear RE: “up front”, “single phase”, “comprehensive specification”, “heavyweight”. Khi đề thi dùng các từ này → Linear. Ngược lại với Iterative: “incrementally”, “interleaved”, “short feedback loops”, “lightweight”.

Tiêu chí để chọn quy trình RE tuyến tính:

  • Quy trình phát triển hệ thống có kế hoạch sẵn (plan-driven) và phần lớn là tuyến tính.
  • Các bên liên quan có mặt, biết rõ yêu cầu của mình và có thể đặc tả chúng ngay từ đầu.
  • Một đặc tả yêu cầu toàn diện được yêu cầu như là cơ sở hợp đồng để thuê ngoài hoặc đấu thầu thiết kế và triển khai hệ thống.
  • Các cơ quan quản lý yêu cầu một đặc tả yêu cầu toàn diện, được phát hành chính thức ở giai đoạn đầu của quá trình phát triển.

⚠️ [GHI CHÚ ÔN THI] Linear thường đi kèm prescriptive (xem 5.2.4). Nhưng không phải lúc nào cũng vậy — ví dụ Contractual RE có thể đôi khi là iterative (đề thi syllabus ghi rõ “Typically Linear, Sometimes Iterative”). Đừng nhớ cứng là Linear = Contractual = luôn luôn tuyến tính.

Trong một quy trình RE lặp lại, yêu cầu được đặc tả theo từng bước tăng dần (incrementally) — bắt đầu từ các mục tiêu chung và một số yêu cầu ban đầu, sau đó bổ sung hoặc điều chỉnh qua từng vòng lặp. Quy trình RE đan xen với thiết kế và triển khai hệ thống. Nhờ vòng phản hồi ngắn và khả năng bổ sung những điều bị bỏ sót ở các vòng sau, quy trình RE lặp lại có thể là các quy trình gọn nhẹ (lightweight).

Tiêu chí để chọn quy trình RE lặp lại:

  • Quy trình phát triển hệ thống là lặp lại và linh hoạt (agile).
  • Nhiều yêu cầu không được biết trước mà sẽ xuất hiện và phát triển trong quá trình phát triển hệ thống.
  • Các bên liên quan có mặt sao cho có thể thiết lập các vòng phản hồi ngắn nhằm giảm thiểu rủi ro phát triển sai hệ thống.
  • Thời gian phát triển cho phép thực hiện nhiều hơn một hoặc hai vòng lặp.
  • Khả năng thay đổi yêu cầu dễ dàng là điều quan trọng.

📌 [GHI CHÚ ÔN THI] Tiêu chí hay bị bỏ sót: “thời gian phát triển cho phép nhiều hơn 1-2 vòng lặp” — nếu chỉ có thời gian cho 1 vòng duy nhất thì iterative mất đi lợi thế. Tiêu chí này nhắc nhở rằng iterative không phải lúc nào cũng nhanh hơn linear, nó chỉ hiệu quả khi có đủ vòng lặp để tích lũy phản hồi và điều chỉnh.

5.2.2 Khía Cạnh Mục Đích: Định Sẵn so với Khám Phá

(Purpose Facet: Prescriptive versus Explorative)

Khía cạnh mục đích xem xét vai trò của các yêu cầu trong quá trình phát triển hệ thống. Ta phân biệt hai dạng: định sẵn (prescriptive) và khám phá (explorative).

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN]

  • Prescriptive RE process: “the requirements specification constitutes a contract: all requirements are binding and have to be implemented” — đặc tả yêu cầu cấu thành hợp đồng, tất cả yêu cầu có tính ràng buộc và phải được triển khai.
  • Explorative RE process: “only the goals are known up front, while the specific requirements have to be elicited” — chỉ có mục tiêu được biết trước, yêu cầu cụ thể phải được khơi gợi.
  • Từ khóa phân biệt: Prescriptive = “binding”, “contract”, “implemented”. Explorative = “goals”, “elicited”, “explored”.

Trong một quy trình RE định sẵn, đặc tả yêu cầu có giá trị như một hợp đồng: tất cả yêu cầu đều ràng buộc và phải được triển khai. Mục tiêu là tạo ra đặc tả có thể được triển khai với ít hoặc không cần thêm tương tác giữa bên liên quan và nhà phát triển.

Tiêu chí để chọn quy trình RE định sẵn:

  • Khách hàng yêu cầu một hợp đồng cố định cho việc phát triển hệ thống, thường với chức năng, phạm vi, giá cả và thời hạn cố định.
  • Chức năng và phạm vi được ưu tiên hơn chi phí và thời hạn.
  • Việc phát triển hệ thống đã đặc tả có thể được đấu thầu hoặc thuê ngoài.

⚠️ [TRAP — DỄ NHẦM] Tiêu chí thứ hai hay bị nhầm ngược chiều:

  • Prescriptive: Chức năng/phạm vi được ưu tiên hơn chi phí/thời hạn — tức là “phải làm đúng mọi yêu cầu dù tốn bao nhiêu”
  • Explorative: Chi phí/thời hạn được ưu tiên hơn chức năng/phạm vi — tức là “làm trong ngân sách/tiến độ, bỏ bớt tính năng nếu cần”

Nhiều người đọc vội sẽ nghĩ ngược lại. Nhớ: Prescriptive = scope cố định, Explorative = time/budget cố định. Đây là logic giống Fixed-Price contract vs Time-and-Material contract.

Trong một quy trình RE khám phá, chỉ có mục tiêu được biết trước — yêu cầu cụ thể phải được khơi gợi dần. Bản chất của quy trình này là yêu cầu thường không rõ từ đầu mà cần được khám phá qua quá trình.

Tiêu chí để chọn quy trình RE khám phá:

  • Ban đầu, các bên liên quan chỉ có ý niệm mơ hồ về yêu cầu của họ.
  • Các bên liên quan tham gia chặt chẽ và cung cấp phản hồi liên tục.
  • Thời hạn và chi phí được ưu tiên hơn chức năng và phạm vi.
  • Khách hàng hài lòng với một hợp đồng khung về mục tiêu, nguồn lực và mức giá phải trả cho một khoảng thời gian hoặc số lượng vòng lặp nhất định.
  • Không rõ trước yêu cầu nào thực sự sẽ được triển khai và theo thứ tự nào.

📌 [GHI CHÚ ÔN THI] Phân biệt nhanh Prescriptive vs Explorative:

  • Prescriptive: Yêu cầu = hợp đồng → tất cả phải được triển khai → biết rõ từ đầu
  • Explorative: Chỉ biết mục tiêu → yêu cầu cụ thể phải khám phá → linh hoạt về phạm vi

Dấu hiệu nhận biết explorative trong đề thi: “stakeholders have only a vague idea”, “deadlines/cost take precedence over functionality”.

5.2.3 Khía Cạnh Mục Tiêu: Dành Riêng cho Khách Hàng so với Định Hướng Thị Trường

(Target Facet: Customer-Specific versus Market-Oriented)

Khía cạnh mục tiêu xem xét loại hình phát triển đang được nhắm đến. Ở mức cơ bản, ta phân biệt giữa quy trình RE dành riêng cho khách hàng (customer-specific) và định hướng thị trường (market-oriented).

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN]

  • Customer-specific RE process: “the system is ordered by a customer and developed by a supplier for that customer” — hệ thống được đặt hàng bởi một khách hàng và phát triển bởi nhà cung cấp cho khách hàng đó.
  • Market-oriented RE process: “the system is developed as a product or service for the market, targeting specific user segments” — hệ thống được phát triển như sản phẩm/dịch vụ cho thị trường, nhắm đến các phân khúc người dùng.
  • Lưu ý quan trọng: “the supplier and the customer may belong to the same organization” — customer-specific KHÔNG có nghĩa là hai tổ chức khác nhau.

Trong quy trình RE dành riêng cho khách hàng, một khách hàng đặt hàng hệ thống và nhà cung cấp phát triển hệ thống đó cho họ. Lưu ý: khách hàng và nhà cung cấp có thể cùng một tổ chức. Quy trình RE phản ánh quan hệ khách hàng–nhà cung cấp này.

Tiêu chí để chọn quy trình RE dành riêng cho khách hàng:

  • Hệ thống sẽ chủ yếu được sử dụng bởi tổ chức đã đặt hàng và trả tiền cho việc phát triển nó.
  • Các bên liên quan quan trọng chủ yếu gắn với tổ chức của khách hàng.
  • Có thể xác định được các cá nhân cụ thể cho từng vai trò bên liên quan.
  • Khách hàng muốn một đặc tả yêu cầu có thể đóng vai trò là hợp đồng.

Trong quy trình RE định hướng thị trường, hệ thống được phát triển như sản phẩm hoặc dịch vụ cho thị trường, nhắm đến các phân khúc người dùng cụ thể. Chính tổ chức phát triển là bên dẫn dắt quy trình RE.

Tiêu chí để chọn quy trình RE định hướng thị trường:

  • Tổ chức phát triển hoặc một trong những khách hàng của họ có ý định bán hệ thống như một sản phẩm hoặc dịch vụ trên một phân khúc thị trường nào đó.
  • Người dùng tiềm năng không thể được xác định từng cá nhân.
  • Kỹ sư Yêu cầu phải thiết kế các yêu cầu phù hợp với nhu cầu được hình dung của người dùng mục tiêu.
  • Chủ sở hữu sản phẩm (product owners), nhân viên tiếp thị, nhà thiết kế kỹ thuật số và kiến trúc sư hệ thống là các bên liên quan chính.

📌 [GHI CHÚ ÔN THI] Phân biệt nhanh Customer-Specific vs Market-Oriented:

  • Customer-Specific: Hệ thống cho 1 khách hàng xác định → biết rõ từng stakeholder → có thể lập hợp đồng dựa trên spec
  • Market-Oriented: Hệ thống cho thị trường → không xác định được từng user → RE process do tổ chức phát triển tự dẫn dắt

Dấu hiệu nhận biết trong đề thi: “prospective users are not individually identifiable” → Market-Oriented. “the customer wants a spec that can serve as a contract” → Customer-Specific.

5.2.4 Gợi Ý và Lưu Ý

(Hints and Caveats)

Cần lưu ý rằng các tiêu chí trên là phỏng đoán kinh nghiệm (heuristics) — không phải quy tắc cứng nhắc luôn luôn áp dụng. Ví dụ: thuê ngoài phát triển hệ thống thường phù hợp hơn với quy trình RE định sẵn, vì hợp đồng thuê ngoài thường dựa trên một đặc tả yêu cầu toàn diện. Tuy nhiên, hoàn toàn có thể đàm phán hợp đồng thuê ngoài dựa trên quy trình RE khám phá.

📌 [GHI CHÚ ÔN THI] Đây là đoạn IREB nhắc nhở tránh áp dụng máy móc. Ví dụ outsourcing là ví dụ hay bị hỏi: “Dự án outsource nên dùng quy trình gì?” — câu trả lời chuẩn là prescriptive (vì hợp đồng cần spec toàn diện), nhưng nếu đề cho thêm điều kiện như “hai bên đồng ý framework contract” thì explorative vẫn khả thi. Đừng chọn đáp án cứng nhắc khi đề thi thêm điều kiện.

Một số lựa chọn facet có điều kiện tiên quyết, hoặc kéo theo hệ quả cần lưu ý. Dưới đây là các ví dụ:

  • Các quy trình RE tuyến tính chỉ hoạt động nếu đã có sẵn một quy trình tinh vi để xử lý việc thay đổi yêu cầu.

🔑 [THUẬT NGỮ — SONG NGỮ] Điều kiện tiên quyết này thường được diễn đạt trong đề thi là:

  • Tiếng Anh: “Linear RE processes only work if a sophisticated process for changing requirements is in place.”
  • Tiếng Việt: Quy trình RE tuyến tính chỉ khả thi nếu đã có sẵn một quy trình quản lý thay đổi yêu cầu hoàn chỉnh.

⚠️ Đây là điều kiện tiên quyết (prerequisite), không phải hệ quả — tức là phải có sẵn trước khi chọn linear, không phải xây dựng sau.

  • Quy trình RE tuyến tính kéo theo các vòng phản hồi dài: từ khi viết một yêu cầu đến khi quan sát được tác động của nó trong hệ thống đã triển khai có thể mất nhiều tháng hoặc nhiều năm. Để giảm rủi ro phát triển sai hệ thống, cần thẩm định yêu cầu thật chuyên sâu khi dùng quy trình tuyến tính.

⚠️ [TRAP — DỄ NHẦM] Đây là hệ quả bắt buộc của Linear, không phải tùy chọn. Vòng phản hồi dài → rủi ro phát triển sai hệ thống cao → bắt buộc phải validation kỹ ngay từ đầu (không thể sửa dễ dàng sau). Đây là điểm đối nghịch trực tiếp với Iterative: vòng phản hồi ngắn → phát hiện lỗi sớm → rủi ro thấp hơn. Câu hỏi thi dạng: “Why is thorough validation especially important in a linear RE process?” — đáp án chính xác là vì long feedback loops khiến lỗi phát hiện muộn, sửa tốn kém.

  • Trong quy trình định hướng thị trường, phản hồi từ người dùng tiềm năng là phương tiện duy nhất để thẩm định xem sản phẩm có thực sự đáp ứng nhu cầu của phân khúc người dùng mục tiêu hay không.

⚠️ [TRAP — DỄ NHẦM] Từ khóa: “the only means of validation” — phản hồi người dùng tiềm năng là phương tiện duy nhất để validate trong market-oriented. Không có cách nào khác vì không xác định được từng người dùng cụ thể từ trước. Đây là điểm hay bị bỏ sót khi trả lời câu hỏi về validation trong market-oriented context.

  • Trong bối cảnh linh hoạt (agile), một quy trình RE lặp lại và khám phá phù hợp nhất. Các vòng lặp có độ dài cố định (thường là 2–6 tuần). Chủ sở hữu sản phẩm đóng vai trò cốt lõi trong quy trình RE, điều phối các bên liên quan, tổ chức các sản phẩm công việc RE và truyền đạt các yêu cầu đến đội ngũ phát triển.

🔑 [THUẬT NGỮ — SONG NGỮ] Vai trò của Product Owner trong agile RE:

  • Tiếng Anh: “The product owner plays a core role in the RE process, coordinating stakeholders, organizing RE work products and communicating requirements to the development team.”
  • Tiếng Việt: Chủ sở hữu sản phẩm điều phối bên liên quan, tổ chức sản phẩm công việc RE, truyền đạt yêu cầu đến nhóm phát triển.
  • Thời lượng sprint cố định: 2–6 tuần — thuộc con số này vì hay bị hỏi trong câu về agile RE context.

Ba khía cạnh trên không hoàn toàn độc lập: lựa chọn cho một khía cạnh có thể ảnh hưởng đến lựa chọn ở các khía cạnh khác. Ví dụ:

  • Tuyến tính và định sẵn thường đi cùng nhau — khi Kỹ sư Yêu cầu chọn quy trình tuyến tính, họ thường chọn quy trình vừa tuyến tính vừa định sẵn.
  • Các quy trình RE khám phá thường cũng là các quy trình lặp lại (và ngược lại).
  • Một quy trình RE định hướng thị trường không kết hợp tốt với một quy trình tuyến tính và định sẵn.

⚠️ [TRAP — DỄ NHẦM] Đây là sự không tương thích quan trọng nhất cần thuộc: Market-Oriented ≠ Linear + Prescriptive. Lý do: market-oriented cần phản hồi liên tục từ người dùng để thẩm định sản phẩm (người dùng không được xác định cụ thể từ đầu), trong khi linear+prescriptive yêu cầu spec cố định từ đầu. Hai hướng mâu thuẫn nhau. Đề thi hay cho tình huống một công ty SaaS hỏi nên dùng quy trình nào → không bao giờ chọn linear+prescriptive cho market-oriented.

📌 [GHI CHÚ ÔN THI — CỰC QUAN TRỌNG] Ba cặp kết hợp thường gặp trong đề thi:

Tên quy trình Time Purpose Target
Participatory Iterative Explorative Customer-Specific
Contractual Linear (đôi khi Iterative) Prescriptive Customer-Specific
Product-Oriented Iterative Explorative Market-Oriented

Câu A3505 trong đề thi mẫu hỏi cái nào KHÔNG phải là tổ hợp được công nhận → đáp án là “Human-oriented RE process” vì đây là tổ hợp không tồn tại trong IREB.

5.2.5 Các Cân Nhắc Bổ Sung

(Further Considerations)

Mức độ cần thiết lập và tuân thủ quy trình RE, cũng như khối lượng sản phẩm công việc cần tạo ra, phụ thuộc vào hai yếu tố: mức độ hiểu biết chung và tính trọng yếu của hệ thống.

Hiểu biết chung càng tốt và tính trọng yếu càng thấp, quy trình RE có thể càng đơn giản và gọn nhẹ.

Khi thời gian và ngân sách RE eo hẹp, cần dùng nguồn lực một cách khôn ngoan. Chọn quy trình lặp lại và khám phá sẽ giúp ích — quy trình sẽ tập trung vào những yêu cầu trọng yếu nhất cho sự thành công của hệ thống.

Cuối cùng, quy trình RE phải phù hợp với kinh nghiệm của Kỹ sư Yêu cầu. Kinh nghiệm càng thấp, quy trình càng phải đơn giản — định nghĩa một quy trình tinh vi mà đội ngũ không thể thực thi đúng là vô nghĩa.

📌 [GHI CHÚ ÔN THI — CÔNG THỨC TỔNG HỢP 5.2.5] Mục này tóm gọn 3 trục ảnh hưởng đến độ nặng/nhẹ của RE process:

Yếu tố Hướng → Nhẹ Hướng → Nặng
Shared understanding Cao Thấp
Criticality Thấp Cao
Time & budget Eo hẹp → iterative/explorative, focus trọng yếu Dồi dào → comprehensive
RE experience Thấp → đơn giản Cao → phức tạp được phép

Quy trình RE nhẹ nhất có thể = shared understanding cao + criticality thấp + RE team có kinh nghiệm + không có ràng buộc quy định.

5.3 Cấu Hình Quy Trình Kỹ Nghệ Yêu Cầu

(Configuring a Requirements Engineering Process)

Kỹ sư Yêu cầu hoặc người chịu trách nhiệm RE phải chọn quy trình RE phù hợp cho từng dự án cụ thể. Khuyến nghị: phân tích các yếu tố ảnh hưởng (Mục 5.1) trước, rồi chọn tổ hợp facets phù hợp từ Mục 5.2.

5.3.1 Các Tổ Hợp Khía Cạnh Điển Hình

(Typical Combinations of Facets)

Trong thực tế, ba tổ hợp facets (hoặc biến thể của chúng) xuất hiện thường xuyên nhất [Glin2019]. Mỗi tổ hợp dưới đây được mô tả theo: trường hợp ứng dụng chính, sản phẩm công việc điển hình, luồng thông tin điển hình, và một ví dụ minh họa. Hình 5.2 cho thấy ba cấu hình trong không gian của ba khía cạnh.

[Hình 5.2 — Ba cấu hình quy trình RE điển hình và mối quan hệ của chúng với ba khía cạnh]

🔑 [THUẬT NGỮ — THUỘC NGUYÊN VĂN] Ba tên quy trình chính thức cần thuộc cả tiếng Anh lẫn tiếng Việt:

Tiếng Anh (chính thức) Tiếng Việt Facet combination
Participatory RE Process Quy trình RE Tham Gia Iterative + Explorative + Customer-Specific
Contractual RE Process Quy trình RE Theo Hợp Đồng (Typically) Linear + Prescriptive + Customer-Specific
Product-Oriented RE Process Quy trình RE Định Hướng Sản Phẩm Iterative + Explorative + Market-Oriented

⚠️ Đề thi dùng tên tiếng Anh — phải nhận ra ngay khi thấy. Không có tên nào là “Agile RE Process”, “Waterfall RE Process” hay “Human-oriented RE Process” — những tên này không tồn tại trong IREB.

Quy Trình RE Tham Gia: Lặp Lại & Khám Phá & Dành Riêng cho Khách Hàng

(Participatory RE Process: Iterative & Explorative & Customer-Specific)

Quy trình RE tham gia thường được chọn trong bối cảnh agile khi có một khách hàng đặt hàng và một đội phát triển xây dựng hệ thống. Trọng tâm là khám phá yêu cầu qua nhiều vòng lặp, với sự cộng tác chặt chẽ giữa bên liên quan phía khách hàng, Kỹ sư Yêu cầu và đội phát triển.
Trường hợp ứng dụng chính Nhà cung cấp và khách hàng cộng tác chặt chẽ; các bên liên quan tham gia mạnh mẽ vào cả quy trình RE lẫn quy trình phát triển.
Sản phẩm công việc điển hình Product backlog với các user story và/hoặc mô tả tác vụ, tầm nhìn (vision), nguyên mẫu (prototypes).
Luồng thông tin điển hình Tương tác liên tục giữa các bên liên quan, chủ sở hữu sản phẩm, Kỹ sư Yêu cầu và nhà phát triển.

Ví dụ: Bộ phận kinh doanh của một công ty bảo hiểm — chuyên bán bảo hiểm doanh nghiệp cho các SME — có ý tưởng về sản phẩm mới: bảo hiểm thiệt hại do tấn công mạng. Họ hợp đồng với bộ phận CNTT nội bộ để phát triển một ứng dụng xử lý sản phẩm bảo hiểm mới trong hệ thống bán hàng hiện tại, đồng thời điều chỉnh hệ thống quản lý hợp đồng tương ứng. Ngoài một số yêu cầu ban đầu, bộ phận kinh doanh chưa có ý tưởng rõ về sản phẩm sẽ trông như thế nào và cần hỗ trợ CNTT ra sao. Bộ phận CNTT đã áp dụng agile cho tất cả các dự án từ vài năm trước.

Đây là tình huống phù hợp với quy trình RE tham gia — khớp với quy trình agile tổng thể của bộ phận CNTT.

Bên liên quan từ bộ phận kinh doanh và Kỹ sư Yêu cầu từ bộ phận CNTT có thể cùng khơi gợi yêu cầu. Vì quy trình lặp lại, đội phát triển có thể tạo ra một sản phẩm thị trường tối thiểu (MMP) để ban quản lý kinh doanh quyết định có đưa sản phẩm vào danh mục hay không. Quan hệ khách hàng–nhà cung cấp rõ ràng giữa hai bộ phận nên quy trình RE dành riêng cho khách hàng (customer-specific) là phù hợp.

⚠️ [TRAP — THUẬT NGỮ] Bản gốc handbook dùng từ không chính thức “customer-oriented” tại đây (không phải “customer-specific”). Thuật ngữ chính thức IREB là customer-specific.

🔑 [THUẬT NGỮ — SONG NGỮ]

  • Customer-specific (dành riêng cho khách hàng): hệ thống phát triển cho một khách hàng xác định, nhà cung cấp và khách hàng có thể cùng tổ chức.
  • “customer-oriented” là cách nói thông thường — không dùng trong bài thi. Khi thấy câu hỏi, luôn chọn đáp án có từ “customer-specific”.

Quy Trình RE Theo Hợp Đồng: Thường Tuyến Tính & Định Sẵn & Dành Riêng cho Khách Hàng

(Contractual RE Process: Typically Linear & Prescriptive & Customer-Specific)

⚠️ [GHI CHÚ ÔN THI] Syllabus IREB ghi đầy đủ tên là “Typically Linear (Sometimes Iterative) & Prescriptive & Customer-Specific”. Handbook bỏ phần “(Sometimes Iterative)” trong heading nhưng body text nói rõ: tùy chất lượng spec hiện có và sự sẵn có của stakeholder, có thể chọn linear hoặc iterative. Đừng nhớ cứng Contractual = tuyến tính tuyệt đối.

Quy trình RE theo hợp đồng thường được chọn khi việc phát triển hệ thống được đấu thầu hoặc thuê ngoài, với hợp đồng dựa trên một đặc tả yêu cầu toàn diện. Đây cũng là lựa chọn phù hợp cho các dự án lớn áp dụng quy trình waterfall.
Trường hợp ứng dụng chính Đặc tả yêu cầu là cơ sở hợp đồng cho việc phát triển hệ thống bởi những người không tham gia vào quá trình đặc tả. Tương tác bên liên quan sau giai đoạn yêu cầu là tối thiểu.
Sản phẩm công việc điển hình Đặc tả yêu cầu hệ thống cổ điển, bao gồm các yêu cầu dạng văn bản và mô hình.
Luồng thông tin điển hình Chủ yếu từ các bên liên quan đến Kỹ sư Yêu cầu.

Ví dụ: Một nhà sản xuất ô tô đang phát triển nền tảng xe mới. Quyết định thiết kế quan trọng là thay thế hàng chục bộ điều khiển điện tử (ECU) riêng lẻ bằng một máy tính điều khiển trung tâm duy nhất. Mục tiêu là giảm chi phí phần cứng, loại bỏ xung đột giữa các ECU, và đơn giản hóa việc cập nhật phần mềm. Nhóm kỹ sư phụ trách hệ thống điện tử đã viết đặc tả yêu cầu khách hàng. Công ty hợp đồng với một nhà sản xuất hệ thống điều khiển ô tô lớn để tạo đặc tả yêu cầu hệ thống cho hệ thống điều khiển tập trung mới. Sau đó, nhà sản xuất ô tô sẽ đấu thầu thiết kế và triển khai dựa trên đặc tả đó — với yêu cầu triển khai theo nhiều vòng lặp để dễ kiểm thử và tích hợp.

Đây là tình huống phù hợp với quy trình RE theo hợp đồng. Quy trình tổng thể là tuyến tính: hệ thống chỉ được thiết kế và triển khai sau khi đặc tả yêu cầu hoàn thành. Việc triển khai lặp lại không ảnh hưởng đến quy trình RE. Tùy chất lượng đặc tả yêu cầu khách hàng hiện có và mức độ sẵn có của bên liên quan tại nhà sản xuất ô tô, có thể chọn quy trình RE tuyến tính hoặc lặp lại.

Rõ ràng cần quy trình RE dành riêng cho khách hàng. Việc đặc tả yêu cầu hệ thống sẽ được dùng để đấu thầu đòi hỏi quy trình RE phải có tính định sẵn (prescriptive).

Quy Trình RE Định Hướng Sản Phẩm: Lặp Lại & Khám Phá & Định Hướng Thị Trường

(Product-Oriented RE Process: Iterative & Explorative & Market-Oriented)

Quy trình RE định hướng sản phẩm thường được chọn khi tổ chức phát triển hệ thống như sản phẩm hoặc dịch vụ cho thị trường. Hầu hết trường hợp đi kèm với quy trình phát triển sản phẩm agile. Chủ sở hữu sản phẩm và nhà thiết kế kỹ thuật số đóng vai trò chủ đạo — họ ảnh hưởng và định hình mạnh mẽ sản phẩm.
Trường hợp ứng dụng chính Một tổ chức đặc tả và phát triển phần mềm để bán hoặc phân phối nó như một sản phẩm hoặc dịch vụ.
Sản phẩm công việc điển hình Product backlog với các user story và/hoặc mô tả tác vụ, tầm nhìn (vision), nguyên mẫu (prototypes), phản hồi người dùng.
Luồng thông tin điển hình Tương tác giữa chủ sở hữu sản phẩm, tiếp thị, Kỹ sư Yêu cầu, nhà thiết kế kỹ thuật số và nhà phát triển, cộng thêm phản hồi từ khách hàng/người dùng.

Ví dụ: Một công ty truyền thông giao bộ phận CNTT nội bộ nhiệm vụ đổi mới hoàn toàn ứng dụng tin tức di động — ứng dụng được bán cho người đăng ký (một số nội dung truy cập tự do). Công ty có nhật ký dài ghi lại phàn nàn và đề xuất cải tiến từ người dùng.

Cụ thể: ứng dụng hiện tại phản hồi chậm, hỗ trợ kém cho việc báo cáo sự cố và đề xuất, không hỗ trợ phóng to bằng hai ngón tay. Bộ tiếp thị nhận thấy bố cục đã lỗi thời và dự đoán có thể thu hút thêm người đăng ký với bố cục mới. CEO quyết định bộ CNTT sẽ phối hợp với agency thiết kế bên ngoài về giao diện trực quan. Ban quản lý muốn có phiên bản sản phẩm tối thiểu (proof of concept) trước, sau đó ra phiên bản mới mỗi ba tuần để tiếp thị và ban giám đốc xem xét.

Đây là tình huống phù hợp nhất với quy trình RE định hướng sản phẩm. Dù có quan hệ khách hàng–nhà cung cấp giữa ban quản lý và bộ CNTT, trọng tâm rõ ràng là tạo ra sản phẩm đổi mới trong phân khúc ứng dụng tin tức di động. Quy trình RE phải có tính khám phá — yêu cầu ngoài nhật ký phản hồi hiện có chưa rõ ràng. Quy trình phát triển tổng thể phải lặp lại theo quyết định của ban quản lý. Do yêu cầu cần được khám phá, quy trình RE lặp lại là lựa chọn phù hợp nhất.

📌 [GHI CHÚ ÔN THI] Ví dụ này minh họa một điểm quan trọng: có mối quan hệ customer-supplier nhưng vẫn chọn market-oriented — vì yếu tố quyết định là hệ thống được phát triển như một sản phẩm thị trường (ứng dụng tin tức cho người đăng ký), không phải cho riêng tổ chức đặt hàng. Đây là bẫy hay gặp: thấy “ban quản lý đặt hàng bộ phận CNTT” → nghĩ customer-specific, nhưng thực ra Target facet nhìn vào người dùng cuối và mục đích thị trường của sản phẩm.

5.3.2 Các Quy Trình RE Khác

(Other RE Processes)

Ba tổ hợp trên bao phủ nhiều tình huống thực tế. Tuy nhiên, có những trường hợp không có cấu hình nào ở trên phù hợp — ví dụ khi ràng buộc quy định bắt buộc phải dùng quy trình tuân thủ một tiêu chuẩn cụ thể như ISO/IEC/IEEE 29148. Khi đó, phải tạo quy trình RE từ đầu bởi chuyên gia quy trình, hoặc tùy chỉnh một trong ba cấu hình có sẵn cho phù hợp.

📌 [GHI CHÚ ÔN THI] Có hai cách xử lý khi không có cấu hình nào phù hợp: (1) tạo từ đầu bởi process experts, hoặc (2) tùy chỉnh một trong 3 cấu hình có sẵn. IREB không yêu cầu thuộc nội dung ISO/IEC/IEEE 29148 — chỉ cần biết đây là ví dụ tiêu chuẩn quốc tế có thể áp đặt một RE process cụ thể.

5.3.3 Cách Cấu Hình Quy Trình RE

(How to Configure RE Processes)

Chúng tôi đề xuất một quy trình năm bước để cấu hình một quy trình RE:

🔑 [THUẬT NGỮ — SONG NGỮ] 5 bước cấu hình RE process — thuộc cả tên tiếng Anh:

Bước Tiếng Anh Tiếng Việt
1 Analyze the influencing factors Phân tích các yếu tố ảnh hưởng
2 Assess the facet criteria Đánh giá các tiêu chí khía cạnh
3 Configure Cấu hình
4 Determine work products Xác định sản phẩm công việc
5 Select appropriate practices Chọn các thực hành phù hợp

Đề thi có thể hỏi tên bước, thứ tự bước, hoặc cho một tình huống và hỏi đang ở bước nào. Thứ tự không thể đảo — phải phân tích influencing factors (bước 1) trước khi assess criteria (bước 2), và configure (bước 3) trước khi determine work products (bước 4).

1. Phân tích các yếu tố ảnh hưởng (Analyze the influencing factors): Phân tích tình huống của bạn dựa trên danh sách các yếu tố ảnh hưởng từ Mục 5.1.

2. Đánh giá các tiêu chí khía cạnh (Assess the facet criteria): Dựa trên phân tích từ bước 1, xem qua danh sách các tiêu chí lựa chọn khía cạnh được đưa ra trong Mục 5.2. Bạn có thể gán cho mỗi tiêu chí một giá trị trên thang điểm năm mức (−−, −, 0, +, ++).

📌 [GHI CHÚ ÔN THI] Thang điểm 5 mức (−−, −, 0, +, ++) là chi tiết đặc thù của IREB — dùng để chấm điểm từng tiêu chí trong bước đánh giá. Biết chi tiết này giúp trả lời câu hỏi về cách đánh giá và chọn facet instance. Lưu ý: đây là thang điểm cho tiêu chí, không phải cho facet — mỗi tiêu chí được đánh giá độc lập, sau đó tổng hợp để quyết định chọn instance nào.

3. Cấu hình (Configure): Nếu phân tích tiêu chí cho kết quả rõ ràng, chọn một trong ba cấu hình điển hình. Nếu không, tùy chỉnh quy trình, với mục tiêu bao trùm là giảm thiểu rủi ro phát triển sai hệ thống.

Ví dụ: khách hàng yêu cầu tạo trước đặc tả yêu cầu hệ thống — điều này đòi hỏi quy trình RE tuyến tính, định sẵn. Nhưng qua các cuộc họp đầu tiên, bạn nhận ra với một hệ thống con quan trọng, khách hàng hoàn toàn chưa biết cần xây dựng gì — điều này lại cần quy trình khám phá. Giải pháp: dùng quy trình RE theo hợp đồng làm khung chung, nhưng tạo một dự án con để từng bước khơi gợi yêu cầu cho hệ thống con đó — qua hai hoặc ba vòng lặp với quy trình RE tham gia — rồi đưa kết quả vào đặc tả yêu cầu hệ thống.

📌 [GHI CHÚ ÔN THI] Kỹ thuật “mixed process” — dùng một cấu hình chính làm khung (ví dụ: contractual) nhưng chạy một sub-process khác (participatory) cho một phần cụ thể — là kỹ thuật thực tế quan trọng mà IREB công nhận. Đây là đáp án cho các câu hỏi dạng “hai yêu cầu mâu thuẫn nhau, làm sao giải quyết?” → không phải chọn một, mà kết hợp cả hai ở các cấp độ khác nhau.

4. Xác định sản phẩm công việc (Determine work products): Dựa trên phân tích và cấu hình quy trình, xác định các sản phẩm công việc RE chính cần tạo ra. Đảm bảo chúng căn chỉnh với sản phẩm công việc của quy trình phát triển tổng thể.

5. Chọn các thực hành phù hợp (Select appropriate practices): Với từng nhiệm vụ cần thực hiện — ví dụ khơi gợi yêu cầu — chọn thực hành phù hợp nhất với tình huống cụ thể. Nhiều thực hành, kèm gợi ý về thời điểm và cách áp dụng, được trình bày trong Chương 2, 4 và 6 của sổ tay này.

Không có quy trình RE nào phù hợp với mọi trường hợp. Dựa trên phân tích các yếu tố ảnh hưởng, mỗi dự án RE cần được tùy chỉnh một quy trình riêng. Cách đơn giản nhất là cấu hình từ bộ các khía cạnh quy trình.

📌 [GHI CHÚ ÔN THI] Câu này là câu kết luận cốt lõi của toàn chương 5 — cũng là câu mở đầu ở mục 1.4. IREB nhấn mạnh: không có one-size-fits-all RE process. Đây là nền tảng lý giải tại sao phải cấu hình từ các facets thay vì áp dụng một quy trình cố định. Câu hỏi thi thường dùng cụm này như một “trap”: nếu đáp án nào khẳng định có một quy trình RE phổ quát → sai.

5.4 Tài Liệu Đọc Thêm

(Further Reading)

Armour [Armo2004] và Reinertsen [Rein1997], [Rein2009] cung cấp các góc nhìn chung về quy trình và luồng thông tin.

Sách giáo khoa của Robertson và Robertson [RoRo2012], dù có tựa là “Mastering the Requirements Process”, thực chất là sách tổng hợp về tất cả khía cạnh của RE.

Wiegers và Beatty [WiBe2013] có một chương về cải thiện quy trình RE. Sommerville và Sawyer [SoSa1998] tổng hợp các thực hành tốt trong khuôn khổ quy trình RE.

Hết Chương 5 — Bản dịch tiếng Việt đầy đủ, dịch sát 100% từ CPRE Foundation Level Handbook v1.3.0, Martin Glinz et al.