4. 需求文档编写：需求类型、需求属性、需求描述规范

好，咱们进入正题。需求文档怎么写，这问题我聊过很多次了。说实话，很多团队栽就栽在需求上。不是技术不行，是需求写得一塌糊涂。我见过一个项目，光需求理解偏差就浪费了三个月。嗯，今天我把我的经验掰开揉碎讲给你听。

4.1 需求类型：你得先分清楚

需求不是铁板一块。我个人习惯，先把它分成三类。你想想看，如果连类型都搞混，后面评估、测试全得乱套。

需求类型	英文缩写	一句话解释
功能需求	FUN	系统要「做什么」
非功能需求	NF	系统要「做到什么程度」
约束条件	CON	系统「不能怎么做」

我在项目中遇到过，有人把「响应时间小于100ms」写成了功能需求。这其实是非功能需求。功能需求说的是「当用户按下按钮，系统执行刹车动作」。而响应时间，那是性能指标。分清楚，后面测试用例才好写。

4.2 需求属性：别漏了关键信息

光写一句话可不够。每个需求都得带上「身份证」。我建议至少包含以下属性：

• 唯一标识符：比如 REQ-FUN-001。别用数字编号，容易乱。
• 需求来源：客户提的？法规要求的？还是内部定义的？
• 优先级：高、中、低。我习惯用 MoSCoW 方法：Must have, Should have, Could have, Won't have。
• 状态：草稿、已评审、已批准、已实现、已验证。
• 风险等级：高、中、低。这个跟 ASIL 等级挂钩。

为什么会这样？因为属性多了，大家就不填了。你想想看，一个需求文档，属性栏全是空的，那跟没写有什么区别？

4.3 需求描述规范：怎么写才不挨骂

这部分是重头戏。我直接给你一套模板，照着写就行。

4.3.1 一句话原则

每个需求，用一句话说清楚。别写长句子。我见过有人一个需求写了200字，读三遍没读懂。说白了，那就是没想清楚。

正确示范：

当车速大于30km/h时，系统应自动锁止车门。

错误示范：

考虑到车辆在行驶过程中可能存在安全隐患，为了保障乘客安全，系统需要在车速达到一定阈值时执行车门锁止操作，该阈值初步设定为30km/h。

你看，第一个多清爽。第二个绕来绕去，核心信息全埋在里面了。

4.3.2 使用主动语态

「系统应执行...」而不是「...应被系统执行」。主动语态更清晰，责任方一目了然。

4.3.3 可验证性

每个需求写完，你问自己一句：这能测试吗？如果不能，重写。

不可验证的写法：

系统响应应足够快。

可验证的写法：

从接收到制动请求到制动执行器开始动作，响应时间应小于50ms。

你看，加了具体数值，测试工程师就知道怎么测了。拿个示波器一抓，数据说话。

4.3.4 避免模糊词汇

「大概」「可能」「应该」「尽量」——这些词在需求文档里就是毒药。我建议你写完后，全文搜索一遍，把这些词全干掉。

❌ 不要用	✅ 改用
系统应尽量在1秒内响应	系统应在1秒内响应
故障灯可能点亮	当检测到A类故障时，故障灯应在2秒内点亮
数据应大致准确	数据误差应在±2%以内

4.4 需求文档的结构模板

最后，我给你一个我常用的结构。你直接套用就行。

1. 引言
   1.1 目的
   1.2 范围
   1.3 术语定义

2. 功能需求
   2.1 功能需求列表
   2.2 功能需求详细描述

3. 非功能需求
   3.1 性能需求
   3.2 安全需求
   3.3 可靠性需求
   3.4 可维护性需求

4. 约束条件
   4.1 技术约束
   4.2 法规约束
   4.3 接口约束

5. 需求追溯矩阵

好了，需求文档这块，核心就是这些。记住：清晰、可验证、无歧义。你按这个标准写，ASPICE评估基本不会在这块扣分。下次咱们聊聊需求评审，那又是另一门学问了。