GB/T 25000.51-2016 PDF English
Search result: GB/T 25000.51-2016 English: PDF (GB/T25000.51-2016)
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Name of Chinese Standard | Status |
| GB/T 25000.51-2016 | English | 145 |
Add to Cart
|
0-9 seconds. Auto-delivery.
|
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
| Valid |
| GB/T 25000.51-2010 | English | 999 |
Add to Cart
|
4 days
|
Software engineering -- Software product quality requirements and evaluation (SQuaRE) -- Requirements for quality of commercial off-the-self (COTS) software product and instructions for testing
| Obsolete |
PDF Preview: GB/T 25000.51-2016
GB/T 25000.51-2016: PDF in English (GBT 25000.51-2016) 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
L77
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
Directory
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
Foreword
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.2.1, 5.1.4, 5.1.6.2, 5.1.6.3, 5.1.8.4, 5.1.10, 5.1.15, 5.1.16,
5.1.17, 5.2.13.1, 5.2.15.1, 5.2.16.1, 5.2.17, 5.2.18.1, 5.2.19.1, 5.3.3, 5.3.4.1, 5.3.5.5, 5.3.6.1,
5.3.7.1, 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 5.1.4.1 "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.
introduction
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.
4.1.1
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]
4.1.2
Abnormal anomaly
Any deviation from expectations based on demand specifications, design documents, standards, etc., or with any person’s perception or experience
Deviation.
[IEEEstd1044-2009]
4.1.3
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]
4.1.5
Conformity evaluation report conformityevaluationreport
A document explaining the behavior and results of evaluating RUSP.
Note. Rewrite IEEE Std 610.12-1998.
4.1.6
ReadytoUseSoftwareProduct Ready Available Software Products
RUSP
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.
4.1.7
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]
4.1.8
Fault fault
Incorrect steps, procedures, or data definitions in a computer program.
[IEEEstd610.12-1998]
4.1.9
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]
4.1.10
Pass/fail criteria for pass/fail criteria
Criteria used to determine whether a software item or software feature passed the test.
[IEEEstd829.12-1998]
4.1.11
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.
4.1.14
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]
4.1.16
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]
4.1.17
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.
[IEEEstd610.12-1998]
4.1.18
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.
[IEEEstd610.12-1998]
4.1.19
Test documentation set testdocumentation
A collection of documents specific to the test campaign.
4.1.20
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.
4.1.21
Test plan testplan
Describe the documentation of the scope, approach, resources, and schedule of expected test activities.
Note. Rewrite IEEE Std 610.12-1998.
4.1.22
Test procedure testprocedure
A detailed description of the setup, execution, and evaluation of results for a given test case.
[IEEEstd610.12-1998]
4.1.23
Testing
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.
[IEEEstd610.12-1998]
4.1.24
Test Description testingdescription
A description of the test execution condition (ie test procedure).
4.1.25
User user
Organizations or individuals who use RUSP and receive revenue.
Note. In the same person or organization, user roles and operator roles may be given at the same time or one after the other.
[ISO /IEC 12207.2008]
4.1.26
User documentation set user documentation
Information provided with the software to assist users in using the software.
4.2 Abbreviations
The following abbreviations apply to this document.
CM. Configuration Management
RUSP. ReadytoUseSoftwareProduct
SQA. Software Quality Assurance
SQC. Software Quality Control
5 RUSP requirements
5.1 Product Description Requirements
Note. The paragraph on cover information in ISO /IEC 9127 "Software Engineering User Sets and Cover Information for Customer Packages" can be used as a production
Product description input.
5.1.1 Availability
The product description should be available to potential buyers and users of the product.
5.1.2 Content
5.1.2.1 The product description should clarify the quality characteristics of the running software.
5.1.2.2 The product description shall contain the information required by the potential acquirer in order to evaluate the suitability of the software for its needs.
5.1.2.3 Product descriptions should avoid internal inconsistencies.
5.1.2.4 The statement of characteristics included in the product description shall be testable or verifiable.
5.1.3 Identification and Labeling
5.1.3.1 The product description shall show a unique identification.
5.1.3.2 RUSP shall refer to its product identification.
5.1.3.3 The product description shall include the name and postal or network of the supplier and, where applicable, the supplier, e-commerce supplier or retailer.
address.
5.1.3.4 The product description shall identify the expected tasks and services that the software can accomplish.
5.1.3.5 When the supplier wants to claim compliance with a document that has a legal or administrative authority that affects the RUSP, the product description shall identify
Out these requirements documents.
5.1.3.6 The product description shall state whether support is provided for operating RUSP.
5.1.3.7 The product description shall state whether maintenance is provided. If maintenance is provided, the product description should state the maintenance services provided.
5.1.4 Mapping
All the functions mentioned in the product description should be classified according to the description of the software product quality characteristics (5.1.5~5.1.12).
5.1.5 Product Quality---Functionality
5.1.5.1 When applicable, the product description shall include the relevant functional statement in accordance with GB/T 25000.10-2016, taking into account the completeness of the function,
Functional correctness, functional suitability, and functional compliance, and demonstrating verifiable compliance evidence in writing.
5.1.5.2 The product description shall provide an overview of the functions that the end user can invoke in this product.
5.1.5.3 The product description should describe all features that the user may encounter with a critical defect.
Note 1. The key defect may be.
---data lost;
--- Deadlock.
Note 2. See ISO /IEC 15026 for more information.
5.1.5.4 The product description shall give all known limitations that the user may encounter.
Note. These restrictions may be.
---Minimum or maximum;
--- Key length;
--- The maximum number of records in a file;
--- The maximum number of search criteria;
--- The minimum sample size.
5.1.5.5 When there are options and versions of software components, they should be indicated without ambiguity.
5.1.5.6 When providing preventive measures for unauthorized access to the software (whether by accident or intentionally), the product description should include this
Information.
5.1.6 Product Quality - Performance Efficiency
5.1.6.1 When applicable, the product description shall contain a statement of performance efficiency according to GB/T 25000.10-2016, taking into account the time characteristics,
Reliance on resource utilization, capacity, and performance efficiency, and demonstrating verifiable compliance evidence in writing.
5.1.6.2 All conditions known to affect performance efficiency shall be stated.
Note. The stated conditions may be.
---System Configuration;
---Resources required for efficient operation of RUSP, such as bandwidth, hard disk space, random access memory, video cards, wireless internet cards, CPU speed, etc.
5.1.6.3 The product description shall describe the capacity of the system, especially the capacity associated with the computer system.
5.1.7 Product Quality---Compatibility
5.1.7.1 Where applicable, product descriptions shall include statements on compatibility according to GB/T 25000.10-2016, taking into account coexistence and interoperability
Assess compliance and compatibility, and demonstrate verifiable compliance evidence in writing.
5.1.7.2 The product description shall indicate in a suitable reference document where RUSP depends on the specific software and/or hardware.
5.1.7.3 The product description shall identify the interface invoked by the user and the associated called software.
5.1.8 Product Quality - Ease of Use
5.1.8.1 When applicable, the product description shall include the statement on ease of use according to GB/T 25000.10-2016, taking into account the identifiability and ease of
Learnability, ease of use, user error prevention, user interface comfort, accessibility, and ease of use compliance, and display in writing
Verifiable evidence of compliance.
5.1.8.2 The product description shall indicate the type of user interface.
Note. These interfaces may be.
---Command Line;
---menu;
---Windows;
---Function keys.
5.1.8.3 The product description shall indicate the expertise required to use and operate the software.
Note. These specialized knowledge may be.
--- knowledge of database calls and protocols used;
--- Knowledge in the field of technology;
--- Operating system knowledge;
--- knowledge gained through specialized training;
--- Knowledge in languages other than the language already stated in the product description.
5.1.8.4 If applicable, the product description shall describe features that prevent the user from mishandling.
5.1.8.5 When technical protection against copyright infringement impedes ease of use, such protection should be stated.
Note. These protections can be.
--- Use deadline of program settings;
--- Copy paid interactive reminders.
5.1.8.6 The product description should include the stipulation of accessibility, especially for users with disabilities and users with linguistic differences.
5.1.9 Product Quality - Reliability
5.1.9.1 Where applicable, product descriptions shall contain statements regarding reliability in accordance with GB/T 25000.10-2016, taking into account maturity and availability
Sexual, fault-tolerant, easy-to-restore, and dependability of reliability, and show verifiable compliance evidence in writing.
Note. Developers should not make claims for reliability unless the developer can verify the claims made with service data or other verifiable data.
5.1.9.2 The product description should be about the software being encountered by the user interface error, the application's own logic error, system or network resource availability
The ability to continue running (ie ready for use) in the event of an error.
5.1.9.3 The product description shall include information on data preservation and restoration procedures.
Note. It is also acceptable to indicate that data backup is performed by the operating system's capabilities.
5.1.10 Product Quality---Information Security
When applicabl......
......
Source: Above contents are excerpted from the PDF -- translated/reviewed by: www.chinesestandard.net / Wayne Zheng et al.
|