在以往，嵌入式系统开发往往是单兵作战，依赖于个体能力，详细的需求文档并不被视为必要条件。然而，随着嵌入式系统的复杂度不断提高，团队协作变得至关重要。这就离不开知识的传递和消费，因此需求管理在嵌入式系统中的重要性日益凸显，它不仅关乎业务实现，更影响到团队的沟通和项目顺利进行。

最近，我们在一项嵌入式项目中探索了不同的需求描述方法，从传统的需求规格说明书到敏捷的用户故事，再到我们最终采用的系统用例。这一方法极大地提升了团队的开发效率，本文将分享我们的经验和思考。

嵌入式系统的需求应该如何描述？

今年，我们有幸参与了一项极富挑战性的嵌入式项目。我们首先面临的问题是如何将客户的想法转化为可供开发的需求文档。

最初客户采用了传统的需求规格说明书的形式。然而我们很快发现，这种通用的模板并不能很好地满足我们的需求。规格说明书的冗长和细节繁多，既增加了编写的工作量，在该详细说明的地方又没说清楚。

作为敏捷软件开发的实践者，我们迅速转向使用用户故事管理需求，用户故事（User Story）是从用户的角度来描述用户渴望得到的功能。它包括三个要素：角色、活动和商业价值。但遗憾的是，用户故事并不适用于我们的嵌入式场景。

首先嵌入式系统中的角色非常单一，并不存在多个角色。另外，用户故事INVEST原则的“可协商性”和“有价值”在这里并不重要。因为嵌入式产品通常完成确定的功能，其价值也是作为一个整体来体现。在我们这个项目中，它完成的是一些标准协议和明确的交互，不存在可协商性。而价值更侧重于整个系统提供完整业务价值，单个具体功能的价值体现非常有限。最后，用户故事通常不涉及详细的实现步骤，更多是围绕价值和验收条件。但在嵌入式系统中，恰恰相反，验收条件可能很简单，但实现过程却非常复杂。如果需求文档缺少了过程的描述，则起不到需求的作用。

那么嵌入式系统究竟应该怎么描述需求呢？有没有更理想的方法？

这使我想起多年前阅读过的经典著作《编写有效用例》，这是一本与Jez Humble的持续交付一样获得Jolt大奖的经典书籍。

能否将用例​用于嵌入式系统的需求管理呢？​

系统用例在嵌入式领域中的应用

用例是系统中各个干系人（stakeholder）就系统行为所达成的契约。用例描述了在不同条件下，系统对某一干系人的请求做出响应时发生的系统行为。

我们采用了一个简化的系统用例模板来描述需求，一个用例只需要包括三部分：概述、基本路径和扩展路径。我们来看一个示例：

一、概述

XX方案一般由主站发送报文，由TM将报文下发，并将设备返回的报文保存到A中心。......

二、基本路径

1 TM根据任务设置，周期性执行XX方案
2 TM根据任务的方案ID，从A中心查询方案
3 A中心返回方案，方案中有“内容集”，结构见附录。
4 TM对“内容集”的“内容”进行循环，执行后续步骤。
5 TM根据通信地址，找到设备档案。
6 TM根据设备档案，确定是通过串口还是载波下发报文。
7 TM通过串口/载波发送方案报文集的一条报文。
8 串口/载波App返回ACK成功。
9 串口/载波App返回设备的报文。
10 TM将设备的原始报文保存到A中心，以记录型数据保存。
...

三、扩展路径

5a TM根据通信地址，未找到设备档案。
5a1 TM结束当前业务处理。

8a 串口/载波App返回ACK超时
8a1 TM重试一次，如果仍然超时则结束业务处理

8b 串口/载波App返回ACK否认
8b1 TM结束当前业务处理。

基本路径是主成功场景，通常是一切顺利的情况下，系统的处理步骤。扩展路径表示备选流，描述了各种分支和异常场景的处理。例如8a就是第8步的一个分支，8a1 表示这个分支的第1步。8b表示第8步的另一个分支，以此类推。

在嵌入式系统中，一个功能通常由若干系统组件共同完成。它可能是由人工触发或者物联设备、系统内置模块等触发，然后系统的不同组件互相协同，通过接口进行交互，完成特定功能。

通过系统用例，我们用不到20行文字就把这个需求描述清楚了。这样的文档具有开发和测试人员所需要的详细信息，同时编写起来也比较简单，不用花很多时间。

嵌入式领域采用系统用例的优势

我们在实践中发现，系统用例特别适合于嵌入式系统。

需求非常清晰

嵌入式系统通常只有很少的UI交互，有些甚至完全没有UI交互。如何描述清楚需求，是一个很大的挑战。

与传统需求规格说明书中的大段落，没有章法的描述相比，系统用例可以清晰地描述每一个步骤的系统行为。每一步都使用简单的语法，而且都很明确，谁做什么事情，或者谁做出什么响应。主语、谓语动词、直接宾语等，这些构成了一个非常简洁、清晰的需求。

提升开发效率

开发人员的时间通常花在想清楚这个需求怎么做、动手开发、调试和测试，以及返工上。而测试人员的时间通常花在理解这是个啥需求，我要怎么测上。在这些方面系统用例都能够大幅提升效率。

系统用例能够提供详细、准确和简洁的需求，为团队提供了明确的方向，避免因为误解或遗漏需求而导致的设计和代码修改。这不仅可以节省开发时间，更重要的是减少了返工的时间。毕竟返工是最大的浪费。

系统用例降低了沟通成本，使团队成员能够快速理解需求并高效地分工合作。BA、Dev和QA可以基于同一份文档高效合作。

对于使用TDD开发的Dev来说还有一个额外的帮助，任务分解（Tasking）变得更加简单了。因为系统用例的每一步都是一个Task。

交付高质量产品

嵌入式系统对于质量有着更高的诉求，有些甚至是工业级产品要求。做一个能工作的产品很容易，但要做一个工业级的产品，要付出十倍、百倍的工作量。如何提升产品的质量？以往的经验告诉我们，产品质量取决于对异常情况的处理。

系统用例通过扩展路径来描述各种备选流和异常分支。在分析需求的过程中，需求分析师通过自问“这一步还会出现别的情况吗？”，可以发现很多程序需要应对的场景。例如，对方超时未响应，对方返回错帧等等。

开发人员可以跟随系统用例的每一步，采用TDD，开发出高质量的代码和安全防护网。

测试人员也非常容易根据系统用例来设计针对边界值、特殊场景的测试用例。甚至提前发现需求遗漏的场景，这也是测试左移的价值。

所以这些都能够帮助团队将质量内建在每个交付过程中。

案例：系统用例帮助我们提升一倍开发效率

我们团队最近交付了一个嵌入式系统软件，这个软件运行于一个终端产品中，完成边缘计算任务。产品具有非常高的稳定性要求，需要在各种恶劣环境下，7*24小时长年持续稳定运行。

在项目早期没有系统用例的时候，因为团队不熟悉业务，对粗粒度的需求文档理解起来非常困难，即使经过多轮沟通，也仍然会有误解或遗漏。大家花费了大量时间去理解业务，代码也经常出现返工。交付效率一直提不上去，质量也不高。

在采用系统用例描述需求后，这种局面得到了彻底改善。即使团队不熟悉业务，也能够按照需求文档的描述完成功能开发。开发效率大幅提升，同样规模的功能，现在只需要一半的时间。其中最明显的区别在于开发人员在理解我要干什么这件事情的认知负担明显降低了，返工明显减少了，而且质量还提高了。

系统用例作为一种描述需求的方法，其简洁、准确的特点有助于形成高质量的需求文档。这些文档为开发过程提供明确的指导，而且会积累成为知识库。这个知识库不仅是组织的核心资产，还能助力新人快速融入项目，提升团队整体能力。

总结与展望

本文探讨了嵌入式系统的需求管理，并分享了在一个具有挑战性的嵌入式项目中所取得的经验。通过对需求描述方式的多次尝试，最终确定了在嵌入式场景下更为适用的需求管理方法——系统用例。通过系统用例，团队成功地提高了开发效率，使得交付过程更为流畅。

展望未来，我们期待继续在嵌入式系统的开发中探索更加精细、高效的需求管理方法。通过不断总结经验，优化流程，我们期待在需求管理领域寻找更多创新的方法，以适应未来嵌入式系统的复杂性挑战。