EN ISO 9000-3:1997

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Standardi za vodenje in zagotavljanje kakovosti - 3. del: Smernice za uporabo standarda ISO 9001:1994 pri razvoju, nabavi in vzdrževanju programske opreme (ISO 9000-3:1997)Normen zum Qualitätsmanagement und zur Qualitätssicherung/QM-Darlegung - Teil 3: Leitfaden für die Anwendung von ISO 9001:1994 auf Entwicklung, Lieferung, Installierung und Wartung von Computer-Software (ISO 9000-3:1997)Normes pour le management de la qualité et l'assurance de la qualité - Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 au développement, a la mise a disposition , a l'installation et a la maintenance de logiciel (ISO 9000-3:1997)Quality management and quality assurance standards - Part 3: Guidelines for the application of ISO 9001 to the development, supply, installation and maintenance of computer software (ISO 9000-3:1997)35.080Dokumentiranje razvoja programske opreme in sistemov (sistemska dokumentacija)Software development and system documentation03.120.10Vodenje in zagotavljanje kakovostiQuality management and quality assuranceICS:Ta slovenski standard je istoveten z:EN ISO 9000-3:1997SIST EN ISO 9000-3:1998en01-april-1998SIST EN ISO 9000-3:1998SLOVENSKI
STANDARDSIST EN 29000-3:19971DGRPHãþD

AReference numberISO 9000-3:1997(E)INTERNATIONALSTANDARDISO9000-3Second edition1997-12-15Quality management and quality assurancestandards —Part 3:Guidelines for the application ofISO 9001:1994 to the development, supply,installation and maintenance of computersoftwareNormes pour le management de la qualité et l'assurance de la qualité —Partie 3: Lignes directrices pour l'application de l'ISO 9001:1994 audéveloppement, à la mise à disposition, à l'installation et à la maintenancede logicielSIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)©
ISO 1997All rights reserved. Unless otherwise specified, no part of this publication may be reproducedor utilized in any form or by any means, electronic or mechanical, including photocopying andmicrofilm, without permission in writing from the publisher.International Organization for StandardizationCase postale 56 · CH-1211 Genève 20 · SwitzerlandInternetcentral@iso.chX.400c=ch; a=400net; p=iso; o=isocs; s=centralPrinted in SwitzerlandiiContentsPage1
Scope.12
Normative references.13
Definitions.14
Quality system requirements.24.1
Management responsibility.24.2
Quality system.44.3
Contract review.54.4
Design control.74.5
Document and data control.144.6
Purchasing.154.7
Control of customer-supplied product.164.8
Product identification and traceability.174.9
Process control.184.10Inspection and testing.194.11Control of inspection, measuring and test equipment.224.12Inspection and test status.234.13Control of nonconforming product.244.14Corrective and preventive action.254.15Handling, storage, packaging, preservation anddelivery.254.16Control of quality records.274.17Internal quality audits.284.18Training.284.19Servicing.284.20Statistical techniques.30Annex A Bibliography.31Annex B Cross-references to ISO/IEC 12207.32SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)iiiForewordISO (the International Organization for Standardization) is a worldwidefederation of national standards bodies (ISO member bodies). The work ofpreparing International Standards is normally carried out through ISOtechnical committees. Each member body interested in a subject for whicha technical committee has been established has the right to be representedon that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISOcollaborates closely with the International Electrotechnical Commission(IEC) on all matters of electrotechnical standardization.Draft International Standards adopted by the technical committees arecirculated to the member bodies for voting. Publication as an InternationalStandard requires approval by at least 75 % of the member bodies castinga vote.International Standard ISO 9000-3 was prepared by Technical CommitteeISO/TC 176, Quality management and quality assurance, SubcommitteeSC 2, Quality systems.This second edition cancels and replaces the first edition(ISO 9000-3:1991), which has been technically revised.ISO 9000 consists of the following parts, under the general title Qualitymanagement and quality assurance standards:—Part 1: Guidelines for selection and use—Part 2: Generic guidelines for the application of ISO 9001, ISO 9002and ISO 9003—Part 3: Guidelines for the application of ISO 9001:1994 to thedevelopment, supply, installation and maintenance of computersoftware—Part 4: Guide to dependability programme management.Annexes A and B of this part of ISO 9000 are for information only.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISOivIntroductionThis part of ISO 9000 provides guidance in applying the requirements ofISO 9001:1994 where computer software design, development, installationand maintenance are an element of the business of a supplier:a)as part of a commercial contract with an external organization;b)as a product available for a market sector;c)in support of the business processes of the supplier;d)as software embedded in a hardware product.It identifies the issues which need to be addressed and is independent ofthe technology, life cycle models, development processes, sequence ofactivities, or organization structure used by a supplier.Where the scope of an organization's activities includes areas other thancomputer software development, the relationship between the computersoftware elements of that organization's quality system and the remainingaspects should be clearly documented within the quality system as awhole.This part of ISO 9000 provides guidelines for the application ofISO 9001:1994. Where text has been quoted from ISO 9001:1994, thattext is enclosed in a box, for ease of identification.Throughout this part of ISO 9000, “shall” is used to express a provision thatis binding between two or more parties; “will” to express a declaration ofpurpose, or intent, of one party; “should” to express a recommendationamong possibilities; and “may” to indicate a course of action permissiblewithin the limits of this parts of ISO 9000.SIST EN ISO 9000-3:1998

INTERNATIONAL STANDARD
© ISOISO 9000-3:1997(E)1Quality management and quality assurance standards —Part 3:Guidelines for the application of ISO 9001:1994 to the development,supply, installation and maintenance of computer software1
ScopeThis part of ISO 9000 sets out guidelines to facilitate the application of ISO 9001:1994 for organizations developing,supplying, installing and maintaining computer software.
It does not add to, or otherwise change, the requirements ofISO 9001.This part of ISO 9000 is not intended to be used as assessment criteria in quality system registration/certification.2
Normative referencesThe following standards contain provisions which, through reference in this text, constitute provisions of this part ofISO 9000.
At the time of publication, the editions indicated were valid.
All standards are subject to revision, and partiesto agreements based on this part of ISO 9000 are encouraged to investigate the possibility of applying the most recentedition of the standards indicated below.
Members of IEC and ISO maintain registers of currently valid InternationalStandards.ISO 8402:1994, Quality management and quality assurance — Vocabulary.ISO 9001:1994, Quality systems — Model for quality assurance in design, development, production, installation andservicing.3
DefinitionsFor the purposes of this part of ISO 9000, the definitions given in ISO 8402 and the following definitions apply.3.1
product: Result of activities or processes.NOTE 1
A product may include service, hardware, processed materials, software or a combination thereof.NOTE 2
A product can be tangible (e.g. assemblies or processed materials) or intangible (e.g. knowledge or concepts), or acombination thereof.NOTE 3
For the purposes of this International Standard, the term “product” applies to the intended product offering only andnot to unintended “by-products” affecting the environment. This differs from the definition given in ISO 8402.[ISO 9001]3.2
tender: Offer made by a supplier in response to an invitation to satisfy a contract award to provide product.[ISO 9001]SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO23.3
contract: Agreed requirements between a supplier and customer transmitted by any means.[ISO 9001]3.4
baseline: A formally approved version of a configuration item, regardless of
media, formally designated andfixed at a specific time during the configuration item's life cycle.[ISO/IEC 12207]3.5
development: Software life cycle process that comprises the activities of requirements analysis, design,coding, integration, testing, installation and support for acceptance of software products.3.6
life cycle model: A framework containing the processes, activities, and tasks involved in the development,operation, and maintenance of a software product, spanning the life of the system from the definition of itsrequirements to the termination of its use.[ISO/IEC 12207]3.7
phase: Defined segment of work.NOTE —
A phase does not imply the use of any specific life cycle model.3.8
regression testing: Testing to determine that changes made in order to correct defects have not introducedadditional defects.3.9
replication: Copying a software product from one medium to another.3.10
software:
See software product (3.11).NOTE —
In this part of ISO 9000, the term “software” is confined to computer software.3.11
software product: The set of computer programs, procedures, and possibly associated documentation anddata.[ISO/IEC 12207]NOTE —
A software product may be designated for delivery, an integral part of another product, or used in the developmentprocess.3.12
software item: Any identifiable part of a software product.4
Quality system requirements4.1
Management responsibility4.1.1
Quality policyThe supplier's management with executive responsibility shall define and document its policy forquality including objectives for quality and its commitment to quality.
The quality policy shall berelevant to the supplier's organizational goals and the expectations and needs of its customers.
Thesupplier shall ensure that this policy is understood, implemented and maintained at all levels of theorganization.No further software-related guidance is provided.SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)34.1.2
Organization4.1.2.1
Responsibility and authorityThe responsibility, authority and the interrelation of personnel who manage, perform and verify workaffecting quality shall be defined and documented, particularly for personnel who need theorganizational freedom and authority to:a)initiate action to prevent the occurrence of any nonconformities relating to product, process andquality system;b)identify and record any problems relating to the product, process and quality system;c)initiate, recommend or provide solutions through designated channels;d)verify the implementation of solutions;e)control further processing, delivery or installation of nonconforming product until the deficiencyor unsatisfactory condition has been corrected.No further software-related guidance is provided.4.1.2.2
ResourcesThe supplier shall identify resource requirements and provide adequate resources, including theassignment of trained personnel (see 4.18), for management, performance of work and verificationactivities including internal quality audits.No further software-related guidance is provided.NOTE —
For further information see ISO/IEC 12207:1995, subclause 7.2.4.1.2.3
Management representativeThe supplier's management with executive responsibility shall appoint a member of the supplier'sown management who, irrespective of other responsibilities, shall have defined authority for:a)ensuring that a quality system is established, implemented and maintained in accordance withthis International Standard, and;b)reporting on the performance of the quality system to the supplier's management for review andas a basis for improvement of the quality system.NOTE 5
The responsibility of a management representative may also include liaison with external partieson matters relating to the supplier's quality system.No further software-related guidance is provided.NOTE —
For further information, see ISO/IEC 12207:1995, subclause 6.3.1.6.4.1.3
Management reviewThe supplier's management with executive responsibility shall review the quality system at definedintervals sufficient to ensure its continuing suitability and effectiveness in satisfying the requirementsof this International Standard and the supplier's stated quality policy and objectives (see 4.1.1).Records of such reviews shall be maintained (see 4.16).SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO4No further software-related guidance is provided.NOTE —
For further information, see ISO/IEC 12207:1995, subclause 7.1.4.4.2
Quality system4.2.1
GeneralThe supplier shall establish, document and maintain a quality system as a means of ensuring thatproduct conforms to specified requirements.
The supplier shall prepare a quality manual coveringthe requirements of this International Standard.
The quality manual shall include or make referenceto the quality system procedures and outline the structure of the documentation used in the qualitysystem.NOTE 6
Guidance on quality manuals is given in ISO 10013.No further software-related guidance is provided.4.2.2
Quality system proceduresThe supplier shall:a)prepare documented procedures consistent with the requirements of this InternationalStandard and the supplier's stated quality policy, and;b)effectively implement the quality system and its documented procedures.For the purpose of this International Standard, the range and detail of the procedures that form partof the quality system shall be dependent upon the complexity of the work, the methods used, andthe skills and training needed by personnel involved in carrying out the activity.NOTE 7
Documented procedures may make reference to work instructions that define how an activity isperformed.No further software-related guidance is provided.4.2.3
Quality planningThe supplier shall define and document how the requirements for quality will be met.
Qualityplanning shall be consistent with all other requirements of a supplier's quality system and shall bedocumented in a format to suit the supplier's method of operation.
The supplier shall giveconsideration to the following activities, as appropriate, in meeting the specified requirements forproducts, projects or contracts:a)the preparation of quality plans;b)the identification and acquisition of any controls, processes, equipment (including inspectionand test equipment), fixtures, resources and skills that may be needed to achieve the requiredquality;c)ensuring the compatibility of the design, the production process, installation, servicing,inspection and test procedures and the applicable documentation.d)the updating, as necessary, of quality control, inspection and testing techniques, including thedevelopment of new instrumentation;e)the identification of any measurement requirement involving capability that exceeds the knownstate of the art, in sufficient time for the needed capability to be developed;SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)5f)the identification of suitable verification at appropriate stages in the realization of product;g)the clarification of standards of acceptability for all features and requirements, including thosewhich contain a subjective element;h)the identification and preparation of quality records (see 4.16).NOTE 8
The quality plans referred to [see 4.2.3a)] may be in the form of a reference to the appropriatedocumented procedures that form an integral part of the supplier's quality system.Quality planning should address the following items, as appropriate:a) quality requirements, expressed in measurable terms, where appropriate;b) the life cycle model to be used for software development;c) defined criteria for starting and ending each
project phase;d) identification of types of reviews, tests and other verification and validation activities to be carried out;e) identification of
configuration management procedures to be carried out;f) detailed planning (including schedules, procedures, resources and approval) and specific responsibilities andauthorities for:—configuration management,—verification and validation of developed products,—verification and validation of purchased products,—verification of customer-supplied products,—control of nonconforming product and corrective action,—assuring that activities described in the quality plan are carried out.A quality plan provides the means for tailoring the application of the quality system to a specific project, product orcontract.A quality plan may include or reference generic and/or project/product/contract-specific procedures, as appropriate.
Aquality plan should be updated along with the progress of the development, and items concerned with each phaseshould be completely defined when starting that phase.A quality plan should be reviewed and agreed by all organizations concerned in its implementation.The document that describes a quality plan may be an independent document (entitled quality plan), a part of anotherdocument, or composed of several documents.A quality plan may include, or reference, the plans for unit, integration, system and acceptance tests.
Guidance on testplanning and the test environment is provided as part of inspection and testing .NOTE —
Guidance on quality plans is given in ISO 10005 and on configuration management in ISO 10007. For furtherinformation, see ISO/IEC 12207:1995, subclauses 6.2 to 6.5.4.3
Contract review4.3.1
GeneralThe supplier shall establish and maintain documented procedures for contract review and for thecoordination of these activities.Software may be developed as part of a contract, as a product available for a market sector, as software embedded ina hardware product, or in support of the business processes of the supplier.
Contract review is applicable in all thesecircumstances.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO64.3.2
ReviewBefore submission of a tender, or the acceptance of a contract or order (statement of requirement),the tender, contract or order shall be reviewed by the supplier to ensure that:a)the requirements are adequately defined and documented; where no written statement ofrequirement is available for an order received by verbal means, the supplier shall ensure thatthe order requirements are agreed before their acceptance;b)any differences between the contract or order requirements and those in the tender areresolved;c)the supplier has the capability to meet the contract or order requirements.The following concerns may also be relevant during the supplier's review of software tenders, contracts, or orders.a)Customer-related concerns:—the terminology to be used, is agreed by the relevant parties;—the customer has the capability and resources to meet the defined contractual obligations;—agreed criteria for customer to accept or reject product;—the customer's responsibilities in the provision of
data and related facilities;—the extent to which the customer is to participate in joint development or in subcontracted work;—the arrangements for joint reviews to monitor progress of the contract;—the agreed procedure for handling changes in customer's requirements during the development and/ormaintenance;—life-cycle processes imposed by the customer;—handling of problems detected after acceptance, including customer complaints and claims;—the responsibility for removal of nonconformities after any warranty period;—any obligations for the customer to upgrade to a subsequent version when the supplier dictates, or for thesupplier to maintain historic versions;—deployment and associated user training.b)Technical concerns:—the feasibility of meeting the requirements;—the software development standards and procedures to be used;—facilities, tools, software items and data, to be provided by the customer, are identified and methods definedand documented to assess their suitability for use;—the operating system or hardware platform;—agreement on the control of interfaces with the software product;—replication and distribution requirements.c)Management concerns:—possible contingencies or risks are identified and the impact of these on subsequent activities are assessed;—the supplier's responsibility with regard to subcontracted work;—scheduling of progress, technical reviews and deliverables;—installation, maintenance and support requirements;—the timely availability of technical, human and financial resources.d)Legal, security and confidentiality concerns:—information handled under the contract may be subject to concerns regarding Intellectual Property Rights,licence agreements, confidentiality and the protection of such information;—guardianship of the master copy of the product and the rights of the customer to access or verify that mastercopy;—the level of information disclosure to the customer needs to be mutually agreed to by the parties;—definition of warranty terms;—liabilities/penalties associated with the contract.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.2.1, 5.2.6 and 6.4.2.1.SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)74.3.3
Amendment to a contractThe supplier shall identify how an amendment to a contract is made and correctly transferred to thefunctions concerned within the supplier's organization.No further software-related guidance is provided.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.1.3.5 and 5.2.3.2.4.3.4
RecordsRecords of contract reviews shall be maintained (see 4.16).NOTE 9
Channels for communication and interfaces with the customer's organization in these contractmatters should be established.No further software-related guidance is provided.4.4
Design control4.4.1
GeneralThe supplier shall establish and maintain documented procedures to control and verify the design ofthe product in order to ensure that the specified requirements are met.This subclause provides guidance on the development activities of requirements analysis, architectural design, detaileddesign and coding. This subclause also contains guidance on development planning.A software development project should be organized according to one or more life cycle models.
Processes, activitiesand tasks should be planned and performed according to the nature of the life cycle model used.
The life cycle modelused may be adapted to suit particular project needs. This part of ISO 9000 is intended for application irrespective ofthe life cycle model used and is not intended to indicate a specific life cycle model.A life cycle model identifies a set of processes and specifies when and how the processes are invoked.
The sequencein which the processes are described in this part of ISO 9000 does not suggest in any way the sequence in which theyare performed.The development process is that which transforms the requirements into a software product.
This process should becarried out in a disciplined manner, in order to prevent the introduction of errors. This approach reduces dependenceon the verification and validation processes as the sole methods for identifying problems.
The supplier shouldtherefore establish and maintain documented procedures that ensure that the software products are developed incompliance with specified requirements and in accordance with the development plan and/or quality plan.The following aspects inherent to the design activities should be taken into account:a)Design method: a design method should be systematically used.
Consideration should be given to the suitabilityof that method for the type of task, product or project and the compatibility of the application, the methods and thetools to be used.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO8b)Use of past experiences: utilizing lessons learned from past experiences,
the supplier should avoid recurrencesof the same or similar problems by applying lessons learned from previous projects, analysis of metrics and post-project reviews.c)Subsequent processes: to the extent practical, the software product should be designed to facilitate testing, install-ation, maintenance and use.d)Security and safety: special consideration should be given to the design for testability or validation.
For productswhere failure may cause damage to people, property or the environment, design of such software should ensuredefinition of specific design requirements that specify desired immunity from, and system response to, potentialfailure conditions.For coding, rules for the use of programming languages, consistent naming conventions, coding and adequatecommentary rules should be specified and observed.
Such rules should be documented and controlled.The supplier may use tools, facilities and techniques in order to make the quality system guidelines in this part of ISO9000 effective.
These tools, facilities and techniques can be effective for management purposes as well as for productdevelopment and/or servicing.
Whether these tools and techniques are developed internally, or purchased, thesupplier should evaluate whether or not they are fit for purpose.
Tools used in the implementation of the product, suchas analysis and design tools, compilers, and assemblers should be approved and placed under an appropriate level ofconfiguration management control, prior to use. The scope of use of such tools and techniques should be documentedand their use reviewed as appropriate, to determine whether there is a need to improve and/or upgrade them.Personnel may need training in the use of such tools and techniques, at commencement of usage, or after anyimprovements/upgrades.4.4.2Design and development planningThe supplier shall prepare plans for each design and development activity.
The plans shall describeor reference these activities, and define responsibility for their implementation.
The design anddevelopment activities shall be assigned to qualified personnel equipped with adequate resources.The plans shall be updated as the design evolves.For software products, development planning should determine the activities of requirements analysis, design, coding,integration, testing, installation and support for acceptance of software products. Development planning should bedocumented in a development plan.A development plan should be reviewed and approved. A development plan may have other names such as “softwaredevelopment plan” or “software project plan”.A development plan may define how the project is to be managed, the progress reviews required and the type andfrequency of reports to management, the customer, and other relevant parties, taking into account any contractualrequirements.Development planning should address the following items, as appropriate:a)the definition of the project, including a statement of its objectives and reference to any related customer orsupplier projects;b)the definition of input and output of the project as a whole;c)the organization of the project resources, including the team structure, responsibilities, use of subcontractors andmaterial resources to be used;d)organizational and technical interfaces between different individuals or groups, such as—sub-project teams,—subcontractors,SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)9—users,—customer representatives,—quality assurance representative;e)the identification of, or reference to—development activities to be carried out,—required inputs to each activity,—required outputs from each activity,—management and supporting activities to be carried out;f)
the analysis of the possible risks, assumptions, dependencies and problems associated with the development;g)the schedule identifying—the phases of the project,—the work to be performed (the inputs to, outputs from and definition of each task),—the associated resources and timing,—the associated dependencies,—the milestones;h)the identification of—standards, rules, practices and conventions,—tools and techniques for development, including the qualification of, and configuration controls placed on,such tools and techniques,—configuration management practices,—method of controlling nonconforming products,—methods of control of nondeliverable software used to support development,—procedures for archiving, back-up and recovery, including contingency planning,—methods of control for virus protection;i)the identification of related plans (including system level plans) such as—quality plan,—risk management plan,—configuration management plan,—integration plan,—test plan,—installation plan,—migration plan,—training plan,—maintenance plan,—re-use plan.The development plan and any of these related plans may be an independent document, a part of another document orcomposed of several documents.NOTE —
For further information, see ISO/IEC 12207:1995, subclause 5.2.4.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO104.4.3Organizational and technical interfacesOrganizational and technical interfaces between different groups which input into the design processshall be defined and the necessary information documented, transmitted and regularly reviewed.The boundaries of responsibility for each part of the software product and the way that technical information will betransmitted between all parties should be clearly defined in the development plans of suppliers or subcontractors.
Thesupplier may require submission of a subcontractor's development plan, for review.In defining interfaces, care should be taken to consider parties, other than the customer and supplier, who need inputto the design, installation, maintenance and training activities.
These may include subcontractors, regulatoryauthorities, associated development projects and help-desk staff. In particular, the end-users and any intermediateoperations function may need to be involved to ensure that appropriate capacity and training are available to achievecommitted service levels.The customer may have certain responsibilities under the contract.
Particular concerns include the need for thecustomer to cooperate with the supplier, to provide necessary information in a timely manner, and resolve action items.Where a customer representative is appropriate, he/she may represent the eventual user of the product, as well asexecutive management, and have the authority to deal with contractual matters which include, but are not limited to, thefollowing:a)defining the customer's requirements to the supplier;b)answering questions from the supplier;c)approving the supplier's proposals;d)concluding agreements with the supplier;e)ensuring that the customer's organization observes the agreements made with the supplier;f)defining the acceptance criteria and procedures;g)dealing with customer-supplied software items, data, facilities and tools that are found unsuitable for use;h)defining the customer's responsibility.Where mutually agreed, joint reviews involving the supplier and customer may be scheduled on a regular basis, or atsignificant project events, to cover the following aspects, as appropriate:a)the progress of software development work undertaken by the supplier;b)the progress of agreed activities being undertaken by the customer;c)conformance of the development products to the customer's agreed requirements specification;d)the progress of activities concerning the eventual users of the system under development, such as systemconversion and training;e)verification results;f)acceptance test results.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.2.6.1 and 6.6.2.4.4.4Design inputDesign input requirements relating to the product, including applicable statutory and regulatoryrequirements, shall be identified, documented and their selection reviewed by the supplier foradequacy.
Incomplete, ambiguous or conflicting requirements shall be resolved with thoseresponsible for imposing these requirements.Design input shall take into consideration the results of any contract review activities.The requirements specification should be provided by the customer.
However, where mutually agreed, the suppliermay provide the specification.
In such a case, the supplier should, where appropriate:SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)11a)establish documented procedures for developing the requirements specification, including—methods for agreeing on requirements and authorizing changes, especially during iterative development,—methods for the evaluation of prototypes or demonstrations, where used,—recording and reviewing discussion results on both sides,b)develop the requirements specification in close cooperation with the customer and make efforts to preventmisunderstandings by, for example, provision of definition of terms, explanation of the background ofrequirements,c)obtain the customer's approval of the requirements specification.Interviews, surveys, studies, prototypes, demonstrations and analysis methods may be used for developing therequirements specification, as appropriate.The requirements specification may be provided and agreed in the form of a system specification.
In this case,procedures should be in place to ensure the correct allocation of system requirements into hardware and softwareaspects and also the appropriate interface specifications.The requirements specification may not be fully defined at contract acceptance, and may be developed during aproject.
The contract may be amended when the requirements specification changes.
Changes to the requirementsspecification should be controlled.The requirements should include all aspects necessary to satisfy the customer's agreed needs.
The requirementsspecification may need to take the operational environment into account.
The requirements may include, but not belimited to the following characteristics: functionality; reliability; usability; efficiency; maintainability and portability (seealso ISO/IEC 9126).
Sub-characteristics may be specified, for example security. Safety
considerations and statutoryobligations may also be specified.If the software product needs to interface with other software or hardware products, the interfaces between thesoftware product to be developed and other software or hardware products should be specified, as far as possible,either directly or by reference, in the requirements specification.The requirements should be expressed in terms which allow validation during product acceptance.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.3.2 to 5.3.4.4.4.5Design outputDesign output shall be documented and expressed in terms that can be verified and validatedagainst design input requirements.Design output shall:a)meet the design input requirements;b)contain or make reference to acceptance criteria;c)identify those characteristics of the design that are crucial to the safe and proper functioning ofthe product (e.g., operating, storage, handling, maintenance and disposal requirements).Design output documents shall be reviewed before release.The required output from the design activity should be defined and documented in accordance with the chosenmethod.
This documentation should be correct, complete and consistent with the requirements.
Design outputs mayinclude:—architectural design specification;—detailed design specification;—source code;—user guides.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses
5.3.5 to 5.3.7.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO124.4.6Design reviewAt appropriate stages of design, formal documented reviews of the design results shall be plannedand conducted.
Participants at each design review shall include representatives of all functionsconcerned with the design stage being reviewed, as well as other specialist personnel, as required.Records of such reviews shall be maintained (see 4.16).The supplier should plan and implement review processes for all software development projects.
The degree offormality and rigour of the activities associated with the review processes should be appropriate to the complexity of theproduct and the degree of risk associated with the specified use of the software product.
The supplier should establishdocumented procedures for dealing with process and product deficiencies or nonconformities identified during theseactivities.During design reviews, aspects inherent to the design activities should be taken into account, for example feasibility,security and safety, programming rules and testability.The results of review, and any further activities required to ensure that the specified requirements are met, should berecorded and checked when they are completed.Most design reviews during the development are scheduled, but there may also be unscheduled design reviews.A documented design review procedure should address the following:a)what is to be reviewed, when, and the type of review;b)what functional groups would be concerned in each type of review and, if there is to be a review meeting, whowould chair it;c)
what records have to be produced, for example meeting minutes, issues, problems, actions and action status.Also the following may be addressed in the design review procedure:a)the methods for monitoring the application of rules, practices and conventions to ensure compliance, such as peerreviews, walkthroughs, code inspections;b)what has to be done prior to the conduct of a review, such as establishment of objectives, meeting agenda,documents required and roles of review personnel;c)what has to be done during the review, including the techniques to
be used and guidelines for all participants;d)the success criteria for the review;e)what follow-up methods are to be used to ensure that issues identified at the review are resolved.Where specified in the contract, the supplier should conduct design review meetings in cooperation with the customer.Both parties should agree on the results of such reviews.It is recommended that further design activities should proceed only when the consequences of all known deficienciesare satisfactorily resolved, or the risk of proceeding otherwise is known.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.3.4.2, 5.3.5.6, 5.3.6.7 and 6.6.3.4.4.7Design verificationAt appropriate stages of design, design verification shall be performed to ensure that the design stage outputmeets the design stage input requirements.
The design verification measures shall be recorded (see 4.16).NOTE 10In addition to conducting design reviews (see 4.4.6), design verification may include activities such as—performing alternative calculations,—comparing the new design with a similar proven design, if available,—undertaking tests and demonstrations, and—reviewing the design stage documents before release.SIST EN ISO 9000-3:1998

© ISOISO 9000-3:1997(E)13Verification of design should be performed as appropriate during the development process.
Design verification maycomprise reviews of design output, demonstrations including prototypes and simulations, or tests.
Verification may beconducted on the output from other development activities.
These verification activities should be planned andconducted in accordance with the quality plan or documented procedures to ensure that process outputs meet theprocess input requirements.The verification results and any further actions required to ensure that the design stage input requirements are metshould be recorded and checked when the actions are completed.Only verified design outputs should be submitted for acceptance and subsequent use. Any findings should beadequately addressed and resolved.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.3.4.2, 5.3.5.6, 5.3.5.7, 5.3.7.5, 5.3.9 and 6.4.4.4.8Design validationDesign validation shall be performed to ensure that product conforms to defined user needs and/orrequirements.NOTES11Design validation follows successful design verification (see 4.4.7).12Validation is normally performed under defined operating conditions.13Validation is normally performed on the final product, but may be necessary in earlier stages prior toproduct completion.14Multiple validations may be performed if there are different intended uses.Before offering the product for customer acceptance, the supplier should validate the product in accordance with itsspecified intended use, for example during final inspection and test.In software development, it is important that the validation results and any further actions required to ensure that thespecified requirements are met should be recorded and checked when the actions are completed.
Only validatedproducts should be submitted for acceptance and subsequent use.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.3.1 and 6.5.4.4.9Design changesAll design changes and modifications shall be identified, documented, reviewed and approved byauthorized personnel before their implementation.The supplier should establish and maintain procedures for controlling the implementation of any design changes, whichmay arise at any time during the product life cycle, in order to:a)document and justify the change;b)evaluate consequences of the change;c)approve or disapprove the change;d)implement and verify the change.In the software development environment, control of design changes is usually addressed under the discipline ofconfiguration management.NOTE —
For further information, see ISO/IEC 12207:1995, subclauses 5.5.2, 5.5.3 and 6.2.3.SIST EN ISO 9000-3:1998

ISO 9000-3:1997(E)© ISO144.5
Document and data control4.5.1
GeneralThe supplier shall establish and maintain documented procedures to control all documents and datathat relate to the requirements of this International Standard including, to the extent applicable,documents of external origin such as standards and customer drawings.NOTE 15
Documents and data can be in the form of any type of media, such as hard copy or electronicmedia.Configuration management procedures may be used to implement document and data control.
In establishing theprocedures to control documents and data, the supplier should identify those documents and data, including those ofexternal origin such as standards and customer data, which should be subject to the control procedures.The document and data control procedures should be applied to relevant documents and data, including the following:a)contractual documents including specification of requirements;b)procedural documents describing the quality system to be applied in the software life cycle;c)planning documents describing the planning and progress of activities of the supplier and the suppliersinteractions with the customer;d)product documents and data describing or associated with a particular software product.NOTE —
For further information, see ISO/IEC 12207, clause 6.1.4.5.2
Document and data approval and issueThe documents and data shall be reviewed and approved for adequacy by authorized personnelprior to issue.
A master list or equivalent document control procedure identifying the current revisionstatus of doc
...