Product Requirements
Subsystem Requirements List
Break down system specifications into detailed implementable requirements for individual device components and subsystems.
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
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 constraintsWriting 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 subsystemRisk 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 featureContext 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 timesExample
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% |
Q&A
How detailed should subsystem requirements be?
How detailed should subsystem requirements be?
Subsystem requirements should provide enough technical detail for implementation teams to design and build the component. Include specific performance parameters, technical specifications, and measurable criteria. They should be more detailed than system requirements but not so prescriptive that they eliminate design flexibility unnecessarily.
How do I ensure all system requirements are covered by subsystem requirements?
How do I ensure all system requirements are covered by subsystem requirements?
Create a traceability matrix that maps each system requirement to one or more subsystem requirements. Review each system requirement and ask “Which subsystems need to do what to satisfy this requirement?” Ensure no system requirement is left without corresponding subsystem requirements.
What's the difference between regular subsystem requirements and risk control requirements?
What's the difference between regular subsystem requirements and risk control requirements?
Regular subsystem requirements derive from system requirements and define normal functionality. Risk control requirements derive from your risk assessment and specify features needed to mitigate identified risks. Both are essential, but risk control requirements specifically address safety concerns and must be clearly linked to identified risks.
How should I handle interface requirements between subsystems?
How should I handle interface requirements between subsystems?
Define interface requirements clearly in both subsystems that need to communicate. Specify data formats, communication protocols, timing requirements, and error handling. Consider creating dedicated interface control documents for complex interactions between subsystems.
Can subsystem requirements be updated during development?
Can subsystem requirements be updated during development?
Yes, but changes must be controlled through your change management process. Assess the impact of changes on other subsystems, system requirements, and verification activities. Update traceability documentation and consider whether changes affect your risk assessment or require additional risk controls.
How do I write subsystem requirements for software components?
How do I write subsystem requirements for software components?
For software subsystems, specify functional behavior, performance requirements, data handling, user interactions, and error conditions. Include technical specifications like processing speed, memory usage, and communication protocols. Ensure requirements are testable and consider both normal operation and edge cases.