软件工程中的需求工程的相关概念定义

2.1 一般规定

需求工程是一种跨学科的功能，处于采购方和供应商 ¹之间，旨在建立和维护系统、软件或相关服务需满足的需求。需求工程涵盖发现、引出、开发、分析、确定验证方法、验证、传达、记录和管理需求等环节。其成果是一个需求层次结构，它能够使利益相关者（如收购方、用户、客户、运营商、供应商）达成一致理解，经过验证，符合实际需求且可实施，并为验证设计和接受解决方案提供基础。 需求层次结构可用一个或多个需求规范来表示（有关规范模板和内容，请参阅软件需求规格说明书IEEE模板 ²）。

2.2 利益相关者

从需求工程的角度看，不同项目的利益相关者 ³各异。最小的利益相关者集合由用户和收购方组成（他们可能不同）。复杂项目可能影响众多用户和众多收购方，每个用户和收购方都有不同关注点。项目要求可能需要将另外两组人纳入最小利益相关者集合。首先，开发、维护或操作系统或软件的组织有合法利益从系统中受益。其次，监管机构可能有法定、行业或其他外部要求，需要仔细分析。

2.3 将要求转化为需求

区分下这两种概念： 要求：needs。 我想要什么什么。 需求：requirements。 我需要什么已达成什么目的。

定义需求始于利益相关者的意图（称为要求、目标或目的），这些意图在成为有效的利益相关者需求之前会演变为更正式的陈述。初始利益相关者意图不作为利益相关者需求，因为它们通常缺乏定义、分析，甚至缺乏一致性和可行性。需求工程使用操作概念来帮助理解组织层面的利益相关者意图，并使用系统视角的系统操作概念，引导利益相关者从初始意图转向结构化和更正式的利益相关者需求陈述。 这些陈述格式正确，符合下文中的特征。然后，将利益相关者的要求转化为相关系统的系统需求。一致的实践表明，此过程需要通过系统设计层次结构与其他生命周期过程并行执行迭代和递归步骤。

注：可以参考 ISO/IEC 26551: 软件和系统工程 - 产品线需求工程和管理的工具和方法。

2.4 需求的制定与规范

应制定格式良好的利益相关者需求、系统需求和系统元素需求，这有助于与利益相关者进行需求验证 ⁴，并确保需求准确捕捉利益相关者的需求。

格式良好的需求陈述： - 可验证。 - 必须由系统满足或拥有，以解决利益相关者的问题或实现利益相关者的目标。 - 符合可测量的条件并受到约束。 - 定义了系统被特定利益相关者使用时的性能或系统相应的能力，但不定义用户、操作员或其他利益相关者的能力。

该描述提供了一种区分需求和这些需求的属性（条件、假设、设计决策和约束）的方法。

编写格式良好的需求的指导： 需求是翻译或表达需求及其相关约束和条件的陈述，此陈述以可以采用自然语言形式的语言编写。如果以自然语言形式表达，则该陈述应包含主语、动词和补语。需求应说明需求的主题（例如，系统、软件等）以及应做什么（例如，在功率级别上运行，提供字段）。图 1 显示了需求的示例语法。条件-动作表和用例是捕获需求的其他方法。

提前商定表示存在需求的特定关键字和术语非常重要。常见的规定如下： - 要求是强制性的约束性规定，使用“必须”。 - 事实陈述、未来性或目的声明是非强制性、非约束性条款，使用“will”。“will”也可用于建立上下文或使用限制。但“will”可能被解释为具有法律约束力，最好避免用于要求。 - 偏好或目标是期望的、非强制性、非约束性的规定，使用“应该”。 - 建议或允许是非强制性、不具约束力的规定，使用“可以”。 - 非要求（例如描述性文字）使用诸如“是”“是”和“是”之类的动词。最好避免使用“必须”一词，以免被误解为要求。

使用肯定的陈述，避免使用“不得”等否定的要求。使用主动语态，避免使用被动语态，例如“应当能够选择”。所有特定于需求工程的术语都应在系统的所有需求中正式定义和一致应用。

[条件] [主体] [行动] [客体] [约束] 示例：当接收到信号 x [条件] 时，系统[主体]应在 2 秒内[约束]设置[操作]信号 x 的接收位[对象] 。

或者

[条件] [行动或约束] [价值] 示例：在海况 1 [条件] 下，雷达系统应探测到距离[行动或限制] 100 海里[值] 范围内的目标。

或者

[主题] [操作] [值] 示例：发票系统[主题]应按升序[值]显示待支付的客户发票[操作] 。

条件： 条件是针对需求规定的可测量的定性或定量属性。它们进一步限定了所需的需求，并提供允许以可验证和核实的方式制定和陈述需求的属性。条件可能会限制设计师的选择。

将利益相关者的需求转化为利益相关者的要求非常重要，且不应对解决方案空间施加不必要的限制。

约束： 约束限制了系统工程流程的设计解决方案或实施。约束可能适用于所有需求，可能与特定需求或需求集有关系，也可能被确定为独立需求（即不限制任何特定需求）。

约束的示例包括： - 与现有系统（例如格式、协议或内容）的接口无法更改。 - 物理尺寸限制（例如，控制器必须安装在飞机机翼的有限空间内）。 - 特定国家的法律。 - 可用的期限或预算。 - 现有的技术平台。 - 用户或操作员的能力和限制。

需求可以按等级或权重排序，以表明优先级 ⁵、时间或相对重要性。场景形式的需求从用户的角度描述系统的操作。

2.5 个体需求的特征

每个利益相关者、系统和系统元素需求应具备以下特征：

• 必要： 该需求定义了一项基本能力、特性、约束和/或质量因素。若将其移除或删除，会存在缺陷，产品或流程的其他能力无法满足该缺陷。此需求当前适用，且不会随时间过时。明确标识了计划到期日期或适用日期的需求。

• 无需实施： 需求在明确系统中必要和充分的内容时，避免对架构设计施加不必要限制。目标独立于实施，说明了需要什么，而非如何满足需求。

注：此类信息虽重要，但应以其他形式文档记录和传达，如下文中的需求属性（如基本原理），以协助设计和实施。且需求中包含设计解决方案可能会忽略或消除潜在设计方案，例如陈述确切商业系统集或可购买而非制造的系统需求，陈述概念系统项目的公差，或建立不一定反映父需求的约束。

• 明确无误： 需求表述应确保只有一种解释方式，表述简单易懂。

• 一致： 该要求与其他要求无冲突。

• 完整： 需求无需进一步详述，因可衡量且充分描述满足利益相关者需求的能力和特性。

• 单数： 需求陈述仅含一个需求，不使用连词。

• 可行： 要求技术上可实现，无需重大技术进步，符合系统约束（如成本、进度、技术、法律、监管），风险可接受。

• 可追溯： 需求可向上追溯到特定记录的利益相关者需求声明、更高层级需求或其他来源（如贸易或设计研究），也可向下追溯到较低层级需求规范或其他系统定义工件中的具体需求。即需求的所有父子关系在跟踪中已识别，可追溯到来源和实施。

• 可验证： 需求有证明系统满足指定要求的手段，可收集证据证明系统能满足指定要求。需求可测量时，可验证性增强。

2.6 需求集(一组需求)的特征

需要考虑利益相关者、系统和系统元素需求集（而非任何单个需求）的某些特征，这将确保需求集共同提供满足利益相关者意图和约束的可行解决方案。每组需求都应具备以下特征：

• 完整： 该需求集无需进一步扩展，因其包含与正在指定的系统或系统元素的定义相关的所有内容。此外，该集合不含待定义（TBD）、待指定（TBS）或待解决（TBR）条款。TBx 指定的解决可能是迭代的，且 TBx 项有一个可接受的时间框架，由风险和依赖关系决定。

一些实践被推荐用于提高完整性，包括所有需求类型；考虑生命周期所有阶段的需求；并让所有利益相关者参与到需求获取活动中。

• 一致： 需求集不包含相互矛盾的个别需求。需求是不重复的，所有需求中，对同一项目使用同一术语。

• 代价合理： 在生命周期约束（如成本、进度、技术、法律、法规）内，可获得/可行的解决方案能够满足整套要求。

• 有界： 需求集维持预期解决方案的既定范围，不会超出满足用户需求的范围。

仔细检查具有这些特征的需求集和可追溯的架构设计对于避免生命周期内需求的变化和增长（“需求蔓延”）至关重要，因为这些变化和增长会影响系统的成本、进度或质量。

2.7 需求语言标准

在编写文本需求时，以下考虑将有助于确保采用良好的需求特征。

• 需求表述： 需求应该说明“需要什么”，而非“如何做”。需求应该说明感兴趣的系统需要什么，而不是包括设计决策。但是，随着需求在系统的各个层次上分配和分解，将认识到在更高层次上定义的设计决策/解决方案架构。这是需求分析和架构设计过程的迭代和递归应用的一部分。

• 避免模糊笼统的术语： 应避免使用模糊和笼统的术语。它们会导致要求往往难以甚至无法验证，或可能允许多种解释。以下是无限制或模棱两可的术语类型：

  • 最高级（例如“最佳”、“最”）
  • 主观语言（例如“用户友好”、“易于使用”、“成本效益”）
  • 模糊代词（例如“它”、“这个”、“那个”）
  • 模棱两可的副词和形容词（例如“几乎总是”、“显著”、“最小”）
  • 开放式、不可验证的术语（例如“提供支持”、“但不限于”、“至少”）
  • 比较短语（例如“优于”、“更高质量”）
  • 漏洞（例如“如果可能”、“视情况而定”、“视适用而定”）
  • 参考文献不完整（未指定参考文献的日期和版本号；未仅指定参考文献的适用部分以限制验证工作）
  • 负面陈述（例如不提供系统能力的陈述）

关于需求的所有假设都应在需求属性小节的需求属性中记录并验证（例如，理由），这些属性与需求相关联或在伴随文件中。将定义作为陈述性声明包含，而不是作为需求。

2.8 需求属性

为了支持需求分析，格式良好的需求应具有定义描述性属性，以帮助理解和管理需求。属性信息应与所选需求存储库中的需求相关联。

3.1 迭代过程和递归过程

两种过程应用形式——迭代和递归，对于应用本国际标准中定义的过程至关重要且有用。

3.2 需求工程中的迭代和递归

由于不同的利益相关者群体通常从不同的抽象层次看待系统，因此有必要在更低、更详细的抽象层次上定义和记录需求陈述，而非仅针对整个感兴趣的系统。这通过将系统需求分配或分发给系统元素来达成。把需求分配给系统元素的活动是架构设计过程的一部分，与系统架构的定义同步进行。需求分析和架构设计过程之间可能会有多次迭代，以解决需求和架构之间的权衡。

架构设计的主要目标之一是确定如何划分系统，即明确应将哪些需求分配给哪些系统元素。在定义系统元素时，应创建其他需求陈述（称为派生需求），用于定义系统架构元素之间的关系，在系统元素的较低抽象级别上下文中提供必要的清晰性，或者指定系统元素的设计约束或性能级别。这通过需求分析过程的递归应用来实现。

此外，有些需求只有在架构或设计的某部分发展之后才能得出。一些需求取决于多个系统元素的交互。例如，系统的信息吞吐量取决于系统硬件、软件、人员操作和环境的交互。需求分析和架构设计过程的递归和迭代应用可用于捕捉这些需求。

即使在需求工程资源充足的情况下，分析水平也很少统一应用。

例如，在需求分析过程早期，经验丰富的工程师通常能确定现有或现成的解决方案在哪些方面可适应系统元素的实施。分配给这些需求的可能需要较少分析，而其他解决方案不明显的需求可能需要更详细的分析。关键需求，即具有高风险或影响公共安全、环境或健康的需求，应始终进行严格分析。