What you will learn
By the end of this topic, you should be able to distinguish user needs from design inputs, identify the sources that feed the input baseline, write clearer and more verifiable requirements, and explain how traceability connects intended purpose, risks, design, verification and validation.
The evidence chain
MTL-102 establishes what the device is for, who will use it and where. User needs express the outcomes those users and patients need. Design inputs then translate the needs—and other mandatory constraints—into requirements detailed enough to design against and verify.
Verification returns to design inputs: did we build the device correctly? Validation returns to user needs and intended use: did we build the right device?
User needs and design inputs are not interchangeable
User need
A solution-independent statement of an outcome, capability or experience required by a user, patient or other stakeholder. It explains why the product matters.
Design input
A documented requirement for the device or its development that is sufficiently precise to support design, review and verification. It explains what must be achieved.
For example, “The patient needs to know that the injection has completed” is a user need. It does not prescribe how the interface works. Design inputs could then specify the required completion-detection performance, the feedback modes, the time within which feedback is presented, the conditions under which it must be perceivable and the behaviour when completion cannot be confirmed.
One user need may generate several design inputs. One design input may also support several user needs, risks or regulatory requirements. The relationship is therefore many-to-many, not a simple one-line conversion exercise.
Where design inputs come from
User needs are important, but they are not the only source. A complete input baseline brings together:
Purpose and user research
Intended purpose, patient and user profiles, clinical workflows, contextual inquiry, interviews, observations, complaints and existing-device experience.
Regulations and standards
Applicable legislation, classification rules, general safety and performance requirements, consensus standards and market-specific obligations.
Risk and usability
Risk-control measures, use-related risk controls, critical tasks, foreseeable misuse, security controls and information for safety.
System and lifecycle constraints
Interfaces, interoperability, environmental conditions, materials, manufacturing, packaging, transport, service, configuration, cybersecurity and disposal.
A risk-control measure that is implemented by design should appear in the requirements baseline and be traced to verification. A standard should not merely be listed as “applicable”; its relevant provisions need to be translated into requirements, plans or justified evidence.
What makes a design input usable?
A good requirement is:
- Necessary: it has an identifiable source and supports the intended device.
- Clear: competent reviewers reach the same interpretation.
- Singular: it contains one principal obligation rather than several hidden requirements.
- Specific: the subject, required behaviour and relevant conditions are defined.
- Feasible: it can be achieved within known technical and lifecycle constraints.
- Verifiable: an objective method can demonstrate whether it has been met.
- Traceable: it connects to its source, risks, outputs, verification and changes.
- Consistent: it does not conflict with another approved input.
- Controlled: its identifier, status, version, rationale and approval are visible.
Not every requirement needs a numeric tolerance. Qualitative requirements can be legitimate when compliance can be assessed objectively—for example against an approved labelling checklist or interface rule. The test is whether pass and fail can be determined without relying on personal opinion.
Write requirements for the people who must use them
A useful pattern is: identified subject + “shall” + required behaviour or characteristic + conditions + measurable limit or acceptance criterion. Add rationale and source as attributes rather than packing them into the requirement sentence.
Weak: “The device should be easy to use.”
This does not identify the user, task, conditions or evidence. Retain the underlying usability outcome as a user need, then derive specific interface and usability requirements.
Weak: “The battery shall last a long time.”
“Long” is subjective. Define the operating profile, environmental conditions, age or cycle state and the minimum supported duration.
Weak: “The system shall be secure.”
Security is an objective, not a verifiable input. Derive requirements for identities, authorisation, data protection, logging, update integrity, recovery and other selected controls.
Better structure
“The device shall [perform a defined function] within [a defined limit] when [specified conditions apply].” The actual limit must be justified from clinical, user, risk, technical or regulatory evidence—not chosen merely because it is easy to test.
Organise requirements without losing the system view
Start with device or system-level inputs, then allocate them to hardware, software, mechanics, consumables, packaging, labelling, production processes and external services. Allocation is an architectural decision. It should not silently weaken the original need or create gaps at interfaces.
System requirements
Define what the complete device or system must achieve, including performance, safety, usability, security and external interfaces.
Subsystem requirements
Allocate system behaviour and constraints to the responsible components while retaining upward traceability.
Interface requirements
Control electrical, mechanical, software, data, user and organisational boundaries. Many failures arise between components rather than within them.
Process and lifecycle requirements
Capture characteristics that must be achieved through manufacturing, packaging, installation, servicing, updates or supplier controls.
Avoid using subsystem specifications as a substitute for an approved system baseline. Teams need a controlled view of the complete product before each discipline optimises its own part.
Traceability is a decision tool
A traceability matrix is valuable only when it helps the team detect missing, unjustified or unevidenced work. At minimum, the relationship model should connect:
- Intended-purpose elements and claims to user needs.
- User needs to the design inputs that realise them.
- Hazards and risk controls to applicable design inputs.
- Design inputs to architecture and design outputs.
- Design inputs to verification methods, protocols and results.
- User needs and intended use to validation evidence.
- Changes to every affected requirement, risk, output and item of evidence.
Coverage alone is not enough. A requirement can have a test reference and still be poor. Reviews should examine the strength and logic of each relationship, not just whether every matrix cell contains an identifier.
Worked example: confirming an injection
A connected injection aid has the user need: “The patient needs to know whether the prescribed injection has completed.” The team first clarifies what “completed” means for the compatible injector, what the accessory can observe, which failure modes could create false reassurance and which users or environments affect perception.
Derived inputs may address event-detection accuracy, permitted false-positive behaviour, timing and persistence of feedback, visual, audible or haptic presentation, accessibility, operation without network connectivity, storage of the event record and behaviour when the device cannot determine completion. Risk analysis may add an input preventing the system from presenting a positive confirmation when confidence is insufficient.
Hardware, embedded software and application requirements are then allocated from the system inputs. Verification demonstrates that each input is met under specified conditions. Validation asks representative patients to perform the complete task in representative environments and determines whether they can correctly understand the result and take appropriate action.
Input review checklist
- The intended purpose, users, population, environments and claims are controlled.
- User needs describe outcomes without unnecessarily prescribing solutions.
- Clinical, user, regulatory, risk, usability, security and lifecycle sources are represented.
- Each input is necessary, clear, feasible, singular and objectively verifiable.
- Conditions, limits and acceptance criteria are defined or have an owned plan for resolution.
- Conflicts, assumptions, placeholders and unresolved decisions are visible.
- System requirements are allocated without losing interface responsibilities.
- Risk controls implemented by design are included and traceable.
- Verification methods are feasible and planned before the design is completed.
- Validation plans return to the user needs and intended use.
- Changes are assessed for effects on risks, outputs, evidence and released products.
- Appropriate clinical, engineering, usability, risk, quality, regulatory and manufacturing stakeholders approve the baseline.
Common misconceptions
“The customer gave us the requirements.”
Customer statements are valuable source material, but the manufacturer remains responsible for resolving ambiguity, regulatory obligations, risks and conflicting stakeholder needs.
“Every user need needs one requirement.”
No. Needs and inputs normally form a many-to-many relationship across system functions, risks and interfaces.
“Design inputs must describe the solution.”
Inputs should constrain the solution only where the constraint is necessary. Premature implementation detail can suppress better designs and conceal the real need.
“We can finalise the requirements after prototyping.”
Prototypes can help discover requirements, but unrecorded learning creates an uncontrolled design. Mature inputs should emerge progressively under review and change control.
“Traceability proves compliance.”
Traceability demonstrates relationships and coverage. It does not prove that requirements, tests or conclusions are technically adequate.
Seven things to remember
- User needs describe required outcomes; design inputs define what the design must achieve.
- Inputs also come from regulations, standards, risk, usability, security and lifecycle constraints.
- Write requirements so pass and fail can be determined objectively.
- Keep rationale, source and traceability with each controlled requirement.
- Review conflicts and interfaces before allocating work to disciplines.
- Plan verification while inputs are being written.
- Validate the finished device against user needs and intended use—not merely against its specifications.