物有本末，事有终始。知所先后，则近道矣。对软件开发而言，软件需求乃重中之重。必先之事重千钧，不可或缺如日辰。

汽车行业由于有方法论和各种标准约束，对软件开发有严苛的要求。ASPICE指导如何审核软件开发，虽然没有明确定义如何去开发，但是ASPICE的Guideline和Essential文件中给出很多参考。本文则详细阐述如何编写软件需求，同时介绍软件需求的必要属性。本文用SRS(Software Requirement Specification)代替软件需求设计规格书。

软件需求描述软件的期望行为。由于软件在现代汽车电子控制单元的重要性持续增长，软件需求分析通常包含类似于系统需求的产物。然而，无论如何，规格书SRS都是强制并且不可或缺的。

1. 软件需求分类

• Heading标题

软件需求工程师用来结构化软件需求规格书SRS，即将SRS按照功能进行分类，并针对功能设置标题，譬如：主动泄放、上下电管理、离合器控制等。

• Information 信息

软件需求工程师用来指示额外信息，仅作参考，譬如：BMS的SOC算法公式，很难在软件测试验证，在编写需求时可以将此作为额外信息输入给软件工程师，设为Information的item无需被软件测试验证。

• Functional Safety Requirement 功能安全需求

软件需求工程师设置用来表征该需求是功能安全相关，相应地，需求属性必须包含ASIL等级这些ISO26262要求的属性。

• Functional Requirement功能需求

软件需求工程师用来表征软件期望行为（区别功能安全需求）。

1. 陈述识别一个产品或者流程应产生什么结果（行为或者结果）。

2. 一个系统或系统组件应执行的需求。

• Nonfunctional Requirement 非功能需求

软件需求工程师应用来指示描述软件行为期望质量。与功能需求相比，该属性描述软件期望。这些期望无法达到预期不严重而且可以被接受。这不适用于功能/信息安全相关的重要的质量准则。性能属性:软件性能需求描述不是软件要做什么而是如何去做。（通常是软件和系统测试无法或很难测试，譬如：ECU应在接受制动信号后，20ms内给出制动响应、变化率等）。一般包含以下：

• 设计约束

• 性能要求

• 质量要求       

  2. 软件需求属性

2.1 软件属性之验证准则 Verification Criteria

Verification criteria define the qualitative and quantitative measures for the verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints, and are the input to test cases. 

验证准则为一条需求的验证定义定性和定量的措施。验证准则描述了一条需求在达成一致的约束范围内被验证，并且是测试用例的输入。

Verification criteria are necessary especially for non-functional requirements or to understand the preconditions for the test of a single or a set of requirements. It is used to answer “Under which condition, the requirement will be fulfilled?”. It will limit the verification condition, range and criteria. So, take the below into account:

对非功能性需求，或者为了理解单个需求或一系列需求的测试的前提条件，验证准则是极其必须的。被用来回答“在什么条件下，需求被满足？”会限制验证条件、范围和准则。因此，考虑以下：

1. Add verification criteria into SRS as the input of the subsequent test cases. 在SRS中增加验证准则，作为后续测试用例的输入。

2. Do not define verification criteria for some specific requirement if the description of this requirement could support to write test case. 针对一些特殊的描述可以用来支持写测试用例需求，无需定义验证准则。

2.2 Create Verification Criteria 创建验证准则

The verification criteria shall cover the following aspects: 

验证准则应覆盖以下方面：

1.Identification of the requirement to be verified 被验证的需求的识别（提炼）

2.Verification method 验证方法

3.Verification environment 验证环境

4.Preconditions and special conditions (e.g. winter diesel) 前提和特殊条件

5.Success criteria 成功准则

Identifying a verification method or verification step (e.g. software test, system test) is necessary, but insufficient for the verification criteria. If special test methods, environments, additional information or constrains are needed to be conducted or to be considered by the verification then this special information has to be documented.

识别验证方法或者验证步骤（例如：软件测试，系统测试）是必要的，但对验证准则而言，不够充分。如果特殊的测试方法、环境、额外的信息或者约束需要被实施，或者被验证考虑，那么这个特殊信息必须被文档化。

Verification criteria need to cover all requirements and can be defined for a single requirement or for groups of requirements.

验证准则需要覆盖所有的需求，而且能够为单个需求或者多组需求被定义。

Verification criteria have the following characteristics: 验证准则有以下特性：

• Be unambiguously assigned to a requirement. 被准确地分配给一条需求

• The requirement is thus verifiable or can be evaluated. 需求是可验证的或者能够内评估

• Verification criteria define the qualitative and quantitative criteria for determining a requirement has been implemented successfully. 为了决策一条需求被成功执行，验证准则定义了定性和定量的准则。

• They cover conditions under which a requirement can be tested. 覆盖需求能够被测试的条件。

• Show that a requirement can be verified under agreed boundary conditions.

表明在同意的边界条件下，需求能够被验证。

举例如下：

Requirement #1: ECU shall be able to identify whether EEPROM is corrupted. ECU应能够识别EEPROM是否损坏。

Verification criteria for Requirement #1: The status of EEPROM whether corrupted can be found by a checksum calculation by the diagnostic service “readCheckSumStatus”, related DTC could be reported. EEPROM是否损坏的状态可以通过诊断服务“readCheckSumStatus”的checksum计算被检测，然后上报相关DTC。

2.3 Verification Method 验证方法

Verification method includes: 验证方法包括：

1. test class (test) 测试类（单元测试、静态测试、资源占用率测试，功能测试，渗透性测试等等）
2. non-test class (e.g. inspections, peer reviews, audits, analysis (FMEA, FTA), simulation, walk-through,) 非测试类（例如：审查、同行评审、审核、分析（FMEA,FTA）,仿真）

Generally, for functional requirementsà Test class method. For non-functional requirementsà non-test class method. For example:

1. Non-functional requirement: cyclomatic complexity of software function < 10.
2. Verification method: use static analysis tool (QAC/ParaSoft).
3. All the requirements have to be verified.

总体而言：对功能性需求à 测试类方法。对非功能性需求à 非测试类方法。例如：

1. 非功能性需求: 软件功能的圈复杂度 < 10.
2. 验证方法: 使用静态分析工具(QAC/ParaSoft).

All the requirements have to be verified. 所有需求都必须被验证。

---

3. 软件需求编写规则

Software requirements have to be granular and understandable. Unclear or generic requirements have to be clarified with the system requirement owner.

软件需求必须颗粒化和易于理解。不清晰的或者概括性的需求必须和系统需求所有者澄清。

The emphasis of the requirement specification is clarifying ‘do what’ instead of ‘how to do’. ‘how to do’ is a matter in the software design and implementation phase. When writing the software requirements, we shall comply with the following rules:

需求重点在于阐述“做什么”而不是“如何做”。“如何做”属于软件设计实现阶段。当编写软件需求时，我们要遵守以下规则：

1. Correctness 正确性
2. Unambiguousness 确定性
3. Completeness 完整性
4. Consistency 一致性
5. Ranked for Importance or Stability 重要性和稳定性
6. Verifiability 可验证性
7. Traceability 追溯性
8. Technical feasibility 技术可行性
9. Atomicity 原子性
10. The former 1) necessity and 2) clear boundaries are deleted here.

---

3.1 Correctness 正确性

A SRS is correct only if every requirement stated therein is one that the software shall meet. There is no tool or procedure that ensures correctness. The SRS should be compared with any appliable superior specification (such as a system requirements specification), with other project documentation, and with other applicable standards, to ensure that it agrees. Alternatively, the customer or user can determine if the SRS correctly reflects the actual needs. Traceability makes this procedure easier and less prone to error.

只有当SRS中规定的每个需求都是软件应满足的需求时，它才是正确的。没有任何工具或过程可以确保正确性。应该将SRS与任何适用的上层规范（例如系统需求规范）、其他项目文档和其他适用的标准进行比较，以确保它们是一致的。或者，客户或用户可以确定SRS是否正确地反映了实际需求。可追溯性使这个过程更容易，更不容易出错。

3.2 Unambiguousness 确定性

A requirement is unambiguous only if every requirement stated therein has only one interpretation. At a minimum, this requires that each characteristic of the final product be described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific. The SRS should be unambiguous both to those who create it and to those who use it. However, these groups often do not have the same background and therefore do not tend to describe software requirements the same way. Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa.

只有当其中所述的每个需求只有一种解释时，需求才是明确的。至少，这需要使用一个唯一的术语来描述最终产品的每个特性。如果在特定上下文中使用的术语可能具有多种含义，则应将该术语包含在其含义更具体的术语表中。对于创建者和使用者来说，SRS都应该是明确的。然而，这些小组通常没有相同的背景，因此不倾向于以相同的方式描述软件需求。为开发人员改进需求规范的表示可能适得其反，因为它们减少了对用户的理解，反之亦然。

The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to be understood. Example

1. BMS shall set “SwtHvCtrK21==High” to cut off the HV positive contactor once upon the cell voltage is ≥700V when charging.

需求是以这样一种方式陈述的，因此它只能以一种方式解释。要求表述简单，易于理解。例子充电时：

1. 当电池电压≥700V时，bms应控制SwtHvCtrK21==High来切断高压主正接触器K1。

3.3 Completeness 完整性

An SRS is complete only if it includes the following elements:

1. All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular, any external requirements imposed by a system specification should be acknowledged and treated.
2. Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
3. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
4. No “To Be Determined” (TBD) labels. If there is a section containing a TBD it must also contain: a description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved, a description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated.

SRS只有包含以下要素才算完整：

1. 所有重要需求，无论是与功能、性能、设计约束、属性或外部接口有关。特别是，系统规范强加的任何外部需求都应该得到确认和处理。
2. 定义软件对所有可实现类型的输入数据在所有可实现类型的情况下的响应。注意，指定对有效和无效输入值的响应是很重要的。
3. SRS中所有数字、表格和图表的完整标签和参考资料，以及所有术语和计量单位的定义。无待定（待定）标签。如果有一个包含TBD的部分，它还必须包括：对导致TBD的条件的描述（例如，为什么答案不知道），以便解决这种情况，必须采取什么措施来消除TBD，谁负责消除它，以及必须在什么时候消除它。

3.4 Consistency 一致性

Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is neither consistent nor correct. An SRS is internally consistent only if no subset of individual requirements described in it conflicts. The three types of likely conflict in an SRS are as follows:

一致性是指内部一致性。如果SRS与一些上级文档（如系统需求规范）不一致，那么它既不一致也不正确。只有当其中描述的单个需求子集不冲突时，SRS才是内部一致的。SRS中可能出现的三种冲突类型如下：

1. Conflict among specified characteristics of real-world objects.

• The format of an output report may be described in one requirement as tabular, but in another as textual.
• One requirement may state that all lights should be green, while another may state that all lights should be blue.

2. Logical or temporal conflict between two specified actions.

• One requirement may specify that the program add two inputs, but another may
  specify that the program should multiply them.
• One requirement may state that “A” must always follow “B,” while another may
  require that “A and B” occur simultaneously.

3. Two or more requirements may describe the same real-world object but use different terms for that object. For example, a program’s request for a user input may be called a “prompt” in one requirement and a “cue” in another. Standard terminology and definitions use promotes consistency.

4. 现实世界对象的特定特征之间的冲突。

• 输出报告的格式可以在一个要求中描述为表格，但是在另一个作为文本的。
• 一项要求可能要求所有的灯都是绿色的，而另一项要求可能要求所有的灯都是蓝色的。

5. 两个指定动作之间的逻辑或时间冲突。

1. 一个要求可以指定程序增加两个输入，但另一个要求可以指定程序应该将它们相乘。
2. 一项要求可能规定“A”必须始终紧跟“B”，而另一项要求可能要求“ A和B ”同时发生。

6. 两个或多个需求可能描述相同的现实世界对象，但对该对象使用不同的术语。例如，程序对用户输入的请求在一个需求中可能被称为“提示”，而在另一个需求中可能被称为“暗示”。标准术语和定义的使用促进了一致性。

3.5 Ranked for Importance or Stability 基于重要性或稳定性排序

An SRS is ranked for importance and/or stability if each requirement in it has an identifier that indicates either the importance or stability of that particular requirement. Typically, requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-saving applications, while others may be desirable.

如果SRS中的每个需求都有一个标识符，表明该特定需求的重要性或稳定性，则SRS根据重要性和/或稳定性进行排名。通常，与软件产品相关的需求并不同等重要。有些需求可能是必要的，特别是对于救生应用程序，而其他需求可能是可取的。

Note:

1. The requirement description shall be concise and unambiguous.
2. Use active voice: describing who does what instead of that will happen.
3. Use attributives as little as possible: for example, words used as modifiers are usually adjectives. Attributive means uncertainty, especially for the verification standard description of non-functional requirements, the principle is transforming the qualitative description into the quantitative description.
4. Use the modal verb ‘shall’ as mandatory requirement (i.e. ‘system shall…’ or ‘controller shall…’), followed by an action, instead of words like could, may, etc.
5. Use natural language and diagram as a combination method to improve the readability, completeness and maintainability of the requirements. A certain grammatical structure can be applied to specify requirements, two structures are listed below:
6. [Condition][Subject][Action][Object][Constraint of Action]        Example: When signal x is received[Condition], the system[Subject] shall set[Action] the signal x received bit[Object] within 2 seconds[Constraint of Action].
7. [Subject][Action][Constraint of Action]     Example: The invoice system[Condition] shall display pending customer invoices[Action] in ascending order of invoice due date[Constraint of Action]
8. When there are two Actions in the requirement, it means that this requirement is not singular and it requires to be split.

注意：

1. 需求描述应简明、明确。
2. 使用主动语态：描述谁做了什么，而不是将会发生什么。
3. 尽量少用定语：例如，用作修饰语的词通常是形容词。属性意味着不确定性，特别是对于非功能需求的验证标准描述，其原则是将定性描述转化为定量描述。
4. 使用情态动词“shall”作为强制性要求（即“system shall…”或“controller shall…”），后面跟着一个动作，而不是像could， may等词。
5. 使用自然语言和图表相结合的方法，提高需求的可读性、完整性和可维护性。可以采用一定的语法结构来指定要求，下面列出了两种结构：
6. [Condition][Subject][Action][Object][动作约束]示例：当接收到信号x [Condition]时，系统[Subject]应在2秒内设置[Action]接收到的信号x位[Object][动作约束]。
7. [主题][操作][操作约束]示例：发票系统[条件]应按发票到期日升序显示待处理的客户发票[操作][操作约束]
8. 当需求中有两个动作时，表示该需求不是单一的，需要拆分。

---

4. 需求分析方法

4.1 工具和方法

软件需求可以维护在ALM系统中，譬如：doors，codeBeamer等，JIRA适合互联网行业，并不合适颗粒度较细的汽车级控制器开发。同时可以使用 UML、Visio 和 EA 作为辅助工具进行软件需求分析，方法如下：

• 例图
• 序列图
• 活动图
• 状态图

注：SRS 将以文字和图表两种形式完成，以使软件架构师和软件开发工程师进一步理解 SRS。

4.2 具体分析方法

从系统分析方面来看，需求分析方法可以分为四类：

• 功能分解法。
• 结构分析法。
• 信息建模方法。
• 面向对象分析方法。

在 ecu 的软件开发过程中，当采用功能分解和结构分析方法时，通常将 UML 应用于软件需求分析中。

在分析过程中，同步编写符合 2.3 规则的文本化需求，并按照以下方法对需求进行结构化描述： 

• 功能用例的定义。
• 操作场景和顺序分析。
• 根据功能用例进行结构功能分解。
• ecu 软件接口分析与描述。

文本需求对于具体细节是有效的，但当需要提供需求的相互关系和上下文时，则无效。因此，图或模型（用例、UML、Simulink 模型）是软件需求规范中促进可读性和完整性所必需的部分。

分析过程完成后，就可以得到软件需求和接口需求。

4.3 对运行环境的影响

对运行环境影响的分析，既包括对范围内软件的影响，也包括对其他软件部件、其他系统或整车考虑以下可能部件的影响：

• 接口

1. 信号及信号质量
2. 电压和电流

• 环境

1. 温度
2. EMC

• 性能

1. 接口响应时间（信号响应、采样时间、周期时间、总线负载、信号延迟、抖动）
2. 微控制器响应时间（处理时间）

• 资源

1. RAM / ROM 内存使用情况
2. EEPROM / DataFlash 内存使用情况

软件/系统交互的其他系统或系统元素（如硬件），构成软件/系统的操作环境。它可以被看作是“固定的”。

---

未完待续。。。

---

参考文章

1. 软件需求开发管理-软件需求分类和验证准则
2. 软件工程：软件需求之需求编写规则
3. 软件工程：软件需求之需求分析方法