GB/T 45804-2025Software and systems engineering - Tools and methods for product line requirements engineering (English PDF)

Foreword

This document is in accordance with the provisions of GB/T 1.1-2020 "Guidelines for standardization work Part 1: Structure and drafting rules for standardization documents" Drafting.

This document is equivalent to ISO/IEC 26551:2016 "Tools and methods for software and systems engineering product line requirements engineering".

The following minimal editorial changes were made to this document.

--- There are errors in the numbered notes after the terms in the original text of Chapter 3 Terms and Definitions. They have been corrected. 3.8 is changed to 3.9, and 3.12 is changed to 3.13;

---In accordance with the requirements for drafting national standards in my country, add introductory words before the items and tables;

--- According to the requirements of drafting national standards of my country, the header format of Table A.1 has been modified.

Introduction

The primary purpose of this document is to establish a baseline for tool and method capabilities for Software and System Product Line (SSPL) Requirements Engineering.

To define the scope of the product line, decisions are made about the original boundaries of the domain before starting the domain requirements engineering process.

Requirements and defined variability have an indirect impact on the products in the product line, so domain requirements engineering is performed in a comprehensive manner.

The results of the requirements engineering process are converted into product family requirements in the application of requirements engineering process. Therefore, when considering requirements engineering tools and methods, when designing a new application, it is necessary to consider both domain requirements engineering and application requirements engineering.

The reasons why product line requirements engineering can be distinguished from single product requirements engineering are as follows.

---There are two core processes in requirements engineering. domain requirements engineering and application requirements engineering. The main goals of the domain requirements engineering process are it is to analyze the commonality and variability of product families and prepare the necessary variability information for variability modeling. Application Requirements Engineering Process the main goal is to define the specific requirements of the application and relate them to the variability defined in the domain requirements engineering process.

---The cost and benefit estimation analysis of product lines is crucial for organizations to make key decisions. Therefore, cost and benefit estimation is a Metrics play a key role in assessing the effectiveness and efficiency of product lines.

Appendix A describes in detail the task differences between single product requirements engineering and product line requirements engineering.

Software and Systems Engineering Tools and methods for product line requirements engineering

1 Scope

This document is within the scope of Tools and Methods for Software and System Product Line Requirements Engineering.

--- Provide specific terms and definitions for requirements engineering of software and system product lines and related member products;

---Define the process groups and processes performed in product line requirements engineering (these processes are performed based on purpose, input, tasks and output describe);

--- Define method capabilities to support the defined tasks of each process;

---Define tool capabilities to automate or semi-automate tasks or defined method capabilities.

This document focuses on the processes and capabilities of requirements tools and methods for families of products rather than for single systems.

This document does not apply to physical artifacts. System-level artifacts and software life cycle artifacts, such as requirements documents, architecture data, verification plans, for the software components of the system, this document is applicable to the system elements that process the product line.

and the software elements used to process the product line, if any. The product line process is recursive across the different levels of products.

Note. This document applies to a family of systems, software or services.

2 Normative references

This document has no normative references.

3 Terms and definitions

The following terms and definitions apply to this document.

Application-specific artifacts produced during the application requirements engineering process, such as application requirements specifications (3.4) and application requirements models.

The sub-process of identifying stakeholders related to the application, obtaining application-specific requirements and binding appropriate variants.

The subprocess of understanding all application-specific requirements (3.9) is to scrutinize incorrect and inconsistent application requirements through modeling and to analyze and negotiate application requirements that cannot be met through domain requirements.

The subprocess of documenting application-specific requirements (3.9) and integrating them with the domain requirements specification (3.13), the domain requirements specification the variant is bound.