|
US$779.00 · In stock
Delivery: <= 6 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 25000.30-2021: Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30: Quality requirements framework
Status: Valid
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 25000.30-2021 | English | 779 |
Add to Cart
|
6 days [Need to translate]
|
Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30: Quality requirements framework
| Valid |
GB/T 25000.30-2021
|
PDF similar to GB/T 25000.30-2021
Basic data | Standard ID | GB/T 25000.30-2021 (GB/T25000.30-2021) | | Description (Translated English) | Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30: Quality requirements framework | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | L77 | | Word Count Estimation | 42,442 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | GB/T 25000.30-2021: Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30: Quality requirements framework
---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.
Systems and software engineering - Systems and software quality requirements and evaluation(SQuaRE) - Part 30.Quality requirements framework
ICS 35.080
L77
National Standards of People's Republic of China
System and Software Engineering
System and Software Quality Requirements and Evaluation (SQuaRE)
Part 30.Quality Requirements Framework
[ISO /IEC 25030.2019,Systemsandsoftwareengineering-
Released on 2021-04-30 and implemented on 2021-11-01
State Administration of Market Supervision and Administration
Issued by the National Standardization Management Committee
Table of contents
Foreword Ⅰ
Introduction Ⅲ
1 Scope 1
2 Normative references 1
3 Terms and definitions 2
4 Abbreviations 4
5 Compliance 4
6 Concept of quality requirements 4
7 Quality requirements process 5
8 Use and control quality requirements 14
Appendix A (informative appendix) Examples of quality levels required for different ICT products (using decision table format) 16
Appendix B (informative appendix) Example of the relationship between product quality characteristics 18
Appendix C (informative appendix) and GB/T 22032-2021 (system life cycle process) relationship 19
Appendix D (informative appendix) The relationship between this part and ISO /IEC /IEEE29148.2018 (requirements engineering process) 21
Appendix E (informative appendix) Recommended process for quality requirements extraction 25
Appendix F (Informative Appendix) Stakeholders --- Example Target Matrix 29
Appendix G (informative appendix) Example of mapping quality requirements to quality characteristics 31
Appendix H (informative appendix) Derive product quality requirements from use quality requirements 33
Appendix I (informative appendix) Examples of prescribed quality requirements 34
Appendix J (informative appendix) Examples of deployment and traceability from quality requirements to software 35
Reference 36
System and Software Engineering System and Software
Quality Requirements and Evaluation (SQuaRE)
Part 30.Quality Requirements Framework
1 Scope
This part of GB/T 25000 provides a framework of quality requirements for systems, software products and data, including the concept of quality requirements, and
And the process and method of extracting, defining and controlling them. The intended readers of this section include but are not limited to.
--- Demand-side. Evaluate whether the system, software products and data meet their value proposition, that is, whether they meet the expected quality;
---Developer. design, implement and test systems, software products and data to ensure that they meet the expected quality;
---Testing party. verify and confirm whether the system, software products and data meet the expected quality;
---Project management party. plan, supervise and control the progress of expected quality;
--- Independent evaluation party. evaluate the system, software products and data according to objective criteria.
This part follows the technical process defined in GB/T 22032, which is related to the quality requirements of the selected stakeholders, and is related to the quality requirements.
The required analysis and definition are related to maintenance. In this part, the quality models of GB/T 25000.10 and GB/T 25000.12 are used to
Requirements are classified, and according to GB/T 25000.20, GB/T 25000.21, GB/T 25000.22, GB/T 25000.23 and
The quality measurement in GB/T 25000.24 lays the foundation for quantifying quality requirements.
This section does not include the definition of other requirements (such as functional requirements, process requirements, etc.). This section does not specify any specific software quality test
Degree, nor does it stipulate a specific development process.
2 Normative references
The following documents are indispensable for the application of this document. For dated reference documents, only the dated version applies to this article
Pieces. For undated reference documents, the latest version (including all amendments) is applicable to this document.
GB/T 22032 System and Software Engineering System Life Cycle Process (GB/T 22032-2021, ISO /IEC /
IEEE15288.2015, IDT)
GB/T 25000.1-2021 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 1.
SQuaRE Guide (ISO /IEC 25000.2014, MOD)
GB/T 25000.10-2016 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 10.
System and software quality model (ISO /IEC 25010.2011, MOD)
GB/T 25000.12-2017 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 12.
Data quality model (ISO /IEC 25012.2008, MOD)
GB/T 25000.22-2019 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 22.
Use quality measurement (ISO /IEC 25022.2016, MOD)
GB/T 25000.23-2019 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 23.
System and software product quality measurement (ISO /IEC 25023.2016, MOD)
GB/T 25000.24-2017 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 24.
Data quality measurement (ISO /IEC 25024.2015, MOD)
ISO /IEC TR12182.2015 System and Software Engineering IT System and Classification Framework Software and Application Guidelines (Systemand
Can be used to measure inherent or system-dependent properties.
6.5 Important considerations for quality requirements
6.5.1 Sources of quality requirements
Two types of needs should be considered according to the source of ICT products.
Directly obtained from the requirements of the relevant parties in their respective fields) and ICT requirements (due to the use of certain ICT technology solutions in the design process)
New requirements introduced). Quality requirements also include the same types.
For example. the use of a web-based system (ICT technology solution) involves some user needs, such as clicking in the browser
How the system responds after the back button (functional requirements), self-description of the user interface (PQR. easy to learn) and browser compatibility (PQR).
6.5.2 Categories of ICT products
There are differences in quality requirements between different ICT products. Therefore, it is better to determine which quality characteristics have higher priority and appropriate
When questioning which quality measures to use, it is important to consider the target system category.
ISO /IEC TR12182 provides a framework for the classification of ICT products, including a set of typical classification axes. These classification axes are in the first layer.
It is organized into five axes by level. target system's architecture/infrastructure, attributes, operating environment, data and stakeholders. These classification axes can
Used to determine which quality features have higher priority. Classification axes that are important for prioritization include.
a) Function (and its problem framework);
b) The key points of the system and data;
c) Characteristics of stakeholders.
Note. Appendix A lists examples of IT decisions that support the required quality level.
6.5.3 Interrelationship with functional requirements/data requirements
Quality requirements cannot be defined and analyzed separately from functional requirements and data requirements. Some quality requirements are attached to functional requirements or data requirements;
In addition, some quality requirements are fulfilled by specifying new functional requirements.
Example 1.Quality requirements attached to functional requirements.
Time efficiency (response time) is defined as the response time of the function.
Example 2.Quality requirements achieved by specifying new functional requirements.
a) Some confidentiality requirements are realized through access control function requirements;
b) Some ease-of-learning requirements are realized through help function requirements;
c) Some easy-to-analyze requirements are realized by recording functional requirements.
Note 1.Unlike functional requirements, most quality requirements represent the emergency attributes of the system, which appear on a set of components, rather than a specific component
on. Therefore, it is difficult to establish and maintain the traceability of quality requirements, and therefore need to be implemented and verified with confidence throughout the product life cycle.
Product requirements cannot be defined separately from data requirements. ICT products consume and generate data. Quality requirements (product quality requirements or data
Quality requirements) can develop into product quality requirements/data quality requirements with the decomposition of the system.
Note 2.From the perspective of ICT products, there are three types of data. external input and/or output data, internal component storage data and internal configuration data.
Note 3.The following is an example of the interdependence of ICT products and data, and the relationship between their PQR and DQR.
a) The configuration data file is written for the configuration of ICT products. Its DQR (e.g., flexibility requirements) is the functional and quality requirements that ICT products need to meet
determine;
b) Customer data is used as the input of the business support system, and its quality (for example, accuracy) affects the product quality of the system (for example, ease of operation and correct function
Sex);
c) The data exchanged between the software components of ICT products and their DQR (e.g., efficiency) has an impact on the implementation methods and product quality (e.g., time) of ICT products.
Time efficiency) has a great impact.
7.2 Overview of the quality requirement process
The requirements-related "stakeholder requirements and requirements definition process" and "system requirements definition" defined in GB/T 22032 should be used.
Process” to extract, define, analyze and maintain quality requirements. Through the process in Figure 5, the requirements of stakeholders will be extracted and transformed into a system.
System requirements.
Note 1.System and software products are regarded as ICT products in this section.
The stakeholder requirements and requirements definition process identifies the stakeholder or a class of stakeholder involved in the entire life cycle of the system
Party and its requirements. It analyzes and transforms these requirements into a set of common stakeholder requirements that express the system and its operation
The expected interaction between environments is the benchmark for verifying the ability of each result to run. For the target system, use the use quality model
And measurement, the quality requirements that are part of the requirements of the stakeholders are extracted, and then converted into QUIR, as the part of the stakeholders
demand.
The system requirements definition process creates a set of measurable system requirements. From the perspective of the supplier, these requirements specify the system to have
Which characteristics, attributes, functions and performance requirements to meet the needs of stakeholders. To meet the needs of stakeholders, use products and data
According to the quality model and measurement, PQR and DQR are defined and analyzed as part of the system requirements.
Note 2.The detailed relationship with GB/T 22032 and ISO /IEC /IEEE29148 is described in Appendix C and Appendix D, respectively. ISO /IEC /IEEE29148
Link the above two related processes with the processes in ISO /IEC 12207 (another international standard that defines software life cycle processes).
Note 3.The iteration and recursion in requirements engineering are described in ISO /IEC /IEEE29148.The requirements, architecture, and design process can be applied iteratively to the system
The same level of the system in order to resolve the trade-offs between requirements and architecture. This set of procedures can also be applied recursively to successive levels of the system structure
System elements to successfully simplify system engineering.
Note 4.Generally speaking, quality requirements are more stable than functional requirements in the product life cycle; but they can also be changed, for example, if new functions are added, they need to be
To change the security requirements, if the environment changes even a little bit, you must reconsider the ease of operation requirements.
Note 5.According to the definition of ISO /IEC /IEEE29148, stakeholder requirements can be recorded in StRS, and system and software requirements can be recorded in SyRS respectively
And SRS.
7.3 Extraction of quality requirements
7.3.1 Identify stakeholders
This article deals with activities that use the stakeholder requirements and requirements in GB/T 22032 to define the process a) "Prepare stakeholder requirements
And requirements definitions" to identify stakeholders (see Appendix C).
The representatives of all stakeholder groups who are potential sources of quality requirements should be identified, and if possible, participate in the extraction of these representatives.
table. Table 2 describes which type of quality requirements originate from which type of stakeholders and users.
Table 2 Types of stakeholders and quality requirements
Users with quality requirements (developers, purchasers/independent evaluators, etc.) have the responsibility to establish and maintain quality requirements, so they should consider cooperation with the society.
The relevant anti-risk needs, which (who should be) are the groups affected by the system, and which cannot directly become the source of demand.
Note. Stakeholders can be regarded as a role, so a person or organization can have multiple roles. In addition, stakeholders should not belong to a specific type
organization. For example, in the case of developing a consumer product, the acquirer and the developer can belong to the same company to consider any of the people affected by the system.
risk.
7.3.2 Define stakeholder requirements
This article relates to the activities of the stakeholder requirements and requirements definition process in GB/T 22032.b) “Define stakeholder requirements” (refer to
See Appendix C).
The assumed usage environment of the target information system and the quality requirements in the usage environment should be extracted from the identified stakeholders. Such as
If the existing system exists, it should also be extracted from the analysis of the experience feedback of stakeholders using the system.
Note 1.Appendix E provides a recommended process for the extraction of quality requirements.
Note 2.In this case, the quality requirements are mainly related to the quality of use.
Note 3.The requirements of stakeholders include not only clearly stated content, but also implicit or unknown content. In order to be exhaustive in a specific context of use
To extract relevant stakeholder requirements, you can use stakeholder-target matrix, as shown in Appendix F.
The quality requirements of the selected stakeholders should be prioritized and selected on this basis. Among them, the category of ICT products should be considered.
Do not (6.5.2) to determine which quality characteristics are important to the target entity.
Note 4.Since different stakeholders have different requirements for the target system, the requirements of the stakeholders may be inconsistent and/or incomplete; therefore, should
Check all prepared requirements to define, analyze and maintain the needs of a group of stakeholders.
Note 5.Due to some commercial reasons, not all stakeholder requirements can be selected to define stakeholder requirements. For example, software package providers can
After weighing the development cost and the impact on the market, it was decided not to implement certain user requirements in the software package.
Note 6.For consumer products, market segmentation techniques can be used to identify user subgroups that share common needs and preferences.
The quality requirements of the acquirer can be recorded as part of the requirements of its stakeholders, as well as its owner and necessary evidence.
7.4 Define quality requirements steps
7.4.1 General description
The quality requirements should be clearly and clearly defined, and where appropriate, the quality requirements should be defined quantitatively, so as to avoid the emergence of main factors that depend on understanding.
Observing judgments and unverifiable needs.
Figure 6 shows the steps that define all types of quality requirements for this purpose.
These steps involve the following processes and activities in GB/T 22032 (see Appendix C).
Requirements definition process.
a) Translate stakeholder requirements into stakeholder needs;
b) Analyze the needs of stakeholders.
System requirements definition process.
a) Prepare to define system requirements;
b) Define system requirements;
c) Analyze system requirements.
Based on QIUR, PQR and DQR from stakeholders (including feedback from existing systems) and higher levels of the system
Obtained quality requirements, define, analyze and record QIUR/PQR/DQR.
Usually, these steps are applied in an iterative and recursive manner. When they are applied recursively to the target entity, these steps should be applied to
All ICT products and data within the entity to achieve further management activities required to achieve the target entity quality.
Note 1.From a management perspective, the definition of QIUR precedes the definition of PQR/DQR, which is very reasonable for the development of customized products, but in fact, for consumer products,
Usually, PQR/DQR is defined first, and then QIUR is defined to evaluate the target entity under operating conditions.
In order to satisfy certain PQRs, in the iteration of the PQR definition step, it is advisable to define technical PQRs so that they can be used as various development stages.
The verification target of the segment.
In the process of recursively applying these steps, it should be considered that certain functional requirements come from certain quality requirements (6.5.3).
Note 2.In fact, the recursive application of the above steps is usually carried out at the same time. For example, the next recursion can be a child ICT product that constitutes the target ICT product
And data (6.5.4).
Note 2.ISO /IEC 25065 specifies the format and syntax used when recording user requirements, including user-related quality requirements, which can include
Use quality requirements.
Note 3.Since most of the quality measures adopted by the measurement methods have been in GB/T 25000.22-2019, GB/T 25000.23-2019 and GB/T 25000.
It is defined in 24-2017, so the quality measures used in quality requirements do not have to be defined from scratch, but can be selected from these standards.
Note 4.According to business or management needs, different stakeholders can have different target values.
Note 5.Regulators can set minimum/maximum limits for certain target values.
f) Analyze quality requirements
Analyze quality requirements from the following perspectives to confirm them.
1) Whether it meets the original requirements and needs of its source;
2) Whether it is consistent with other quality requirements and constraints;
3) Can it be verified;
4) Whether it is feasible.
And solve the problems found.
Note 1.See 6.5.5 and Appendix B for quality demand trade-offs.
If conflicts and contradictions between quality requirements are found, they should be resolved by finding an appropriate balance between them according to their given priority.
In this step, risk analysis should be carried out for each quality requirement to identify and resolve the risks that may be brought about by the quality requirement. Should be considered
Human, economic, health, safety and environmental risks to choose a specific category that applies to the problem. Should evaluate whether the quality requirements can be as expected
This fully reduces higher-level system risks.
Note 2.In order to perform risk analysis requirements, engineers can work with users to identify business-related risks specific to each quality requirement.
Identify technical risks specific to quality requirements together.
g) Manage quality requirements
First, obtain a clear agreement on these QIUR and PQR/DQR, and should be approved by all stakeholder organizations.
Second, establish and maintain the relationship between the defined quality requirements and their sources (quality requirements, QIUR, PQR and higher-level DQR).
Traceability.
Finally, if it is determined that the quality requirements need to be improved, all steps are executed iteratively.
8 Use and control quality requirements
8.1 The key factors to achieve quality requirements
The quality requirements of the target entities should be selected according to the usage environment and design trade-offs of the system, and the quality requirements of the target entities should be sorted according to the priority. with
At the same time, the quality requirements of the target entity to be verified or confirmed should be selected based on the key factors that meet the objectives of the stakeholders, and the quality requirements of the target entity to be verified or confirmed should be determined accordingly.
They are sorted by priority.
Note 1.Quality requirements fulfill two purposes. a) to guide and prioritize design solutions that are expected to meet quality requirements; b) to provide evaluable
Acceptance criteria.
Since it is also important to minimize development costs and development time in practice, the entire process of the realization, verification and confirmation of quality requirements
It should be both effective and efficient. In some cases, a compromise is needed. Therefore, it is recommended to adopt a risk-based quality requirements analysis method.
Method, including the following steps.
a) Evaluate each quality requirement, and prioritize the following points.
---Importance. Obligation to key stakeholders and the degree of importance to society, business, human life and/or the environment.
--- Impact. The impact of rework on the development and maintenance process.
b) Verify and confirm the planned activities and execution points of the quality requirements (in the development phase), and estimate their costs and effects. Such activities
Including testing, inspection, prototyping, adopting effective design methods, iterative processes, etc.
c) For each high-priority quality demand, the risk of unfulfilled demand and the cost of taking action to avoid the risk
Balance between. If actions are considered cost advantages, then these actions are adopted and included in the development plan.
Note 2.When the product contains a database management system (DBMS) software component, the DQR of the data processed by it is greatly simplified, or even non-existent.
8.2 Traceability of quality requirements
The two-way traceability between quality requirements and ICT components should be maintained and reconfirmed throughout the life cycle of the product.
a) Product elements such as product design, realization and evaluation;
b) The needs of stakeholders and system requirements.
Examples of achieving PQR/DQR traceability in the product development life cycle.
a) Functional requirements; such as security requirements and access control functions to achieve security requirements;
b) Architecture; e.g., fault-tolerant requirements and the structure that realizes fault-tolerant requirements;
c) The PQR/DQR of the deployed components; for example, the response time requirements of the software and the response time requirements of the software components;
d) Principles in the design process; for example, security requirements and security coding principles to achieve security requirements.
Note. See Appendix J for an example of achieving traceability of quality requirements in the development phase.
8.3 Key factors for testing quality requirements
It should be tested according to the defined quality requirements to quantify the quality characteristics and sub-characteristics of the target system. For example, by performing functional tests
To quantify the functional characteristics of the target system, and to quantify the performance efficiency by performing performance tests. Quantify the consistency of data through data comparison
To quantify the completeness of the data by counting the null values.
Note 1.GB/T 25000.40-2018 provides requirements and suggestions for using quality requirements to evaluate the process.
Tests are carried out at different stages of the development process to reflect different quality requirements. For example, software that can be based on PQR/DQR
And system testing, acceptance testing based on QIUR and unit testing and integration testing based on technology PQR/DQR.
Note 2.Technical PQR refers to technically recognized requirements to meet other PRQ attributes (such as target specifications, source code, etc.), which can be used in development and
In all stages of maintenance, intermediate products are verified through review and testing.
Testing usually involves planning the test, designing and developing test cases related to specific quality measures, and then executing the test cases.
A series of processes. Then, based on the test results and other findings based on the test objectives (as specified in the planning document), reports (incidents/
Defect report and test report).
Note 3.Please refer to the regulations and explanations in ISO /IEC /IEEE29119-2.2013 for the testing process or software testing.
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 25000.30-2021_English be delivered?Answer: Upon your order, we will start to translate GB/T 25000.30-2021_English as soon as possible, and keep you informed of the progress. The lead time is typically 4 ~ 6 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GB/T 25000.30-2021_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 25000.30-2021_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay.
|