如何编写一份合格需求矩阵

　如何编写一份合格的需求矩阵

　 一、 需求矩阵的作用和特质

　通过对用户需求规格说明书和系统需求规格书进行需求分析和优化，提炼出明确的需求项，作为版本需求范围指导后续设计、编码实现、测试需求编写以及检视版本完成情况，项目经理可以通过需求矩阵管理整个版本的需求。

　二、 一份好的需求矩阵需要具备一下四个特性

　1、需求矩阵的输入是用户需求规格书和系统需求规格书，保证是和规格书一致的； 2、产品解决方案包含的需求项，保证是必要的、有价值的、完整的以及技术可行的； 3、需求项描述语言，保证是正确、简洁、无歧义的； 4、需求矩阵，保证是可跟踪和可检视的。

　三、 需求矩阵过程中常见问题

　1、功能需求追求大而全，没有考虑清楚需求的价值、优先级，会导致整体项目周期很长； 2、没有考虑需求的实现难度，投入产出比，后期需求变更风险大； 3、某些模块需求不明确，无法指导设计； 4、非功能需求容易被遗漏； 5、需求项粒度标准不一，如果粒度太粗，无法体现模块的功能需求；粒度太细又超出需求边界，有些需求项已经涉及到模块设计范畴； 6、需求矩阵编写语言不规范，无法准备表达需求项。

　四、 编写需求矩阵操作方法

　1、熟读用户需求规格书和系统需求规格书 用户需求描述使用场景，系统需求描述交付哪些功能以满足用户需求，通过熟读需求规格数，明确产品价值、使用场景、解决什么问题、需求来源和价值，对于我们清楚知道需要实现的功能目标。

　以容器云为例，我们的需要给客户提供年一套完整的，高可用的容器解决方案，包括集群、节点、应用、服务、容器、网络、存储、仓库等功能，所有的需求都是围绕这个主场景来确定价值和优先级，非主场景的需求在评审和工作量优化的时候都会被剔掉或者降低优先级。

　2、划分系统模块，确定每个模块的范围 根据功能需求范围划分大模块，并将每个大模块细分为若干子模块。

　比如容器云集群模块，划分思路大致是新建、编辑、删除、展示，如下图所示

　 3、列出每个模块的需求项和描述，输入为需求规格说明书，重点关注显性的功能点，无需列出功能细节。比如页面上需要添加某个导航入口或者交互，那是交互设计范畴。

　4、通过 TP 平台的版本需求分析功能，对整体进行隐形需求分析，包括性能、兼容性、可靠性、硬件、升级、可测性、安全性、可维护性、需求质量标准、砍老需求，这里不再赘述。

　5、需求取舍，确定需求价值和优先级，思路如下：

　1）为了保证方案完整性，目标客户用户场景需要的功能，价值高，优先级高，比如镜像仓库，缺少该功能，方案会不完整； 2）主场景、核心需求，价值高，优先级高，比如集群、应用编排等； 3）基础模块，其他模块对其有依赖的，优先级高，比如母盘、内核； 4）用户体验需求，价值高，优先级中； 5）不明确的需求，价值未知，优先级低； 6）方案实现复杂，投入产出比低，优先级低； 7）平衡好进度和完美，拿用户体验为例，尽可能做到更加友好，一味追求用户体验，项目进度可能会不断的延期；如果忽视用户体验，产品做出来非常难用，那这个产品也很难得到客户认可 8）还有另外一种思路，可以通过对需求点的重要性和紧急程度进行排序。

　6、检视需求项粒度，这个比较难把握，暂时还没想到如何量化，按照经验，一般一个大的需求项可以拆分成 5-6 个功能点，功能点再细化成测试需求点； 7、需求项描述语言规范，要求正确、简洁、无歧义的，比如支持 xxx；不支持 xxx；

　8、需求矩阵评审会议，这是一个十分重要的环节，重点关注需求完整性和正确性，确认需求的优先级，讨论不明确的需求； 9、明确需求接口人，定期检视需求是否满足用户场景，是否遗漏或者膨胀。

　五、P TP 需求管理功能优化建议

　1、TP 导出的需求矩阵，没有按照模块划分的目录结构导出 excel 表格，建议改进； 2、建议 TP 需求管理增加价值维度的优先级，分 1-3 级； 3、建议增加需求项分类，标识主场景需求和非主场景需求，辅助确定价值； 4、建议增加重要性和紧急程度，辅助确定价值； 5、建议增加实现工作量性价比，辅助确定优先级。