Đặc tả Yêu cầu

Đặc tả yêu cầu là hoạt động ghi lại các yêu cầu đã được khơi gợi và phân tích dưới dạng chính xác, nhất quán và có thể kiểm chứng được, đóng vai trò là cơ sở thống nhất cho việc thiết kế, xây dựng và nghiệm thu.

Definition

Đặc tả yêu cầu là việc tạo ra một bản tài liệu thể hiện các yêu cầu hệ thống, được viết sao cho mỗi yêu cầu là không mơ hồ, có thể kiểm chứng và có thể truy vết, và toàn bộ tập hợp yêu cầu là nhất quán và đầy đủ.

Scope

Chủ đề này bao gồm cấu trúc và nội dung của một đặc tả yêu cầu phần mềm; các phong cách từ ngôn ngữ tự nhiên có cấu trúc đến các trường hợp sử dụng (use cases), câu chuyện người dùng (user stories) và các mô hình hình thức; các thuộc tính chất lượng của các yêu cầu tốt như không mơ hồ, đầy đủ, nhất quán và có thể kiểm thử được; và các tiêu chuẩn như ISO/IEC/IEEE 29148 quy định nội dung đặc tả.

Core questions

• Làm thế nào để các yêu cầu bằng ngôn ngữ tự nhiên trở nên không mơ hồ và có thể kiểm chứng?
• Khi nào thì các đặc tả hình thức hoặc dựa trên mô hình là đáng giá?
• Những thuộc tính chất lượng nào đặc trưng cho một đặc tả tốt?
• Các yêu cầu chức năng và phi chức năng nên được tổ chức như thế nào trong một tài liệu?

Key theories

Các thuộc tính chất lượng của yêu cầu

Các yêu cầu riêng lẻ nên không mơ hồ, có thể kiểm chứng, khả thi và cần thiết, trong khi tập hợp các yêu cầu nên đầy đủ, nhất quán và có thể truy vết; những thuộc tính này cung cấp các tiêu chí cụ thể để xem xét một đặc tả.

Đặc tả hình thức so với đặc tả không hình thức

Các đặc tả có thể từ ngôn ngữ tự nhiên có cấu trúc và các trường hợp sử dụng đến các ký hiệu toán học hình thức; tính hình thức làm tăng độ chính xác và khả năng phân tích nhưng phải trả giá bằng công sức và khả năng tiếp cận, vì vậy mức độ được chọn để phù hợp với rủi ro và đối tượng.

Clinical relevance

Một đặc tả rõ ràng là hợp đồng giữa các bên liên quan và nhà phát triển, đồng thời là tài liệu tham khảo để xác minh; sự mơ hồ hoặc thiếu sót trong đặc tả có thể dẫn đến các thiết kế lỗi và tranh chấp về những gì đã được hứa hẹn.

Evidence & guidelines

ISO/IEC/IEEE 29148 định nghĩa cấu trúc và đặc tính chất lượng được khuyến nghị của các đặc tả yêu cầu và là tiêu chuẩn chính điều chỉnh nội dung của chúng.

History

Các đặc tả ban đầu chủ yếu là văn xuôi tự do; tiêu chuẩn IEEE 830 đã chính thức hóa đặc tả yêu cầu phần mềm vào những năm 1990, và các công trình sau này đã giới thiệu các trường hợp sử dụng, câu chuyện người dùng, và các ký hiệu dựa trên mô hình và hình thức, đỉnh điểm là tiêu chuẩn ISO/IEC/IEEE 29148 hợp nhất.

Debates

Tài liệu nặng ký so với câu chuyện người dùng nhẹ ký

Thực hành theo định hướng kế hoạch ưu tiên các tài liệu đặc tả toàn diện, trong khi thực hành linh hoạt (agile) ưu tiên các câu chuyện người dùng nhẹ ký được xây dựng kịp thời; sự lựa chọn này đánh đổi sự kỹ lưỡng và rõ ràng về mặt hợp đồng với khả năng thích ứng và giảm chi phí tài liệu.

Key figures

• Axel van Lamsweerde
• Michael Jackson
• Ian Sommerville

Seminal works

• iso29148
• vanlamsweerde2009
• sommerville2015

Frequently asked questions

Điều gì làm cho một yêu cầu có thể kiểm thử được?

Một yêu cầu có thể kiểm thử được khi nó được nêu đủ chính xác để một quy trình khách quan có thể xác định liệu hệ thống được bàn giao có đáp ứng nó hay không; các thuật ngữ mơ hồ như nhanh hoặc thân thiện với người dùng phải được định lượng hoặc đưa ra các tiêu chí chấp nhận có thể đo lường được.

Các câu chuyện người dùng có thay thế đặc tả yêu cầu không?

Các câu chuyện người dùng là một phong cách đặc tả nhẹ nhàng phù hợp với phát triển lặp đi lặp lại, nhưng chúng vẫn yêu cầu các tiêu chí chấp nhận và, đối với các hệ thống phức tạp hoặc được quy định, thường được bổ sung bằng tài liệu chi tiết hơn để đảm bảo tính đầy đủ và khả năng truy vết.