4.1 Management responsibility

4.1.1
Quality policy 

Define a policy that describes your organization's attitude 
towards quality. Your quality policy should:

• State a clear commitment to quality.

• Recognize customer needs and expectations.

• Be actively supported by senior management.

• List the quality objectives you want to achieve.

• Be understood by everyone in the organization.

• Be consistent with your organization's goals.

• Be maintained throughout your organization.

• Be applied throughout your organization.

4.1.2
Organization

Define the organizational structure that you will 
need in order to manage a quality system.

4.1.2.1 Responsibility and authority

Define quality system responsibilities, give quality system personnel
the authority to carry out these responsibilities, and ensure that the
interactions between these personnel are clearly specified. And
make sure all of this is well documented. This requirement
must be met for those who:

• Manage quality system work.

• Perform quality system work. 

• Verify quality system work.

More specifically, this quality system requirement 
must be met for those who:

• Control nonconforming products.

• Prevent product nonconformities.

• Prevent process nonconformities.

• Prevent quality system nonconformities.

• Identify problems related to the quality system.

• Report problems related to the quality system.

• Record problems related to the quality system.

• Recommend solutions to quality system problems.

• Design solutions to quality system problems.

• Verify that solutions were implemented.

• Evaluate whether solutions were effective.

4.1.2.2 Resources

Identify and provide the resources that people will need to manage,
perform, and verify quality system work. Make sure that:

• Only trained personnel are assigned.

• Managers have the resources they need to verify work.

• Internal auditors have the resources they need.

4.1.2.3 Management representative

Appoint a senior executive to manage your quality system and
give him or her the necessary authority. This senior executive must
ensure that your quality system is developed and implemented. This
executive must:

• Monitor the performance of your quality system.

• Control the performance of your quality system.

• Report on the performance of your quality system.

• Help improve the performance of your quality system.

• Act as your organization's spokesperson on quality.

4.1.3
Management review

Define a procedure that your senior managers can use 
to review the effectiveness of your quality system.

• Quality system reviews should be:

  • Carried out on a regular basis.

  • Documented and records should be maintained.

• Quality system reviews should ensure that your:

  • Quality system requirements are being met.

  • Quality objectives are being achieved.

  • Quality policy is being applied.

4.2 Quality system

4.2.1
General 

Develop a quality system and a manual that describes it.

• Your quality system should ensure that your products  conform to all specified requirements.                      

•  Your quality manual should:

  • State your quality policy.

  • List your quality objectives.

  • Provide an overview of your quality system.

  • Describe the structure of your organization.

  • Discuss your quality system procedures.

  • Introduce your quality documents and records.

  • Teach people about your quality system.

  • Control quality system work practices.

  • Guide the implementation of your quality system.

  • Explain how your quality system will be audited.

4.2.2
Quality system procedures

Develop and implement quality system procedures 
that are consistent with your quality policy.

• Develop your procedures for all areas of your quality system.

• Document your procedures, and keep them up to date.

• Each procedure should:

  • Specify its purpose and scope.

  • Describe how an activity should be carried out.

  • Describe who should carry out the activity.

  • Explain why the activity is important to quality.

  • Describe when and where it should be carried out.

  • Explain what tools and equipment should be used.

  • Explain what supplies and materials should be used.

  • Explain what documents and records should be kept.

• Procedures may also refer to detailed work instructions  that explain exactly how the work should be done.

4.2.3
Quality planning

Develop quality plans that show how you intend to fulfill quality
system requirements. You are expected to develop quality plans
for products, processes, projects, and customer contracts.

• Your quality plans should list the quality objectives you intend to achieve, and the steps you intend to take to achieve these objectives.                                                         

• When you construct your quality plan, consider  the following questions:                                            

  • Do you need to purchase any new equipment or  instruments, or any new inspection and test tools?

  • Do you need to carry out any special training in  order to fulfill all quality system requirements?

  • Do you need to improve design, production, testing,  inspection, installation, or servicing procedures?

  • Do you need to improve your quality  measurement and verification procedures?

  • Do you need to develop any new  measurement methods or instruments?

  • Do you need to clarify your organization's  standards of acceptability?                                   

  • Do you need to develop any new documents,  forms, reports, records, or manuals?                     

  • Do you need to allocate more resources in  order to achieve the required levels of quality?

Quality planning for software

Develop quality plans to control your software development projects.

• Your quality plans should control:

  • Project implementation.

  • Project schedules.

  • Project resources.

  • Project approvals.

  • Project phases.

    • When a phase can begin.

    • When a phase has been completed.

• Your quality plans should define:

  • Quality requirements.

  • Responsibilities.

  • Authorities.

  • Life cycle model.

  • Review methods.

  • Testing methods.

  • Verification methods.

  • Validation methods.

• Develop detailed quality plans and procedures, and define  specific responsibilities and authorities to control:

  • Configuration management.

  • Product verification.

    • Verification of your developed products.

    • Verification of your purchased products.

    • Verification of your customer-supplied products.

  • Product validation.

    • Validation of your developed products.

    • Validation of your purchased products.

  • Nonconforming products.

  • Corrective actions.

• Your quality plans may include or refer to:

  • Generic project, product, or contract procedures.

  • Special project, product, or contract procedures.

• Your quality plan can be a separate document or it can  be part of another larger document. Or, it can be made  up of several specific documents.                           

• Your quality plan should be updated and refined  as your software development plan is implemented.

• Make sure that all participating groups and organizations get a chance to review and approve the quality plan before it is implemented.                                        

4.3 Contract review

4.3.1
General 

Develop and document procedures to coordinate the review
of sales orders and customer contracts. Make sure you include
the customer in the process of review.

Develop and document procedures to coordinate the review of
software development contracts. Develop procedures to coordinate
the review of contracts that affect:

• Software that will be developed for a customer.

• Software that will be developed for a market sector.

• Software that will be embedded in a hardware product.

• Software that will be developed for your internal use.

4.3.2
Review

Your contract review procedures should ensure that all contractual
requirements are acceptable before you agree to provide products to
your customers. Specifically, your procedures should make sure that:

• Your customer's order is clearly and completely defined.  When verbal orders are received, make sure that you  and your customer agree on what is required.

• You have resolved all differences between the original tender or proposal and the final contract or sales order.

• Your organization is capable of supplying the  products ordered by the customer.

Customer contract
review
questions

• Have you and your customer agreed on terminology?

• Have you and your customer agreed on the criteria  that will be used to accept or reject your product?

• Have you and your customer agreed on the data  and facilities that will be provided by the customer?

• Have you and your customer agreed on how joint progress reviews will be carried out?

• Have you and your customer agreed on how  joint product development will be carried out?

• Have you and your customer agreed on which life  cycle processes will be imposed by the customer?

• Have you and your customer agreed on how  your software product be deployed?                        

• Have you and your customer agreed on  how software users will be trained?                           

• Have you and your customer agreed on how you  will handle changes in customer requirements?

  • Have you agreed on how changes will be  handled during software development?

  • Have you agreed on how changes will be  handled during software maintenance?

• Have you and your customers agreed on  how software upgrades will be handled?                  

• Have you and your customers agreed on how     historical software versions will be handled?

• Have you and your customers agreed on how  problems will be handled after product acceptance?

  • Have you agreed on how complaints will be handled?

  • Have you agreed on how claims will be handled?

  • Have you agreed on who will be responsible  for nonconformities after the warranty runs out?

• Are you satisfied that your customer will be able  to meet all of his contractual obligations?

Technical
contract
review
questions

• Have you established that the project is feasible  and that all requirements can be met?

• Have you identified all the software development  standards that will be referred to during the project?

• Have you defined all the software development  procedures that will be used during the project?

• Have you defined all the facilities, tools, data, and  other items that must be provided by the customer?

  • Have you developed and documented methods for determining whether customer supplied facilities, tools, data, and items are suitable?

• Have you clarified which operating system  and which hardware platform will be used?

• Have you agreed on how interfaces with  the software product will be controlled?                 

• Have you defined all software replication  and distribution requirements?                             

Management contract review
questions 

• Have you identified significant risks and contingencies?

  • Have you evaluated the impact these could have?

• Have you clarified the extent of your responsibility  for subcontracted work?                                

• Have you established a project schedule?

  • Does it say when progress reviews will be done?

  • Does it say when technical reviews will be done?

  • Does it say when deliverables are due?

• Have you clarified and documented all installation,  maintenance, and support requirements?                

• Have you confirmed that all resources will  be available when you need them?                         

  • Will all technical resources be available?

  • Will all human resources be available?

  • Will all financial resources be available?

Legal contract
review questions

• Have you taken steps to respect the rights of others?

  • Will you respect all intellectual property rights?

  • Will you respect all licensing agreements?

  • Will you respect all confidentiality requirements?

• Have you clarified the rules governing the  guardianship of the master software copy?

  • Have you clarified the conditions under which  the customer may access or verify the master copy?

  • Have you clarified exactly what kinds of information  wil or will not be disclosed to the customer?

  • Have you defined all product warranty terms?

  • Have you defined all contractual liabilities and penalties?

4.3.3
Amendments

Develop procedures which specify how customer contracts 
are amended, and which ensure that changes in contracts 
are communicated throughout the organization.

4.3.4
Records 

Develop a record keeping system that you can use to 
document the review of customer orders and contracts.

4.4 Software development and design

4.4.1
General 

Develop and document procedures to control the product
design and development process. These procedures must
ensure that all requirements are being met.

Software development 

Control your software development project and make 
sure that it is executed in a disciplined manner.

• Use one or more life cycle models to help  organize your software development project.

• Develop and document your software development  procedures. These procedures should ensure that:

  • Software products meet all requirements.

  • Software development follows your:

    • Quality plan.

    • Development plan.

Software design

Control your software design process and make 
sure that it is performed in a systematic way.

• Use a suitable software design method.

• Study previous software design projects  to avoid repeating old mistakes.                          

Design software that is:

• Easy to test, install, use, and maintain.

• Safe and reliable when failure could cause:

  • Human injury.

  • Property damage.

  • Environmental harm.

Develop and document rules to control:

• Coding activities.

• Naming conventions.

• Commentary practices.

• Programming languages.

Apply configuration management techniques to 
document and control the use and review of all:

• Analysis tools.

• Design techniques.

• Compilers and assemblers.

Train personnel in the use of such tools and techniques.

4.4.2
Design and development planning 

Create design and development planning procedures. 
Your product planning procedures should ensure that:

• Plans are prepared for each design activity or phase.

• Responsibility for implementing each plan,  activity, or phase is properly defined.

• Qualified personnel are assigned to the   product design and development process.

• Adequate resources are allocated to the  product design and development process.

• Plans are updated, and circulated to the  appropriate participants, as designs change.

Software design and development planning

Prepare a software development plan. Your plan should
be documented and approved before it is implemented.
Your plan should control:

• Technical activities. 

  • Requirements analyses.

  • Design processes.

  • Coding activities.

  • Integration methods.

  • Testing techniques.

  • Installation work.

  • Acceptance testing.

• Management activities.

  • Project supervision.

  • Progress reviews.

  • Reporting requirements.

Your software development plan should:

• Define your project.

• Identify related plans and projects.

• List your project objectives.

• Define project inputs and outputs.

  • Define inputs for each project activity.

  • Define outputs for each project activity.

• Explain how your project will be organized.

  • Explain how your teams will be structured.

  • Explain who will be responsible for what.

  • Explain how subcontractors will be used.

  • Explain how project participants will interact.

  • Explain how all resources will be managed.

• Discuss project risks and potential problems.

• Identify important project assumptions.

• Present your project schedule.

  • Define project phases and dependencies.

  • Specify project time lines and milestones.

  • Introduce your project budget.

  • Describe the work that will be done.

    • Describe each task.

    • Describe the inputs for each task.

    • Describe the outputs for each task.

• Identify all relevant control strategies.

  • Identify all relevant standards and conventions.

  • Identify all relevant rules and regulations.

  • Identify all relevant practices and procedures.

    • Identify configuration management practices.

    • Identify backup and recovery procedures.

    • Identify archiving procedures.

  • Identify all relevant methods and approaches.

    • Identify methods used to control nonconforming products.                           

    • Identify methods used to control software development software.                

    • Identify methods used to control virus protection activities.                    

  • Identify all relevant tools and techniques.

    • Identify methods used to qualify all tools and techniques.                            

    • Identify methods used to control all tools and techniques.                          

4.4.3
Organizational and technical interfaces

Identify the groups who should be routinely involved in the
product design and development process, and ensure that their
design input is properly documented, circulated, and reviewed.

Make sure that your software development 
plan or your subcontractors' plans:

• Define how the responsibility for software development  will be distributed between all participants.

• Define how technical information will be shared  and transmitted between all participants.

Explain how all project participants will provide input.

• Explain how subcontractors will provide input during  design, installation, maintenance, and training.

• Explain how regulatory authorities will provide input  during design, installation, maintenance, and training.

• Explain how help desk staff will provide input during  design, installation, maintenance, and training.

• Explain how other related projects will provide input  during design, installation, maintenance, and training.

• Explain how end users will provide input during  design, installation, maintenance, and training.

Make sure that your customer has 
accepted the responsibility to:

• Cooperate and support your project.

• Provide the information you need when you need it.

• Resolve outstanding issues in a timely manner.

Make sure that your customer representative has 
been given the responsibility and authority to:

• Clarify requirements and expectations.

• Answer questions and solve problems.

• Make and implement agreements.

• Approve plans and proposals.

• Establish acceptance criteria.

• Provide appropriate customer-supplied products.

• Define and distribute authorities and responsibilities.

Schedule joint progress reviews. You and 
your customer together should review:

• Activities.

  • Your developmental activities.

  • Your customer's activities.

  • Your users' activities.

    • Training activities.

    • Conversion activities.

• Results.

  • Results of verification activities.

  • Results of acceptance tests.

  • Results of conformance evaluations.

4.4.4
Design input 

Develop procedures to ensure that all design-input requirements
are identified, documented, and reviewed; and that all design flaws,
ambiguities, contradictions, and deficiencies are resolved. Design
input requirements can be classified as follows:

• Customer expectations.

• Contractual conditions.

• Statutory imperatives.

• Regulatory requirements.

• Environmental constraints.

• Safety considerations.

• Performance standards.

• Functional specifications.

• Descriptive prescriptions.

• Aesthetic preferences.

Software 
design input

Design input requirements should be specified by the customer.
However, sometimes the customer will expect you to develop
the design input specification. In this case, you should:

• Prepare procedures that you can use to develop the design input specification. These procedures should be documented and should explain:

  • How interviews, surveys, studies, prototypes, and demonstrations will be used to develop your design input specification.                     

  • How you and your customer will formally agree:

    • To accept the official specification.

    • To accept changes to the official specification.

  • How changes to specifications will be controlled.

  • How prototypes and product demonstrations are evaluated.

  • How input requirements will be met through the use of hardware, software, and interface technologies.

  • How reviews, evaluations, and other discussions  between you and your customer will be recorded.

• Work closely with your customer in order to avoid misunderstandings and to ensure that the specification meets the customers needs.                                

• Express your specification using terms that will make  it easy to validate during product acceptance.

• Ask your customer to formally approve the resulting design input specification.                         

Your design input specification may address the 
following kinds of characteristics or requirements:

• Functional requirements.

• Reliability requirements.

• Usability requirements.

• Efficiency requirements.

• Maintainability requirements.

• Portability requirements.

• Interface requirements.

  • Hardware interface requirements.

  • Software interface requirements.

• Operational requirements.

• Safety requirements.

• Security requirements. 

• Statutory requirements.

4.4.5
Design output

Develop procedures to control design outputs.

• Design outputs are usually documents. They include drawings, parts lists, process specifications, servicing procedures, and storage instructions. These types of documents are used for purchasing, production, installation, inspection, testing, and servicing.

• Design outputs must be expressed in terms that allow  them to be compared with design input requirements.

• Design output documents must identify those aspects of the product that are crucial to its safe and effective operation. These aspects can include operating, storage, handling, maintenance, and disposal requirements.                 

• Design output documents must be reviewed  and approved before they are distributed.                 

• Design outputs must be accepted only if  they meet official acceptance criteria.

Software 
design output 

• Prepare design output documents using standardized methods and make sure that your documents are correct and complete.

• Software design outputs can include design specifications,  source code, user guides, etc.                             

4.4.6
Design review

Develop procedures that specify how design reviews should be 
planned and performed. Design review procedures should:

• Be formally documented.

• Ensure that reviews are recorded.

• Ensure that representatives from all relevant  areas are involved in the process of review.

Software design review

Plan and perform design reviews for software development 
projects. Your reviews should ensure that all:

• Design activities and results are reviewed.

• Product nonconformities are identified and addressed.

• Process deficiencies are identified and addressed.

• Review conclusions and observations are recorded.

Software design review procedures

Develop and document design review procedures. 
Your procedures should make sure that you:

• Clarify exactly what is being reviewed.

• Distinguish between different types of reviews.

• Organize and schedule design review meetings.

• Indicate when design reviews should be performed.

• Maintain a record of all design review meetings.

• Invite all appropriate groups to participate.

  • Invite customers to participate (when required).

    • Confirm that customers agree with your results.

• Allow design activities to continue only if all:

  • Deficiencies and nonconformities have been addressed.

  • Risks and consequences have been assessed.

Your design review procedures may also:

• Define the methods that should be used to ensure  that all rules and conventions are being followed.

• Define what needs to be done to prepare  for a design review. This may include:                

  • Defining roles.

  • Listing objectives.

  • Preparing an agenda.

  • Collecting documents.

• Define what should be done during the review.  This may include:                                    

  • Defining the guidelines that should be followed.

  • Defining the techniques that should be used.

• Define the criteria that constitute a successful review.

• Define the follow-up methods that should be used to  ensure that all outstanding issues will be addressed.

4.4.7
Design verification

Develop procedures that specify how design outputs, at every stage
of the product design and development process, should be verified.
These procedures should:

• Verify that outputs satisfy design-input requirements.

• Ensure that objective evidence is used to verify outputs.

• Ensure that all design verifications are recorded.

• Ensure that all design documents are verified.

These design verification procedures may also:

• Use alternative calculations to verify design outputs.

• Use tests and demonstrations to verify outputs.

• Compare design outputs with proven designs.

Software design verification

Verify design outputs by:

• Performing design reviews.

• Performing demonstrations. 

  • Evaluating prototypes.

  • Carrying out simulations.

• Performing tests.

Maintain a record of design verifications.

• Record verification results.

• Record remedial actions.

• Record action completions.

Accept design outputs for subsequent use only if they have been
properly verified and only if all remedial actions have been taken.

4.4.8
Design
validation

Develop procedures that validate the assumption that your newly
designed products will meet customer needs. Develop design
validation procedures that:

• Confirm that your new product performs properly  under all real world operating conditions.

• Confirm that your new product will meet every legitimate customer need and expectation.

• Ensure that validations are carried out early in the design process whenever this will help guarantee that customer needs will be met.

Software design validation

• Prove that your product is ready for its intended  use before you ask your customer to accept it.

• Accept validated products for subsequent use only if they have been properly verified and only if all remedial actions have been taken.

• Maintain a record of design validations.

  • Record validation results.

  • Record remedial actions.

  • Record action completions.

4.4.9
Design changes

Develop procedures to ensure that all product design modifications are
documented, reviewed, and formally authorized before the resulting
documents are circulated and the changes are implemented.

Software design changes

• Develop procedures to control design changes that may occur during the product life cycle. Your procedure should ensure that you:                                               

  • Document the design change.

  • Evaluate the design change.

  • Justify the design change.

  • Verify the design change.

  • Approve the design change.

  • Implement the design change.

  • Monitor the design change.

• Your configuration management process  may be used to control design changes.                          

4.5 Document and data control

4.5.1
General 

Develop procedures to control all the documents and data related
to your quality system. These procedures should control:

• Internal and external documents and data.

• Electronic or hardcopy documents and data.

Identify all documents and data that must be controlled.

• Identify all internal documents that must be controlled.

• Identify all external documents that must be controlled.

Develop procedures to control documents and data.

• Use configuration management procedures  to control documents and data (if appropriate).

Use your procedures to control the following 
kinds of quality documents and data:

• Communications.

• Specifications.

• Requirements.

• Descriptions.

• Instructions.

• Procedures.

• Contracts.

• Standards.

• Manuals.

• Reports.

• Plans.

Your procedures should control documents and data
connected with the following kinds of activities:

• Interactions with customers.

• Periodic evaluations.

• Progress reviews.

Your procedures should control documents and data 
connected with the following kinds of things:

• Software products.

• Quality systems.

4.5.2
Document and data approval and distribution

Develop procedures to review, approve, and manage all
of your quality system documents and data. These procedures
should ensure that:

• Only authorized people are allowed to formally  approve documents and data prior to distribution.

• All documents and data are formally approved before  they are distributed throughout the organization.

• The accidental use of obsolete documents and data is prevented.

• Only current versions of documents are available for use.

• Documents and data, that are used to maintain your quality system, are available whenever they are needed.

• Documents that are retained for legal or historical purposes should be marked as such and segregated from current versions.

Develop procedures to control electronic documents
and data. These procedures should control:

• The media to be used.

• The process to be followed. 

  • The access process.

  • The approval process.

  • The removal process.

  • The distribution process.

  • The archiving process.

4.5.3
Document and data changes

Develop procedures to control changes to documents and data. 
These procedures should ensure that changes are:

• Justified.

• Marked as changes.

• Reviewed and approved by original review and approval groups.

The procedures should also ensure that these review and approval
groups have all the information they need to justify their approval.

4.6 Purchasing requirements

4.6.1
General 

Develop procedures to ensure that purchased products (including
services) meet all requirements. These procedures should control
the selection of subcontractors, the use of purchasing data, and
the verification of purchased products.

Types of
purchased
products and services

• Purchased products.

  • Software products.

    • Software purchased "off-the-shelf".

    • Software developed by subcontractors.

  • Hardware products.

    • Computer hardware.

    • Communications hardware.

  • Other products.

    • Tools used during software development.

    • Training materials and supplies.

• Purchased services.

  • Services provided by contractors.

  • Software maintenance services.

  • Customer support services.

4.6.2
Evaluation of subcontractors

Develop procedures to select, evaluate, monitor, and
control your subcontractors (your suppliers). These
procedures should define how:

• Subcontractors are selected.

• Subcontractor performance is monitored.

• Subcontractor performance is evaluated.

• Subcontractor performance is controlled.

These procedures should ensure that subcontractors 
are chosen only if they are able to meet your:

• Contractual expectations.

• Quality assurance requirements.

Make sure that quality records are kept which chronicle
the performance of your subcontractors. Your records should
identify the acceptable subcontractors and the products and
services they provide.

4.6.3
Purchasing data

Develop procedures to ensure that your purchase order
documents precisely describe what you want to buy.
When appropriate, these procedures should ensure
that your purchasing documents:

• Use technical specifications and drawings  to describe exactly what you want to order.

• State the type or grade of product being purchased.

• Define product inspection and approval requirements.

• Specify process requirements that must be met.

• Identify process equipment that should be used.

• Describe procedures that should be followed.

• Specify technical support service requirements.

• Reference the applicable quality system standards.

• Are carefully reviewed to ensure that they meet all  requirements before they are approved and issued.

Purchasing data and documents related to software development

Make sure that your purchasing documents:

• Identify the products you wish to order.

• Identify the specifications that must be met.

• Identify the standards that must be applied.

• Identify the protocols that must be followed.

• Identify the procedures that must be followed.

• Identify the instructions that must be followed.

• Identify the development environment that will be used.

• Identify the requirements that personnel must respect.

4.6.4
Verification of purchased product

Develop procedures that allow you or your customers 
to verify the acceptability of products you have purchased.

4.6.4.1 Supplier verification at subcontractor's place

When you must verify the acceptability of purchased products
at the subcontractor's premises, ensure that your purchase order
documents and contracts specify your verification and acceptance
requirements and methods.

4.6.4.2 Customer verification of subcontracted product

When your customers wish to verify the acceptability of the
products you purchase on their behalf, ensure that they are given
this opportunity at both the subcontractors' premises and yours.

4.7 Customer-supplied products

Protect customer supplied products 

Develop procedures to control products supplied to you 
by customers. These procedures should ensure that you:

• Examine the product when you receive it to confirm  that the right items were shipped without loss or damage.

• Prevent product loss, misuse, damage, or deterioration  through proper storage and security.                          

• Record product loss, misuse, damage, or deterioration,  and report it to the customer.                             

• Clarify who is responsible for the maintenance and  control of the product while it is in your possession.

Products and services supplied to you by your customers 

Control the following types of products, services, documents, 
and data supplied to you by your customers:

• Products.

  • Software.

  • Hardware.

• Services.

  • Network services.

  • Developmental support.

• Documents.

  • Specifications.

  • Proprietary information.

• Data.

  • Test data.

  • Operational data.

Define how customer supplied products, 
services, documents, and data will be:

• Accepted from your customers.

• Integrated into your project.

TO SEE SECTIONS 4.8 TO 4.20, PLEASE GO TO PAGE TWO

ISO 9000-3 is NOW OBSOLETE. It has been replaced by ISO 90003.