28、软件需求可追溯性：关键概念与实践指南

软件需求可追溯性：关键概念与实践指南

1. 需求可追溯性概述

需求追溯能够确定软件变更的潜在影响，从而帮助我们选择回报率最高的变更进行投入。在项目中，很多人会提及“可追溯性”，期望项目实现全面的需求可追溯性，但实际上，很少有软件项目团队能真正做到这一点，尤其是采用面向对象技术的团队。需求可追溯性十分复杂，需要集成工具支持以及深入理解软件开发过程的团队成员。

需求可追溯性是指在整个系统生命周期内，能够描述和跟踪需求的生命周期，包括正向和反向跟踪。正向跟踪意味着对于任何可交付成果的特征，都能追溯到其最初来源以及最终实现；反向跟踪则是从实现追溯到需求。同时，需求可追溯性应贯穿整个系统生命周期，这里的系统生命周期不仅仅是软件开发阶段，还包括维护和支持阶段。

需求可追溯性有四种不同类型：
- 正向从需求出发（Type 1） ：将满足需求的责任分配给各个系统组件，确保每个需求都能得到满足。
- 反向到需求（Type 2） ：验证软件是否符合需求。无法追溯到需求的软件功能可能表示需求缺失或过度设计（镀金）。
- 正向到需求（Type 3） ：将利益相关者的需求映射到需求文档，以便在需求变化时确定对需求的影响。
- 反向从需求出发（Type 4） ：验证系统是否满足用户群体的需求，有助于在申请预算时提供依据。

2. 为何需要需求可追溯性

从软件工程的角度来看，需求可追溯性有四个实际好处：
- 使业务需求与软件对齐 ：提高软件开发的有效性和信息技术部门的生产力。
- 降低风险 ：通过捕获对项目成功至关重要的知识，避免因人员离职而导致知识流失。
- 确定变更影响 ：能够轻松确定变更所需的时间、成本和潜在收益，帮助组织做出更明智的投资决策。
- 支持过程改进 ：帮助理解软件开发过程，识别员工工作中的困难并加以改进。

然而，从商业角度来看，一些所谓的好处存在疑问甚至有害。例如，为了满足合同要求而进行的可追溯性工作往往变得官僚和繁琐，很少用于改进软件或软件过程；为了避免批评或法律诉讼而进行可追溯性工作也不是一个好的动机。

3. 何时进行需求追溯

需求追溯应贯穿整个项目过程：
- 初始阶段（Inception） ：从确定系统的初始需求开始，开发的初始用户界面原型应可追溯到业务需求，有助于完善需求和设计更有效的用户界面。
- 细化阶段（Elaboration） ：在改进需求模型和定义架构时继续追溯，确保架构满足需求，并发现之前遗漏的需求。
- 构建阶段（Construction） ：将需求追溯到模型、源代码和单元测试用例，检查软件是否满足需求，发现冗余或不一致的工作。
- 过渡阶段（Transition） ：功能测试用例追溯到初始需求，证明交付的软件符合定义的需求，快速定位测试失败的部分。
- 生产阶段（Production） ：在识别问题报告和新需求时仍需进行追溯，变更控制委员会应审查潜在变更，进行影响分析并分配到未来版本。

许多组织将追溯工作留到项目生命周期的末尾，这往往没有太大价值，是浪费时间的做法。

4. 可追溯性与UML

在可追溯性与UML方面，有两个基本问题需要解决：UML如何支持可追溯性以及应该追溯什么。

UML通过跟踪构造型（trace stereotype）支持可追溯性。在模型上表示可追溯性时，只需从一个项目到另一个项目建模一个依赖关系，用带开放箭头的虚线表示，并标记为 «trace»。但仅仅画一条线并标记是不够的，还需要记录追溯的原因、记录追溯的人员以及追溯的时间。

关于应该追溯什么，这更为复杂。UML图之间以及潜在的面向对象开发可交付成果之间都需要进行追溯。例如：
- 关键需求可交付成果之间 ：用例模型与业务规则、用户界面模型、用户文档之间需要进行追溯。
- 类模型与其他可交付成果之间 ：非功能需求与类模型、状态图模型与类模型、类模型与持久化模型、类模型与源代码、类模型与组件模型之间都存在可追溯性。
- 项目计划和变更案例 ：项目计划应基于用例模型进行开发，每个迭代应追溯到一个或多个用例；变更案例应追溯到可能受影响的用例。

以下是一个简单的mermaid流程图，展示部分可追溯关系：

graph LR
    A[用例模型] --> B[业务规则]
    A --> C[用户界面模型]
    A --> D[用户文档]
    D --> C
    E[类模型] --> F[非功能需求]
    E --> G[状态图模型]
    G --> E
    E --> H[持久化模型]
    E --> I[源代码]
    E --> J[组件模型]

5. 可追溯性与统一过程

统一过程采用迭代和增量的开发方法，这对需求可追溯性有重要影响。迭代开发要求在开发过程中能够轻松追溯可交付成果之间的关系；增量开发则需要追溯可交付成果的不同版本。

统一过程的主要可交付成果包括需求模型、设计模型、实现模型和测试模型。设计模型的第n次迭代基于第n次迭代的需求模型和第n - 1次迭代的现有设计模型开发，因此需要追溯到这两个模型。为了维护模型版本之间的可追溯性，需要对模型进行基线化，进行配置管理，并在每次迭代结束时禁止对基线版本进行更改。

以下是参与需求追溯的人员及其职责列表：
|人员|职责|
| ---- | ---- |
|分析师|从组织需求到需求模型、测试模型和设计模型的追溯|
|设计师|与分析师合作确保可追溯性，与架构师和程序员合作确保设计到代码的可追溯性|
|架构团队|确保项目架构与企业架构的可追溯性|
|测试工程师|与所有项目团队成员合作确保测试模型的可追溯性|

6. 成功秘诀

• 持续追溯需求 ：可追溯性应成为日常工作的一部分，尽早记录追溯信息，以便更快地获得好处。
• 工具支持 ：虽然由于对象范式和UML图的一致性，很多追溯工作可以自动完成，但市场上支持全面可追溯性的工具较少，因此工具支持至关重要。
• 理解重要性 ：让团队成员理解需求可追溯性的重要性，提供培训和教育，寻找能够开发健壮软件的导师。
• 制定追溯策略 ：组织应定义和记录需求可追溯性策略，并在所有软件项目中积极支持和执行。
• 提高生产力 ：利用可追溯性提高整体生产力，而不是仅仅为了生成文档。

需求可追溯性是软件开发的关键方面，虽然其好处常被低估和误解，但它是变更控制的关键推动者。采用成熟的需求可追溯方法往往是成功开发软件的组织与不成功的组织之间的关键区别。在下次软件项目中选择进行需求追溯，是选择成功的一部分。

7. 潜在的面向对象可交付成果

以下是一些潜在的面向对象可交付成果及其定义：
- 活动模型 ：一个或多个UML活动图及相应文档，描述系统的动态性质和业务流程。
- 业务规则 ：系统必须支持的操作或准则的规定，通常用文本和活动图描述。
- 变更案例 ：对现有系统潜在需求的描述，有助于系统架构设计以支持未来需求。
- 类模型 ：类图及相应文档，展示软件的静态视图。
- 协作图 ：显示类的实例、它们之间的关系和消息流。
- 组件模型 ：组件图及相应文档，描述软件组件及其关系。
- 部署模型 ：UML部署图及文档，描述系统的硬件或软件配置。
- 持久化模型 ：指示持久对象数据的永久存储方式。
- 项目计划 ：包括项目概述、进度、估算、团队定义和风险评估等项目管理可交付成果。
- 序列图 ：显示用例场景中对象类型、消息和返回值。
- 源代码 ：软件的代码实现。
- 状态图 ：描述对象的状态和状态转换。
- 补充规范 ：非行为需求的集合，如法规要求、质量要求和技术要求。
- 用例模型 ：用例图及文档，描述系统的功能/行为需求。
- 用户文档 ：用户手册、参考手册等，指导用户使用系统。
- 用户界面模型 ：用户界面原型、界面流程图和支持规范等。

通过对这些可交付成果之间的可追溯性管理，可以更好地实现软件项目的需求可追溯性，提高软件质量和开发效率。

软件需求可追溯性：关键概念与实践指南

8. 可追溯性的挑战与应对策略

尽管需求可追溯性带来诸多好处，但在实践中也面临一些挑战。

挑战1：工具支持不足
市场上支持全面可追溯性的工具较少，这使得很多追溯工作难以自动化完成。很多工具只能提供部分功能，无法满足复杂项目的需求。
应对策略 ：组织需要仔细评估现有的工具，选择最适合项目需求的工具。同时，可以考虑定制开发一些辅助工具，以弥补现有工具的不足。另外，鼓励工具供应商不断改进和完善其产品，推动行业工具的发展。

挑战2：团队成员理解不足
如果团队成员不理解需求可追溯性的重要性，就很难投入足够的精力去做好这项工作。他们可能认为这是额外的负担，而忽视了其对项目的长期价值。
应对策略 ：加强对团队成员的培训和教育，让他们了解需求可追溯性的概念、好处以及在项目中的具体应用。可以通过内部培训、分享会等形式，提高团队成员的认识。同时，寻找理解如何开发健壮软件的导师，为团队成员提供指导和支持。

挑战3：缺乏有效的追溯策略
没有明确的需求可追溯性策略，团队在进行追溯工作时可能会混乱无序，导致追溯结果不准确或不完整。
应对策略 ：组织应定义和记录详细的需求可追溯性策略，并将其传达给所有项目团队成员。策略应包括追溯的范围、方法、流程以及责任分配等内容。同时，要积极支持和执行该策略，确保其在所有软件项目中得到有效实施。

挑战4：项目变更频繁
在项目开发过程中，需求、设计等方面可能会频繁变更，这增加了需求可追溯性的难度。变更可能导致原有的追溯关系失效，需要及时更新和维护。
应对策略 ：建立有效的变更管理机制，对项目变更进行严格的控制和管理。在变更发生时，及时评估其对需求可追溯性的影响，并更新相应的追溯信息。同时，加强沟通和协作，确保所有团队成员都了解变更的情况和影响。

9. 可追溯性在不同项目阶段的具体实践

为了更好地说明需求可追溯性在实际项目中的应用，下面详细介绍其在不同项目阶段的具体实践。

初始阶段（Inception）
- 需求收集 ：通过直接与用户沟通、了解管理层的需求等方式，收集系统的初始需求。将这些需求记录在需求文档中，并为每个需求分配唯一的标识符。
- 原型开发 ：根据收集到的需求，开发初始用户界面原型。在原型开发过程中，确保每个原型元素都能追溯到相应的需求。可以使用工具或手动记录的方式，建立需求与原型元素之间的追溯关系。
- 需求验证 ：对收集到的需求进行验证，确保其完整性、准确性和可行性。通过与用户和管理层的沟通，确认需求是否符合他们的期望。同时，检查需求与原型之间的追溯关系是否正确。

细化阶段（Elaboration）
- 需求分析 ：对初始需求进行深入分析，将其分解为更详细的子需求。在分析过程中，建立子需求与父需求之间的追溯关系。
- 架构设计 ：根据需求分析的结果，进行系统架构设计。确保架构设计能够满足所有需求，并建立需求与架构元素之间的追溯关系。例如，将功能需求映射到相应的模块和组件。
- 新需求发现 ：在细化阶段，可能会发现一些之前遗漏的需求。对于这些新需求，同样要建立其与其他相关元素的追溯关系，并更新需求文档和设计文档。

构建阶段（Construction）
- 模型开发 ：根据架构设计，开发各种模型，如类模型、序列图等。在模型开发过程中，确保模型元素能够追溯到相应的需求和设计。例如，类的属性和方法应能追溯到需求中的功能描述。
- 代码实现 ：根据模型，进行源代码的实现。在代码编写过程中，确保代码能够实现相应的需求和模型。可以通过在代码中添加注释的方式，记录代码与需求、模型之间的追溯关系。
- 单元测试 ：编写单元测试用例，对代码进行测试。确保单元测试用例能够验证代码是否实现了相应的需求。建立需求与单元测试用例之间的追溯关系，以便在测试过程中发现问题时能够快速定位到相关需求。

过渡阶段（Transition）
- 功能测试 ：进行功能测试，验证交付的软件是否满足定义的需求。将功能测试用例追溯到初始需求，确保每个需求都得到了验证。
- 问题定位 ：如果在测试过程中发现软件存在问题，通过需求可追溯性，快速定位到问题所在的需求和相关代码。根据问题的严重程度和影响范围，确定是否需要进行变更。
- 变更管理 ：对于需要进行的变更，按照变更管理机制进行处理。在变更实施过程中，更新相应的追溯信息，确保追溯关系的准确性。

生产阶段（Production）
- 问题报告 ：在软件投入生产后，收集用户反馈的问题报告。将问题报告追溯到相应的需求和代码，分析问题的原因。
- 新需求识别 ：根据用户的反馈和业务的发展，识别新的需求。对于新需求，建立其与现有系统的追溯关系，并评估其对系统的影响。
- 版本管理 ：根据问题报告和新需求，进行系统的版本更新。在版本更新过程中，维护好需求可追溯性，确保不同版本之间的追溯关系清晰。

10. 可追溯性与项目管理的结合

需求可追溯性与项目管理密切相关，它可以为项目管理提供重要的支持。

进度管理 ：通过需求可追溯性，可以清晰地了解每个需求的实现进度。如果某个需求的实现出现延迟，可以快速定位到相关的任务和责任人，及时采取措施进行调整。同时，根据需求的优先级和依赖关系，合理安排项目进度，提高项目的整体效率。

风险管理 ：需求可追溯性有助于识别项目中的风险。例如，如果某个需求的追溯关系不清晰，可能意味着该需求的实现存在风险。通过对需求可追溯性的监控，可以及时发现潜在的风险，并采取相应的措施进行防范。另外，在项目变更时，通过需求可追溯性评估变更对项目的影响，降低变更带来的风险。

质量管理 ：需求可追溯性是保证软件质量的重要手段。通过将测试用例追溯到需求，可以确保软件的所有功能都得到了充分的测试。如果发现软件存在质量问题，可以通过追溯关系快速定位到问题所在的需求和代码，及时进行修复。同时，通过对需求可追溯性的分析，可以发现软件过程中的薄弱环节，采取措施进行改进，提高软件的整体质量。

成本管理 ：需求可追溯性可以帮助组织更好地管理项目成本。通过了解每个需求的实现成本，可以合理分配资源，避免资源的浪费。在进行项目变更时，通过评估变更对需求可追溯性的影响，准确计算变更带来的成本，从而做出更明智的决策。

11. 总结与展望

需求可追溯性是软件项目开发中至关重要的一环，它能够帮助组织更好地管理软件变更、降低风险、提高软件质量和开发效率。虽然需求可追溯性面临着诸多挑战，但通过采用合适的工具、加强团队培训、制定有效的追溯策略等措施，可以克服这些挑战，实现有效的需求可追溯性。

在未来，随着软件行业的不断发展，需求可追溯性的重要性将更加凸显。一方面，软件系统的规模和复杂性不断增加，对需求可追溯性的要求也越来越高。另一方面，敏捷开发、DevOps等新的开发模式的兴起，也对需求可追溯性提出了新的挑战和机遇。我们需要不断探索和创新，将需求可追溯性与新的开发模式相结合，推动需求可追溯性技术的发展和应用。

建议软件组织在未来的项目中，高度重视需求可追溯性，将其纳入项目管理的重要环节。加强对需求可追溯性的研究和实践，不断提高团队的能力和水平。同时，积极参与行业标准的制定和推广，推动整个行业对需求可追溯性的重视和应用。相信在大家的共同努力下，需求可追溯性将为软件行业的发展做出更大的贡献。

下面是一个mermaid流程图，展示需求可追溯性在项目管理中的应用：

graph LR
    A[需求收集] --> B[需求分析]
    B --> C[设计开发]
    C --> D[代码实现]
    D --> E[测试验证]
    E --> F[生产部署]
    F --> G[问题反馈]
    G --> A
    H[进度管理] --> A
    H --> B
    H --> C
    H --> D
    H --> E
    H --> F
    I[风险管理] --> A
    I --> B
    I --> C
    I --> D
    I --> E
    I --> F
    J[质量管理] --> A
    J --> B
    J --> C
    J --> D
    J --> E
    J --> F
    K[成本管理] --> A
    K --> B
    K --> C
    K --> D
    K --> E
    K --> F

通过以上的介绍，我们对软件需求可追溯性有了更深入的了解。在实际项目中，我们应该充分认识到需求可追溯性的重要性，并采取有效的措施来实现它，从而提高软件项目的成功率和质量。