Why Design Input Requirements Decide Program Outcomes 

[and how to get them right] 

Design input requirements (DIRs) are rarely where leadership attention naturally goes. They sit deep within the development process, owned by engineering, reviewed by quality, and often treated as a technical exercise rather than a strategic one. 

But in combination product development, DIRs are not just documentation. They are where key program decisions become embedded. 

When DIRs are well constructed, teams move with clarity. Verification is straightforward. Regulatory conversations are grounded in objective evidence. Programs progress with fewer surprises. 

When they are not, the consequences tend to surface later, during verification, upon submission, or under regulatory scrutiny, when the cost of correction is highest. At that point, issues that appear technical are often symptoms of something more fundamental: unclear, incomplete, or misaligned design inputs. These low-quality DIRs can delay marketing authorization, create confusion during development, and — in the worst cases — lead to poor patient outcomes.  

For leadership teams, the question is whether they are being written in a way that protects the program from avoidable delays, rework, and regulatory risk. 

This article outlines the characteristics of high-quality DIRs, not as a writing guide, but as a lens for evaluating whether your program is set up to execute cleanly downstream. 

As you review your DIRs, ask yourself “Are they…?”

Necessary 

A DIR is necessary if it defines a capability, constraint, or condition that is required to meet user needs, satisfy a regulatory requirement, or reduce patient risk. If you can remove the DIR and the design still meets all stakeholder expectations, the DIR is probably unnecessary. 

Unnecessary DIRs are not harmless. They add complexity, increase development costs, and prolong design verification without providing any value to stakeholders. In the worst cases, unnecessary DIRs can introduce new features and functions that carry patient risks without providing any benefits to users. 

Correct 

A DIR is correct if it accurately reflects the user need, regulatory requirement, or other source from which it originates. Put simply, a DIR is correct if it says the right thing about how the product is intended to be used and how it should perform. Correct DIRs are technically accurate and do not distort or misinterpret user needs. 

Incorrect DIRs often stem from designer preferences, mistaken assumptions, outdated data, or misreadings of standards and regulations. Incorrect DIRs propagate errors into later stages of development, including design outputs and design verification. 

Unambiguous 

A DIR is unambiguous if it has only one reasonable interpretation. That is, all stakeholders, design engineers, test engineers, and regulators would read and understand the DIR same way. Unambiguous DIRs ensure consistent understanding across multidisciplinary teams. 

Ambiguity most often creeps into DIR through vague language (e.g., “many,” “quickly,” “as needed”), unnecessary qualifiers (e.g., “be designed to”), and open-ended phrases (e.g., “including but not limited to”). Ambiguous DIRs lead to inconsistent designs and disputes during verification. In safety-critical applications, ambiguous DIRs can result in unintended product behavior that puts patients at risk. 

Complete 

A DIR is complete if it contains all the information design engineers and test engineers needs without having to infer details or make assumptions. A DIR that is missing key information often lacks one or more of the following: 

• Who or what is performing the action (the subject). 

• What the action is (the behavior). 

• When or under what conditions the action occurs (e.g., a trigger or operating state). 

• How well the action must be performed, expressed in measurable terms with units. 

Incomplete DIRs force designers to fill in the gaps themselves, which increases the risk of unintended functionality or performance shortfalls. This is especially important for safety-critical functions, alarms, and clinical performance characteristics, as missing details can impact clinical efficacy, patient safety, and regulatory reviews. 

Verifiable 

A DIR is verifiable if the development team can produce objective evidence that the product satisfies  the DIR. That is, the development team can perform an inspection, analysis, demonstration, or test to confirm — without debate — that the DIR has been met. If reasonable people could disagree about whether the product passes or fails, the DIR is not verifiable. 

Like ambiguous DIRs, unverifiable DIRs often arise from vague terms (e.g., “sufficient,” “safely,” “robust”) and unnecessary qualifiers (e.g., “be capable of”). The hallmark of a verifiable DIR is a clear, objective acceptance criterion. If you cannot define a pass/fail threshold for verification, the DIR is not verfiable. 

ISO 13485 requires that design outputs be verified against design inputs; however, if a DIR is unverifiable, compliance cannot be objectively demonstrated. Verifiable DIRs enable clear test cases, reduce disputes during design verification, and support regulatory submissions and audits. 

Feasible 

A DIR is feasible if it can be implemented in the design within known technical, schedule, cost, and regulatory constraints. If satisfying the DIR would require physics to be violated, budgets to be ignored, schedules to be doubled, or nonexistent technology to be invented, it is not feasible. 

Infeasible DIRs often lead to unrealistic commitments to stakeholders, missed milestones, depleted budgets, document churn, and failures during design verification. Feasible DIRs ensure that the development team can deliver a compliant product within project constraints. 

Singular 

A DIR is singular if it expresses one – and only one – capability, constraint, function, or performance obligation. A singular DIR is one requirement, not a combination of several requirements bundled together. 

Non-singular DIRs often result from the use of multiple sentences or conjunctions (i.e., “and,” “or,” “but”) to form compound sentences. Non-singular DIRs are difficult to trace, verify, and manage. For example, if the product fails design verification, then: 

• Which part(s) of the DIR did the product fail to meet? 

• Will you reject the entire DIR? 

• How will you track partial compliance to the DIR? 

At best, these questions cause confusion and waste time. At worst, non-singular DIRs can make the Design and Development File difficult to comprehend and raise red flags with regulators. Singular DIRs improve traceability, simplify design verification, and simplify impact assessment for design changes. 

Consistent 

A DIR is consistent if it does not conflict with other DIRs for the same product. If two or more DIRs cannot be satisfied at the same time, they are inconsistent. Common sources of inconsistency include non-uniform definitions, misaligned numeric values, conflicting interface specifications between subsystems, and mismatches between system-level and subsystem-level DIRs. 

Inconsistent DIRs create design deadlocks and increase the likelihood of costly rework during design verification. They also force engineers to make informal trade-offs between DIRs and undocumented assumptions about DIRs, introducing undocumented risks into the program. 

Final Thoughts

Development teams will always be under pressure to move quickly. That pressure does not eliminate the need for high-quality DIRs. It increases the consequences of getting them wrong. 

For leadership, this is not about reviewing individual requirements. It is about ensuring the system that produces them is functioning properly and created as critical, rather than routine. 

A few practical considerations: 

• Are DIRs being challenged for necessity, clarity, and verifiability, or simply reviewed for completeness? 

• Is there clear ownership for requirement quality across functions such as engineering, quality, and regulatory, or is it fragmented? 

• Do verification challenges trace back to how requirements were written? If so, is that feedback loop being addressed? 

Remember: Taking the time to create high-quality DIRs do not slow programs down. It prevents the kind of downstream friction that consumes timelines, budgets, and regulatory credibility. If you want your teams to move faster with fewer surprises, this is one of the highest-leverage places to focus. 

AUTHOR

Andrew Ozga, Senior Consultant, Suttons Creek – Andrew has been a Systems Engineer in the pharmaceutical industry for over 5 years. Throughout his career, he has developed well-rounded experience with systems engineering (ISO 15288), design controls (ISO 13485, 21 CFR 820.30), and risk management (ISO 14971). Andrew has leveraged his experience to drive the design and development of numerous drug-device combination products, including auto-injectors, injector pens, and enhanced prefilled syringes. Andrew is passionate about developing products that satisfy the needs of all stakeholders, including the patient, healthcare providers, business, and regulators.