需求跟踪目的

在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。

需求跟踪是个要求手工操作且劳动强度很大的任务，要求组织提供支持。随着系统开发的进行和维护的执行，要保持关联链信息与实际一致。跟踪能力信息一旦过时，可能再也不会重建它了。由于这些原因，应该正确使用需求跟踪能力。

• 下面是在项目中使用需求跟踪能力的一些好处：
  • 审核（certification） 跟踪能力信息可以帮助审核确保所有需求被应用。
  • 变更影响分析跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
  • 维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更，从而提高生产率。要是一下子不能为整个系统建立跟踪能力信息，一次可以只建立一部分，再逐渐增加。从系统的一部分着手建立，先列表需求，然后记录跟踪能力链，再逐渐拓展。
  • 项目跟踪在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联系链意味着没有相应的产品部件。
  • 再设计（重新建造） 你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个现成系统的反向工程中所学到的方法。
  • 重复利用跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关资源。例如：功能设计、相关需求、代码、测试等。
  • 减小风险使部件互连关系文档化可减少由于一名关键成员离开项目带来的风险。
  • 测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。

以上所述许多是长期利益，减少了整个产品生存期费用，但同时要注意到由于积累和管理跟踪能力信息增加了开发成本。这个问题应该这样来看，把增加的费用当作一项投资，这笔投资可以使你发布令人满意同时更容易维护的产品。尽管很难计算，但这笔投资在每一次修改、扩展或代替产品时都会有所体现。如果在开发工程中收集信息，定义跟踪能力联系链一点也不难，但要在整个系统完成后再实施代价确实很大。

CMMI要求具备需求跟踪能力。软件产品工程活动的关键过程域有关于它的陈述，“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。”需求跟踪过程中还定义了一些关于一个组织如何处理需求跟踪能力的期望。

需求跟踪能力矩阵

表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。下表展示了这种矩阵，这是一个“化学制品跟踪系统”实例的跟踪能力矩阵的一部分。这个表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计、代码和测试元素。设计元素可以是模型中的对象，例如数据流图、关系数据模型中的表单、或对象类。代码参考可以是类中的方法，源代码文件名、过程或函数。加上更多的列项就可以拓展到与其它工作产品的关联，例如在线帮助文档。包括越多的细节就越花时间，但同时很容易得到相关联的软件元素，在做变更影响分析和维护时就可以节省时间。

表1：一种需求跟踪能力矩阵

用例	功能需求量	设计元素	代码	测试实例
UC-28 UC-29	Catalog.query.sort catalog.query.IMport	Class Catalog Class catalog	Catalog.sort() Catalog.import() Catalog.valiDATe()	Search.7 Search.8 Search.8 Search.13 Search.14 跟踪能力联系链可以定义各种系统元素类型间的一对一，一对多，多对多关系。表1中允许在一个表单元中填入几个元素来实现这些特征。这里是一些可能的分类： 一对一一个代码模块应用一个设计元素。 一对多多个测试实例验证一个功能需求。 多对多每个使用实例导致多个功能性需求，而一些功能性需求常拥有几个使用实例。 手工创建需求跟踪能力矩阵是一个应该养成的习惯，即使对小项目也很有效。一旦确立使用实例基准，就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构造、测试开发的进展不断更新矩阵。例如，在实现某一功能需求后，你可以更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。表示跟踪能力信息的另一个方法是通过矩阵的集合，矩阵定义了系统元素对间的联系链。例如： 一类需求与另一类需求之间。 同类中不同的需求之间。 一类需求与测试实例之间。 可以使用这些矩阵定义需求间可能的不同联系，例如：指定/被指定、依赖于、衍生为以及限制/被限制。 下表2中说明了两维的跟踪能力矩阵。矩阵中绝大多数的单元是空的。每个单元指示相对应行与列之间的联系，可以使用不同的符号明确表示“追溯到”和“从.. 回溯”或其他联系。表2中使用一个箭头表示一个功能性需求是从一个使用实例追溯来的。这些矩阵相对于表16-6中的单跟踪能力表更容易被机器自动支持。 表2：反映使用实例与功能需求之间联系的需求跟踪能力矩阵 功能 需求 用例 U C - 1 U C - 2 U C - 3 U C - 4 F R - 1 √ F R - 2 √ F R - 3 √ F R - 4 √ F R - 5 √ √ F R - 6 √ 跟踪能力联系链无论谁有合适的信息都可以定义。下表3定义了一些典型的知识源，即关于不同种类源和目标对象间的联系链。定义了可以为工程项目提供每种跟踪能力信息的角色和个人。 表3：跟踪能力联系链可能的信息源 链的源对象种类 链的目的对象种类 信息源 系统需求 用例 功能性需求 功能性需求 功能性需求 设计元素 功能性需求 软件需求 功能性需求 功能性需求 软件体系结构元素 其他设计元素 代码 测试实例 系统工程师 需求分析员 需求分析员 软件体系结构（设计）者 开发者 开发者 测试工程师 需求跟踪能力工具 由于联系链源于开发组成员的头脑中，所以需求跟踪能力不能完全自动化。然而，一旦已确定联系链，特定工具就能帮你管理巨大的跟踪能力信息。可以使用电子数据表来维护几百个需求的矩阵，但更大的系统需要更“鲁棒”的解决办法。 具有强大需求跟踪能力的商业需求管理工具均使用如表16 -7的跟踪能力矩阵。可以在工具的数据库中存储需求和其他信息，定义不同对象间的联系链，甚至包括同类需求的对等联系链。有一些工具需要区分“追溯到（跟踪进）”与“从..回溯（跟踪出）”关系，自动定义相对的联系链。这就是说，如果你指出需求R追溯到测试实例T，工具会自动定义相对的联系“ T从R回溯”。还有一些工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查确保知道变更的后续效果。 这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有20个子系统的大项目，某些高层产品需求建立在多个子系统之上。有些情况下，分配给一个子系统的需求，实际上是由另一个子系统提供的服务完成的。这样的项目采用商业需求管理工具可以成功地跟踪这些复杂的跟踪能力关系。 需求跟踪能力过程 当你应用需求跟踪能力来管理工程时，可以考虑下列步骤： 决定定义哪几种联系链，可以参见图2来进行。 选择使用的跟踪能力矩阵的种类，是表1还是表2。 确定对产品哪部分维护跟踪能力信息。由关键的核心功能、高风险部分或将来维护量大的部分开始做起。 通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链。 制定标记性的规范，用以统一标识所有的系统元素，达到可以相互联系的目的。若必要，作文字记录，这样就可以分析系统文件，便于重建或更新跟踪能力矩阵。 确定提供每类联系链信息的个人。 培训项目组成员，使其接受需求跟踪能力的概念和了解重要性、这次活动的目的、跟踪能力数据存储位置、定义联系链的技术—例如，使用需求管理工具的特点。确保与会人员明白担负的责任。 一旦有人完成某项任务就要马上更新跟踪能力数据，即要立刻通知相关人员更新需求链上的联系链。 在开发过程中周期性地更新数据，以使跟踪信息与实际相符。要是发现跟踪能力数据没完成或不正确那就说明没有达到效果。 需求跟踪能力的可行性 对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程，但这很必要。并不是所有的公司都会因为软件问题而造成严重的结果，然而应该严肃地对待需求跟踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后，才能决定是否使用任何改进的需求工程实践。随着软件的发展，要把时间投向回报丰厚的地方。 联系管理员 15775053793 经济百科创始人 经济百科 经济百科，分享各种关于经济的科普知识。 版权声明：本站文章如无特别标注，均为本站原创文章，于2022-08-13，由经济百科发表，共 4567个字。 转载请注明出处：经济百科，如有疑问，请联系我们 本文地址：http://www.dj0415.com/xu-qiu-gen-zong-f71 上一篇:教育制度 下一篇:里斯和里斯聚焦咨询公司 相关推荐 公益服务 拆迁补偿安置协议 特锐德 战略中心说 发表评论 取消回复 发布评论