第4章软件需求分析

4、软件需求分析：需求获取方法、功能需求与安全需求、需求可追溯性矩阵、需求评审流程

好，咱们进入第四章。软件需求分析。

说实话，很多团队觉得这步就是走个过场。写个文档，签个字，完事。但我得告诉你，在IEC62304认证里，需求分析是整个软件安全性的地基。地基没打好，后面盖多高的楼都白搭。我见过太多项目，到了集成测试阶段才发现需求漏了，那叫一个痛苦。

需求从哪来？不是你想出来的，是挖出来的。

我个人习惯把需求获取分成三个渠道：

标准法规：比如IEC62304本身、ISO14971风险管理标准、还有产品对应的专用标准（比如血压计有血压计的标准）。这些是硬性要求，没得商量。
用户与临床：医生怎么用？护士怎么操作？病人会误触吗？我做过一个输液泵项目，工程师觉得界面很友好，结果临床一测，护士说“按钮太小，戴手套按不准”。你看，这就是没去现场。
系统需求分解：软件是嵌入在系统里的。系统说“设备要在5秒内启动”，那软件就得分解出“初始化序列不超过4.5秒”。

我的小技巧： 做需求获取时，一定要拉上临床工程师和风险管理负责人。三个人坐在一起聊，比各自写文档高效十倍。我曾经试过只靠邮件沟通，结果需求文档改了八版，最后还是漏了关键功能。

很多新手容易混淆这两个概念。我简单说说。

功能需求，说白了就是“软件要做什么”。比如：

安全需求，则是“软件不能做什么”或者“出问题时怎么办”。比如：

嗯，这里要注意。安全需求往往是从风险分析里推导出来的。你想想看，如果风险分析说“电池电量低可能导致治疗中断”，那安全需求就得写“当电量低于10%时，系统应发出声光报警，并自动保存当前治疗参数”。

    核心原则： 每一个安全需求，都必须能追溯到至少一个风险控制措施。反过来，每一个不可接受的风险，都必须有对应的安全需求来覆盖。这是IEC62304的硬性要求，也是审核员最爱查的地方。

需求可追溯性矩阵，简称RTM。听起来高大上，其实就是一个表格。但它能救你的命。

为什么这么说？因为审核员会随机抽一个需求，问你：“这个需求对应的设计是哪个？测试用例是哪个？风险分析里怎么说的？”你要是答不上来，直接开不符合项。

我建议的RTM结构是这样的：

需求ID	需求描述	类型	来源	设计文档	测试用例	风险ID
REQ-001	系统应实时显示心率	功能需求	用户需求	SDD-001	TC-001, TC-002	N/A
REQ-002	心率异常时100ms内报警	安全需求	风险分析	SDD-002	TC-003, TC-004	RISK-005

你看，每一行都是一个需求。从来源到设计到测试，清清楚楚。我曾经在一个项目里，用这个矩阵发现了17个“孤儿需求”——就是写了但没人实现的需求。你想想，要是没这个矩阵，这些需求就石沉大海了。

避坑指南： 我曾经见过一个团队，RTM做得特别漂亮，但全是手工维护。需求改了，矩阵忘了更新。结果审核时被查出20多处不一致。我的建议是：用工具维护，比如Doors、Jama，或者至少用Excel加版本控制。千万别手写。

需求写完了，不代表就对了。必须评审。

我习惯的评审流程分三步：

自检：作者自己先过一遍。检查格式、完整性、一致性。别把明显的问题留给别人。
同行评审：找2-3个同事，最好是不同角色的。开发、测试、风险管理各一个。大家坐在一起，逐条过需求。我一般要求评审者提前一天看文档，会上只讨论问题，不现场读文档。
正式签收：评审通过后，所有参与者签字确认。这不仅是形式，更是责任绑定。签了字，就代表你认可了。

评审时重点看什么？我列几个常见问题：

我的经验： 评审时不要只盯着文字。我习惯让测试人员提前写测试用例草稿。如果测试用例写不出来，那需求肯定有问题。这个方法帮我揪出了不少“伪需求”。

好了，关于需求分析，我就说这么多。记住一句话：需求分析花的时间，会在后面十倍百倍地省回来。别急着写代码，先把需求搞扎实了。