Từ điển học thuật Kỹ thuật và công nghệ

Requirements là gì? Các công bố khoa học về Requirements

Tiếng AnhSoftware and systems requirements engineering

Requirements (yêu cầu phần mềm và hệ thống) là các đặc tả mô tả các tính năng chức năng, ràng buộc vận hành và thuộc tính chất lượng mà một hệ thống phải đáp ứng để giải quyết vấn đề của các bên liên quan.

284 lượt xem Cập nhật 10/9/2026

Requirements (software and systems requirements engineering) trong kỹ nghệ phần mềm và hệ thống là tập hợp các phát biểu đặc tả những tính năng, hành vi chức năng, ràng buộc vận hành và thuộc tính chất lượng mà một hệ thống thông tin phải thỏa mãn nhằm giải quyết các bài toán thực tế của các bên liên quan (stakeholders). Quản trị yêu cầu là giai đoạn quyết định trực tiếp đến sự thành bại và chi phí của toàn bộ dự án công nghệ.

Phân loại yêu cầu phần mềm chuẩn hóa

Theo chuẩn kỹ nghệ phần mềm quốc tế ISO/IEC/IEEE 29148, các yêu cầu hệ thống được phân định rõ ràng thành các cấp độ và phân loại:

  • Yêu cầu nghiệp vụ (Business Requirements): Các mục tiêu chiến lược cấp cao và chỉ số hiệu quả kinh doanh cốt lõi (KPIs/ROI) mà tổ chức mong muốn đạt được khi phát triển sản phẩm.
  • Yêu cầu người dùng (User Requirements): Mô tả những tác vụ, luồng công việc và trải nghiệm mà người dùng đầu cuối có thể thực hiện với hệ thống (thường được biểu đạt qua User Stories hoặc Use Cases).
  • Yêu cầu chức năng (Functional Requirements - FRs): Đặc tả chi tiết các dịch vụ phần mềm, thuật toán xử lý dữ liệu, quy tắc nghiệp vụ (business rules) và phản ứng của hệ thống đối với các dữ liệu đầu vào xác định.
  • Yêu cầu phi chức năng (Non-Functional Requirements - NFRs): Các thuộc tính chất lượng và ràng buộc kỹ thuật của hệ thống, bao gồm hiệu năng (performance), độ tin cậy (reliability), khả năng mở rộng (scalability), tính sẵn sàng (availability), bảo mật an toàn thông tin (security) và tính khả dụng (usability).

Vòng đời kỹ nghệ yêu cầu (Requirements Engineering Life Cycle)

Quá trình kỹ nghệ yêu cầu là một chuỗi hoạt động kỹ thuật có tính lặp và phối hợp chặt chẽ:

Giai đoạn kỹ thuật Mục tiêu hoạt động Kỹ thuật và công cụ áp dụng
Khơi gợi yêu cầu (Elicitation) Khai phá nhu cầu tiềm ẩn của khách hàng và người sử dụng Phỏng vấn chuyên gia, hội thảo Joint Application Design (JAD), khảo sát, quan sát thực địa
Phân tích & Đàm phán (Analysis & Negotiation) Phát hiện xung đột, loại bỏ yêu cầu mơ hồ và phân tầng mức độ ưu tiên Mô hình hóa dữ liệu (DFD, ERD, UML), kỹ thuật phân loại MoSCoW, ma trận ưu tiên Eisenhower
Đặc tả yêu cầu (Specification) Văn bản hóa các yêu cầu thành tài liệu quy chuẩn kỹ thuật Tài liệu đặc tả yêu cầu phần mềm (SRS), mẫu User Story định dạng 'As a / I want / So that'
Xác minh & Thẩm định (Verification & Validation) Kiểm tra tính hoàn chỉnh, nhất quán, khả thi và khả năng kiểm thử được Đánh giá ngang hàng (peer review), thanh tra tài liệu (inspection), tạo mẫu nguyên mẫu nhanh (prototyping)

Quản lý yêu cầu và ma trận truy xuất nguồn gốc (Traceability Matrix)

Trong các mô hình phát triển phần mềm Agile lẫn Waterfall, quản lý yêu cầu (Requirements Management) bảo đảm sự kiểm soát chặt chẽ đối với các yêu cầu thay đổi:

  • Ma trận truy xuất nguồn gốc yêu cầu (Requirements Traceability Matrix - RTM): Một bảng ánh xạ hai chiều liên kết từ mục tiêu nghiệp vụ ban đầu, qua các trường hợp sử dụng (use cases), kiến trúc thiết kế, mã nguồn cài đặt cho đến các kịch bản kiểm thử nghiệm thu (acceptance test cases). RTM đảm bảo không có yêu cầu nào bị bỏ sót và không có mã nguồn thừa không phục vụ mục tiêu hệ thống.
  • Quản lý thay đổi phạm vi (Scope Management): Kiểm soát hiện tượng trôi dạt phạm vi (scope creep) thông qua quy trình phê duyệt thay đổi chính thức (Change Control Board - CCB) hoặc sắp xếp lại thứ tự ưu tiên trong Product Backlog ở mỗi vòng lặp Sprint.

Câu hỏi thường gặp

Sự khác nhau căn bản giữa Tiêu chuẩn nghiệm thu (Acceptance Criteria) và Yêu cầu chức năng?

Yêu cầu chức năng mô tả hành vi tổng thể mà hệ thống cần thực hiện; trong khi Tiêu chuẩn nghiệm thu (thường viết dưới dạng Given-When-Then) xác định các điều kiện biên và kịch bản cụ thể mà tính năng phải vượt qua để được Product Owner chấp thuận hoàn thành.

Ma trận MoSCoW phân loại mức độ ưu tiên của các yêu cầu theo những nhóm nào?

MoSCoW phân loại thành 4 mức: Must have (Bắt buộc phải có trong bản phát hành), Should have (Nên có nếu có đủ nguồn lực), Could have (Có thể có nếu không ảnh hưởng tiến độ) và Won't have (Chưa thực hiện trong lần phát hành này nhưng xem xét trong tương lai).

Tại sao việc sửa chữa lỗi sai sót về yêu cầu ở giai đoạn vận hành lại tốn kém gấp 50-100 lần so với giai đoạn phân tích ban đầu?

Theo nghiên cứu của Barry Boehm, lỗi yêu cầu bị phát hiện muộn ở giai đoạn triển khai đòi hỏi phải đập bỏ và làm lại toàn bộ kiến trúc, thiết kế cơ sở dữ liệu, viết lại hàng nghìn dòng code và chạy lại toàn bộ quy trình kiểm thử liên quan, gây lãng phí nguồn lực khổng lồ.

Tài liệu tham khảo

  1. Panichella, Ruiz (2020). Requirements-Collector: Automating Requirements Specification from Elicitation Sessions and User Feedback. 2020 IEEE 28th International Requirements Engineering Conference (RE). DOI: 10.1109/re48521.2020.00057
  2. Schnitzhofer, Schnitzhofer, Ramler (2014). Tool Support for Reuse-Driven Elicitation and Specification of User Requirements. 2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications. DOI: 10.1109/seaa.2014.73
  3. Alagić (2017). Software Verification. Software Engineering: Specification, Implementation, Verification. DOI: 10.1007/978-3-319-61518-9_6