1 SYS.2标准原文

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

过程结果：

1) 明确系统需求。

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

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

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

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

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

基本实践：

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

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

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

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

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

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

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

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

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

SYS.2.BP4：分析对系统环境的影响。分析系统要求对相关系统环境因素的影响。

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

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

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

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

2 SYS.2标准解析

2.1 过程目的Process purpose

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

The purpose is to establish a structured and analyzed set of system requirements consistent with the stakeholder requirements.

此流程的核心目的是根据利益相关方的需求，建立一套结构化且经过分析的系统需求。即，需求不仅要被明确地识别和记录，还要确保它们与项目目标和利益相关方的期望相一致。

2.2 过程成果Process outcomes

原文：

1) 明确系统需求。

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

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

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

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

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

1) System requirements are specified.

2) System requirements are structured and prioritized.

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

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

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

6) The system requirements are agreed and communicated to all affected parties.

解析:

1) Outcome 1: 需求必须被清晰地定义，没有歧义。

2) Outcome 2: 需求应该被组织成逻辑结构，并根据它们的重要性进行排序。

3) Outcome 3: 需求必须经过分析，以确保它们是可实现的，并且技术上是可行的。

4) Outcome 4: 需求对系统操作环境的影响必须被评估，以确保系统能在预期环境中正常工作。

5) Outcome 5: 需求必须与利益相关方的需求保持一致，并且能够追溯到它们的来源。

6) Outcome 6: 需求必须得到所有相关方的认可，并且相关信息必须被传达给所有将受到影响的个人或团队。

实施步骤:

1) 明确指定需求：使用清晰、无歧义的语言定义需求。

2) 结构化和优先级排序：将需求组织成层次结构，并根据项目目标进行排序。

3) 需求分析：进行技术可行性研究，确保需求是可实现的。

4) 环境影响分析：评估需求对操作环境的影响。

5) 建立追溯性：确保需求可以追溯到利益相关方的需求。

6) 需求确认：通过评审和批准流程，确保需求被所有相关方接受。

2.3 基本实践Base Practices

2.3.1 SYS.2.BP1：明确系统要求

原文：根据已定义的需求特征，使用利益相关方需求来识别和记录系统的功能和非功能需求。

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

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

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.

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

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.

1) 第一个关键词：“已定义的需求特征”。指的是在需求工程中，对需求的一系列属性或特征进行明确定义，这些特征帮助确保需求的质量和有效性。说白话就是：每项需求中需要体现的相关属性与字段描述。这些特征通常包括但不限于以下几个方面：

a)需求ID：对需求进行唯一性标识，有利于需求的定位以及需求的追踪。

b)负责人：明确需求的负责人，确保需求的管理和跟踪有人负责。

c)需求来源：标识需求来自于哪一个利益相关方，可能来自于某一个工程师、某一个系统、法律要求等。

d)需求类型：包括功能性需求和非功能性需求，如安全性需求、可靠性需求、维护性需求等。

e)是否衍生需求：标识需求是否是通过其他需求拆解而来，或者它们是否有来源。

f)优先级：需求的优先级，例如高、中、低。

g)风险：需求的风险等级。

h)是否清晰：描述需求是否清晰，即需求表述是否明确无误。

i)正确性：需求是否是正确的，用户的需求不一定总是正确的，这也是需要对需求进行分析的必要性所在。

j)完整性：需求表述是否完整，能够完善的表达该表述的意义。

k)可实现性：需求是否是可实现的。

l)可验证性：需求是否是可以验证的。

m)可跟踪性：需求是否便于同其他需求或领域项进行追踪的。

n)验收标准：需求的验收标准。

o)冲突需求ID：与该需求存在冲突的需求ID。

p)评审状态：需求的评审状态。

q)测试状态：需求当前的测试状态，如待测试、测试通过、测试失败。

r)实现状态：需求的实现状态，例如未开始、未满足、已满足。

s)备注：任何额外的说明或注释。

除了这些需求属性描述，需求描述中还应该包含需求的具体内容，即需求主体，这是需求描述的核心部分。需求主体应该清晰地描述系统必须实现的功能或性能，以及任何相关的业务规则或约束。这些属性和需求主体一起，构成了一个完整的需求描述，使得需求既清晰又可管理，便于后续的设计、实现和验证工作。

2) 第二个关键词“使用利益相关方需求”，即表示系统需求的上游来源是SYS.1的“利益相关方需求”，即我们之前常说的“涉众需求”；

3) 第三个关键词“识别和记录系统的功能和非功能需求”

a) 识别：即通过与利益相关方的沟通和协作，全面地发现和理解利益相关方需求中，和本系统相关的需求内容。

b) 记录：然后识别出的需求，以书面形式详细记录下来，形成正式的需求文档。

c) 需识别并记录的内容包含功能性需求和非功能性需求；

4) 那什么是功能性需求？什么是非功能性需求？

功能性需求：

功能性需求定义了系统或系统元素必须执行的功能。它们描述了系统的行为。功能需求通常包括以下几个方面：

- 业务规则：系统必须遵循的业务逻辑和规则。

- 用户交互：系统如何与用户交互，包括界面需求。

- 数据处理：系统如何处理数据，包括输入、处理和输出的规定。

- 外部接口：系统如何与外部系统或组件交互。

- 报告要求：系统需要生成的报告和文档。

- 认证要求：系统如何验证用户的身份。

功能需求是具体的、可执行的，它们通常可以用“系统能够...”或“用户能够...”这样的语句来描述。

非功能性需求：

非功能需求则关注系统的属性和质量，它们描述了系统应该如何执行，而不是应该做什么。

非功能需求通常包括以下几个方面：

1) 性能要求：如响应时间和吞吐量。

2) 可靠性：系统在指定时间内的正常运行时间。

3) 可用性：系统如何易于使用和访问。

4) 安全性：系统如何保护数据和防止未授权访问。

5) 可维护性：系统如何容易维护和升级。

6) 可扩展性：系统如何适应未来的增长和变化。

非功能需求通常是通过一些具体的、可衡量的指标来定义，它们影响着系统的用户体验和整体质量。

而非功能性需求涉及到性能、安全性、可靠性等属性，通常以“系统应该在...条件下运行”或“系统必须达到...的性能标准”来描述。

如何判断功能需求与非功能需求：

判断一个需求是功能需求还是非功能需求，可以依据以下标准：

- 是否描述具体行为：如果需求描述了系统必须执行的具体行为或任务，那么它通常是功能需求。

- 是否关注用户体验：如果需求关注用户的体验，如系统的响应速度或易用性，那么它通常是非功能需求。

- 是否可量化：非功能需求往往可以通过量化的指标来衡量，如99.9%的可靠性或3秒内的响应时间。

- 是否与系统结构相关：如果需求与系统的内部结构或设计选择相关，那么它可能是非功能需求。

例如：下面这些例子与系统内部结构与设计相关，为非功能性需求。

可靠性：

需求描述：系统必须在99.9%的时间内可用，任何故障的恢复时间不得超过5分钟。

解释：这个需求涉及到系统的内部设计，要求系统具备容错能力和快速恢复能力，以确保高可用性。

可维护性：

需求描述：系统的代码复杂度应控制在一定范围内，任何模块的圈复杂度不得超过15。

解释：这个需求关注代码的可维护性，要求在设计时考虑代码的清晰度和可读性，以便于后续的维护和修改。

性能：

需求描述：系统在高峰时段的响应时间不得超过2秒，普通时段不得超过1秒。

解释：这个需求涉及到系统的性能设计，要求在架构时考虑到性能优化。

兼容性：

需求描述：系统应支持多种的手机，包括小米手机、苹果手机和华为手机。

解释：这个需求关注系统的兼容性设计，确保系统能够支持不同的手机环境。

总结来说，功能需求关注的是“系统必须做什么”，而非功能需求关注的是“系统如何做”以及“系统的质量属性”。

在实际的软件开发过程中，两者都是必不可少的，它们共同确保了软件产品能够满足用户的需求和期望。

2.3.2 SYS.2.BP2：构建系统需求

原文：构建系统需求并确定优先次序。

Structure and prioritize the system requirements.

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

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

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

Note 4: Prioritization can be done according to project or stakeholder needs via e.g., definition of

本BP比较简单，即编写系统需求，并要求要定义每个需求的实现优先次序。

注3的要求是将系统需求结构化，可能包括按功能分组或识别产品变体。

1) 分组：将相关的系统需求按项目相关集群进行分组。

2) 排序：按照项目的逻辑顺序对系统需求进行排序。

3) 分类：基于项目相关准则对系统需求进行分类。

4) 优先级排序：根据利益相关方的需求进行优先级排序，通常包括将功能性内容分配给已发布的计划。

注4说明的是确定优先次序的方法：

1) 根据项目或利益相关方的需求，

2) 通过定义产品发布范围；

一般来讲，确定优先次序，涉及到如下方法：

1)利益相关方的需求：

a) 项目团队需要与利益相关方沟通，了解他们的需求和期望，并基于这些信息来确定需求的优先级。

b) 这可能涉及到对业务价值的评估，技术复杂度的考量，以及风险的分析。

2)定义发布范围：

a) 这通常涉及到确定产品或系统在不同开发阶段的里程碑，以及每个里程碑所期望完成的功能集合。

b) 通过定义这些发布范围，项目团队可以明确哪些需求是必须在特定发布前完成的，从而为这些需求设定一个较高的优先级。

3)产品发布时机：

a) 在产品开发过程中，可能会有多个样品发布或产品迭代的时机，例如A Sample, B Sample, C Sample。

b) 根据这些不同的发布时机，项目团队可以针对系统需求排定顺序，确定哪些需求应该在哪个发布版本中实现。

4)需求的实现逻辑：

a) 系统需求之间可能因为功能的实现存在先后顺序，项目团队可以根据这种逻辑顺序来排序系统需求，以确保先实现基础或关键的功能，再逐步完善其他功能。

5)业务价值评估：

a) 评估每个需求对业务的影响，包括增加收入、节省成本、提高客户满意度等，可以明确哪些需求对公司最为重要，从而确保资源和时间集中在关键需求上。

6)技术复杂度评估：

a) 技术复杂度包括开发难度、技术风险、实施周期等。

b) 评估技术复杂度可以帮助项目团队更好地理解需求的实现难度，从而合理安排资源和时间。

BP2中只罗列了上面的前两点，实际评估过程上，上面这些方法均可涉及。

这6点，用白话说，分别为：

1) 客户的要求

2) 成熟度计划要求

3) 样件发布要求

4) 功能需求实现的先后顺序

5) 公司评估哪些需求更重要

6) 技术复杂度参与评估。例如：太难的可能周期要花较长时间。或有风险的，要尽快做出来，以尽量降低风险。

2.3.3 SYS.2.BP3：分析系统需求

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

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

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

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

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

Note 6: Technical feasibility can be evaluated based on e.g., platform or product line, or by means of prototype development or product demonstrators.

该过程具体详细解析如下：

1)分析指定的系统需求：分析系统需求的目的是为了确保这些需求是清晰、完整、一致的，并且可以被实现。这包括对需求的详细审查，以识别和解决任何潜在的冲突或歧义。主要涉及如下操作：

a)需求审查：对每个系统需求进行详细审查，以确保它们是可理解和可实现的。

b)需求验证：验证需求是否符合利益相关方的需求和期望。

c)需求追溯性：确保每个系统需求都可以追溯到相应的利益相关方需求，以保持一致性。

2)包括它们之间的相互依赖关系：识别和分析系统需求之间的依赖关系，以确保系统的整体性和协调性。主要涉及如下操作：

a)依赖关系映射：识别哪些需求依赖于其他需求，以及这些依赖关系如何影响系统的实现。

b)依赖关系管理：制定策略来管理这些依赖关系，以减少风险并确保项目的顺利进行。

3)确保所有系统需求在技术上都是可行的，并且在项目范围内是可实现的。主要涉及如下操作：

a)技术可行性分析：评估需求的技术实现可能性，包括所需的技术、工具和资源。

b)风险评估：识别与技术可行性相关的风险，并制定缓解策略。

4)为项目管理提供有关项目估算的支持。通过分析系统需求，为项目管理提供准确的项目估算，包括成本、时间和资源需求。主要涉及如下操作：

a)项目估算：基于系统需求分析，估算实现这些需求所需的工作量、成本和时间。

b)资源规划：确定实现这些需求所需的人力资源、技术资源和其他资源。

实例说明

假设我们正在开发一个自动驾驶系统，该系统需要满足以下系统需求：

- SD1: 车辆必须能够在高速公路上以最高120公里/小时的速度自动驾驶。

- SD2: 系统必须能够识别并响应交通信号和道路标志。

- SD3: 系统必须能够在恶劣天气条件下保持操作。

分析过程：

1)相互依赖关系分析：我们发现SD1和SD3之间存在依赖关系，因为高速自动驾驶需要在恶劣天气条件下也能工作。SD2是实现SD1和SD3的基础，因为交通信号和道路标志的识别对于安全驾驶至关重要。

2)技术可行性分析：我们分析了实现SD1所需的传感器和控制算法，以及SD3所需的环境适应性技术。我们发现当前技术可以支持这些需求，但需要进一步的研发来确保在所有条件下的可靠性。

3)项目估算支持：基于这些需求，我们估算了研发成本、测试成本和人力资源需求。我们发现SD3的实现可能需要额外的时间和资源，因为它涉及到复杂的环境适应性技术。

2.3.4 SYS.2.BP4：分析对系统环境的影响。

原文：分析系统要求对相关系统环境因素的影响。

Analyze the impact that the system requirements will have on elements in the relevant system context.

本BP的目的是确保系统需求在考虑了它们对周围环境的影响后，能够被正确地实现和集成。具体解析如下：

1)识别系统和环境元素之间的接口

即，需要明确系统如何与外部环境交互，包括输入和输出的关系，以及系统与环境之间的物理、信息和能量交换。

2)分析系统需求对接口和运行环境的影响

分析系统需求对这些接口和运行环境的影响，包括但不限于以下几个方面：

物理影响：系统需求如何影响系统的物理布局、尺寸、重量等。

功能影响：系统需求如何影响系统的功能和性能。

环境适应性：系统需求如何影响系统在不同环境条件下的适应性和稳定性。

资源消耗：系统需求如何影响资源的使用，包括能源、材料等。

环境影响：系统需求如何影响环境，例如污染、生态平衡等。

3)评估环境因素对系统的影响

系统环境因素包括自然、社会、国际、劳动和技术等方面的因素。

这些因素的属性或状态及其变化都对系统产生影响，促使系统发生变化。

反之，系统建成并开始运行后，系统本身也会对周围环境发生影响，使环境因素的属性或状态发生变化。

4)支持项目决策和风险管理

通过分析系统需求对环境的影响，项目团队可以更好地理解潜在的风险和挑战，从而做出更明智的决策，并制定相应的风险管理计划。

实例说明

假设我们正在开发一个新的城市交通管理系统，该系统需要与现有的交通信号灯、监控摄像头和车辆通信系统等集成。以下是如何应用SYS.2.BP4的步骤：

1)识别接口：识别该系统与现有交通信号灯、监控摄像头和车辆通信系统之间的接口，包括数据交换格式、通信协议等。

2)分析影响：分析该系统需求对这些接口的影响，例如数据交换的频率、数据量、实时性要求等，以及对现有系统性能的影响。

3)评估环境因素：评估该系统对城市交通流量、环境（如噪音、污染）和社会效益（如减少拥堵、提高安全性）的影响。

4)支持决策：基于以上分析，项目团队可以决定是否需要对现有系统进行升级或改造，以及如何平衡技术实现和环境影响。

2.3.5 SYS.2.BP5：确保一致性并建立双向可追溯性。

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

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

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

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

Note 8: There may be non-functional stakeholder requirements that the system requirements do not trace to. Examples are process requirements. Such stakeholder requirements are still subject to verification.

本BP主要关注两个关键词“一致性”、“双向追溯性”：

1)确保一致性

确保系统需求与涉众需求之间的一致性。即，系统需求必须准确地反映涉众需求，并且没有冲突或歧义。

一致性是确保项目成功的关键因素，因为它帮助避免在项目后期因需求误解或变化而导致的返工和成本增加。

2)建立双向可追溯性

双向可追溯性是指从涉众需求到系统需求（正向追溯），以及从系统需求回溯到涉众需求（反向追溯）的能力。这种追溯性支持以下方面：

a) 一致性：通过双向追溯，可以确保系统需求与利益相关方需求保持一致，任何对需求的变更都可以被追踪和评估其影响。

b)变更影响分析：当需求发生变更时，双向追溯性可以帮助分析这些变更对项目的影响，包括成本、时间和资源的调整。

c) 需求覆盖范围展示：双向追溯性支持展示涉众需求的覆盖范围，即所有利益相关方的需求是否都被系统需求所覆盖。

注 7：双向可追溯性的重要性

注 7强调，仅仅存在链接（即追溯性）并不一定意味着信息之间是一致的。即，除了建立追溯性之外，还需要定期检查和验证系统需求与利益相关方需求之间的一致性，以确保信息的准确性和完整性。

注 8：非功能性利益相关方需求的验证

注 8指出，系统需求可能与非功能性的利益相关方需求没有直接关联，例如过程要求。这些非功能性需求虽然可能不会直接映射到系统需求，但仍需进行验证，以确保它们被适当地考虑和实现。

实施建议

为了实施SYS.2.BP5，可以采取以下步骤：

1) 明确需求收集过程：识别所有相关利益方，使用标准化模板收集和记录需求。

2) 使用标准化模板：确保需求文档包含所有重要属性，如需求标识符、描述、来源、优先级和验证标准等。

3) 经常性复审需求：定期复审需求，以确保它们与利益相关者需求保持一致，并适应项目的变化。

4) 建立需求变更控制流程：跟踪和处理需求的变更请求，并记录其影响和后果。

5) 利用需求管理工具：使用工具来支持需求的收集、分析、追踪和变更管理。

2.3.6 SYS.2.BP6：沟通商定的系统要求和对系统环境的影响

原文：将商定的系统要求和对系统背景的影响分析结果传达给所有受影响方。

Communicate the agreed system requirements, and results of the impact analysis on the system context, to all affected parties.

本BP强调了沟通的重要性。这一实践确保所有相关方都了解系统需求以及这些需求对系统背景的影响。具体解析如下：

1)理解商定的系统要求

商定的系统要求是指经过项目团队和利益相关者共同讨论、审查并同意的系统需求。这些需求是项目成功的关键，因为它们定义了系统必须实现的功能和性能。

2)理解系统背景的影响分析

系统背景的影响分析是指对系统需求对项目背景（包括技术、市场、环境、法规等方面）的影响进行的分析。这种分析有助于识别潜在的风险、机会和约束，从而为项目决策提供支持。

3)沟通的目的

沟通商定的系统要求和影响分析结果的目的是为了确保所有受影响方都了解：

项目目标和期望：确保所有相关方对项目的目标和期望有共同的理解。

需求的详细信息：提供系统需求的详细信息，包括它们的目的、范围和限制。

潜在的影响：让相关方了解系统需求可能对项目背景产生的影响，包括风险和机会。

决策依据：提供影响分析结果，帮助相关方理解项目决策的依据。

4)沟通的对象

受影响方可能包括但不限于：

项目团队成员：包括项目经理、系统工程师、设计师、开发人员等。

利益相关者：包括客户、用户、供应商、合作伙伴等。

管理层：包括项目发起人、高级管理人员等。

外部监管机构：如果项目受到特定法规或标准的约束，可能需要与外部监管机构沟通。

5)沟通的方法

会议和研讨会：组织会议和研讨会，让相关方讨论和审查系统要求和影响分析结果。

文档和报告：准备详细的文档和报告，概述系统要求和影响分析结果，并分发给所有相关方。

培训和教育：为项目团队成员提供培训，确保他们理解系统要求和影响分析结果。

在线平台和工具：使用在线平台和工具，如项目管理软件、协作工具等，以便于沟通和信息共享。

6)沟通的频率和时机

定期沟通：定期与所有相关方沟通，以确保信息的及时更新和共享。

关键决策点：在项目的关键决策点，如需求变更、项目里程碑等，进行特别沟通。

实施建议

为了有效实施SYS.2.BP6，可以采取以下步骤：

1) 制定沟通计划：明确沟通的目标、对象、方法、频率和时机。

2) 使用标准化模板：为系统要求和影响分析结果的沟通准备标准化的模板，以确保信息的一致性和完整性。

3) 监控沟通效果：定期评估沟通的效果，确保所有相关方都理解并满意。

4) 处理反馈和问题：积极收集和处理相关方的反馈和问题，以改进沟通效果。

2.4 过程结果/输出信息项/基本实践 对照表

3 总结

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

2)过程成果：

a) 明确系统需求。

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

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

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

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

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

3)基本实践：

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

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

d)SYS.2.BP4：分析对系统环境的影响。分析系统要求对相关系统环境因素的影响。

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

f)SYS.2.BP6：沟通商定的系统要求和对系统环境的影响。

4)输出信息项：

a) 17-00 需求

b) 17-54 需求属性

c) 15-51 分析结果

d) 13-51 一致性证据

e) 13-52 沟通证据

5)功能性需求：

a) 功能性需求定义了系统或系统元素必须执行的功能。

b) 它们描述了系统的行为。功能需求是具体的、可执行的，它们通常可以用“系统能够...”或“用户能够...”这样的语句来描述。

6)非功能性需求：

a) 非功能性需求关注系统的属性和质量，它们描述了系统应该如何执行，而不是应该做什么。

b) 非功能需求通常是通过一些具体的、可衡量的指标来定义，它们影响着系统的用户体验和整体质量。

c) 非功能性需求涉及到性能、安全性、可靠性等属性，通常以“系统应该在...条件下运行”或“系统必须达到...的性能标准”来描述。

7) 系统需求要以结构化的方式来编写，并且每个需求要定义优先级；

8) 系统需求之间，若有相互依赖关系，需定义出来。