需求分析基础：什么是需求、需求的层次与嵌入式开发中的重要性

说实话，我见过太多嵌入式项目翻车，根源往往不是技术不行，而是需求没搞清楚。有个项目我印象特别深——团队闷头干了三个月，结果客户一看说“我要的不是这个”。嗯，从那以后，我每次启动项目第一件事就是拉着团队把需求掰开揉碎。

到底什么是“需求”？

很多人觉得需求就是“客户想要什么”。这话没错，但太笼统了。我个人的理解是：需求是系统必须实现的能力或必须遵守的约束。它不只是功能列表，还包括性能、接口、环境、安全等方方面面。

举个例子，客户说“我要一个温度采集器”。这算需求吗？算，但太模糊了。你得追问：采集精度多少？采样频率多快？工作温度范围？供电方式？通信接口？这些细节才是真正能指导开发的需求。

需求的三个层次：从业务到系统

做嵌入式这么多年，我习惯把需求分成三层。你想想看，如果这三层没对齐，项目肯定要出问题。

层次	定义	典型表述	谁关心
业务需求	组织或客户的高层目标	“提升产线效率20%”	决策层、客户
用户需求	用户使用系统完成的具体任务	“操作工能一键启动设备”	最终用户
系统需求	系统必须实现的技术规格	“MCU响应时间≤50ms”	开发团队

业务需求：为什么做这个项目？

业务需求回答的是“为什么”。它通常来自公司战略或客户的高层目标。比如“我们要开发一款智能门锁，抢占高端公寓市场”。这个目标会直接影响后续所有决策——成本预算、功能取舍、质量要求。

我记得有个项目，客户说“我们要做一个工业网关”。后来深聊才知道，他们的真实目标是“把现有产线设备的数据统一上云，减少人工巡检”。你看，业务需求清楚了，技术方案的方向就完全不一样了。

用户需求：谁在用？怎么用？

用户需求关注的是“人机交互”。嵌入式设备的使用者可能是操作工、维修员、甚至终端消费者。你得搞清楚他们在真实场景下怎么操作。

我曾经犯过一个错：给一个手持设备设计了很酷的触摸屏界面，结果现场工人戴着手套根本点不了。后来改成物理按键加大字体，问题才解决。说白了，用户需求不是你想当然的，得去现场看、去问、去体验。

系统需求：技术团队要做什么？

系统需求是把用户需求翻译成技术语言。它是开发团队的直接输入，必须具体、可测量、可验证。

举个例子，用户需求是“设备启动要快”。系统需求就得写成：

• 上电后5秒内完成自检
• 操作系统启动时间≤3秒
• 应用程序加载时间≤2秒

你看，这样写，测试才能验证，开发才知道目标。

需求分析在嵌入式开发中的重要性

做嵌入式跟做纯软件不一样。硬件定了就改不了，芯片选型错了只能重新打板。所以需求分析在嵌入式领域尤其关键。我总结了几点：

1. 决定硬件选型——MCU主频、内存大小、外设接口，全由需求驱动。需求没搞清楚就选型，后面只能加钱换芯片。
2. 影响架构设计——实时性要求高的功能放中断还是任务？功耗要求严苛的模块怎么休眠？这些都得从需求出发。
3. 控制项目风险——需求越模糊，后期变更越多，成本越高。嵌入式项目改一次硬件，周期至少多两周。
4. 指导测试验证——没有明确的需求，测试就没标准。你说功能对了，客户说不对，谁说了算？

说白了，需求分析做得好，项目就成功了一半。做得不好，后面全是坑。

需求层次关系图

下面这张图展示了三个层次之间的转化关系。我每次做项目都会画一遍，确保团队理解一致。

需求分析的核心活动

做需求分析不是一次性的工作。我个人的流程大致分四步：

步骤	活动	输出	常见问题
1	需求获取	访谈记录、问卷、现场观察笔记	只听客户说，不看实际场景
2	需求分析	需求分类、优先级排序、冲突识别	忽略隐性需求（如安全性）
3	需求规格	需求文档、用例图、原型	写得太技术化，客户看不懂
4	需求验证	评审记录、确认签字	跳过验证，直接开发

嵌入式需求分析的特殊性

跟纯软件项目比，嵌入式需求分析有几个特别要注意的地方：

• 硬件约束前置——选型前就得把性能、功耗、成本需求定清楚，不然后面改不了。
• 实时性要求——很多嵌入式系统对响应时间有硬性要求，需求里必须明确是“硬实时”还是“软实时”。
• 资源受限——内存、Flash、算力都有限，需求分析时就得考虑能不能在目标芯片上跑起来。
• 环境因素——温度、湿度、振动、电磁干扰，这些在需求阶段就得写清楚，不然测试时才发现设备扛不住。

嗯，说到环境因素，我有个教训。之前做户外设备，需求里写了“工作温度-20°C到60°C”。结果选型时没注意芯片的工业级温度范围，量产了一批才发现低温下频繁死机。那次返工的成本，够买好几倍的好芯片了。