Replace generic placeholders for 14 rd_* docs, add writing-norm doc and allowlist lint so structure and per-section instructions stay enforceable. Co-authored-by: Cursor <cursoragent@cursor.com>
3.9 KiB
3.9 KiB
系统需求规格书(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 或材料。不编造未提出的功能。不做疗效宣称。冲突需求并列,不自行取舍。后续补充的材料不会改变本次内容。