系统需求分析SYS.2和软件需求分析SWE.1，是两个非常相似的过程。所以本文大部分内容会 结合系统需求分析来进行讲解 ，以便大家理清楚二者的关系、边界与差异。

系统需求分析SYS.2可以详见之前的文章《 【ASPICE4.0】--深度解析 SYS.2系统需求分析 》

1、SWE.1软件需求解析

下面的解析主要结合系统需求，对比软件需求来展开描述。

黑色字体为SYS.2系统需求的标准内容；

蓝牙字体为SWE.1软件需求的标准内容；

红色字体为SWE.1软件需求部分多出来的差异点；

绿色字体为两者之间的区别描述；

1.1 过程目的

SYS.2 过程目的： 目的是根据 利益相关方的要求 ， 建立 一套结构化的、经过分析的 系统需求 。

SWE.1 过程目的： 目的是建立一套结构化的、经过分析的、 与系统需求和系统架构相一致的软件需求 。

SWE.1 Process purpose： The purpose is to establish a structured and analyzed set of software requirements consistent with the system requirements, and the system architecture.

两个区分很明显，如下：

SYS.2的上游是利益相关方，然后依其生成系统需求；

SWE.1的上游是系统需求和系统架构，然后依其生成软件需求；

1.2 过程成果

SYS.2 过程成果：

1) 明确系统需求。

2) 对系统需求进行结构化和优先排序。

3) 分析系统需求的正确性和技术可行性。

4) 分析系统需求对运行环境的影响。

5) 在系统需求和利益相关方需求之间建立一致性和双向可追溯性。

6) 就系统需求达成一致意见，并传达给所有受影响方。

SWE.1 过程结果：

1) 明确软件需求。

2) 对软件需求进行结构化和优先排序。

3) 分析软件需求的正确性和技术可行性。

4) 分析软件需求对运行环境的影响。

5) 在软件需求和系统需求之间建立一致性和双向可追溯性。

6) 在软件需求和系统架构之间建立一致性和双向可追溯性。

7) 软件需求得到同意，并传达给所有受影响方。

SWE.1  Process outcomes

1) Software requirements are specified.

2) Software requirements are structured and prioritized.

3) Software requirements are analyzed for correctness and technical feasibility.

4) The impact of software requirements on the operating environment is analyzed.

5) Consistency and bidirectional traceability are established between software requirements and system requirements.

6) Consistency and bidirectional traceability are established between software requirements and system architecture.

7) The software requirements are agreed and communicated to all affected parties.

两个基本没区别，唯一区别是，

SYS.2系统需求只有一个上游“利益相关方需求”，故只需建立与利益相关方需求一致性和双向可追溯性。

SWE.1软件需求有两个上游“系统需求”、”系统架构设计”，故需建立与系统需求和需求架构设计一致性和双向可追溯性。

1.3 基本实践 BP1

SYS.2.BP1 ：明确系统要求。 根据已定义的需求特征，使用利益相关方需求来识别和记录系统的功能和非功能需求。

注1：ISO IEEE 29148、ISO 26262-8:2018或INCOSE《需求编写指南》等标准对需求的特征进行了定义。

注 2：技术标准中定义的需求特征包括：可验证性 (即需求文本中固有的验证标准) 、明确性/可理解性、不受设计和实施的限制，以及不与任何其他需求相矛盾。)

SWE.1.BP1：明确软件要求。

使用系统需求和系统架构，根据已定义的需求特征，确定并记录软件的功能和非功能需求。

Use the system requirements and the system architecture to identify and document the functional and non-functional requirements for the software according to defined characteristics for requirements.

注 1：需求特征在 ISO IEEE 29148、ISO 26262-8:2018 或 INCOSE《需求编写指南》等标准中均有定义。

注 2：技术标准中定义的需求特征有：可验证性 (即需求文本中固有的验证标准) 、明确性/可理解性、设计与实现的自由度、不与任何其他需求相矛盾。)

注 3：在纯软件开发的情况下，系统需求和系统架构是指给定的运行环境。在这种情况下，利益相关方的要求可作为确定软件所需功能和能力的基础。

注 4：硬件-软件-接口 (HSI) 定义的背景是硬件，因此它是系统设计层面的接口决策。如果存在这样的硬件-软件接口，则可为软件要求提供输入。

Note 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO 26262-8:2018, or the INCOSE Guide for Writing Requirements.

Note 2: Examples for defined characteristics of requirements shared by technical standards are verifiability (i.e., verification criteria being inherent in the requirements text), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement).

Note 3: In case of software-only development, the system requirements and the system architecture refer to a given operating environment. In that case, stakeholder requirements can be used as the basis for identifying the required functions and capabilities of the software.

Note 4: The hardware-software-interface (HSI) definition puts in context hardware and therefore it is an interface decision at the system design level. If such a HSI exists, then it may provide input to software requirements.

两者的主要区别是SWE.1比SYS.2增加了注3和注4。

1）注3的意思是：在纯软件开发的情况下，没有传统意义上的系统需求和系统架构作为输入。此时，可以直接依据利益相关方的需求来确定软件的需求。

2）注4的意思是：

HSI是系统设计的一部分，它涉及到硬件组件和软件组件之间的交互。这些接口定义了硬件如何与软件通信，包括数据流、控制信号、同步机制等。

若产品开发包含HSI，则其应该作为软件需求的输入。因为软件需求必须与这些硬件接口兼容，确保软件能够正确地与硬件交互。

1.4 基本实践 BP2

SYS.2.BP2：构建系统需求。 构建系统需求并确定优先次序。

注3：结构化标准的例子可以是分组 (如按功能) 或产品变体识别。

注4：可根据项目或利益相关方的需求，如通过定义发布范围来确定优先级。请参阅 SPL.2.BP1。

SWE.1.BP2 ： 构建软件需求。 对软件需求进行结构化和优先排序。

Structure and prioritize the software requirements.

注 5：结构化标准的例子可以是分组 (如按功能) 或表达产品变体。

注 6：可根据项目或利益相关者的需求，如通过定义发布范围来确定优先级。参见 SPL.2.BP1。

Note 5: Examples for structuring criteria can be grouping (e.g., by functionality) or expressing product variants.

Note 6: Prioritization can be done according to project or stakeholder needs via e.g., definition of release scopes. Refer to SPL.2.BP1.

SYS.2与SWE.1二者完全一样。

1.5 基本实践 BP3

SYS.2.BP3：分析系统需求。 分析指定的系统需求，包括它们之间的相互依赖关系，以确保正确性和技术可行性，并为项目管理提供有关项目估算的支持。

注5：项目可行性见 MAN.3.BP3，项目估算见 MAN.3.BP5。

注6：技术可行性可根据平台或产品系列等进行评估，也可通过原型开发或产品演示进行评估。

SWE.1.BP3 ：分析软件需求。 分析指定的软件需求，包括它们之间的相互依赖关系，以确保正确性和 技术可行性，并为项目管理提供有关项目估算的支持。

Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility, and to support project management regarding project estimates.

注 7：项目可行性见 MAN.3.BP3，项目估算见 MAN.3.BP5。

注 8：技术可行性可根据平台、产品线或原型设计等进行评估。

Note 7: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.

Note 8: Technical feasibility can be evaluated based on e.g., platform or product line, or by prototyping.

SYS.2与SWE.1二者完全一样。

1.6 基本实践 BP4

SYS.2.BP4：分析对系统环境的影响。 分析系统要求对相关系统环境因素的影响。SWE.1.BP4 ：分析对运行环境的影响。 分析软件需求对运行环境中各要素的影响。Analyze the impact that the software requirements will have on elements in the operating environment.

SYS.2与SWE.1二者基本一样的。主要的区别在于系统环境与运行环境的差异上。系统环境主要包括了系统运行的外部条件和背景，如物理环境、法律法规、用户期望等。运行环境特指软件运行所在的系统，例如硬件、操作系统等。

假设我们需要开发一个新的车身控制系统，该系统需要与车辆的多个传感器和执行器交互。

在SYS.2.BP4的实践中，我们需要分析这个系统需求如何影响车辆的整体运行环境。例如，如果系统需求包括一个新的安全特性，要求在检测到碰撞时自动断开燃料供应，那么我们需要分析这一需求对车辆安全标准、环境保护法规以及用户操作习惯的影响。

在SWE.1.BP4的实践中，我们关注的是软件需求如何影响软件的运行环境。我们需要分析软件如何处理来自传感器的数据，如何控制执行器，以及这些操作如何依赖于特定的硬件性能和操作系统特性。例如，如果软件需要在特定的时间内处理传感器数据以确保及时响应，那么我们需要分析软件需求对硬件处理速度的要求，以及对操作系统实时性能的依赖。

简言之，SYS.2.BP4更侧重于系统层面的宏观影响，而SWE.1.BP4则更侧重于软件与其直接运行环境之间的相互作用。

1.7 基本实践 BP5

SYS.2.BP5：确保一致性并建立双向可追溯性 。确保系统需求与利益相关方需求之间的一致性并建立双向可追溯性。

注7：双向可追溯性支持一致性，便于对变更请求进行影响分析，并支持展示利益相关方需求的覆盖范围。仅有可追溯性，如存在链接，并不一定意味着信息之间是一致的。

注8：系统需求可能与非功能性的利益相关方需求没有关联。例如过程要求。此类利益相关方要求仍需验证。

SWE.1.BP5 ：确保一致性并建立双向可追溯性。 确保软件需求与系统架构之间的一致性并建立双向可 追溯性。确保软件需求与系统需求之间的一致性并建立双向可追溯性。

Ensure consistency and establish bidirectional traceability between software requirements and system architecture. Ensure consistency and establish bidirectional traceability between software requirements and system requirements.

注 9：不要建立冗余的可追溯性。

注 10：可能会有一些非功能性的系统需求，而软件需求与之无关。例如，过程需求或与软件产品生命周期后期阶段 (如事故处理) 相关的需求。这些要求仍有待核实。

注 11：双向可追溯性支持一致性，便于对变更请求进行影响分析和证明验证范围。仅有可追溯性，如存在链接，并不一定意味着信息之间是一致的。

注 12：针对纯软件开发，系统需求和系统架构指的是特定的运行环境。在这种情况下，可确保利益相关方的要求与软件要求之间的一致性和双向可追溯性。

Note 9: Redundant traceability is not intended.

Note 10: There may be non-functional system requirements that the software requirements do not trace to. Examples are process requirements or requirements related to later software product lifecycle phases such as incident handling. Such requirements are still subject to verification.

Note 11: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.

Note 12: In case of software development only, the system requirements and system architecture refer to a given operating environment. In that case, consistency and bidirectional traceability can be ensured between stakeholder requirements and software requirements.

软件需求比系统需求主要增加了注9和注12。

1）注9中，描述不要建立冗余的可追溯性，我觉得对系统需求和软件需求都应该是适用的。只是软件需求有两个上游，更容易出现冗余的可追溯性，所以软件需求特地做了注解。

2）注12中，针对纯软件开发，系统需求和系统架构实际上指的是软件将要运行的特定环境，即给定的运行环境。这里的“系统需求”和“系统架构”不再是传统意义上描述整个系统的文档，而是特指软件运行所依赖的硬件、操作系统等环境因素。在这种情况下，利益相关方的需求成为确定软件需求的输入，故需确保利益相关方需求与软件需求之间存在一致性和双向可追溯性。

1.8 基本实践 BP6

SYS.2.BP6：沟通商定的系统要求和对系统环境的影响。 将商定的系统要求和对系统背景的影响分析结果，传达给所有受影响方。

SWE.1.BP6 ：传达商定的软件要求和对运行环境的影响。 将商定的软件需求和对运行环境影响的分析结果，传达给所有受影响的各方。

Communicate the agreed software requirements, and the results of the analysis of impact on the operating environment, to all affected parties.

SYS.2与SWE.1二者完全一样。

1.9 输出信息项&过程成果&基本实践关系

2 总结与示例

软件需求分析SWE.1与 系统需求分析SYS.2 的差异点总结如下：

一、相同点：

1) 目的一致性 ： 两者都要求确保需求的完整性和一致性，并且都强调需求的结构化和分析。SYS.2的目的是建立一套结构化并经过分析的系统需求，而SWE.1的目的是将系统需求中与软件相关的部分转化为一组软件需求。

2) 过程成果 ： 两者的过程成果相似，都包括定义需求、分析需求的正确性和可验证性、分析需求对运行环境的影响、定义需求实施的优先级、评估需求的成本、进度和技术影响，以及与所有受影响方沟通需求。

3) 双向可追溯性 ： 在ASPICE 4.0中，SYS.2和SWE.1都强调了需求的一致性和双向可追溯性，但 SYS.2系统需求只有一个上游“利益相关方需求”，故只需建立与利益相关方需求一致性和双向可追溯性。而SWE.1软件需求有两个上游“系统需求”、”系统架构设计”，故需建立与系统需求和需求架构设计一致性和双向可追溯性。

二、差异点：

1) 关注层面 ： SYS.2关注的是 整个系统层面的需求 ，包括硬件、软件和其他系统组件；而SWE.1 专注于软件层面的需求 。

2) 输入来源 ： SYS.2的输入 主要来自利益相关方的需求 ，而SWE.1的输入则来源于SYS.2的输出，即 系统需求中与软件相关部分。

3) 详细程度 ： SYS.2定义的需求可能更为宏观，而SWE.1则需要更详细地描述软件的功能和非功能需求，包括具体的接口和性能参数。

4) 实践细节 ： 在基础实践（Base Practices）中，SYS.2和SWE.1有所不同。例如，SYS.2的BP1强调了根据利益相关方需求识别和记录 系统的功能和非功能需求 ，而SWE.1的BP1则侧重于根据系统需求和系统架构识别 软件的功能要求和性能要求 。

5) 运行环境：系统需求关注的系统环境，软件需求关注是软件运行环境。区别为： 系统环境主要包括了系统运行的外部条件和背景，如 物理环境、法律法规、用户期望 等。运行环境特指软件运行所在的系统，例如 硬件、操作系统 等。

三、实例说明：

假设我们正在开发一个汽车的车身控制系统，其中涉及到外灯系统中的近光灯控制。

1) 在SYS.2中，我们可能会定义一个系统需求，如“ SYS_REQ-0001:  车辆应在打开近光灯开关被按下时，打开近光灯 ”。

2) 在SWE.1中，这个需求会被进一步细化为软件需求，例如“ SW_REQ-0001: 若整车电源模式是ON，车辆应在打开近光灯开关（对应某IO口输入，如PortA-2）被按下时，打开近光灯（对应某IO口输出，如PortB-8） ”。

通过这个实例，我们可以看到SYS.2和SWE.1在需求定义和分析上的不同侧重点和详细程度。