ISO 9000-3 Software Standard in Plain English

We've just finished our Plain English version of ISO IEC 90003:2004.
It translates the ISO IEC 90003 2004 software standard into plain English
using a task oriented checklist approach. It is 175 pages long.
If you would like to purchase this product (Title 60),
please go to http://praxiom.com/orders.htm.

This web page is based on the ISO 9000-3:1997 Quality Standard
published by the International Organization for Standardization.
It presents a detailed and comprehensive interpretation of this
standard using language that is clear and easy to understand.
If you're looking for a complete interpretation of this quality
management standard, you've come to the right place.

ISO prepared the ISO 9000-3:1997 quality standard in order to help
companies to apply the ISO 9001:1994 standard to computer software.
Use ISO 9000-3 if you develop, supply, install, and maintain computer
software. ISO 9000-3:1997 is really an expanded version of the old
ISO 9001:1994 standard. ISO has simply copied the old text from
ISO 9001 and pasted it into the new version of ISO 9000-3, and
then added some new text that refers only to software.

PAGE ONE OF TWO
ISO 9000-3	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.


ISO 9000-3	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.


ISO 9000-3	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 will 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 will 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.


ISO 9000-3	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 will be evaluated. How system oriented 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. Your design input specification may also need to address the following kinds of 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.


ISO 9000-3	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.



ISO 9000-3 1997 Guidelines in Plain English
Guidelines for Applying ISO 9001 1994 to Computer Software
PAGE ONE OF TWO	GO TO PAGE TWO

ISO 9000-3 1997 is now OBSOLETE. It has been replaced by ISO IEC 90003 2004.
ISO 90003 is a quality management standard for computer software. It replaces the old ISO 9000-3 1997 standard. ISO 90003 2004 explains how ISO 9001 2000 can be applied to software and related services.


ISO 9000-3	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 and data are available for use. Documents and data, that are used to maintain your quality system, are available wherever and whenever they are needed. Documents that are retained for legal or historical purposes should be officially 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 the 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.


ISO 9000-3	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.

ISO 9000-3 1997 Guidelines in Plain English

ISO 9000-3

4.1 Management responsibility

ISO 9000-3

4.2 Quality system

ISO 9000-3

4.3 Contract review

ISO 9000-3

4.4 Software development and design

ISO 9000-3

4.5 Document and data control

ISO 9000-3

4.6 Purchasing requirements

ISO 9000-3

4.7 Customer-supplied products