ASPICE-SYS2-系统需求分析

系统需求分析过程域的目的是：将上一过程域中已定义的相关方需求转换成内部的系统需求，以指导后续的系统设计。

该过程域的输入工作产品为：

(1) Stakeholder requirements

(2) Project Management Plan

该过程域输出工作产品为：

(1) SYS.2_System Requirements Analysis Process Checklist

(2) SYS.2_System Requirements Analysis Plan

(3) SYS.2_System Requirements Analysis Plan Checklist

(4) SYS.2_System Requirements Specification

(5) SYS.2_System Requirements Specification Checklist

如何成功实施系统需求分析？

成功实施该过程域主要体现在以下几方面:

（1）根据相关方需求(相关方需求包括客户需求或者其他公司内部需求)建立一组清晰定义的系统需求;

（2）根据系统需求分析计划对已定义的系统需求进行分类，如功能性需求和非功能性需求；并分析对应系统需求的正确性和可验证性;

(3) 针对拆解的每一条系统需求分析其对控制器运行环境的影响;

（4）根据项目计划以及与客户的沟通结果，针对拆解出来的每一条系统需求定义其实施的优先级以及实施的阶段

（5）拆解的系统需求需要根据实际项目情况进行对应的更新，并记录对应的变更记录；

（6）建立相关方需求和系统需求之间的一致性和双向可追溯关系，做到至少每一条相关方需求可以被系统需求进行连接；

（7）从项目成本、项目的开发进度和技术实现的难易程度来综合评估系统需求；

（8）拆解后的系统需求需要与相关的工程师进行评审，以确保系统需求分析的正确性；

SYS.2过程域在ASPICE审核中关注的BP点

对于该过程域，在对SYS2进行审核时，主要会关注以下BP点：

BP1: 定义系统需求。 使用相关方需求及其需求的变更，识别系统所需的功能和能力。在拆解的系统需求规范中定义功能性需求和非功能性系统需求。 
注 1：影响功能和能力的应用参数是系统需求的一部分。

注 2：需重点关于相关方需求的变更，假如需要进行需求变更的情况，需触发需求变更流程，适用于 SUP.10。
BP2: 结构化系统需求。 拆解的系统需求规范需要结构化，例如：按项目相关集群进行分组，如软件需求，硬件需求，结构需求等分类；按项目中逻辑顺序排序；基于项目相关准则进行分类，或者根据利益相关方需要进行优先级排序。
BP3: 分析系统需求。对拆解的系统需求进行分析，分析已定义的系统需求，包括它们的相互依赖关系，以确保拆解出来的每一条系统需求的正确性、技术可行性和可验证性，并且支持风险识别。分析系统需求对项目成本、项目开发进度和技术实现的难易程序的影响。对成本和进度的影响分析有助于项目估算的调整。
BP4: 分析系统需求对运行环境的影响。 识别项目中已定义的系统和运行环境中其他要素或系统之间的接口。分析系统需求对这些接口和运行环境的影响。 
BP5: 定义验证准则。 对每一条已经拆解出来的系统需求定义验证准则，定义定性的
和定量的措施用于需求验证。 验证准则证明了需求可以在约定的约束范围内得到验证，并且通常被用作系统测试用例开发或其它证明符合系统需求的验证措施的输入。
BP6: 建立双向可追溯性。建立相关方需求和系统需求之间的双向可追溯性。一般会使用需求管理工具，例如IBM Rational DOORS、Jama Connect、Polarion Requirements等，或者Excel文档也可以实现。双向可追溯性有助于覆盖率、 一致性和影响分析。
BP7: 确保一致性。 确保相关方需求和系统需求之间的一致性。一致性由双向可追溯性支持，并可通过评审记录来证明。
BP8: 沟通约定的系统需求。 与所有相关方沟通约定的系统需求及对系统需求的更新。