Chương 3 - Sản phẩm Công việc và Thực hành Tài liệu hóa

Kỹ nghệ Yêu cầu truyền thống (RE) yêu cầu phải viết một đặc tả yêu cầu toàn diện, đầy đủ và không mơ hồ [IEEE830], [Glin2016]. Mặc dù việc tạo ra các đặc tả yêu cầu hoàn chỉnh vẫn phù hợp trong nhiều trường hợp, nhưng cũng có nhiều trường hợp khác mà chi phí viết những đặc tả như vậy vượt quá lợi ích mà chúng mang lại. Ví dụ, các đặc tả yêu cầu hoàn chỉnh là hữu ích hoặc thậm chí cần thiết khi đấu thầu hoặc thuê ngoài việc thiết kế và triển khai một hệ thống, hoặc khi hệ thống có tính an toàn then chốt và bắt buộc phải tuân thủ các quy định. Mặt khác, 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 một cách lặp lại, việc viết một đặc tả yêu cầu toàn diện là không hợp lý. Do đó, điều cốt yếu trong RE là phải điều chỉnh việ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 để tài liệu hóa các yêu cầu cũng như thông tin liên quan đến yêu cầu sao cho mang lại giá trị tối ưu cho dự án.

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 cung cấp cái nhìn tổng quan về các sản phẩm công việc điển hình trong RE, kèm theo mục đích tương ứng (tức là 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 được cấu trúc thành bốn nhóm: sản phẩm công việc cho yêu cầu đơn lẻ, tập hợp yêu cầu nhất quán, tài liệu hoặc cấu trúc tài liệu hóa, và các sản phẩm công việc 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) — tức là khoảng thời gian từ khi sản phẩm công việc được tạo ra cho đến khi nó bị loại bỏ hoặc trở nên không còn liên quan. Chúng tôi phân biệt ba loại vòng đờ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 theo thời gian (ví dụ: một tập hợp user story ngày càng tăng về cả số lượng lẫn nội dung câu chuyện). Cần lưu giữ một số siêu dữ liệu — tối thiểu là chủ sở hữu, trạng thái và lịch sử sửa đổi — cho mỗi sản phẩm công việc đang phát triển. Tùy theo tầm quan trọng và trạng thái của sản phẩm, cần áp dụng các quy trình kiểm soát thay đổi khi có sửa đổi.

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

Một sản phẩm công việc tạm thời có thể trở 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. Trong trường hợp đó, cần bổ sung một số siêu dữ liệu để giữ quá trình phát triển dưới sự kiểm soát. Khi một sản phẩm đang phát triển được thiết lập đường cơ sở hoặc phát hành, trạng thái vòng đời của nó chuyển từ “đang phát triển” sang “lâu bền”.

📌 GHI CHÚ Ô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)

⚠️ BẪY ĐỀ THI

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à các sản phẩm công việc tương ứng xuất hiện ở nhiều mức độ trừu tượng khác nhau — từ ví dụ như 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, chẳng hạn 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 thể hiện trong các sản phẩm công việc lâu bền — chẳng hạ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ụ, trong các tình huống hợp đồng, khi khách hàng đặt hàng việc phát triển hệ thống từ nhà cung cấp, khách hàng thường tạo và phát hành một đặc tả yêu cầu bên liên quan. Nhà cung cấp sau đó sử dụng tài liệu này làm cơ sở để tạo ra đặc tả yêu cầu hệ thống. Trong các dự án khác, yêu cầu nghiệp vụ, yêu cầu bên liên quan và yêu cầu hệ thống có thể cùng tiến hóa (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 mức độ hiểu biết chung ngầm định thấp (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.

📌 GHI CHÚ Ô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ể sản phẩm công việc RE nào được sử dụng, khi tài liệu hóa các yêu cầu cần xem xét một số khía cạnh [Glin2019].

Trước hết, vì có 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), Kỹ sư Yêu cầu phải đảm bảo bao phủ đủ cả ba loại yêu cầu khi tài liệu hóa. Trong thực tế, các bên liên quan thường bỏ sót yêu cầu chất lượng vì họ xem đó là điều hiển nhiên. Họ cũng thường đặc tả các ràng buộc như thể chúng là yêu cầu chức năng. Do đó, điều quan trọng là Kỹ sư Yêu cầu phải xác định và phân loại chúng đúng cách.

Nhìn vào yêu cầu chức năng, ta thấy chúng liên quan đến các khía cạnh khác nhau — ví dụ như cấu trúc dữ liệu được yêu cầu, thứ tự hành động được yêu cầu, hoặc phản ứng yêu cầu 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.

Bất cứ khi nào có thể, nên đặc tả các giá trị có thể đo lường được. Khi các giá trị tuân theo một phân phối xác suất, chỉ đặc tả giá trị trung bình là không đủ. Nếu không thể đặc tả hàm phân phối và các tham số của nó, Kỹ sư Yêu cầu nên cố gắng đặc tả các giá trị tối thiểu và tối đa, hoặc giá trị 95 phần trăm, bên cạnh giá trị trung bình.

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.

Quy tắc thường nghe “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” là 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ỉ trong các trường hợp có rủi ro cao về việc không đáp ứng nhu cầu của bên liên quan — đặc biệt khi yêu cầu chất lượng có tính an toàn then chốt — mới nên xem xét sử dụng biểu diễn định lượng đầy đủ hoặc vận hành hóa thông 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 vật lý–không gian mạng (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ể được yêu cầu bởi các bên liên quan quan trọng cũng tạo thành ràng buộc.

Cuối cùng, yêu cầu chỉ có thể được hiểu trong bối cảnh (xem Nguyên tắc 4 ở Chương 2). Do đó, một khía cạnh nữa cần được xem xét, mà chúng tôi gọi là bối cảnh và ranh giới (context and boundary). Khía cạnh này bao gồm yêu cầu miền và giả định miền trong bối cảnh của hệ thống, cũng như 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 giữa hệ thống với môi trường 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.

Khi tài liệu hóa yêu cầu, cần xem xét nhiều khía cạnh khác nhau — đặc biệt là chức năng (cấu trúc và dữ liệu, chức năng và luồng, trạng thái và hành vi), chất lượng, ràng buộc, và bối cảnh xung quanh (bối cảnh và ranh giới).

📌 GHI CHÚ Ô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

⚠️ BẪY ĐỀ THI

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.

⚠️ BẪY ĐỀ THI

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

📌 GHI CHÚ Ô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ả ở dạng nói lẫn viết, luôn là phương tiện cốt lõi để truyền đạt các yêu cầu đối với hệ thống. Việc sử dụng ngôn ngữ tự nhiên để viết các sản phẩm công việc RE có nhiều ưu điểm. Đặc biệt, ngôn ngữ tự nhiên cực kỳ linh hoạt và có tính biểu cảm cao, có nghĩa là hầu như bất kỳ yêu cầu nào cũng có thể được biểu đạt bằng ngôn ngữ tự nhiên ở bất kỳ khía cạnh nào. Hơn nữa, ngôn ngữ tự nhiên được dùng trong cuộc sống hàng ngày và được dạy ở trường, do đó không cần đào tạo chuyên môn để đọc và hiểu các yêu cầu được viết bằng ngôn ngữ tự nhiên.

Quá trình tiến hóa của con người đã định hình ngôn ngữ tự nhiên như một phương tiện giao tiếp bằng lời nói giữa những người tương tác trực tiếp, nơi những hiểu lầm và thông tin thiếu sót có thể được phát hiện và sửa chữa nhanh chóng. Do đó, ngôn ngữ tự nhiên không được tối ưu hóa cho việc giao tiếp chính xác, không mơ hồ và toàn diện thông qua các tài liệu viết. Đây là vấn đề lớn khi viết tài liệu kỹ thuật (như yêu cầu) bằng ngôn ngữ tự nhiên. Trái với giao tiếp bằng ngôn ngữ tự nhiên nói — nơi giao tiếp có ngữ cảnh và mang tính tương tác với phản hồi tức thì — 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 và không nhất quán trong văn bản viết bằng ngôn ngữ tự nhiên. Ngược lại, việc tìm ra những vấn đề đó trong văn bản viết là rất khó khăn và tốn kém, đặc biệt đối với các sản phẩm công việc chứa lượng lớn văn bản ngôn ngữ tự nhiên.

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 viết các yêu cầu chứa những vấn đề sau:

Mô tả không đầy đủ (Incomplete descriptions): Các động từ trong ngôn ngữ tự nhiên thường đi kèm với một tập hợp chỗ điền cho danh từ hoặc đại từ. Ví dụ, động từ “trao” có ba chỗ điền cho: ai trao, trao cái gì, và trao cho ai. Khi viết một yêu cầu bằng ngôn ngữ tự nhiên, tất cả các chỗ điền của động từ được sử dụng phải được điền đầy đủ.
Danh từ không cụ thể (Unspecific nouns): Sử dụng các danh từ như “dữ liệu” hoặc “người dùng” để lại quá nhiều chỗ cho các cách giải thích khác nhau của các bên liên quan hoặc nhà phát triển. Chúng nên được thay thế bằng các danh từ cụ thể hơn, hoặc được làm cụ thể hơn bằng cách thêm tính từ hoặc gán cho chúng một kiểu được định nghĩa rõ ràng.
Điều kiện không đầy đủ (Incomplete conditions): Khi mô tả những gì cần được thực hiện, nhiều người tập trung vào trường hợp bình thường và bỏ qua các trường hợp ngoại lệ. Trong viết kỹ thuật, đây là cạm bẫy cần tránh: khi điều gì đó chỉ xảy ra nếu một số điều kiện là đúng, cần phải nêu rõ các điều kiện đó, cung cấp cả mệnh đề “thì” (then) và “nếu không” (else).
So sánh không đầy đủ (Incomplete comparisons): Trong giao tiếp nói, người ta thường dùng so sánh (ví dụ: “ứng dụng video mới tốt hơn nhiều”) mà không nói so sánh với cái gì, thường giả định đây là điều hiển nhiên từ ngữ cảnh. Trong viết kỹ thuật, các phép so sánh phải bao gồm đối tượng tham chiếu — 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 sử dụng cẩn thận vì chúng là các cạm bẫy tiềm ẩn:

Câu bị động (Passive voice): Câu bị động không có chủ thể hành động. Nếu một yêu cầu được phát biểu ở dạng bị động, điều này có thể che giấu ai là người chịu trách nhiệm cho hành động được mô tả trong yêu cầu, dẫn đến mô tả không đầy đủ.
Lượng từ phổ quát (Universal quantifiers): Lượng từ phổ quát là các từ như “tất cả”, “luôn luôn” hoặc “không bao giờ”, được dùng để đưa ra các phát biểu đúng phổ quát. Tuy nhiên, trong các hệ thống kỹ thuật, các thuộc tính phổ quát như vậy rất hiếm. Mỗi khi Kỹ sư Yêu cầu sử dụng lượng từ phổ quát, họ cần xem xét liệu đây có phải là một thuộc tính thực sự phổ quát hay chỉ là một quy tắc chung có ngoại lệ (mà họ cũng cần đặc tả). Cần áp dụng sự thận trọng tương tự khi sử dụng các mệnh đề “hoặc là” (either-or), vì theo ngữ nghĩa của chúng, chúng loại trừ mọi trường hợp ngoại lệ thêm vào.
Danh từ hóa (Nominalizations): Khi một danh từ được dẫn xuất từ một động từ (ví dụ: “xác thực — authentication” từ “xác thực — to authenticate”), các nhà ngôn ngữ học gọi đây là danh từ hóa. Khi đặc tả yêu cầu, Kỹ sư Yêu cầu cần xử lý danh từ hóa cẩn thận vì nó có thể che giấu các yêu cầu chưa được đặc tả. Ví dụ, yêu cầu “Chỉ sau khi xác thực thành công, hệ thống mới cấp cho người dùng quyền truy cập vào (…)” ngụ ý rằng một quy trình để xác thực người dùng hợp lệ đã tồn tại. Do đó, khi viết yêu cầu như vậy, Kỹ sư Yêu cầu phải kiểm tra xem có cả các yêu cầu về quy trình xác thực người dùng hợp lệ hay không.

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.

⚠️ BẪY ĐỀ THI

— Đ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)

⚠️ BẪY ĐỀ THI

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.

Như đã đề cập ở Mục 3.2, sử dụng 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, từ đó giảm thiểu một số điểm yếu của ngôn ngữ tự nhiên trong viết kỹ thuật. Một mẫu là một loại bản thiết kế sẵn cho cấu trúc cú pháp của một sản phẩm công việc. Khi sử dụng ngôn ngữ tự nhiê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ột mẫu câu cung cấp một cấu trúc khung xương với các chỗ điền (placeholders), trong đó Kỹ sư Yêu cầu điền vào các chỗ trống để có được những câu có cấu trúc tốt, đồng nhất nhằm thể hiện các yêu cầu. Sử dụng mẫu câu là thực hành tốt nhất khi viết các yêu cầu đơn lẻ bằng ngôn ngữ tự nhiên và khi viết user story.

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 xây dựng hành động với mẫu này, các quy ước sau về việc sử dụng trợ động từ thường được 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.

📌 GHI CHÚ Ô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

⚠️ BẪY ĐỀ THI

“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 vật lý–không gian mạng (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.

📌 GHI CHÚ Ô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.

⚠️ BẪY ĐỀ THI

— 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 sử dụng để cấu trúc các sản phẩm công việc có kích thước vừa, chẳng hạn như các use case. Cockburn [Cock2001] đã giới thiệu một mẫu biểu phổ biến cho use case. Lauesen [Laue2002] đề xuất một mẫu 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ể được chia nhỏ thành một 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)
Điều kiện kết thúc thành công (Success end condition)
Điều kiện kết thúc thất bại (Failed end condition)
Tác nhân chính (Primary actor)
Các tác nhân khác (Other actors)
Kích hoạt (Trigger)
Luồng chính (Normal flow)	`...`
Luồng thay thế (Alternate flows)
Phần mở rộng (Extensions)
Thông tin liên quan (Related information)

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

	Mẫu	Ví dụ
ID		R137.2
Mục tiêu (Goal)		Xác nhận đặt phòng ngay lập tức
Thang đo (Scale)		Thời gian trôi qua tính bằng giây (thang tỉ lệ)
Cách đo (Meter)		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)		Ít hơn 5 giây trong ít nhất 95% trường hợp
Mức chấp nhận (OK range)		Từ 0,5 đến 3 giây trong hơn 98% trường hợp
Mức mong muốn (Desired)		Í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.

📌 GHI CHÚ Ô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 trong bản gốc so sánh các yêu cầu văn bản trên với 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 tách của 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.

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 được khám phá thêm 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 một phần thực tế cần được tạo ra. Khái niệm “thực tế” bao gồm bất kỳ tập hợp các phần tử, hiện tượng hoặc khái niệm nào có thể tưởng tượng được, kể cả các mô hình khác. Phần thực tế được mô hình hóa được gọi là nguyên bản (original). Quá trình mô tả nguyên bản có thể là mô tả hoặc quy định:

Mô hình hóa mô tả (Descriptive modeling): Mô hình hóa nguyên bản đang tồn tại — thể hiện thực tế hiện tại và phản ánh các yêu cầu đang được đáp ứng. Nếu chưa có mô hình của nguyên bản, thì mô hình như vậy là kết quả của việc phân tích tình huống hiện tại.
Mô hình hóa quy định (Prescriptive modeling): Mô hình hóa nguyên bản cần được tạo ra — chỉ ra thực tế tương lai được kỳ vọng hoặc được yêu cầu. Nếu tồn tại mô hình mô tả cho tình huống đã cho, mô hình quy định có thể được dẫn xuất từ nguyên bản bằng cách chỉ ra những yêu cầu nào sẽ là mới, đã thay đổi, hoặc không còn cần thiết nữa. Mô hình quy định mô tả tình huống tương lai cuối cùng được mong muốn.

Thực tế có thể phức tạp. Nếu áp dụng “quá nhiều” chi tiết, một mô hình có thể khó nắm bắt. Thực tế phức tạp này có thể được đơn giản hóa bằng cách rút gọn lượng thông tin trong mô hình. Trong một mô hình, chúng ta có thể bỏ qua các thông tin không liên quan. Việc rút gọn lượng thông tin có thể giúp chúng ta hiểu thực tế tốt hơn và nắm bắt bản chất của thực tế dễ dàng hơn. Dựa trên mục đích dự định (thuộc tính đầu tiên), chỉ thông tin liên quan mới được hiển thị trong mô hình.

Lưu ý: nếu “quá nhiều” thông tin bị rút gọn, có thể tạo ra hình ảnh bị làm mờ hoặc sai lệch về thực tế. Do đó, cần cân nhắc cẩn thận lượng thông tin có thể rút gọn mà không làm bóp méo thực tế.

Có một số cách để rút gọn thông tin:

Bằng tổng hợp gộp nhóm (aggregation): Thông tin được tổng hợp để trở nên trừu tượng hơn — loại bỏ các chi tiết không liên quan và trở nên gọn hơn. Thông tin được, theo một cách nào đó, cô đọng lại.
Bằng lọc lựa (selection): Chỉ chọn thông tin liên quan, không phải tất cả, để chỉ ra chủ đề đang được xem xét. Trọng tâm là một phần cụ thể hoặc một số phần cụ thể của tổng thể.

Cả hai cách rút gọn thông tin cũng có thể được áp dụng kết hợp.

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ó những ưu điểm sau, trong số những ưu điểm khác:

Các phần tử và mối liên hệ của chúng dễ hiểu và dễ nhớ hơn. Một hình ảnh nói lên hơn ngàn chữ. Một hình ảnh, và cũng như một mô hình, có thể dễ nắm bắt và dễ nhớ hơn. Lưu ý rằng một mô hình không tự giải thích bản thân và cần thêm thông tin — tức là chú giải, ví dụ, kịch bản, v.v.
Tập trung vào một khía cạnh duy nhất giảm tải nhận thức cần thiết để hiểu các yêu cầu được mô hình hóa. Vì mô hình có mục đích cụ thể và lượng thông tin được rút gọn, việc hiểu thực tế được mô hình hóa có thể đòi hỏi ít nỗ lực hơn.
Ngôn ngữ mô hình hóa yêu cầu có cú pháp bị hạn chế làm giảm khả năng mơ hồ và thiếu sót. Vì ngôn ngữ mô hình hóa (cú pháp và ngữ nghĩa) đơn giản hơn — tức là có ít phần tử ký pháp hơn và các quy tắc ngôn ngữ chặt chẽ hơn so với ngôn ngữ tự nhiên — rủi ro nhầm lẫn và thiếu sót nhỏ hơn.
Tiềm năng cao hơn cho việc phân tích và xử lý tự động các yêu cầu. Vì ngôn ngữ mô hình hóa chính thức hơn (ít phần tử ký pháp hơn và quy tắc ngôn ngữ chặt chẽ hơn) so với ngôn ngữ tự nhiên, nó phù hợp hơn để tự động hóa việc phân tích hoặc xử lý yêu cầu.

Mặc dù có những ưu điểm lớn trong việc trực quan hóa yêu cầu bằng mô hình, mô hình cũng có những hạn chế:

Giữ cho các mô hình tập trung vào các khía cạnh khác nhau nhất quán với nhau là thách thức. Nếu nhiều mô hình được sử dụng để mô tả các yêu cầu, điều quan trọng là giữ các mô hình này nhất quán với nhau. Điều này đòi hỏi nhiều kỷ luật và phối hợp giữa các mô hình.
Thông tin từ các mô hình khác nhau cần được tích hợp để có sự hiểu biết toàn diện về yêu cầu. Nếu nhiều mô hình được sử dụng, tất cả mô hình phải được hiểu để có sự hiểu biết tốt về các yêu cầu.
Mô hình chủ yếu tập trung vào yêu cầu chức năng. Các mô hình để mô tả yêu cầu chất lượng và ràng buộc còn hạn chế nếu không thiếu vắng trong ngữ cảnh cụ thể. Các loại yêu cầu này cần được cung cấp bằng ngôn ngữ tự nhiên cùng với mô hình — ví dụ như một sản phẩm công việc riêng biệt.
Cú pháp bị hạn chế của ngôn ngữ mô hình hóa đồ họa có nghĩa là không phải mọi thông tin liên quan đều có thể được biểu diễn trong mô hình. Vì mô hình được tạo ra cho một mục đích và bối cảnh cụ thể, không phải lúc nào cũng có thể ghi lại tất cả yêu cầu trong mô hình hoặc nhiều mô hình. Các yêu cầu không thể biểu diễn bằng mô hình được thêm vào mô hình dưới dạng yêu cầu ngôn ngữ tự nhiên hoặc sản phẩm công việc riêng biệt.

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

📌 GHI CHÚ Ô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:

Đặc tả (thay thế) textual requirements
Phân tách thực tế phức tạp thành các khía cạnh rõ ràng
Diễn giải lại (paraphrase) requirements văn bản để cải thiện hiểu biết
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.

⚠️ BẪY ĐỀ THI

— 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 độ mà một phần tử mô hình đơn lẻ (đồ họa hoặc văn bản), biểu đồ yêu cầu hoặc mô hình yêu cầu tuân thủ các đặc tả cú pháp. Ví dụ, nếu một mô hình mô tả yêu cầu dưới dạng mô hình lớp chứa các phần tử mô hình không thuộc cú pháp, hoặc các phần tử mô hình bị sử dụng sai mục đích, điều này sẽ làm giảm chất lượng cú pháp của mô hình. Một bên liên quan của mô hình này — ví dụ như người kiểm thử — có thể hiểu sai thông tin được biểu diễn bởi mô hình, có thể dẫn đến các trường hợp kiểm thử không phù hợp. Các công cụ mô hình hóa yêu cầu cung cấp tính năng kiểm tra chất lượng cú pháp của mô hình.

Chất lượng ngữ nghĩa (Semantic quality) thể hiện mức độ mà một phần tử mô hình đơn lẻ (đồ họa hoặc văn bản), biểu đồ yêu cầu hoặc mô hình yêu cầu biểu diễn chính xác và đầy đủ các sự kiện. Cũng giống như trong ngôn ngữ tự nhiên, ngữ nghĩa cho ý nghĩa cho các từ. Nếu một thuật ngữ có thể có nhiều nghĩa khác nhau hoặc có nhiều thuật ngữ có cùng nghĩa, điều này có thể dẫn đến giao tiếp sai. Điều tương tự cũng áp dụng cho ngữ nghĩa của các phần tử mô hình. Nếu các phần tử mô hình bị hiểu sai hoặc áp dụng không đúng, mô hình có thể bị giải thích sai.

Chất lượng thực dụng (Pragmatic quality) thể hiện mức độ mà một phần tử mô hình đơn lẻ (đồ họa hoặc văn bản), biểu đồ yêu cầu hoặc mô hình yêu cầu phù hợp với mục đích dự định — tức là liệu mức độ chi tiết và mức độ trừu tượng có phù hợp với mục đích sử dụng dự định hay không và liệu mô hình phù hợp có được chọn so với miền hoặc ngữ cảnh không. Có thể đánh giá điều này nếu biết mục đích và các bên liên quan của biểu đồ. Các phiên bản trung gian của mô hình có thể được gửi đến các bên liên quan quan tâm để xác nhận liệu các biểu đồ có phù hợp với mục đích của họ không.

Trong quá trình xác nhận các yêu cầu, chất lượng của các biểu đồ mô hình hóa được sử dụng được đánh giá để đảm bảo rằng các biểu đồ này phù hợp với mục đích dự định và tính hữu ích của chúng.

3.4.1.6 Kết hợp ưu điểm của cả hai phương pháp

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

📌 GHI CHÚ Ô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.

⚠️ BẪY ĐỀ THI

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. 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ệ 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 đầu cuối (terminators): khách hàng, máy in và bộ quản lý tài chính. Đầu cuối cung cấp thông tin hoặc dịch vụ cho hệ thống được gọi là nguồn (source). Đầu cuối nhận thông tin hoặc dịch vụ từ hệ thống được gọi là đích (sink). Một đầu cuố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.

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) bắt đầu 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.

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.

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.

Một biểu đồ hoạt động UML diễn đạt luồng kiểm soát của các hoạt động của một (hệ thống con). Tư duy luồng xuất phát từ việc trực quan hóa mã chương trình bằng lưu đồ (theo [DIN66001], [ISO5807]). Điều này đã giúp các lập trình viên hình thành và hiểu các cấu trúc và luồng phức tạp trong chương trình. Với sự giới thiệu của UML [OMG2017], một mô hình đã được đưa ra để trực quan hóa các hoạt động và hành độ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 (xem Hình 3.9 trong bản gốc), bạn có thể thiết lập một biểu đồ hoạt động tuần tự đơn giản. 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) của hoạt động sử dụng các phần tử ký pháp cho fork và join node. Fork và join node được sử dụng cùng nhau và do đó thường được gọi là đồng bộ hóa (synchronization).

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. 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 yêu cầu lệnh in đượ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 (xem Hình 3.12 trong bản gốc) bao gồm:

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

📌 GHI CHÚ Ô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)

⚠️ BẪY ĐỀ THI

— 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

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

📌 GHI CHÚ Ô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)

⚠️ BẪY ĐỀ THI

— 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):

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.

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.

Trong thiết kế: Một thể hiện sơ bộ, bán phần 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 mang tính 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 độ trung thực 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. Các nguyên mẫu mang tính 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 mang tính thử 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. Các nguyên mẫu mang tính thử nghiệm không được sử dụng trong RE.
Các nguyên mẫu mang tính 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 tạo nguyên mẫu mang tính tiến hóa.

Các Kỹ sư Yêu cầu chủ yếu sử dụng các nguyên mẫu mang tính khám phá như một phương tiện để khơi gợi và thẩm định. Trong khơi gợi, các nguyên mẫu đóng vai trò như phương tiện đặc tả bằng ví dụ. Cụ thể, khi các bên liên quan không thể diễn đạt rõ ràng những gì họ muốn, một nguyên mẫu có thể minh chứng những gì họ sẽ nhận được, từ đó giúp họ định hình các yêu cầu của mình. Trong thẩm định, các nguyên mẫu là phương tiện mạnh mẽ để thẩm định tính thỏa đáng (xem Mục 3.8) của các yêu cầu.

Các nguyên mẫu mang tính khám phá có thể được xây dựng và sử dụng với các mức độ trung thực 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ó độ trung thực 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ó độ trung thực 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 chân 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ó độ trung thực 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 thuộc vào mức độ trung thực, các nguyên mẫu mang tính khám phá có thể là một sản phẩm công việc tốn kém. Các Kỹ sư Yêu cầu phải cân nhắc sự đánh đổi giữa chi phí xây dựng và sử dụng các nguyên mẫu với giá trị thu được, xét về mặt dễ dàng khơi gợi hơn và giảm thiểu rủi ro có các yêu cầu không thỏa đáng hoặc thậm chí sai lệch.

⚠️ BẪY ĐỀ THI

— 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).

📌 GHI CHÚ ÔN THI

3 mức Fidelity của Exploratory Prototype

Loại	Fidelity	Đặc điểm	Mục đích chính
Wireframe (paper prototype)	Low	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	Medium	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	High	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)

Rõ ràng, các Kỹ sư Yêu cầu nên phấn đấu viết ra những yêu cầu tốt đáp ứng các tiêu chí chất lượng đã cho. Các tài liệu tham khảo và tiêu chuẩn về RE cung cấp một tập hợp phong phú các tiêu chí chất lượng như vậy. Tuy nhiên, không có sự đồng thuận chung nào về việc những tiêu chí chất lượng nào sẽ được áp dụng cho các yêu cầu. Tập hợp các tiêu chí được trình bày trong tiểu mục này nhằm mục đích cung cấp một thực hành đã được kiểm chứng ở cấp độ nền tảng.

RE hiện đại tuân theo cách tiếp cận định hướng giá trị đối với các yêu cầu (xem Nguyên tắc 1 trong Chương 2). Do đó, mức độ mà một yêu cầu đáp ứng các tiêu chí chất lượng đã cho phải tương ứng với giá trị được tạo ra bởi yêu cầu đó. Điều này có hai hệ quả quan trọng:

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): việc đáp ứng yêu cầu bởi một hệ thống được triển khai có thể được kiểm tra một cách không thể tranh cãi, để các bên liên quan hoặc khách hàng có thể quyết định liệu một yêu cầu có được đáp ứng bởi hệ thống được triển khai hay không.

Tính thỏa đáng và tính có thể hiểu được là những tiêu chí chất lượng quan trọng nhất. Nếu không có chúng, một yêu cầu sẽ trở nên vô dụng hoặc thậm chí có hại, bất kể việc đáp ứng tất cả các tiêu chí còn lại. Tính có thể kiểm chứng là quan trọng khi hệ thống được triển khai phải trải qua một 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.

📌 GHI CHÚ Ô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.

⚠️ BẪY ĐỀ THI

“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): các yêu cầu trong sản phẩm công việc có thể được truy xuất ngược về nguồn gốc của chúng, truy xuất tiến đến việc triển khai chúng (trong thiết kế, mã nguồn và kiểm thử), và đến các yêu cầu khác mà chúng phụ thuộc vào.
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.

📌 GHI CHÚ Ô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

⚠️ BẪY ĐỀ THI

“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