需求工程基础：需求类型、需求来源、需求属性

大家好，我是老张。今天咱们聊聊需求工程里最基础，但也最容易翻车的一块——需求类型、来源和属性。

说实话，我见过太多项目，开发到一半才发现需求没写清楚。不是功能漏了，就是性能指标没对齐。最后大家互相甩锅，项目延期。嗯，这里我要强调一句：需求工程做不好，后面全是坑。

一、需求类型：功能、非功能、系统

咱们做ECU开发的，需求一般分三类。我习惯把它们比作“车要能跑”、“跑得稳”、“怎么装到车上”。

1. 功能需求

功能需求说白了就是“系统要做什么”。比如：

• 当车速超过120km/h时，仪表盘发出报警声
• 按下雨刮开关，雨刮器以低速模式运行
• CAN总线接收到制动信号后，在100ms内点亮刹车灯

我在项目中遇到过最典型的例子：客户说“我要一个自动大灯功能”。结果开发完了才发现，客户要的是“根据环境光自动切换远近光”，而我们只做了“根据环境光自动开关大灯”。你看，一句话没写清楚，返工两周。

2. 非功能需求

非功能需求，说白了就是“系统要做得怎么样”。它不直接描述功能，但决定了功能的品质。

常见的非功能需求包括：

• 性能：CPU负载率不超过70%，内存占用不超过512KB
• 可靠性：系统连续运行1000小时无故障
• 安全性：满足ISO 26262 ASIL B等级要求
• 可维护性：软件模块化设计，单个函数不超过200行

我曾经吃过一次亏。一个项目，功能需求写得清清楚楚，但非功能需求里只写了“系统稳定”。结果测试时发现，高温环境下ECU频繁重启。客户问：“你们测试过温度范围吗？”我们答：“没写啊。”嗯，从那以后，我要求每个项目必须把非功能需求列成表格，逐条确认。

3. 系统需求

系统需求是站在整车层面看的。它描述的是“系统与系统之间的交互”。比如：

• BCM与网关之间通过CAN总线通信，波特率500kbps
• ECU在休眠模式下电流消耗不超过100μA
• 系统上电后，必须在200ms内完成自检并进入工作状态

系统需求往往涉及多个ECU的协同。我建议用接口定义表来管理，避免遗漏。

二、需求来源：别只盯着客户

很多人以为需求就是客户给的。其实不然。我总结了一下，需求来源至少有五个方面：

1. 客户/市场：这是最直接的。比如“我们要一个自动泊车功能”。但要注意，客户说的往往不是真正的需求，而是解决方案。你要深挖背后的“为什么”。
2. 法规/标准：比如GB/T 32960、ISO 26262、ECE R10等。这些是强制性的，不满足就不能上市。我见过一个项目，因为没考虑EMC标准，最后测试不通过，重新改板子，损失几十万。
3. 内部平台/复用：公司已有的平台架构、软件模块、硬件接口。比如“新项目必须兼容现有CAN协议”。这能减少开发成本，但也会限制设计自由度。
4. 竞品分析：对标竞品的功能和性能。比如“我们的雨刮响应速度要比竞品快20%”。
5. 历史项目经验：之前项目踩过的坑、客户投诉、售后反馈。这些往往是隐性需求，但非常重要。

三、需求属性：给每个需求贴上标签

需求不是写出来就完事了。每个需求都要有明确的属性，方便管理、追踪和验证。我个人习惯用以下属性：

• ID：唯一标识，比如REQ-FUNC-001
• 名称：简短描述，比如“雨刮低速模式”
• 描述：详细说明，包括输入、输出、触发条件、行为
• 优先级：高/中/低。高优先级的需求必须实现，低优先级可以推迟
• 来源：客户/法规/内部/竞品
• 状态：草稿/已评审/已批准/已实现/已验证
• 责任人：谁负责实现这个需求
• 版本：需求变更时更新版本号

举个例子：

四、总结一下

需求工程不是写文档，而是管理信息。功能需求、非功能需求、系统需求，三者缺一不可。需求来源要全面，别只盯着客户。需求属性要完整，方便追踪和变更管理。

嗯，今天就聊到这儿。下一章咱们讲讲需求如何分解和分配，那是从需求到设计的关键一步。

公众号:蓝海资料掘金营，微信deep3321