物有本末，事有终始。知所先后，则近道矣。对软件开发而言，软件需求乃重中之重。必先之事重千钧，不可或缺如日辰。
汽车行业由于有方法论和各种标准约束，对软件开发有严苛的要求。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****功能需求
软件需求工程师用来表征软件期望行为（区别功能安全需求）。
-
陈述识别一个产品或者流程应产生什么结果（行为或者结果）。
-
一个系统或系统组件应执行的需求。
- 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:
对非功能性需求，或者为了理解单个需求或一系列需求的测试的前提条件，验证准则是极其必须的。被用来回答"在什么条件下，需求被满足？"会限制验证条件、范围和准则。因此，考虑以下：
-
Add verification criteria into SRS as the input of the subsequent test cases. 在SRS中增加验证准则，作为后续测试用例的输入。
-
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: 验证方法包括：
- test class (test) 测试类（单元测试、静态测试、资源占用率测试，功能测试，渗透性测试等等）
- 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:
- Non-functional requirement: cyclomatic complexity of software function < 10.
- Verification method: use static analysis tool (QAC/ParaSoft).
- All the requirements have to be verified.
总体而言：对功能性需求à 测试类方法。对非功能性需求à 非测试类方法。例如：
- 非功能性需求: 软件功能的圈复杂度 < 10.
- 验证方法: 使用静态分析工具(QAC/ParaSoft).
All the requirements have to be verified. 所有需求都必须被验证。
引用文章：