解决混淆需求和设计界限的方法——用例

需求和设计，在概念上区别很明显——前者是描述用户的期望，后者是描述如何实现用户的期望；可是在实际操作过程中，开发人员常常会混淆二者之间的界限，对系统需求描述详细到可以用于设计的程度，这同样是违背软件工程要求的。

那么，怎么样才能避免混淆需求和设计的界限，解决系统需求不知道该详细到什么程度的问题呢？

答案是使用用例方法来描述需求。

用例是描述系统需求的一种方法，它由用例图和用例规格说明两部分构成。

• 用例图

用例图描述了参与者和系统发生的交互，它主要由3种元素组成：

1. 参与者(Actor)：位于系统外部，并与该系统发生交互的人或者其他系统。它代表系统的使用者或者使用环境。

2. 用例(Use Case)：用于表示系统所提供的功能或服务，定义了系统如何被参与者使用。

3. 通信关联(Communication Association)：用于表示参与者使用了系统中的哪些功能或服务(用例)。

• 用例规格说明

用例规格说明描述的是参与者和系统之间的对话的细节，它主要包括以下内容：

1. 简要说明：概述该用例的作用和目的。

2. 事件流：包括基本流和备选流，基本流描述的是程序正常运行实现主要功能的步骤或动作顺序，备选流描述的是异常情况下程序的处理流程。

3. 用例场景：场景是一次完整的用户使用过程，是由基本流和备选流组合而成的，它包括成功场景和失败场景。

4. 特殊需求：描述与该用例相关的非功能性需求(包括性能、可靠性、安全性、保密性和可维护性等质量特性需求)和设计约束(所使用的操作系统及开发工具等)。

5. 前置条件：执行用例之前系统必须所处的状态或者说应具备的条件。

6. 后置条件：用例执行完毕后系统可能处于的一组状态（有时也需要程序执行某一动作）。

用例方法的核心思想是从用户的角度(从系统的外部)描述系统的功能，它将系统看做是一个黑盒，并不关心系统内部是如何完成它所提供的功能。

使用用例方法应切记不要违背这一思想，描述需求仅是描述系统外部“参与者”与系统的交互以及系统为“参与者”所提供的服务（用例），用例的描述仅停留在描述清楚事件流、用例场景、特殊需求、前置和后置条件，不要涉及如何完成系统的功能的内容。因为后者就是设计。

所以，只要不违背用例方法的核心思想，就能够解决需求和设计混淆的问题。

这正是：

需求设计易混淆，用例方法解决了

用户角度是核心，莫要越俎去代庖

参考书目：软件测试设计，作者：马均飞，郑文强，出版社：电子工业出版社