需求工程基础：从“拍脑袋”到“有章法”
大家好，我是你们的老朋友。今天咱们聊聊需求工程。说实话，我见过太多项目，前期需求没搞明白，后期疯狂改代码。那种痛苦，经历过的人都懂。
需求工程，说白了就是一套把“客户想要什么”变成“我们能做什么”的方法论。它不是简单的“记笔记”，而是一个系统化的过程。
需求工程的定义与目标
先给个定义。需求工程是系统化地发现、分析、记录、验证和管理需求的工程方法。它的目标很明确：确保最终产品真正满足用户需要。
我个人习惯把需求工程的目标拆成三点：
- 理解问题域：搞清楚用户到底在什么场景下遇到什么问题。
- 明确解决方案：我们要做什么来帮用户解决这个问题。
- 达成共识：客户、开发、测试，所有人对“做什么”的理解一致。
我在项目中遇到过最典型的反面教材：客户说“我要一个智能门锁”，结果开发直接开始写蓝牙协议栈。后来才发现，客户要的是能远程开锁，至于用蓝牙还是WiFi，人家根本不在乎。你看，这就是没理解问题域。
需求开发与需求管理
需求工程可以分成两大块：需求开发和需求管理。这两者是什么关系？
需求开发是“从无到有”的过程。包括：
- 需求获取：跟用户聊、看现场、分析竞品。
- 需求分析：把零散的信息整理成结构化的需求。
- 需求规格说明：写成文档，让大家都能看懂。
- 需求验证：确认我们理解对了。
需求管理是“从有到稳”的过程。包括：
- 需求跟踪：每个需求从哪来，到哪去。
- 需求变更控制：改需求可以，但要有流程。
- 需求版本管理：别让版本乱成一锅粥。
我建议，小项目可以弱化管理，但大项目一定要把管理做扎实。我曾经在一个车载项目中，因为没管好需求版本，导致A版本的需求被B版本的代码实现了，结果测试全乱套。嗯，那周我加了三天班。
需求层次：别把“想要”当“需求”
需求是有层次的。我经常跟团队说：别把用户说的“我想要”直接当成需求。用户说“我想要一个红色的按钮”，他的真实需求可能是“在紧急情况下能快速找到停止键”。
需求通常分四个层次：
| 层次 | 定义 | 例子 |
|---|---|---|
| 业务需求 | 组织或客户的高层目标 | “我们要把生产线效率提升20%” |
| 用户需求 | 用户使用产品要完成的任务 | “操作工能一键切换生产模式” |
| 功能需求 | 系统必须实现的具体功能 | “系统提供模式切换按钮，点击后3秒内完成切换” |
| 非功能需求 | 系统在质量、性能等方面的约束 | “系统全年可用性不低于99.9%” |
你想想看，如果只盯着功能需求，很容易忽略业务目标。我见过一个智能家居项目，功能做得花里胡哨，但用户的核心业务需求是“省电”。结果呢？功能越多，功耗越大，完全跑偏了。
注意：非功能需求经常被忽视，但往往是项目成败的关键。我曾经做过一个医疗设备项目，功能需求全部满足，但实时性要求没写清楚。结果设备在关键时刻响应慢了200毫秒，差点出事故。从那以后，我每次评审需求都会专门检查非功能需求。
需求工程活动模型
需求工程不是线性的，而是一个迭代循环。我常用的活动模型包含五个阶段：
- 需求获取：访谈、问卷、原型演示、现场观察。别只坐在办公室里想。
- 需求分析：建模、分类、优先级排序。把模糊变清晰。
- 需求规格说明：写文档。格式不重要，清晰最重要。
- 需求验证：评审、原型测试、验收标准确认。别等到开发完了才发现理解错了。
- 需求管理：贯穿始终。跟踪、变更、版本控制。
这五个阶段不是走完就完事了。实际项目中，你经常需要从验证阶段回到获取阶段——“哦，原来用户不是这个意思，我们再聊聊”。
我个人习惯在项目初期做一次快速的原型验证。花两天时间做个简陋的界面或者功能demo，拿给用户看。用户看到实物，才会说出真实想法。这比看文档有效十倍。
好了，今天的内容就到这里。需求工程是嵌入式开发的基石。地基没打好，后面盖的楼再漂亮也白搭。下一章咱们聊聊具体的需求获取技巧，到时候我会分享一些实战中踩过的坑。