软件需求与分析教程（第二十章）.ppt

第20章 需求链中的联系链 本章的主题是需求跟踪(或可追溯性)。 需求跟踪机制将单个需求和其他系统元素之间的依赖关系和逻辑联系编写成文档，这些元素包括各种类型的其他需求、业务规则、系统体系结构和其他设计组件、源代码模块、测试用例以及帮助文件等。 20.1 需 求 跟 踪 图20.1演示了4种类型的需求跟踪链(Jarke 1998)。 通过跟踪链，我们可以了解各个需求之间的父子关系、相互连接和依赖关系，这些信息揭示出删除或修改某一特定的需求会波及到的范围。 20.2 需求跟踪动机 需求跟踪是一个需要进行大量手工劳动的任务，需要组织提供支持。在系统开发和维护的过程中，一定要随时更新这些联系链信息。 应该正确利用需求跟踪能力(Ramesh et al. 1995)。实现需求跟踪能力可能在以下方面给我们带来好处： 审核(certification) 要审核一个安全关键(safety-critical)的产品时，通过跟踪信息可以证明所有的需求都已实现，虽然并不能确认实现是否正确和完整！ 变更影响分析 如果没有跟踪信息，当添加、删除或修改某一特定的需求时，就很可能会忽略受影响的系统元素。 20.2 需求跟踪动机 维护 可靠的跟踪信息有利于在维护过程中正确而完整地实施变更，从而提高生产率。 项目跟踪 如果在开发期间认真地记录跟踪数据，就可以获得一个列入计划中功能的实现状态的精确记录。 再工程(reengineering) 定义跟踪联系链是一种方法，可以捕获到从现有系统的逆向工程中了解到的一些信息。 重用 通过跟踪信息可以确认与需求、设计、编码和测试相关的软件包，就可以方便地复用产品组件。 降低风险 把组件互连关系(interconnection)文档化，当对系统有深入了解的关键团队成员离开项目组时，就可以降低由此带来的风险(Ambler 1999)。 测试 了解哪些测试验证哪些需求，可以消除冗余测试，从而节省时间。 20.3 需求跟踪矩阵 表示需求和其他系统元素之间联系链的最普遍的方式是需求跟踪能力矩阵(requirements traceability matrix)，也称为需求跟踪矩阵(requirements trace matrix)或可跟踪性表(traceability table)(Sommerville和Sawyer 1997)。 表20.1说明了这种矩阵的一部分。 20.3 需求跟踪矩阵 表示需求和其他系统元素之间联系链的最普遍的方式是需求跟踪能力矩阵(requirements traceability matrix)，也称为需求跟踪矩阵(requirements trace matrix)或可跟踪性表(traceability table) (Sommerville和Sawyer 1997)。 非功能性需求(例如性能目标和质量属性)并不总是能直接跟踪到代码。 图20.3说明了一种包括非功能性需求的可能的跟踪联系链。 跟踪联系链可以定义系统元素之间的一对一、一对多、多对多的关系。表20.1可以表示出这些基数(cardinality)。 20.3 需求跟踪矩阵 表20.3给出了一些典型的有关各种类型的源对象和目标对象之间的联系链的信息源。 20.4 需求跟踪工具 第21章将介绍几种商业需求管理工具，这些工具有强大的需求跟踪能力。可以将需求和其他信息存储在这种工具的数据库中，并定义各种类型的存储对象之间的联系链，包括相同类型的两个需求之间的对等联系链。 有些工具可以区分开“跟踪到……”和“从……跟踪出”关系，并自动地定义相反的联系链。 联系链的一端被修改，一些工具都会自动地将联系链标记为“可疑(suspect)”，这种联系链在需求跟踪矩阵的相应表格单元中有一个可见的指示符。 20.5 需求跟踪过程 对某个特定的项目开始进行需求跟踪时，应该考虑下面这些步骤： (1)选择要定义的联系链。 (2)选择要使用的跟踪矩阵的类型。 (3)确定对产品的哪些部分维护跟踪信息。 (4)修改开发过程和检查列表。 (5)定义使用什么样的标记约定可以惟一地标识系统元素 (6)确定负责提供每类联系链信息的人员，和负责协调跟踪活动并管理这些数据的人员。 (7)为项目团队提供培训，讲述需求跟踪的概念和重要性、这一活动的目标、跟踪数据的存储位置以及定义这些联系链所用的技术。 (8)在开发过程中，要求每个参与者只要完成工作的一小部分主体后，就提供所要求的跟踪信息。 (9)要定期审核跟踪信息，以确保信息必威体育精装版。 20.6 需求跟踪可行吗？必要吗？ 即使产品出现故障并不会造成生命危险或肢体受伤，也应该认真对待需求跟踪。 应该根据采用某一技术所需的费用和不采用这一技术所带来的风险