INSIGHT
REPORT |
mdi Consultants’
|
|
|
|
Insight Report No. 4 Vol. 10 DESIGN REQUIREMENTS AND DESIGN SPECIFICATIONSDesign requirements (Inputs) and design specifications (outputs) are two components of a well-planned medical product design process; however there are many Engineers who do not understand what they are and the differences between them. Design requirements define the product from the customer's viewpoint. Please note these concepts apply both to software design and to hardware design and that they describe the features of the product and list regulatory and safety requirements. Design requirements are what the product is to be or what it is to do: Generally it describes the interface between the user and the medical system or device. Design specifications describe how the product will achieve the requirements and are developed by the Engineering department. These design specifications define the mechanical, hardware and software architecture of the product and precedes any detailed design work. The Engineers will work from these design specifications to create the detailed designs that will meet the specification. Design requirements typically originate as a broad concept. After consultation by middle management, the requirements become more detailed and are usually documented in a controlled "Product Design Requirements " document. We will use an oversimplified example to illustrate the concepts. Larry Manager has an inspiration: "lets build a small box having a
blinking light. We will sell a million of them!" The design
requirements (the what) are: The above example shows how we go from the what that is wanted to the how to satisfy those wants. While many may think that this process is unnecessary, it is by no means superfluous. For a large and complex medical system, it helps to prevent design misunderstandings and provides an important part of the traceability chain from concept to design release. It also permits the originators of the concept to review just how the concept will be implemented before expending resources in the design process. Traceability is usually accomplished by linking the two documents by means of identical paragraph numbers (A.1 to A.5) for the requirement and the specification or by providing a "traceability matrix", which is a list of requirement paragraph numbers and corresponding specification paragraph numbers. When changes in the product are desired, the traceability from design requirements to design specification to detail design allows intelligent assessment of the consequences of the proposed change: Conceivably, a problem in detailed design may result in a proposed design spec change. With traceability, the driving requirement can be located and the consequence of the design change to the requirement can be addressed. A change in requirements can be easily traced to the affected design module. In addition, traceability prevents requirements not being met as well as preventing the initiation of design work that is not required. Without traceability, many documents would have to be reviewed to determine consequences. Most importantly, maintaining documentation on the design requirements (inputs) and design specifications (outputs) it is a requirement of the ISO 9000 standard for design control and to assure compliance to the FDA QSR regulations. Documenting changes in the design phases and sign-off is another regulatory requirement needing careful attention and control. Next Insight Report - to be announced. If you
have any comments on these INSIGHTS we hope that you let us hear them. If you have any of
your own INSIGHTS that you feel would be of value to other companies, we would be pleased
to hear from you and to discuss them with you and if you allow, we would even put them up
on this site for others to learn from. |
| Copyright 1998 mdi Consultants, Inc. |