| 需求工程:基础、原理和技术8 |
| 波尔(Klaus Pohl) |
| 计算机科学丛书 |
| 27：需求确认基础、30：需求管理基础、31：需求的可追踪性、32：需求优先级 |
第27章 需求确认基础
27.1 动机和目标
为了检查需求制品的质量，应将这些制品反馈涉众，请他们就这些制品进行沟通，以检查出文档化的需求与涉众真实需求与期望之间的偏差。
需求制品质量检查的一个重要结果就是决定是否将所检查的制品进行发布并供后续的开发活动使用。应当基于之前所定义的验收准则决定需求制品的发布。
27.1.1确认的目标
确认活动包含3个子目标。
❑目标1：检查活动的输出是否满足所定义的质量准则。意味着需要通过检查所创建的需求制品来发现需求缺陷。
❑目标2：检查活动的输入是否满足定义的质量准则。
❑目标3：检查活动的执行是否遵循了过程定义和活动准则。
27.1.2不充分确认的风险
需求的缺陷会影响到这些开发活动。如果一个需求中的缺陷直到系统的发布阶段才被检测到，那么所有的相关制品（需求制品、设计制品、源代码、测试制品和用户手册）都需要进行修正。
需求确认会导致需求工程过程额外的工作量。也会降低后期开发阶段因需求缺陷而带来的成本和风险
尽早地在需求制品中检测和修正错误可以避免在后期开发阶段中缺陷修正所带来的巨大成本。
27.2确认vS.验证
27.2.1构造性质量保障和分析性质量保障
❑构造性质量保障；构造性质量保障是指在开发制品创建时使用一些技术。
❑分析性质量保障：分析性质量保障是指应用一些技术检查一个已创建的开发制品的质量。
需求确认是一种特定类型的分析性质量保障手段。
27.2.2 确认和验证的定义
❑确认（validation）：我是否在构造正确的系统？
❑验证（verification）：我是否在正确地构造系统？
❑验证有两种类型的基本答案：正确和不正确。
❑确认的两种基本答案是：适当和不适当。不适当的结果揭示了“第三类错误”，即所问的问题是错误的、所使用的方法是错误的，或者所实现的系统提供的结果不是人们所希望的。
27.2.3本书所使用的术语“确认”
定义27-1：（需求工程中的）确认
确认是指检查需求工程核心活动的输入、执行的活动和所创建的输出（需求制品）是否符合所定义的质量准则。确认的执行需要将相关涉众、其他需求来源（标准、法律等），如有必要还有外部评审者，纳入进来。
需求验证的任务是检查一个系统需求模型表述的正确性。验证的结果是对需求表述的确认或质疑。验证允许涉众形式化地证明所期望和要求的属性，并由此得出关于待开发系统属性的结论。
提示27-1：术语“确认”和“验证”的使用
❑当说到术语“确认”或“验证”时，确定其到底是指哪一个。
❑我们建议专门使用术语“验证”指代形式化的（数学）证明。
27.3子活动：确认所创建的需求制品
❑内容维度的确认：检查是否所有的相关需求都被了解了，并且理解程度达到了要求的详细水平。
❑文档化维度的确认：检查记录的需求是否符合定义的文档化和规约规则。
第30章 需求管理基础
30.1 管理活动的目标
“需求管理”这个术语是指在需求工程过程中的管理活动。
必须达到至少3个目标：
❑管理需求工程制品：在需求工程过程中所文档化的需求制品需要被合适地管理。
❑管理（观察）系统上下文：观察系统上下文，发现相关的需求变更，并建议执行合理的活动来调整需求工程过程和/或需求制品，从而应对上下文环境的变化。
❑管理需求工程过程：定义下一步要执行的需求工程活动（需求抽取、文档化、协商、确认等）。即管理过程需要不断地监测需求工程过程，并在有需要的情况下调整已定义的工作计划。
另外，在开发软件产品线的情况下，必须管理软件产品线中需求的可变性。
30.2 定义
定义30-1：需求工程中的管理
管理是两个横切的需求工程活动之一。
需求工程中管理的目标是：
（1）观察系统上下文以侦测上下文变更。
（2）管理需求工程活动的执行。
（3）管理需求制品。
30.3 管理需求制品
每一个需求制品都会有特定的属性，并且会关联到其他的需求制品，以及设计和测试制品。
目标在于持续追踪所有的需求制品，这些制品的相关属性和关联，以及它们的演化情况。
该活动由5个主要的子任务组成：
❑需求属性规范的定义：属性记录了需求有关的信息。通常还包括管理属性。
❑需求的可追踪性：当一个需求能被追溯到其源头以及被追溯到其精化或实现时，那么可以认为该需求是可追踪的。
❑需求变更管理：需求的变更管理应该保证以系统化的方式处理这些变更，并且将变更一致地集成进已有的需求制品。
❑需求配置管理：配置管理基于版本管理，用来管理需求制品的不断演化。一个需求版本可以确定在某个时间点上对需求制品的定义。一个配置将相互关联的各种需求制品的不同版本进行组合。
❑需求的优先级排序：为了保证每个需求能够用到与其（相对）重要程度相匹配的资源，需要赋予被记录下的需求优先级。
30.4 观察系统上下文
该子活动的目标在于发现上下文中的变更并估计其影响。系统上下文中的变更必须在需求工程中被明确地指出来。
30.4.1 观察上下文的技术
技术包括：
❑上下文扫描：上下文扫描表示系统化地查找系统环境中的变化，
❑上下文监控：上下文监控基于不断地记录上下文的演化过程。
❑上下文预测：上下文预测建立在上下文扫描和/或上下文监控的结果之上。其目标在于根据上下文的当前知识以及历史变化情况来得到与未来上下文开发有关的信息。
30.4.2 结构化的上下文观察
上下文观察的一个主要困难在于要尽可能早地检测并分析在4个上下文刻面中的变化。
上下文刻面中的变化包括：
❑需求来源的变化：上下文中可能会出现新的需求来源。
❑上下文对象的变化：一个已知的上下文对象会发生变化，或新的上下文对象。
❑上下文对象属性与关系的变化：一个上下文对象的属性或不同上下文对象间的关系可能一发生变化。
30.5 管理需求工程活动
需求工程活动的管理旨在监控、控制并调整由抽取、文档化、协商和确认活动所组成的计划流程。需要应用项目管理中的已有技术。
管理需求工程活动的方法分为两种：面向阶段的方法和情境方法。
在面向阶段的方法中，对所有的需求制品都采取相同的活动顺序。
而情境方法是根据对已有需求制品的当前状态的评估来决定下一步要执行的活动。
30.5.1 面向阶段的方法
需求工程活动被包含在一个有反馈环的瀑布过程模型中，原则上被顺序地执行。
①抽取活动的主要来源是以前项目的需求文档（注意：只有在系统需求与以前项目的需求在很大程度上相似的情况下才能使用面向阶段的方法）。需求管理为记录抽取出的需求以及为活动的执行提供合适的结构。
②遵从特定项目的规则可以保证使用合适的需求格式详述需求，以支持后续的开发活动。
③需要检查是否所有的相关涉众都同意已文档化的需求。如果发现冲突，就着手解决。
④需求制品的确认要考虑内容、文档化和共识这三个确认方面。
**注：以上任何一步，如发现问题，包括抽取来源有变化、文档结构不正确、无法达成共识、冲突不能解决、无法完成确认步骤，都可以按反馈环退回到发生问题的步骤上。解决问题后再依次执行过程。如此反馈迭代，以解决全部问题，最终达成需求共识的确认。
唯有在很好地理解了领域和系统的情况下，即唯有在绝大部分的需求之前已经知道并定义的情况下，才可能会依照以上所概述的过程来顺序执行这些活动。
30.5.2 情境方法
在情境方法中，下一步要执行哪个活动是根据对（一组）需求制品的评估决定的。下一步要执行的活动取决于需求制品（即单个需求制品或制品的同构子集，如拥有相关的交互场景的系统目标）的状态以及当前的过程情况。
情境方法旨在通过内容、共识和文档化这3个维度来确定需求工程活动的执行顺序，从而得到最好的执行路径。
需求制品的评估
需求制品是从3个质量方面（内容、共识和文档化）被评估的。
每个质量维度分配以下3个值中的一个：
❑“+”：没有缺陷；
❑“0”：较小缺陷；
❑“-”：重大缺陷。
建议通过考虑特定项目和特定产品的特性，更详细地指定这些标准。定义的标准越详细，评估越精确。
需求制品的评估标准
| + | 0 | – | |
| 内容样本标准：（1）完备性（2）无歧义性（3）通用性 | 制品符合定义的标准 | 制品不符合某些定义的标准 | 制品不符合大部分定义的标准 |
| 文档化/规约需求的文档化/规约是否与给定的文档化/规约规则一致？ | 制品符合定义的文档化/规约规则 | 制品违反了某些定义的文档化/规约规则 | 制品违反了大部分定义的文档化/规约规则 |
| 共识 | 对制品达成一致，即不存在未解决的、已知的冲突 | 制品中存在相关的、未解决的冲突 | 对制品未达成一致（或存在未知状态，或存在重大的开放冲突) |
如果不同的涉众对相同的需求制品进行评估，结果往往互不相同。
决定下一步执行的活动
基于考虑了3个质量方面（内容、共识和文档化）的（一组）需求制品的评估，就能比较客观地挑选下一步要执行的活动。
表（上）中的建议基于以下规则：
1.如果需求制品在3个维度上（内容、文档化和共识）没有明显的缺陷，就执行确认活动。
2.一个维度上的重大缺陷比另一个维度上的较小缺陷具有更高的优先级。
3.一个维度上的较小缺陷比另一个维度上的没有缺陷具有更高的优先级。
4.如果多个维度中的评估结果相同，内容维度的优先级高于文档化维度，文档化维度的优先级高于共识维度。
如果不确定下一步该执行哪个活动，就应该先进一步理解需求，即内容。如果文档化和识维度具有相同程度的缺陷，文档化维度的优先级要高于共识维度，这是因为合适的文档化支持了对冲突的检测。而如果需求没有被很好地文档化，也不可能检测冲突。
30.5.3面向阶段的方法与情境方法的比较
情境方法可以为一个系统或子系统的软件制品开发提供一种更为迭代的方式。
当必须开发创新性的需求和/或涉众对系统类型或上下文不熟悉时，情境方法可以应用于这些情况所产生的常见的、快速的变化。
**注：因此，在进行需求管理过程中，除非时间节点严格，或之前有相似内容项目开发经验，可以使用过程阶段管理的方法。其他条件下，采用情境方法更适合于在新项目和面对新内容环境中的快速发现问题和解决问题，抽取需求知识，针对性达成共识的迭代过程。
第31章 需求的可追踪性
31.1 可追踪性的基础
需求管理的一项本质任务是在整个开发过程中支持需求的可追踪性。
术语“可追踪性”
指在不同开发制品间能够建立起一种关系的程度，特别是与其他制品间存在前驱-后继或主-从关系的制品。
定义31-1：需求可追踪性
“需求的可追踪性是指在前向与后向两方面描述并密切注意一个需求的生命的能力（例如,从一个需求的起源开始，经历对该需求的开发和规约化，到随后对其的部署和使用，以及贯穿所有时期的持续精化和在任何此类阶段中的迭代)。”
需求可追踪性的动机
被记录下来的需求的可追踪性信息可以支持不同的系统开发活动。
| 方面 | 可追踪性 |
| 可检验性和验收 | 可追踪性支持对一个需求在系统实现阶段是否被（正确地与完整地）考虑到的确认。 |
| 镀金 | 可以揭示出在需求中没有被详述的系统功能或质量。对这些功能和质量的开发与集成被称为镀金。也可以揭示对存在没有合理解释的需求。 |
| 变更管理 | 在一次变更情况下，可追踪性容许分析一次变更会影响到哪些其他制品 |
| 质量保障、维护和修理 | 可追踪性便于识别错误的原因和影响，识别由一个错误所影响到的系统部分，并预测为修正这个错误所需的工作量 |
| 再工程 | 通过将遗留系统的功能关联到新系统的需求，并通过记录新系统的哪些构件实现了这些需求 |
| 复用 | 当一个需求（集合）在新系统中被复用时，在老系统中实现该需求的相应制品也可以被识别出来。可以检查它们是否需要改写或者无须改写就可以用于复用 |
| 项目可追踪性 | 可追踪性信息支持跟踪项目和当前项目的状态 |
| 风险管理 | 通过识别被一个风险或威胁所潜在影响的开发制品，需求和其他制品（如，构件）之间的可追踪性能够支持风险管理 |
| 可计量性 | 可以用于对单个的需求分配开发工作量 |
| 过程改进 | 可追踪性信息可以被用于回溯开发过程中的问题直至其起因。改进动作的计划和执行可以以消除问题的实际起因为目标。 |
31.2 需求的前可追踪性和后可追踪性
前可追踪性确保个需求可以追踪至它的来源或起源。
后可追踪性确保了需求可以追踪至诸如设计和实现一类的制品。
扩展的前可追踪性和后可追踪性
需求的前可追踪性包含从需求制品（即目标、场景、面向方案的需求）到4个上下文刻面中方面的联系。
需求的后可追踪性包含需求制品与它们的后继制品之间的关系。
扩展的需求前可追踪性和后可追踪性包括了不同需求制品间的可追踪性。
31.3 可追踪性关系类型
可追踪性信息通常以可追踪性关系的形式被记录下来。两个开发制品间可以存在着不同类型的可追踪性关系（可追踪性链接）。
几种可追踪性关系类型的建议：
❑需求制品和后继制品，例如派生出的需求或体系结构构件之间的可追踪性。
❑记录着涉众对需求以及初始需求产生贡献的贡献结构，因而也记录了一个需求为何存在的原因。
❑设计决策、替代方案和根本假设的可追踪性。
❑过程执行的可追踪性，即执行单独过程步骤的参与者与工具的文档、单独的过程步骤的输入和输出，以及执行过程步骤的顺序。
可追踪性类型的5种分类：
❑条件（Condition）。
❑内容（Content）。
❑抽象（Abstraction）。
❑演化（Evolution）。
❑杂项（Miscellaneous）。
31.3.1 条件
用于记录一个（需求）制品为另一个（需求）制品所定义的约束。
属于“条件”分类的可追踪性关系类型
| 关系类型 | 描述 |
| 约束 | 这类从制品A到制品B的关系记录了制品A对制品B所定义的一个约束。 |
| 前置条件 | 这类从制品 A到制品B的关系记录了在制品B被实现之前必须被满足的由制品A所定义的条件。 |
31.3.2 内容
记录相关的需求制品内容之间的、或需求制品与开发过程中的其他制品之间的依赖。
属于“内容”分类的可追踪性关系类型
| 关系类型 | 描述 |
| 相似 | 记录了两个相关制品在内容上是相似的。 |
| 对比 | 表示制品之间进行比较的结果。 |
| 矛盾 | 记录了无法一起实现的两个制品，指示着在需求制品中存在着不一致。 |
| 冲突 | 从制品A到制品B的这种类型的关系记录了A的实现可能阻碍（但并不排除）B的实现。 |
31.3.3 抽象
表示需求制品之间抽象依赖的可追踪性关系类型所组成。
属于“抽象”分类的可追踪性关系类型
| 关系类型 | 描述 |
| 分类 | 一个制品 A与一个制品集合B…Bn之间的这种类型的关系记录了用A对B…Bn所进行的分类 |
| 聚合 | 一个关系记录了一个制品A是其他制品B…Bn集合的聚合 |
| 泛化 | 一个关系记录了一个制品是（一个或）若干其他制品的泛化 |
31.3.4 演化
记录了需求制品之间、或需求制品与其他开发制品之间的一种时序关系。
属于“演化”分类的可追踪性关系类型
| 关系类型 | 描述 |
| 替换 | 从一个制品A到一个制品B的这种类型的关系记录了制品B被制品A所替换 |
| 满足 | 从一个制品A到一个制品B的这种类型的关系记录了如果制品A在系统中被实现，那么制品B也可以被实现 |
| 基于 | 从一个制品B到一个制品A的这种类型的关系记录了制品A已经影响到制品B的定义 |
| 形式化 | 从一个制品A到一个制品B的这种类型的关系表示A是制品B的一种形式化记录 |
| 精化 | 制品A定义了制品B的更多细节 |
| 派生 | 需求制品A是基于一个（组）其他制品所派生出的 |
31.3.5 杂项
其他的开发制品之间所定义的可追踪性关系类型
属于“混杂”分类的可追踪性关系类型
| 关系类型 | 描述 |
| 示例 | 记录了一个制品包含一组制品的示例方面 |
| 验证 | 将一个制品（例如，一个测试制品）关联到一个需求制品上。前者用于验证或确认该需求制品 |
| 依据 | 表示一个制品记录了另一个制品存在的理由 |
| 负责 | 记录了一个涉众（或一个角色）对相关的制品负有责任 |
| 背景 | 用于把“背景信息”指定给一个需求制品 |
| 注解 | 用于将任何一种信息关联到一个需求制品上 |
31.4 文档化可追踪性关系
可追踪性关系可以用不同的方式被文档化。使用定义可追踪性关系结构的专用的信息模型对可追踪性关系进行文档化。
31.4.3 可追踪性模型
使用一个信息模型用来定义和构建可追踪性信息和关系类型。
抽象类“可追踪的制品”，该类被项目中的不同制品类型所特化。称为“目标”、“场景”和“面向方案的需求”。
类“可追踪性关系”是所有可追踪性关系类型的一个超类。它被特化为子类“条件”、“内容”、“抽象”、“演化”和“杂项”，以表示在31.3节中所描述的不同的可追踪性关系类型的分类。
通过两个表示可追踪性关系的来源与目标的关系，类“可追踪性关系”能够与类“可追踪的制品”相关联。模型中定义的基数允许定义一组来源制品与一组目标制品之间的可追踪性关系。
31.5 可追踪性信息的表示
可追踪性矩阵
需求制品之问或需求制品与前驱或后继制品之间的可追踪性信息可以使用可追踪性矩阵来展示（可视化）。
行表示在这个矩阵中所考虑到的来源制量，而可追踪性矩阵的列代表着目标制品。
在实践中，由于存在大量的需求，用于可视化可追踪性信息的可追踪性矩阵的使用受到一定的限制。
可追踪性图
在一个可追踪性图中，结点代表制品而边代表制品之间的可追踪性关系。
在可追踪性图的基础上，可以派生出局部图。
一个特定的制品类型（或一组具体的制品）可以用于导出一个局部图。
按照特定的路径对可追踪性图进行分析，这些路径由多个结点和边组成。这种分析方法揭示了由逻辑上属于一起的制品（由可追踪性关系链接起来）所组成的一条路径。
可以派生出一个跨越整个制品生命周期的、完整的可追踪性图。
通用的需求管理工具在创建可追踪性图时容许选择一个搜索深度。
31.6 特定项目的可追踪性
一个特定项目的可追踪性环境的图解
需求工程师在系统开发期间定义了特定项目的可追踪性模型（TM）以及可追踪性信息的记录策略（RS)和使用策略（US)。待记录的可追踪性信息（TI）从可追踪性使用策略中导出，即对每一个可追踪性使用的类型，可识别出特定用途所需的可追踪性信息。最终，所需要的可追踪性信息的结果被集成到一个一致的可追踪性模型（TM）中。
在开发过程中，开发团队的成员在遵循记录准则的情况下记录所定义的可追踪性信息(TI)。依照使用策略的准则，在开发过程中可访问所记录的可追踪性信息（TI)。类似地，开发团队依据可追踪性使用准则（US）使用已定义的可追踪性信息。
为了创建一个特定项目的可追踪性环境，需要定义如下元素：
❑使用策略(US)：使用策略定义了在系统开发期间以及整个系统的生命期间可追踪性信息的预期用途。每一个使用策略需要一种为每个策略所明确定义的可追踪性信息的类型。
❑可追踪性模型(TM)：可追踪性模型定义了待记录的可追踪性信息的类型。
❑记录策略(RS)：记录策略定义了为哪一个活动必须记录哪种类型的可追踪性信息，以及谁应当负责记录这类信息。
31.6.2 可追踪性信息的使用策略
涉众定义使用场景以描述可道踪性信息应当在何种情况下被使用，以及应当如何被使用。
它在系统开发期间定义了可追踪性信息的预期用途。
使用策略应定义:
❑在何种情况下（何时？）；
❑使用了哪一个可追踪性信息（什么？)；
❑通过谁，即哪一个角色或代理人（谁?)；
❑执行了哪一个活动（为了什么？）。
31.6.3 特定项目的可追踪性模型
符合特定项目的可追踪性使用策略的可追踪性信息应该在特定项目的可追踪性信息模型中被定义。
可追踪性元模型定义了用于一个特定项目的可追踪性模型的模型元素。
31.6.4 可追踪性信息的记录策略
依赖项目目标与可用资源，可定义为了记录可追踪性信息的特定项目的策略。
❑在何种情况下（何时?);
❑记录了哪一个可追踪性信息（什么?);
❑通过谁，即哪一个角色或代理人（谁?);
❑用哪种方式（如何？）。
提示31-1：记录可追踪性信息
当可追踪性信息发生时就记录下来。换句话说，不要将可追踪性信息的记录推迟到后续的处理步骤中。不要在事后尝试着构建可追踪性信息。
如果该信息在以后被记录，那么关于可追踪性信息的很多方面就不再显而易见，或者记录可追踪性信息的工作会因其他具有更高优先级的任务而被忽略掉。
31.6.5 涉众准则
特定项目的可追踪性模型与特定项目的记录和使用策略为在开发项目时记录与使用可追踪性信息提供了全面的准则。我们区分出两类基本的涉众准则：
❑特定项目的可追踪性手册。
❑集成过程的涉众准则。
理想情况下，可以得到支持记录与使用可追踪性信息的集成的涉众准则。在此情况中，可追踪性信息在集成过程环境的过程步骤（或开发活动）执行时被记录和被使用。
第32章 需求优先级
32.1 需求优先级排序的基础
为了保证被限制的资源能充分用来实现尽可能重要、尽可能完整的需求，已记录的需求通常应进行优先级排序。
需求被分为不同的优先级，根据优先级标准表示一个需求的重要程度。
定义32-1:需求的优先级
需求的优先级刻画了在一个或多个优先级排序的标准下一个需求的重要性。需求的优先级 可以被单独确定，也可以经过成对地比较后确定。
每个需求都被指定了一个优先级等级(类)。在这个优先级类中，不再进一步地定义排名或顺序。
需求工程中的优先级排序
对需求进行优先级排序，以决定需求被执行的次序。
对于5个需求工程活动，需求可以以如下方式进行排序：
❑抽取：在需求抽取阶段，优先级可以决定哪些需求应该在下一阶段被详细说明，或者决定哪些需求来源(如涉众)应该被首先考虑。
❑文档化：在需求文档化阶段，用优先级来决定需求为了满足预先定义的文档化规则与格式而被记录的次序。
❑协商：在协商阶段，发生冲突的需求以它们对项目成功的影响大小而进行优先级排序。利用优先级首先解决那些最为重要的需求的冲突。
❑确认：在需求确认阶段，利用优先级决定需求被确认的次序，或者定义已发现缺陷被解决的顺序。
❑管理：在管理阶段，利用优先级排序定义哪些变更请求应该被首先处理。
32.2 优先级排序的准备活动
一组需求的优先级排序总是应由一个清晰的目标所指导，并涉及所有的相关涉众。
在定义需求的优先级之前应该执行以下4个准备活动：
❑确定在需求优先级排序中所需要涉及的涉众;
❑选择进行优先级排序的制品;
❑定义将使用的优先级排序标准;
❑选择合适的优先级排序技术。
32.2.1 确定涉众
一般而言，开发团队、项目管理、顾客/用户和质量保证团队都至少有一个代表参与到优先级排序过程中。这些涉众拥有对项目上下文的特殊知识，这些知识在需求优先级排序过程中必须独立于排序标准而被考虑到。
32.2.2 选择将要排序的制品
目标、场景和面向方案的需求。
当选择需求制品进行排序时，推荐只使用相同类型的需求制品。
对不同抽象层次需求的优先级联合排序常常导致错误的排序结果
推荐(在同一次排序活动中)只对同一类型并且定义在几乎相同的抽象层次中的需求制品进行排序。
一个已被验证的策略是从高抽象层的需求开始排序。
32.2.3 选择优先级排序标准
对需求制品进行优先级排序时可以考虑多种可能的准则。
| 表32-1 需求制品优先级排序的通用标准 | |
| 标准 | 解释 |
| 重要性 | 一个需求的“重要性”标准涉及多个方面，例如实现该需求的紧迫性，需求对系统验收的重要性，需求对体系结构设计的重要性，或者与组织的市场定位有关的需求的策略重要性 |
| 成本 | “成本”标准指完成需求所需的财政资源。这些成本明显依赖于需求制品的复杂程度，可能的复用程度，或者与该需求相关的文档和质量保证活动的程度 |
| 损害 | “损害”标准指忽视需求所带来的损失或者缺陷的程度。这些发生的损害能够导致对违约的惩罚，降低系统在市场中的销售势头或者丢失信誉 |
| 持续期 | “持续期”标准指实现需求所需花费的时间。持续期显式地考虑了开发活动并行的可能性 |
| 风险 | “风险”标准指实现需求时带来的风险。风险可以基于其发生的概率和所带来的损害来评估。使用 “风险”标准时，尽可能详细地定义在排序中所要考虑的风险是非常重要的。例如，超出时间表的风险，未满足顾客需求的风险，系统低性能的风险，或者项目失败的风险 |
| 动荡性 | “动荡性”标准指在开发期或者系统生存期中，需求发生变更的可能性。需求的高动荡性通常会增加开发成本，例如，由于系统体系结构必须要具备足够的可扩展性以适应以后的变化(见[Lauesen 2002;Sommerville 2004])。另外，也应该考虑整合变更所需的工作量。在这种情况下，动荡性和工作量的组合 (即变更的可能性和这个变更导致的损失)定义了一个风险标准 |