1.1 定义架构

此活动包括以下任务： 注：本活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 对需求分析中确定的系统功能进行划分，并将其分配给系统架构元素。根据分配需要生成派生需求。

架构设计解决方案是根据系统配置所基于的一组系统元素的需求来定义的。建立和维护需求与架构设计（包括系统元素和接口）之间的可追溯性非常重要。在生成派生需求时，应确定并记录系统元素的验证和确认标准。 - 定义并记录系统元素之间以及系统边界与外部系统的接口。

应通过适当的接口规范（如接口控制文档）来识别接口需求。接口需求被纳入架构设计解决方案。这些文档由涉及系统间交互的程序共享。

1.2 分析和评估架构

此活动包括以下任务： 注：本活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 确定分配给运营商的系统要求。

注 1：此项判定考虑了使用环境因素，并至少考虑了最有效、最高效和最可靠的人机交互的以下因素： - 人类能力的局限性； - 对安全至关重要的人类行为以及如何应对错误造成的后果； - 将人类表现融入系统及其运行中。

注：有关架构设计的更多指导，可参阅 ISO/IEC 15288:2008（IEEE Std 15288‐2008）第 6.4.3 款“架构设计流程”。

2.1 方案验证

此活动包括以下任务： 注：本活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 根据系统需求定义验证计划。

注：计划考虑了集成策略中定义的配置顺序，并在适当的情况下考虑了故障诊断的拆卸策略。计划通常定义风险管理 ⁵验证步骤，逐步建立对完全配置产品合规性的信心。

通过在创建需求时最初关联验证方法来促进此活动。验证方法应记录在案。文档可能包括需求验证 ⁶和可追溯性矩阵或验证计划中的验证语句。验证方法定义了如何（包括成功标准和收尾方法）、在何处和何时证明每个需求的合规性以供收购方接受。验证方法与每个需求相关联，以定义产生客观信息以证明满足需求的活动。良好的验证方法定义解决了以下部分或所有内容注意事项： - 如何确定将采用哪种验证方法； - 谁确定负责执行验证的组织/个人，例如承包商、分包商、供应商 ⁷、产品团队或供应商； - 时间 – 在项目计划中指定进行验证的时间。这应该是基于事件而非日历日期的成就； - 地点 – 指定验证活动所需的任何独特场地和环境。

有四种标准验证方法可用于获取已满足要求的客观证据：检查、分析或模拟、演示和测试。

• 检查：根据适用文件检查物品，以确认符合要求。检查用于验证通过检查和观察 ⁸确定的属性（例如，油漆颜色、重量等）。检查通常是非破坏性的，通常包括使用视觉、听觉、嗅觉、触觉和味觉；简单的物理操作；机械和电气测量；以及测量。良好做法：包括用于对所需内容和正在检查的内容进行比较的文件/图纸的识别。

• 分析（包括建模和模拟）：使用分析数据或在规定条件下进行模拟，以显示理论合规性。用于无法实现或不具成本效益的现实条件测试。当分析（包括模拟）确定所提出的解决方案满足适当的要求、规范或派生要求时，可以使用分析。分析也可以基于“相似性”，通过审查类似项目的先前验证并确认其验证状态可以合法地转移到当前系统元素。只有在项目在设计、制造和使用上相似；对类似的系统元素使用了等效或更严格的验证规范；并且预期的操作环境与类似的系统元素相同或不那么严格。良好做法：确定分析的通用名称（如故障模式影响分析）、分析/计算机工具和/或数值方法；输入数据的来源；以及如何分析原始数据。确保与采购方达成一致，即分析方法和工具（包括模拟）可用于提供客观证据或符合要求。

• 演示：功能性能的定性展示，通常不使用或仅使用最少的仪器或测试设备。演示使用一组测试活动，其中系统刺激由供应商选择，以显示系统或系统元素对刺激的响应是合适的，或显示操作员在使用系统时可以执行其分配的功能。进行观察并与预定的响应进行比较。当要求或规范以统计形式给出时（例如，平均修复时间、平均功耗等），演示可能是合适的。良好做法：说明为了收集成功证据，证人是谁，将遵循哪些一般步骤，以及需要哪些特殊资源，例如仪器、特殊测试设备或设施、模拟器、特定数据收集或演示结果的严格分析。

• 测试：在受控的真实或模拟条件下定量验证物品的可操作性、可支持性或性能能力的行为。这些验证通常使用特殊的测试设备或仪器来获取非常准确的定量数据以供分析。良好做法：说明谁将是收集成功证据的证人。确定测试设施、测试设备、任何独特的资源需求和环境条件、所需的资格和测试人员、将遵循的一般步骤、要收集的具体数据、收集数据的可重复性标准以及分析结果的方法。

注：认证通常作为第五种验证方法。认证是一种书面保证，表明系统或系统元素已根据所需标准开发并满足要求。这确保系统或系统元素能够按照商定的标准执行其指定功能。开发评审 ⁹和系统验证和确认结果构成认证的基础。认证通常是由第三方按照公认的标准执行。

此信息包含并记录在更新的需求可追溯性矩阵 (RTM) 中。

2.2 进行验证

此活动包括以下任务： 注：本活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 进行验证以证明符合规定的设计要求。

注：不合规表明存在随机故障和/或设计错误，并根据需要启动纠正措施。验证以符合组织约束的方式进行，以尽量减少验证行动、条件和结果复制中的不确定性。对验证行动和结果进行批准记录。

需求可追溯性通常用作单一责任点，用于将需求追溯到需求来源并在整个生命周期中向前追溯，以评估需求是否得到满足。在需求可追溯性中，验证方法和信息与需求相关联，以指示如何验证系统或系统元素以表明其满足需求。随着系统经历生命周期阶段，应添加需求对工作产品的可追溯性。为每个需求包含唯一标识符非常重要。

3.1 计划验证

此活动包括以下任务： 注：此活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 制定验证计划。

注：验证基于利益相关者的要求。在适当的情况下，定义验证步骤，例如各种运行状态、场景和任务，以逐步建立对已安装系统一致性的信心并帮助诊断任何差异。指定实施验证策略所需的方法和技术，以及每次验证的目的、条件和一致性标准。当利益相关者的要求无法全面指定或经常更改时，可以采用对系统演进增量（通常是快速开发的）的重复验证来完善利益相关者的要求并降低正确识别需求的风险，例如，ISO 13407描述了涉及用户的迭代生命周期。

系统操作概念和基线利益相关者要求是验证计划活动的输入。

3.2 执行验证

此活动包括以下任务： 注：本活动下的任务未包括在内，因为没有与需求工程相关的具体指导。 - 进行验证以证明服务符合利益相关者的要求。

注：验证以符合组织约束的方式进行，以便将验证行动、条件和结果的重复中的不确定性降至最低。客观记录和批准验证行动和结果。验证还可以用于确认系统不仅满足所有操作、功能和可用性要求，而且还满足通常不太正式表达但有时至关重要的态度、经验和主观测试，这些测试构成了客户满意度。

需求验证需经项目主管部门和主要利益相关者批准。此流程在利益相关者需求定义流程 ¹⁰中调用，以确认需求正确反映了利益相关者的需求并建立验证标准，即我们拥有正确的需求。系统验证确认所构建的系统满足利益相关者陈述的需求和要求，即它是正确的系统。应维护需求可追溯性，并可在需求可追溯性矩阵 (RTM) 中记录。

注 1：有关验证的更多指导意见，请参阅 ISO/IEC 15288:2008 (IEEE Std 15288‐2008)，验证流程。 注 2: 有关验证可用性要求的更多指导，可参见 ISO/IEC 25060 和 ISO/IEC 25062。

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