3.1 引出利益相关者的要求

此活动包括以下任务： 1. 确定在系统整个生命周期中拥有合法利益的个人利益相关者或利益相关者类别。 注：包括但不限于用户、操作人员、支持者、开发者、生产者、培训人员、维护人员、处置者、采购方和供应商 ⁶组织、负责外部接口实体或支持系统的各方、监管机构和社会成员。当无法直接沟通时（例如，对于消费产品和服务），将选择代表或指定的代理利益相关者。

最好先确定系统生命周期的所有阶段，然后确定在整个生命周期中对系统具有合法利益的单个利益相关者或利益相关者类别。从利益相关者那里获得的需求将取决于利益相关者在组织中的角色 ⁷、职责和地位。确定对所需产品或服务具有角色或利益的所有利益相关者类别。然后确定那些对目标、战略、运营和目标系统有重大影响的利益相关者。随着对所需产品或服务的了解越来越多，利益相关者类别列表通常会随着时间的推移而修改。应确定每个利益相关者类别的代表，并包括多层次的观点。仅从一个利益相关者类别或一个层次收集的信息可能会从单一角度产生偏差。需要有代表性的利益相关者横截面来提供“待解决问题”的真实情况。

2. 从已确定的利益相关者处获取利益相关者的要求。 注：利益相关者需求描述了已确定的利益相关者的需求、愿望、期望和感知到的约束。它们以文本或正式的模型来表达，该模型专注于系统目的和行为，并在运行环境和条件的背景下进行描述。产品质量模型和质量要求（如 ISO/IEC 9126‐1 和 ISO/IEC 25030 中所述）可能有助于协助此项活动。利益相关者需求包括社会施加的需求和要求、采购组织施加的约束以及用户和运营商员工的能力和操作特性。引用来源（包括招标文件或协议）以及（如果可能）其理由和原理、利益相关者的假设以及他们对满足其要求的重视程度会很有用。对于关键的利益相关者需求，定义了有效性衡量标准，以便可以衡量和评估运营绩效。如果在系统生命周期的任何时候，与人（用户和其他利益相关者）及其参与或与系统交互有关的问题（即需求、愿望、约束、限制、关注、障碍、因素或考虑）可能产生重大风险，则可以在 ISO PAS 18152《人与系统问题流程评估规范》中找到有关识别和处理人与系统问题的建议。

   注 1 子条款 5.2.3 描述了如何使用操作概念和系统操作概念作为工具来获取、记录和获取构建需求所需的信息。附件 A 包含系统操作概念的基本要素，附件 B 包含操作概念的相关信息。

   注 2：很少有系统不存在与使用、用户、操作人员、维护人员或某些人为系统问题源相关的重大风险。

   在大多数系统中，需求来源有很多，必须识别所有潜在来源并评估其对系统的影响。一些常见的需求来源和需要处理的问题包括：

   • 目标 – “目标”（有时称为“业务关注点”或“关键成功因素”）是指系统的总体、高级目标。目标为系统提供了动力，但其表述往往比较模糊。评估目标的价值（相对于优先级 ⁸）和成本非常重要。
   • 任务概况 系统将如何执行其任务？系统将如何为业务或组织运作？
   • 操作场景 – 是否有任何需要考虑的特殊场景？场景可用于定义操作概念，并限制系统产品的预期用途范围、预期操作环境和接口系统、平台或产品。场景有助于识别可能被忽视的需求。
   • 操作环境和使用环境 需求将源自系统或软件产品将在其中运行的环境。它将在炎热或寒冷的条件下、在外部还是其他同样严格的条件下运行？与系统环境交互的特征、时间和数量（工作量）是什么？实时系统中是否存在时间限制，商业环境中是否存在互操作性限制，例如操作时间限制？环境的其他方面（威胁和互操作系统）也可能导致对系统的要求。这些会极大地影响系统的可行性和成本，并限制设计选择。
   • 运营部署 系统何时使用？它将在初始、中期还是总结需求的各个阶段？
   • 性能 完成任务的关键系统参数是什么？
   • 有效性 系统在执行任务时应有多有效/高效？有效性的适用措施是什么？系统是否必须有最低限度的时间来执行任务，例如 90% 的时间？
   • 运行生命周期 系统的使用寿命有多长？20年？30年？系统每年应运行多少小时？
   • 组织环境 – 需要许多系统来支持组织的流程，这可能受组织的结构、文化和内部政策制约。一般而言，新系统不应强制对业务流程进行计划外的更改。
   • 用户和操作员特征 谁将使用或操作系统？他们在角色、技能水平和预期工作量方面有何不同？对他们的能力和可用性有何期望或限制？是否应考虑可访问性？ 注3：有关无障碍功能的更多信息，请参阅 ISO/IEC TR 29138‐1:2009, 信息技术 ⁹ 残疾人无障碍考虑 第 1 部分：用户需求摘要。

   作为这项任务的一部分，确定和评估重用先前存在的需求的机会非常重要。这包括确定提供类似功能或能力的现有系统、适用于新系统的特定功能或能力，以及可重用程度的信息。

   注4：有关需求重用的更多指导，请参阅 ISO/IEC 26551, 信息技术 ‐ 产品线需求工程和管理工具和方法。

   需求获取是一项迭代活动。在获取任务期间，请考虑几种不同的识别需求的技术，以更好地适应各种需求来源，其中包括：

   • 结构化研讨会和头脑风暴 ¹⁰
   • 访谈 ¹¹、问卷调查
   • 观察 ¹²环境或工作模式（例如时间和动作研究）
   • 技术文件审查
   • 市场分析 ¹³或竞争体系评估
   • 模拟、原型设计 ¹⁴、建模
   • 对流程和系统进行基准测试
   • 组织分析技术（例如优势 ‐ 劣势 ‐ 机会 ‐ 威胁分析、产品文件夹）

   系统利益相关者将是系统需求的权威来源，代表他们的利益或专业领域。但是，他们通常不熟悉如何将他们的专业知识转化为格式良好的需求陈述。除了这些人类需求来源之外，重要的系统需求通常由环境中的其他系统施加，这些系统需要系统的某些服务，或对系统进行约束，甚至来自应用领域的基本特征。还可能存在驱动系统需求的安全或其他监管约束。用户社区的描述（通常在组织运营概念中找到）可以提供整个工作的共同理解并验证方案的适当性。用户描述可能涵盖产品将面向的人口统计群体或将被分配使用该系统或以其他方式从其运营中受益的特定人员类别。

   在利益相关者需求获取流程中，让利益相关者参与验证利益相关者需求（例如，格式良好的需求），也可以帮助利益相关者尽早验证这些陈述是否准确地反映了他们的需求。应用第 5.2 节中提供的构建格式良好的需求陈述的特征和指导原则。

3.2 定义利益相关者的要求

此活动包括以下任务： 1. 定义系统解决方案的约束，这些约束是现有协议、管理决策和技术决策的不可避免的后果。 注：这些可能源于 1)利益相关者定义的解决方案的实例或领域 2)在系统层次结构的更高级别做出的实施决策 3)需要使用定义的支持系统、资源和人员。

约束是要求的一种类型。约束可能由以下因素施加： - 外部或组织利益相关者（例如，工程计划、技术性能指标、技术成熟度、法规、生命周期成本或用户和运营商人员配备限制）。 - 外部的、交互的或支持性的系统。 - 其他生命周期阶段的活动以及技术活动，如转换、运营和维护。 - 衡量有效性和适用性的指标，反映总体收单方/用户满意度（例如，绩效、安全性 ¹⁵、可靠性、可用性、可维护性和工作负载要求）。 约束的示例包括：1)高层管理人员要求的预算限制是对后续需求流程的约束；2)为系统开发的维护策略可能会对需求施加条件或约束（维修时间和/或 备件水平可能会影响可靠性值），或者可以直接定义能力要求（例如，内置测试功能以支持维护故障隔离）。

2. 定义一组具有代表性的活动序列，以识别与预期的操作和支持场景和环境相对应的所有所需服务。 注：场景用于分析系统在其预期环境中的运行，以便识别任何利益相关者可能尚未正式规定的要求，例如法律、法规和社会义务。识别和分析系统的使用环境。在环境分析中包括用户为实现系统目标而执行的活动、系统最终用户的相关特征（例如预期培训、疲劳程度）、物理环境（例如可用光、温度）和任何要使用的设备（例如防护或通信设备）。在适用的情况下，分析可能影响系统使用或限制其设计的社会和组织对用户的影响。

   场景可用于定义概念文档，并限制系统产品的预期用途范围、预期的操作环境和接口系统、平台或产品。场景有助于识别可能被忽视的需求。场景可能有助于为系统成功至关重要的系统性能参数建立关键和期望的系统性能阈值和目标。它们还可以确定那些期望的但可能需要妥协以满足关键参数的参数。用例方法也可用于定义概念文档。在这种方法下，将确定一组参与者（与系统交互的系统和人员类别），以及他们对系统的目标、目的和需求。分析用例以确定利益相关者的要求。

   通常需要不同层次的抽象或表示机制来解决包括收购方、用户和供应商在内的所有利益相关者的问题。

3. 识别用户与系统之间的交互。 注：确定可用性要求，至少要建立最有效、最高效和最可靠的人机性能和人机交互。交互应考虑人的能力和技能限制。在可能的情况下，使用适用的标准（例如 ISO 9241）和公认的专业实践来定义：i)身体、心理和学习能力；ii)工作场所、环境和设施，包括使用环境中的其他设备；iii)正常、异常和紧急情况；iv)运营商和用户的招聘、培训和文化；

   如果可用性很重要，则应通过生命周期流程来规划、指定和实施可用性要求，并且可能适用以下标准或技术报告： ISO 9241‐11:1998, 使用视觉显示终端（VDT）的办公室工作的人体工程学要求第11部分：可用性指南； ISO 13407:1998, 人体工程学‐人机系统交互的人体工程学‐以人为本的交互系统设计流程。

   考虑人机系统集成 (HSI) 是系统工程中的一个重要概念。HSI 关注系统生命周期中的人类。它提倡一种整体系统方法，包括人类、技术（硬件和软件）、操作环境以及系统元素之间必要的接口，以使它们协调工作。HSI 将以人为中心的学科（如人力、人员、培训、人为因素、环境、健康、安全、可居住性和生存性）纳入系统工程流程，以改善整个系统的设计和性能。将 HSI 考虑纳入需求取决于对任务、功能、操作场景和任务、用户群体和质量特性考虑的清晰理解。用户任务和性能、人力和培训方面的需求只能通过将系统的目标或任务分解到任务分析级别来定义，以定义用户界面的特征或前端分析以确定培训影响。

   注：ISO 13407:1999 已被 ISO 9241‐210《人机交互人体工程学‐第210部分：以人为本的交互系统设计》所取代。

4. 明确与关键品质相关的健康、安全、保障、环境和其他利益相关者的要求和功能。 注：识别安全风险，并在必要时指定提供安全的要求和功能。这包括与操作和支持方法、健康和安全、财产威胁和环境影响相关的风险。使用适用标准（例如 IEC 61508）和公认的专业实践。识别安全风险，并在必要时指定系统安全的所有适用领域，包括物理、程序、通信、计算机、程序、数据和排放。识别可能影响系统安全的功能，包括对受保护人员、财产和信息的访问和损坏、敏感信息的泄露以及拒绝批准对财产和信息的访问。指定所需的安全功能，包括缓解和遏制，在强制性或相关的情况下引用适用标准和公认的专业实践。

   关键品质是系统的某些方面，对于确保系统及其运行环境的完整性至关重要。

3.3 分析并维护利益相关者的需求

此活动包括以下任务： 1. 分析所引出的完整需求集。 注：分析包括识别和确定冲突、缺失、不完整、模糊、不一致、不协调或无法验证的需求的优先顺序。

应根据子条款 5.2.5 和 5.2.6 中定义的特性分析需求。应按优先顺序排列需求，并可按照子条款 5.2.8 中的描述进行分类。使用检查表或标准模板有助于审查流程。

如果已确定现有或遗留系统中的利益相关者需求可重用，则应根据适用性、可行性、可用性、质量、成本效益、价值和时效性等因素对其进行分析。在重用需求时，应仔细检查重用需求与相关系统的特定需求之间的一致性，以确保一致性。

2. 解决需求问题。 注：这包括无法实现或不切实际的要求。

   在需求分析和分配流程中，继续进行需求协商非常重要，因为冲突将会发生。利益相关者之间可能需要协商，因为需要相互不兼容的功能，或者由于期望的性能要求、约束、可用预算和交付时间表之间存在冲突。在大多数情况下，有必要与利益相关者协商，就适当的权衡达成共识。出于合同原因，此类决策可追溯到利益相关者通常很重要。各种分析方法和冲突解决技术可能适用于促进解决，并且取决于具体情况。

   一些组织将需求协商视为需求验证 ¹⁶的一部分。具体流程子类别并不重要，只要冲突解决在需求分析任务中尽早发生即可。

3. 将分析后的需求反馈给适用的利益相关者，以确保充分捕捉和表达需求和期望。 注：解释并获得利益相关者对解决冲突、不切实际和无法实现的要求的提议的同意。

4. 与利益相关者确认他们的要求得到正确表达。 注：这包括确认利益相关者的要求对于发起者来说是可以理解的，并且需求冲突的解决不会破坏或损害利益相关者的意图。

   在需求工程流程中，通常会有一个或多个正式安排的点来验证需求。目标是在投入资源实施系统解决方案之前发现任何问题。需求验证涉及检查需求集的流程，以确保它定义了正确的系统，即利益相关者期望的系统。需求验证中最常见的活动是进行需求审查、模拟和原型设计。

   进行需求审查可能是验证和确认需求文档的最常见方法。审查人员组成一个小组，负责查找错误、错误假设、不明确之处、可验证性问题以及偏离标准做法的问题。进行审查的小组的组成很重要（例如，对于由收购方驱动的项目，应至少包括一名收购方代表），并且以清单的形式提供要查找的内容的指导可能会有所帮助。评审 ¹⁷可以在需求集的任何抽象级别进行。在需求的开发和维护流程中，可以进行各种类型的评审，包括技术评审、检查和演练。可以使用低保真原型来获得系统潜在用户的反馈，从而实现有效的早期需求评审和验证。

   注 1：审计。有关评审的更多指导意见，请参阅 IEEE Std 1028‐2008《软件评审标准》和

   注 2：关于原型设计和模拟的讨论包含在第 6.3.3.2 节中。

5. 以适合整个生命周期及以后的需求管理的形式记录利益相关者的需求。 注：这些记录建立了利益相关者需求基线 ¹⁸，并保留了整个系统生命周期中需求的变化及其来源。它们是系统需求可追溯性的基础，并构成了后续系统实体需求的知识来源。

   应考虑使用需求管理工具，尤其是对于更复杂的项目。此工具应能够跟踪需求之间的联系以显示关系。需求管理工具旨在促进和支持整个项目生命周期内系统地管理需求。这包括但不限于需求获取、需求分析、需求变更管理 ¹⁹、需求重用和需求质量评估。

   注：有关需求管理工具的其他信息和指南，请参阅 ISO/IEC TR 24766:2009 –需求工程工具能力指南。

   需求存储库应首先填充利益相关者需求的源文档、项目约束（例如来自业务政策/规则或监管要求）以及为控制其设计的整个系统需求集提供基础的任何其他条件。需要捕获每个需求的来源和理由。

   作为涉众需求定义流程的一部分，可能输出的需求文档 ²⁰包括：

   • 利益相关者需求规范
   • 行动概念
   • 系统运作概念

   有关这些要求相关文件的更多信息可在第 7 至 9 条以及附件 A 和 B 中找到。

   需求库还应包括所有需求属性，包括需求的优先级和关键性。有关需求属性的更多信息，请参见第 5.2.8 节。

6. 保持利益相关者需求与利益相关者需求来源的可追溯性。 注：在生命周期的关键决策时刻对利益相关者的要求进行评审，以确保考虑到任何需求变化。

   应建立并维护初始需求可追溯性，以记录正式需求如何满足利益相关者的目标并获得利益相关者的同意。利益相关者的需求需要在整个系统生命周期及之后进行捕获、跟踪和维护，并置于配置控制之下。使用需求管理工具可以促进这一流程。有关可追溯性应用的更多讨论可在本国际标准任务 3 下的第 6.3.3.2 节中找到。

   注：本国际关于将信息置于配置控制之下的更多指导，可以在 ISO/IEC 15288 中找到。标准 6.3.5 款 1 和 6.5.2.1 款。

   注 2：5.2.5 条款描述了与需求工程相关的需求可追溯性。

本文同步发表在 软件需求探索的https://srs.pub/specification/req-flow-strs.html