ISO 90003

Tor Stålhane

IDI / NTNU

What is ISO 90003

ISO 9001 was developed for the production industry but has a rather general structure

ISO 90003 describes how to use ISO 9001 for software development

ISO 90003 is a set of guidelines – not a standard

ISO 90003

ISO 90003 contains the complete ISO 9001 but does not add extra items for all items in the standard

We will only look at ISO 90003’s comments for a few, selected parts of ISO 9001. The selection is partly random but is supposed to give an impression of what it is important to consider

Requirements for a QA system - 1

Requirements for planning in the QA system should include requirements for

• Development process – one for each type of project

• Documents such as requirements specification, architecture description, design description, code and user documentation

• Project plans, test plans and plans for training

Requirements for a QA system - 2

Requirements for planning in the QA system should include requirements for

• How methods will be adapted to the organization’s projects and development processes

• Tools and development environment• Special conventions, e.g. coding

standards and libraries• Reuse of software components

Responsibility for training - 1

The need for training should be assessed based on what the company uses for development, e.g.

• Methods and notations• Programming languages and tools

The company should also provide training pertaining to the domain where the company operates – e.g. banking or train control

Responsibility for training - 2

The company should continuously assess the need for new knowledge and techniques in the areas of

• Development • Operation• MaintenanceTraining does not need to be courses – it

may be arranged as seminars, workshops or self study activities

Development processes - 1

The processes we use must be adapted to the project at hand. When choosing development process we should take into consideration:

• Project size

• Complexity

• Safety and security requirements

• Project risk

Development processes - 2

Design and development may be an evolutionary process. We might therefore need to change one or more procedures during the project

The procedures shall focus on• What we shall develop• How we shall develop it• Who shall do what• Why shall we do this

QA processes

When we have a development process, the QA process can be adapted to the development. The QA process has two parts:

• A generic part – concerns all projects and can be reused. E.g. document templates

• A project specific part that needs to be adapted to each new project. E.g. test plans

QA plan - 1

The QA plan should contain• The project plan or a reference to this plan• Quality requirements for product and

process• Project specific procedures• Development process, chosen

programming language, libraries etc.• Criteria for start and acceptance for each

activity or step in the process

QA plan - 2

The QA plan should contain

• Methods used for verification – e.g. inspections – and testing

• Configuration management

• Who shall approve the results from each process step or activity

• Training needed

• What process info need to be generated

Product requirements - 1

According to ISO 90003 software may be developed for

• A single customer

• A general market

• As a component for a larger product

In all cases, it is important to put a considerable amount of work into developing a set of requirements

Product requirements - 2

In order to develop a set of requirements we need procedures and methods that can help us to

• Reach an agreement on requirements• Change requirements• Evaluate prototypes and demo versions• Document the results from meetings and

discussions involving one or more stakeholders

Product requirements - 3

The requirements should be developed in cooperation with the customers or users. In order to avoid misunderstandings we should develop a

• Project dictionary that explains the domain specific terms used in this project

• A rationale for each requirements – why do we need this

Product requirements - 4

The customer should approve the final set of requirements.

It is important to be able to trace all requirements, e.g. by using a trace matrix. This matrix should show

• How each requirement is realized – from high level design down to code or procedure

• Why each chunk of code is written – which requirement it helps to realize

Product requirements - 5

We need to control all changes to requirements. Changes to requirements may lead to changes in the contract

The requirements specification may include non-functional requirements, e.g. requirements to reliability, usability etc.

The requirements specification may contain requirements to interfaces to other software systems

Contract audit - 1

Important things to check:• Are we able to fulfill the requirements to

– The product– Development process, tools and hardware

• How large is the risk for cost overruns or delays

• How do we cooperate with third party companies

• Legal obligations, e.g. guarantees

Contract audit - 2

The contract should be updated when time of delivery, costs or available resources are changed

The contract should contain a section on the customer’s obligations to

• Provide information• Participate in discussions related to the

requirements• Make necessary decisions