Skip to product information
1 of 7

PayPal, credit cards. Download editable-PDF and invoice in 1 second!

GB/T 25000.51-2016 English PDF (GBT25000.51-2016)

GB/T 25000.51-2016 English PDF (GBT25000.51-2016)

Regular price $145.00 USD
Regular price Sale price $145.00 USD
Sale Sold out
Shipping calculated at checkout.
Quotation: In 1-minute, 24-hr self-service. Click here GB/T 25000.51-2016 to get it for Purchase Approval, Bank TT...

GB/T 25000.51-2016: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- Part 51: Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing

GB/T 25000.51-2016
Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Part 51. Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing ICS 35.080
National Standards of People's Republic of China
Replacing GB/T 25000.51-2010
System and Software Engineering System and Software Quality Requirements And Evaluation (SQuaRE) Part 51. Readiness
The quality requirements of available software products (RUSP) and
Test details
Evaluation(SQuaRE)-Part 51.RequirementsforqualityofReadyto
(ISO /IEC 25051.2014, Software engineering-
2016-10-13 released2017-05-01 implementation
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China China National Standardization Administration released
Preface III
Introduction V
1 Range 1
2 Compliance 2
3 Normative references 2
4 Terms and Definitions, Abbreviations 2
4.1 Terms and Definitions 2
4.2 Abbreviations 5
5 RUSP requirements 5
5.1 Product Description Requirements 5
5.2 User Documentation Set Requirements 8
5.3 Software Quality Requirements 10
6 Test Document Set Requirements 13
6.1 General requirements 13
6.2 Test Plan Requirements 14
6.3 Test Description Requirements 15
6.4 Test result requirement 15
7 Compliance Assessment Rule 16
7.1 General Principle 16
7.2 Conformity Assessment Prerequisites 17
7.3 Compliance Assessment Activity 17
7.4 Compliance Assessment Process 17
7.5 Conformity Evaluation Report 17
7.6 Follow-up Compliance Evaluation 18
Appendix A (Informative) Guidelines for the Evaluation of RUSP in Business or Safety-critical Application Systems 19 Appendix B (Informative) How to use this section 22
Reference 23
GB/T 25000 "System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE)" is divided into the following sections. --- Part 1. SQuaRE guidelines;
--- Part 2. Planning and Management;
--- Part 10. System and software quality model;
--- Part 12. Data Quality Model;
--- Part 20. Measurement Reference Models and Guidelines;
--- Part 21. Quality Measurement Elements;
--- Part 22. Use of quality measurements;
--- Part 23. System and software product quality measurement;
--- Part 24. Measurement of data quality;
--- Part 30. Quality requirements;
--- Part 40. Evaluation process;
--- Part 41. Evaluation guidelines for developers, demanders, and independent evaluators; --- Part 42. Evaluation module;
--- Part 45. Evaluation modules for recoverability;
--- Part 51. Quality requirements and test details for ready usable software products (RUSP); --- Part 60. Usability Test Reports Industry Common Format (CIF). A generic framework for information related to usability; --- Part 62. Usability Test Report Industry Common Format (CIF);
--- Part 63. Common industry format for ease of use (CIF). Use of context description; --- Part 64. Industry Common Format for Ease of Use (CIF). User Requirements Report; --- Part 65. Industry-Friendly Format for Ease of Use (CIF). Specification of user requirements; --- Part 66. Common industry format for ease of use (CIF). Evaluation report. This section is Part 51 of GB/T 25000.
This section was drafted in accordance with the rules given in GB/T 1.1-2009. This section replaces GB/T 25000.51-2010 "Software Engineering Software Product Quality Requirements and Evaluation (SQuaRE) Commercial Spot (COTS) Quality Requirements and Testing Rules for Software Products." Compared with GB/T 25000.51-2010, the main technical changes are as follows. a) GB/T 25000.51-2010 is equivalent to ISO /IEC 25051.2006, and this part is modified to adopt ISO /IEC 25051.2014. b) The terms and definitions have been adjusted and supplemented.
c) In this part, the expressions related to product quality characteristics of "information security" and "compatibility" have been added, and the quality characteristics have been adjusted to. The five characteristics of "effectiveness", "efficiency", "satisfaction", "resistance to risk", and "peripheral coverage" have been modified and adjusted Complete and supplementary (for details of the added provisions, see, 5.1.4,,,, 5.1.10, 5.1.15, 5.1.16, 5.1.17,,,, 5.2.17,,, 5.3.3,,,,, 5.3.9, 5.3.10, 5.3.11, 5.3.12, 5.3.13, 6.2.4, 6.2.5, 6.2.6, 6.2.7). d) Adjustments have also been made in the appendix.
This section adopts redrafted law to amend ISO /IEC 25051.2014 "Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Quality Requirements and Testing Rules for Ready-to-Use Software Products (RUSP) (in English). This section is related to The main technical differences between ISO /IEC 25051.2014 and its causes are as follows. a) In the normative reference document, the ISO /IEC 25000 cited in the original international standard was deleted because the text was not drawn; ISO /IEC 25010 is replaced by the national standard GB/T 25000.10-2016, dated by reference, because of the reference to the quality model Must be dated.
b) As GB/T 25000.10-2016 is modified to adopt ISO /IEC 25010.2011, the relevant features of this 5.1, 5.2, 5.3 The description has been revised accordingly, mainly focusing on compliance issues. c) All functions described in "Product Description in International Standards shall be classified according to the requirements of software quality characteristics" (5.3.2~ 5.3.9) "Correct to" All the functions described in the product description should be classified according to the description of the quality characteristics of the software product (5.1.5~ 5.1.12)".
Please note that some of the contents of this document may involve patents. The issuing agency of this document does not assume responsibility for identifying these patents. This part is proposed and managed by the National Information Technology Standardization Technical Committee (SAC/TC28). This section was drafted by. China Electronics Standardization Institute, Shanghai Computer Software Technology Development Center, National Application Software Products Quality Supervision and Inspection Center, Guangdong Science and Technology Infrastructure Platform Center, Shenzhen Zhongan Standard Technology Co., Ltd., Foshan Kewei Photoelectricity Unit Co., Ltd., Chongqing Software Testing Center Co., Ltd., Nanjing University, Zhuhai South Software Network Testing Center, Hubei Software Evaluation Xin, China Aerospace Science and Technology Corporation Software Testing Center, Inner Mongolia Electronic Information Products Quality Inspection Institute, Nanchang Jinyi Software Park Software Review Training Co., Ltd., Shanghai Zezhong Software Technology Co., Ltd., Shanghai Deyuan Information Technology Co., Ltd., and Shanghai Software Industry Association. Drafters of this section. Zhang Hao, Feng Hui, Cai Lizhi, Hu Yi, Wang Wei, Ding Xiaoming, Song Hongbo, Luo Liang, Pan Yucong, He Zhiming, Liao Hui, Zhang Yi, Xue Baoping, Xu Baowen, Hou Jianhua, Wang Rui, Yang Guizhi, Xia Qiming, Huang Zhaosen, Liu Yujian, Li Xiaochun, Ding Weiqing, Gao Hailing, Gong Yifei, Zhang Xueli, Chen Hai, and Li Yinghua.
The previous editions of the standards replaced by this section are.
---GB/T 17544-1998;
--- GB/T 25000.51-2010.
The application area of ready-to-use software products (RUSP) is constantly expanding, and its proper operation is often applied to business, security or personal applications. Is very important.
The RUSP may be a software product packaged and sold to a demander that does not have any effect on its characteristics and other qualities. Typical situation Yes, this software product is prepackaged and sold with its user documentation set, or downloaded from a web store. Users can connect at any time Software products used in cloud computing can be thought of as RUSP. The information provided on the packaging cover or on the supplier’s website is often manufactured The only means by which a business or marketing organization can communicate with a demander or user. Therefore, give basic information so that the buyer can evaluate according to his needs The quality of the RUSP is important.
Because RUSP may need to operate in various environments, and users do not have the opportunity to compare the performance of selected products with similar products. In contrast, the selection of high quality RUSP is extremely important. The supplier needs a way to ensure that users trust the services provided by RUSP. Some suppliers may choose to follow the evaluation or certification of the evaluation organization to assist them in providing this trust. In addition, when the user asks for guarantees involving business or safety risks, such guarantee may need to be selected by the user after purchase. Specific technology to deal with. This section does not specify the minimum business or safety-critical quality requirements of RUSP, but gives informational Guide (see Appendix A).
System and Software Engineering System and Software Quality Requirements And Evaluation (SQuaRE) Part 51. Readiness
The quality requirements of available software products (RUSP) and
Test details
1 Scope
This part of GB/T 25000 establishes.
a) Quality requirements for ready usable software products (RUSP);
b) Test document set requirements for testing RUSP including test plans, test descriptions and test results; Note 1. The collection of documents used for testing is called "test document set". c) RUSP compliance assessment rules.
This section also includes advice on safety or business-critical RUSP.
This section only deals with providing users with the trust of the product, that is, RUSP can operate according to the provided and delivered instructions. Does not involve production Implementation (contains various activities and intermediate products, such as specifications). The supplier's quality system is beyond the scope of this section. This section applies to RUSP.
Note 2. Examples of RUSP include but are not limited to. text processing programs, spreadsheets, database control software, graphics packages, and for technical, scientific or Real-time embedded-functional software (such as real-time operating systems), human resource management software, sales management, smart phone applications, free software, and Web software such as Web sites and home page builders.
Note 3. Open source software does not fall within the scope of RUSP.
The intended users in this section include.
a) The supplier, when.
1) specify the requirements of RUSP;
2) When assessing its software product against the claimed characteristics; 3) When the Declaration of Conformity [ISO /IEC 17050] is issued;
4) When applying for a conformity certificate or mark [ISO /IEC Guide 23]; b) certification bodies that wish to establish a certification model (International, Regional or National) [ISO /IEC Guide 28]; c) Test laboratories [ISO /IEC 17025] who perform testing by providing compliance certificates or signs in accordance with this test specification; d) accredited registries or certification bodies and accreditation bodies of test laboratories; e) Potential acquirer, which may.
1) Compare expected work task requirements with product description information of existing software products; 2) Seek certified RUSP;
3) whether the inspection requirements are satisfied;
f) end-users who can benefit from better software products;
g) The organization that is carrying out the following activities.
1) Establish a management and engineering environment based on the quality requirements and methods in this section; 2) Manage and improve its quality process and human resource allocation; h) May require or recommend the use of RUPS in safety or business-critical applications. mechanism.
Appendix B gives information on how to use this section.
2 Compliance
RUSP meets the following conditions.
a) Has the characteristics specified in Chapter 5;
b) Tests have been carried out according to the test documentation set that complies with the requirements of Chapter 6; c) Record the anomalies found during the test and resolve these anomalies before product release. Should eliminate the performance noise against advertising The exception is called, otherwise it should be cancelled. If there are the following two conditions, the known abnormality can be considered Received.
1) The exception does not violate the claimed performance;
2) The supplier has given due consideration to the nature of the anomaly and its impact on the potential acquirer, and believes that the anomaly is negligible and has been safeguarded. Documents about these exceptions are saved for future improvement.
Chapter 7 and Appendix A are optional.
Note. In order to facilitate compliance evaluation, the requirements in this section are given in Level 3 sub-clauses (numbered XXXX). Informative comments improve these terms, Can be used as a guide.
3 Normative references
The following documents are indispensable for the application of this document. For dated references, only dated versions apply to this article Pieces. For undated references, the latest version (including all amendments) applies to this document. GB/T 25000.10-2016 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 10. System and software quality model
4 Terms and Definitions, Abbreviations
4.1 Terms and Definitions
The following terms and definitions apply to this document.
Demand Acquirer
Stakeholders who acquire or purchase products or services from suppliers. Note. The acquirer may be one of the following. buyer, customer, owner, purchaser. [ISO /IEC 12207.2008]
Abnormal anomaly
Any deviation from expectations based on demand specifications, design documents, standards, etc., or with any person’s perception or experience Deviation.
Application Management Function applicationadministrationfunction
Functions performed by users, including installation, configuration, backup, maintenance (patching and upgrading), uninstallation, and so on. 4.1.4
Conformity evaluation
A systematic assessment of the degree to which a product, process, or service meets the required requirements. [ISO /IEC Guide 2.2004]
Conformity evaluation report conformityevaluationreport
A document explaining the behavior and results of evaluating RUSP.
Note. Rewrite IEEE Std 610.12-1998.
ReadytoUseSoftwareProduct Ready Available Software Products
Whether you pay or not, any software product that users can obtain without going through development activities. Note 1. RUSP includes.
--- Product description (including all cover information, data sheets, web page information, etc.); --- User documentation set (documents necessary for installing and using the software), including the operating system or target computer required to run the software product Any configuration
--- Software on computer media (disk, CD-ROM, network downloadable media, etc.). Note 2. The software consists mainly of programs and data.
Note 3. This definition also applies to product descriptions, user documentation sets, and software that is produced and supported as a separate finished product. The software does not charge the usual Business costs and certificate fees.
End user enduser
Individuals who ultimately benefit from RUSP functionality.
Note. The end user may be the official operator of the software product or the temporary user, such as a member of the public. [GB/T 25000.1-2010, definition 4.14]
Fault fault
Incorrect steps, procedures, or data definitions in a computer program. [IEEEstd610.12-1998]
Maintenance maintenance
The process of modifying the software system after delivery.
Note. The purpose is to correct errors, improve performance and attributes, adapt to the environment, etc. [IEEEstd610.12-1998]
Pass/fail criteria for pass/fail criteria
Criteria used to determine whether a software item or software feature passed the test. [IEEEstd829.12-1998]
Product Description productdescription
State documents of various natures of the software.
Note. The main purpose is to help potential buyers to evaluate the suitability of the software before purchasing. 4.1.12
Product identification
The name, version, variant, and date information of the software product. 4.1.13
Requirements document requirementsdocument
Documents containing any combination of requirements or rules that RUSP wants to meet. Note. These documents can be technical reports, standards, a list of requirements for a certain type of user (or model requirements specification) or an administrative agency or regulatory agency Issuing regulations or regulations.
Software function
The implementation of the algorithm in software, using this implementation, the end user or software can perform some or all of a task. Note. Features are not necessarily callable by the end user (eg, automatic backup of data). 4.1.15
Software Testing Environment softwaretestenvironment
The facilities, hardware, software, firmware, procedures, documentation, etc. that are required for compliance testing or other testing of the software. [ISO /IEC /IEEE24765.2010]
Supplier supplier
The organization or individual that has signed an agreement with the buyer to provide the product or service. Note 1. The supplier may be a contractor, producer, supplier or retailer. Note 2. In some cases, the supplier and demander belong to the same organization. [ISO /IEC 12207.2008]
Test (activity) test
Execute the system or component under specified conditions, observe or record the result, and make comments on the system or some aspects of the component Price activity.
Test case testcase
Inputs, execution bars developed for a specific goal (for example, for the purpose of drilling through a specific program path or verifying compliance with specific requirements) Pieces and the collection of expected results.
Test documentation set testdocumentation
A collection of documents specific to the test campaign.
Test target testobjective
The set of identified software features to be measured compares the actual behavior with the required behavior under specified conditions. measuring.
Note. Rewrite IEEE Std 610.12-1998.
Test plan testplan
Describe the documentation of the scope, approach, resources, and schedule of expected test activities. Note. Rewrite IEEE Std 610.12-1998.
Test procedure testprocedure
A detailed description of the setup, execution, and evaluation of results for a given test case. [IEEEstd610.12-1998]
Run a system or component under specified conditions, observe or record its results, and evaluate certain aspects of the system or component the process of.
Test Description testingdescription
A description of the test execution condition (ie test procedure).
User user
Organizations or individuals who use RUSP and recei...

View full details