Chương 3

(Work Products and Documentation Practices)

---

Kỹ nghệ Yêu cầu truyền thống (RE) đòi hỏi phải có một đặc tả yêu cầu toàn diện, đầy đủ và không mơ hồ [IEEE830], [Glin2016]. Cách tiếp cận này phù hợp trong nhiều trường hợp, nhưng đôi khi chi phí bỏ ra để viết đặc tả lại vượt quá lợi ích thu được. Đặc tả toàn diện thực sự hữu ích — thậm chí là bắt buộc — trong các tình huống đấu thầu, thuê ngoài phát triển, hoặc khi hệ thống có yêu cầu an toàn then chốt và phải tuân thủ quy định nghiêm ngặt. Ngược lại, khi các bên liên quan và nhà phát triển cùng nhau xác định và phát triển hệ thống theo từng vòng lặp, việc viết đặc tả hoàn chỉnh ngay từ đầu thường không thực tế. Vì vậy, điều then chốt trong RE là điều chỉnh mức độ tài liệu hóa cho phù hợp với bối cảnh dự án và lựa chọn các sản phẩm công việc mang lại giá trị thiết thực nhất.

Trong chương này, bạn sẽ được học về các sản phẩm công việc RE điển hình và cách tạo ra chúng.

---

3.1 Sản phẩm Công việc trong Kỹ nghệ Yêu cầu

(Work Products in Requirements Engineering)

Có nhiều loại sản phẩm công việc được sử dụng trong RE.

Định nghĩa 3.1. Sản phẩm công việc (Work product): Một kết quả trung gian hoặc cuối cùng được ghi lại, được tạo ra trong một quy trình làm việc.

Chúng tôi coi thuật ngữ tạo phẩm (artifact) là từ đồng nghĩa với sản phẩm công việc. Chúng tôi ưu tiên dùng thuật ngữ “sản phẩm công việc” hơn “tạo phẩm” để nhấn mạnh rằng đây là kết quả của công việc được thực hiện trong một quy trình làm việc.

Theo định nghĩa này, một sản phẩm công việc RE có thể là bất cứ thứ gì thể hiện các yêu cầu — từ một câu đơn hoặc một biểu đồ duy nhất cho đến một đặc tả yêu cầu hệ thống bao gồm hàng trăm trang — cũng như các thông tin liên quan đến yêu cầu, ví dụ như một bảng thuật ngữ (glossary). Ngoài ra, cần lưu ý rằng một sản phẩm công việc có thể chứa các sản phẩm công việc khác.

3.1.1 Đặc điểm của Sản phẩm Công việc

(Characteristics of Work Products)

Các sản phẩm công việc có thể được đặc trưng bởi các khía cạnh sau: mục đích, kích thước, hình thức biểu diễn, vòng đời và lưu trữ.

Bảng 3.1 tổng quan các sản phẩm công việc điển hình trong RE, kèm mục đích (sản phẩm công việc đặc tả hoặc cung cấp cái gì) và kích thước thông thường. Bảng chia thành bốn nhóm: yêu cầu đơn lẻ, tập hợp yêu cầu nhất quán, tài liệu và cấu trúc tài liệu hóa, và các loại khác.

Bảng 3.1 — Tổng quan các sản phẩm công việc RE

Sản phẩm công việc	Mục đích: Sản phẩm công việc đặc tả / cung cấp	Kích thước*
Yêu cầu đơn lẻ
Yêu cầu đơn lẻ (Individual requirement)	Một yêu cầu duy nhất, thường ở dạng văn bản	S
User story	Một chức năng hoặc hành vi từ góc độ của bên liên quan	S
Tập hợp yêu cầu nhất quán
Use case	Một chức năng hệ thống từ góc độ của tác nhân hoặc người dùng	S–M
Mô hình đồ họa (Graphic model)	Nhiều khía cạnh khác nhau, ví dụ: bối cảnh, chức năng, hành vi (xem Mục 3.4)	M
Mô tả tác vụ (Task description)	Một tác vụ mà hệ thống phải thực hiện	S–M
Mô tả giao diện ngoài (External interface description)	Thông tin được trao đổi giữa hệ thống và một tác nhân trong bối cảnh hệ thống	M
Epic	Cái nhìn cấp cao về một nhu cầu của bên liên quan	M
Tính năng (Feature)	Một đặc điểm phân biệt của hệ thống	S–M
Tài liệu hoặc cấu trúc tài liệu hóa
Đặc tả yêu cầu hệ thống** (System requirements specification)	Một tài liệu yêu cầu toàn diện	L–XL
Product backlog và Sprint backlog	Danh sách các hạng mục công việc, bao gồm cả yêu cầu	M–L
Bản đồ câu chuyện người dùng (Story map)	Cách sắp xếp trực quan các user story	M
Tầm nhìn (Vision)	Hình dung về một hệ thống tương lai	M
Các sản phẩm công việc khác
Bảng thuật ngữ (Glossary)	Thuật ngữ chung được thống nhất và không mơ hồ	M
Ghi chú văn bản hoặc phác thảo đồ họa	Bản ghi nhớ phục vụ giao tiếp và tạo sự hiểu biết	S
Nguyên mẫu (Prototype)	Đặc tả thông qua ví dụ, đặc biệt để hiểu, xác nhận và thương lượng về yêu cầu	S–L

** S: Nhỏ, M: Vừa, L: Lớn, XL: Rất lớn*

*** Các ví dụ khác: đặc tả yêu cầu nghiệp vụ, đặc tả yêu cầu miền, đặc tả yêu cầu bên liên quan/người dùng, hoặc đặc tả yêu cầu phần mềm.*

Có nhiều cách khác nhau để biểu diễn một sản phẩm công việc. Trong RE, các hình thức biểu diễn dựa trên ngôn ngữ tự nhiên, mẫu (template) và mô hình có tầm quan trọng đặc biệt. Các hình thức này được thảo luận lần lượt tại Mục 3.2, 3.3 và 3.4. Ngoài ra còn có các hình thức biểu diễn khác như bản vẽ hoặc nguyên mẫu, được đề cập tại Mục 3.7.

Mỗi sản phẩm công việc đều có một vòng đời (lifespan) — khoảng thời gian từ khi sản phẩm được tạo ra cho đến khi bị loại bỏ hoặc không còn có giá trị sử dụng. Chúng tôi phân biệt ba loại:

Sản phẩm tạm thời (Temporary) được tạo ra để hỗ trợ giao tiếp và tạo ra sự hiểu biết chung (ví dụ: phác thảo tương tác người dùng–hệ thống được vẽ trong một buổi workshop). Sản phẩm tạm thời bị loại bỏ sau khi sử dụng và không cần lưu giữ siêu dữ liệu (metadata).

Sản phẩm đang phát triển (Evolving) được hình thành và liên tục hoàn thiện qua nhiều vòng lặp (ví dụ: một tập hợp user story ngày càng tăng về số lượng lẫn nội dung). Cần lưu giữ tối thiểu các siêu dữ liệu: chủ sở hữu, trạng thái và lịch sử sửa đổi. Mức độ kiểm soát thay đổi cần áp dụng tùy theo tầm quan trọng của sản phẩm.

Sản phẩm lâu bền (Durable) đã được thiết lập đường cơ sở (baselined) hoặc phát hành (ví dụ: một đặc tả yêu cầu là một phần của hợp đồng, hoặc một sprint backlog đang được triển khai trong một vòng lặp nhất định). Cần lưu giữ đầy đủ siêu dữ liệu để quản lý sản phẩm đúng cách, và phải tuân theo một quy trình thay đổi chặt chẽ để chỉnh sửa sản phẩm lâu bền (Chương 6).

Sản phẩm tạm thời có thể chuyển thành đang phát triển khi Kỹ sư Yêu cầu quyết định giữ lại và phát triển thêm — lúc đó cần bổ sung siêu dữ liệu để theo dõi quá trình phát triển. Khi sản phẩm đang phát triển được thiết lập đường cơ sở hoặc phát hành, vòng đời của nó chuyển sang trạng thái “lâu bền”.

📌 ÔN THI — 3 loại Lifespan (Vòng đời)

Loại	Tiếng Anh	Metadata	Đặc điểm
Tạm thời	Temporary	❌ Không giữ gì	Dùng xong bỏ (vd: phác thảo workshop)
Đang phát triển	Evolving	Tối thiểu: owner, status, revision history	Tăng trưởng qua nhiều vòng lặp; cần change control
Lâu bền	Durable	Full metadata + elaborate change process	Đã baseline/release (vd: spec trong hợp đồng)

⚠️ TRAP — Ngưỡng chuyển đổi: Temporary → Evolving khi quyết định giữ lại. Evolving → Durable khi được baselined hoặc released. Hay bị hỏi trong đề.

Hiện nay, hầu hết các sản phẩm công việc được lưu trữ điện tử dưới dạng tệp, trong cơ sở dữ liệu, hoặc trong các công cụ RE. Các sản phẩm công việc không chính thức và tạm thời có thể được lưu trữ trên phương tiện khác — ví dụ như giấy hoặc sticky notes trên bảng Kanban.

3.1.2 Các Mức độ Trừu tượng

(Abstraction Levels)

Các yêu cầu và sản phẩm công việc xuất hiện ở nhiều mức trừu tượng khác nhau — từ yêu cầu cấp cao cho một quy trình nghiệp vụ mới, cho đến các yêu cầu rất chi tiết như phản ứng của một thành phần phần mềm cụ thể trước một sự kiện ngoại lệ.

Yêu cầu nghiệp vụ, yêu cầu miền và yêu cầu của bên liên quan/người dùng thường xuất hiện ở mức độ trừu tượng cao hơn yêu cầu hệ thống. Khi một hệ thống bao gồm một hệ thống phân cấp của các hệ thống con (subsystem) và thành phần (component), sẽ có các yêu cầu hệ thống tương ứng ở từng mức độ trừu tượng cho các hệ thống con và thành phần đó.

Khi yêu cầu nghiệp vụ và yêu cầu của bên liên quan được ghi lại trong các sản phẩm công việc lâu bền — như đặc tả yêu cầu nghiệp vụ, đặc tả yêu cầu bên liên quan, hoặc tài liệu tầm nhìn — chúng thường đi trước đặc tả yêu cầu hệ thống. Ví dụ điển hình là trong các dự án làm theo hợp đồng: khách hàng lập và phát hành đặc tả yêu cầu bên liên quan, sau đó nhà cung cấp dùng tài liệu này làm cơ sở để xây dựng đặc tả yêu cầu hệ thống. Trong nhiều dự án khác, các loại yêu cầu này phát triển song song với nhau (co-evolve).

Một số sản phẩm công việc, như yêu cầu đơn lẻ, phác thảo hoặc mô hình quy trình, xuất hiện ở tất cả các mức. Các sản phẩm công việc khác lại gắn liền với một mức cụ thể. Ví dụ, một đặc tả yêu cầu hệ thống gắn với mức hệ thống. Cần lưu ý rằng một yêu cầu đơn lẻ ở mức trừu tượng cao có thể được tinh chỉnh thành nhiều yêu cầu chi tiết hơn ở các mức cụ thể hơn.

Sự lựa chọn mức độ trừu tượng phù hợp phụ thuộc đặc biệt vào đối tượng cần được đặc tả và mục đích của đặc tả. Điều quan trọng là không được trộn lẫn các yêu cầu ở các mức độ trừu tượng khác nhau. Ví dụ, trong đặc tả hệ thống thông tin y tế, khi viết một yêu cầu chi tiết về ảnh trên thẻ ID khách hàng, đoạn văn tiếp theo không nên nêu một mục tiêu hệ thống chung chung như “giảm chi phí chăm sóc sức khỏe trong khi duy trì mức độ dịch vụ hiện tại cho bệnh nhân”. Trong các sản phẩm công việc nhỏ và vừa (ví dụ: user story hoặc use case), các yêu cầu nên ở cùng một mức độ trừu tượng. Trong các sản phẩm công việc lớn như đặc tả yêu cầu hệ thống, các yêu cầu ở các mức độ trừu tượng khác nhau nên được giữ riêng biệt bằng cách cấu trúc đặc tả tương ứng (Mục 3.6).

Các yêu cầu tự nhiên xuất hiện ở các mức độ trừu tượng khác nhau. Việc lựa chọn sản phẩm công việc phù hợp với mức độ trừu tượng nhất định và cấu trúc hợp lý các sản phẩm công việc chứa yêu cầu ở nhiều mức độ trừu tượng là rất hữu ích.

3.1.3 Mức độ Chi tiết

(Level of Detail)

Khi đặc tả yêu cầu, Kỹ sư Yêu cầu phải quyết định mức độ chi tiết mà các yêu cầu sẽ được đặc tả. Tuy nhiên, việc quyết định mức độ chi tiết nào là phù hợp hoặc thậm chí tối ưu cho một yêu cầu cụ thể là một nhiệm vụ đầy thách thức.

Ví dụ, trong một tình huống mà khách hàng và nhà cung cấp hợp tác chặt chẽ, có thể chỉ cần phát biểu một yêu cầu về biểu mẫu nhập liệu như sau: “Hệ thống phải cung cấp một biểu mẫu để nhập dữ liệu cá nhân của khách hàng.” Ngược lại, trong tình huống thiết kế và triển khai hệ thống được thuê ngoài cho một nhà cung cấp có ít hoặc không có kiến thức về miền, thì một đặc tả chi tiết về biểu mẫu nhập thông tin khách hàng là cần thiết.

Mức độ chi tiết mà các yêu cầu cần được đặc tả phụ thuộc vào một số yếu tố, đặc biệt là:

• Vấn đề và bối cảnh dự án: Vấn đề càng khó và Kỹ sư Yêu cầu cùng nhà phát triển càng ít quen thuộc với bối cảnh dự án, thì cần càng nhiều chi tiết hơn.
• Mức độ hiểu biết chung về vấn đề: Khi các bên chưa có nhiều sự hiểu biết chung ngầm định (xem Nguyên tắc 3 ở Chương 2), cần có các đặc tả rõ ràng và chi tiết để tạo ra mức độ hiểu biết chung cần thiết.
• Mức độ tự do dành cho nhà thiết kế và lập trình viên: Các yêu cầu ít chi tiết hơn sẽ cho phép nhà phát triển nhiều quyền tự do hơn.
• Sự sẵn có của phản hồi nhanh từ bên liên quan trong quá trình thiết kế và triển khai: Khi có phản hồi nhanh, các đặc tả ít chi tiết hơn đủ để kiểm soát rủi ro phát triển sai hệ thống.
• Chi phí so với giá trị của một đặc tả chi tiết: Lợi ích của một yêu cầu càng cao thì chúng ta càng có thể đủ khả năng để đặc tả nó một cách chi tiết.
• Tiêu chuẩn và quy định: Các tiêu chuẩn được áp đặt và các ràng buộc quy định có thể yêu cầu đặc tả các yêu cầu chi tiết hơn mức cần thiết trong điều kiện bình thường.

Không có mức độ chi tiết “đúng” nào có thể áp dụng phổ quát cho mọi yêu cầu. Đối với mỗi yêu cầu, mức độ chi tiết phù hợp phụ thuộc vào nhiều yếu tố. Mức độ chi tiết trong các yêu cầu được đặc tả càng cao, rủi ro cuối cùng nhận được sản phẩm có tính năng hoặc thuộc tính không mong muốn hoặc thiếu sót càng thấp. Tuy nhiên, chi phí cho việc đặc tả tăng lên khi mức độ chi tiết tăng.

📌 ÔN THI — Trade-off cốt lõi về Level of Detail: Chi tiết càng cao → rủi ro nhận sai/thiếu tính năng càng thấp, nhưng chi phí viết spec càng cao. 6 yếu tố quyết định: (1) bối cảnh vấn đề/dự án, (2) mức độ shared understanding, (3) tự do dành cho developer, (4) khả năng feedback nhanh từ stakeholder, (5) cost vs. value, (6) tiêu chuẩn/quy định bắt buộc.

3.1.4 Các Khía cạnh cần Xem xét

(Aspects to be Considered)

Bất kể dùng sản phẩm công việc RE nào, khi tài liệu hóa yêu cầu cần xem xét một số khía cạnh [Glin2019].

Có ba loại yêu cầu cần bao phủ đủ: yêu cầu chức năng, yêu cầu chất lượng và ràng buộc (xem Mục 1.1). Trong thực tế, các bên liên quan thường bỏ qua yêu cầu chất lượng vì coi đó là điều hiển nhiên, và hay đặc tả ràng buộc dưới dạng yêu cầu chức năng. Kỹ sư Yêu cầu phải nhận ra và phân loại đúng cả ba nhóm.

Với yêu cầu chức năng, cần xem xét các khía cạnh khác nhau — ví dụ như cấu trúc dữ liệu cần có, thứ tự hành động, hoặc cách hệ thống phản ứng trước một sự kiện bên ngoài. Chúng tôi phân biệt ba khía cạnh chính:

Khía cạnh Cấu trúc và Dữ liệu (structure and data) tập trung vào các yêu cầu liên quan đến cấu trúc tĩnh của hệ thống và dữ liệu (bền vững) mà hệ thống cần biết để thực hiện các chức năng và tạo ra kết quả được yêu cầu.

Khía cạnh Chức năng và Luồng (function and flow) xử lý các chức năng mà hệ thống phải cung cấp và luồng kiểm soát cũng như dữ liệu bên trong và giữa các chức năng để tạo ra kết quả được yêu cầu từ dữ liệu đầu vào.

Khía cạnh Trạng thái và Hành vi (state and behavior) tập trung vào việc đặc tả hành vi phụ thuộc vào trạng thái của hệ thống — đặc biệt là cách hệ thống phản ứng với sự kiện bên ngoài nào đó tùy thuộc vào trạng thái hiện tại của hệ thống.

Khi xử lý yêu cầu chất lượng như tính khả dụng, độ tin cậy hoặc tính sẵn sàng, có thể sử dụng một mô hình chất lượng — ví dụ như mô hình được cung cấp bởi ISO/IEC 25010 [ISO25010] — làm danh sách kiểm tra (checklist).

Trong các yêu cầu chất lượng, yêu cầu hiệu năng (performance requirements) có tầm quan trọng đặc biệt. Yêu cầu hiệu năng liên quan đến:

• Thời gian (ví dụ: để thực hiện một tác vụ hoặc phản ứng với sự kiện bên ngoài)
• Khối lượng (ví dụ: kích thước cơ sở dữ liệu cần thiết)
• Tần suất (ví dụ: tần suất tính toán một chức năng hoặc nhận kích thích từ cảm biến)
• Thông lượng (ví dụ: tốc độ truyền dữ liệu hoặc tốc độ giao dịch)
• Tiêu thụ tài nguyên (ví dụ: CPU, bộ nhớ, băng thông, pin)

Một số người cũng xem độ chính xác cần thiết của một phép tính là yêu cầu hiệu năng.

Nên đặc tả các giá trị đo lường được khi có thể. Khi giá trị tuân theo phân phối xác suất, chỉ đặc tả giá trị trung bình là không đủ — nên bổ sung giá trị tối thiểu, tối đa, hoặc percentile 95, tùy theo mức độ phức tạp của phân phối.

Việc tài liệu hóa các yêu cầu chất lượng ngoài yêu cầu hiệu năng thường rất khó khăn.

Biểu diễn định tính (Qualitative representations), ví dụ như “Hệ thống phải an toàn và dễ sử dụng”, là mơ hồ và do đó khó đạt được và xác nhận.

Biểu diễn định lượng (Quantitative representations) có thể đo lường được — đây là một ưu điểm lớn trong việc đạt được và xác nhận yêu cầu chất lượng một cách có hệ thống. Tuy nhiên, cách này đặt ra những khó khăn cơ bản (ví dụ: làm sao diễn đạt bảo mật bằng giá trị số?) và có thể rất tốn kém để đặc tả.

Biểu diễn được vận hành hóa (Operationalized representations) phát biểu yêu cầu chất lượng thông qua các yêu cầu chức năng để đạt được chất lượng mong muốn. Ví dụ, một yêu cầu bảo mật dữ liệu có thể được biểu diễn thông qua một chức năng đăng nhập giới hạn quyền truy cập dữ liệu và một chức năng mã hóa dữ liệu được lưu trữ. Biểu diễn được vận hành hóa làm cho yêu cầu chất lượng có thể kiểm tra được, nhưng cũng có thể dẫn đến các quyết định thiết kế quá sớm.

Quan niệm phổ biến cho rằng “Chỉ yêu cầu chất lượng được định lượng mới là yêu cầu chất lượng tốt” đã trở nên lỗi thời và có thể dẫn đến các yêu cầu chất lượng có giá trị thấp hoặc thậm chí âm do nỗ lực định lượng quá lớn. Thay vào đó, nên sử dụng phương pháp tiếp cận dựa trên rủi ro [Glin2008].

Biểu diễn định tính của yêu cầu chất lượng là đủ trong các trường hợp sau:

• Có đủ sự hiểu biết chung ngầm định giữa các bên liên quan, Kỹ sư Yêu cầu và nhà phát triển.
• Các bên liên quan, Kỹ sư Yêu cầu và nhà phát triển đồng ý về một giải pháp đã biết có thể đáp ứng yêu cầu.
• Các bên liên quan chỉ muốn đưa ra định hướng chất lượng chung và tin tưởng nhà phát triển để xử lý các chi tiết.
• Có các vòng phản hồi ngắn để phát hiện vấn đề sớm.

Khi nhà phát triển có khả năng khái quát hóa từ các ví dụ, việc đặc tả yêu cầu chất lượng dưới dạng các ví dụ định lượng hoặc so sánh với một hệ thống hiện có là cách rẻ và hiệu quả để tài liệu hóa yêu cầu chất lượng.

Chỉ khi rủi ro không đáp ứng được nhu cầu stakeholder cao — đặc biệt với các yêu cầu chất lượng có tính an toàn then chốt — mới nên cân nhắc dùng biểu diễn định lượng đầy đủ hoặc vận hành hóa qua các yêu cầu chức năng.

Khi đặc tả ràng buộc (constraints), cần xem xét các loại ràng buộc sau:

• Kỹ thuật (Technical): Các giao diện hoặc giao thức đã có sẵn, các thành phần hoặc framework phải được sử dụng, v.v.
• Pháp lý (Legal): Các hạn chế do luật pháp, hợp đồng, tiêu chuẩn hoặc quy định áp đặt.
• Tổ chức (Organizational): Có thể có các ràng buộc về cơ cấu tổ chức, quy trình hoặc chính sách mà hệ thống không được thay đổi.
• Văn hóa (Cultural): Thói quen và kỳ vọng của người dùng được định hình một phần bởi văn hóa mà họ sống trong đó. Đây là khía cạnh đặc biệt quan trọng cần xem xét khi người dùng hệ thống đến từ nhiều nền văn hóa khác nhau, hoặc khi Kỹ sư Yêu cầu và nhà phát triển có gốc văn hóa khác với người dùng hệ thống.
• Môi trường (Environmental): Khi đặc tả các hệ thống thực - ảo (cyber-physical systems), các điều kiện môi trường như nhiệt độ, độ ẩm, bức xạ hoặc rung động có thể phải được xem xét là ràng buộc; tiêu thụ năng lượng và tản nhiệt cũng có thể tạo thành ràng buộc thêm.
• Vật lý (Physical): Khi một hệ thống bao gồm các thành phần vật lý hoặc tương tác với chúng, hệ thống bị ràng buộc bởi các quy luật vật lý và thuộc tính vật liệu được sử dụng cho các thành phần vật lý.
• Ngoài ra, các giải pháp hoặc hạn chế cụ thể do các bên liên quan quan trọng áp đặt cũng là ràng buộc.

Cuối cùng, yêu cầu chỉ có thể được hiểu đúng khi đặt trong bối cảnh (xem Nguyên tắc 4 ở Chương 2). Do đó cần xem xét thêm khía cạnh bối cảnh và ranh giới (context and boundary) — bao gồm các yêu cầu và giả định về miền ứng dụng, các tác nhân bên ngoài mà hệ thống tương tác, và các giao diện bên ngoài tại ranh giới hệ thống.

Có nhiều mối liên hệ và phụ thuộc giữa các khía cạnh đã đề cập. Ví dụ, một yêu cầu được người dùng gửi (bối cảnh) có thể được nhận bởi hệ thống qua một giao diện bên ngoài (ranh giới), kích hoạt một sự chuyển đổi trạng thái của hệ thống (trạng thái và hành vi), sau đó khởi tạo một hành động (chức năng) tiếp theo bởi một hành động khác (luồng) cần đến dữ liệu có cấu trúc nhất định (cấu trúc và dữ liệu) để cung cấp kết quả cho người dùng (bối cảnh) trong một khoảng thời gian nhất định (chất lượng).

Một số sản phẩm công việc tập trung vào một khía cạnh cụ thể và trừu tượng hóa các khía cạnh khác — điều này đặc biệt đúng với các mô hình yêu cầu (Mục 3.4). Các sản phẩm công việc khác, như đặc tả yêu cầu hệ thống, bao phủ tất cả các khía cạnh. Khi các khía cạnh khác nhau được tài liệu hóa trong các sản phẩm công việc riêng hoặc trong các chương riêng của cùng một sản phẩm, các sản phẩm hoặc chương đó phải được giữ nhất quán với nhau.

Tóm lại, khi tài liệu hóa yêu cầu cần bao phủ đủ các khía cạnh: chức năng (cấu trúc & dữ liệu, chức năng & luồng, trạng thái & hành vi), chất lượng, ràng buộc, và bối cảnh & ranh giới hệ thống.

📌 ÔN THI — Các khía cạnh cần nhớ (3.1.4)

3 khía cạnh functional requirements:

• Structure & data (Cấu trúc & dữ liệu) → UML Class Diagram
• Function & flow (Chức năng & luồng) → UML Activity Diagram, BPMN, DFD
• State & behavior (Trạng thái & hành vi) → UML State Diagram

6 loại Constraints (đề hay hỏi liệt kê): Technical · Legal · Organizational · Cultural · Environmental · Physical

⚠️ TRAP: Stakeholders hay bỏ sót quality requirements vì coi là hiển nhiên. Họ cũng hay đặc tả constraints như functional requirements. RE Engineer phải nhận ra và sửa.

⚠️ TRAP — “Chỉ quality requirement định lượng mới tốt” → LỖI THỜI. Dùng risk-based approach. Qualitative representation vẫn chấp nhận được khi có đủ shared understanding, feedback loop ngắn, hoặc stakeholder chỉ muốn chỉ hướng chung.

3.1.5 Hướng dẫn Tài liệu hóa Chung

(General Documentation Guidelines)

Độc lập với các kỹ thuật được sử dụng, có một số hướng dẫn chung cần tuân theo khi tạo các sản phẩm công việc RE:

• Chọn loại sản phẩm công việc phù hợp với mục đích dự định.
• Tránh sự dư thừa bằng cách tham chiếu đến nội dung thay vì lặp lại cùng một nội dung.
• Tránh sự không nhất quán giữa các sản phẩm công việc, đặc biệt khi chúng bao phủ các khía cạnh khác nhau.
• Sử dụng các thuật ngữ nhất quán theo định nghĩa trong bảng thuật ngữ.
• Cấu trúc các sản phẩm công việc một cách hợp lý — ví dụ: sử dụng các cấu trúc chuẩn.

3.1.6 Lập kế hoạch Sản phẩm Công việc

(Work Product Planning)

Mỗi bối cảnh dự án và mỗi miền là khác nhau, vì vậy tập hợp các sản phẩm công việc cần được xác định cho từng dự án. Các bên liên quan — đặc biệt là Kỹ sư Yêu cầu, bên liên quan, và chủ sản phẩm hoặc quản lý dự án — cần thống nhất về các vấn đề sau:

• Các yêu cầu sẽ được ghi lại trong sản phẩm công việc nào và phục vụ mục đích gì (xem Bảng 3.1)?
• Những mức độ trừu tượng nào cần được xem xét (Mục 3.1.2)?
• Cần tài liệu hóa các yêu cầu đến mức độ chi tiết nào tại mỗi mức trừu tượng (Mục 3.1.3)?
• Các yêu cầu sẽ được biểu diễn như thế nào trong các sản phẩm này (ví dụ: dựa trên ngôn ngữ tự nhiên hoặc dựa trên mô hình) và ký pháp nào sẽ được sử dụng?

Kỹ sư Yêu cầu nên xác định các sản phẩm công việc RE sẽ được sử dụng từ sớm trong dự án. Việc xác định sớm như vậy:

• Giúp lập kế hoạch công sức và nguồn lực.
• Đảm bảo sử dụng đúng ký pháp.
• Đảm bảo tất cả kết quả được ghi lại vào đúng sản phẩm công việc.
• Đảm bảo không cần tái cấu trúc thông tin lớn và “chỉnh sửa cuối” tốn kém.
• Giúp tránh sự dư thừa, dẫn đến ít công việc hơn và dễ bảo trì hơn.

📌 ÔN THI — Tại sao phải lập kế hoạch work products sớm? Giúp: (1) lập kế hoạch công sức & tài nguyên, (2) đảm bảo dùng đúng notation, (3) ghi kết quả vào đúng work product, (4) tránh xáo trộn lớn và “chỉnh sửa cuối” tốn kém, (5) tránh dư thừa → dễ bảo trì hơn.

---

3.2 Sản phẩm Công việc Dựa trên Ngôn ngữ Tự nhiên

(Natural-Language-Based Work Products)

Ngôn ngữ tự nhiên, cả nói lẫn viết, luôn là phương tiện cốt lõi để truyền đạt yêu cầu. Ưu điểm nổi bật là tính linh hoạt và biểu cảm cao — hầu như bất kỳ yêu cầu nào cũng có thể diễn đạt được — và không cần đào tạo đặc biệt để đọc hiểu.

Tuy nhiên, ngôn ngữ tự nhiên vốn được hình thành qua tiến trình tiến hóa như một công cụ giao tiếp nói trực tiếp, nơi hiểu lầm có thể được phát hiện và sửa ngay. Đây là nhược điểm lớn khi dùng nó để viết tài liệu kỹ thuật: trong văn bản viết, không có cơ chế tự nhiên nào để nhanh chóng phát hiện và sửa chữa sự mơ hồ, thiếu sót hay mâu thuẫn. Tìm ra những vấn đề đó sau khi đã viết rất tốn công, đặc biệt với những sản phẩm công việc dài.

Vấn đề này có thể được giảm thiểu một phần bằng cách viết tài liệu kỹ thuật một cách có ý thức, tuân theo các quy tắc đã được chứng minh và tránh các cạm bẫy đã biết.

Khi viết yêu cầu bằng ngôn ngữ tự nhiên, Kỹ sư Yêu cầu có thể tránh nhiều hiểu lầm tiềm ẩn bằng cách áp dụng một số quy tắc đơn giản:

• Viết câu ngắn gọn và có cấu trúc tốt. Nguyên tắc chung là diễn đạt một yêu cầu trong một câu bằng ngôn ngữ tự nhiên. Để đạt được cấu trúc tốt, Kỹ sư Yêu cầu nên sử dụng mẫu câu (Mục 3.3).
• Tạo ra các sản phẩm công việc có cấu trúc tổng thể tốt. Bên cạnh việc viết câu có cấu trúc tốt (xem trên), các sản phẩm công việc được viết bằng ngôn ngữ tự nhiên cũng nên có cấu trúc tốt ở tổng thể. Một cách đã được chứng minh là sử dụng cấu trúc phân cấp gồm các phần, chương, mục và tiểu mục, như thường thấy trong các sách kỹ thuật. Mẫu tài liệu (Mục 3.3) giúp đạt được cấu trúc tốt.
• Định nghĩa và sử dụng nhất quán một thuật ngữ đồng nhất. Tạo và sử dụng bảng thuật ngữ (Mục 3.5) là phương tiện cốt lõi để tránh hiểu lầm và không nhất quán về thuật ngữ.
• Tránh sử dụng các thuật ngữ mơ hồ hoặc không rõ ràng.
• Nắm rõ và tránh các cạm bẫy trong viết kỹ thuật (xem bên dưới).

Khi viết tài liệu kỹ thuật bằng ngôn ngữ tự nhiên, có một số cạm bẫy nổi tiếng cần tránh hoặc cần dùng cẩn thận (xem ví dụ [GoRu2003]).

Kỹ sư Yêu cầu cần tránh các lỗi sau khi viết yêu cầu:

• Mô tả không đầy đủ (Incomplete descriptions): Động từ trong ngôn ngữ tự nhiên thường có các tham số bắt buộc. Ví dụ, động từ “trao” cần ba tham số: ai trao, trao cái gì, và trao cho ai. Khi viết yêu cầu, tất cả tham số của động từ phải được điền đầy đủ — không được bỏ trống.
• Danh từ không cụ thể (Unspecific nouns): Các danh từ chung như “dữ liệu” hay “người dùng” mở ra quá nhiều cách hiểu khác nhau. Cần thay bằng danh từ cụ thể hơn, thêm tính từ xác định, hoặc tham chiếu đến một kiểu đã định nghĩa trong glossary.
• Điều kiện không đầy đủ (Incomplete conditions): Nhiều người chỉ mô tả trường hợp bình thường và bỏ qua các trường hợp ngoại lệ. Khi một hành động chỉ xảy ra trong điều kiện nhất định, phải nêu rõ điều kiện đó và đặc tả cả nhánh “thì” (then) lẫn nhánh “nếu không” (else).
• So sánh không đầy đủ (Incomplete comparisons): So sánh mà không có đối tượng tham chiếu (ví dụ: “nhanh hơn nhiều” mà không nói nhanh hơn cái gì) là mơ hồ. Trong kỹ thuật phải luôn ghi rõ ngưỡng so sánh — ví dụ: “nhanh hơn 0,1 ms”.

Ngoài ra có một số thứ mà Kỹ sư Yêu cầu cần dùng cẩn thận vì tiềm ẩn nguy cơ gây mơ hồ:

• Câu bị động (Passive voice): Câu bị động không có chủ thể rõ ràng, có thể che giấu ai là người chịu trách nhiệm thực hiện hành động — dẫn đến mô tả không đầy đủ.
• Lượng từ phổ quát (Universal quantifiers): Các từ như “tất cả”, “luôn luôn” hay “không bao giờ” ngụ ý không có ngoại lệ. Trong hệ thống kỹ thuật, điều này hiếm khi đúng tuyệt đối — cần kiểm tra xem có thực sự phổ quát hay chỉ là quy tắc chung có ngoại lệ. Thận trọng tương tự áp dụng với cấu trúc “hoặc là…” (either-or) vì chúng loại trừ mọi khả năng ngoài hai lựa chọn.
• Danh từ hóa (Nominalizations): Danh từ dẫn xuất từ động từ (ví dụ: “authentication” từ “to authenticate”) có thể che giấu các yêu cầu chưa được đặc tả. Ví dụ, câu “Chỉ sau khi xác thực thành công, hệ thống mới cấp quyền truy cập” ngầm giả định đã có quy trình xác thực — nhưng quy trình đó đã được đặc tả ở đâu? Cần kiểm tra xem các yêu cầu tương ứng đã được viết đầy đủ chưa.

Ngôn ngữ tự nhiên là phương tiện rất mạnh để viết yêu cầu. Để giảm thiểu những nhược điểm vốn có của ngôn ngữ tự nhiên trong tài liệu kỹ thuật, Kỹ sư Yêu cầu nên tuân theo các quy tắc viết đã được chứng minh và tránh các cạm bẫy nổi tiếng.

⚠️ TRAP — Điểm yếu của ngôn ngữ tự nhiên: Ngôn ngữ tự nhiên được tối ưu cho giao tiếp nói trực tiếp, KHÔNG cho tài liệu kỹ thuật viết. Trong tài liệu viết, không có cơ chế tự nhiên để phát hiện nhanh sự mơ hồ, thiếu sót, mâu thuẫn.

🔑 THUẬT NGỮ — Các cạm bẫy viết requirements:

• Incomplete descriptions (Mô tả không đầy đủ): chưa điền đủ placeholder của động từ
• Unspecific nouns (Danh từ không cụ thể): “the data”, “the user” — quá chung
• Incomplete conditions (Điều kiện không đầy đủ): chỉ mô tả trường hợp bình thường, bỏ exceptional cases
• Incomplete comparisons (So sánh không đầy đủ): so sánh thiếu reference object
• Passive voice (Câu bị động): che giấu ai chịu trách nhiệm
• Universal quantifiers (Lượng từ phổ quát): “all”, “always”, “never” — phải kiểm tra có thực sự phổ quát không
• Nominalizations (Danh từ hóa): danh từ từ động từ có thể che giấu requirements ẩn

---

3.3 Sản phẩm Công việc Dựa trên Mẫu

(Template-Based Work Products)

⚠️ Lưu ý dịch thuật: “Template” được dịch là “mẫu” trong phần này. Không nhầm với “biểu mẫu (form)” — đó là một loại mẫu cụ thể (form template / mẫu biểu). Ba loại mẫu trong RE: mẫu câu, mẫu biểu và mẫu tài liệu.

Mẫu (template) là phương tiện đã được chứng minh để viết các sản phẩm công việc tốt, có cấu trúc bằng ngôn ngữ tự nhiên — giúp giảm thiểu một số nhược điểm vốn có của ngôn ngữ tự nhiên trong viết kỹ thuật. Một mẫu cung cấp cấu trúc cú pháp định sẵn với các chỗ điền. Trong RE, chúng tôi phân biệt ba loại mẫu: mẫu câu (phrase template), mẫu biểu (form template) và mẫu tài liệu (document template).

3.3.1 Mẫu câu

(Phrase Templates)

Định nghĩa 3.2. Mẫu câu (Phrase template): Một mẫu cho cấu trúc cú pháp của một cụm từ diễn đạt một yêu cầu đơn lẻ hoặc một user story bằng ngôn ngữ tự nhiên.

Mẫu câu cung cấp một khung cú pháp với các chỗ điền (placeholders) — Kỹ sư Yêu cầu điền vào để tạo ra những câu đồng nhất, có cấu trúc tốt. Đây là thực hành tốt nhất khi viết yêu cầu đơn lẻ hoặc user story bằng ngôn ngữ tự nhiên.

3.3.1.1 Mẫu câu cho Yêu cầu Đơn lẻ

(Phrase Templates for Individual Requirements)

Nhiều mẫu câu để viết yêu cầu đơn lẻ đã được định nghĩa, ví dụ trong [ISO29148], [MWHN2009] và [Rupp2020]. Tiêu chuẩn ISO/IEC/IEEE 29148 [ISO29148] cung cấp một mẫu câu thống nhất duy nhất cho các yêu cầu đơn lẻ như sau:

[<Điều kiện>] <Chủ thể> <Hành động> <Các đối tượng> [<Ràng buộc>].

Ví dụ: Khi phát hiện thẻ hợp lệ, hệ thống phải hiển thị thông báo “Nhập mã PIN” trên màn hình hội thoại trong vòng 200 ms.

Khi dùng mẫu này, các quy ước sau về trợ động từ thường được áp dụng trong thực tế:

• Shall (phải) — biểu thị một yêu cầu bắt buộc.
• Should (nên) — biểu thị một yêu cầu không bắt buộc nhưng được mong muốn mạnh mẽ.
• May (có thể) — biểu thị một gợi ý.
• Will (sẽ), hoặc dùng động từ ở thì hiện tại không có trợ động từ trên — biểu thị một phát biểu thực tế, không được coi là yêu cầu.

Khi không có nghĩa đã được thống nhất cho các trợ động từ trong dự án, hoặc khi nghi ngờ, nên đưa các định nghĩa như trên vào đặc tả yêu cầu.

📌 ÔN THI — Auxiliary verbs (Trợ động từ)

• shall → yêu cầu BẮT BUỘC (mandatory)
• should → không bắt buộc nhưng MONG MUỐN MẠNH (strongly desired)
• may → GỢI Ý / tùy chọn (suggestion)
• will / động từ present tense → PHÁT BIỂU THỰC TẾ, không phải requirement

⚠️ TRAP: “Will” không phải requirement. Đề thi hay cho câu có “will” và hỏi đây có phải requirement không → KHÔNG.

EARS (Easy Approach to Requirements Syntax) [MWHN2009] cung cấp một bộ mẫu câu được điều chỉnh cho các tình huống khác nhau như mô tả dưới đây.

Yêu cầu phổ quát (Ubiquitous requirements) — luôn phải thỏa mãn:

The <system name> shall <system response>.

Yêu cầu theo sự kiện (Event-driven requirements) — được kích hoạt bởi một sự kiện bên ngoài:

WHEN <optional preconditions> <trigger> the <system name> shall <system response>.

Hành vi không mong muốn (Unwanted behavior) — mô tả các tình huống cần tránh:

IF <optional preconditions> <trigger>, THEN the <system name> shall <system response>.

Lưu ý: Mặc dù mẫu hành vi không mong muốn tương tự mẫu theo sự kiện, Mavin và cộng sự cung cấp mẫu riêng biệt cho loại này, với lý do rằng hành vi không mong muốn (chủ yếu do các sự kiện bất ngờ trong bối cảnh như lỗi, tấn công, hoặc những gì chưa ai nghĩ đến) là nguồn gốc chính của các thiếu sót trong RE.

Yêu cầu theo trạng thái (State-driven requirements) — chỉ áp dụng khi hệ thống đang ở một trạng thái nhất định:

WHILE <in a specific state> the <system name> shall <system response>.

Tính năng tùy chọn (Optional features) — chỉ áp dụng nếu một tính năng nào đó được tích hợp trong hệ thống:

WHERE <feature is included> the <system name> shall <system response>.

Trong thực tế, có thể cần những câu kết hợp các từ khóa WHEN, WHILE và WHERE để diễn đạt các yêu cầu phức tạp.

EARS được thiết kế chủ yếu cho việc đặc tả các hệ thống thực - ảo (cyber-physical systems). Tuy nhiên, nó cũng có thể được điều chỉnh cho các loại hệ thống khác.

📌 ÔN THI — EARS: 5 loại mẫu câu + từ khóa

Loại	Từ khóa	Tình huống
Ubiquitous	(không có)	Luôn phải đúng
Event-driven	WHEN	Kích hoạt bởi sự kiện bên ngoài
Unwanted behavior	IF…THEN	Tình huống cần tránh — nguồn thiếu sót lớn
State-driven	WHILE	Chỉ áp dụng khi hệ thống ở trạng thái nhất định
Optional features	WHERE	Chỉ áp dụng nếu tính năng được tích hợp

Trong thực tế có thể kết hợp WHEN + WHILE + WHERE để diễn đạt yêu cầu phức tạp.

3.3.1.2 Mẫu câu cho User Story

(Phrase Templates for User Stories)

Mẫu câu cổ điển để viết user story được giới thiệu bởi Cohn [Cohn2004]:

Với tư cách là <vai trò>, tôi muốn <yêu cầu> để <lợi ích>.

Ví dụ: “Với tư cách là người quản lý trực tiếp, tôi muốn thực hiện các truy vấn đột xuất vào hệ thống kế toán để có thể lập kế hoạch tài chính cho bộ phận của mình.”

Mặc dù Cohn đã chỉ định phần <lợi ích> của mẫu là tùy chọn, ngày nay thực hành tiêu chuẩn là phải đặc tả lợi ích cho mỗi user story.

Mỗi user story nên đi kèm với một tập hợp tiêu chí chấp nhận (acceptance criteria) — tức là các tiêu chí mà việc triển khai user story phải thỏa mãn để được các bên liên quan chấp nhận. Tiêu chí chấp nhận làm cho user story cụ thể hơn và ít mơ hồ hơn, giúp tránh các lỗi triển khai do hiểu lầm.

⚠️ TRAP — Benefit trong User Story: Cohn ban đầu định <lợi ích> là tùy chọn (optional). Nhưng ngày nay đây là bắt buộc (standard practice). Mỗi user story cũng phải kèm acceptance criteria.

3.3.2 Mẫu biểu

(Form Templates)

Định nghĩa 3.3. Mẫu biểu (Form template): Một mẫu cung cấp biểu mẫu (form) với các trường được xác định trước để điền vào.

Mẫu biểu được dùng để cấu trúc các sản phẩm công việc cỡ vừa như use case. Cockburn [Cock2001] giới thiệu mẫu biểu phổ biến cho use case; Lauesen [Laue2002] đề xuất mẫu tương tự cho mô tả tác vụ.

Bảng 3.2 trình bày một mẫu biểu đơn giản để viết use case. Mỗi bước trong luồng có thể tách thành hành động của tác nhân và phản hồi của hệ thống.

Bảng 3.2 — Mẫu biểu đơn giản để viết use case

Trường	Nội dung
Tên (Name)	<Một cụm động từ chủ động ngắn gọn>
Điều kiện tiên quyết (Precondition)	<Các điều kiện phải đúng khi use case được kích hoạt>
Điều kiện kết thúc thành công (Success end condition)	<Trạng thái sau khi use case hoàn thành thành công>
Điều kiện kết thúc thất bại (Failed end condition)	<Trạng thái sau khi use case thực thi thất bại>
Tác nhân chính (Primary actor)	<Tác nhân chính>
Các tác nhân khác (Other actors)	<Danh sách các tác nhân khác tham gia, nếu có>
Kích hoạt (Trigger)	<Sự kiện bắt đầu việc thực thi use case>
Luồng chính (Normal flow)	<Mô tả kịch bản thành công chính theo từng bước>
Luồng thay thế (Alternate flows)	<Mô tả các bước thay thế hoặc ngoại lệ, có tham chiếu đến các bước tương ứng trong luồng chính>
Phần mở rộng (Extensions)	<Các phần mở rộng của luồng chính (nếu có), kèm tham chiếu tới các bước được mở rộng>
Thông tin liên quan (Related information)	<Trường tuỳ chọn cho thông tin bổ sung như hiệu năng, tần suất, mối quan hệ với các use case khác,...>

Mẫu biểu cũng hữu ích để viết các yêu cầu chất lượng ở dạng có thể đo lường được [Gilb1988]. Bảng 3.3 cung cấp một mẫu biểu đơn giản cho yêu cầu chất lượng đo lường được, kèm theo ví dụ.

Bảng 3.3 — Mẫu biểu để đặc tả yêu cầu chất lượng đo lường được

Trường	Mẫu	Ví dụ
ID	<Số hiệu yêu cầu>	R137.2
Mục tiêu (Goal)	<Mục tiêu được mô tả định tính>	Xác nhận đặt phòng ngay lập tức
Thang đo (Scale)	<Thang đo dùng để đo yêu cầu>	Thời gian trôi qua tính bằng giây (thang tỉ lệ)
Cách đo (Meter)	<Quy trình dùng để đo yêu cầu>	Ghi dấu thời gian khi người dùng nhấn nút “Đặt phòng” và khi ứng dụng hiển thị xác nhận. Đo hiệu thời gian.
Mức tối thiểu (Minimum)	<Mức chất lượng tối thiểu phải đạt>	Ít hơn 5 giây trong ít nhất 95% trường hợp
Mức chấp nhận (OK range)	<Khoảng giá trị được coi là ổn và hướng tới>	Từ 0,5 đến 3 giây trong hơn 98% trường hợp
Mức mong muốn (Desired)	<Chất lượng đạt được trong trường hợp lý tưởng nhất>	Ít hơn 0,5 giây trong 100% trường hợp

3.3.3 Mẫu tài liệu

(Document Templates)

Định nghĩa 3.4. Mẫu tài liệu (Document template): Một mẫu cung cấp cấu trúc khung xương được xác định trước cho một tài liệu.

Mẫu tài liệu giúp cấu trúc có hệ thống các tài liệu yêu cầu — ví dụ như đặc tả yêu cầu hệ thống. Mẫu tài liệu RE có thể tìm thấy trong các tiêu chuẩn, ví dụ trong [ISO29148]. Mẫu Volere của Robertson và Robertson [RoRo2012], [Vole2026] cũng được sử dụng phổ biến trong thực tế. Khi một đặc tả yêu cầu được bao gồm trong tập hợp sản phẩm công việc mà khách hàng đã đặt hàng và sẽ thanh toán, khách hàng đó có thể yêu cầu sử dụng các mẫu tài liệu do khách hàng cung cấp. Hình 3.1 trình bày một ví dụ về mẫu tài liệu đơn giản cho đặc tả yêu cầu hệ thống.

Hình 3.1 — Mẫu tài liệu đặc tả yêu cầu hệ thống (ví dụ đơn giản)

Phần	Nội dung
Phần I: Giới thiệu (Introduction)	Mục đích hệ thống · Phạm vi phát triển · Các bên liên quan
Phần II: Tổng quan hệ thống (System overview)	Tầm nhìn & mục tiêu · Bối cảnh & ranh giới hệ thống · Cấu trúc tổng thể · Đặc điểm người dùng
Phần III: Yêu cầu hệ thống (System requirements)	Tổ chức phân cấp theo cấu trúc hệ thống. Mỗi hệ thống con/thành phần: Yêu cầu chức năng (cấu trúc & dữ liệu, chức năng & luồng, trạng thái & hành vi) · Yêu cầu chất lượng · Ràng buộc · Giao diện
Tài liệu tham khảo	—
Bảng thuật ngữ	(nếu không quản lý riêng)
Phụ lục	Giả định và phụ thuộc

3.3.4 Ưu điểm và Nhược điểm

(Advantages and Disadvantages)

Việc sử dụng mẫu khi viết các sản phẩm công việc RE bằng ngôn ngữ tự nhiên có những ưu điểm lớn. Mẫu cung cấp cấu trúc rõ ràng và có thể tái sử dụng cho các sản phẩm công việc, làm cho chúng trông đồng nhất và do đó cải thiện khả năng đọc hiểu. Mẫu cũng giúp ghi lại các thông tin quan trọng nhất và giảm thiểu các lỗi thiếu sót. Mặt khác, có một cạm bẫy tiềm ẩn khi Kỹ sư Yêu cầu sử dụng mẫu một cách máy móc, chỉ tập trung vào cấu trúc cú pháp thay vì vào nội dung, bỏ qua mọi thứ không khớp với mẫu.

Sử dụng mẫu khi viết các sản phẩm công việc RE bằng ngôn ngữ tự nhiên cải thiện chất lượng sản phẩm công việc, với điều kiện các mẫu không bị lạm dụng chỉ như một bài tập cú pháp.

📌 ÔN THI — Trade-off của Templates

• Ưu: cấu trúc rõ ràng, tái sử dụng được, đồng nhất, cải thiện readability, giảm thiếu sót
• Nhược / bẫy: RE Engineers dùng máy móc, tập trung vào cú pháp thay vì nội dung, bỏ qua mọi thứ không khớp template

🔑 THUẬT NGỮ: Phrase template (mẫu câu) · Form template (mẫu biểu) · Document template (mẫu tài liệu)

---

3.4 Sản phẩm Công việc Dựa trên Mô hình

(Model-Based Work Products)

Các yêu cầu được phát biểu bằng ngôn ngữ tự nhiên có thể dễ dàng đọc bởi những người biết ngôn ngữ đó. Ngôn ngữ tự nhiên có sự mơ hồ do tính không chính xác về mặt ngữ nghĩa của các từ, cụm từ và câu [Davi1993]. Sự không chính xác này có thể dẫn đến nhầm lẫn và thiếu sót trong các yêu cầu. Khi đọc các yêu cầu văn bản, mỗi người sẽ cố gắng giải thích chúng theo cách riêng của mình. Chúng ta thường cố gắng hình dung các yêu cầu đó trong đầu. Khi số lượng yêu cầu ở mức có thể quản lý được, vẫn có thể duy trì cái nhìn tổng quan về các yêu cầu văn bản. Khi số lượng yêu cầu văn bản trở nên “quá nhiều”, chúng ta mất đi cái nhìn tổng quan đó. Ngưỡng này khác nhau ở mỗi người. Số lượng yêu cầu văn bản không phải là lý do duy nhất khiến mất đi cái nhìn tổng quan — độ phức tạp của yêu cầu, mối quan hệ giữa các yêu cầu và mức độ trừu tượng cũng đóng góp vào điều này. Bạn có thể phải đọc các yêu cầu được phát biểu bằng ngôn ngữ tự nhiên nhiều lần trước khi có được bức tranh chính xác và đầy đủ mà hệ thống phải tuân thủ. Chúng ta có khả năng xử lý hạn chế đối với các yêu cầu bằng ngôn ngữ tự nhiên.

Ví dụ — Yêu cầu văn bản:

REQ001: Khách hàng đặt một đơn hàng
REQ002: Khách hàng thanh toán cho đơn hàng
REQ003: Nếu thanh toán thành công, thì đơn hàng được xử lý
REQ004: Nếu thanh toán thất bại, thì đơn hàng bị hủy
REQ005: Sau khi đơn hàng được xử lý, nó được giao đến khách hàng
REQ006: Khách hàng có thể hủy đơn hàng trước khi thanh toán

Hình 3.2 — So sánh yêu cầu văn bản và biểu diễn tương đương bằng biểu đồ hoạt động UML

Một mô hình (model) là sự biểu diễn trừu tượng của một phần thực tế đang tồn tại hoặc một phần thực tế cần được tạo ra. Hiển thị các yêu cầu (cũng) bằng một mô hình (hoặc hình ảnh) sẽ góp phần giúp người đọc nắm bắt các yêu cầu dễ hơn. Sự biểu diễn bằng sơ đồ của một mô hình như vậy được gọi là biểu đồ (diagram).

Một biểu đồ cho thấy ngay lập tức những gì hệ thống phải cung cấp — nhưng chỉ khi bạn đã thành thạo ngôn ngữ mô hình hóa. Rõ ràng là nếu bạn không hiểu biểu đồ — trong trường hợp này là biểu đồ hoạt động UML — thì hình ảnh đó sẽ không đóng góp vào việc hiểu yêu cầu tốt hơn.

Ở mục tiếp theo (3.4.1), khái niệm về mô hình yêu cầu được giải thích. Mô hình hóa các yêu cầu nghiệp vụ và mục tiêu được trình bày tại Mục 3.4.6. Một phương pháp quan trọng để mô tả sự phân định ranh giới hệ thống là mô hình bối cảnh. Các ví dụ về bối cảnh được trình bày tại Mục 3.4.2. Các Mục 3.4.3 đến 3.4.5 cung cấp một số ví dụ về ngôn ngữ mô hình hóa thường được sử dụng trong thực tế kỹ nghệ hệ thống.

3.4.1 Vai trò của Mô hình trong Kỹ nghệ Yêu cầu

(The Role of Models in Requirements Engineering)

Giống như bất kỳ ngôn ngữ nào, một ngôn ngữ mô hình hóa bao gồm các quy tắc ngữ pháp và mô tả ý nghĩa của các cấu trúc ngôn ngữ, xem Mục 3.4.1.1. Mặc dù một mô hình là sự biểu diễn trực quan của thực tế, các quy tắc ngôn ngữ quan trọng để hiểu mô hình và các sắc thái trong mô hình.

Không phải lúc nào cũng hiệu quả hoặc hữu ích để tóm tắt các yêu cầu bằng mô hình. Bằng cách hiểu các thuộc tính của một mô hình, chúng ta có thể xác định tốt hơn khi nào có thể áp dụng mô hình nào, xem Mục 3.4.1.2.

Cũng giống như ngôn ngữ tự nhiên có ưu và nhược điểm trong việc diễn đạt yêu cầu, các mô hình cũng vậy. Nếu chúng ta quan sát những thực tế này khi áp dụng mô hình, chúng ta có thể xác định tốt hơn giá trị gia tăng của việc áp dụng mô hình “đúng”. Điều này được thảo luận tại Mục 3.4.1.3.

Nhiều mô hình đã được chuẩn hóa và được sử dụng trong nhiều lĩnh vực ứng dụng khác nhau, xem Mục 3.4.1.4. Ví dụ như trong xây dựng nhà, kiến trúc sư sử dụng mô hình chuẩn hóa để mô tả tòa nhà — một ví dụ là mô hình thông tin tòa nhà BIM (Building Information Model) [ISO19650], mô hình hóa các yếu tố cần thiết để lập kế hoạch, xây dựng và quản lý các công trình. Một ví dụ khác là điện tử, nơi sơ đồ điện được chuẩn hóa để các chuyên gia có thể hiểu, tính toán và thực hiện các mạch điện.

Để xác định liệu một biểu đồ có được áp dụng đúng hay không, chúng ta có thể đánh giá dựa trên các tiêu chí chất lượng của biểu đồ. Các tiêu chí này được mô tả tại Mục 3.4.1.5.

3.4.1.1 Cú pháp và Ngữ nghĩa

(Syntax and Semantics)

Nếu bạn nghĩ về một ngôn ngữ tự nhiên — ví dụ như ngôn ngữ mẹ đẻ của bạn — nó được định nghĩa bởi ngữ pháp và ngữ nghĩa của nó.

Ngữ pháp mô tả các phần tử (từ và câu) và các quy tắc mà ngôn ngữ phải tuân thủ. Trong một ngôn ngữ mô hình hóa, điều này được gọi là cú pháp (syntax) (xem Hình 3.3). Cú pháp mô tả các phần tử ký pháp (ký hiệu) được sử dụng trong ngôn ngữ và cách các phần tử ký pháp này có thể được kết hợp với nhau.

Ngữ nghĩa (semantics) định nghĩa ý nghĩa của các phần tử ký pháp và ý nghĩa của sự kết hợp các phần tử. Hiểu được ý nghĩa của các phần tử ký pháp là điều cơ bản để ngăn ngừa rủi ro mô hình bị hiểu sai.

Hình 3.3 — Ví dụ về cú pháp (syntax) và ngữ nghĩa (semantics) của biểu đồ Use Case UML

3.4.1.2 Thuộc tính của Mô hình

(Properties of a Model)

Một mô hình yêu cầu là một mô hình khái niệm mô tả các yêu cầu đối với hệ thống cần phát triển. Mô hình cũng được dùng để biểu diễn tình huống hiện tại nhằm hiểu, phân tích và khám phá các vấn đề hiện tại. Ở đây, “khái niệm” có nghĩa là thực tế được rút gọn về bản chất cốt lõi của nó — mô hình có mức độ trừu tượng cao và rút gọn thực tế về những gì liên quan ở mức chung đó.

Một ngôn ngữ mô hình hóa khái niệm có thể được chuẩn hóa (quốc tế) và khi đó được gọi là ngôn ngữ mô hình hóa chính thức (formal modeling language). Một ví dụ là ngôn ngữ mô hình hóa được sử dụng rộng rãi UML (Unified Modeling Language).

Một mô hình có một số thuộc tính sẽ được trình bày chi tiết hơn trong các mục sau:

• Một mô hình được tạo ra cho một mục đích cụ thể.
• Một mô hình cung cấp sự biểu diễn của thực tế.
• Một mô hình được dùng để rút gọn thông tin để chúng ta có thể hiểu thực tế tốt hơn hoặc tập trung vào một phần của thực tế.

Một mô hình là sự biểu diễn trừu tượng của một phần thực tế đang tồn tại hoặc cần được tạo ra. Phần thực tế được mô hình hóa được gọi là đối tượng gốc (original). Quá trình mô tả đối tượng gốc có thể theo hai hướng:

• Mô hình hóa mô tả (Descriptive modeling): Mô hình hóa thực tế hiện tại (as-is) — phản ánh các yêu cầu đang được đáp ứng. Nếu chưa có mô hình cho tình huống hiện tại, thì đây là kết quả của quá trình phân tích.
• Mô hình hóa quy định (Prescriptive modeling): Mô hình hóa thực tế tương lai mong muốn (to-be) — chỉ ra những yêu cầu sẽ là mới, đã thay đổi, hoặc không còn cần thiết.

Khi một mô hình có quá nhiều chi tiết, nó sẽ khó nắm bắt. Giải pháp là lọc bỏ thông tin không liên quan, chỉ giữ lại những gì phục vụ cho mục đích cụ thể của mô hình. Việc lọc bỏ có thể thực hiện qua hai cách:

• Cô đọng/Tổng hợp (Aggregation): Gộp nhiều chi tiết thành thông tin trừu tượng hơn, ngắn gọn hơn.
• Lọc chọn (Selection): Chỉ hiển thị phần thông tin liên quan đến chủ đề đang xét, bỏ qua phần còn lại.

Cả hai cách có thể kết hợp. Lưu ý: nếu lọc bỏ quá nhiều thì mô hình sẽ phản ánh sai lệch thực tế — cần cân nhắc mức độ hợp lý.

Một mô hình là sự biểu diễn của thực tế và mỗi mô hình biểu diễn những khía cạnh nhất định của thực tế. Ví dụ, một bản vẽ xây dựng thể hiện sự phân chia không gian trong một tòa nhà và một sơ đồ điện thể hiện cách đấu dây của mạch điện. Cả hai mô hình đều biểu diễn tòa nhà cho một mục đích cụ thể. Điều này làm rõ ngay lập tức rằng một mô hình cụ thể chỉ có thể được sử dụng nếu nó phù hợp với mục đích mà mô hình được tạo ra.

3.4.1.3 Ưu điểm và Nhược điểm của Mô hình hóa Yêu cầu

(Advantages and Disadvantages of Modeling Requirements)

So với ngôn ngữ tự nhiên, mô hình có các ưu điểm sau:

• Dễ nắm bắt và dễ nhớ hơn. Một hình ảnh nói lên hơn ngàn chữ. Tuy nhiên, mô hình không tự giải thích được — cần có chú giải, ví dụ và kịch bản đi kèm.
• Giảm tải nhận thức. Vì mô hình tập trung vào một khía cạnh cụ thể và lọc bỏ thông tin không liên quan, người đọc cần ít nỗ lực hơn để hiểu yêu cầu.
• Giảm nguy cơ mơ hồ và thiếu sót. Ngôn ngữ mô hình hóa có cú pháp hạn chế và quy tắc chặt chẽ hơn ngôn ngữ tự nhiên — nên ít bị hiểu nhầm hơn.
• Tiềm năng tự động hóa cao hơn. Tính chính xác về mặt hình thức của ngôn ngữ mô hình hóa giúp nó phù hợp hơn cho phân tích và xử lý tự động.

Mô hình cũng có các hạn chế:

• Khó duy trì nhất quán giữa nhiều mô hình. Khi nhiều mô hình mô tả các khía cạnh khác nhau của yêu cầu, giữ chúng nhất quán với nhau đòi hỏi kỷ luật cao.
• Cần hiểu nhiều mô hình để có cái nhìn toàn diện. Không có mô hình nào một mình đủ — người đọc cần tích hợp thông tin từ tất cả các mô hình liên quan.
• Chủ yếu phục vụ yêu cầu chức năng. Yêu cầu chất lượng và ràng buộc khó — thậm chí không thể — biểu diễn trong mô hình. Chúng cần được bổ sung bằng ngôn ngữ tự nhiên.
• Cú pháp hạn chế không cho phép biểu diễn mọi thông tin. Những yêu cầu không mô hình hóa được phải ghi lại dưới dạng văn bản hoặc sản phẩm công việc riêng.

Do đó, các mô hình yêu cầu phải luôn đi kèm với ngôn ngữ tự nhiên [Davi1995].

📌 ÔN THI — Models phải đi kèm Natural Language Models tập trung chủ yếu vào functional requirements. Quality requirements và constraints bị hạn chế trong models → phải supplement bằng ngôn ngữ tự nhiên hoặc work product riêng.

4 cách áp dụng models:

1. Đặc tả (thay thế) textual requirements
2. Phân tách thực tế phức tạp thành các khía cạnh rõ ràng
3. Diễn giải lại (paraphrase) requirements văn bản để cải thiện hiểu biết
4. Xác nhận (validate) requirements văn bản để phát hiện thiếu sót/mơ hồ/mâu thuẫn

🔑 THUẬT NGỮ: Descriptive modeling (mô hình hóa mô tả) = thực tế hiện tại (as-is). Prescriptive modeling (mô hình hóa quy định) = thực tế tương lai mong muốn (to-be).

3.4.1.4 Ứng dụng của Mô hình Yêu cầu

(Application of Requirements Models)

Như đã chỉ ra trong các mục trước, có các mô hình phổ biến cho nhiều bối cảnh khác nhau. Ví dụ, trong kiến trúc, có bản vẽ xây dựng, sơ đồ đường ống, sơ đồ điện, v.v. để diễn đạt các thông số kỹ thuật của một tòa nhà. Trong các bối cảnh khác — ví dụ như phát triển phần mềm — có các ngôn ngữ mô hình hóa hữu ích trong các loại bối cảnh đó. Một khía cạnh quan trọng trong việc áp dụng mô hình là sử dụng các mô hình phổ biến trong bối cảnh hoặc đã được phát triển đặc biệt cho một bối cảnh cụ thể.

Nhiều ngôn ngữ mô hình hóa — ví dụ như UML [OMG2017] hoặc BPMN [OMG2013] — đã được chuẩn hóa. Khi các yêu cầu được đặc tả bằng ngôn ngữ mô hình hóa không chuẩn, cú pháp và ngữ nghĩa của ngôn ngữ đó phải được giải thích cho người đọc — ví dụ: thông qua chú giải (legend).

Mô hình được sử dụng để mô tả các yêu cầu từ một góc nhìn nhất định. Trong phát triển hệ thống, các yêu cầu chức năng được phân loại theo các góc nhìn sau (xem thêm Mục 3.1.4):

• Cấu trúc và dữ liệu (Structure and data): Các mô hình tập trung vào các thuộc tính cấu trúc tĩnh của hệ thống hoặc miền.
• Chức năng và luồng (Function and flow): Các mô hình tập trung vào chuỗi hành động cần thiết để tạo ra kết quả được yêu cầu từ dữ liệu đầu vào, hoặc các hành động cần thiết để thực hiện một quy trình (nghiệp vụ), bao gồm luồng kiểm soát và dữ liệu giữa các hành động và ai chịu trách nhiệm cho hành động nào.
• Trạng thái và hành vi (State and behavior): Các mô hình tập trung vào hành vi của hệ thống hoặc vòng đời của các đối tượng nghiệp vụ theo dạng phản ứng phụ thuộc trạng thái với các sự kiện, hoặc sự tương tác động học giữa các thành phần.

Bản chất của hệ thống đang được sửa đổi hoặc xây dựng định hướng các mô hình cần sử dụng. Ví dụ, nếu bản chất của hệ thống là xử lý thông tin và các mối quan hệ, thì dự kiến sẽ có khá nhiều yêu cầu chức năng mô tả thông tin và các mối quan hệ này. Do đó, chúng ta sử dụng ngôn ngữ mô hình hóa phù hợp, thích hợp để mô hình hóa dữ liệu và cấu trúc của nó.

Một hệ thống tự nhiên sẽ bao gồm sự kết hợp của các góc nhìn trên. Do đó, một hệ thống cần được mô hình hóa từ nhiều góc nhìn. Các Mục 3.4.3 đến 3.4.5 trình bày chi tiết hơn các mô hình khác nhau cho mỗi góc nhìn.

Trước khi các yêu cầu được khai thác và tài liệu hóa — ví dụ với mô hình — cần thực hiện kiểm kê các mục tiêu và bối cảnh. Những điều này cũng có thể được mô hình hóa, xem Mục 3.4.6 và Mục 3.4.2 tương ứng.

Áp dụng mô hình giúp chúng ta chủ yếu theo các cách sau:

• Đặc tả (chủ yếu là chức năng) các yêu cầu một phần hoặc hoàn toàn, như một phương tiện thay thế cho các yêu cầu được biểu diễn bằng văn bản.
• Phân tách thực tế phức tạp thành các khía cạnh được xác định rõ ràng và bổ sung cho nhau; mỗi khía cạnh được biểu diễn bởi một mô hình cụ thể, giúp chúng ta nắm bắt được sự phức tạp của thực tế.
• Diễn giải lại các yêu cầu được biểu diễn bằng văn bản để cải thiện khả năng hiểu, đặc biệt là về mối quan hệ giữa chúng.
• Xác nhận (validate) các yêu cầu được biểu diễn bằng văn bản với mục tiêu phát hiện thiếu sót, mơ hồ và không nhất quán.

Mô hình hóa yêu cầu cũng giúp cấu trúc và phân tích kiến thức. Bạn có thể sử dụng biểu đồ để cấu trúc suy nghĩ của chính mình để có sự hiểu biết tốt hơn về hệ thống và bối cảnh của nó.

3.4.1.5 Khía cạnh Chất lượng của Mô hình Yêu cầu

(Quality Aspects of a Requirements Model)

Đây là mục bổ sung — sẽ không có câu hỏi thi CPRE Foundation Level về nội dung này.

⚠️ TRAP — Mục 3.4.1.5 KHÔNG có trong đề thi CPRE Foundation Level. Syntactic quality, Semantic quality, Pragmatic quality của model → chỉ đọc để biết, không cần thuộc công thức hay ví dụ.

Phần lớn các mô hình yêu cầu là các biểu đồ hoặc biểu diễn đồ họa. Chất lượng của mô hình yêu cầu được xác định bởi chất lượng của các biểu đồ riêng lẻ và mối quan hệ giữa chúng. Đến lượt mình, chất lượng của các biểu đồ riêng lẻ được xác định bởi chất lượng của các phần tử mô hình trong các biểu đồ.

Chất lượng của các mô hình yêu cầu và phần tử mô hình có thể được đánh giá dựa trên ba tiêu chí [LiSS1994]:

Chất lượng cú pháp (Syntactic quality) thể hiện mức độ tuân thủ các đặc tả cú pháp của từng phần tử mô hình. Ví dụ, nếu mô hình lớp chứa ký hiệu sai cú pháp hoặc dùng ký hiệu không đúng mục đích, người đọc — như người kiểm thử — có thể hiểu sai thông tin trong mô hình, dẫn đến các test case không phù hợp. Các công cụ mô hình hóa thường hỗ trợ kiểm tra chất lượng cú pháp tự động.

Chất lượng ngữ nghĩa (Semantic quality) thể hiện mức độ mà mô hình biểu diễn chính xác và đầy đủ thực tế. Nếu ký hiệu mô hình có nhiều nghĩa hoặc bị áp dụng sai, mô hình sẽ bị giải thích sai — tương tự như từ ngữ mơ hồ trong ngôn ngữ tự nhiên.

Chất lượng thực dụng (Pragmatic quality) thể hiện mức độ phù hợp của mô hình với mục đích dự định — tức là mức chi tiết, mức trừu tượng, và loại mô hình có phù hợp với nhu cầu của người đọc hay không. Có thể đánh giá bằng cách gửi phiên bản trung gian của mô hình cho các bên liên quan liên quan để xác nhận.

Khi xác nhận yêu cầu, chất lượng của các biểu đồ mô hình cũng được đánh giá để đảm bảo chúng phục vụ đúng mục đích.

3.4.1.6 Tận dụng Cả Hai Thế giới

(Best of Both Worlds)

Như đã giải thích trong mục trước, các yêu cầu được biểu diễn bằng văn bản hoặc bằng hình ảnh/đồ họa (tức là qua mô hình yêu cầu) đều có ưu và nhược điểm riêng. Bằng cách sử dụng kết hợp cả hai hình thức biểu diễn văn bản và đồ họa của yêu cầu, chúng ta có thể khai thác sức mạnh và lợi ích của cả hai hình thức biểu diễn.

Bổ sung mô hình bằng các yêu cầu văn bản giúp thêm ý nghĩa cho mô hình. Một kết hợp hữu ích khác là liên kết các yêu cầu chất lượng và ràng buộc với một mô hình hoặc một phần tử mô hình cụ thể — điều này cung cấp bức tranh hoàn chỉnh hơn về các yêu cầu cụ thể đó.

Sử dụng mô hình cũng có thể hỗ trợ các yêu cầu văn bản. Thêm mô hình và hình ảnh vào yêu cầu văn bản hỗ trợ các yêu cầu này để có sự hiểu biết và cái nhìn tổng quan tốt hơn.

📌 ÔN THI — “Best of Both Worlds”: Kết hợp text + model: (a) thêm textual req vào model → model có thêm ý nghĩa; (b) liên kết quality req & constraints vào model element cụ thể → bức tranh hoàn chỉnh hơn; (c) thêm model vào text → cải thiện overview và hiểu biết.

⚠️ TRAP — UML Use Case Diagram vs DFD: Trong DFD, hệ thống = hộp đen (black box). Trong UML Use Case Diagram, hiển thị các chức năng (use cases) bên trong hệ thống. Association trong use case KHÔNG biểu diễn data flow — chỉ thể hiện actor nhận lợi ích từ use case.

3.4.2 Mô hình hóa Bối cảnh Hệ thống

(Modeling System Context)

Chương 2, Nguyên tắc 4 giới thiệu khái niệm rằng các yêu cầu không bao giờ xuất hiện độc lập và bối cảnh hệ thống — như các hệ thống hiện có, quy trình và người dùng — cần được xem xét khi xác định các yêu cầu cho hệ thống mới hoặc đang thay đổi. Bối cảnh hệ thống được mô tả bằng mô hình vì điều này sẽ cung cấp cái nhìn tổng quan và sâu sắc hơn về bối cảnh hệ thống. Bối cảnh hệ thống đơn giản cũng có thể được ghi lại bằng, ví dụ như ngôn ngữ tự nhiên hoặc ở dạng bảng, nhưng cách này không được ưu tiên.

Mô hình bối cảnh xác định sự nhúng về cấu trúc của hệ thống vào môi trường của nó, cùng với các tương tác với người dùng hệ thống cũng như với các hệ thống mới hoặc hiện có khác trong bối cảnh liên quan. Mô hình bối cảnh không phải là mô tả đồ họa của các yêu cầu mà được dùng để làm lộ ra một số nguồn của các yêu cầu. Hình 3.4 cung cấp một ví dụ trừu tượng về một hệ thống và môi trường của nó, với các giao diện đến người dùng hệ thống và các giao diện đến các hệ thống khác.

Hình 3.4 — Ví dụ trừu tượng về hệ thống nhúng trong bối cảnh, với ranh giới bối cảnh, ranh giới hệ thống, người dùng và các hệ thống liên quan

Do đó, biểu đồ bối cảnh giúp xác định giao diện người dùng cũng như giao diện hệ thống. Nếu hệ thống tương tác với người dùng, các giao diện người dùng phải được đặc tả trong một bước sau trong RE.

Nếu hệ thống tương tác với các hệ thống khác, các giao diện đến các hệ thống này phải được định nghĩa chi tiết hơn trong một bước sau. Các giao diện đến các hệ thống khác có thể đã tồn tại hoặc cần được phát triển hoặc sửa đổi.

Mặc dù không có ngôn ngữ mô hình hóa chuẩn hóa cho mô hình bối cảnh, mô hình bối cảnh thường được biểu diễn bằng:

• Biểu đồ luồng dữ liệu (Data Flow Diagram) từ phân tích có cấu trúc [DeMa1978]
• Biểu đồ Use Case UML [OMG2017]

Lưu ý: Mô hình Use Case UML bao gồm hai phần tử: biểu đồ use case UML (xem Hình 3.6) và đặc tả use case (Mục 3.4.2.2). Chương này tập trung vào mô hình hóa bằng biểu đồ use case UML.

• Biểu đồ hộp-và-đường tùy chỉnh [Glin2019]

Trong miền kỹ nghệ hệ thống, các biểu đồ định nghĩa khối SysML [OMG2018] có thể được điều chỉnh để biểu diễn mô hình bối cảnh bằng cách sử dụng các khối có khuôn rập (stereotyped blocks) cho hệ thống và các tác nhân.

Trong hai mục con tiếp theo, chúng tôi giới thiệu ký pháp của biểu đồ luồng dữ liệu (DFD) và biểu đồ use case UML để mô hình hóa bối cảnh của một hệ thống. Hai ví dụ này không mô tả bối cảnh đầy đủ mà nhấn mạnh bối cảnh từ một góc nhìn cụ thể.

3.4.2.1 Biểu đồ Luồng Dữ liệu

(Data Flow Diagram)

Bối cảnh hệ thống có thể được nhìn từ các góc độ khác nhau. Phân tích có cấu trúc của hệ thống [DeMa1978] đề cập đến biểu đồ bối cảnh (context diagram). Biểu đồ này là một biểu đồ luồng dữ liệu (DFD) đặc biệt trong đó hệ thống được biểu diễn bởi một tiến trình (hệ thống). Hình 3.5 trình bày một ví dụ về biểu đồ bối cảnh.

Hình 3.5 — Ví dụ biểu đồ bối cảnh (DFD) của hệ thống đặt sách, với các thực thể ngoài: Customer, Printer, Financial administration

Hệ thống được đặt ở vị trí trung tâm trong mô hình. Nó có tên rõ ràng để người đọc biết hệ thống nào đang được xem xét.

Các hình chữ nhật xung quanh hệ thống là các thực thể ngoài (terminator / external entity): khách hàng, máy in và bộ quản lý tài chính. Thực thể ngoài cung cấp thông tin hoặc dịch vụ cho hệ thống được gọi là nguồn (source). Thực thể ngoài nhận thông tin hoặc dịch vụ từ hệ thống được gọi là đích (sink). Một thực thể ngoài có thể đóng cả hai vai tùy thuộc vào dữ liệu được cung cấp hoặc nhận, ví dụ như khách hàng trong ví dụ trên.

Các mũi tên trong ví dụ cho thấy thông tin từ các đầu cuối chảy vào hệ thống (nguồn) và từ hệ thống ra các đầu cuối (đích). Các mũi tên được đặt tên logic mô tả thông tin nào được truyền. Các chi tiết không liên quan bị bỏ qua ở cấp độ biểu đồ bối cảnh. Ví dụ, luồng thông tin giữa khách hàng và hệ thống chứa dữ liệu khách hàng. Những thông tin nào (tên, ngày sinh, địa chỉ email, số điện thoại, địa chỉ giao hàng, địa chỉ thanh toán, v.v.) cấu thành dữ liệu khách hàng chưa cần phải liên quan ở mức trừu tượng này.

Luồng thông tin có thể bao gồm các đối tượng hữu hình (vật liệu) và vô hình (thông tin). Ngoài ra, ở cấp độ khái niệm này, chưa có tham chiếu về cách thức — email, website, biểu mẫu, v.v. — thông tin được cung cấp.

Thêm các chi tiết bổ sung vào biểu đồ bối cảnh có thể làm rõ hơn cho các bên liên quan liên quan và có thể giúp cải thiện sự hiểu biết chung. Các chi tiết này cần được xây dựng cho từng tình huống cụ thể.

Sử dụng biểu đồ luồng dữ liệu để mô hình hóa bối cảnh của hệ thống cung cấp một số hiểu biết về các tương tác của hệ thống với môi trường, ví dụ:

• Các giao diện với người, bộ phận, tổ chức và các hệ thống khác trong môi trường.
• Các đối tượng hữu hình và vô hình mà hệ thống nhận từ môi trường.
• Các đối tượng hữu hình và vô hình được tạo ra bởi hệ thống và cung cấp cho môi trường.

Biểu đồ luồng dữ liệu chỉ ra rõ ràng ranh giới giữa hệ thống và môi trường. Người dùng và các hệ thống liên quan trong môi trường được xác định trong quá trình khai thác yêu cầu (Mục 4.1). Biểu đồ bối cảnh DFD có thể giúp cấu trúc bối cảnh để đạt được sự hiểu biết chung về bối cảnh hệ thống và ranh giới hệ thống.

3.4.2.2 Biểu đồ Use Case UML

(UML Use Case Diagram)

Một góc nhìn khác về bối cảnh của hệ thống có thể được tiếp cận từ góc độ chức năng. Biểu đồ use case UML là cách tiếp cận phổ biến để mô hình hóa các khía cạnh chức năng của hệ thống và ranh giới hệ thống, cùng với các tương tác của hệ thống với người dùng và các hệ thống khác. Use case cung cấp cách dễ dàng để mô tả có hệ thống các chức năng khác nhau trong phạm vi đã định từ góc nhìn người dùng. Điều này khác với biểu đồ bối cảnh DFD, nơi hệ thống được biểu diễn như một hộp đen lớn.

Use case được đề xuất lần đầu tiên như một phương pháp tài liệu hóa các chức năng của hệ thống trong [Jaco1992]. Mô hình use case UML bao gồm các biểu đồ use case đi kèm với các đặc tả use case văn bản (xem Mục 3.3.2). Một đặc tả use case đặc tả chi tiết từng use case bằng cách, ví dụ, mô tả các hoạt động có thể có của use case, logic xử lý của nó, và các điều kiện tiên quyết và hậu điều kiện của việc thực thi use case. Đặc tả use case về cơ bản là dạng văn bản — ví dụ: thông qua các mẫu use case theo khuyến nghị trong [Cock2001].

Như đã đề cập, biểu đồ use case UML hiển thị các chức năng (use case) từ góc độ của người dùng trực tiếp và các hệ thống khác tương tác với hệ thống đang được xem xét. Tên của use case thường bao gồm một động từ và một danh từ. Điều này đưa ra mô tả ngắn gọn về chức năng mà hệ thống cung cấp, như thể hiện trong ví dụ ở Hình 3.6.

Hình 3.6 — Ví dụ biểu đồ Use Case UML với ranh giới hệ thống, các use case (Place order, Check order status, Update delivery status) và các actor (Customer, Printer)

Các tác nhân (actors) là người dùng trực tiếp hoặc hệ thống tương tác với hệ thống đang được xem xét. Tác nhân (người dùng hoặc hệ thống) kích hoạt use case sẽ nhận được lợi ích mà use case mang lại (ví dụ: hiển thị trạng thái đơn hàng cho khách hàng). Liên kết (association) nối tác nhân với use case liên quan nhưng nó không ghi lại hướng hay luồng dữ liệu nào (như được thực hiện trong DFD); nó chỉ thể hiện rằng tác nhân nhận được lợi ích từ use case.

Biểu đồ use case UML mô tả chức năng mà hệ thống cung cấp cho môi trường của nó. Sự phân tách giữa chức năng trong hệ thống và các tác nhân trong bối cảnh được trực quan hóa bằng ranh giới hệ thống (hình chữ nhật bao quanh các use case, ví dụ: “hệ thống đặt sách”). Biểu đồ use case hỗ trợ làm rõ ranh giới hệ thống và kiểm tra xem phạm vi chức năng của hệ thống ở cấp cao có được bao phủ đủ hay không.

Mỗi use case cũng bao gồm một đặc tả use case chi tiết, tài liệu hóa các điều kiện tiên quyết, kích hoạt, hành động, điều kiện hậu, tác nhân, v.v. Use case thường được mô tả bằng một mẫu biểu (Mục 3.3.2). Nếu các kịch bản của một use case trở nên phức tạp hoặc lớn, khuyến nghị là trực quan hóa các kịch bản bằng biểu đồ hoạt động UML, xem Mục 3.4.4.1. Đặc tả chi tiết của use case không phải là một phần của mô hình hóa bối cảnh và có thể được xây dựng vào thời điểm sau, khi thông tin này trở nên liên quan.

3.4.3 Mô hình hóa Cấu trúc và Dữ liệu

(Modeling Structure and Data)

Đối với các yêu cầu chức năng từ góc độ đối tượng nghiệp vụ (xem Mục 3.1.4), có nhiều mô hình dữ liệu khác nhau. Một đối tượng (nghiệp vụ) có thể là đối tượng hữu hình hoặc vô hình, chẳng hạn như xe đạp, bàn đạp, chuông xe đạp, nhưng cũng có thể là một yêu cầu đào tạo, giỏ hàng với các sản phẩm kỹ thuật số, v.v. Một đối tượng (nghiệp vụ) là “một thứ gì đó” trong thế giới thực. Một số (hoặc có thể tất cả) trong số các đối tượng (nghiệp vụ) này được sử dụng bởi hệ thống đang được xem xét. Hệ thống sử dụng các đối tượng này làm đầu vào để xử lý, để lưu trữ bền vững, và/hoặc để cung cấp đầu ra. Mô hình dữ liệu được dùng để mô tả các đối tượng (nghiệp vụ) mà hệ thống cần biết.

Các loại biểu đồ này mô hình hóa đối tượng, thuộc tính của đối tượng và các mối quan hệ giữa các đối tượng. Để đơn giản, chúng tôi gọi là mô hình hóa cấu trúc và dữ liệu — tuy nhiên, điều này biểu diễn các cấu trúc thông tin giữa các đối tượng (nghiệp vụ) trong thế giới thực.

Một số mô hình phổ biến để biểu diễn cấu trúc và dữ liệu bao gồm:

• Biểu đồ quan hệ thực thể ERD (Entity Relationship Diagram) [Chen1976]
• Biểu đồ lớp UML [OMG2017]. Xem Mục 3.4.3.1
• Biểu đồ định nghĩa khối SysML (SysML Block Definition Diagrams) [OMG2018]. Xem Mục 3.4.6.2

Để giải thích khái niệm mô hình hóa cấu trúc và dữ liệu, chương này sử dụng biểu đồ lớp UML làm ví dụ. UML, viết tắt của Unified Modeling Language, bao gồm một tập hợp tích hợp các biểu đồ. Tập hợp biểu đồ này là sự tập hợp của các thực hành kỹ nghệ tốt nhất và đã được chứng minh thành công trong mô hình hóa các hệ thống phức tạp và lớn. UML được thiết kế bởi Grady Booch, James Rumbaugh và Ivar Jacobson vào những năm 1990 và đã là ngôn ngữ mô hình hóa được chuẩn hóa từ năm 1997. Nếu cần chiều sâu hơn hoặc muốn dùng mô hình khác, hãy đọc tài liệu tham chiếu và thực hành với ngôn ngữ mô hình hóa mong muốn.

3.4.3.1 Biểu đồ Lớp UML

(UML Class Diagrams)

UML là một tập hợp các mô hình khác nhau có thể được sử dụng để mô tả một hệ thống. Một trong số đó là biểu đồ lớp. Một biểu đồ lớp mô tả một tập hợp các lớp và các mối liên kết giữa chúng. Chúng tôi chỉ thảo luận về các phần tử ký pháp phổ biến và đơn giản của mô hình này. Nếu cần chiều sâu hơn, chúng tôi giới thiệu tài liệu hoặc CPRE Advanced Level Requirements Modeling.

Hình 3.7 — Ký pháp cơ bản của biểu đồ lớp UML: class, attribute, association, multiplicity và role

Trong mô hình lớp, bạn sẽ tìm thấy các khái niệm và thuật ngữ liên quan trong miền. Các khái niệm này bao gồm định nghĩa rõ ràng được đưa vào bảng thuật ngữ. Với việc sử dụng mô hình dữ liệu, bảng thuật ngữ được mở rộng thêm thông tin về cấu trúc và sự gắn kết của các thuật ngữ và khái niệm. Định nghĩa rõ ràng và sự gắn kết của các thuật ngữ được sử dụng giúp ngăn ngừa giao tiếp sai về vấn đề đang được xem xét.

Hình 3.8 trình bày một mô hình đơn giản của hệ thống đặt sách (xem các ví dụ về bối cảnh tại Mục 3.4.2). Thông tin tĩnh mà hệ thống cần để thực hiện chức năng — đặt sách — được mô hình hóa.

Hình 3.8 — Biểu đồ lớp UML: Customer đặt Order (1.. orders), Order chứa Book*

Một khách hàng đặt một cuốn sách và do đó thông tin được lưu trữ bền vững cho các lớp Khách hàng (Customer), Đơn hàng (Order) và Sách (Book). Khách hàng có thể đặt một đơn hàng và do đó tồn tại một mối quan hệ (liên kết) giữa Khách hàng và Đơn hàng. Khách hàng có thể đặt nhiều đơn hàng theo thời gian và chỉ trở thành khách hàng khi họ đặt đơn. Thông tin này xác định hệ số đa lượng: 1 khách hàng đặt 1 hoặc nhiều đơn hàng.

Việc khách hàng có thể đặt sách có nghĩa là cũng có mối quan hệ giữa các lớp Đơn hàng và Sách. Để giữ ví dụ đơn giản, ở đây, khách hàng chỉ có thể đặt một cuốn sách trong một lần. Ngoài ra, một đơn hàng phải chứa ít nhất một cuốn sách. Một đơn hàng không có sách không phải là đơn hàng.

Trong lớp Sách, thuộc tính inStock (tồn kho) cũng được duy trì. Thông tin như “nếu tồn kho không đủ để thực hiện đơn hàng, thì một lệnh in được gửi đến máy in” không thể được mô hình hóa. Đây là loại thông tin không thể được mô hình hóa trong biểu đồ lớp vì nó mô tả một chức năng nhất định của hệ thống. Thông tin này là một phần của yêu cầu và nên được tài liệu hóa trong một sản phẩm công việc khác. Nó có thể được thêm vào như một yêu cầu văn bản đi kèm với biểu đồ lớp, hoặc được mô hình hóa bằng biểu đồ khác — ví dụ: biểu đồ hoạt động UML (xem Mục 3.4.4.1).

3.4.4 Mô hình hóa Chức năng và Luồng

(Modeling Function and Flow)

Chức năng và luồng mô tả cách hệ thống (hoặc hệ thống con) biến đổi đầu vào thành đầu ra. Chúng ta có thể trực quan hóa loại yêu cầu này bằng các mô hình mô tả chức năng và luồng.

Không giống với mô hình hóa dữ liệu — về cơ bản chỉ cần một loại biểu đồ — chức năng và luồng có thể được nhìn từ nhiều góc độ khác nhau. Tùy thuộc vào nhu cầu của các bên liên quan để thực hiện bước tiếp theo trong quá trình phát triển, có thể cần nhiều hơn một mô hình để tài liệu hóa các yêu cầu về chức năng và luồng.

Một số mô hình phổ biến để biểu diễn chức năng và luồng bao gồm:

• Biểu đồ Use Case UML [OMG2017]. Xem Mục 3.4.2.2
• Biểu đồ hoạt động UML [OMG2017]. Xem Mục 3.4.4.1
• Biểu đồ luồng dữ liệu [DeMa1978]. Xem Mục 3.4.2.1
• Mô hình Domain story [HoSch2020]. Xem Mục 3.4.6.3
• BPMN (Business Process Model and Notation) [OMG2013]

Phần mở rộng: Mô hình quy trình BPMN được sử dụng để mô tả các quy trình nghiệp vụ hoặc quy trình kỹ thuật. BPMN được sử dụng thường xuyên để diễn đạt các mô hình quy trình nghiệp vụ.

Để giải thích khái niệm mô hình hóa chức năng và luồng, mục này giới hạn ở một số ví dụ về biểu đồ UML. Nếu cần chiều sâu hơn hoặc muốn dùng mô hình khác, hãy đọc tài liệu tham chiếu và thực hành với ngôn ngữ mô hình hóa liên quan.

3.4.4.1 Biểu đồ Hoạt động UML

(UML Activity Diagram)

Mô hình hoạt động UML được dùng để đặc tả các chức năng hệ thống. Chúng cung cấp các phần tử để mô hình hóa các hành động và luồng kiểm soát giữa các hành động. Biểu đồ hoạt động cũng có thể thể hiện ai chịu trách nhiệm cho hành động nào. Các phần tử mô hình hóa nâng cao (không được đề cập trong handbook này) cung cấp phương tiện để mô hình hóa luồng dữ liệu.

Biểu đồ hoạt động UML diễn đạt luồng kiểm soát của các hoạt động trong một (hệ thống con). Ý tưởng về luồng bắt nguồn từ lưu đồ (flowchart) được dùng để trực quan hóa mã chương trình [DIN66001], [ISO5807] — giúp lập trình viên hình dung và hiểu các cấu trúc phức tạp. Với sự ra đời của UML [OMG2017], biểu đồ hoạt động được chuẩn hóa để trực quan hóa hoạt động từ góc độ chức năng.

Với tập hợp các phần tử ký pháp cơ bản (Hình 3.9), bạn có thể thiết lập một biểu đồ hoạt động tuần tự đơn giản.

Hình 3.9 — Ký pháp cơ bản: start node, end node, control flow termination, action/activity, action/control flow arrow

Nếu cần kiểm soát phức tạp hơn, mô hình có thể được mở rộng với các quyết định (decisions) và luồng song song (parallel flows) sử dụng các phần tử ký pháp cho fork và join node (thường được gọi là đồng bộ hóa — synchronization).

Hình 3.10 — Ký pháp nâng cao: decision node, merge node, fork node và join node (synchronization bar)

Biểu đồ hoạt động có thể được dùng để đặc tả chi tiết logic xử lý của các kịch bản use case (xem Mục 3.3.2). Biểu đồ hoạt động được tạo ra để trực quan hóa các kịch bản — là các quy trình với các hoạt động và logic xử lý. Miễn là biểu đồ vẫn dễ hiểu, kịch bản chính có thể được mô hình hóa cùng với các kịch bản thay thế và kịch bản ngoại lệ trong cùng một biểu đồ.

Hình 3.11 trình bày một ví dụ đơn giản về hệ thống đặt sách.

Hình 3.11 — Biểu đồ hoạt động UML: quy trình đặt sách với luồng chính, luồng thay thế (hết hàng) và luồng ngoại lệ (thông tin không hợp lệ)

Luồng hành động đơn giản hóa này bắt đầu khi khách hàng gửi đơn hàng. Trước tiên, thông tin Đơn hàng và Khách hàng được xác nhận để xác định xem tất cả thông tin (cần thiết) đã được cung cấp chưa. Nếu thông tin Đơn hàng hoặc Khách hàng không hợp lệ (sai hoặc không đủ), thì một thông báo được gửi đến khách hàng và quá trình đặt hàng bị hủy. Kịch bản cơ bản là thông tin Đơn hàng và Khách hàng hợp lệ. Kịch bản mà thông tin Đơn hàng hoặc Khách hàng không hợp lệ được gọi là luồng ngoại lệ (exceptional flow) và xử lý một điều kiện lỗi chức năng trong quy trình.

Nếu cả thông tin Đơn hàng và Khách hàng đều đúng, thì tồn kho được kiểm tra. Nếu có đủ số lượng sản phẩm trong kho, Đơn hàng được nhặt và gửi đến Khách hàng. Một luồng thay thế được bắt đầu nếu không có đủ sản phẩm trong kho: một lệnh in (print job) được gửi đến Máy in và một thông báo giao hàng lại được gửi đến Khách hàng.

Trong hệ thống đặt sách, cũng có các luồng khác được tách biệt khỏi quy trình đặt hàng và giao hàng. Ví dụ, các quy trình thanh toán, giao hàng lại và hóa đơn có các luồng riêng biệt để cho phép phân tách mối quan tâm (separation of concerns) rõ ràng. Ví dụ, nếu quyết định không còn lưu trữ bất kỳ sản phẩm nào trong kho, thì quy trình đặt hàng và giao hàng vẫn áp dụng. Nếu cần thay đổi trong luồng này, những thay đổi này có thể không ảnh hưởng đến các luồng khác. Sự phân tách chức năng này giúp giữ mọi thứ đơn giản và rõ ràng.

3.4.5 Mô hình hóa Trạng thái và Hành vi

(Modeling State and Behavior)

Các yêu cầu chức năng mô tả hành vi, trạng thái và sự chuyển đổi của một (hệ thống con) hoặc của một đối tượng nghiệp vụ là các yêu cầu thuộc góc nhìn hành vi. Ví dụ, một trạng thái hệ thống có thể là Bật (On), Chờ (Standby) hoặc Tắt (Off). Một đối tượng nghiệp vụ có thể có vòng đời trải qua một số trạng thái được quy định trước. Ví dụ, đối tượng nghiệp vụ Đơn hàng có thể ở các trạng thái: Đã đặt (Placed), Đã xác nhận (Validated), Đã thanh toán (Paid), Đã vận chuyển (Shipped) và Hoàn thành (Completed).

Một kỹ thuật được sử dụng rộng rãi để mô tả hành vi của hệ thống là statechart [Hare1988]. Statechart là máy trạng thái với các trạng thái được phân tách theo cấp bậc và/hoặc theo chiều trực giao. Máy trạng thái, bao gồm cả statechart, có thể được biểu diễn trong ngôn ngữ mô hình hóa UML [OMG2017] bằng biểu đồ máy trạng thái (còn gọi là biểu đồ trạng thái).

Biểu đồ trạng thái mô tả các máy trạng thái hữu hạn (finite state machines). Điều này có nghĩa là các hệ thống này cuối cùng đạt đến trạng thái cuối cùng. Một biểu đồ trạng thái hiển thị các trạng thái mà hệ thống hoặc một đối tượng có thể đảm nhận. Nó cũng chỉ ra cách chuyển đổi trạng thái — tức là sự chuyển đổi trạng thái (state transition). Một hệ thống không tự làm nhiều thứ. Việc chuyển trạng thái đòi hỏi một kích hoạt từ hệ thống hoặc từ môi trường của hệ thống.

Các mô hình phổ biến để biểu diễn hành vi và trạng thái bao gồm:

• Statechart [Hare1988]
• Biểu đồ trạng thái UML [OMG2017]

3.4.5.1 Biểu đồ Trạng thái UML

(UML State Diagram)

Để giải thích khái niệm mô hình hóa hành vi và trạng thái, chương này sử dụng biểu đồ trạng thái UML làm ví dụ. Nếu cần chiều sâu hơn hoặc muốn dùng mô hình khác, hãy đọc tài liệu tham chiếu và thực hành với ngôn ngữ mô hình hóa liên quan.

Các phần tử ký pháp cơ bản (Hình 3.12) bao gồm:

Hình 3.12 — Ký pháp cơ bản: initial pseudo state, final state, state, transition (với event, guard condition và activity)

• Trạng thái ban đầu (Initial pseudo state): Điểm bắt đầu của máy trạng thái hoặc trạng thái phức hợp.
• Trạng thái cuối (Final state): Loại trạng thái đặc biệt báo hiệu rằng vùng bao quanh đã hoàn tất.
• Trạng thái (State): Điều khiển phản ứng của máy trạng thái với các sự kiện. Nói cách khác, nó mô tả hành vi của hệ thống khi ở trạng thái cụ thể đó.
• Sự chuyển đổi (Transition): Sự chuyển đổi từ một trạng thái sang trạng thái khác. Chuyển đổi sang trạng thái khác xảy ra khi một sự kiện kích hoạt (tùy chọn) xuất hiện. Sự chuyển đổi có thể được bảo vệ (tùy chọn) bởi một điều kiện — chỉ khi điều kiện là “đúng” thì sự chuyển đổi mới có hiệu lực. Có thể cần nhiều điều kiện cho một sự chuyển đổi. Trong quá trình chuyển đổi, một hoạt động (tùy chọn) được thực hiện.

Như đã thảo luận ở đầu mục, một biểu đồ trạng thái có thể làm rõ các trạng thái mà một đối tượng có thể đảm nhận. Chúng ta thấy ở đây cơ hội để trực quan hóa thêm thông tin (và một phần dư thừa) về một đối tượng. Hãy tưởng tượng bạn đặt một cuốn sách trên website và muốn theo dõi trạng thái đơn hàng của mình. Một đơn hàng được dùng trong thế giới thực và được mô hình hóa như một đối tượng nghiệp vụ trong biểu đồ lớp (xem Hình 3.8) với, rất có thể, một thuộc tính status. Biểu đồ lớp chỉ ra rằng thuộc tính status có thể nhận một số giá trị giới hạn, như Đã xác nhận (Validated), Đã thanh toán (Paid), Đã giao hàng (Delivered), Đã hủy (Canceled), v.v. Biểu đồ lớp không mô tả thứ tự của các thay đổi trạng thái có thể. Biểu đồ lớp cũng không mô tả hành vi của hệ thống ở một “trạng thái” nhất định. Điều này có thể được làm rõ bằng biểu đồ trạng thái UML — ví dụ: một đơn hàng được cung cấp không thể chuyển trực tiếp sang trạng thái Đã giao hàng mà không có khách hàng đã thanh toán cho đơn hàng.

Hình 3.13 trình bày một ví dụ về biểu đồ trạng thái của hệ thống đặt sách.

Hình 3.13 — Biểu đồ trạng thái UML: vòng đời của đối tượng Order qua các trạng thái New → Validated → Picked → Sent → Paid → Handled (và Canceled, Not in stock)

Trong biểu đồ lớp (Hình 3.8) của hệ thống đặt sách, một đối tượng Đơn hàng (Order) được mô hình hóa. Đối tượng này có thuộc tính status có thể nhận một số giá trị giới hạn. Các giá trị này được liệt kê và giải thích trong biểu đồ lớp. Điều mà biểu đồ lớp không mô tả là thứ tự xử lý đơn hàng. Biểu đồ trạng thái trực quan hóa các trạng thái và các chuyển đổi giữa các trạng thái, làm rõ thứ tự của trạng thái đơn hàng. Biểu đồ trạng thái cho thấy, ví dụ, đơn hàng không thể được gửi trước khi được nhặt hoàn toàn (chuyển đổi giữa các trạng thái Đã nhặt và Đã gửi). Ngoài ra, nếu đơn hàng đang ở trạng thái Đã gửi, trạng thái tiếp theo chỉ có thể là Đã thanh toán. Một chuyển đổi từ Đã gửi sang Đã xử lý là không thể. Biểu đồ này cũng làm rõ rằng việc thanh toán xảy ra sau khi sách được gửi đi. Bạn có thể hỏi các bên liên quan liệu đây có phải điều họ cần hoặc đã yêu cầu hay không.

Một sự chuyển đổi có thể hướng đến cùng một trạng thái. Tình huống này được thể hiện ở trạng thái Đang nhặt (Picked). Mỗi lần đơn hàng chưa được nhặt hoàn toàn, nó vẫn ở cùng một trạng thái để tránh gửi đơn hàng không đầy đủ. Chỉ khi đơn hàng được nhặt hoàn toàn thì nó mới được gửi đến khách hàng.

Vài tháng sau khi phát hành hệ thống đặt sách, khách hàng phàn nàn rằng họ không có khả năng hủy đơn hàng. Đã được thống nhất rằng khách hàng có thể hủy đơn hàng ở bất kỳ trạng thái nào trong quy trình đặt hàng. Mô hình hóa yêu cầu mới này có nghĩa là cần có một chuyển đổi đến trạng thái Đã hủy (Canceled) từ mỗi trạng thái. Điều này có thể làm cho biểu đồ khó đọc. Thêm một yêu cầu văn bản để mô tả hành vi này có thể là cách để giữ cho mô hình đơn giản và dễ đọc đối với người xem.

📌 ÔN THI — UML State Diagram: Phù hợp khi hệ thống/business object có nhiều trạng thái rõ ràng và hành vi thay đổi tùy trạng thái. Khi diagram quá phức tạp → kết hợp thêm textual requirement để giữ model đơn giản.

---

3.4.6 Các Mô hình Bổ sung (Supplementary Models)

⚠️ TRAP — Mục 3.4.6 KHÔNG có trong đề thi CPRE Foundation Level. Handbook ghi rõ: “will not be questioned in the CPRE Foundation level exam.” Các model/technique sau chỉ cần biết tên, không học sâu ký hiệu hay công thức:

• AND/OR tree — mô hình hóa goals
• GRL (Goal-oriented Requirements Language)
• KAOS (Knowledge Acquisition in Automated Specification)
• i* framework
• SysML Block Definition Diagrams
• Domain story (Domain Storytelling)
• UML Sequence Diagram

UML Sequence Diagram (Biểu đồ Tuần tự UML)

(Nội dung này KHÔNG có trong đề thi CPRE Foundation Level — chỉ đọc để biết)

Biểu đồ tuần tự UML mô tả sự tương tác giữa các đối tượng (hoặc tác nhân) theo trình tự thời gian. Nó thể hiện ai gửi thông điệp cho ai và theo thứ tự nào. Biểu đồ tuần tự bổ sung cho biểu đồ hoạt động bằng cách tập trung vào sự trao đổi thông điệp giữa các thành phần thay vì luồng kiểm soát bên trong.

Các phần tử ký pháp cơ bản bao gồm sequence diagram frame, actor/object, lifeline, activation và termination (Hình 3.14), cùng với ba loại thông điệp: asynchronous message, synchronous message và answer message (Hình 3.15).

Hình 3.14 — Ký pháp cơ bản: sequence diagram frame, actor/object, lifeline, activation, termination

Hình 3.15 — Ba loại thông điệp: asynchronous message (→), synchronous message (→ với mũi tên đặc), answer message (←- - -)

Hình 3.16 trình bày một ví dụ đơn giản với một hệ thống đặt hàng (Ordering system) nhận một đơn hàng và gửi lệnh in sách.

Hình 3.16 — Ví dụ đơn giản: Ordering system nhận order và gửi print book

Hình 3.17 mở rộng ví dụ với ba thành phần: Customer, Ordering system và Printer, thể hiện toàn bộ luồng từ đặt hàng đến xử lý và giao hàng.

Hình 3.17 — Biểu đồ tuần tự UML: Customer → Ordering system → Printer, thể hiện các thông điệp orderBook, sendOrderStatus, printJob, printJobResult, sendOrder

---

3.5 Bảng thuật ngữ (Glossaries)

Các bảng thuật ngữ là phương tiện cốt lõi để thiết lập sự hiểu biết chung về thuật ngữ được sử dụng khi phát triển một hệ thống: chúng giúp tránh tình trạng các bên tham gia — với tư cách là bên liên quan hoặc nhà phát triển — sử dụng và diễn giải cùng một thuật ngữ theo những cách khác nhau.

Một bảng thuật ngữ tốt chứa định nghĩa cho tất cả các thuật ngữ có liên quan đến hệ thống, cho dù là thuật ngữ đặc thù theo bối cảnh hay thuật ngữ thông dụng hàng ngày được dùng với ý nghĩa đặc biệt trong bối cảnh của hệ thống sẽ được phát triển. Bảng thuật ngữ cũng nên định nghĩa tất cả các từ viết tắt và từ cấu tạo bằng chữ cái đầu (acronyms) được sử dụng. Nếu có từ đồng nghĩa (tức là các thuật ngữ khác nhau biểu thị cùng một thứ), chúng nên được đánh dấu là như vậy. Từ đồng âm (tức là các thuật ngữ giống hệt nhau biểu thị những thứ khác nhau) nên được tránh hoặc ít nhất được đánh dấu là như vậy trong bảng thuật ngữ.

Có một số quy tắc hướng dẫn việc tạo lập, sử dụng và bảo trì bảng thuật ngữ trong một dự án phát triển hệ thống.

• Tạo lập và bảo trì (Creation and maintenance): Để đảm bảo thuật ngữ được định nghĩa trong bảng thuật ngữ là nhất quán và luôn được cập nhật, điều sống còn là bảng thuật ngữ phải được quản lý và bảo trì tập trung trong toàn bộ quá trình của một dự án, với một người hoặc một nhóm nhỏ chịu trách nhiệm về bảng thuật ngữ. Khi định nghĩa các thuật ngữ, điều quan trọng là các bên liên quan phải được tham gia và đồng thuận về thuật ngữ đó.
• Sử dụng (Usage): Để nhận được toàn bộ lợi ích của một bảng thuật ngữ, việc sử dụng nó phải là bắt buộc. Các sản phẩm công việc nên được kiểm tra về việc sử dụng bảng thuật ngữ thích hợp. Rõ ràng, điều này có nghĩa là mọi người tham gia vào một dự án đều phải có quyền truy cập đọc vào bảng thuật ngữ.

Khi một tổ chức phát triển các hệ thống có liên quan trong nhiều dự án, việc tạo ra một bảng thuật ngữ ở cấp độ doanh nghiệp là hợp lý, nhằm đạt được thuật ngữ nhất quán xuyên suốt các dự án.

Việc tạo lập, bảo trì và sử dụng bảng thuật ngữ một cách nhất quán giúp tránh được các lỗi và sự hiểu lầm liên quan đến thuật ngữ được sử dụng. Làm việc với các bảng thuật ngữ là một thực hành tốt nhất (best practice) tiêu chuẩn trong kỹ nghệ yêu cầu (RE).

📌 ÔN THI — Quy tắc quản lý Glossary

• Creation & Maintenance: Quản lý và bảo trì tập trung trong suốt dự án. Một người hoặc nhóm nhỏ chịu trách nhiệm. Stakeholders phải tham gia và đồng thuận.
• Usage: Sử dụng phải là bắt buộc (mandatory). Work products phải được kiểm tra về cách dùng glossary đúng. Mọi người phải có quyền đọc glossary.
• Khi tổ chức phát triển nhiều hệ thống liên quan: tạo enterprise-level glossary.

🔑 THUẬT NGỮ: Synonym (từ đồng nghĩa) = các từ khác nhau chỉ cùng một thứ → đánh dấu trong glossary. Homonym (từ đồng âm khác nghĩa) = cùng từ nhưng chỉ những thứ khác nhau → phải tránh hoặc đánh dấu rõ.

---

3.6 Các tài liệu yêu cầu và cấu trúc tài liệu hóa (Requirements Documents and Documentation Structures)

Làm việc với các yêu cầu ở cấp độ từng yêu cầu đơn lẻ là chưa đủ. Các yêu cầu phải được đối chiếu và nhóm lại trong các sản phẩm công việc phù hợp, cho dù chúng là các tài liệu yêu cầu tường minh (explicit requirements documents) hay các cấu trúc tài liệu hóa liên quan đến RE khác (chẳng hạn như product backlog).

Các mẫu tài liệu (xem Mục 3.3.3) có thể được sử dụng để tổ chức các tài liệu như vậy với một cấu trúc được xác định rõ ràng, nhằm tạo ra một tập hợp các yêu cầu nhất quán và có thể bảo trì. Các mẫu tài liệu có sẵn trong tài liệu tham khảo [Vole2026], [RoRo2012] và trong các tiêu chuẩn [ISO29148]. Các mẫu cũng có thể được tái sử dụng từ các dự án tương tự trước đây, hoặc có thể bị áp đặt bởi khách hàng. Một tổ chức cũng có thể quyết định tạo ra một mẫu tài liệu như một tiêu chuẩn nội bộ.

Một tài liệu yêu cầu cũng có thể chứa thông tin bổ sung và các lời giải thích — ví dụ: một bảng thuật ngữ, các tiêu chí chấp nhận (acceptance criteria), thông tin dự án, hoặc các đặc điểm của việc triển khai kỹ thuật.

Các tài liệu yêu cầu thường được sử dụng:

• Đặc tả yêu cầu của bên liên quan (Stakeholder requirements specification): những mong muốn và nhu cầu của các bên liên quan sẽ được thỏa mãn bằng việc xây dựng một hệ thống, nhìn từ góc độ của các bên liên quan. Khi khách hàng viết một đặc tả yêu cầu của bên liên quan, nó được gọi là đặc tả yêu cầu của khách hàng (customer requirements specification).
• Đặc tả yêu cầu người dùng (User requirements specification): một tập con của đặc tả yêu cầu của bên liên quan, chỉ bao gồm các yêu cầu của những bên liên quan là người dùng tương lai (prospective users) của một hệ thống.
• Đặc tả yêu cầu hệ thống (System requirements specification): các yêu cầu đối với một hệ thống sẽ được xây dựng và bối cảnh của nó, để hệ thống đó thỏa mãn những mong muốn và nhu cầu của các bên liên quan.
• Đặc tả yêu cầu nghiệp vụ (Business requirements specification): các mục tiêu, mục đích và nhu cầu nghiệp vụ của một tổ chức sẽ đạt được bằng cách sử dụng một hệ thống (hoặc một tập hợp các hệ thống).
• Tài liệu Tầm nhìn (Vision document): một hình dung mang tính khái niệm về một hệ thống trong tương lai, mô tả các đặc điểm chính của nó và cách nó sẽ tạo ra giá trị cho người dùng.

Các cấu trúc tài liệu hóa thay thế thường được sử dụng:

• Product backlog (Danh sách tồn đọng sản phẩm): một danh sách được ưu tiên hóa các hạng mục công việc, bao gồm tất cả các yêu cầu cần thiết và đã biết cho sản phẩm.
• Sprint backlog (Danh sách tồn đọng Sprint): một tập con được chọn lọc từ product backlog, chứa các hạng mục công việc sẽ được hiện thực hóa trong vòng lặp tiếp theo.
• Story map (Bản đồ câu chuyện người dùng): một tổ chức trực quan hai chiều của các user story trong một product backlog xét về mặt thời gian và nội dung.

Không có tài liệu yêu cầu hay cấu trúc tài liệu hóa nào là tiêu chuẩn hoặc vạn năng. Theo đó, các tài liệu hoặc cấu trúc tài liệu hóa không nên được tái sử dụng từ các dự án trước đây một cách thiếu cân nhắc.

Sự lựa chọn thực tế phụ thuộc vào một số yếu tố, ví dụ:

• Quy trình phát triển được lựa chọn
• Loại dự án và lĩnh vực ứng dụng (ví dụ: giải pháp tùy chỉnh, phát triển sản phẩm, hoặc tùy chỉnh sản phẩm tiêu chuẩn)
• Hợp đồng (khách hàng có thể quy định việc sử dụng một cấu trúc tài liệu hóa nhất định)
• Kích thước của tài liệu (tài liệu càng lớn thì càng cần nhiều cấu trúc)

⚠️ TRAP — Không có documentation structure chuẩn phổ quát. Không được tái sử dụng cấu trúc từ dự án trước mà không suy nghĩ. Lựa chọn phụ thuộc: development process, project type & domain, contract, document size.

---

3.7 Các nguyên mẫu trong kỹ nghệ yêu cầu (Prototypes in Requirements Engineering)

Các nguyên mẫu đóng một vai trò quan trọng trong cả kỹ thuật và thiết kế.

Định nghĩa 3.5. Nguyên mẫu (Prototype):

1. Trong sản xuất: Một sản phẩm được chế tạo trước khi bắt đầu sản xuất hàng loạt.
2. Trong kỹ nghệ phần mềm và hệ thống: Một sự hiện thực hóa sơ bộ, một phần của những đặc điểm nhất định của một hệ thống.
3. Trong thiết kế: Một phiên bản sơ bộ, chưa hoàn chỉnh của một giải pháp thiết kế.

Các nguyên mẫu trong kỹ nghệ phần mềm và hệ thống được sử dụng cho ba mục đích chính [LiSZ1994]:

• Các nguyên mẫu khám phá (Exploratory prototypes) được sử dụng để tạo ra sự hiểu biết chung, làm rõ các yêu cầu, hoặc thẩm định các yêu cầu ở các mức độ hoàn thiện khác nhau. Các nguyên mẫu như vậy là sản phẩm công việc tạm thời và sẽ bị loại bỏ sau khi sử dụng. Nguyên mẫu khám phá cũng có thể được sử dụng như một phương tiện đặc tả bằng ví dụ (specification by example). Khi được dùng theo cách đó, chúng phải được xử lý như những sản phẩm công việc đang tiến hóa hoặc lâu bền.
• Các nguyên mẫu thực nghiệm (Experimental prototypes) — còn được gọi là breadboards — được sử dụng để khám phá các khái niệm giải pháp thiết kế kỹ thuật, đặc biệt liên quan đến tính khả thi về mặt kỹ thuật của chúng. Chúng bị loại bỏ sau khi sử dụng. Nguyên mẫu thực nghiệm không được sử dụng trong RE.
• Các nguyên mẫu tiến hóa (Evolutionary prototypes) là các hệ thống thí điểm tạo thành cốt lõi của một hệ thống sẽ được phát triển. Hệ thống cuối cùng tiến hóa bằng cách mở rộng và cải thiện dần dần hệ thống thí điểm qua nhiều vòng lặp. Phát triển hệ thống linh hoạt (Agile) thường xuyên sử dụng cách tiếp cận nguyên mẫu tiến hóa.

Kỹ sư Yêu cầu chủ yếu dùng nguyên mẫu khám phá cho hai mục đích: khơi gợi yêu cầu và thẩm định. Trong khơi gợi, nguyên mẫu hoạt động như phương tiện đặc tả bằng ví dụ — khi stakeholder không thể diễn đạt rõ điều họ muốn, nguyên mẫu trình diễn một hệ thống mẫu và giúp họ định hình yêu cầu. Trong thẩm định, nguyên mẫu là công cụ mạnh để xác nhận tính thỏa đáng (xem Mục 3.8) của các yêu cầu.

Nguyên mẫu khám phá có thể được xây dựng và sử dụng với các mức độ hoàn thiện khác nhau. Chúng ta phân biệt giữa wireframes, mock-ups và native prototypes.

• Wireframes (còn được gọi là nguyên mẫu trên giấy) là các nguyên mẫu có độ hoàn thiện thấp, được xây dựng bằng giấy hoặc các vật liệu đơn giản khác, chủ yếu phục vụ cho việc thảo luận và thẩm định các ý tưởng thiết kế và các khái niệm giao diện người dùng. Khi tạo nguyên mẫu cho các hệ thống kỹ thuật số, wireframes cũng có thể được xây dựng bằng các công cụ vẽ kỹ thuật số hoặc các công cụ wireframing chuyên dụng. Tuy nhiên, khi sử dụng công cụ kỹ thuật số để tạo wireframe, điều quan trọng là phải giữ lại các thuộc tính cốt yếu của một wireframe: có thể xây dựng nhanh, sửa đổi dễ dàng, và trông không bóng bẩy cũng như không giống với sản phẩm cuối cùng.
• Mock-ups là các nguyên mẫu có độ hoàn thiện trung bình. Khi đặc tả các hệ thống kỹ thuật số, chúng sử dụng các màn hình thực và luồng nhấp chuột (click flows) nhưng không có chức năng thực sự. Chúng chủ yếu phục vụ cho việc đặc tả và thẩm định các giao diện người dùng. Mock-ups mang lại cho người dùng trải nghiệm sát thực về cách tương tác với một hệ thống thông qua giao diện người dùng của nó. Chúng thường được xây dựng bằng các công cụ tạo nguyên mẫu chuyên dụng.
• Native prototypes là các nguyên mẫu có độ hoàn thiện cao, hiện thực hóa các phần trọng yếu của một hệ thống đến mức độ mà các bên liên quan có thể sử dụng nguyên mẫu đó để xem liệu phần được tạo nguyên mẫu của hệ thống sẽ hoạt động và cư xử đúng như mong đợi hay không. Chúng phục vụ cho cả việc đặc tả bằng ví dụ lẫn việc thẩm định kỹ lưỡng các yêu cầu trọng yếu. Native prototypes cũng có thể được sử dụng để khám phá và quyết định về các biến thể yêu cầu cho một khía cạnh nào đó — ví dụ: hai cách khả thi khác nhau để hỗ trợ một quy trình nghiệp vụ nhất định.

Tùy vào mức độ hoàn thiện, nguyên mẫu khám phá có thể tốn kém đáng kể. Kỹ sư Yêu cầu phải cân nhắc đánh đổi giữa chi phí xây dựng và giá trị thu được — dưới dạng dễ khơi gợi yêu cầu hơn và giảm rủi ro có yêu cầu không thỏa đáng hoặc sai lệch.

⚠️ TRAP — Prototype types: Experimental prototype (breadboard) KHÔNG dùng trong RE — chỉ để kiểm tra technical feasibility. RE chỉ dùng Exploratory (elicitation + validation) và Evolutionary (agile, pilot system).

📌 ÔN THI — 3 mức Fidelity (Độ hoàn thiện) của Exploratory Prototype

Loại	Độ hoàn thiện	Đặc điểm	Mục đích chính
Wireframe (paper prototype)	Thấp	Giấy/vật liệu đơn giản; nhanh, dễ sửa, không bóng bẩy	Thảo luận & xác nhận design ideas, UI concepts
Mock-up	Trung bình	Màn hình thực + click flows, KHÔNG có chức năng thực	Đặc tả & xác nhận user interfaces
Native prototype	Cao	Hiện thực hóa phần quan trọng, stakeholder có thể dùng	Specification by example + xác nhận kỹ requirements quan trọng

🔑 THUẬT NGỮ: Exploratory prototype (nguyên mẫu khám phá) · Experimental prototype (nguyên mẫu thực nghiệm/breadboard) · Evolutionary prototype (nguyên mẫu tiến hóa) · Wireframe · Mock-up · Native prototype

---

3.8 Các tiêu chí chất lượng đối với sản phẩm công việc và yêu cầu (Quality Criteria for Work Products and Requirements)

Kỹ sư Yêu cầu cần phấn đấu viết các yêu cầu tốt theo các tiêu chí chất lượng đã định. Có nhiều bộ tiêu chí khác nhau trong tài liệu tham khảo và tiêu chuẩn RE, nhưng chưa có bộ nào được đồng thuận chung. Bộ tiêu chí dưới đây là thực hành đã được kiểm chứng ở cấp độ nền tảng.

RE hiện đại theo cách tiếp cận định hướng giá trị (xem Nguyên tắc 1, Chương 2): mức độ tuân thủ tiêu chí chất lượng phải tương xứng với giá trị của yêu cầu đó. Hệ quả thực tế:

• Các yêu cầu không nhất thiết phải tuân thủ hoàn toàn tất cả các tiêu chí chất lượng.
• Một số tiêu chí chất lượng quan trọng hơn những tiêu chí khác.

Chúng ta phân biệt giữa các tiêu chí chất lượng cho các yêu cầu đơn lẻ và các tiêu chí chất lượng cho các sản phẩm công việc RE.

Tiêu chí chất lượng cho yêu cầu đơn lẻ

Chúng tôi đề xuất sử dụng các tiêu chí chất lượng sau:

• Thỏa đáng (Adequate): yêu cầu mô tả những nhu cầu chân thực và đã được đồng thuận của các bên liên quan.
• Cần thiết (Necessary): yêu cầu là một phần của phạm vi hệ thống có liên quan, nghĩa là nó sẽ đóng góp vào việc đạt được ít nhất một mục tiêu hoặc nhu cầu của bên liên quan.
• Không mơ hồ (Unambiguous): có một sự hiểu biết chung thực sự về yêu cầu, nghĩa là mọi người tham gia đều diễn giải nó theo cùng một cách.
• Đầy đủ (Complete): yêu cầu tự nó đã trọn vẹn, nghĩa là không có các phần cần thiết nào để hiểu nó bị thiếu.
• Có thể hiểu được (Understandable): yêu cầu là dễ hiểu đối với đối tượng mục tiêu, nghĩa là đối tượng mục tiêu có thể hiểu hoàn toàn yêu cầu đó.
• Có thể kiểm chứng (Verifiable): có thể kiểm tra một cách rõ ràng, không mơ hồ xem hệ thống đã được triển khai có đáp ứng yêu cầu hay không.

Adequate và Understandable là hai tiêu chí quan trọng nhất. Thiếu một trong hai, yêu cầu sẽ vô dụng hoặc thậm chí có hại — dù mọi tiêu chí khác đều đạt. Verifiable đặc biệt quan trọng khi hệ thống phải trải qua quy trình nghiệm thu chính thức.

Lưu ý — Tính thỏa đáng so với tính chính xác: Một số người dùng thuật ngữ tính chính xác (correctness) thay vì tính thỏa đáng. Tuy nhiên, khái niệm tính chính xác hàm ý rằng có một quy trình hình thức để quyết định xem điều gì đó có chính xác hay không. Vì không có quy trình hình thức nào để thẩm định một yêu cầu đã được tài liệu hóa so với những mong muốn và nhu cầu mà các bên liên quan có trong đầu, chúng tôi ưu tiên dùng thuật ngữ tính thỏa đáng hơn tính chính xác.

📌 ÔN THI — 6 tiêu chí cho Single Requirement (THUỘC tiếng Anh)

Tiêu chí EN	Tiếng Việt	Nghĩa cốt lõi
Adequate ⭐	Thỏa đáng / Phù hợp	Mô tả đúng nhu cầu thực của stakeholder đã đồng thuận
Necessary	Cần thiết	Thuộc system scope; đóng góp vào ít nhất 1 stakeholder goal
Unambiguous	Không mơ hồ	Mọi người hiểu theo cùng một cách
Complete	Đầy đủ (self-contained)	Không thiếu phần nào cần thiết để hiểu requirement
Understandable ⭐	Có thể hiểu được	Target audience hiểu đầy đủ requirement
Verifiable	Có thể xác minh	Kiểm tra đáp ứng requirement không mơ hồ

⭐ = Adequate + Understandable là quan trọng NHẤT. Thiếu một trong hai → requirement vô dụng hoặc có hại dù các tiêu chí khác đạt.

⚠️ TRAP — “Adequate” không phải “Correct”: Không có quy trình chính thức để validate documented requirement vs. ý muốn thực trong đầu stakeholder → dùng “Adequate” thay “Correct”. Đây là điểm tinh tế hay xuất hiện trong đề.

Tiêu chí chất lượng cho sản phẩm công việc (nhiều yêu cầu)

Đối với các sản phẩm công việc bao gồm nhiều yêu cầu, chúng tôi đề xuất áp dụng các tiêu chí chất lượng sau:

• Nhất quán (Consistent): không có hai yêu cầu nào, được ghi lại trong cùng một sản phẩm công việc hoặc trong các sản phẩm công việc khác nhau, lại mâu thuẫn với nhau.
• Không dư thừa (Non-redundant): mỗi yêu cầu chỉ được tài liệu hóa một lần và không bị chồng chéo với một yêu cầu khác.
• Đầy đủ (Complete): sản phẩm công việc chứa tất cả các yêu cầu có liên quan (yêu cầu chức năng, yêu cầu chất lượng và các ràng buộc) đã được biết đến tại thời điểm này và có liên quan đến sản phẩm công việc này.
• Có thể sửa đổi (Modifiable): sản phẩm công việc được thiết lập theo cách sao cho nó có thể được sửa đổi mà không làm giảm sút chất lượng của nó.
• Có thể truy xuất nguồn gốc (Traceable): mỗi yêu cầu có thể trace ngược về nguồn gốc, trace xuôi đến triển khai (thiết kế, mã nguồn, kiểm thử), và trace đến các yêu cầu phụ thuộc.
• Tuân thủ (Conformant): nếu có các hướng dẫn bắt buộc về cấu trúc hoặc định dạng, sản phẩm công việc phải tuân thủ chúng.

📌 ÔN THI — 6 tiêu chí cho Work Product (nhiều requirements) (THUỘC tiếng Anh)

Tiêu chí EN	Tiếng Việt	Nghĩa cốt lõi
Consistent	Nhất quán	Không có requirements mâu thuẫn nhau (trong hoặc giữa các work products)
Non-redundant	Không dư thừa	Mỗi requirement chỉ tài liệu hóa một lần, không chồng chéo
Complete	Đầy đủ (bao phủ)	Chứa TẤT CẢ requirements liên quan đã biết tại thời điểm này
Modifiable	Có thể sửa đổi	Sửa mà không làm giảm chất lượng work product
Traceable	Có thể truy xuất	Trace ngược về nguồn gốc, xuôi đến implementation (design, code, test)
Conformant	Tuân thủ	Tuân thủ quy định bắt buộc về cấu trúc/format

⚠️ TRAP — “Complete” có 2 nghĩa hoàn toàn khác nhau:

• Complete ở cấp single requirement = self-contained (requirement đó đầy đủ trong chính nó, không thiếu phần nào để hiểu)
• Complete ở cấp work product = bao phủ đủ tất cả requirements liên quan (không bỏ sót requirement nào)

---

3.9 Tài liệu đọc thêm (Further Reading)

Mavin và cộng sự [MWHN2009] giới thiệu và mô tả mẫu câu EARS. Robertson và Robertson [RoRo2012] mô tả các mẫu Volere. Goetz và Rupp [GoRu2003], [Rupp2020] thảo luận về các quy tắc và cạm bẫy khi viết các yêu cầu bằng ngôn ngữ tự nhiên. Cockburn [Cock2001] đã viết toàn bộ một cuốn sách về cách viết các use case. Lauesen [Laue2002] thảo luận về các mô tả tác vụ và cũng cung cấp một số ví dụ về các sản phẩm công việc RE trong thế giới thực.

Tiêu chuẩn ISO/IEC/IEEE 29148 [ISO29148] cung cấp nhiều tài nguyên liên quan đến các sản phẩm công việc RE: các mẫu câu, các tiêu chí chất lượng cho yêu cầu, và các mô tả chi tiết về nội dung của nhiều sản phẩm công việc RE khác nhau, bao gồm cả một mẫu tài liệu cho mỗi sản phẩm công việc. Cohn [Cohn2010] có một chương về cách định khung các yêu cầu trong một product backlog.

Gregory [Greg2016] và Glinz [Glin2016] thảo luận về vấn đề các yêu cầu nên được đặc tả chi tiết đến mức nào và mức độ khả thi của việc có các đặc tả yêu cầu đầy đủ và không mơ hồ.

Vô số ấn phẩm đề cập đến việc sử dụng các mô hình để đặc tả các yêu cầu. Đặc tả UML [OMG2017], cũng như các sách giáo khoa về UML, mô tả các mô hình có sẵn trong UML. Hofer và Schwentner [HoSch2020] giới thiệu việc mô hình hóa lĩnh vực ứng dụng bằng kể chuyện lĩnh vực (domain storytelling). [OMG2013] và [OMG2018] lần lượt mô tả các ngôn ngữ mô hình hóa BPMN cho việc mô hình hóa các quy trình nghiệp vụ và SysML cho việc mô hình hóa các hệ thống. Các cuốn sách của Booch, Rumbaugh và Jacobson [BoRJ2005], [JaSB2011], [RuJB2004] đưa ra chiều sâu hơn và các ứng dụng thực tế của UML.

---

Ghi chú hiệu đính

Mục	Nội dung sửa	Lý do
3.1.1 (bảng)	“Bản đồ user story” → “Bản đồ câu chuyện người dùng (Story map)”	“cốt truyện” = narrative plot — sai ngữ nghĩa; “user story” không phải cốt truyện
3.1.1 (body)	“biểu mẫu và mô hình” → “mẫu (template) và mô hình”	Tham chiếu đến Mục 3.3 — phải dùng “mẫu” nhất quán
Định nghĩa 3.2	“Một biểu mẫu cho cấu trúc cú pháp” → “Một mẫu cho cấu trúc cú pháp”	Phrase template không phải biểu mẫu (form)
3.3 (header)	“Dựa trên Biểu mẫu” → “Dựa trên Mẫu (Template-Based)”	“Biểu mẫu” = form cụ thể; section này bao gồm cả phrase template và document template
3.3 (intro)	“ba lớp biểu mẫu” → “ba loại mẫu: mẫu câu (phrase template), mẫu biểu (form template) và mẫu tài liệu (document template)”	Nhất quán với tiêu đề đã sửa
3.3.2 (heading)	“Mẫu biểu mẫu” → “Mẫu biểu”	“Mẫu biểu mẫu” là tautology
3.3.2 (body)	4 chỗ “Mẫu biểu mẫu” → “Mẫu biểu”	Nhất quán với định nghĩa 3.3
Định nghĩa 3.3	“Một biểu mẫu cung cấp biểu mẫu (form)” → “Một mẫu cung cấp biểu mẫu (form)”	Danh từ đầu câu phải là “mẫu” (template), không phải “biểu mẫu” (form)
Định nghĩa 3.4	“Một biểu mẫu cung cấp cấu trúc khung xương” → “Một mẫu cung cấp cấu trúc khung xương”	Document template không phải biểu mẫu (form)
3.3.4 (toàn bộ)	4 chỗ “biểu mẫu” → “mẫu”	Khi bàn về templates nói chung phải dùng “mẫu” không phải “biểu mẫu”
3.3.3	Bổ sung bảng nội dung Hình 3.1 (SRS template structure)	Bản dịch cũ có tham chiếu đến Hình 3.1 nhưng thiếu nội dung bảng
3.4.1.3	“sự hiểu biết nhân quả” → “sự hiểu biết toàn diện về yêu cầu”	Dịch “causal understanding” thành “nhân quả” gây hiểu lầm trong ngữ cảnh này
3.4.2 (context)	“tiết lộ một số nguồn” → “làm lộ ra một số nguồn”	“Tiết lộ” hàm ý bí mật; “reveal” ở đây nghĩa là phát hiện ra/xác định
3.4.2 (context)	“người ta cần kiểm kê” → “cần thực hiện kiểm kê”	Bỏ “người ta” — phrasing thụ động tự nhiên hơn
3.4.2.2	“mô tả bằng một biểu mẫu (Mục 3.3)” → “mô tả bằng một mẫu biểu (Mục 3.3.2)”	Use cases dùng form template (mẫu biểu), tham chiếu đúng vào 3.3.2
3.4.6	Bổ sung section heading + exam trap note cho Supplementary Models	Mục này hoàn toàn thiếu trong bản dịch cũ
3.6 (annotation)	“3 loại constraints” → “6 loại Constraints”	Annotation tự mâu thuẫn: viết “3 loại” nhưng liệt kê 6
3.7 (prototype)	Lỗi formatting: “(” → ()**	Thiếu đóng ngoặc đơn trước đóng bold
3.6	“tài liệu yêu cầu tường minh” — giữ nguyên, đúng	“Explicit” = tường minh — đã đúng từ trước
3.6	“tiêu chí chấp nhận” — giữ nguyên, đúng	Thuật ngữ IREB chuẩn
3.8	Bổ sung đoạn “tính chính xác vs tính thỏa đáng”	Có trong Handbook gốc, bản dịch cũ bỏ sót
Toàn bộ	Bổ sung 📌 ÔN THI, ⚠️ TRAP, 🔑 THUẬT NGỮ annotations	Hỗ trợ ôn tập thi CPRE FL