周四的时候，因为公司要对之前的一个软件系统做双软认证，然后就把软件需求规格说明书的任务给了我。蛋疼啊！别的还好说，但是用例图和需求建模把我弄得要死要活的。后来好在有了一个网友给力的支持了我，才得以渡过难关。于是，新的学习目标又出现了-UML的使用和用例建模（需求建模）。
根据网友的推荐，看了一篇IBM的用例建模入门简介，颇有收获，在此共享给所有做产品经理和需求分析的朋友。
这东西粗略一看觉得很枯燥，但是从个人感觉来说，如果深入了，可能会比Axure rp的学习还好玩儿得多。
好了，废话不多说了，下面分享干货：
1、从参与者的角度并以主动语态编写用例。
应该以主动语态：“学生表明参加研习班意向”，而不是被动语态“研习班意向被学生表明”来编写用例。而且，应该从参与者的角度来编写用例。毕竟，用例的目的是理解用户如何对系统进行操作。
2、编写方案文本，而非功能需求。
用例描述的是对参与者来说有价值的一系列行动，而不是特性集。例如，“招收研习班的学生”用例描述的是学生如何与系统交互来参加研习班。它没有描述用户界面看上去是什么样子，或者它是如何工作的。有一些其它的模型来描述这些重要的信息，例如用户界面模型和增补规范。面向对象分析非常复杂，因此需要对它使用几种模型，并且应该适当地应用每一种模型。
3、用例只记载行为需求。
用例既不是类规范，也不是数据规范。这是应该由概念性模型捕捉的一种信息，在对象世界中，它是通过 UML类模型建模的。您往往会引用概念性模型中描述的类，例如，“参加研习班”用例包括了“研习班”和“学生”等概念，它们都将由概念性模型描述。
4、不要忘记用户界面。
系统用例经常引用主用户界面 (UI)元素，这些元素常常称为“边界”或“用户界面”项，例如 HTML页面和报表。用例有时也引用一些次要的 UI元素，例如按钮或数据输入字段，但这种级别的细节并不太常见。
5、创建用例模板。
用例包含了相当数量的信息，这些信息可以轻易地以常见格式记载。您应该考虑开发自己的模板。
6、始终如一地组织用例图。
一般的做法是垂直地绘制继承 (inheritance) 和扩展 (extend)关联，在父／基本用例下面绘制继承／扩展用例。同样，通常水平绘制包含(include) 关联。请注意，这些是简单的经验法则 –只要始终遵循这些法则，产生的图将很容易理解。
7、不要忘记系统对参与者行动的响应。
用例既应该描述参与者是如何与系统交互的，也应该描述系统如何响应这些交互。例如，在“参加研习班”用例中，如果系统在学生表明他们希望参加研习班时没有做出响应，学生就会很沮丧地离开。
8、备选行动过程非常重要。
如果一切顺利，使用的将是基本行动过程 –但也不要忘记备选过程。引入备选过程是为了描述潜在的使用错误以及商业逻辑错误和异常。这些重要的信息对于驱动系统的设计来说很有必要，因此不要忘记在用例中对它们建模。
9、不要被 <<include>> 和 <<extend>>关联所困扰。
我不是很确定到底发生了什么事，但我总是在想包含 (include) 和扩展(extend) 关联，以及旧版本 UML 中使用 (uses) 和扩展 (extends)关联的正确使用从来没有得到很好的描述。结果，用例建模小组往往在这些关联的正确应用上争论不休，在整个建模技术中一些有趣但次要的部分上浪费了惊人的时间。我曾在一个组织中工作，这家组织居然取缔了<<include>> 和 <<extend>>原型的使用，几个星期后，当意识到公司仍然需要这些概念时不得不撤消了这种极端的解决方案，而这时该组织对它们的正确使用还没有达成共识。
10、让用例带动用户文档。
用户文档的目的是描述如何使用系统。每个用例都描述了参与者通过使用系统所采取的一系列动作。简而言之，用例包含从中开始编写问党用户稳当的信息。例如，可以使用“参加研习班”用例作为基础来编写系统用户文档的“如何参加研习班”一节。
11、让用例带动演示。
软件开发过程中的一部分是向项目资金管理者通报工作成果，因此有时需要提供演示。因为用例是从用户的角度编写的，它们包含了演示中对资金管理者可能希望听到的事物的有价值的深刻见解。换句话说，用例通常包含制定演示稿所需的逻辑。
看完觉得怎么样？是不是还不错。
另外在最后再给大家推荐一本书，名字叫《大象：Thinking+in+UML》。我也是浏览了一部分，关于用例那一块，感觉不错。需要电子书的朋友可以联系我。点击博客右上角“小楼的QQ”就可以直接跟我对话了。 | 
