4、DOORS需求编写：需求属性定义、需求文本编写规范、使用富文本格式

好，咱们进入第四章。这一章我打算聊聊DOORS里最基础、但也最容易被忽视的活儿——怎么写需求。

你可能会想：「写需求谁不会？不就是打字吗？」

嗯，我当年也是这么想的。直到有一次，我接手一个项目，发现前任留下的需求文本，读了三遍愣是没看懂。有的需求写了半页纸，有的就一句话「系统应正常工作」。你说这怎么往下做？

所以，今天咱们就把这件事掰开揉碎了讲清楚。

4.1 需求属性定义：给每条需求贴上标签

在DOORS里，每条需求不只是一段文字。它是一组数据的集合。我习惯把需求比作一个「档案袋」，袋子上贴着各种标签。

这些标签，就是属性。

为什么要定义属性？说白了，就是为了后期能快速筛选、追溯、做影响分析。你想想看，几百上千条需求，如果没有属性，你怎么找？一条条翻？

我个人建议，至少定义以下几类核心属性：

属性类别	属性名称	说明	示例值
标识类	需求ID	系统自动生成，唯一标识	REQ-ACC-0012
标识类	需求名称	简短标题，一看就懂	ACC目标车检测
层级类	需求类型	区分系统/功能/子系统	系统需求
状态类	状态	生命周期阶段	已评审 / 已批准
追溯类	来源	来自哪个更高层需求	REQ-SYS-0005
验证类	验证方法	如何证明需求被满足	测试 / 分析 / 演示
优先级	优先级	实现的重要程度	高 / 中 / 低

我在项目中遇到过一种情况：团队没有定义「验证方法」这个属性。结果到了项目后期，测试工程师跑来问我：「这条需求怎么测？」我一看，需求写的是「系统应具有良好的性能」……你说这怎么测？

所以，属性定义这件事，一定要在项目启动时就定好。别等到需求写了一大堆再回头补，那工作量会让你崩溃。

4.2 需求文本编写规范：把话说清楚

好，属性贴完了，接下来是正文。

需求文本怎么写？我总结了四个字：清晰、唯一。

什么叫清晰？就是别人看了不会产生歧义。什么叫唯一？就是一条需求只表达一个意思。

我见过最糟糕的需求长这样：

系统应能在检测到前方车辆时自动减速，并在必要时发出警告，
同时记录相关数据，且系统应支持OTA升级。

你数数，这里面塞了几个功能？检测、减速、警告、记录、OTA升级……这根本就是五条需求揉在一起了。

正确的写法应该是：

REQ-ACC-0010：当ACC系统检测到前方目标车辆时，应自动调节本车车速，
以保持设定的安全跟车距离。

REQ-ACC-0011：当ACC系统判定需要紧急减速时，应通过HMI向驾驶员发出视觉和听觉警告。

REQ-ACC-0012：ACC系统应记录每次激活和退出事件的时间戳及相关状态数据。

REQ-ACC-0013：ACC系统应支持通过OTA方式进行软件升级。

你看，每条需求只讲一件事。这样后期做变更影响分析时，你才能精准定位。

另外，我建议遵循以下几条编写规范：

• 使用「应」字：表示强制性要求。不要用「可以」、「可能」、「应该」这类模糊词。
• 避免否定句式：尽量写「系统应做什么」，而不是「系统不应做什么」。否定句式容易遗漏边界条件。
• 量化指标：能用数字的，别用形容词。「快速」改成「小于200ms」，「足够远」改成「大于50米」。
• 上下文独立：每条需求读起来应该能自解释，不需要翻看其他需求才能理解。

4.3 使用富文本格式：让需求更好读

DOORS支持富文本格式。很多人觉得这就是个花架子，其实不然。

我举个例子。你写一条需求：

当车速大于30km/h且小于120km/h时，系统应激活ACC功能。

这种纯文本，读起来是不是有点费劲？尤其是条件多了以后。

如果用富文本格式，我会这样写：

当满足以下所有条件时，系统应激活ACC功能：
• 车速：大于30 km/h 且 小于120 km/h
• 挡位：D挡 或 M挡
• 制动状态：未踩下制动踏板
• 系统状态：无故障

你看，用加粗突出关键数值，用列表分条列出条件。是不是一目了然？

我个人常用的富文本技巧包括：

• 加粗：用于突出关键数值、条件、对象名称
• 列表：用于枚举多个条件、多个输出、多个场景
• 颜色标记：我习惯用红色标注「必须满足」的条件，用蓝色标注「可选」条件
• 表格：当需求涉及输入输出映射关系时，表格比文字更清晰

举个例子，用表格描述ACC的激活条件：

条件	要求	备注
车速范围	30 km/h ~ 120 km/h	含边界值
挡位	D 或 M	N/P/R挡不激活
制动踏板	未踩下	踩下时退出ACC
系统故障	无	含传感器、执行器、通信

不过，这里我要提醒一句：富文本是工具，不是目的。别为了好看而过度使用。我见过有人把需求写得跟PPT似的，五颜六色，各种字体。结果导出成文档时，格式全乱了。

小结一下

这一章我们聊了三件事：

• 属性定义：给每条需求贴上标签，方便后期管理和追溯
• 文本规范：清晰、唯一、量化、独立，别写模棱两可的话
• 富文本格式：用加粗、列表、表格让需求更好读，但别过度

嗯，这些看起来都是基本功。但说实话，我见过太多项目，就是栽在这些基本功上。需求写不清楚，后面设计、开发、测试全在猜。猜来猜去，项目就延期了。

所以，别嫌我啰嗦。把这些基础打牢了，后面的路才好走。

下一章，我们聊聊怎么用DOORS做需求追溯矩阵。那可是个大活儿。