一，需求管理目标

  • 作为横切活动的需求管理，包含了三个方面的目标：
    • 观察系统上下文，以侦测系统上下文的变化；
    • 管理需求工程活动的执行
    • 管理需求制品

二，管理系统上下文

  • 系统上下文是需求的来源。
  • 管理系统上下文主要是观察其有无变化。目标是发现上下文变化并估计其影响，在需求中反映这些影响。
  • 观察上下文的技术:
    • 上下文扫描：系统地查找上下文环境中的变化。这些变化或周期性的，或偶发的。
    • 上下文监控：通过不断记录上下文的演化过程达成。包含记录和解释上下文的变化。
    • 上下文预测：在上下文扫描和上下文监控的基础上，根据当前知识和历史情况得到与未来上下文发展有关的信息。
  • 结构化的上下文观察：区分4种上下文刻面的观察。包括主题刻面的观察，使用刻面的观察，IT系统刻面的观察，开发刻面的观察
  • 上下文中所有需求来源、上下文对象、上下文对象的属性和关联都可能发生变化：
    • 需求来源变化：上下文中可能会出现新的需求来源，这就可能出现新的需求，或已有需求的变化
    • 上下文对象的变化：一个已知的上下文对象会发生变化，或者会出现一个新的上下文对象
    • 上下文对象属性与关系的变化：二者都可能变
  • 上下文观察要针对具体情境选择合适的观察技术。

三，管理需求过程

  • 需求工程过程的活动顺序，不是固定不变的。
  • 需求工程活动的管理旨在监控、控制并调整由获取、文档化、协商和确认活动组成的工作流程。为此需要用到项目管理技术。
  • 管理方法有两种：
    • 面向阶段的方法：对所有需求制品采用相同的活动顺序；
    • 情景方法：根据对已有需求制品的当前状态的评估来决定下一步要执行的活动。

1.面向阶段的方法

  • 面向阶段的方法将需求工程活动包含在一个带有反馈环的瀑布模型中，原则上顺序执行。这种方式仅适用于待开发的系统与以前的系统相同或相似时。

    反馈环

  • 如果所有需求制品都通过了确认，则整个过程就结束了。这种方法只能在已很好地理解了领域或系统的情况下使用（即绝大部分需求以前已获取并文档化过）。

  • 对于没有经验的系统，或者需要采用创新解决方案时，面向阶段的方法并不适合。

2.情景方法

  • 情景方法根据需求制品的状态及当前的过程情况，决定下一步执行哪个活动。

  • 情景方法旨在通过内容、共识和文档化这3个维度来确定需求工程活动的执行顺序，从而得到最好的执行路径。(为了防止开展进展很小，或没有实际进展的活动)

  • 情景方法分为两个步骤:

    1. 需求制品的评估

      为了减少个体主观因素差异，按以下表格从内容、文档化、共识三方面评价制品：

      +（无缺陷） 0（较小缺陷） -（重大缺陷）
      内容(完备，无歧义，通用) 制品符合定义的标准 制品不符合某些定义的标准 制品不符合大部分定义的标准
      文档化/规约(是否与给定的文档化/规约规则一致？) 制品符合定义的文档化/规约规则 制品符合定义的文档化/规约规则 制品违反了大部分定义的文档化/规约规则
      共识 对制品达成一致，即不存在未解决的、已知的冲突 制品中存在相关的、未解决的冲突 制品中存在相关的、未解决的冲突

      按照上表给每个需求制品从三个方面分配一个评估值。

    2. 决定下一步执行的活动

      • 根据上一步的评估，可以决定下一步活动。
        • 如果在三个维度没有明显缺陷，就执行确认活动
        • 一个维度上的重大缺陷比另一个维度上的较小缺陷具有更高的优先级
        • 一个维度上的较小缺陷比另一个维度上的没有缺陷具有更高的优先级；
        • 如果多个维度上的评估结果相同，则内容维度的优先级高于文档化维度，文档化维度的优先级高于共识维度。
      • 在内容方面推进。如果文档化和共识维度具有相同程度的缺陷，文档化维度的优先级要高于共识维度。

3.两种方法比较

  • 面向阶段的方法不够灵活，适用于业务熟悉、有开发经验的系统，简单易行；
  • 情景方法更加灵活，为需求制品开发提供了迭代方法。适用于开发创新性需求或上下文不熟悉的系统的需求，适应这类系统常见的、快速的变化。所需资源略多。

4.管理需求制品

  • 需求工程活动会获取大量需求制品。每一个需求制品都有特定的属性，并与其他需求制品和设计、测试制品关联。

  • 管理需求制品的目标是持续追踪所有需求制品、这些制品的相关属性和关联、它们的演化情况等。

  • 管理需求制品的5项子任务：

    • 需求属性的定义：需求属性是对需求的描述
    • 维持需求可追踪性：需求应该既能追踪到源头，也能追踪到其精化和实现，此外还要关联到确认和质量保证所用相关制品。
    • 需求变更管理：需求在开发过程中不可避免要发生变化。需求变更管理应该保证以系统化的方式处理变更，并且将变更一致地集成到已有的需求制品。变更管理需要需求具有可跟踪性。
    • 需求配置管理：需求制品的版本会不断演化。需求制品的一个配置将相互关联的各种需求制品的不同版本进行组合。配置管理可避免配置项的错误搭配。
    • 需求优先级排序：为了保证各种需求制品消耗与其重要性一致的资源，需要给需求制品排优先级。

    4.1可跟踪性支持

    • 需求管理的一项本质任务是在整个开发过程中支持需求的可跟踪性。
    • 可追踪性状态影响了所开发系统的质量。
    • 可追踪性包括：
      • 前可追踪性：一个需求制品与其前驱制品(上下文刻面的需求来源)之间可追踪；
      • 后可追踪性：一个需求制品到其后继制品（详细设计、代码等）可追踪。
    • 制品之间存在的可追踪关系，通常可按条件、内容、抽象、演化、杂项等5种大类分成20多个小类。
    • 可以在描述需求文档中，注明需求之间的追踪关系（通过引用参考、链接等）；也可以使用图、表说明需求制品之间的追踪关系。
    • 为了在特定的项目中管理需求制品的可追踪性，需求工程师要定义本项目的可追踪性模型，制定可追踪性信息记录策略和使用策略。(需要使用大量的项目资源，在敏捷开发或小型项目中不适合采用)实际上，上下文——需求——实现之间的追踪性，可以通过设计和实现方法（如面向对象的软件工程方法）的特点自然达成

    4.2设置需求优先级

    • 优先级排序的结果，可以是量化的顺序，也可以是有限等级（类别）。
    • 需求的优先级决定需求被处理或实现的顺序。
    • 定义需求的优先级要做好以下四项准备活动：
      • 确定需要涉及的涉众
      • 选择进行优先级排序的制品
      • 定义将使用的优先级排序标准
      • 选择合适的优先级排序技术

    4.3配置与变更管理

    • 配置管理是对需求的各种制品及各制品的不同版本进行组合、跟踪，以管理需求制品的不断演化，避免混乱。配置管理基于版本管理。

    • 可以从制品维度和版本维度理解配置管理。

      • 制品维度中，配置管理考虑不同的需求制品；
      • 版本维度中，管理制品的不同变更状态。

    • 需求的配置管理可以从文档层、制品层或属性层进行。层次越低越复杂，工作量越大。

    • 版本、配置和基线是配置管理的基本概念

      • 版本：需求制品或软件产品的一个已定义状态。版本通过一个唯一的编号标识。编号由版本号和增量号构成。
      • 配置：特定版本的一组相关的制品组成了一个配置。配置具有唯一标识；配置中的各制品具有一致性；
      • 基线：一个稳定的配置即基线。基线一般是一个发布版本，对客户是可见的。而一般的配置是内部的，外部客户不可见。基线是变更管理的主体。因为基线所包含的配置项不可随意更改，所以进行变更管理。

    • 初期需求活动产生的需求制品还不稳定，变更可以相对自由地进行；

    • 如要变更基线所包含的配置项，则必须依照单位或项目组定义的变更管理流程进行。

    • 为了执行变更管理，必须成立由相关涉众和决策人员代表组成的**“变更控制委员会”**。委员会履行对变更的控制和决策职责。

    • 为了有效管理，变更请求必须文档化。一般按照变更请求模板（可自行定义或裁剪）写变更请求。

    • 变更控制委员会或其成员按照以下流程处理变更请求：

      1. 对变更请求分类；
      2. 对变更请求做影响分析；
      3. 评估变更请求。如果决定拒绝，则转6.结束；
      4. 对接受的变更请求作优先级排序；
      5. 监控变更的执行和集成；
      6. 结束。

    重点！！！

    • 需求管理包括对需求上下文监控、需求过程管理和需求制品的管理。
    • 上下文监控主要关注需求来源变化、上下文对象的变化、上下文对象属性的变化。
    • 需求过程管理主要关注需求活动的先后顺序。可以用瀑布模型，也可以基于情景判断。
    • 需求制品的管理主要关注需求属性的定义、需求可追踪性支持、需求变更管理、需求配置管理、需求优先级排序。

​