软件需求的问题

十年来国内软件工程方面的进展有目共睹，在软件需求方面，我们看到在大多数组织中已经建立起了一级或两级需求体系（业务需求和软件需求）；在某些组织中，需求分析员已经成为一种专门的职位；甚至在某个大型国有商业银行已经成立一个专门的部门来负责需求分析工作。应该来说，这是一些非常可喜的进步。

 

然而，目前大多数的项目参与者都对需求工程的现状不满，这又是为什么呢？首先，我们必须承认市场快速变化而带来的需求变化的确对项目带来了很大的挑战，为此许多项目应用了迭代化开发来应对这样的变化。但根据我们对客户的访谈，更多的需求变化是由于需求沟通不力造成的，也就是说，参与需求沟通的各方并没有达成真正的共识，这又是什么原因呢？根据我们的分析，这主要是由于缺少一个可以被各方真正理解和沟通、并可以被逐步精化的需求体系。

 

目前，大多数用户采用的需求体系基本上是沿袭了结构化分析的文档体系（包括数据流图，数据字典等）。这种文档体系起源于70年代，当时，软件的主要应用还是科学计算或信息处理，理解需求的人往往也受过结构化分析的相关教育，然而这些内容对今天的大多说业务人员或最终用户而言就是很难理解的了。这里的主要问题是 分析代替了需求。为了解决这个问题，有的组织引入了非形式化、非结构化的业务需求，然而却很难在两种需求之间建立明确的对应关系，从而出现了业务人员/最终用户认可业务需求，但开发人员觉得不够详细；开发人员认可软件需求，但业务人员/最终用户无法给与确认。

 

那么，我们如何解决这一软件需求的困境呢？

首先，让我们仔细研究一下用例的定义：

一个用例抽象了目标系统在现实中将执行的一组场景（每个场景由一系列动作组成）；这些场景会产生一个对某个Actor有价值的、可观测的结果;

 

在这个定义中，我们强调了两件事情：一、用例是被从现实的场景中抽象出来的，而不是被随便发明出来的；二、每个用例（场景）应能提供完整的商业价值。在未来的博文里会介绍这两条会如何帮助我们避免对用例的误用。

 

用例的优势在于它天生是黑盒的，它用自然语言抽象了用户和目标系统的交互，避免了混入分析、设计和实现细节，以保证用例可以被不懂具体技术的业务及测试人员所真正理解。同时，需求分析员又可以方便地通过用例分析（use case analysis）（即用分析类来试图在理想方式下实现用例），将需求体系精华成分析模型。在这一过程中，需求分析员可以更进一步地完善基于用例的需求体系，而不必担心分析模型会污染需求，从而实现需求与分析的分离及有效互动。

 

最后，我们必须指出，基于用例的需求管理体系中不仅仅包含用例，它还应该包括涉众请求，特性列表，前景文档，补充规约，词汇表等等。

 

用例其实是Ivar在许多年前发明的老技术了，现在被很多人所采用，而被更多人误用，下面的文章让我们看看一些对用例的典型的误解和误用

 

用例是一个门槛很低的技术，任何人都可以随便画几个小人和几个椭圆，然后向全世界宣称我在用用例进行需求建模了，但是好像也没有真正解决我的问题。在这种情况下，用例技术很可能被误用了。在对用例不同类型的误用之中，最严重、最普遍的莫过于利用用例来进行功能分解了。刚在为了偷懒，想找张现成的错误使用用例的例子，结果找的了2001年Kurt写的在这方面的文章以及最近一位老兄在优快云上给出的翻译（已经收藏在我的网摘里）。Kurt对这个问题的阐述已经相当清楚了，我也就不多写了，大家去看我的网摘或原文吧！

作为总结，可以记住这样两句话：

1、Login往往不是一个好的用例；

2、用例是不会互相调用的；

 

英文原文：

http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/WhyUseCasesAreNotFunctionsDec00.pdf

 

中文翻译：

http://blog.youkuaiyun.com/soaringbird/archive/2007/03/28/1544093.aspx

最近在与用户的沟通过程中，发现用户经常会认为用例是一种基于图形描述或UML的方法，从而质疑用例是否能够有足够的描述能力，或者用例是否易于被业务人员理解。其实，这是对用例的另一种典型的误解。

 

在用例模型中，的确会用到一些UML的图符（一个小人代表Actor，一个椭圆代表Use Case，等等），但这些图符是非常容易理解的。而且用例的主要信息是在需求规约当中，用例模型传递的信息可能只占所有相关需求信息的5%。

 

所以，我建议，大家可以粗略地认为用例与UML基本无关，它主要是一种基于文本的结构化地书写需求的方式。

用例的粒度问题一直是困扰着需求分析员的常见问题，对于这个问题，抱歉，没有银弹，我只能给出一些解决这个问题的基本原则：

1.         控制用例的总体数量：一般来说，一个相当复杂的系统的用例数量可能在30-50个之间，如果一个系统的用例数量大大超过了这一范围，那就该看看是不是陷入了功能分解的误区；

2.         高内聚、低耦合：用例是一种结构化写作需求的技术，用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系（高内聚），那用用例技术来组织它们则可以复用这些场景中的步骤描述，从而达到事倍功半的效果；

3.         写写看:很多时候在初步规划用例模型的阶段，有时很难判断一个用例的粒度是否合适，不要执迷于一次获得一个完美的用例模型和用例粒度。不妨先得出一个初稿，然后写写用例，看看是不是符合高内聚、低耦合的原则，实际上在写用例的过程中，用例模型往往是需要不断进行调整的；

4.         避免功能分解：功能分解是正确使用用例技术的最大敌人，很多用例粒度的讨论其实都是功能分解的思想在作怪。

目前大多数用户的开发都是对现有系统的升级和改造，在这样的情况下还能使用用例技术吗？很幸运答案是肯定的，你可以按照以下步骤进行：

1.         确定系统边界：通过标识Actor来定义系统边界；

2.         重构用例模型：简要地捕获和描述现有系统的用例模型；

3.         扩展用例模型补充用例规约：根据系统的升级和改造要求，增加新的用例或对已有用例进行扩展；在对现有用例进行扩展之前，则需要补充用例的基本事件流和涉及到的备选流，在以它们为基础来对描述需要的新行为；

 

这样，就可以在对现有系统的改造过程中，逐步地重构整个系统的用例模型和用例描述。