为什么做软件需求管理
从软件开发角度讲，需求回答了软件开发团队要做什么的问题。从软件成功的角度讲，软件项目失败原因中需求因素占比近50%。从医疗器械软件监管角度讲，是公司按照质量管理体系执行软件开发的证据。

如何做软件需求管理
宏观上讲软件需求管理，跟日常的任何需求管理底层逻辑都是一致的，基本都是获得需求，分析需求，描述需求，验证/确认求，管理需求这5大过程。

我们结合CMMI的“需求开发和管理（Requirement Development &Management）”实践域，即RDM来理解这5大过程：

YY/T 0664 《医疗器械软件-软件生存周期过程》
我们对需求管理已经有了一个大概的框架，接下来我们认识一下医疗器械软件的最基本的行业标准《医疗器械软件-软件生存周期过程》即YY/T 0664，从该标准的图示中，我们明显可以看到5.2软件需求分析，是我们CMMI概念中的RDM 3.1-3.7的实践内容

跟着图示，我们进入5.2软件需求分析章节，5.2软件需求分析章节一共如有如下6点要求：

5.2.1 定义来自系统需求的软件需求并将其形成文件

简单理解就是这过程有输出文件要求，并没有说输出文件的载体是什么，如果是成熟型企业可以通过系统管理，如果是初创企业建议先用文档管理，探索出适合公司运行的流程后，再转成系统管理。粗狂理解对应CMMI的RDM的3.1。

5.2.2 软件需求的内容

此内容是5.2.1输出文件内容的具体要求，是5.2.1输出文件内容是否合规的重点，非常详细描述5.2.1输出文件至少包含哪些内容，可以把这章节描述的内容，按照质量模型分为功能性、性能效率、兼容性、易用性、可靠性、信息/网络安全性、维护性、可移植性8大类，在5.2.1输出文件中体现。粗狂理解对应CMMI的RDM的3.2-3.5。

5.2.3 将风险控制措施纳入软件需求

就是将风险控制措施转换到5.2.1输出文件内容，从这里我们可以看到在完成5.2.1输出文件定稿之前，至少已经完成一轮风险管理工作，不可省略。具体风险管理如何做我们后续单独再说。CMMI的RDM章节未单独说。

5.2.4 医疗器械风险分析的再评价

承接5.2.3的内容，即在风险控制措施纳入5.2.1输出文件后，再回过头去评价一下风险分析的内容，并更新风险分析内容。具体风险分析如何做我们后续单独再说。CMMI的RDM章节未单独说。

5.2.5 更新需求

对需求的任何更新，做好5.2.1输出文件的更新，保证输出文件正确有效。此处隐含一个内容，变更同样要做好变更评审，变更如何做我们后续单独再说。粗狂理解对应CMMI的RDM的3.1。

5.2.6 验证软件需求

对5.2.1输出文件进行验证，确保其完整、有效及可追溯性。粗狂理解对应对应CMMI的RDM的3.7。