3. 需求分析基础：需求层次与分类

做实时系统这么多年，我最大的体会是：需求分析做不好，后面全是坑。你想想看，一个时序约束没搞清楚，到了集成测试阶段才发现，那代价可就大了。今天咱们就聊聊需求分析的基础——需求层次和分类。

3.1 需求层次：从业务到系统的三层结构

我个人习惯把需求分成三个层次：业务需求、用户需求、系统需求。这三层不是随便分的，它们对应着不同角色的关注点。

3.1.1 业务需求

业务需求是最高层。它回答的是：为什么要做这个系统？

举个例子，一个工业控制系统的业务需求可能是：

• 将生产线故障响应时间缩短到50ms以内
• 降低30%的停机维护成本
• 满足ISO 26262功能安全ASIL-D等级

我在项目中遇到过，有些团队一上来就写功能列表，结果做出来的东西跟业务目标对不上。说白了，业务需求是老板和客户关心的，它决定了项目的价值。

3.1.2 用户需求

用户需求是中间层。它描述的是：用户用系统做什么？

还是那个工业控制系统，用户需求可能是：

• 操作员能在3秒内查看任意传感器的实时数据
• 系统在故障发生时自动记录前后各5秒的波形
• 维护人员可以通过手持终端查看设备状态

嗯，这里要注意：用户需求是从用户视角出发的，不是从开发者视角。我见过不少需求文档，写着「系统需要支持Modbus TCP协议」——这其实是系统需求，不是用户需求。用户不会关心你用Modbus还是CAN，他只关心能不能读到数据。

3.1.3 系统需求

系统需求是最底层，也是最技术化的。它描述的是：系统具体要做什么？

系统需求会细化到：

• CPU在50ms内完成所有传感器数据的采集与处理
• 系统支持最多128个Modbus TCP从站设备
• 看门狗定时器超时时间为100ms，触发后执行安全停机

我曾经在一个项目中，业务需求写的是「高可靠性」，用户需求写的是「系统不能死机」，结果到了系统需求层面，大家吵了一个星期才定下来：MTBF（平均无故障时间）要大于100,000小时，故障恢复时间不超过200ms。你看，这才是能落地的系统需求。

3.2 功能需求与非功能需求

需求除了分层，还要分类。最常用的分类就是功能需求和非功能需求。这个分类在实时系统中尤其重要，因为很多坑都出在非功能需求上。

3.2.1 功能需求

功能需求就是系统做什么。它描述的是系统的行为、功能、输入输出关系。

举个例子，一个实时数据采集系统的功能需求：

• 系统每10ms采集一次温度传感器数据
• 当温度超过85°C时，系统触发报警并记录时间戳
• 系统支持通过UART接口以115200bps的波特率发送数据

功能需求相对好写，因为它是「看得见摸得着」的。但要注意，功能需求要写清楚边界条件。比如「当温度超过85°C时触发报警」——那如果传感器故障，读到的值是0xFF呢？这个也要写清楚。

3.2.2 非功能需求

非功能需求描述的是系统做得怎么样。它关注的是系统的质量属性。在实时系统中，非功能需求往往比功能需求更难满足。

常见的非功能需求包括：

3.2.3 功能需求与非功能需求的关系

这两者不是独立的。你想想看，一个功能需求「每10ms采集一次数据」，如果非功能需求要求「CPU利用率≤50%」，那你就得考虑怎么优化采集算法，或者用DMA来减轻CPU负担。

说白了，功能需求决定了系统能不能用，非功能需求决定了系统好不好用。在实时系统中，非功能需求往往决定了系统能不能可靠地运行。

3.3 需求分析的常见误区

做了这么多年，我总结了一些常见误区，分享给大家：

1. 混淆用户需求和系统需求：用户说「我要快」，你得翻译成「响应时间≤10ms」。
2. 忽略非功能需求：尤其是实时性、可靠性这些，等到测试再补就晚了。
3. 需求写得太模糊：别写「系统要稳定」，要写「MTBF≥100,000小时」。
4. 没有考虑边界条件：正常情况好写，异常情况（传感器故障、通信超时）才是真正的考验。

好了，需求分析的基础就聊到这里。下一章咱们会深入讨论时序规格的定义方法，包括时序图、时间约束语言这些实战工具。到时候我会拿一个真实的嵌入式项目来拆解，保证干货满满。