Your company must plan:
- the stages of development – a Gannt chart / other flow diagram
- any review or testing process on the plan
- the responsibilities for design and development and how team members interact
– just like the full process interaction map for the quality system we talked of earlier
- customer involvement when required
- documented information to demonstrate requirements have been met (test plans, acceptance criteria etc)
Inputs should be considered and preferably recorded and may include:
- functional / technical specs
- any regulatory requirements
- previous designs
- customer supplied information / products eg drawings, materials, data
- standards you have committed to follow (project management, coding etc)
Defined at the outset so you can check against them at the end – like a checklist: (records of these outputs must be maintained)
- provide information for other activities – perhaps another quote, or support documentation
- contain product acceptance criteria
- specify characteristics for safe a proper use
- training courses for use
- a user manual
Review is carried out as per the plan in order to determine that the design will meet the requirements and to identify any perceived problems and propose actions for their rectification. Records must be maintained.
This should occur in order to ensure design / developments have met the input requirements. Records must be maintained
Should be in line with acceptance as guided by Planning / outputs above and if possible (but not always)
should be completed prior to delivery / implementation. Records should be maintained.
Control of changes
Records should be maintained of changes. These shall be reviewed and communicated to everyone concerned.
It may also include any likely influence the change may have of previous designs
There is no real change here, this is the old 4.4 Design from 1994.
The only change is that the procedure itself does not need to be documented, but everything else still does.