Chương 5 - Quy trình và Cấu trúc Công việc

Bất cứ khi nào công việc phải được thực hiện một cách có hệ thống, một quy trình là cần thiết để định hình và cấu trúc cách thức làm việc và việc 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 Kỹ nghệ Yêu cầu (RE) tổ chức cách thức các nhiệm vụ RE được thực hiện 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. Tuy nhiên, không có một quy trình RE đã được kiểm chứng nào phù hợp với mọi trường hợp (xem Mục 1.4). Do đó, các Kỹ sư Yêu cầu phải cấu hình một quy trình RE phù hợp với từng tình huống cụ thể.

Quy trình RE định hình luồng thông tin và mô hình giao tiếp giữa các thành phần tham gia vào RE (ví dụ: khách hàng, người dùng, Kỹ sư Yêu cầu, nhà phát triển và kiểm thử viên). Nó cũng xác định các sản phẩm công việc RE cần được sử dụng hoặc tạo ra. Một quy trình RE phù hợp cung cấp khuôn khổ mà trong đó các Kỹ sư Yêu cầu khơi gợi, tài liệu hóa, thẩm định và quản lý các 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.

Một mặt, việc phân tích đó cung cấp thông tin về cách cấu hình quy trình RE. Ví dụ, khi phân tích cho thấy các bên liên quan chỉ có ý niệm mơ hồ về yêu cầu của họ, nên chọn một 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 ràng buộc không gian các cấu hình quy trình khả thi. Ví dụ, nếu các bên liên quan chỉ có mặt vào giai đoạn đầu của dự án phát triển hệ thống, thì một quy trình dựa vào phản hồi liên tục từ bên liên quan sẽ không phù hợp. Dưới đây, chúng tôi thảo luận về các yếu tố quan trọng đối với quy trình RE.

📌 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

Overall process fit — Phải khớp với quy trình phát triển tổng thể
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
Stakeholder availability & capability — Sẵn có + năng lực
Shared understanding — Hiểu biết chung ↑ → RE process nhẹ hơn
Complexity & criticality — Phức tạp/trọng yếu cao → spec chi tiết + formal models
Constraints — Ràng buộc tường minh từ khách hàng hoặc cơ quan quản lý
Time & budget — Ngân sách eo → iterative, ưu tiên yêu cầu quan trọng nhất
Volatility of requirements — Thay đổi nhiều → iterative + change-friendly
Experience of Requirements Engineers — Ít kinh nghiệm → quy trình đơn giản hơn

⚠️ BẪY ĐỀ THI

Đề 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 một quy trình RE, điều thiết yếu là phải biết và hiểu quy trình phát triển tổng thể đã được chọn cho hệ thống cần phát triển — việc đị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 các sản phẩm công việc mà quy trình RE phải cung cấp. Thuật ngữ sử dụng trong quy trình RE cần được căn chỉnh với thuật ngữ của quy trình tổng thể. Đặc biệt, thuật ngữ dành cho các sản phẩm công việc phải được căn chỉnh thống nhất. Điều này giúp tránh nhầm lẫn và hiểu nhầm, đồng thời giúp việc triển khai quy trình RE cũng như đào tạo và huấn luyện những người phải làm việc theo quy trình đó trở nên dễ dàng hơn. Ví dụ, nếu hệ thống được phát triển theo một quy trình tuyến tính, có kế hoạch sẵn (plan-driven) và yêu cầu phải có một đặc tả yêu cầu hệ thống toàn diện cùng với một bảng thuật ngữ hệ thống vào cuối giai đoạn yêu cầu, thì quy trình RE được chọn phải phù hợp với giai đoạn yêu cầu đó và tạo ra hai sản phẩm công việc nêu 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ác yếu tố cần cân nhắc bao gồm mối quan hệ khách hàng–nhà cung cấp–người dùng, loại hình phát triển, vấn đề hợp đồng và sự tin tưởng. Khi phân tích bối cảnh phát triển, cần trả lời một số câu hỏi:

Mối quan hệ khách hàng–nhà cung cấp–người dùng: Có một khách hàng cụ thể đặt hàng và trả tiền cho hệ thống, và một nhà cung cấp phát triển hệ thống đó không? Khách hàng và nhà cung cấp có thuộc cùng một tổ chức hay khác tổ chức? Nếu cùng tổ chức, ai đóng vai trò khách hàng, ai đóng vai trò nhà cung cấp? Người dùng hệ thống là ai? Người dùng có thuộc tổ chức của khách hàng không? Nếu không, họ dùng hệ thống như một sản phẩm hoặc dịch vụ để tương tác với khách hàng (ví dụ: thương mại điện tử), hay họ mua hệ thống như một sản phẩm hoặc dịch vụ từ khách hàng (ví dụ: một ứ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 tương tự 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 cổ điển giữa khách hàng và nhà cung cấp (với chức năng, thời hạn và chi phí 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 kiểu lặp lại.
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)

Tính sẵn có của các bên liên quan ràng buộc các lựa chọn cấu hình quy trình RE. Ví dụ, không thể chọn một quy trình đòi hỏi tương tác chặt chẽ liên tục với các bên liên quan nếu các bên liên quan cốt lõi chỉ có mặt trong một khoảng thời gian ngắn ở đầu quy trình.

Năng lực của các bên liên quan cũng ảnh hưởng đến quy trình: các bên liên quan càng ít có khả năng bày tỏ nhu cầu của họ một cách rõ ràng, và họ càng ít biết về nhu cầu thực tế của mình, thì quy trình RE càng phải điều chỉnh để phù hợp với việc khám phá các 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 mà các yêu cầu cần được đặc tả phụ thuộc mạnh mẽ vào độ phức tạp và tính trọng yếu của hệ thống cần phát triển. Khi hệ thống có độ phức tạp cao và/hoặc có tính trọng yếu đối với an toàn hoặc bảo mật, quy trình RE được chọn phải đáp ứng việc đặc tả chi tiết các yêu cầu trọng yếu, bao gồm các mô hình hình thức hoặc bán hình thức và việc thẩm định chặt chẽ — ví dụ, bằng cách xác minh các mô hình thể hiện hành vi được quy định, hoặc bằng cách xây dựng các 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)

Rõ ràng, tất cả các yếu tố ảnh hưởng đều ràng buộc không gian các cấu hình khả thi của một quy trình RE. Khi nói về các ràng buộc, chúng tôi muốn nói đến những ràng buộc được áp đặt một cách tường minh bởi, ví dụ, khách hàng hoặc một cơ quan quản lý. Các ràng buộc như vậy có thể kéo theo việc bắt buộc tạo ra một số sản phẩm công việc nhất định và phải tuân theo một quy trình bắt buộc để tạo ra các sản phẩm công việc đó. Khách hàng hoặc cơ quan quản lý cũng có thể yêu cầu một quy trình RE tuân thủ theo một tiêu chuẩn nhất định.

📌 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 cho phép (Time and budget available)

Nếu tiến độ và ngân sách eo hẹp, thời gian và ngân sách dành cho RE cần được sử dụng một cách khôn ngoan — điều này thường ngụ ý việc chọn một quy trình RE gọn nhẹ. Việc chọn một quy trình RE lặp lại giúp ưu tiên các yêu cầu và triển khai những yêu cầu quan trọng nhất trong phạm vi ngân sách và tiến độ đã cho.

📌 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 được chọn phải khớp với năng lực và kinh nghiệm của các Kỹ sư Yêu cầu tham gia. 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 quy trình đã chọn. Tốt hơn là chọn một quy trình tương đối đơn giản mà các Kỹ sư Yêu cầu có thể xử lý đúng cách, thay vì một quy trình tinh vi và phức tạp 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)

Việc định nghĩa quy trình RE từ đầu cho mỗi nỗ lực RE là một sự lãng phí công sức. Bất cứ khi nào các yếu tố ảnh hưởng cho phép, quy trình nên được cấu hình từ các thành phần có sẵn. Nhằm cung cấp hướng dẫn về cách cấu hình một quy trình RE phù hợp, chúng tôi mô tả ba khía cạnh, mỗi khía cạnh có hai thể hiện (instances), cùng với các tiêu chí lựa chọn cho từng thể hiện [Glin2019]. Sau đó, trong Mục 5.3, chúng tôi sử dụng các khía cạnh này để cấu hình các quy trình RE. Hình 5.1 cho thấy tổng quan về các khía cạnh và các thể hiện.

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

Các khía cạnh này có thể được coi là trải dài trong một không gian ba chiều của các tùy chọn cấu hình quy trình. Mỗi thể hiện khía cạnh đi kèm với các tiêu chí để lựa chọn nó.

Tính phù hợp của các tiêu chí này bắt nguồn từ việc phân tích các yếu tố ảnh hưởng đã được thảo luận trong Mục 5.1 ở trên. Lưu ý rằng không phải tất cả các tiêu chí đều cần được đáp ứng để chọn một thể hiện của một khía cạnh.

📌 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 giải quyết việc tổ chức các hoạt động RE trên thang thời gian. Chúng ta phân biệt giữa các quy trình 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, các yêu cầu được đặc tả toàn bộ từ đầu (up front) trong một giai đoạn duy nhất của quy trình. Ý tưởng là tạo ra một đặc tả yêu cầu toàn diện không cần hoặc chỉ cần ít thích nghi hay thay đổi trong quá trình thiết kế và triển khai hệ thống. Việc tạo ra một đặc tả yêu cầu toàn diện ngay từ đầu đòi hỏi một quy trình toàn diện. Do đó, trong hầu hết các trường hợp, quy trình RE tuyến tính là các quy trình nặng (heavyweight processes).

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

⚠️ BẪY ĐỀ 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, các 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 yêu cầu trong mỗi vòng lặp. Ý tưởng là đan xen việc đặc tả yêu cầu với việc thiết kế và triển khai hệ thống. Nhờ các vòng phản hồi ngắn và khả năng thích nghi với thay đổi hoặc những điều bị bỏ sót ở các vòng lặp sau, quy trình RE lặp lại có thể là các quy trình gọn nhẹ (lightweight processes).

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 giải quyết mục đích và vai trò của các yêu cầu trong quá trình phát triển hệ thống. Chúng ta phân biệt giữa các quy trình RE đị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ấu thành một hợp đồng: tất cả các yêu cầu đều có tính ràng buộc và phải được triển khai. Ý tưởng là tạo ra một đặc tả yêu cầu có thể được triển khai mà cần rất ít hoặc không cần thêm tương tác giữa các 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.

⚠️ BẪY ĐỀ THI

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ó các mục tiêu được biết trước, trong khi các yêu cầu cụ thể phải được khơi gợi. Ý tưởng là các yêu cầu thường không được biết trước mà phải được khám phá.

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: loại hình phát triển nào chúng ta nhắm đến với quy trình RE? Ở mức cơ bản, chúng 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 một quy trình RE dành riêng cho khách hàng, hệ thống được đặt hàng bởi một khách hàng và được phát triển bởi một nhà cung cấp cho khách hàng đó. Lưu ý rằng nhà cung cấp và khách hàng có thể thuộc cùng một tổ chức. Ý tưởng là quy trình RE phản ánh mối quan hệ khách hàng–nhà cung cấp.

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 một quy trình RE định hướng thị trường, hệ thống được phát triển như một 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ể. Ý tưởng là tổ chức phát triển hệ thống cũng chính là đơn vị 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.
Các Kỹ sư Yêu cầu phải thiết kế các yêu cầu sao cho phù hợp với nhu cầu được hình dung của các 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)

Điều quan trọng cần lưu ý là các tiêu chí đưa ra ở trên là các phương pháp phỏng đoán kinh nghiệm (heuristics). Chúng không nên được coi là một tập hợp các quy tắc cố định luôn luôn áp dụng. Ví dụ, việc thuê ngoài phát triển hệ thống được thực hiện tốt hơn với một quy trình RE định sẵn hơn là một quy trình khám phá. Điều này là do hợp đồng giữa khách hàng và nhà cung cấp thường dựa trên một đặc tả yêu cầu toàn diện. Tuy nhiên, cũng có thể đàm phán một hợp đồng thuê ngoài dựa trên một 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.

Có thể có những điều kiện tiên quyết cho việc chọn một số thể hiện nhất định của các khía cạnh quy trình, hoặc sự lựa chọn đó có thể kéo theo những hệ quả cần được xem xét. Dưới đây là một số 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.

⚠️ BẪY ĐỀ THI

Đâ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.

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

⚠️ BẪY ĐỀ THI

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 một quy trình định hướng thị trường, phản hồi từ những người dùng tiềm năng là phương tiện duy nhất để thẩm định xem liệu sản phẩm có thực sự thỏa mãn nhu cầu của phân khúc người dùng được nhắm đến hay không.

⚠️ BẪY ĐỀ THI

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 đề cập ở trên không hoàn toàn độc lập với nhau: sự lựa chọn được đưa ra cho một khía cạnh có thể ảnh hưởng đến những gì có thể hoặc nên được chọn ở các khía cạnh khác. Dưới đây là một số ví dụ:

Tuyến tính và định sẵn thường được chọn cùng nhau — điều đó có nghĩa là khi các Kỹ sư Yêu cầu quyết định chọn một quy trình RE tuyến tính, họ thường quyết định một 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.

⚠️ BẪY ĐỀ THI

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 độ mà một quy trình RE phải được thiết lập và tuân theo, cũng như khối lượng các sản phẩm công việc yêu cầu cần tạo ra trong quy trình đó, phụ thuộc vào 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 có ít thời gian và ngân sách cho RE, các nguồn lực có sẵn phải được sử dụng cẩn thận. Việc chọn một quy trình lặp lại và khám phá sẽ giúp ích. Hơn nữa, quy trình nên tập trung vào việc xác định và xử lý những yêu cầu có tính trọng yếu đối với sự thành công của hệ thống.

Cuối cùng, quy trình RE nên phù hợp với kinh nghiệm của các Kỹ sư Yêu cầu. Kỹ năng và kinh nghiệm của họ càng thấp thì quy trình RE nên được thiết kế càng đơn giản — việc định nghĩa một quy trình tinh vi khi những người tham gia không thể thực thi quy trình đó đúng cách 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)

Trong một bối cảnh phát triển hệ thống cụ thể, các Kỹ sư Yêu cầu hoặc (những) người chịu trách nhiệm về RE phải chọn quy trình RE cần áp dụng. Chúng tôi khuyến nghị phân tích các yếu tố ảnh hưởng (xem Mục 5.1) trước, sau đó chọn một tổ hợp phù hợp của các khía cạnh quy trình được mô tả trong Mục 5.2.

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

(Typical Combinations of Facets)

Ba tổ hợp khía cạnh (hoặc các biến thể của chúng) thường xuyên xuất hiện trong thực tế [Glin2019]. Dưới đây, chúng tôi mô tả ngắn gọn từng tổ hợp và đặc trưng hóa chúng theo trường hợp ứng dụng chính, các sản phẩm công việc điển hình và luồng thông tin điển hình. Ngoài ra, chúng tôi cung cấp một ví dụ minh họa. Hình 5.2 cho thấy ba cấu hình quy trình điển 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

⚠️ BẪY ĐỀ THI

Đề 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 linh hoạt khi có một khách hàng đặt hàng hệ thống và một đội ngũ phát triển thiết kế và triển khai nó. Trọng tâm là khám phá các yêu cầu qua một chuỗi các vòng lặp, trong sự cộng tác chặt chẽ giữa các bên liên quan phía khách hàng, các Kỹ sư Yêu cầu và đội ngũ 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ụ: Trong một công ty bảo hiểm, bộ phận kinh doanh chuyên bán bảo hiểm doanh nghiệp cho các doanh nghiệp vừa và nhỏ có ý tưởng về một sản phẩm mới để bảo hiểm khách hàng trước thiệt hại do tấn công mạng gây ra. Họ hợp đồng với bộ phận CNTT nội bộ của công ty để thành lập một đội ngũ phát triển với nhiệm vụ thiết kế và phát triển một ứng dụng mới có thể xử lý sản phẩm bảo hiểm mới trong hệ thống hỗ trợ bán bảo hiểm hiện tại. Ngoài ra, hệ thống quản lý hợp đồng bảo hiểm hiện có cũng cần được điều chỉnh tương ứng. Ngoài một số yêu cầu ban đầu, bộ phận kinh doanh đặt hàng không có ý tưởng rõ ràng về cách sản phẩm mới sẽ trông như thế nào và cần được hỗ trợ bởi các hệ thống CNTT nội bộ ra sao. Bộ phận CNTT nội bộ đã áp dụng phát triển linh hoạt cho tất cả các dự án từ vài năm trước.

Trong tình huống này, một quy trình RE tham gia là phù hợp. Nó phù hợp với quy trình linh hoạt tổng thể mà bộ phận CNTT sẽ sử dụng để phát triển hệ thống mới và điều chỉnh các hệ thống hiện có.

Các bên liên quan từ bộ phận kinh doanh và các Kỹ sư Yêu cầu từ bộ phận CNTT có thể cùng nhau khơi gợi các yêu cầu cho sản phẩm bảo hiểm mới. Vì quy trình có tính lặp lại, đội ngũ phát triển có thể tạo ra một sản phẩm thị trường tối thiểu nguyên mẫu (minimum marketable product — MMP) giúp ban quản lý của bộ phận kinh doanh quyết định có đưa sản phẩm được hình dung vào danh mục hay loại bỏ ý tưởng. Có mối quan hệ khách hàng–nhà cung cấp rõ ràng giữa bộ phận kinh doanh và bộ phận CNTT, vì vậy một quy trình RE định hướng khách hàng là phù hợp.

⚠️ BẪY ĐỀ THI

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)

⚠️ BẪY ĐỀ 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 một hệ thống được đấu thầu và thuê ngoài cho một nhà cung cấp 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à quy trình phù hợp cho RE trong các dự án phát triển hệ thống lớn áp dụng quy trình phát triển kiểu thác nước (waterfall).


Trường hợp ứng dụng chính	Đặc tả yêu cầu cấu thành 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ả, và với ít tương tác bên liên quan sau giai đoạn yêu cầ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, từ đó sẽ phát sinh ra nhiều mẫu xe. Một quyết định thiết kế quan trọng cho nền tảng mới là loại bỏ hàng chục bộ điều khiển điện tử (ECU) hiện được sử dụng trong các xe và thay thế bằng một máy tính điều khiển duy nhất chạy một bộ ứng dụng điều khiển lái xe và hỗ trợ lái xe. Mục tiêu là tiết kiệm chi phí phần cứng, loại bỏ các tương tác không mong muốn giữa các ECU, và giảm cả thời gian lẫn công sức khi thực hiện cập nhật phần mềm. Các kỹ sư phụ trách hệ thống điện tử của nền tảng mới đã viết mộ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 ra một đặc tả yêu cầu hệ thống cho hệ thống điều khiển xe tập trung mới. Sau đó, nhà sản xuất ô tô sẽ đấu thầu thiết kế và triển khai hệ thống dựa trên đặc tả đó. Nhà sản xuất sẽ yêu cầu việc triển khai được thực hiện theo nhiều vòng lặp để dễ dàng kiểm thử và tích hợp hệ thống với nền tảng xe mới.

Trong tình huống này, một quy trình RE theo hợp đồng là phù hợp. Quy trình tổng thể là tuyến tính: hệ thống sẽ 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 theo từng vòng lặp không ảnh hưởng đến quy trình RE. Tùy thuộc vào chất lượng của đặc tả yêu cầu khách hàng hiện có và tính sẵn có của các bên liên quan tại nhà sản xuất ô tô, nên chọn quy trình RE tuyến tính hoặc lặp lại.

Rõ ràng, cần có một quy trình RE định hướng khách hàng. Sự tồn tại của một đặc tả yêu cầu khách hàng và việc đặc tả yêu cầu hệ thống sẽ được dùng để đấu thầu thiết kế và triển khai hệ thống đòi hỏi một quy trình RE định sẵn.

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 một tổ chức đang phát triển hệ thống như một sản phẩm hoặc dịch vụ cho thị trường. Trong hầu hết các trường hợp, quy trình RE định hướng sản phẩm đi cùng với một quy trình phát triển sản phẩm linh hoạt. Chủ sở hữu sản phẩm và các nhà thiết kế kỹ thuật số đóng vai trò chủ đạo trong quy trình này: 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 nhiệm vụ cho bộ phận CNTT nội bộ của mình đổi mới toàn bộ ứng dụng tin tức di động mà công ty bán cho người đăng ký (với một số nội dung có thể truy cập tự do). Từ phản hồi của người dùng, công ty duy trì một nhật ký dài ghi lại các phàn nàn và đề xuất cải tiến của khách hàng.

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

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

📌 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 được mô tả ở trên bao phủ nhiều tình huống xảy ra trong thực tế. Tuy nhiên, có thể có những tình huống mà không có cấu hình quy trình nào đã nêu ở trên là phù hợp. Ví dụ, các ràng buộc về quy định có thể áp đặt việc sử dụng một quy trình tuân thủ một tiêu chuẩn nhất định, chẳng hạn như ISO/IEC/IEEE 29148 [ISO29148]. Trong trường hợp như vậy, quy trình RE phải được tạo ra từ đầu bởi các chuyên gia về quy trình, hoặc một trong các cấu hình đã đề cập ở trên phải được tùy chỉnh để nó thích ứng với tình huống đã cho.

📌 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 ra kết quả rõ ràng đối với ba cấu hình điển hình đã đề cập ở trên, hãy chọn cấu hình đó. Nếu không, hãy chọn một cách tùy chỉnh quy trình khác, được dẫn dắt bởi mục tiêu chung là giảm thiểu rủi ro phát triển sai hệ thống. Ví dụ, hãy tưởng tượng một tình huống trong đó khách hàng yêu cầu tạo trước một đặc tả yêu cầu hệ thống, điều này đòi hỏi một quy trình RE tuyến tính, định sẵn. Tuy nhiên, trong các cuộc họp đầu tiên với khách hàng, bạn nhận thấy rằng đối với một hệ thống con quan trọng, khách hàng không có ý tưởng rõ ràng về cần xây dựng cái gì, điều này lại đòi hỏi một quy trình RE khám phá. Một giải pháp tiềm năng có thể là chọn một quy trình RE theo hợp đồng làm khuôn khổ RE chung, nhưng tạo ra một dự án con để từng bước khơi gợi các yêu cầu cho hệ thống con quan trọng đó — tạo ra các nguyên mẫu trong hai hoặc ba vòng lặp (được dẫn dắt bởi một quy trình RE con có tính tham gia), sau đó đư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 các 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 của bạn, xác định các sản phẩm công việc RE chính sẽ được tạo ra. Hãy đảm bảo rằng các sản phẩm công việc RE được căn chỉnh với các 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): Đối với các nhiệm vụ cần thực hiện — ví dụ, khơi gợi yêu cầu — hãy chọn các thực hành phù hợp nhất trong tình huống đã cho. Nhiều thực hành trong số này, bao gồm các gợi ý về vị trí và thời điểm áp dụng chúng, được trình bày trong Chương 2, 4 và 6 của sổ tay này.

Không có một quy trình RE đã được kiểm chứng 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ột quy trình RE cụ thể cần được tùy chỉnh cho từng nỗ lực RE. Một cách đơn giản để tùy chỉnh là cấu hình một quy trình RE từ một tập hợp 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 suy nghĩ chung về quy trình và luồng thông tin trong các quy trình.

Mặc dù cuốn sách giáo khoa của Robertson và Robertson [RoRo2012] có tựa đề là “Mastering the Requirements Process” (Làm chủ Quy trình Yêu cầu), đây là một cuốn sách giáo khoa chung về mọi khía cạnh của RE.

Wiegers và Beatty [WiBe2013] cung cấp một chương về việc cải thiện các quy trình RE. Cuốn sách của Sommerville và Sawyer [SoSa1998] chứa một bộ sưu tập các thực hành tốt để sử dụng trong khuôn khổ của các 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.