Product Requirements
System Requirements List
Translate user needs into objective testable requirements defining device functionality and performance criteria.
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
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”
- “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 assessmentTraceability 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 |
Q&A
How should system requirements be structured?
How should system requirements be structured?
System requirements should be more granular than user needs but not overly technical. They should be objective and testable, allowing for flexibility and traceability as the product evolves. Each requirement must clearly state what the system must do using measurable criteria.
What's the difference between user needs and system requirements?
What's the difference between user needs and system requirements?
User needs describe what users expect from the device from their perspective, while system requirements specify what the device must do to meet those needs. User needs are solution-neutral and focus on outcomes (e.g., “Users must quickly understand device status”). System requirements are more technical and specific (e.g., “Device must display status using LED indicators visible from 2 meters”). Each system requirement should trace back to one or more user needs.
How detailed should system requirements be?
How detailed should system requirements be?
System requirements should be detailed enough to be testable and unambiguous, but not so detailed that they constrain design solutions unnecessarily. They should specify what the system must do and how well it must perform, but generally avoid specifying how it will be implemented. Save implementation details for subsystem requirements and design specifications.
How do I ensure my system requirements are complete?
How do I ensure my system requirements are complete?
Ensure completeness by systematically reviewing each user need and asking “What must the system do to satisfy this need?” Consider all aspects: functional performance, safety, environmental conditions, interfaces, and lifecycle requirements. Use your risk assessment to identify additional safety-related requirements that may not be obvious from user needs alone.
Can system requirements be updated during development?
Can system requirements be updated during development?
Yes, system requirements can be updated, but changes must be controlled through your change management process. Document the rationale for changes and assess their impact on design, verification activities, and risk management. Update traceability matrices to maintain links between user needs, requirements, and verification activities.
How should availability requirements be phrased?
How should availability requirements be phrased?
Availability requirements should be kept general, such as “maintain high availability,” without specifying exact uptime percentages. This allows for flexibility while ensuring the system remains reliable. Focus on user-relevant outcomes rather than specific technical metrics that may become outdated or unnecessarily constrain implementation approaches.