Systems engineering is a disciplined, cross-functional approach to developing a medical device as an integrated system. Within medical device design and engineering, it translates user needs into requirements, architecture, interfaces and verified subsystems.
Systems engineering coordinates mechanical, electronic, software, firmware and human-factors activities so that every part of the device works together and satisfies applicable safety, performance, usability and regulatory requirements.
What is systems engineering?
Systems engineering is the practice of managing a medical device as a collection of interacting parts rather than as separate components developed independently.
The process begins with stakeholder needs and the device’s intended use. It then:
- Defines system requirements
- Establishes product architecture
- Divides functions among subsystems
- Defines subsystem interfaces
- Allocates requirements and risk controls
- Coordinates implementation
- Integrates the subsystems
- Verifies the completed system
- Validates the device against user needs
The principal general framework is ISO/IEC/IEEE 15288:2023, which describes lifecycle processes for engineered systems. In medical-device development, those processes operate alongside ISO 13485, ISO 14971, IEC 62304, IEC 60601 and IEC 62366-1.
Systems engineering begins during concept and feasibility and continues throughout development, verification, design transfer, production and post-market change management.
Why systems engineering matters in medical-device development
A modern medical device rarely belongs to only one engineering discipline.
An infusion pump may combine:
- Mechanical pumping components
- Fluid paths
- Motors and actuators
- Power electronics
- Sensors
- Embedded software
- Alarm systems
- A display and controls
- Disposable sets
- Network connectivity
A patient monitor may combine signal-acquisition electronics, electrodes, embedded algorithms, displays, alarms, power supplies, communications and accessories. A point-of-care analyzer may combine fluidics, optics, temperature control, consumable cartridges, firmware and result-interpretation software.
When these elements are developed in isolation, failures appear at their interfaces.
Examples include:
- Firmware expecting a sensor response time the hardware cannot achieve
- A power supply introducing noise into a measurement circuit
- A connector that can be attached to the wrong accessory
- Mechanical tolerances preventing reliable sensor alignment
- An alarm that users cannot interpret
- A software timeout conflicting with a mechanical sequence
- A disposable cartridge that does not consistently interface with the reader
- A subsystem that passes testing individually but fails after integration
Systems engineering makes these interfaces, assumptions and dependencies explicit before integration.
Systems engineering and product architecture
A central systems-engineering activity is defining the device’s product architecture.
Product architecture identifies:
- Major subsystems
- Functions assigned to each subsystem
- Physical and logical boundaries
- Data interfaces
- Electrical interfaces
- Mechanical interfaces
- Fluidic or optical interfaces
- Safety-critical elements
- Shared resources
- External systems and accessories
A clear architecture allows teams to develop subsystems in parallel while preserving compatibility. It also helps contain failures and isolate safety-critical functions from non-critical functions.
Architecture decisions should be documented because they affect:
- Safety classification
- Verification scope
- Manufacturing strategy
- Serviceability
- Cybersecurity
- Component selection
- Future design changes
- Product variants
Systems engineering and embedded devices
Systems engineering is particularly important for devices containing embedded systems, where hardware and software behavior are tightly connected.
An embedded medical system may involve:
- Microcontrollers
- Sensors
- Actuators
- Firmware
- Real-time operating systems
- Communication interfaces
- Safety monitors
- Power-management functions
- Diagnostic routines
A software requirement may depend on sensor accuracy, processor timing, memory limits, electrical behavior or mechanical response. Systems engineering ensures those cross-disciplinary assumptions are documented and tested at the appropriate level.
How the systems-engineering process works
Many medical-device teams use a V-model or a related iterative lifecycle. The left side of the V defines the device from stakeholder needs down to detailed subsystem requirements. The right side integrates and tests the resulting components from unit level back to the complete device.
Each definition activity should have a corresponding verification or validation activity.
1. Define stakeholder needs
Stakeholder needs describe the clinical, operational and business problems the device must address.
Stakeholders may include:
- Patients
- Clinicians
- Caregivers
- Service personnel
- Manufacturing teams
- Healthcare organizations
- Distributors
- Regulators
- Payers
Needs should describe the required outcome without prematurely prescribing a technical solution.
For example:
The clinician needs to recognize a dangerous patient condition quickly.
This need may later produce requirements for sensing accuracy, alarm timing, display presentation and data availability.
2. Establish intended use and use context
The team defines:
- Medical purpose
- Intended patient population
- Intended users
- Use environment
- Indications
- Contraindications
- Operating principle
- Expected service life
- Relevant clinical workflow
These elements affect device classification, risk management, usability, performance requirements and the regulatory pathway.
3. Develop system requirements
System requirements translate stakeholder needs, regulations, standards and risk controls into specific and testable statements.
Requirements may address:
- Function
- Performance
- Safety
- Reliability
- Usability
- Cybersecurity
- Environmental conditions
- Mechanical strength
- Electrical characteristics
- Software behavior
- Interfaces
- Manufacturing constraints
- Service and maintenance
- Packaging and labeling
A good requirement should be:
- Necessary
- Clear
- Unambiguous
- Feasible
- Measurable
- Verifiable
- Traceable
- Consistent with other requirements
Statements such as “the device shall be easy to use” are not verifiable. The underlying need should be translated into objective requirements and evaluated through usability engineering.
4. Define the system architecture
The device is divided into logical and physical subsystems. Each subsystem receives assigned functions, requirements and risk controls.
Architecture development should consider:
- Function allocation
- Safety segregation
- Software safety classification
- Electrical isolation
- Fault containment
- Power distribution
- Data flow
- User interaction
- Manufacturability
- Serviceability
- Component obsolescence
- Future expansion
Architectural choices should be reviewed before detailed design because changing subsystem boundaries later can invalidate significant downstream work.
5. Define interfaces
Interfaces describe how subsystems interact.
Interface types may include:
- Mechanical
- Electrical
- Software
- Data
- Communications
- Thermal
- Fluidic
- Optical
- User
- Manufacturing
- Service
An interface specification should identify:
- Inputs and outputs
- Units and ranges
- Timing
- Data formats
- Mechanical dimensions
- Connector definitions
- Failure behavior
- Ownership
- Verification method
Interface-control documents reduce the risk that teams make incompatible assumptions.
6. Allocate requirements and risk controls
Every requirement should be assigned to one or more responsible subsystems. Risk controls identified under ISO 14971 should also be allocated to the design elements that implement them.
Allocation prevents requirements from becoming orphaned and clarifies ownership.
Where a requirement spans several subsystems, the systems engineer should define:
- Which subsystem owns the requirement
- Contributions required from other subsystems
- Interface responsibilities
- Integration method
- System-level verification
7. Implement the subsystems
Mechanical, electronic and software teams implement their allocated requirements using the controls appropriate to each discipline.
Software and firmware development should follow IEC 62304 where applicable. Mechanical and electronic development should follow controlled specifications, reviews, risk-management requirements and applicable product standards.
Subsystem teams should not change an interface or shared assumption without assessing the effect on the rest of the system.
8. Integrate the system
Integration combines the individual elements in a planned sequence.
A complex device may be integrated through stages such as:
- Software units
- Software items
- Electronic boards
- Sensors and actuators
- Mechanical subassemblies
- Embedded subsystem
- Complete device
- Accessories and external systems
Integration planning should identify:
- Required test fixtures
- Test software
- Configuration
- Sequence
- Expected results
- Entry criteria
- Failure handling
- Responsible teams
Early integration reduces the risk of discovering major interface failures immediately before formal verification.
9. Verify requirements
Verification confirms that the design outputs meet approved design inputs.
The system-verification strategy may use:
- Inspection
- Analysis
- Demonstration
- Bench testing
- Software testing
- Electrical-safety testing
- EMC testing
- Environmental testing
- Reliability testing
- Dimensional inspection
Formal verification and validation should be planned while requirements are being written. A requirement that cannot be verified objectively should be corrected before the design is finalized.
10. Validate the finished device
Validation confirms that the finished device meets user needs and intended use under actual or simulated-use conditions.
Validation typically uses production-equivalent units and may include:
- Usability validation
- Simulated-use studies
- Clinical evaluation
- Performance validation
- Labeling validation
- Workflow assessment
- Device-specific clinical studies
Verification asks whether the device was built according to its requirements. Validation asks whether the resulting device is appropriate for its intended users and clinical purpose.
Standards connected to systems engineering
ISO/IEC/IEEE 15288
ISO/IEC/IEEE 15288:2023 describes lifecycle processes for engineered systems, including concept, development, production, utilization, support and retirement.
The standard is lifecycle-model independent and can support V-model, iterative and Agile approaches.
ISO 13485
ISO 13485:2016 Clause 7.3 establishes controlled design and development planning, inputs, outputs, reviews, verification, validation, transfer and changes.
The FDA Quality Management System Regulation incorporates ISO 13485:2016 by reference through 21 CFR 820.10.
ISO 14971
ISO 14971 governs medical-device risk management. Hazards and risk controls feed into requirements, architecture, interface definitions and verification.
IEC 60601
For medical electrical equipment, IEC 60601 establishes requirements for basic safety and essential performance.
These requirements can affect architecture, isolation, power supplies, alarms, software behavior, mechanical protection and system-level testing.
IEC 62366-1
Usability engineering under IEC 62366-1 connects user profiles, use environments, use-related risks, interface requirements and validation to the wider system-development process.
IEC 62304
IEC 62304 governs software lifecycle activities within the larger medical-device system. Software requirements and architecture should remain traceable to system requirements and risk controls.
Requirements traceability
Traceability connects the systems-engineering lifecycle:
Stakeholder need → System requirement → Risk control → Architecture element → Subsystem requirement → Design output → Verification → Validation
A Requirements Traceability Matrix helps demonstrate that every need, requirement and risk control has been implemented and tested.
Traceability should operate in both directions:
- Forward traceability confirms every requirement reaches implementation and test.
- Backward traceability confirms every design feature and test originates from an authorized requirement.
The traceability structure should also support change-impact analysis. When a requirement changes, teams should be able to identify affected architecture, interfaces, risk controls, test cases and documentation.
Managing system changes
A change in one subsystem may affect several others.
Examples include:
- Replacing a sensor may change firmware algorithms and verification limits.
- Modifying an enclosure may affect cooling, EMC and usability.
- Updating software timing may alter actuator behavior.
- Changing a power supply may affect electrical safety and signal quality.
- Revising a disposable may affect reader mechanics and detection algorithms.
Formal change control should evaluate:
- Reason for the change
- Affected requirements
- Affected risks
- Interface impact
- Architecture impact
- Verification and validation impact
- Regulatory impact
- Manufacturing impact
- Documentation updates
Systems engineering provides the cross-disciplinary perspective needed to prevent a local change from creating an unexpected system-level failure.
Common challenges and best practices
Weak requirements
Vague, subjective or conflicting requirements create disputes and incomplete testing later.
Write requirements that are measurable, uniquely identified and traceable to a source.
Incomplete interface definitions
Teams may document individual subsystems thoroughly while leaving the boundaries between them unclear. Integration then reveals incompatible assumptions.
Define interfaces early and manage them as controlled design records.
Siloed development teams
Mechanical, electronics and software teams can optimize their own designs while damaging overall system performance.
Use cross-functional architecture and interface reviews.
Poor traceability
When requirements, risks and tests exist in disconnected spreadsheets, teams struggle to assess changes and prepare for audits.
Maintain one controlled traceability structure throughout development.
Starting systems engineering too late
Beginning after detailed design leaves little opportunity to correct architectural and interface problems.
Start during concept and feasibility.
Confusing component success with system success
A subsystem can pass all its tests and still fail after integration.
Plan subsystem, integration and system-level verification separately.
Allowing architecture to become outdated
The documented architecture must reflect the real device. Update architectural records when subsystem boundaries, functions or interfaces change.
Systems-engineering best practices
Strong programs generally:
- Start with stakeholder needs and intended use.
- Define objective, testable system requirements.
- Establish architecture before detailed design.
- Document subsystem interfaces.
- Allocate every requirement and risk control.
- Plan verification while writing requirements.
- Integrate subsystems incrementally.
- Maintain forward and backward traceability.
- Review requirements and architecture cross-functionally.
- Control changes and assess system-wide effects.
- Keep risk management and usability within the engineering loop.
- Verify interfaces as well as individual components.
- Preserve configuration control over test units and software.
- Confirm that validation addresses real user needs and environments.
Design transfer and manufacturing
Systems engineering continues through design transfer. The approved architecture, interfaces and requirements must be translated into controlled production specifications.
Transfer activities may include:
- Released drawings
- Bills of Materials
- Software and firmware releases
- Assembly instructions
- Test specifications
- Inspection criteria
- Supplier requirements
- Manufacturing fixtures
- Configuration rules
- Service documentation
Connecting engineering with medical-device contract manufacturing helps ensure that system requirements remain intact as the design moves into repeatable production.
Manufacturing feedback may expose tolerance, assembly, test-access or supply-chain issues requiring controlled design changes and system-level impact assessment.
How SJML helps with systems engineering
SJML provides systems engineering as part of end-to-end electromechanical medical-device development.
Its teams work across:
- Mechanical engineering
- Electronics
- Embedded systems
- Firmware
- Software
- Systems engineering
- Risk management
- Usability engineering
- Verification
- Design transfer
Programs can move from concept and feasibility through architecture, detailed design, integration, verification and manufacturing transfer within one coordinated organization.
In-house laboratories support IEC 60601 electrical-safety, EMC, reliability, environmental and endurance testing. Phase-gate program management and structured change control keep requirements, interfaces, risks and verification evidence aligned as the design evolves.
Frequently asked questions
Systems engineering is the technical method for defining, architecting, integrating, and verifying a device as a whole. Design controls are the regulatory requirements that govern the design process, now enforced through ISO 13485:2016 Clause 7.3 under the FDA QMSR. Systems engineering produces the design outputs, while design controls make sure the process is planned, reviewed, and traceable.
ISO/IEC/IEEE 15288:2023 is the anchor standard, describing system life cycle processes from concept to retirement. It is independent of the life cycle model, so it applies to the V-model, iterative, and agile approaches. For medical devices, it works alongside ISO 13485, ISO 14971, IEC 62304, and IEC 60601-1, which add the device-specific quality, risk, software, and safety requirements.
No. Systems engineering applies to any device with interacting parts, including electromechanical products with little or no software. It is most valuable where hardware, electronics, software, and users all interact, such as patient monitors or point-of-care diagnostics. For software elements specifically, IEC 62304 governs the software life cycle within the wider systems approach.
It should start before detailed design, during concept and feasibility. Defining stakeholder needs, system requirements, and architecture early is when changes cost the least, and interfaces and risks are easiest to control. Starting late tends to push defects into integration and verification, where they are more expensive to fix and can delay a regulatory submission.