需求性文件对于产品开发的重要性不用多说，研发中的许多问题都是由于不完整的、不成熟的、不正确的、模糊有歧义的、糟糕的系统需求而引发的。对于功能安全领域，如何开发出安全、可靠的产品，良好的系统需求性文件是关键的一个环节，笔者将结合功能安全标准以及实践经验，来讲讲如何写好功能安全产品系统需求的一些良好实践方法。
本文福利：分享报告《2022中国薪酬报告》，公众号对话框回复【汽车ECU开发009】下载。
需求的结构化
系统需求应采用结构化的方法，根据需求类型进行分类，逐级细化，拆分到最简单直观的层次，常见的结构化分类方式包括：
系统应用场景及任务概要；
输入文件；
参考标准；
功能需求（包括安全功能及对应的安全目标，和非安全功能）；
性能需求；
接口需求；
环境适应性需求；
可信性需求（可靠性、可用性、可维护性、维修保障）；
系统约束和假设；
其它。
其中1，2，3，9，10为系统需求的描述性内容（information），为4，5，6，7，8提供支撑，而4，5，6，7，8则为系统需求的正式内容（specification）。
需求的基本属性
EN50126、DO-178C、ISO26262都有对需求属性的基本要求，包括：
完整性（complete）：每个需求项应包括对应此项的全部必要信息，不需要进一步扩展；
正确性（precise）：需求描述的内容如功能定义、性能要求等是正确的；
无歧义（unambiguous）：不能模棱两可，需求只能有一个解释，设计实现者可以无歧义地理解；
可验证（verifiable）：需求是可验证的，通过评审、分析或测试的验证方法，以确定需求被正确的实现，对于可测性需求能够对照需求完成测试用例；
可追踪（traceable）：需求的可追踪性以便其可以追踪到更底层的需求，纵向追踪如软件到代码级，硬件到板级，横向追踪如需求与测试用例之间的对应关系；
可维护（maintainable）：需求条目的修改、删除、增加是清晰可见的，项目内部对于需求的更新有着一致的认识。
为什么需求有着以上的属性，有些人认为我是这么想的，写这么复杂干什么。系统需求在产品开发生命周期中作为顶层文件，不同的参与方都将利用系统需求开展开发、安全分析、验证确认等工作，因此需求必须明确、清晰、简洁，以易于理解。
下面举一些示例来说明下什么是良好的需求。
良好需求的示例
1.系统功能需求
系统功能应逐级分解，以致到最低层不可再分解的条目。如图，以制动系统的紧急制动功能为例，从顶层功能向下分解，包括EB1（制动指令获取）、EB2（制动指令传递）、EB3（列车载荷计算）、EB4（紧急制动力计算）、EB5（部分制动力丧失后再分配）、……。每个子功能再按照输入-处理-输出的逻辑关系进行描述。
系统需求结构化示例
2.安全相关功能需求
对于安全相关功能，不仅应标记出从风险分析分配的安全目标（SIL等级），而且在需求的通用属性要求外，还应规定：
安全侧（safe state）定义；
定义从故障发生、系统检测到故障到进入到安全侧的最大允许时间，轨道交通叫做SDT（safe down time），汽车叫做FTTI（fault tolerant time inteval）
FTTI时间指标定义
故障诊断安全措施，常见的故障诊断措施如
输入数据的非预期性，是否超限、数据冻结不更新、短路、开路等；
通信链路的七类典型失效模式及防护措施；
冗余数据的比较，输入数据、输出指令的比较；
CPU、内存中内部错误，各类自检机制。
采用哪些故障诊断措施，依赖于系统的危害分析以及选定的安全完整性等级。
安全功能的目标在于防范风险，系统完整性在于系统的健壮性，因此更多考量的是各种故障场景下，系统是否有监控、差异化的故障诊断和响应机制，保障系统发生导向危险失效后能够在规定的时间内导向安全侧。因此对于安全功能要求，以上三点要求缺一不可。
3.可信性需求
轨道交通常称为RAM需求，包括可靠性、可用性、可维护性和维修保障，常用MTBF、MTTR、可用性A等定量指标进行规定，但在规定定量指标前，确定系统的下述属性非常重要：
系统的应用场景和任务概要——以确定可信性指标对应的系统是在何种应用场景下，执行哪些任务；
系统失效判据——根据系统失效的影响范围，可以将指标进行有区分度的定义，比如影响列车安全的故障、影响列车服务的故障、未对服务质量产生影响但需要维修保障的故障，对应的可信性指标是不同的；
系统的工作条件和环境条件；
用于验证指标符合预期的方法。
4.性能需求
可以划分为时间性需求和空间性需求，时间性需求有系统运行周期、响应延时、上电启动时间、重启时间等；
空间性需求有内存容量、处理器容量、通信缓存容量、带宽容量，考虑未来的可扩展性和灵活性。
5.文字和图形化的结合
采用图文结合的方法用于需求编写，如
系统接口图——用于描述系统内外部接口，并在接口需求再详细描述接口规格；
状态转移图——用于描述系统不同模式之间的转换关系，每个状态用文字描述；
数据流图——用于描述不同系统之间的数据流和时序关系。
但应注意图形并不能完全替代文字，而是作为文字的辅助，帮助阅读者的理解。
其它还有一些通用性的需求，如可测试性、可制造性等，不再赘述。另外，现代安全关键系统的需求编写，还常采用形式化/半形式化、基于模型的设计方法，下面讲讲这些方面。
首先应该了解需求的一些特性要求，需求的要求分为单个需求项要求和一组需求的整体要求。
单个需求项应符合以下要求：
单一的：一条需求是一个明确的，不可分割的元素，它表达的是唯一的一个要求；
简洁的：一条需求必须以单个句子的形式来写，长度不要超过两到三行，大段的文字需要断句分开；
清晰的：句子结构简单，不拖泥带水，没有额外的修饰，阅读者可以完全理解需求；
精确的：需求中使用的所有元素都是可识别的，并有充分的特征；
抽象的：一条需求只是描述需求，不应该是一个具体的技术实现方案；
无二义性的：对该需求的解读应有助于对该需求的理解，并只有一种可能的解释，要用简洁的语言表达，不要用太复杂的句子；
可验证的：必须有一种可行的验证需求的方法，常用的方法有走读、建模、分析、测试；
可实现的：从成本和进度上考虑，需求是可实现的。
由单个需求项构成的一组需求，应符合以下要求：
完整的：没有遗漏的需求，需求集的内容是完整的。完整性比较难以判断，它与需求分析的详尽程度有关。在项目中的需求编写过程，容易忘记定义软件需求在不希望发生的事件中的行为（比如硬件故障，用户输入的数据错误等等）。在确定需求的过程中，有必要检查这些需求是否包括在内，不要让软件实现人员去考虑这些问题；
一致的：需求之间不能有不一致的地方，并在文件中有唯一的标识，需求中使用的专用词汇在每条需求中的表达要一致；
非冗余的：在一组要求中，相同的信息和需求不应多次出现，只表达一次；
充分的：需求的内容是充分的，不需要为了理解需求，去回顾需求之外的其它文件；
结构化的：需求集有清晰的结构，如软件需求按照类别分为功能、接口、性能、硬件约束、安全性、可维护性、可靠性、可用性、可移植性、健壮性等；
模块化的：同一类型的需求应放在一个明确的结构内进行分组；
可扩展的：有灵活的结构，适应需求的变更；
可追溯的：需求与其它项目文件（上下层集）建立追溯关系。
每条需求除了它的内容外，还具备以下这些属性：
| 属性 | 描述 |
| ID | 需求的唯一标识符 |
| 类型 | 功能、接口、RAM、性能、…… |
| TEXT | 需求的内容 |
| SOURCE | 需求的来源 |
| STATE | 开发中、挂起、已实现、已测试、…… |
PRIORITY | Key, mandatory, optional, desirable |
| Verifiable | 是/否 |
| type of Verification | 走读、分析、建模、测试 |
| Testable | 是/否 |
| Version | 版本 |
在了解以上需求的要求和各类属性后，如何编写需求以符合以上的要求。需求表达可以采用自然语言和模型语言两种方法或它们的组合，现在有一种认识，认为模型语言要比自然语言更高级，但是模型的建立并不能替代自然语言表达的需求，如果需求编写者用自然语言表达出来的需求是模棱两可的，那也不能奢望他用模型语言能够表达清楚。
从实践来说，推荐两种方法相结合，在高层次的需求，用自然语言表达更恰当，可以结合一些半形式化方法（公式、图形、表格、流程图、时序图或其它UML和SysML）作为补充；
在低层次的需求，定义了精确的硬件和软件行为，采用形式化或半形式化方法更合适，但也没有必要每条需求都用。
EN50128 软件需求推荐的技术方法
ISO26262 安全需求推荐的技术方法
自然语言（文本语言）作为需求表达的基本方法，人们在日常表达经常存在歧义，在需求管理中，经常会举下面这个例子。
以上这个例子虽然有些夸张，但实际项目中不同的人由于知识背景、社会背景和经验能力的差别，对同一需求的理解确实千差万别，需求和设计实现出现这么大的差异也就不足为怪了。
在需求的表达上有基本的规则可以遵循，建立一个需求模板是很有必要的，使得需求简单且易于理解，减少自然语言对语义表达的影响。
在Klaus Pohl. Chris Rupp的《Requirements Engineering Fundamentals》一书中，推荐了一类描述功能需求的自然语言模板如下：
在这个模板框架中，采用"主语+动词+宾语+补语 "的结构，要求的强烈程度分为SHALL/SHOULD/WILL/MAY，需求的过程表达了三种行为：
系统自动执行该过程；
THE SYSTEM SHALL/SHOULD/WILL/MAY
系统提供该过程作为给用户的服务；
THE SYSTEM SHALL/SHOULD/WILL/MAY provide
系统根据另一个系统的输入执行流程，系统等待外部触发事件执行；
THE SYSTEM SHALL/SHOULD/WILL/MAY be able to
最后additional details中，用于确定系统在什么条件下执行该流程，常见的条件有逻辑条件和时间条件。
第二个减少需求理解的冲突和误解的方法是，尽早地建立一份项目组共享的术语、缩写和缩略语清单，它包括：
与系统特定相关的技术类术语；
缩写和首字母缩略词；
日常语义在给定的场景中特殊含义；
具有相同含义的不同词；
具有不同含义的相同词。
通过定义术语列表，可以大大提高需求的可理解性，从一开始就避免对可能导致冲突的术语的误解和不同的解释。
参考文件：
EN50126-1 2017 Railway Applications - The Specification and Demonstration of Reliability, Availability, Maintainability and Safety (RAMS) Part 1: Generic RAMS Process
EN50129 2018 Railway applications – Communication, signalling and processing systems – Safety related electronic systems for signalling
ISO26262-4 2011 Road vehicles - Functional safety -Part 4: Product development at the system level
基于功能安全的示例AUTOSAR软件系统
关于对汽车ECU软件测试的理解
特斯拉最新中央计算模块(CCM)解析
2021款特斯拉Model Y ECU接口梳理
详解CANoe之CAPL编程
关于CAN时间同步的理解
dbc文件的格式以及创建详解
大众ID.4 X网络架构详解
基于UDS的Bootloder详解
关于整车上下电流程的理解
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
