> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withdovetail.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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

<Tabs>
  <Tab title="FDA">
    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

    <Warning>
      **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
    </Warning>
  </Tab>

  <Tab title="MDR">
    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))

    <Warning>
      **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
    </Warning>
  </Tab>
</Tabs>

## 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%       |

## Q\&A

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>