中文翻译《ASPICE in practice》之“ENG.1 需求引出”

2.3 ENG.1 需求引出（需求获取）

2.3.1 目的

需求获取过程的目的是收集、处理和跟踪产品和/或服务整个生命周期内不断变化的客户需求和要求，以建立需求基线，作为定义所需工作产品的基础。

如果需求没有得到足够仔细的引出，整个项目就没有坚实的基础，后期必然会出现问题。以书面形式记录需求通常会在实践中造成困难或不足。常见的原因有：

1. 开发项目从一开始就面临着巨大的时间压力，因此需求定义不明确。
2. 客户不能或不愿意在项目早期承诺所有细节。
3. 这是第一次开发一个高度创新和复杂的系统，最初很难定义需求。

通常，在报价阶段获取需求会面临相当大的时间压力。特别是在客户-供应商关系中，需求分析无法进行得足够深入，因为专家们在报价截止日期迫在眉睫的压力下被迫局限于最基本的分析。在这种情况下，只有在下订单后才能进行详细分析，这反过来又经常导致合作伙伴之间对报价内容产生意见分歧。以下情况已被证明会对项目的进一步进展造成问题：

1. 客户不参与系统功能的规范，规范工作完全留给供应商。但是，客户在项目后期发出各种变更请求和新要求。
2. 供应商未能让客户确认其指定的要求，或者客户拒绝确认。

在某些情况下，已经建立了一种“节省劳动力的做法”，即订购的系统“与竞争对手的系统相同”或“与前一个项目类似，只有以下变化......”。此时，项目的后续问题的种子已经播下。

使用现有的和已经开发的平台解决方案，或重复使用为其他客户设计的应用程序，也可能存在问题。这样的组合在下订单时可能看起来非常诱人；然而，由于必要的更改和调整，它们可能会在以后迅速将项目推向失败的边缘，并在以后引发重复使用的经济竞争力问题。在实践中，提供平台解决方案的公司不得不在项目期间放弃它们并重新开始的情况不止一次。造成这种情况的原因可能是，相对于项目规模而言，更改可能过于广泛，或者由于架构问题，计划的解决方案无法再实施。这些情况下的成功不仅取决于需求的识别，还取决于其他因素，例如变更管理及其与工程流程、软件架构、单个软件组件封装等的联系。因此，客户将获得添加更改的“拼凑解决方案”或符合其要求的一致产品。

在复杂的系统中，我们经常会发现定义了大量需求，这些需求分布在不同的文档中。无论发生什么变化，都必须保证这些需求的内容在整个项目生命周期内保持一致。通常，我们会在一段时间内收集变更，然后一次性将其纳入需求文档中，这一步骤通常用于创建所谓的需求基线。

2.3.2 汽车行业特有的特征

在大多数情况下，需求并非仅仅来自明确表达的客户需求。在复杂的产品中，还必须考虑其他要求、标准或其他法规，例如与 ECU 可闪存性相关的诊断法规和规范。需要考虑的文档数量可能很快就会达到数百份。在某些情况下，文档已经过时，而且它们经常充斥着相互矛盾的信息。这会导致大量的开发工作，因为不仅需要检查、分配和确定所有这些文档的优先级，而且还必须识别和整理其中包含的所有不一致、错误和技术上不可行的要求。客户很少意识到这些活动所带来的复杂性和工作量，但通过提供精确而合理的规范，他们可以极大地有助于预防以后的问题。

2.3.3 基本实践

BP1：获取客户需求和请求。通过直接征求客户意见以及审查客户业务提案、目标操作和硬件环境以及其他与客户需求相关的文档来获取和定义客户需求和请求。

注意：必须收集和记录保持每个客户需求可追溯性所需的信息。

最常见的情况是，以下情况与需求获取相关：

1. 正在按订单开发产品。需求至少部分来自客户。适用的方法包括访谈、研讨会和客户文档分析。
2. 正在直接为市场开发产品。在这种情况下，需求由公司自己的产品营销或产品管理指定，所应用的机制和技术与第一种情况不同，例如，市场分析、最终客户调查或竞争产品分析的方式不同。
3. 前两种情况的混合形式用于为客户开发特定产品。但是，它应该基于现有的产品平台。或者，该产品旨在作为进一步产品的基础（因此是产品平台的基础）。

无论如何，积极接触需求提供者并获取他们的需求非常重要。当已识别的需求被记录下来时，必须通过指明客户需求的来源（例如，基础实践中提到的客户概念、目标操作环境和硬件环境，以及可能对客户需求产生影响的其他文件）来确保可追溯性（参见 ENG.2）。如果是混合形式，则需要区分客户特定需求和平台特定需求。应尽早识别和消除出现的冲突。系统和软件需求源自后续级别的客户需求。

评估员须知

关于 BP1（和 BP2），一个关键（且与评级相关）的点是供应商积极努力引出需求并将其付诸应用。然而，在实践中，问题经常因客户的参与而产生。如果客户无法传达其需求或无法积极参与表达这些需求，则不应在评估中降低供应商的评级。然而，此类结果应在报告中提及。

BP2：了解客户期望。确保供应商和客户以相同的方式理解每项要求。

注意：与客户一起审查他们的要求和请求，以更好地了解他们的需求和期望。请参阅流程 SUP.4 联合审查。

如注释中所述，让客户和供应商参与联合评审是达成共识的有效方法。在迭代开发模型中，联合评审通常是在逐步增强的原型的基础上进行的，并且可能在项目生命周期的大部分时间内持续进行。

供应商通常在领域部门审查需求文档时发现不明确或含糊的需求，并传达给客户。未解决的问题可以在随后的联合审查中澄清。此类需求审查不仅在项目开始时进行，而且在功能发生变化或增强时必须重复进行，以确保供应商真正了解客户的需求。同时，供应商还必须检查可行性和适用性（例如，关于可理解性和一致性）。审查结果应记录在案并由双方批准，以避免误解和冲突。

尽管基本实践未作要求，但隐含需求（参见 BP4）应以与明确的客户需求完全相同的方式处理，即评审、同意、批准等。

BP3：就需求达成一致。获得所有相关方的明确同意，以便按照这些需求开展工作。

参与开发的所有人（即供应商和客户方）的一致意见要求每个团队都评估了需求并认为这些需求是可行的。这样，与技术可行性和相关风险有关的问题就会大大减少，并建立共同的开发目标。实际上，获得具有约束力的协议通常很困难，通常由管理层在专家评估后进行。特别强调从相关利益相关者那里获取的信息的完整性。为此，我们需要在项目开始时确定并记录相关利益相关者是谁以及他们何时做出了哪些决定。

通常，报价团队或（未来）项目管理部门在报价阶段（即下订单之前）就已经获得了供应商技术部门实施客户要求的承诺。因此，供应商已经了解了客户的要求及其可行性。根据对可行性的初步评估以及粗略的工作量和成本估算，通常会制定一份初步报价，其内容和范围将在后续谈判中与客户进一步完善和调整。如果在下订单后才进行详细的需求分析，则必须根据对需求的详细了解来重新做出承诺。

此过程在供应商处以多次迭代的方式执行，但 Automotive SPICE 的基本实践中并未明确映射。同样，Automotive SPICE 并未解释如何处理无法实现的要求。建议在下订单之前确定供应商无法同意或无法满足的要求并以书面形式传达给客户（“偏差列表”）。如果不这样做，这些要求将成为合同不可分割的一部分，这可能会导致以后出现问题。

BP4：建立客户需求基线。将客户需求正式化，并建立项目使用和监控客户需求的基线。供应商应确定客户未说明但对指定和预期用途必要的要求，并将其纳入基线。

基线（另见 SUP.8）既是项目的基线，也是变更管理的基础。除了客户的要求之外，通常还有其他要求，例如需要考虑的环境法规或义务、法案和其他法律要求、不同市场或地区的标准或适用法规。供应商必须关注所有相关要求的全面识别，无论是否明确来自客户。

一旦供应商确定（BP1 和 BP2）并同意（BP3）所有相关要求，商定的状态将保留以形成需求基线。这可以以需求规范的形式完成，也可以作为配置管理系统中所有需求文档的基线。基于此初始版本，项目后期使用变更管理程序（参见 BP5）识别、评估和跟踪客户需求的每次变更或增强。这样，可以连续创建其他基线。

实践表明，没有需求基线的项目是有问题的，因为供应商无法确定需求是否已被考虑，而且项目中的变化通常没有被确定。

需求规范应该满足正式要求，例如，IEEE 830-1998“软件需求规范推荐做法”中所表达的要求。根据标准，需求应该正确、明确、完整、一致、按重要性和/或稳定性排序、可验证、可修改和可追溯 [IEEE 830]。

需求基线用于在项目过程中创建附加文档（例如，用于需求规范），并随着时间的推移添加更多细节（参见 ENG.2）。因此，它们对项目至关重要。第一个需求基线在实践中如此重要的原因之一是它构成了项目计划的基础。在客户-供应商关系中，第一个基线通常在报价阶段制定，并成为合同不可或缺的一部分。

BP5：管理客户需求变更。根据客户需求基准管理对客户需求所做的所有变更，以确保识别因技术和客户需求变化而产生的改进，并确保受变更影响的人员能够评估影响和风险并启动适当的变更控制和缓解措施。

注意：需求变更可能来自不同的来源，例如技术和客户需求的变化、法律约束。

一个运作良好的需求变更管理系统对于项目至关重要。考虑到这一点，变更请求必须遵循定义的工作流程（另请参阅 SUP.10）。典型工作流程的示例如下：

1. 变更请求被收集并传递给有权做出决定的个人或团体（通常是项目经理本人或与其他工作人员一起，甚至可能是与客户一起）。必须避免的是，个别开发人员“不官僚地”接受未经授权的变更，然后实施这些变更，从而产生潜在的不良副作用和计划外的额外成本。
2. 每项变更请求都会根据其影响和可行性进行评估
3. 如果在客户-供应商关系中，第一个需求基线是合同不可分割的一部分，则供应商必须能够将已委托的工作与额外工作区分开来。客户后来要求的每项变更或增强都会进行估算，并决定变更是否收费，即是否必须发出补充报价。
4. 变更请求需接受风险分析，如有必要，将制定风险降低措施（另见 MAN.5）。
5. 如果决策是肯定的，则将估算变更工作量，将其纳入项目计划，并在内部委托。然后通知客户。使用项目的跟踪机制，将对变更请求进行全程跟踪，直至完成（另见 MAN.3）。
6. 如果决策是否定的，则将向客户说明理由。

在这方面需要考虑的不仅是客户或最终客户的要求，还包括所有必要的变更，例如技术变更或法律要求变更。因此，供应商必须持续观察市场，以了解这些最新技术的变化。在项目过程中，必须跟踪相关变更的后续实施，以确保按照约定进行，并确保所有变更都能在计划日期或发布时可用。

BP6：建立客户-供应商查询沟通机制。提供一种方式，使客户能够了解其需求变更的状态和处置情况，并使供应商能够以客户指定的语言和格式传达必要的信息（包括数据）。

注：这可能包括与客户的联合会议或正式沟通，以审查其需求和请求的状态；请参阅流程 SUP.4 联合审查。

注：供应商传达的信息格式可能包括计算机辅助设计数据和电子数据交换。

客户将获悉其变更/增强需求的状态（例如，是否已就变更请求做出决定？）和处置情况（例如，将在哪个版本中实施变更？）。已建立明确的沟通机制，用于状态报告。提供必要的技术前提条件（数据连接、工具、格式规范等）。这是为了确保客户理解报告，并在需要时可以进一步处理这些报告。

例如，如果未使用特定工具，客户可以维护变更请求列表，并要求供应商定期添加评论并完成列表。此外，与所有利益相关者举行联合会议讨论需求和变更请求的状态也是常见的做法。

建议建立主动反馈机制，让客户有信心在商定的期限内以适当的方式处理其需求变更。这包括始终让客户了解其需求变更的完成程度。

最终客户会根据需要获得信息，例如通过有关召回和纠正措施的新闻稿，或通过已实施所需更改的新产品的商业广告。

2.3.4 指定工作产品

13-21 变更控制记录

参见 SUP.10

17-03 客户要求

客户要求定义系统或产品的特性。根据项目配置，它们要么由客户提供（以“客户要求规范”的形式），要么在项目内开发。

以下质量属性表征了需求规范：

1. 正确性：关于符合更高级别要求
2. 明确性：关于语言
3. 完整性：关于功能、性能、接口等。
4. 可验证性：要求表述清晰且可衡量
5. 一致性：术语使用一致（无同义词），要求不矛盾
6. 可修改性：内容结构化、系统组织（例如目录、索引、交叉引用）且一致
7. 可追溯性：各个要求分开，可向前追溯到后续文档，并可向后追溯到来源（参见第 2.24 节）

需求文档的结构参见图2-4。

图 2-4 符合 [IEEE 830] 的需求文档结构示例

2.3.5  2 级的特征

关于绩效管理

过程属性 PA 2.1 中列出的内容通常使用项目的项目管理方法实施，并部分记录在项目计划中。变更管理中的活动规划仅限于安排会议和 BP5 中提到的程序。

关于工作产品管理

过程属性 2.2 的要求特别适用于需求文档和变更记录。