System Requirements List
Summary
The System Requirements List translates user needs into specific, testable technical requirements that define what your medical device must do to meet user expectations. This document serves as the foundation for all subsequent design and development activities, ensuring traceability from user needs through to final verification.
Why is System Requirements List important?
System requirements bridge the gap between user needs and technical implementation. They transform high-level user expectations into objective, measurable criteria that your development team can design against. This document ensures that every aspect of your device’s functionality is deliberately planned and traceable back to actual user needs, which is essential for regulatory compliance and successful product development.
The FDA and EU MDR require clear documentation showing how user needs translate into design requirements. Without well-defined system requirements, you cannot demonstrate that your device will actually meet user needs or prove that your verification activities are comprehensive.
Regulatory Context
Under 21 CFR Part 820.30 (Design Controls):
- System requirements must be documented and derived from user needs
- Requirements must be objective and testable to enable verification
- Must demonstrate traceability from user needs to system requirements
- Requirements must be reviewed and approved before implementation
Special attention required for:
- Software medical devices (FDA Guidance on Software as Medical Device)
- Design input requirements must be without ambiguity
- Requirements must enable objective verification of design outputs
- Change control procedures must govern requirement modifications
Under 21 CFR Part 820.30 (Design Controls):
- System requirements must be documented and derived from user needs
- Requirements must be objective and testable to enable verification
- Must demonstrate traceability from user needs to system requirements
- Requirements must be reviewed and approved before implementation
Special attention required for:
- Software medical devices (FDA Guidance on Software as Medical Device)
- Design input requirements must be without ambiguity
- Requirements must enable objective verification of design outputs
- Change control procedures must govern requirement modifications
Under EU MDR 2017/745:
- Must comply with EN ISO 13485:2016 Section 7.3.3 (Design and development inputs)
- Requirements must be functional, performance, and safety-related
- Must be complete, unambiguous, and verifiable
- Traceability required throughout the design process (Article 10(9))
Special attention required for:
- General Safety and Performance Requirements (GSPR) compliance
- Risk management integration per ISO 14971
- Software lifecycle processes per IEC 62304
- Clinical evaluation requirements must be considered in system design
Guide
Understanding System Requirements
System requirements define what your device must do rather than how it will do it. They should be more granular than user needs but not overly technical. Each requirement must be:
- Objective: Based on measurable criteria, not subjective opinions
- Testable: You must be able to verify whether the requirement is met
- Traceable: Clearly linked to one or more user needs
- Unambiguous: Written clearly with no room for interpretation
Structuring Your Requirements
Your system requirements table should include:
User Need ID: Reference to the specific user need this requirement addresses. This creates the essential traceability link required by regulations.
System ID: Unique identifier for each system requirement (e.g., SYS-001, SYS-002). Use a consistent numbering scheme that allows for future additions.
Description: Clear, concise statement of what the system must do. Use active voice and specific language. Avoid vague terms like “user-friendly” or “reliable.”
Relevant Subsystem: Identify which part of your device will implement this requirement. This helps organize your development work and ensures nothing falls through the cracks.
Writing Effective Requirements
Good system requirement examples:
- “The device shall display measurement results within 5 seconds of completing analysis”
- “The system shall store a minimum of 1000 patient records”
- “The device shall operate continuously for 8 hours on battery power”
Poor system requirement examples:
- “The device should be fast” (not measurable)
- “The system must be user-friendly” (subjective)
- “The device will work well” (not testable)
Requirements Categories
Consider organizing your requirements into categories:
Functional Requirements: What the device does (core functions, user interactions, data processing)
Performance Requirements: How well it performs (speed, accuracy, capacity, throughput)
Interface Requirements: How it connects with other systems (communication protocols, data formats)
Environmental Requirements: Operating conditions (temperature, humidity, electromagnetic compatibility)
Safety Requirements: Risk mitigation and safety features derived from your risk assessment
Traceability and Context
The configuration specifies that system requirements should consider context from user needs, shelf-life, and expected lifetime. This means your requirements should account for:
- User needs: Every requirement must trace to at least one user need
- Shelf-life considerations: Requirements for storage, packaging, and degradation
- Expected lifetime: Durability, maintenance, and long-term performance requirements
Example
Scenario: You’re developing a portable blood glucose monitor. Your user needs include “Users must quickly obtain accurate blood glucose readings” and “Users must easily understand their results.” You need to translate these into specific system requirements that your engineering team can design against.
System Requirements List
| User Need ID | System ID | Description | Relevant Subsystem |
|---|---|---|---|
| UN-001 | SYS-001 | The device shall complete blood glucose analysis within 10 seconds of sample application | Measurement Engine |
| UN-001 | SYS-002 | The device shall provide glucose readings accurate to ±15% of reference method | Measurement Engine |
| UN-001 | SYS-003 | The device shall require a blood sample volume of no more than 1.0 μL | Sample Interface |
| UN-002 | SYS-004 | The device shall display glucose values in units of mg/dL or mmol/L as selected by user | User Interface |
| UN-002 | SYS-005 | The device shall provide visual indication when glucose reading is outside normal range (70-180 mg/dL) | User Interface |
| UN-003 | SYS-006 | The device shall store minimum 500 glucose readings with date and time stamps | Data Management |
| UN-004 | SYS-007 | The device shall operate for minimum 1000 tests on single battery charge | Power Management |
| UN-005 | SYS-008 | The device shall function in temperature range of 5°C to 45°C | Environmental Control |