目标
系统需求分析过程的目的是将已定义的干系人需求转化为系统需求集以指导系统设计。
收益
系统需求分析是整个产品研发的基础，完备的表述、清晰无歧义的定义、结构化组织的系统需求是高效开发和功能测试的基石。
工作产品
沟通记录
评审记录
变更控制记录
追踪记录
分析报告
接口需求文档
系统需求规范
验证准则
基础实践
BP1: 确定系统需求
通过干系人需求和干系人需求变更识别系统的功能和能力。确定功能和非功能系统需求，形成系统需求规范。
NOTE 1: 影响功能和能力的标定参数也是系统需求的一部分。
NOTE 2: 对于干系人的需求变更应用SUP.10.
解读
- 系统需求的确定要考虑所有的干系人，包括内部和外部干系人的输入，不要遗漏对系统有影响或被系统影响的相关方。
- 系统需求不是干系人需求的简单拷贝，系统需求是干系人需求的衍生和细化，需求的条目数量一般远多于干系人需求。
- 不仅要确定功能性需求，还要包含非功能性部分
BP2: 结构化系统需求
在系统需求规范中结构化系统需求
NOTE 3: 执行优先级通常包括功能内容到计划发布的分配，参考 SPL.2.BP1.
解读
- 系统需求以结构化的形式进行组织，并统一于形成的系统需求规范中。结构化的方式使需求结构更清晰，有助于提高需求管理效率。
- 系统需求规范需要被记录，例如Word文档进行记录，也可以基于商业工具进行记录，例如DOORS/DNG/Polarion。
BP3: 分析系统需求
分析已确定的系统需求，包括需求间的依赖关系，以保证正确性、技术可行性和可验证性。分析成本和进度影响和技术影响。
NOTE 4: 对成本和进度的影响分析支持项目估算的调整，参考 MAN.3.BP5.
解读
- 系统需求分析设计需求依赖关系、风险、正确性、可行性、可验证性、成本和时间等诸多因素。
BP4: 分析对运行环境的影响
识别已确定的系统与运行环境的其他元素间的接口。分析系统需求将会对这些接口和运行环境的影响。
BP5: 确立验证准则
为系统需求制定验证准则，验证准则定义了需求验证所需的定量和定性方式 。
NOTE 5: 验证准则展示了一条需求可以基于达成一致的约束被验证，其通常作为开发系统测试用例或其他确保系统需求遵循性的验证方式的输入。
NOTE 6: 不能通过测试覆盖的验证由SUP.2过程覆盖。
解读
- 验证准则表明了需求验证基于的方式，定义了什么是 "完成"，是判断需求是否被满足的准则。
BP6: 确立双向追踪
确立干系人需求和系统需求间的双向可追踪性
NOTE 7: 双向追踪性支持覆盖度分析、一致性分析和影响分析
解读
- 双向追踪关系可以通过维护跟踪矩阵，或者基于工具提供的链接功能。关联方向可以做适当的区分，并制定有意义的表述关联关系的词汇。
BP7: 保证一致性
确保干系人需求和系统需求的一致性
NOTE 8: 一致性由双向追踪性支持，并可以通过评审记录进行展示。
BP8: 传达达成一致的系统需求
传达达成一致的系统需求以及对系统需求的更新到所有相关方。
解读
- 达成一致的系统需求和需求变更必须被所有的相关方知晓，以沟通记录的形式进行记录。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。