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

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

2.3.1 目的

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

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

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

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

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

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

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

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

2.3.2 汽车行业特有的特征

在大多数情况下，需求并非仅仅来自明确表达的客户需求。在复杂的产品中，还必须考虑其他要求、标准或其他法规，例如与 ECU 可闪存性相关的诊断法规和规范。需要考虑的文档数量可能很快就会达到数百份。在某些情况下，文档已经过时，而且它们经常充斥着相互矛盾的信息。这会导致大量的开发工作，因为不仅需要检查、分配和确定所有这些文档的优先级，而且还必