3、需求工程基础：需求的定义与分类（功能/非功能/系统/软件）、需求属性
各位同学，咱们今天聊聊需求工程的基础。说实话，我见过太多项目栽在需求上。不是需求写得太模糊，就是分类搞混了。最后开发出来的东西，跟客户想要的完全是两码事。
为什么会这样？说白了，很多人对需求的理解还停留在「用户说要什么，我们就做什么」的阶段。但在汽车行业，尤其是ASPICE框架下，需求管理是一门严谨的工程学科。
3.1 需求的定义：到底什么是「需求」？
先给个标准定义。在系统工程里，需求是对系统或组件必须满足的能力、条件或约束的正式描述。嗯，这个定义有点绕。我换个说法：需求就是「系统应该做什么」和「系统应该做成什么样」的明确陈述。
我个人习惯把需求拆成三个要素：
- 谁需要？ — 需求的来源（客户、法规、内部标准）
- 需要什么？ — 具体的能力或属性
- 在什么条件下？ — 场景、边界、约束
我在项目中遇到过一种情况：客户说「我要一个安全的刹车系统」。这句话算需求吗？当然不算。它太模糊了。什么叫「安全」？是响应时间小于100ms？还是失效概率低于10^-8？没有量化，开发人员根本没法落地。
核心原则：好的需求必须是明确的、可验证的、无歧义的。如果你写出来的需求，两个人看了有两种理解，那这个需求就是不合格的。
3.2 需求的分类：功能 vs 非功能
需求分类是需求工程的基础。你想想看，如果连需求类型都分不清，后面怎么分配、怎么追溯？
3.2.1 功能需求
功能需求描述的是系统「做什么」。它直接对应系统的行为或功能。比如：
- 「当车速超过120km/h时，系统发出报警声」
- 「用户按下解锁键后，车门在500ms内解锁」
这些需求很直观，开发人员一看就知道要写什么代码、做什么逻辑。
3.2.2 非功能需求
非功能需求描述的是系统「做得怎么样」。它关注的是质量属性、约束条件。比如：
- 「系统在-40°C到85°C的环境下正常工作」
- 「系统启动时间不超过2秒」
- 「系统满足ISO 26262 ASIL B安全等级」
我记得有一次，团队把所有精力都放在功能实现上，结果到了集成测试阶段，发现系统在高温下频繁死机。为什么？因为非功能需求里写了「工作温度范围」，但没人当回事。嗯，这个教训挺深刻的。
我的建议：非功能需求往往比功能需求更难验证。功能需求你写个测试用例就能测，但非功能需求（比如可靠性、可维护性）需要专门的测试策略。所以，写非功能需求时，一定要同时定义验证方法。
3.3 需求的层级：系统 vs 软件
在ASPICE里，需求是有层级关系的。你不能把系统需求和软件需求混在一起写。我见过一些项目，需求文档里既有「整车加速性能」又有「CAN报文发送周期」，这明显是层级混乱。
3.3.1 系统需求
系统需求是从系统层面描述的需求。它关注的是整个系统（包括硬件、软件、机械、电气等）的行为和属性。比如：
- 「系统在接收到制动信号后，200ms内产生制动力」
- 「系统支持OTA远程升级」
系统需求不关心具体是软件实现的，还是硬件实现的。它只关心「系统整体要达成什么」。你想想看，如果系统需求里写了「软件需要...」，那其实已经是在做软件需求了，层级就乱了。
3.3.2 软件需求
软件需求是从系统需求分解出来的，专门针对软件部分的需求。它描述的是软件组件必须实现的功能和属性。比如：
- 「软件模块A在接收到CAN报文ID 0x123后，解析出车速值并更新全局变量」
- 「软件模块B的看门狗喂狗周期不超过50ms」
这里有个关键点：软件需求必须可追溯到系统需求。你不能凭空写一个软件需求，它必须是为了满足某个系统需求而存在的。我曾经在评审时发现，有个软件需求写了「每100ms记录一次日志」，但翻遍系统需求，根本找不到对应的要求。这种需求就是多余的。
注意：系统需求和软件需求之间不是一一对应的关系。一个系统需求可能分解成多个软件需求，也可能同时涉及软件和硬件。比如「系统在2秒内启动」，可能软件需要1.5秒完成初始化，硬件需要0.5秒完成上电。这时候，软件需求和硬件需求都要写清楚。
3.4 需求属性：不只是写内容
很多新手写需求，只关注「内容」本身。但真正的需求管理，还要关注需求的「属性」。属性就是描述需求本身的数据。我把它比作「需求的身份证」。
常见的需求属性包括：
| 属性名称 | 说明 | 示例 |
|---|---|---|
| ID | 唯一标识 | REQ-SYS-001 |
| 类型 | 功能/非功能/约束 | 功能需求 |
| 优先级 | 高/中/低 | 高 |
| 状态 | 草稿/已评审/已批准/已实现/已验证 | 已批准 |
| 来源 | 客户/法规/内部 | 客户需求文档第3.2节 |
| 版本 | 变更历史 | V1.2 |
| 责任人 | 谁负责编写/维护 | 张三 |
为什么要关注属性？我举个例子。有一次项目评审，大家争论一个需求要不要实现。有人说「这个需求优先级是低，先放一放」，另一个人说「不对，这是法规要求，必须做」。结果一查属性，发现「来源」字段写的是「客户建议」，不是「法规」。问题一下就清楚了。
实战建议：在需求管理工具（比如DOORS、Polarion、Jama）里，属性字段一定要配置好。我个人习惯至少保留：ID、类型、优先级、状态、来源、版本、责任人。这些属性在ASPICE审核时是必查项。
3.5 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历过的教训：
- 坑一：需求写得太细 — 我曾经见过一个软件需求，把每一行代码的逻辑都写进去了。这已经不是需求了，是详细设计。需求应该关注「什么」，而不是「怎么实现」。
- 坑二：非功能需求被忽略 — 项目初期大家都很重视功能需求，但非功能需求往往被当成「锦上添花」。结果到了测试阶段，性能、安全性、可靠性问题全冒出来。改起来成本极高。
- 坑三：需求属性不维护 — 需求写完了，属性就再也没更新过。状态永远是「草稿」，版本永远是「V1.0」。审核时被问「这个需求实现了吗？」没人能回答。
嗯，说了这么多，其实核心就一句话：需求是工程的起点，起点错了，后面全白干。下一章咱们聊聊需求获取的方法，到时候我会分享一些跟客户「斗智斗勇」的经验。
课后小练习：找一份你手头的需求文档，试着给每个需求补充属性字段。看看你能不能把「类型」「优先级」「来源」都填清楚。如果填不出来，说明需求本身可能就有问题。