亲爱的读者，很多人可能对需求跟踪的需求跟踪能力矩阵和关于需求跟踪矩阵以下哪一个描述是正确的不是很了解，所以今天我来和大家分享一些关于需求跟踪的需求跟踪能力矩阵和关于需求跟踪矩阵以下哪一个描述是正确的的知识，希望能够帮助大家更好地了解这个话题。
本文目录一览
需求跟踪的需求跟踪能力矩阵
表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。下表展示了这种矩阵，这是一个“化学制品跟踪系统”实例的跟踪能力矩阵的一部分。这个表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计、代码和测试元素。设计元素可以是模型中的对象，例如数据流图、关系数据模型中的表单、或对象类。代码参考可以是类中的方法，源代码文件名、过程或函数。加上更多的列项就可以拓展到与其它工作产品的关联，例如在线帮助文档。包括越多的细节就越花时间，但同时很容易得到相关联的软件元素，在做变更影响分析和维护时就可以节省时间。
表1：一种需求跟踪能力矩阵用例功能需求量设计元素代码测试实例UC-28
UC-29Catalog.query.sort
catalog.query.importClass
Catalog
Class
catalogCatalog.sort()
Catalog.import()
Catalog.validate()Search.7
Search.8
Search.8
Search.13
Search.14跟踪能力联系链可以定义各种系统元素类型间的一对一，一对多，多对多关系。表1中允许在一个表单元中填入几个元素来实现这些特征。这里是一些可能的分类：
一对一一个代码模块应用一个设计元素。一对多多个测试实例验证一个功能需求。多对多每个使用实例导致多个功能性需求，而一些功能性需求常拥有几个使用实例。手工创建需求跟踪能力矩阵是一个应该养成的习惯，即使对小项目也很有效。一旦确立使用实例基准，就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构造、测试开发的进展不断更新矩阵。例如，在实现某一功能需求后，你可以更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。表示跟踪能力信息的另一个方法是通过矩阵的，矩阵定义了系统元素对间的联系链。例如：
一类需求与另一类需求之间。同类中不同的需求之间。一类需求与测试实例之间。可以使用这些矩阵定义需求间可能的不同联系，例如：指定/被指定、依赖于、衍生为以及限制/被限制。
下表2中说明了两维的跟踪能力矩阵。矩阵中绝大多数的单元是空的。每个单元指示相对应行与列之间的联系，可以使用不同的符号明确表示“追溯到”和“从..回溯”或其他联系。表2中使用一个箭头表示一个功能性需求是从一个使用实例追溯来的。这些矩阵相对于表16-6中的单跟踪能力表更容易被机器自动支持。
表2：反映使用实例与功能需求之间联系的需求跟踪能力矩阵功能
需求用例UC-1UC-2UC-3UC-4FR-1√FR-2√FR-3√FR-4√FR-5√√FR-6√跟踪能力联系链无论谁有合适的信息都可以定义。下表3定义了一些典型的知识源，即关于不同种类源和目标对象间的联系链。定义了可以为工程项目提供每种跟踪能力信息的角色和个人。
表3：跟踪能力联系链可能的信息源链的源对象种类链的目的对象种类信息源系统需求
用例
功能性需求
功能性需求
功能性需求
设计元素
功能性需求软件需求
功能性需求
功能性需求
软件体系结构元素
其他设计元素
代码
测试实例系统工程师
需求分析员
需求分析员
软件体系结构（设计）者
开发者
开发者
测试工程师
关于需求跟踪矩阵以下哪一个描述是正确的
项目经理要首先关注高层级或项目级别的需求，比如项目成本变化、项目时间变化等，而产品相关的需求变化应该由产品经理或开发人员专门关注。需求跟踪矩阵属于项目管理范畴，应该首先关注项目需求，项目经理一定不要把自己局限于具体工作，要从具体工作的上层或背后动因看问题望采纳~
总结：以上就是本站针对你的问题搜集整理的答案，希望对你有所帮助。