ISO 9001 Design Inputs (Design Requirements)
Before you actually begin to design and develop your product or service, the designers and developers need to know what to design and develop. The ISO 9001 design inputs clause requires formal design and development inputs to be established and documented prior to starting development activities.
In some circles these inputs are referred to as “requirements” and are usually documented in some type of requirements document or requirements specification. Taking the time and putting in the effort to generate a set of well-defined design input requirements is by far the single most important activity you can do to facilitate a robust product that satisfies customer needs and ensuring projects are completed on time and within budget.
ROI for Design Inputs
Evidence has shown a strong correlation between establishing a strong set of design inputs and completing a successful development project on time, on budget, and delivering a robust product that meets the customer’s needs. Along the same line, failure to establish solid requirements often results in project delays, redesign efforts, and poor product reception by customers. Unfortunately, many development teams fail to spend an appropriate amount of time on the front end defining requirements before jumping into the actual design and development work. Management often doesn’t help the situation as they push the team to produce tangible outputs such as drawings, specifications, and prototypes which appear to demonstrate progress.
Consider though, the cost to discover a design issue during the initial development stages versus late in the project. During design input activities everything is on paper and can be changed immediately and with little cost using a pen or computer. Find that problem near product launch and you will need to rework the same requirements document, but now you may need to redesign, prototype, review, test, verify, validate, and pilot the product to address the issue. Finding it early cost you a few minutes of time and minimal administrative cost to fix. Find it late, and it might cost you tens or hundreds of thousands of dollars to redesign, retool, and re-validate. This doesn’t even consider the cost of project delays, launch delays, customer dissatisfaction, material and scrap costs, and lost revenue. Taking some extra time early in the project and investing in a robust set of design inputs can reap significant rewards and lead to well managed projects, on-time product launches, and robust products delivered to customers.
The following excerpt from a Design Control guidance document published by the FDA (Food and Drug Administration) further reinforces the need to establish a well-defined set of design input requirements:
Design input is the starting point for product design. The requirements which form the design input establish a basis for performing subsequent design tasks and validating the design. Therefore, development of a solid foundation of requirements is the single most important design control activity.
Many medical device manufacturers have experience with the adverse effects that incomplete requirements can have on the design process. A frequent complaint of developers is that “there’s never time to do it right, but there’s always time to do it over.” If essential requirements are not identified until validation, expensive redesign and rework may be necessary before a design can be released to production.
By comparison, the experience of companies that have designed devices using clear-cut, comprehensive sets of requirements is that rework and redesign are significantly reduced and product quality is improved. They know that the development of requirements for a medical device of even moderate complexity is a formidable, time-consuming task. They accept the investment in time and resources required to develop the requirements because they know the advantages to be gained in the long run
Types of ISO 9001 Design Inputs
ISO 9001 design inputs emulate the general standard practices for defining design requirements. A Google search for terms such as “design requirements” or “product requirements” and you will find literally hundreds of pages dedicated to the subject. As with many of the ISO 9001 requirements, the key is to establish a process for defining requirements that is appropriate for your products and organization. A set of requirements for designing a camping tent will be considerably less complex than those associated with a riding lawn mower or a medical device. Let’s take a closer look at the specific requirements for design inputs:
- Essential Requirements: You don’t need to define every little input or requirement. Just make sure you consider and capture the significant ones that will make a difference or impact your design outputs and product. Utilize some type of risk assessment or prioritization method to differentiate between the must have and nice to have requirements.
- Functional / Performance Requirements: Define the inputs which describe how the product is to function when used by the customer. Consider things such as speed, strength, size, weight, mobility, user interface, use (startup, shut down, operation), product outputs, product functionality, safety, interface with other products or accessories, power consumption, operating temperatures, color/finish, etc. to name a few. Don’t forget to define requirements for product manufacturing, service delivery, materials, key external providers, product verification and test during production, equipment, facilities, environment, etc. This can be a separate initiative and requirements document or combined into one. Just make sure that product requirements consider manufacturing needs and vice versa.
- Information From Previous Designs: Information and lessons learned from previous design projects and products can provide significant input to the design requirements. Don’t repeat the same mistakes twice and leverage what is already known from previous efforts.
- Statutory / Regulatory Requirements: This one often gets overlooked. Be sure to capture any legal or regulatory requirements that might need to be considered during design and development. This might be regulations for medical devices, automotive, telecommunications, aerospace, waste materials, safety, etc.
- Standards or Codes: Are there specific performance, functionality, or operational standards to be specified and met? What about testing or validation standards?
- Failure Consequences: These are generally risks to consider if the product fails during handling or use. Utilize tools and methods such as product risk analysis, design FMEA (Failure Modes and Effects Analysis) or FTA (Fault Tree Analysis) to identify potential failures and incorporate these into your design inputs to ensure the design outputs address and mitigate the risks.
Other requirements to consider but not required by ISO 9001 are business, customer, user, interface, system, product, and technical. Our eCoach ISO 9001 Learning System provides additional guidance and information on the different ISO 9001 design inputs and requirements.
ISO 9001 design inputs also require the following attributes for design inputs / requirements:
- Adequate Inputs: Design requirements must be appropriate for the nature, complexity, and risk associated with the product. The information provided must be sufficient such that designers clearly understand the boundaries, limitations, and expectations for the product.
- Complete Inputs: Ensure that requirements specifications cover and address all essential aspects of the product to be designed and developed.
- Unambiguous Inputs: Verify that requirements are concise, well defined, and measurable. Requirements form the basis for verification and validation therefore they need to be verifiable through test, measurement, or observation. Rather than stating that the product should be lightweight, the requirement should indicate that the product weight must be less than twelve pounds.
- Non-conflicting Inputs: Ensure that different requirements do not conflict with each other. When conflicts do arise, they must be clearly resolved.
- Documented Inputs: ISO 9001 mandates that design inputs must be documented and there are numerous methods to do this. We’ll discuss documentation needs later in this article.
Other good requirements practices not specifically stated by ISO 9001, but generally adopted by most requirements management processes include:
- Avoid Design Solutions: As you develop and review your requirements specifications, be careful not to focus on and state your requirements as design solutions.
- Single Requirements: Ensure that each requirement is well defined and that it only defines one requirement. It is easy to combine two separate but similar or interconnected requirements into one requirement or line item in the requirements specification document.
- Verifiable Requirements: Each requirement must be verifiable through test, measurement, observation, etc.
Requirements Management Tools: There are numerous methods and tools for developing, managing, and documenting design inputs / requirements. If you develop simple products, keep the process simple. You might only have 10, 20, or 30 key requirements which can be managed in a simple spreadsheet or other document. If you develop more complex products or execute a large number of projects, you might want to invest in an off-the-shelf requirements management software application. These come as local install software packages or online/cloud apps. Do your due diligence to find the right solution for your organization.
Requirements Review: We will discuss design reviews in a later article, however, note that while not required by ISO 9001, one good opportunity to complete a design review would be a cross-functional review of the initial design input requirements prior to initiating full design and development activities. The review should be completed by all applicable functions within the organization such as Engineering, Marketing, Manufacturing, Quality, Supply Chain/Purchasing, etc.
Requirements Control and Changes: Prior to the start of formal design and development activity, a baseline requirements specification should be established, approved, and placed under revision control. This will be the initial requirements document within your design & development project file and the basis for future reviews and revisions. The requirements document should be a living document which is reviewed and updated as the project evolves and new information is obtained. Note that not all requirements may be fully defined at the initial baseline as more information may be needed to flush out some of the requirements, and that is acceptable.
As the requirements evolve during the project and design changes are made, be sure to review and update requirement documents periodically and control each revision. A good practice would be to update the requirements document and submit a new revision at the end of each project phase or milestone. At the conclusion of the project, several revisions of the requirements document should exist within the project file providing a historical evolution of the requirements over time.
Product changes after launch must consider the impact to established requirements and as needed, review and update the requirements during the change process. Any changes to the requirements will necessitate re-verification and/or re-validation efforts to demonstrate that the new or revised requirements have been satisfied. This should be part of your established Change Management process (also see ISO 9001 Processes and Procedures (Support) – Document Control and Change Management).
Traceability: Design inputs form the basis and criteria for completing design verification and validation activities, therefore, it is important that some type of mechanism provides evidence that all design inputs have been verified and/or validated. The most common tool for this is the Traceability Matrix which links each requirement or design input to the test methods and results demonstrating successful verification and validation activities. There are numerous methods and tools for controlling traceability. Do your research and implement a solution that works for your organization. Note that the requirements management software discussed earlier in this article will most like have the ability to manage requirements traceability. The EBS ISO 9001 eCoach course also provides a simple spreadsheet example document as a traceability matrix.
Not all of the requirement categories may apply to your organization or development project. For most projects, Customer/User, Functional/Performance, and Product requirements should be considered. Further refinement into Technical requirements may be needed for complex and highly technical product development activities. If you are new to this process and/or your products are simple, basic, and low risk, then don’t get too hung up on getting your design inputs perfect.
However, you should dedicate a reasonable amount of time and effort to clearly defining those requirements which are essential to the product and will allow you to effectively test and validate the product. If you feel lost or are struggling with this activity, then reach out for help and find an expert to help you establish a process that is right for your organization and help guide through the learning curve.