追踪性基础知识

1.可追踪性

软件可追踪性是指在软件开发过程中建立和维护软件制品之间的关联关系，并利用这些关系对软件项目进行一系列分析的能力^[1]。需求可追踪性指的是前向或后向描述和跟踪整个需求生命周期的能力^[2]。例如，从需求的起源，经由开发和规约到随后的部署和使用等。

[1] Co EST: Center of excellence for software traceability, http://www.Co EST.org.

[2] Gotel O C Z, Finkelstein A C W. An analysis of the requirements traceability problem[C]//Requirements Engineering, 1994., Proceedings of the First International Conference on. IEEE, 1994: 94-101.

【说明】分析的能力：可追溯性支持许多活动，例如证明产品符合利益相关方规定的要求，并符合一系官方规定。可追溯性也被用来建立和理解需求和下游工作产品（如设计文档，源代码和测试用例）之间的关系。在这种情况下，它支持诸如影响分析这样的任务，这些任务可以帮助开发人员理解提议的变更如何影响当前的系统，通过追溯源代码的所有元素回溯到特定的需求以及安全分析来识别多余和不需要的功能的代码验证。可追溯性还可以通过识别符合（新）要求的部分以及软件系统的发展来支持软件系统部分的重用。

【说明】前向和后向：前向追踪是指从书写文档形式的需求(软件需求规格说明SRS)追踪到需求的来源．后向追踪指在软件开发过程中，从需求义档确定后一直到软件发布过程中的各种制品之间的追踪。

2.可追踪性基础

2.1TIM

可追踪信息元模型定义了项目中被追踪的软件制品类型、追踪链类型等，为实际项目中可追踪信息的建立提供指导，是软件可追踪性的核心^[1]。

[1] Cleland-Huang J, Gotel O, Zisman A. Software and systems traceability[M]. Springer, 2012.

l 可追踪制品(Trace Artifact)指一个可被追踪的数据单元，可以是软件生命周期中出现任何制品、组织或个人，例如单个需求、需求集、UML 类或源代码等。每个可追踪制品都有其各自的属性，如制品类型。可追踪制品类型(Trace Artifact Type)用于标识拥有相同或相似结构（语法）或用途（语义）的可追踪制品。如软件的需求、设计或测试用例为不同类型的软件制品。

l 可追踪链(Trace Link)描述了一对制品间特定的关联关系。与可追踪制品相同，可追踪链也有其各自的属性，如可追踪链类型。可追踪链类型(Trace Link Type)用于标识有相同或相似结构或用途的制品间关联关系，如实现、测试、精化及替代关系等。

l 追踪关系(Trace Relation)描述了给定类型的可追踪制品间的所有追踪链的集合。例如，需求与需求的追踪关系描述了需求之间存在的全部可追踪链。追踪关系类型表示了制品间特定类型的追踪关系。

2.2追踪性分类^[1]

(1) 向 前 需 求 规 范 (Pre-requirements Specification) 和 向 后 需 求 规 范 (Pre-requirements Specification)可追踪性^[2]：向前、向后需求规范可追踪性分别表示向前追踪需求规范或向后追踪需求规范的能力。向前追踪指的是从需求规范到用户需求的追踪，向后追踪则指的是从需求规范到实现需求的软件设计、源代码间的追踪。

（2）前向(Forwards)和后向可追踪性(Backwards)^[3]：前向追踪指的是从当前软件制品到其后继派生制品的追踪，如从需求到实现该需求的源代码之间的追踪，后向追踪的是从当前制品到派生出该制品的源制品的追踪，如从源代码中某功能函数到 UML 类中某操作的追踪。

（3）水平(Horizontal)和垂直(Vertical)可追踪性^[4]：水平追踪指的是对处于相同的项目开发阶段或拥有相同抽象层次的制品间的追踪，例如与系统性能相关的所有需求间的追踪，特定需求在不同时刻不同版本间的追踪。垂直可追踪性则描述了处于不同阶段拥有不同抽象层次制品间的追踪，如软件需求和设计制品间的追踪。水平和垂直追踪中均可包含前向和后向可追踪。

（4）层次内(Within-Level)和层次间(Between-Level)的可追踪性^[5]：与水平和垂直追踪类似，层次内追踪指对拥有相同抽象层次不同精化程度制品的追踪，例如，同一需求规范中不同用例图间或需求间的追踪。层次间追踪则指对属于不同抽象层次制品的追踪

[1] Winkler S, Pilgrim J. A survey of traceability in requirements engineering and model-driven development[J]. Software and Systems Modeling (So Sy M), 2010, 9(4): 529-565.

[2] Gotel O C Z, Finkelstein A C W. An analysis of the requirements traceability problem[C]//Requirements Engineering, 1994., Proceedings of the First International Conference on. IEEE, 1994: 94-101.

[3] IEEE. (1984). IEEE Guide to Software Requirements Specification.

[4] Ramesh B, Edwards M. Issues in the development of a requirements traceability model[C]//Requirements Engineering, 1993., Proceedings of IEEE International Symposium on. IEEE, 1993: 256-259.

[5] Von Knethen A, Paech B. A survey on tracing approaches in practice and research[J]. Frauenhofer Institut Experimentelles Software Engineering, IESE-Report No, 2002, 95.

【说明】：向前和前向，向后和后向：

‚ 向前指的的是从需求规范到用户需求，向后指的是从需求规范到需求的软件设计

‚ 前向是从当前软件制品到其后继派生制品的追踪，如从需求到实现该需求的源代码之间的追踪，后向追踪的是从当前制品到派生出该制品的源制品的追踪，如从源代码中某功能函数到 UML 类中某操作的追踪。

ƒ 向前和前向的区别是向前是从出发点向前，比如从需求规范到用户需求。而前向是从出发点向后，比如从需求到需求的代码实现。向后和后向也是这个区别

2.3追踪关系的分类^[1]

（1）依赖(Dependency)：若制品 E1依赖于制品 E2，则 E2是 E1实现的基础和前提，制品E2的变更也会导致 E1的变更。依赖关系可以存在于不同的需求或需求与设计元素间。

（2）精化/泛化(Refinement/Generalization)：精化关系存在于属于不同抽象层次的软件制品中，可以表示一个抽象泛化的软件制品的细化或具体化、对一个复杂制品的分解等。

（3）演化(Evolution)：演化关系描述了制品在开发和维护过程中的演化或替代关系，若制品 E1演化为 E2表明原制品 E1被现有制品 E2所替代。例如新版本替换旧版本或需求的再加工等。

（4）可满足性(Satisfiability)：可满足性关系描述了开发过程中另一种类型的演化关系，若制品 E1满足了 E2的预期、需求或 E1符合 E2的某种条件，则称 E1可满足 E2。例如，下游的软件制品实现了上游软件制品的需求。

（5）覆盖(Overlap)：覆盖关系描述了拥有相同系统或领域功能或特性的制品间的关联关系。例如，自然语言的文本需求与其对应的形式化描述间的关联。

（6）冲突(Conflict)：冲突关系标识了制品间的矛盾，如需求间的不一致等。冲突关系通常伴随着解决冲突和问题的方法、冲突时制品的选择等信息。

（7）原理(Rationale)：此类关系通常用于描述和维护制品创建、演化的依据或系统不同级别的决策信息。

（8）贡献(Contribution)：此类关系泛化表示软件制品与项目相关人员之间的关联，如用户与其所提出的需求间的关联关系。

【说明】需求间存在依赖、精化、演化及冲突等追踪关系，软件的设计制品间

存在依赖、精化、可满足和冲突等类型的追踪关系。

[1] Spanoudakis G, Zisman A. Software traceability: a roadmap[J]. Handbook of Software Engineering and Knowledge Engineering, 2005, 3: 395-428.