标签：
现在RUP如日中天，需求分析是第一步，可以看作是高级系统分析员的必备知识，那么，如果用面向对象的分析技术来描述需求呢？
在一个需求分析过程中，主要有项目描述，风险分析，用例图以及描述，项目建议这几部分。
其中最重要的，也是最需要学习的就是用例的描述。那么用例的描述关键点在哪里呢？
确定清晰的系统边界，就是要确定系统中有什么？系统外有什么？通过执行者和用例来确定系统边界。
那么，我们第一步就是要找出执行者，执行者是一个角色，我们可以根据以下几个问题来思考决定一下：谁在使用系统？谁在维护？谁在启动?谁在关闭？谁从这个系统获得信息？谁为这个系统提供信息？是否有自动的事情在预计时间发生？等等方式，来确定执行者。
找出了执行者，那就要确定用例，用例是系统的一个行为，为执行者产生可以估量的价值结果。
用例的描述一般都是动名词结构。
需要构建一张表，清楚的以名词解释的形式，把用例和执行者进行简单的定义。
如果用例图过于大，那就分开，也可以采用包的形式。
其中用例图的中的箭头表示是单向还是双向，要根据交付的信息看。
如果是外部定时发生的事情，可以把时间也作为执行者。
需求在系统之内，无法被执行者看到，那么这个需求就不用在用例图中体现。
归档用例就是把用例用文档的方式表示。基本用例主要包括：前置条件（前置条件就是用例开始时候，必须要处在一个什么状态） 后置条件（用例结束，系统处在什么状态）事件流。（事件流是一系列的陈述句）。
事件流中包含一些循环语句。可以采用for ,while循环。
用例是一个传达工具，只有向读者传达系统如何工作的时候才有效。
用例要从执行者的观点来写。
对于非事件流的需求，可以在用例的特殊需求中描述。
事件流分为两部分：基本路径和可选路径。
一切正常运转就是基本路径。
不同于基本路径而允许选择不同的事件序列的路径，就是可选路径，也可以说各种异常情况的处理也是可选路径。
可选路径，最好用不同的段落编号来标示。
什么是场景？ 场景就是一种贯穿用例的特定路径。
用例的包含：如果你发现在写各种用例的时候，要经常copy同一部分的内容，那么就说明你有了一部分通用的行为，那么就可以用一种包含关系来抽象这种通用行为。包含用例一定要有被包含用例，这个用例才算完整。
用例的扩展：在不改变原始用例的情况下，增加用例的行为。重要关注的一个概念是扩展点，当到达这个扩展点，如果条件为真，就是这个扩展条件的前置条件为真的话，这个扩展的步骤将被执行。
用例的继承：用例的继承代表一个用例（子）是另外一个用例（父）的特殊实现，执行者的继承意味着一个执行者（子）可以完成另外一个执行者（父）的任务。
接口：接口不是执行者和用例的一部分。接口是执行者和用例相互作用的一种描述。
文档中的文字可以简洁的描述系统，那么有些文字分支很多的时候，采用图就是一个非常好的方式，图形化用例也是一个不错的手段。我们可以用三种图来细化和具体化用例。
活动图：描述用例的步骤。活动图描述满足用例需求而进行的活动以及活动之间的关系。（有些书把活动图定义为状态图的子集）
时序图：描述执行者和系统的相互作用。时序图中，每个实体下面有虚线，代表对象生命周期。确认的返回值，是采用虚线箭头来表示。
在学会写用例以后，那就有一个问题，用例写到什么程度好呢? 就是用例细化到什么程度为好。要回答这个问题，需要考虑三个问题： 谁需要阅读并审批这个文档？谁需要使用这个文档？我们要这个文档做什么？用例可能是给最终用户和开发者的，或者管理者的，决定多少细节放到用例中是一个很重要的事情。可以对同一个用例做不同细节程度的版本，交给不同的人看，要注意维护这种对应关联关系。
用例文档模板：
包括系统简介，风险因素，系统级用例（一个或者多个反映系统中所有用例和执行者的图，没必要包含用例之间的关系，例如包含，扩展和泛化），体系结构，子用例，非功能性的需求包括可用性，系统，安全，持久性，冗余性，性能，规模，标准化等。
可以通过活动图来描述和表现用例之间的关系和流程。
标签：
原文地址：http://www.cnblogs.com/LJT666/p/5089678.html
