# 系统需求规格书（SR）

- 项目：{{project_name}}
- 生成时间：{{generated_at}}
- 快照：{{snapshot_id}}
- 文件编号：RD-SR
- 记录归属：DHF
- 版本：A
- 阶段：03 设计输入
- 产品：{{device_type}}
- 预期用途：{{intended_use}}
- 目标市场：{{target_market}}

## 结论

（一句话：系统需求是否可验证、可追溯到用户需求与法规输入。信息不足标「待确认」。不适用则写「本文件不适用」及理由。）

## 适用性

- 适用 / 不适用：{{applicability}}
- 不适用理由：{{na_rationale}}

## 文件简介

（本需求规格书针对 {{device_type}} 的市场需求、功能需求与临床/使用流程编写，说明系统需实现的功能与约束。）

### 目的

（明确产品开发需求；作为系统设计、子系统设计、风险分析、临床、测试与验证的依据；信息不足标「待确认」。）

### 范围

（含产品介绍、法规、环境、网络安全、可维护性、性能、可靠性、安全性、易用性等系统需求。）

### 面向对象

（产品策划、系统设计、子系统需求设计、风险分析、临床、测试、验证人员。）

## 产品介绍

### 产品说明

（基于材料与字段，标〔材料：文件名〕。不做疗效宣称。）

### 产品的预期用途

{{intended_use}}

### 产品的结构及组成

（结构与组成、关键子系统、能量源、软件/网络安全、人体接触方式等。缺项「待确认」。）

## 需求输入

| 文档编号 | 文件名称 | 版本 |
| --- | --- | --- |
| RD-UN | 用户需求规格书 | 待确认 |
| RD-RISK-PLAN | 风险管理计划 | 待确认 |

（优先引用 `prior_docs/` 中已批准文档；无 URS 时列出 PIR/技术要求等材料并说明 UR 来源。）

## 详细需求

### 基本法规项

| 序号 | 法规项编号 | 软件开发/设计参考的法规文件 |
| --- | --- | --- |
| 1 | 待确认 | 待确认 |

（来自材料与 `known_standards`；指导原则标注「非强制标准」。）

### 需求标识

**需求分类及标识方法：RX－nnnn**

| 类别 | 代号 | 含义 |
| --- | --- | --- |
| R | R | 需求（requirement） |
| F | F | 功能需求 |
| P | P | 性能需求 |
| I | I | 接口需求 |
| E | E | 环境需求 |
| U | U | 易用性需求 |
| R | R | 可靠性需求 |
| M | M | 可维护性需求 |
| L | L | 网络安全需求 |
| S | S | 安全需求 |
| O | O | 其他需求 |
| nnnn | 0001… | 流水号 |

（系统需求 ID 使用 RS/RF/RP 等前缀 + 四位流水号；用户需求 ID 使用 UR-nnnn / UN-nnn。）

## 需求描述

（主表：每条 applies 的系统需求须为原子表述；标准条款须拆至参考文档粒度，禁止合并多条款为一行。）

| 用户需求ID | 系统需求ID | 系统需求描述 | 备注 |
| --- | --- | --- | --- |
| UR-001 | RS-0001 | 待确认 | 待确认 |

## 系统需求（摘要表）

| ID | 需求陈述 | 追溯 UN | 验证方式 |
| --- | --- | --- | --- |
| SR-001 | 待确认 | UN-001 | 待确认 |

## 术语和缩写

（列出正文用到的术语与缩写；无则写 NA。）

## 追溯

| 本文件 ID | 上游（输入/需求） | 下游（输出/验证/确认） |
| --- | --- | --- |
| RD-SR |  |  |

## 已有材料摘要

{{materials}}

## 待确认清单

- （列出本阶段仍缺、会影响后续设计/验证/确认的项）

## 签署

| 角色 | 姓名 | 结论 | 日期 |
| --- | --- | --- | --- |
| 编制 |  | 已编制 | {{generated_at}} |
| 审核 |  |  |  |
| 批准 |  |  |  |

## 历史记录

| 版本 | 日期 | 修订人 | 更改内容 |
| --- | --- | --- | --- |
| A | {{generated_at}} |  | 新建 |

## 说明

本文档由研发小队在任务快照上生成，属于设计历史记录。系统需求须追溯到需求输入中的 UR/UN 或材料。不编造未提出的功能。不做疗效宣称。冲突需求并列，不自行取舍。后续补充的材料不会改变本次内容。