1 目的
系统/软件需求定义过程的目的是转变利益相关者 1、用户面向目标的能力视角转变为满足运营需求的解决方案的技术视角用户。
这一过程创建了一组可衡量的系统要求，从供应商 2的角度指定系统需要具备哪些特性、属性、功能和性能要求，以满足利益相关者的要求。在限制允许的范围内，这些要求不应暗示任何特定的实施。
注：从软件系统的高层视角来看，此过程可用于定义系统的总体要求。当软件系统分解为元素时，每个元素又被视为一个系统、功能或一组
功能，并且此过程可用于进一步指定需求。需求分析和工具支持软件系统及其元素之间的需求可追溯性 3。
SWEBOK （软件工程知识体系指南）的软件需求知识领域注2讨论了软件需求的定义、分析、建模、规范、验证、管理和其他为软件系统提供额外指导的主题。
注：系统/软件需求定义过程结果的措辞与 ISO/IEC/IEEE15288:2015 的系统需求定义过程 4结果略有不同。使用“系统/软件需求”措辞强调本文件适用于具有软件需求和系统需求的软件系统。这旨在帮助用户按层次或在不同阶段定义系统需求和软件需求。
2 结果
成功实施系统/软件需求定义过程的结果是：
3 活动和任务
项目应根据与系统/软件需求定义过程相关的适用组织政策和程序实施以下活动和任务。
a)准备系统/软件需求定义。此活动包括以下任务：
1）根据行为和属性定义软件系统或元素的功能边界假如。
注：功能边界定义部分基于利益相关者需求和要求定义过程 7框架内定义的使用环境和操作场景。这包括软件系统的刺激（输入）
及其对用户和外部系统的响应，以及对软件系统与其操作环境之间所需交互的分析和描述， 包括接口属性和约束，比如程序流、 调用顺序、数据格式和流程、吞吐量和时间。这建立了以定量术语表示的预期软件系统行为在其边界上。 对于软件，边界通常以应用程序接口 (API) 和图形用户界面 (GUI) 或接口文件或服务来表示，包括数据格式。附件 E(E.5) 提供了生命周期过程的接口管理视图。
- 定义系统/软件需求定义策略。
注：这包括使用所选生命周期模型（如进化、 增量或迭代）来识别、定义和管理系统 / 软件需求的方法。许多因素都会影响该策略，例如，软件系统的复杂性以及要管理的信息和功能；多个团队成员是否需要随时访问和达成共同理解；在整个开发阶段， 采购方或用户代表的协作参与程度；项目是否涉及新开发、修改、重用或集成现有系统；以及流程文档要求（包括保留期）。生命周期模型将影响何时以及多久定义系统 / 软件需求。 附件 H 描述了使用敏捷方法在项目中逐步开发需求。
- 识别并规划支持系统/软件需求定义所需的必要支持系统或服务。
注：这包括识别支持系统的需求和接口。需求定义的支持系统包括促进和需求管理工具。与软件开发、测试和CM集成的软件需求管理工具可以简化跟踪和加快软件构建。支持系统/软件需求定义过程所使用的支持系统计划和建模技术描述可以合并到SDP中。
- 获取或获得将要使用的支持系统或服务的访问权。
注：验证过程 8用于客观确认支持系统是否实现了其支持的预期用途。
b)定义系统/软件需求。此活动包括以下任务：
- 定义软件系统或元素需要执行的每个功能。
注：软件功能可以在用例、用户故事 9或场景中描述，并涉及数据和信息的转换以满足用户需求（利益相关者要求）。在某些情况下，功能是从关键质量特性的分析中衍生出来的，比如性能、安全性或可用性（例如，系统诊断功能或高度频繁的数据备份功能，以实现可靠性）。
注：支持感兴趣的系统实现其功能所需的启用功能也与感兴趣的系统的功能同时被识别和定义。这对于帮助确保识别和说明系统环境中的启用功能是必要的。
2）识别软件系统所需的状态或操作模式。
注：状态或操作模式可以通过多种建模技术和视角进行建模和表示，以提供所需系统或元素要求的足够完整的描述。
注：功能执行条件通常涉及跨功能或元素的互操作性。例如，一些软件需求（例如，性能时间限制）可以分配到多个软件系统元素，从而影响测试用例或回归测试中对该需求的处理。
3）定义必要的实施约束。
注：对于软件元素，这包括由软件系统更高层次的架构定义分配的实施决策，由利益相关者的要求或解决方案的限制引入。实施约束包括系统能够执行功能的条件、系统开始执行该功能的条件（输入）以及系统停止执行该功能的条件（输出）。
4）识别与风险、软件系统关键性或关键质量相关的需求特征。
注：软件系统中的非功能性需求和关键质量特性通常包括与健康、安全、保障和软件保证、可靠性、可用性和可支持性（可维护性）以及吞吐量和性能的时间约束相关的需求和特性。系统分析过程 10可用于确定性能需求的适当值，同时考虑实现这些需求的预期成本及其对系统运行和使用的影响。
注：安全考虑的分析和定义包括与操作和维护方法、环境影响和人员受伤风险有关的要求。它还包括表达每项安全相关功能及其相关完整性，以及必要的风险降低和分配给指定的安全相关系统。适用标准涉及功能安全，例如 IEC61508，以及环境保护，例如 ISO14001。分析包括安全考虑，例如与敏感信息的泄露和保护有关的考虑。信息、数据和材料。使用适当且适用的安全标准定义与安全相关的风险，包括管理、人员、物理、计算机、通信、网络、排放和环境因素。有关系统和软件保证指南，请参阅 ISO/IEC/IEEE15026‑4。ISO/IEC27036 为产品和服务外包的信息安全要求提供指导。ISO25030 为外部系统质量因素和特性提供指导。附件 E（E.6）提供了生命周期过程的软件保证视图。
注：对于用于人机交互的软件系统，应考虑人因工程（人体工程学）规范。对于有可用性要求的系统，可在 ISO/FDIS9241‑220《人机交互人体工程学 第 220 部分：在组织内实现、执行和评估以人为本的设计的过程》中找到获得所需可用性水平的建议。
5）定义系统/软件需求和需求属性 11，包括以下内容：
我） 数据元素、数据结构和格式以及数据库或数据保留要求；
二） 用户界面和用户文档（用户信息）和用户培训；
三） 与其他系统和服务接口；
四） 功能和非功能特性，包括关键质量特性和成本目标；
五） 从现有的自动和手动系统转换操作流程和数据、迁移方法和计划、软件安装和产品验收；以及
- 需求属性，例如基本原理、
优先级12、软件系统元素、测试用例和信息项的可追溯性、验证方法、纳入批准的基线；以及评估的风险。
注：需求定义涉及与其他生命周期过程并行的迭代和递归步骤。根据正在使用的生命周期模型，比较用于确保需求的初始正确性所需的资源与基于验证和确认结果发展需求所需的资源是很有用的。
注：系统/软件需求和属性以适合生命周期需求管理的形式详细记录。有关需求的更多信息，请参阅 ISO/IEC/IEEE29148:2011 第 5 和第 6 条，有关系统需求规范和软件需求规范的描述和注释大纲，请参阅第 8 和第 9 条。
c)分析系统/软件需求。此活动包括以下任务：
1）分析完整的系统/软件需求。
注：需求分析不仅要分析单个需求的特性，还要分析需求集的特性。潜在分析特性包括需求是必要的、无需实施的、明确的、一致的、完整的、单一的、可行的、可追踪的、可验证的、可负担的、有界的。验证过程用于确定需求是否满足良好需求的属性和特性。在某些情况下，还要评估确认和验证需求替代表述的技术和经济可行性。
ISO/IEC/IEEE29148 提供了有关需求特征的附加信息。
注：系统分析过程可用来评估可行性、可承受性、平衡性和其他需求特征。系统分析过程用于确定需求参数的适当值，同时考虑软件系统的估计成本、进度和技术性能。
注：预计某些要求可以逐步实现，甚至推迟或放弃，因此可以对要求进行优先排序。
2）定义能够评估技术成就的关键绩效指标。
注：这包括定义与软件系统要素要求中确定的每个有效性度量相关的技术和质量度量以及关键性能参数。对关键性能度量（例如，性能度量和技术性能度量）进行分析和评审 13以帮助确保满足系统/软件要求，并帮助确保识别与任何不合规情况相关的项目成本、进度或性能风险。ISO/IEC15939 提供了识别、定义和使用适当度量的过程。
INCOSETP‑2003‑020‑01 《技术测量》提供了有关关键绩效指标的选择、定义和实施的信息。ISO/IEC25000系列标准提供了相关的质量指标。
3）将分析后的要求反馈给适用的利益相关者以供审阅。
注意反馈有助于验证指定的要求是否已被充分捕获和表达。确认意味着它们是对利益相关者要求的必要和充分的响应，也是对其他过程的必要和充分的输入，特别是软件架构、设计和验证。验证过程用于确定系统/软件要求是否满足用户的需求。
4）识别并解决完整体系中的问题、不足、冲突和弱点。要求。
注：这包括不可验证的需求、 含糊不清的需求、违反个别需求特征的需求或与需求集中的其他需求不一致的需求。需求问题的解决可以通过某些生命周期模型进行迭代。
d)管理系统/软件需求。此活动包括以下任务：
注：维护系统 / 软件需求包括定义、记录和控制基线（通常在正式配置管理下），以及管理因应用其他生命周期过程（如架构或设计）而导致的变更。
- 就系统/软件要求达成明确的协议。
注：这包括确认系统/软件需求表达正确、发起者和实施者可理解，并且需求冲突的解决与利益相关者的决定一致。
2）保持系统/软件需求的可追溯性。
注：在整个生命周期中，系统/软件需求与干系人需求、架构实体、接口定义、分析结果、验证方法或技术以及分配、分解和派生需求之间保持双向可追溯性。可追溯性允许验证可实现的干系人要求是否由一个或多个系统或元素要求满足，并且这些要求是否满足或有助于满足至少一个干系人要求。可追溯性通常由适当的数据存储库或集成的开发和测试基础设施促进。
- 提供已选定的基线关键工件和信息项。
注意配置管理过程用于建立和维护配置项和基线。此过程确定基线的候选者，而信息管理过程控制信息项，例如需求规范。对于此过程，系统 / 软件需求是典型的基线工件。