>>
<<
GSO IEC 62304:2017
GSO - Cover page
Gulf Foreword
ISO - Cover page
FOREWORD
INTRODUCTION
1 Scope
 1.1 *Purpose
 1.2 *Field of application
 1.3 Relationship to other standards
 1.4 Compliance
2 *Normative references
3 * Terms and definitions
4 * General requirements
 4.1 * Quality management system
 4.2 *Risk management
 4.3 *Software safety classification
5 Software development PROCESS
 5.1 * Software development planning
  5.1.1 Software development plan
  5.1.2 Keep software development plan updated
  5.1.3 Software development plan reference to SYSTEM design and development
  5.1.4 Software development standards, methods and tools planning
  5.1.5 Software integration and integration testing planning
  5.1.6 Software verification planning
  5.1.7 Software risk management planning
  5.1.8 Documentation planning
  5.1.9 Software configuration management planning
  5.1.10 Supporting items to be controlled
  5.1.11 Software configuration item control before verification
 5.2 * Software requirements analysis
  5.2.1 Define and document software requirements from system requirements
  5.2.2 Software requirements content
  5.2.3 Include risk control measures in software requirements
  5.2.4 Re-evaluate medical device risk analysis
  5.2.5 Update system requirements
  5.2.6 Verify software requirements
 5.3 * Software architectural design
  5.3.1 Transform software requirements into an architecture
  5.3.2 Develop an architecture for the interfaces of software items
  5.3.3 Specify functional and performance requirements of soup item
  5.3.4 Specify system hardware and software required by soup item
  5.3.5 Identify segregation necessary for risk control
  5.3.6 Verify software architecture
 5.4 *Software detailed design
  5.4.1 Refine software architecture into software units
  5.4.2 Develop detailed design for each software unit
  5.4.3 Develop detailed design for interfaces
  5.4.4 Verify detailed design
 5.5 * Software unit implementation and verification
  5.5.1 Implement each software unit
  5.5.2 Establish software unit verification process
  5.5.3 Software unit acceptance criteria
  5.5.4 Additional software unit acceptance criteria
  5.5.5 Software unit verification
 5.6 * Software integration and integration testing
  5.6.1 Integrate software units
  5.6.2 Verify software integration
  5.6.3 Test integrated software
  5.6.4 Integration testing content
  5.6.5 Verify integration test procedures
  5.6.6 Conduct regression tests
  5.6.7 Integration test record contents
  5.6.8 Use software problem resolution process
 5.7 * Software system testing
  5.7.1 Establish tests for software requirements
  5.7.2 Use software problem resolution process
  5.7.3 Retest after changes
  5.7.4 Verify software system testing
  5.7.5 software system test record contents
 5.8 * Software release
  5.8.1 Ensure software verification is complete
  5.8.2 Document known residual anomalies
  5.8.3 Evaluate known residual anomalies
  5.8.4 Document released versions
  5.8.5 Document how released software was created
  5.8.6 Ensure activities and tasks are complete
  5.8.7 Archive software
  5.8.8 Assure repeatability of software release
6 Software maintenance process
 6.1 * Establish software maintenance plan
 6.2 * Problem and modification analysis
  6.2.1 Document and evaluate feedback
  6.2.2 Use software problem resolution process
  6.2.3 Analyse change requests
  6.2.4 change request approval
  6.2.5 Communicate to users and regulators
 6.3 * Modification implementation
  6.3.1 Use established process to implement modification
  6.3.2 Re-release modified software system
7 * Software risk management process
 7.1 * Analysis of software contributing to hazardous situations
  7.1.1 Identify software items that could contribute to a hazardous situation
  7.1.2 Identify potential causes of contribution to a hazardous situation
  7.1.3 Evaluate published soup anomaly lists
  7.1.4 Document potential causes
  7.1.5 Document sequences of events
 7.2 Risk control measures
  7.2.1 Define risk control measures
  7.2.2 Risk control measures implemented in software
 7.3 Verification of risk control measures
  7.3.1 Verify risk control measures
  7.3.2 Document any new sequences of events
  7.3.3 Document traceability
 7.4 Risk management of software changes
  7.4.1 Analyse changes to medical device software with respect to safety
  7.4.2 Analyse impact of software changes on existing risk control measures
  7.4.3 Perform risk management activities based on analyses
8 * Software configuration management process
 8.1 * Configuration identification
  8.1.1 Establish means to identify configuration items
  8.1.2 Identify soup
  8.1.3 Identify system configuration documentation
 8.2 * Change control
  8.2.1 Approve change requests
  8.2.2 Implement changes
  8.2.3 Verify changes
  8.2.4 Provide means for traceability of change
 8.3 * Configuration status accounting
9 * Software problem resolution process
 9.1 Prepare problem reports
 9.2 Investigate the problem
 9.3 Advise relevant parties
 9.4 Use change control process
 9.5 Maintain records
 9.6 Analyse problems for trends
 9.7 Verify software problem resolution
 9.8 Test documentation contents
Annex A (informative) Rationale for the requirements of this standard
Annex B (informative) Guidance on the provisions of this standard
Annex C (informative) Relationship to other standards
Annex D (informative) Implementation
Bibliography
30mm
20mm
15mm
15mm
10mm
17mm
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
GSO IEC 62304:2017
IEC 62304:2006
مواصفة قياسية خليجية
برمجيات الأجهزة الطبية - عمليات دورة حياة البرمجية
Gulf Standard
Medical device software -- Software life cycle processes
ICS:
11.040.01 ; 35.240.80

هذه الوثيقة محمية بالقانون
COPYRIGHT PROTECTED DOCUMENT
جميع الحقوق محفوظة لهيئة لتقييس لدول مجلس التعاون لدول الخليج العربية.
ما لم ينص على خلاف ذلك، لا يجوز إعادة إنتاج أي جزء من هذا المنشور أو استخدامه بأي شكل آخر أو بأي وسيلة، إلكترونية أو ميكانيكية، بما في ذلك التصوير، أو النشر على الإنترنت أو الإنترانت، دون إذن كتابي مسبق من هيئة التقييس لدول مجلس التعاون لدول الخليج العربية على العنوان أدناه أو الدول الأعضاء في الهيئة داخل بلدانهم.
All rights reserved to GCC Standardization Organization (GSO). Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either GSO at the address below or GSO's member body in the country of the requester.
Outreach Dept, Knowledge Management Section
GCC Standardization Organization (GSO)
P.O.Box: 85245 Riyadh 12511
Kingdom of Saudi Arabia
إدارة التواصل، قسم إدارة المعرفة
هيئة التقييس لدول مجلس التعاون لدول الخليج العربية (GSO)
ص. ب: 85245 الرياض 12511
المملكة العربية السعودية
Tel: +966115208000 :هاتف
Fax: +966115208010 :فاكس
E-Mail: csc@gso.org.sa :بريد إلكتروني
Website: www.gso.org.sa :موقع ويب
30mm
20mm
15mm
15mm
10mm
17mm

Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard

Gulf Foreword

GCC Standardization Organization (GSO) is a regional organization which consists of the national standardization bodies of GCC member states. One of GSO main functions is to issue Gulf Standards and Technical Regulations through specialized technical committees.
GSO Technical Council in its meeting number (42) held on 30/07/1438 H, which corresponds to 27/04/2017, has approved the document GSO IEC 62304:2017 as a Gulf Standard titled "Medical device software -- Software life cycle processes" in English language which was studied and adopted from International Electrotechnical Commission Standard IEC 62304:2006 without any technical modifications through the technical program of GSO Technical Committee for Information and Information Technology (TC08) in SAUDI ARABIA schedule .
تقديم خليجي
هيئة التقييس لدول مجلس التعاون لدول الخليج العربية هيئة إقليمية تضم في عضويتها أجهزة التقييس الوطنية في الدول الأعضاء، ومن مهام الهيئة إعداد المواصفات القياسية واللوائح الفنية الخليجية بواسطة لجان فنية متخصصة.
قرر المجلس الفني لهيئة التقييس لدول مجلس التعاون لدول الخليج العربية في الاجتماع الـ (42) بتاريخ 1438/07/30 هـ، الموافق 2017/04/27م اعتماد الوثيقة رقم GSO IEC 62304:2017 كمواصفة قياسية خليجية عنوانها "برمجيات الأجهزة الطبية - عمليات دورة حياة البرمجية " باللغة الانجليزية والتي تم دراستها وتبنيها عن اللجنة الدولية الكهروتقنية رقم IEC 62304:2006 بدون إدخال تعديلات فنية عليها ضمن برنامج عمل اللجنة الفنية الخليجية لمواصفات المعلومات وتقنية المعلومات (TC08) المدرجة في خطة المملكة العربية السعودية .
30mm
20mm
15mm
15mm
10mm
17mm
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard

International

Standard

IEC 62304
Medical device software — Software life cycle processes
Logiciels de dispositifs médicaux — Processus du cycle de vie du logiciel
Reference number
IEC 62304:2006(en)
First edition
2006-05
30mm
20mm
15mm
15mm
10mm
17mm
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
30mm
20mm
15mm
15mm
10mm
17mm

Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
ContentsPage

FOREWORD

1)
The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non­governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2)
The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.
3)
IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
4)
In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5)
IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with an IEC Publication.
6)
All users should ensure that they have the latest edition of this publication.
7)
No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
8)
Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication.
9)
Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62304 has been prepared by a joint working group of subcommittee 62A: Common aspects of electrical equipment used in medical practice, of IEC technical committee 62: Electrical equipment in medical practice and ISO Technical Committee 210, Quality management and corresponding general aspects for medical devices. Table C.5 was prepared by ISO/IEC JTC 1/SC 7, Software and system engineering.
It is published as a dual logo standard.
The text of this standard is based on the following documents:
FDIS Report on voting
62A/523/FDIS 62A/528/RVD
Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table. In ISO, the standard has been approved by 23 P-members out of 23 having cast a vote.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
In this standard the following print types are used:
requirements and definitions: in roman type;
informative material appearing outside of tables, such as notes, examples and references: in smaller type. Normative text of tables is also in a smaller type;
terms used throughout this standard that have been defined in Clause 3 and also given in the index: in small capitals.
An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that there is guidance related to that item in Annex B.
The committee has decided that the contents of this publication will remain unchanged until the maintenance result date indicated on the IEC web site under “http://webstore.iec.ch” in the data related to the specific publication. At this date, the publication will be
reconfirmed;
withdrawn;
replaced by a revised edition, or
amended.

INTRODUCTION

Software is often an integral part of medical device technology. Establishing the safety and effectiveness of a medical device containing software requires knowledge of what the software is intended to do and demonstration that the use of the software fulfils those intentions without causing any unacceptable risks.
This standard provides a framework of life cycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. This standard provides requirements for each life cycle process. Each life cycle process is further divided into a set of activities, with most activities further divided into a set of tasks.
As a basic foundation it is assumed that medical device software is developed and maintained within a quality management system (see 4.1) and a risk management system (see 4.2). The risk management process is already very well addressed by the International Standard ISO 14971. Therefore IEC 62304 makes use of this advantage simply by a normative reference to ISO 14971. Some minor additional risk management requirements are needed for software, especially in the area of identification of contributing software factors related to hazards. These requirements are summarized and captured in Clause 7 as the software risk management process.
Whether software is a contributing factor to a hazard is determined during the hazard identification activity of the risk management process. Hazards that could be indirectly caused by software (for example, by providing misleading information that could cause inappropriate treatment to be administered) need to be considered when determining whether software is a contributing factor. The decision to use software to control risk is made during the risk control activity of the risk management process. The software risk management process required in this standard has to be embedded in the device risk management process according to ISO 14971.
The software development process consists of a number of activities. These activities are shown in Figure 1 and described in Clause 5. Because many incidents in the field are related to service or maintenance of medical device systems including inappropriate software updates and upgrades, the software maintenance process is considered to be as important as the software development process. The software maintenance process is very similar to the software development process. It is shown in Figure 2 and described in Clause 6.
Figure 1 — Overview of software development processes and activities
Figure 2 — Overview of software maintenance processes and activities
This standard identifies two additional processes considered essential for developing safe medical device software. They are the software configuration management process (Clause 8) and the software problem resolution process (Clause 9).
This standard does not specify an organizational structure for the manufacturer or which part of the organization is to perform which process, activity, or task. This standard requires only that the process, activity, or task be completed to establish compliance with this standard.
This standard does not prescribe the name, format, or explicit content of the documentation to be produced. This standard requires documentation of tasks, but the decision of how to package this documentation is left to the user of the standard.
This standard does not prescribe a specific life cycle model. The users of this standard are responsible for selecting a life cycle model for the software project and for mapping the processes, activities, and tasks in this standard onto that model.
Annex A provides rationale for the clauses of this standard. Annex B provides guidance on the provisions of this standard.
For the purposes of this standard:
“shall” means that compliance with a requirement is mandatory for compliance with this standard;
“should” means that compliance with a requirement is recommended but is not mandatory for compliance with this standard;
“may” is used to describe a permissible way to achieve compliance with a requirement;
“establish” means to define, document, and implement; and
where this standard uses the term “as appropriate” in conjunction with a required process, activity, task or output, the intention is that the manufacturer shall use the process, activity, task or output unless the manufacturer can document a justification for not so doing.
30mm
20mm
15mm
15mm
10mm
17mm

Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
International StandardIEC 62304:2006(en)
Medical device software — Software life cycle processes

1Scope

1.1*Purpose

This standard defines the life cycle requirements for medical device software. The set of processes, activities, and tasks described in this standard establishes a common framework for medical device software life cycle processes.

1.2*Field of application

This standard applies to the development and maintenance of medical device software.
This standard applies to the development and maintenance of medical device software when software is itself a medical device or when software is an embedded or integral part of the final medical device.
This standard does not cover validation and final release of the medical device, even when the medical device consists entirely of software.

1.3Relationship to other standards

This medical device software life cycle standard is to be used together with other appropriate standards when developing a medical device. Annex C shows the relationship between this standard and other relevant standards.

1.4Compliance

Compliance with this standard is defined as implementing all of the processes, activities, and tasks identified in this standard in accordance with the software safety class.
NOTEThe software safety classes assigned to each requirement are identified in the normative text following the requirement.
Compliance is determined by inspection of all documentation required by this standard including the risk management file, and assessment of the processes, activities and tasks required for the software safety class. See Annex D.
NOTE 1This assessment could be carried out by internal or external audit.
NOTE 2Although the specified processes, activities, and tasks are performed, flexibility exists in the methods of implementing these processes and performing these activities and tasks.
NOTE 3Where any requirements contain “as appropriate” and were not performed, documentation for the justification is necessary for this assessment.
NOTE 4The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.

2*Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 14971, Medical devices - Application of risk management to medical devices.

3* Terms and definitions

For the purposes of this document, the following terms and definitions apply.
3.1
activity
a set of one or more interrelated or interacting tasks
3.2
anomaly
any condition that deviates from the expected based on requirements specifications, design documents, standards, etc. or from someone’s perceptions or experiences. Anomalies may be found during, but not limited to, the review, test, analysis, compilation, or use of software products or applicable documentation
[SOURCE: IEEE 1044:1993, definition 3.1]
3.3
architecture
organizational structure of a system or component
[SOURCE: IEEE 610.12:1990]
3.4
change request
a documented specification of a change to be made to a software product
3.5
configuration item
entity that can be uniquely identified at a given reference point
Note 1 to entry: Based on ISO/IEC 12207:1995, definition 3.6.
3.6
deliverable
required result or output (includes documentation) of an activity or task
3.7
evaluation
a systematic determination of the extent to which an entity meets its specified criteria
[SOURCE: ISO/IEC 12207:1995, definition 3.9]
3.8
harm
physical injury, damage, or both to the health of people or damage to property or the environment
[SOURCE: ISO/IEC Guide 51:1999, definition 3.3]
3.9
hazard
potential source of harm
[SOURCE: ISO/IEC Guide 51:1999, definition 3.5]
3.10
manufacturer
natural or legal person with responsibility for designing, manufacturing, packaging, or labelling a medical device; assembling a system; or adapting a medical device before it is placed on the market and/or put into service, regardless of whether these operations are carried out by that person or by a third party on that person’s behalf
[SOURCE: ISO 14971:2000, definition 2.6]
3.11
medical device
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material or other similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of
-
diagnosis, prevention, monitoring, treatment or alleviation of disease,
-
diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
-
investigation, replacement, modification, or support of the anatomy or of a physiological process,
-
supporting or sustaining life,
-
control of conception,
-
disinfection of medical devices,
-
providing information for medical purposes by means of in vitro examination of specimens derived from the human body,
and which does not achieve its primary intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its function by such means
Note 1 to entry: This definition has been developed by the Global Harmonization Task Force (GHTF). See bibliographic reference [15] (in ISO 13485:2003).
[SOURCE: ISO 13485:2003, definition 3.7]
Note 2 to entry: Some differences can occur in the definitions used in regulations of each country.
3.12
medical device software
software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right
3.13
problem report
a record of actual or potential behaviour of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use or contrary to specification
Note 1 to entry: This standard does not require that every problem report results in a change to the software product. A manufacturer can reject a problem report as a misunderstanding, error or insignificant event.
Note 2 to entry: A problem report can relate to a released software product or to a software product that is still under development.
Note 3 to entry: This standard requires the manufacturer to perform extra decision making steps (see Clause 6) for a problem report relating to a released product to ensure that regulatory actions are identified and implemented.
3.14
process
a set of interrelated or interacting activities that transform inputs into outputs
[SOURCE: ISO 9000:2000, definition 3.4.1]
Note 1 to entry: The term “activities” covers use of resources.
3.15
regression testing
the testing required to determine that a change to a system component has not adversely affected functionality, reliability or performance and has not introduced additional defects
[SOURCE: ISO/IEC 90003:2004, definition 3.11]
3.16
risk
combination of the probability of occurrence of harm and the severity of that harm
[SOURCE: ISO/IEC Guide 51:1999 definition 3.2]
3.17
risk analysis
systematic use of available information to identify hazards and to estimate the risk
[SOURCE: ISO/IEC Guide 51:1999 definition 3.10]
3.18
risk control
process in which decisions are made and risks are reduced to, or maintained within, specified levels
[SOURCE: ISO 14971:2000 definition 2.16, modified]
3.19
risk management
systematic application of management policies, procedures, and practices to the tasks of analyzing, evaluating, and controlling risk
[SOURCE: ISO 14971:2000 definition 2.18]
3.20
risk management file
set of records and other documents, not necessarily contiguous, that are produced by a risk management process
[SOURCE: ISO 14971:2000 definition 2.19]
3.21
safety
freedom from unacceptable risk
[SOURCE: ISO/IEC Guide 51:1999 definition 3.1]
3.22
security
protection of information and data so that unauthorized people or systems cannot read or modify them and so that authorized persons or systems are not denied access to them
[SOURCE: ISO/IEC 12207:1995 definition 3.25]
3.23
serious injury
injury or illness that directly or indirectly:
a)
is life threatening,
b)
results in permanent impairment of a body function or permanent damage to a body structure, or
c)
necessitates medical or surgical intervention to prevent permanent impairment of a body function or permanent damage to a body structure
Note 1 to entry: Permanent impairment means an irreversible impairment or damage to a body structure or function excluding trivial impairment or damage.
3.24
software development life cycle model
conceptual structure spanning the life of the software from definition of its requirements to its release for manufacturing, which:
-
identifies the process, activities and tasks involved in development of a software product,
-
describes the sequence of and dependency between activities and tasks, and
-
identifies the milestones at which the completeness of specified deliverables is verified.
Note 1 to entry: Based on ISO/IEC 12207:1995, definition 3.11
3.25
software item
any identifiable part of a computer program
[SOURCE: ISO/IEC 90003:2004, definition 3.14, modified]
Note 1 to entry: Three terms identify the software decomposition. The top level is the software system. The lowest level that is not further decomposed is the software unit. All levels of composition, including the top and bottom levels, can be called software items. A software system, then, is composed of one or more software items, and each software item is composed of one or more software units or decomposable software items. The responsibility is left to the manufacturer to provide the definition and granularity of the software items and software units.
3.26
software product
set of computer programs, procedures, and possibly associated documentation and data
[SOURCE: ISO/IEC 12207:1995 definition 3.26]
3.27
software system
integrated collection of software items organized to accomplish a specific function or set of functions
3.28
software unit
software item that is not subdivided into other items
Note 1 to entry: Software units can be used for the purpose of software configuration management or testing.
3.29
soup
software of unknown provenance (acronym)
software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as “off-the-shelf software”) or software previously developed for which adequate records of the development processes are not available
3.30
system
integrated composite consisting of one or more of the processes, hardware, software, facilities, and people, that provides a capability to satisfy a stated need or objective
[SOURCE: ISO/IEC 12207:1995, definition 3.31]
3.31
task
a single piece of work that needs to be done
3.32
traceability
degree to which a relationship can be established between two or more products of the development process
[SOURCE: IEEE 610.12:1990]
3.33
verification
confirmation through provision of objective evidence that specified requirements have been fulfilled
Note 1 to entry: “Verified” is used to designate the corresponding status.
[SOURCE: ISO 9000:2000, definition 3.8.4]
Note 2 to entry: In design and development, verification concerns the process of examining the result of a given activity to determine conformity with the stated requirement for that activity.
3.34
version
identified instance of a configuration item
Note 1 to entry: Modification to a version of a software product, resulting in a new version, requires software configuration management action.
Note 2 to entry: Based on ISO/IEC 12207:1995, definition 3.37.
30mm
20mm
15mm
15mm
10mm
17mm

Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
Bibliography
[1]
IEC 60601-1:2005, Medical electrical equipment - Part 1: General requirements for basic safety and essential performance
[2]
IEC 60601-1-4:1996, Medical electrical equipment - Part 1: General requirements for safety - 4.Collateral standard: Programmable electrical medical systems Amendment 1 (1999)
[3]
IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements
[4]
IEC 61010-1:2001, Safety requirements for electrical equipment for measurement, control, and laboratory use - Part 1: General requirements
[5]
ISO 9000:2005, Quality management systems - Fundamentals and vocabulary
[6]
ISO 9001:2000, Quality management systems - Requirements
[7]
ISO 13485:2003, Medical devices - Quality management systems - Requirements for regulatory purposes
[8]
ISO/IEC 9126-1:2001, Software engineering — Product quality — Part 1: Quality model
[9]
ISO/IEC 12207:1995, Information technology – Software life cycle processes Amendment 1 (2002) Amendment 2 (2004)
[10]
ISO/IEC 14764:1999, Information technology – Software maintenance
[11]
ISO/IEC 90003:2004, Software engineering – Guidelines for the application of ISO 9001:2000 to computer software
[12]
ISO/IEC Guide 51:1999, Safety aspects – Guidelines for their inclusion in standards
[13]
IEEE 610.12:1990, IEEE standard glossary of software engineering terminology
[14]
IEEE 1044:1993, IEEE standard classification for software anomalies
[15]
IEC 60601-1-6, Medical electrical equipment - Part 1-6: General requirements for safety - Collateral standard: Usability
30mm
20mm
15mm
15mm
10mm
17mm
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
Gulf StandardGSO IEC 62304:2017
GSO IEC 62304:2017Gulf Standard
ICS 11.040.01; 35.240.80
Price based on 151 pages
iso.org