如何进行需求矩阵管理
产品经理需要掌握并管理产品的全部需求，需求是软件项目成败的关键所在，好的需求应具备“内涵一致，外延完整”的特质，这个特质可以保证需求分析无歧义、完整、一致、正确、可行、必要、可检验、可跟踪。
软件需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。如下图所示：
启动一个新产品时，产品经理需和各方进行充分的沟通，深刻理解客户或者公司高层对系统、产品高层次的目标要求，将业务需求反映在产品的创意阶段、策划阶段的《产品项目策划书》、《产品项目规划方案》中予以说明。
用户需求主要描述了用户能使用系统来做什么，用例、场景描述都是表达用户需求的有效途径。这部分需求通常在用例文档或方案脚本说明中予以说明。
功能需求定义了开发人员必须实现的软件功能，用户能够利用这些功能完成任务，从而满足业务需求。功能需求通常是通过对系统特性的描述表现出来的，它记录在《软件需求规格说明书》（SRS）中。《软件需求规格说明书》完整地描述了软件系统的预期特性，是开发、测试、质量保证、项目管理的重要依据。因设计的产品功能一般都较为复杂，业务规则的描述也需尽可能详尽，所以通常情况下《软件需求规格说明书》并不是一份文档，而是根据功能模块的划分由多个子文件组成。每一篇需求说明文档中均必须包含功能列表和功能详细描述，可依据实际业务情况增加数据字典方面的描述。《软件需求规格说明书》中的功能列表需要和《需求跟踪矩阵》一一对应，包括功能点编号、功能点名称。需要强调一点，需求文档的重点是说明功能所在，无需描述界面中的Icon、色彩、像素等信息，为避免和界面设计稿等展示高保真产品原型的文档发生冲突，需求文档中应尽量全部采用低保真界面，界面类描述交由《交互设计说明书》及界面设计稿、Html文件去说明。
《软件需求规格说明书》中还应包括非功能需求，非功能需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节要求，性能要求，设计或实现的约束条件及质量属性。通俗地讲，非功能需求是这样一种需求，它不是解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。在非功能需求中，针对性能方面一般需要有单点、混合、持续三方面的要求：
1、在单点方面，要求延迟和吞吐量有对应关系，假如我们设计一款BS软件，要求打开登录页面的延迟要求为响应时间3秒、抖动2秒，那么一定要在吞吐量的要求上写上针对这一点的高峰并发人数，比如100人。
2、在混合方面，产品经理依据业务的实际情况，定义混合并发值，并依据单点定义的部分或全部点以百分比的形式分配并发比例，注意混合下的并发值不得高于单点下的并发值。比如定义混合并发值200人，其中20%访问首页，20%登录，20%上传文件，40%浏览页面。
3、在持续方面，通常定义为单点最高并发值二分之一情况下的2*24小时或3*24小时持续测试。比如定义50人并发下持续性测试时间2*24小时。
《需求跟踪矩阵》主要是跟踪及统计功能需求和非功能需求。当需求基线第一次形成时就需要填写这个文档，这篇文档中的功能点名称和编号需和需求文档中对应，不得存在差异，每个功能点都需要定义它的级别（P1、P2、P3，P1为最高级别）。通常，重要程度为P1级的功能点数，不超过50%；或者P1级和P2级的功能点数，不超过80%。需求发生变更时，需填写《需求跟踪矩阵》中的需求变更记录表用以记录新增、修改、删除的功能点，并需在各模块的功能点列表中标记变更状态，通常如有新增功能，则增加在相应模块底部，字体设置为红色，如有删除功能，用蓝色标记。
在《需求跟踪矩阵》的需求变更统计表中，有一组图表可以直观地展现各阶段需求变更工作量、项目整体需求变更率、项目整体功能点变化的情况，如下图所示：
以上主要解释并分析了需求的四个层次，以及如何管理需求跟踪矩阵，希望能对产品经理们有所启发。
最后附上Jan L.A. Van de Snepscheut的一段话，可以细细品味：就理论而言，理论和实践并无差异。但真付诸实行之时，差异即开始显现。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
产品经理需要掌握并管理产品的全部需求，需求是软件项目成败的关键所在，好的需求应具备“内涵一致，外延完整”的特质，这个特质可以保证需求分析无歧义、完整、一致、正确、可行、必要、可检验、可跟踪。
软件需求是多层次的，包括业务需求、用户需求、功能需求和非功能需求。如下图所示：
启动一个新产品时，产品经理需和各方进行充分的沟通，深刻理解客户或者公司高层对系统、产品高层次的目标要求，将业务需求反映在产品的创意阶段、策划阶段的《产品项目策划书》、《产品项目规划方案》中予以说明。
用户需求主要描述了用户能使用系统来做什么，用例、场景描述都是表达用户需求的有效途径。这部分需求通常在用例文档或方案脚本说明中予以说明。
功能需求定义了开发人员必须实现的软件功能，用户能够利用这些功能完成任务，从而满足业务需求。功能需求通常是通过对系统特性的描述表现出来的，它记录在《软件需求规格说明书》（SRS）中。《软件需求规格说明书》完整地描述了软件系统的预期特性，是开发、测试、质量保证、项目管理的重要依据。因设计的产品功能一般都较为复杂，业务规则的描述也需尽可能详尽，所以通常情况下《软件需求规格说明书》并不是一份文档，而是根据功能模块的划分由多个子文件组成。每一篇需求说明文档中均必须包含功能列表和功能详细描述，可依据实际业务情况增加数据字典方面的描述。《软件需求规格说明书》中的功能列表需要和《需求跟踪矩阵》一一对应，包括功能点编号、功能点名称。需要强调一点，需求文档的重点是说明功能所在，无需描述界面中的Icon、色彩、像素等信息，为避免和界面设计稿等展示高保真产品原型的文档发生冲突，需求文档中应尽量全部采用低保真界面，界面类描述交由《交互设计说明书》及界面设计稿、Html文件去说明。
《软件需求规格说明书》中还应包括非功能需求，非功能需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节要求，性能要求，设计或实现的约束条件及质量属性。通俗地讲，非功能需求是这样一种需求，它不是解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。在非功能需求中，针对性能方面一般需要有单点、混合、持续三方面的要求：
1、在单点方面，要求延迟和吞吐量有对应关系，假如我们设计一款BS软件，要求打开登录页面的延迟要求为响应时间3秒、抖动2秒，那么一定要在吞吐量的要求上写上针对这一点的高峰并发人数，比如100人。
2、在混合方面，产品经理依据业务的实际情况，定义混合并发值，并依据单点定义的部分或全部点以百分比的形式分配并发比例，注意混合下的并发值不得高于单点下的并发值。比如定义混合并发值200人，其中20%访问首页，20%登录，20%上传文件，40%浏览页面。
3、在持续方面，通常定义为单点最高并发值二分之一情况下的2*24小时或3*24小时持续测试。比如定义50人并发下持续性测试时间2*24小时。
《需求跟踪矩阵》主要是跟踪及统计功能需求和非功能需求。当需求基线第一次形成时就需要填写这个文档，这篇文档中的功能点名称和编号需和需求文档中对应，不得存在差异，每个功能点都需要定义它的级别（P1、P2、P3，P1为最高级别）。通常，重要程度为P1级的功能点数，不超过50%；或者P1级和P2级的功能点数，不超过80%。需求发生变更时，需填写《需求跟踪矩阵》中的需求变更记录表用以记录新增、修改、删除的功能点，并需在各模块的功能点列表中标记变更状态，通常如有新增功能，则增加在相应模块底部，字体设置为红色，如有删除功能，用蓝色标记。
在《需求跟踪矩阵》的需求变更统计表中，有一组图表可以直观地展现各阶段需求变更工作量、项目整体需求变更率、项目整体功能点变化的情况，如下图所示：
以上主要解释并分析了需求的四个层次，以及如何管理需求跟踪矩阵，希望能对产品经理们有所启发。
最后附上Jan L.A. Van de Snepscheut的一段话，可以细细品味：就理论而言，理论和实践并无差异。但真付诸实行之时，差异即开始显现。
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
