Subsystem Requirements List
Summary
The Subsystem Requirements List breaks down system requirements into detailed, implementable specifications for each subsystem of your medical device. This document provides the technical granularity needed for design teams to build specific components while maintaining traceability to system-level requirements and user needs.
Why is Subsystem Requirements List important?
Subsystem requirements translate system-level specifications into actionable design inputs for individual components or subsystems. They provide the detailed technical specifications that engineers need to design, develop, and verify each part of your device. This granular level ensures that every system requirement is fully addressed and that no functionality falls through the cracks during development.
Regulatory authorities require clear traceability from user needs through system requirements down to subsystem implementation. The subsystem requirements also serve as the foundation for your verification and validation activities, ensuring that each component meets its intended function before system integration.
Regulatory Context
Under 21 CFR Part 820.30 (Design Controls):
- Subsystem requirements must be traceable to system requirements
- Must be complete, unambiguous, and verifiable
- Design inputs must be documented and reviewed
- Risk control measures must be incorporated as requirements
Special attention required for:
- Software subsystems must follow FDA Software as Medical Device guidance
- Risk control requirements must be clearly specified and verifiable
- Interface requirements between subsystems must be well-defined
- Change control must govern all requirement modifications
Under 21 CFR Part 820.30 (Design Controls):
- Subsystem requirements must be traceable to system requirements
- Must be complete, unambiguous, and verifiable
- Design inputs must be documented and reviewed
- Risk control measures must be incorporated as requirements
Special attention required for:
- Software subsystems must follow FDA Software as Medical Device guidance
- Risk control requirements must be clearly specified and verifiable
- Interface requirements between subsystems must be well-defined
- Change control must govern all requirement modifications
Under EU MDR 2017/745:
- Must comply with EN ISO 13485:2016 Section 7.3.3 (Design and development inputs)
- Requirements must address safety, performance, and functionality
- Risk management integration per ISO 14971 is mandatory
- Traceability throughout design process required (Article 10(9))
Special attention required for:
- General Safety and Performance Requirements (GSPR) implementation
- Software lifecycle processes per IEC 62304 for software subsystems
- Risk control measures must be integrated into subsystem design
- Post-market surveillance considerations must influence requirements
Guide
Understanding Subsystem Requirements
Subsystem requirements define the specific functions and characteristics that each component of your device must have. They are more detailed than system requirements and provide the technical specifications needed for implementation. Think of them as user stories for engineers - they describe what each subsystem must do to contribute to the overall system function.
Structuring Your Subsystem Requirements
Your subsystem requirements table should include:
Subsystem: The specific component or functional area (e.g., User Interface, Data Processing, Communication Module, Power Management)
System ID: Reference to the system requirement this subsystem requirement addresses, maintaining essential traceability
Subsystem ID: Unique identifier for each subsystem requirement (e.g., UI-001, DATA-001, COMM-001)
Description: Detailed specification of what the subsystem must do, including technical parameters, performance criteria, and constraints
Writing Effective Subsystem Requirements
Subsystem requirements should be specific and implementable. Include technical specifications, performance parameters, and measurable criteria. Consider:
Functional specifications: What the subsystem does Performance parameters: Speed, accuracy, capacity, throughput Interface definitions: How it connects with other subsystems Environmental constraints: Operating conditions and limitations Safety features: Risk mitigation measures built into the subsystem
Risk Control Requirements Integration
The second table addresses risk control subsystem requirements - these are specific features or functions that must be implemented to mitigate identified risks. These requirements should:
Risk ID: Reference the specific risk from your risk assessment Risk Control Requirement ID: Unique identifier for the control measure Subsystem: Which component will implement the risk control Description: Detailed specification of the risk control feature
Context Considerations
The configuration specifies that subsystem requirements should consider context from system requirements, shelf-life, and expected lifetime. This means accounting for:
- System requirements: Every subsystem requirement must trace to a system requirement
- Shelf-life factors: Storage conditions, material degradation, packaging requirements
- Expected lifetime: Durability, maintenance intervals, component replacement needs
Technical Specifications
When writing subsystem requirements, include specific technical details:
For software subsystems: Processing speed, memory requirements, data formats, communication protocols For hardware subsystems: Physical dimensions, material specifications, electrical characteristics, environmental tolerances For user interface subsystems: Display specifications, input methods, accessibility features, response times
Example
Scenario: You’re developing a portable blood glucose monitor with multiple subsystems. Your system requirements specify that the device must complete analysis within 10 seconds and display results clearly. You need to break these down into specific subsystem requirements that your development teams can implement.
Subsystem Requirements List
| Subsystem | System ID | Subsystem ID | Description |
|---|---|---|---|
| Measurement Engine | SYS-001 | MEAS-001 | The measurement subsystem shall complete glucose analysis within 8 seconds of sample detection |
| Measurement Engine | SYS-002 | MEAS-002 | The measurement subsystem shall provide glucose readings with coefficient of variation ≤5% |
| Sample Interface | SYS-003 | SAMP-001 | The sample interface shall detect blood sample volume ≥0.5 μL within 2 seconds |
| User Interface | SYS-004 | UI-001 | The display subsystem shall show glucose values in 14-point font minimum |
| User Interface | SYS-005 | UI-002 | The display subsystem shall use red backlight for readings >180 mg/dL |
| Data Management | SYS-006 | DATA-001 | The storage subsystem shall save readings with timestamp accurate to ±1 second |
| Power Management | SYS-007 | PWR-001 | The power subsystem shall provide 3.3V ±5% to measurement circuits |
Risk Control Subsystem Requirements
| Risk ID | Risk Control Requirement ID | Subsystem | Description |
|---|---|---|---|
| RISK-003 | RC-001 | User Interface | The display subsystem shall show “ERROR” message when sample volume is insufficient |
| RISK-005 | RC-002 | Measurement Engine | The measurement subsystem shall perform automatic calibration check before each reading |
| RISK-007 | RC-003 | Data Management | The storage subsystem shall encrypt all patient data using AES-256 encryption |
| RISK-009 | RC-004 | Power Management | The power subsystem shall display low battery warning when charge drops below 20% |