过程目的
系统需求分析过程的目的是：将已定义的利益相关方需求转换成一组系统需求，以指导系统设计。
过程成果
1) 建立了一组定义的系统需求 ;
2) 对系统需求进行分类，并分析了其正确性和可验证性;
3) 分析了系统需求对运行环境的影响;
4) 定义了系统需求实施的优先级;
5) 根据需要更新了系统需求；
6) 建立了利益相关方需求和系统需求之间的一致性和双向可追溯性；
7) 从成本、进度和技术影响来评估系统需求；
8) 约定了系统需求，并与所有受影响方沟通。
基本实践
SYS.2.BP1:定义系统需求。使用利益相关方需求及其变更，以识别系统所需的功能和能力。在系统需求规范中定义功能性和非功能性系统需求。[成果1, 5, 7]
注1：影响功能和能力的应用参数是系统需求的一部分。
注2：关于利益相关方需求的变更，适用SUP.10
SYS.2.BP2:结构化系统需求。在系统需求规范中结构化系统需求，例如：
按项目相关集群进行分组，
按项目中逻辑顺序排序，
基于项目相关准则进行分类，
根据利益相关方需要进行优先级排序。
[成果2, 4]
注3：优先级排序通常包括将功能性内容分配给已计划的发布。参见SPL.2.BP1。
SYS.2.BP3: 分析系统需求。分析已定义的系统需求（包括它们的相互依赖关系），以确保正确性、技术可行性和可验证性，并且支持风险识别。分析对成本、进度和技术的影响。[成果1, 2, 7]
注4：对成本和进度的影响分析有助于项目估算的调整。参见MAN.3.BP5。
SYS.2.BP4: 分析对运行环境的影响。识别定义的系统和运行环境中其他要素之间的接口。分析系统需求对这些接口和运行环境的影响。 [成果 3,7]
SYS.2.BP5:制订验证准则。对每一个系统需求制订验证准则，定义定性的和定量的措施用于需求验证。 [成果2, 7]
注5: 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。
注6：测试不能覆盖的验证由SUP.2 覆盖。
SYS.2.BP6: 建立双向可追溯性。建立利益相关方需求和系统需求之间的双向可追溯性。[成果6]
注7：双向可追溯性有助于覆盖率、 一致性和影响分析。
SYS.2.BP7: 确保一致性。确保利益相关方需求和系统需求之间的一致性。[成果6]<br>注8：一致性由双向可追溯性支持，并可通过评审记录来证明。<br>SYS.2.BP8: 沟通约定的系统需求。与所有相关方沟通约定的系统需求及对系统需求的更新。 [成果8]
输出工作产品
13-04 沟通记录 [成果8]
备注
13-19 评审记录 [成果6]
备注
13-21 变更控制记录 [成果1]
备注
13-22 追溯记录 [成果6]
备注
15-01 分析报告 [成果2, 3, 4, 7]
备注
17-08 接口需求规范 [成果1, 3]
备注
17-12 系统需求规范 [成果1, 5]
备注
17-50 验证准则 [成果2]
备注
