Path:
Home >
GB/T >
Page216 > GB/T 45804-2025
Price & Delivery
US$1174.00 · In stock · Download in 9 secondsGB/T 45804-2025: Software and systems engineering - Tools and methods for product line requirements engineering
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See
step-by-step procedureStatus: Valid
| Std ID | Version | USD | Buy | Deliver [PDF] in | Title (Description) |
| GB/T 45804-2025 | English | 1174 |
Add to Cart
|
3 days [Need to translate]
|
Software and systems engineering - Tools and methods for product line requirements engineering
|
Click to Preview a similar PDF
Basic data
| Standard ID | GB/T 45804-2025 (GB/T45804-2025) |
| Description (Translated English) | Software and systems engineering - Tools and methods for product line requirements engineering |
| Sector / Industry | National Standard (Recommended) |
| Classification of Chinese Standard | L77 |
| Classification of International Standard | 35.080 |
| Word Count Estimation | 58,557 |
| Date of Issue | 2025-05-30 |
| Date of Implementation | 2025-12-01 |
| Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration |
GB/T 45804-2025: Software and systems engineering - Tools and methods for product line requirements engineering
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
ICS 35.080
CCSL77
National Standard of the People's Republic of China
Software and Systems Engineering
Tools and methods for product line requirements engineering
(ISO /IEC 26551.2016, IDT)
Released on 2025-05-30
2025-12-01 Implementation
State Administration for Market Regulation
The National Standardization Administration issued
Table of contents
Preface III
Introduction IV
1 Scope 1
2 Normative references 1
3 Terms and Definitions 1
4 Product Line Requirements Engineering Reference Model 3
5 Product Line Scoping 6
5.1 Product Scope Definition 6
5.2 Field Scope Definition 9
5.3 Asset Scope Definition10
6 Domain Requirements Engineering12
6.1 Domain Requirements Acquisition 13
6.2 Domain Requirements Analysis 15
6.3 Domain Requirements Specification 18
6.4 Domain Requirements Verification and Validation 20
6.5 Domain Requirements Management 22
7 Requirements Engineering Variability Management 25
7.1 Text Requirements Variability 25
7.2 Demand Model Variability 26
7.3 Demand variability mechanism 27
7.4 Traceability between Requirement Variability and Variability Models 29
8 Requirements Engineering Asset Management 30
8.1 Domain Demand Artifacts as Domain Assets 30
8.2 Application Requirements Artifacts as Application Assets 31
9 Application Requirements Engineering 32
9.1 Application Requirements Acquisition 33
9.2 Application Requirements Analysis 35
9.3 Application Requirements Specification 38
9.4 Application Requirements Verification and Validation 40
9.5 Application Requirements Management 42
Appendix A (Informative) Comparison of Requirements Engineering Tasks for Single Products and Product Lines 45
Appendix B (Informative) ISO /IEC 12207, ISO /IEC /IEEE15288 and ISO /IEC /IEEE29148 process mapping 47
Appendix C (Informative) Relationship between processes, methods, tools and aspects 50
References 51
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.
Please note that some of the contents of this document may involve patents. The issuing organization of this document does not assume the responsibility for identifying patents.
This document was proposed and coordinated by the National Information Technology Standardization Technical Committee (SAC/TC28).
This document was drafted by. China Shipbuilding Industry Corporation 709th Research Institute, China Electronics Technology Standardization Institute, Beijing Software
Information Service Exchange Co., Ltd., Inspur Software Technology Co., Ltd., CSSC Lingjiu Electronics (Wuhan) Co., Ltd., Yunnan Power Grid
Information Center of Hangzhou Times Yintong Software Co., Ltd., Shanghai Xuanyi Technology Co., Ltd., Hunan Yunjian Group Co., Ltd.
Corporation, National Application Software Product Quality Inspection and Testing Center, Chongqing Software Evaluation Center Co., Ltd., China Aerospace System Science and Engineering Research Institute
Institute, Shanghai Pai Rui Information Technology Co., Ltd., Shandong Shanke Digital Economy Research Institute Co., Ltd., Guangdong Science and Technology Basic Conditions Platform Center,
Beijing Guqi Data Technology Co., Ltd., Kunlun Digital Intelligence Technology Co., Ltd., Shanghai Chuangjing Information Technology Co., Ltd., Lenovo
(Beijing) Co., Ltd., Chengdu Songxing Technology Co., Ltd., Southwest Computer Co., Ltd., CSSC Lingjiu Hi-Tech (Wuhan) Co., Ltd.
Shenzhen Open Source Internet Security Technology Co., Ltd., Zhongkong Technology Co., Ltd., China Testing and Certification Group Co., Ltd., Beijing
Shenzhou Aerospace Software Technology Co., Ltd., Beijing University of Technology, Hefei Tianyuan Dico Information Technology Co., Ltd., China Civil Aviation Information Network
Co., Ltd., Hubei Huazhong Electric Power Technology Development Co., Ltd., Qiming Information Technology Co., Ltd., China Mobile Internet Co., Ltd.
Co., Ltd., Lai Future Technology (Zhejiang) Co., Ltd., Shenzhen Lianyou Technology Co., Ltd., and Hebei CRRC Digital Technology Co., Ltd.
The main drafters of this document are. Huang Jihong, Yang Mengpei, Ding Yilin, Zhang Yangyang, Su Wei, Li Wenpeng, Zhang Chuanqi, Sui Yaqian, Chen Huanxin, Zeng Lingjiang,
Li Lingfan, Chen Min, Zhao Bin, Hao Lin, Wu Wei, Zhao Changjun, Huang Zhongnian, Zheng Xufei, Li Shulin, Ni Hao, Wu Dilong, Feng Zhengqian, Long Lianghua, Dong Dai,
Zhang Wenyuan, Zheng Yongsheng, Wang Zhidong, Zhao Yang, Wang Tiejun, Liu Libing, Lu Debo, Wang Jie, Zheng Erlei, Deng Xiong, Wang Nan, Liu Xiaojian, Xing Tongkun, Yu Xiaodong,
Xingyong Hu, Jing Pang, Hui Qiang, Wenqing Sun, Lin Zhu, Li Lou, Yan Sun, Yijin Li, Yuliang Zhang, Juan Luo, Yingmei Xu, Xiaojing Lü, Yongli Hu, and Siyu Hua.
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.
3.1
Application-specific artifacts produced during the application requirements engineering process, such as application requirements specifications (3.4) and application requirements models.
3.2
The sub-process of identifying stakeholders related to the application, obtaining application-specific requirements and binding appropriate variants.
3.3
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.
3.4
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.
...
