一，概念

  • 需求确认：在需求活动进行后，对需求活动的输出（文档或制品）、需求活动的输入(上下文因素)以及需求活动过程进行检查，看是否符合预定的质量标准或过程指南(是否适当)。
  • 需求确认需要将相关涉众、其他需求来源(标准、法律等)以及外部评审者(如果有必要)纳入活动中。
  • 确认是正确性检查，验证是正确性证明。确认的结果一般为“适当”、“不适当”；验证的结果一般为“正确”、“不正确”。
  • 由于验证主要关注表述的正确性，往往使用形式化方法，实践中更关注确认。
  • 对需求而言，如果不能确定需求是适当的，即使能证明个别属性如安全性的正确性也无意义。

二，确认的目的

  • 需求确认有三个具体目标：
    • 检查活动的输出是否满足所定义的质量准则；
    • 检查活动的输入是否满足所定义的质量准则；
    • 检查活动的执行是否遵循了过程定义和活动准则。
  • 不充分进行确认，产生的风险
    • 影响到开发活动有效开展
    • 导致法律问题或合同纷争
    • 导致额外的成本或工作量

三，制品的确认

  • 从以下三个维度进行：

    • 内容维度：检查是否所有的相关需求都被发掘了，并且理解的程度达到了要求的详细程度。
    • 文档化维度：检查记录的需求是否符合定义的文档化和规约规则。
    • 共识维度：检查涉众是否对文档化的需求达到了一致。检查每一个已知的冲突是否被解决，同时检查是否还存在未识别的冲突。

  • 内容维度的确认：检查需求内容上的缺陷。按以下准则进行：

    • 制品/文档的完备性：制品是否包含了所有相关信息
    • 需求完备性：每个需求是否包含了所有需要的信息
    • 一致性：系统是否能同时满足所有需求
    • 需求正确性：需求内容确实反应了涉众的需要和期望
    • 需求分类正确性：每个需求是否被划分到正确的类别
    • 必要性：每一个需求是否需要(满足定义的一致目标)
    • 无提前的设计决定：每个需求未规定设计或偏好
    • 可测试性：是否为每个需求定义了验收或测试准则
    • 可追踪性：是否定义了每个需求所有的相关可追踪关系，文档的链接是否正确。

  • 文档化维度的确认：检查文档化的需求是否符合通用的文档化规则和项目特定的方针。按以下准则进行：

    • 正确的文档格式：需求制品是否符合所要求的格式
    • 易理解性：文档化的需求在给定的上下文中是否容易理解
    • 无歧义：需求制品的文档格式是否保证对需求无歧义的解读？
    • 符合文档化规则：需求制品是否符合文档化的规则和指南？

  • 共识维度的确认：检查所有相关的涉众是否在最终的需求上达成了共识。针对以下方面：

    • 共识：相关涉众是否对每一项需求都达成共识？
    • 修改后的共识：在需求修改或者上下文发生改变后，相关涉众是否重新达成了共识？
    • 已进行了冲突检查：是否检查了需求中由冲突目标等造成的潜在冲突？
    • 冲突已解决：每一项需求中已知的冲突是否都已经解决了？

四，上下文确认

  • 仅检查需求制品，无法发现需求缺失方面的问题。需求缺失与不充分的上下文考虑相关。
  • 上下文缺陷主要有：
    • 上下文信息缺失
    • 不正确的上下文信息
    • 未充分考虑上下文信息
    • 不完备的需求来源
  • 上下文的四个刻面:
    • 主体刻面
    • 使用刻面：确保系统的使用方式信息、相关的用户组和他们期望的使用界面类信息，以及其他系统期望的系统使用信息，完备和正确。
    • IT系统刻面：考虑IT系统刻面各因素（硬件、软件、网络、其他相关系统），确保系统能集成到IT系统环境中。
    • 开发刻面：开发所用的方法、工具，会影响系统的开发过程。应在开发早期确认，后期无法更改。

五，活动的确认

  • 活动的确认：检查每一要求的需求工程活动是否被适当地执行。
  • 确认动机：如果遵循了已被采纳和证明有效的过程，会增强对产品质量的信心。
  • 活动确认的目标：找出活动与已约定开发过程的不一致(偏差)。这种偏差会导致需求质量的损害。
  • 过程定义以任务和活动描述定义，确认即检查过程定义相对应的执行活动是否有偏差。

六，确认的准则

  • 原则1：引入正确的涉众
  • 原则2：分离缺陷检测和缺陷修正
  • 原则3：利用多个独立视角
  • 原则4：使用恰当的文档化格式
  • 原则5：确认期间创建开发制品
  • 原则6：反复确认

七，常用技术

  • 常用技术有：审查，桌面评审，走查，基于原型的确认。
    • 审查：通过阅读、讨论、修改等，对书面材料进行质量提升的过程。(改进文档本身质量，也改进文档产生和评审的过程质量)
    • 桌面评审：比审查简单的确认方式。作者将制品发给多个涉众，让涉众在自己的桌面各自检查制品。将发现的问题直接反馈给作者，或者以小组讨论的方式收集缺陷
    • 走查：由制品作者发起的确认活动。作者在产生初始想法和建立制品草案阶段，让4个上下文刻面的参与者较早介入，以非正式的方式就有关需求达成一致。
    • 基于原型的确认：由于自然语言描述的需求文档抽象，有歧义，仅仅根据需求文档进行确认难免会有遗漏的缺陷。
  • 了基于原型确认，涉众从需求中挑选部分需求到原型中。
  • 原型越接近实际系统，得到的结果越有意义。
  • 为了控制成本，又要限制原型的功能与性能。

重点！！！

  • 需求确认是对需求输出、输入、过程进行检查的核心活动，可以发现以上三个方面的问题，改正错误，改进过程；
  • 输出即需求制品。主要从内容、文档化、共识程度三个维度检查；
  • 输入即需求上下文，主要从主体、使用、IT系统、开发四个刻面开展检查；
  • 过程即需求活动开展的方式。有无过程定义；有没有按照过程定义工作；过程有无改进。
  • 需求确认有六项可遵循的原则：引入正确的涉众；分离缺陷检测和缺陷修正；利用多个独立视角；使用恰当的文档化格式；确认期间创建开发制品；反复确认。
  • 需求确认常采用审查、桌面检查、走查、基于原型等方法。前三者主要依据文档，难免有遗漏；后者可以弥补前三者的不足，但成本高。