Use Case 问答

 Use Case Q/A：

1、什么是Use Case？
   Use Case，一般翻译为用例，即使用场景的示例。软件系统的Use Case，就是用户使用软件系统的场景描述。
   用例，就是系统的一个具体的可操作的功能，应该有一个页面或操作按钮与之相对应。注意用例名称是动词+名词，比如“下定单

”。
   它不是虚的抽象的，所以象“一站管理”就不是一个用例，应该具体到“需求管理”、“待办任务”等用例。

2、什么是actor？
   Use Case中的actor是指：在某一功能中的使用者，所以可能是：客户资料录入人员，客户资料审批人员
   actor是使用者，不是角色，也不是岗位，角色和岗位是更大更粗的描述，同一个岗位人员的角色可能有差异。
   
   在需求分析阶段，我们关注的是系统的功能需求。不要太关注角色/岗位的整理，在系统需求分析完成之后，系统功能就有了，然

后在系统基础数据整理时才关心哪些人拥有哪些功能，即哪些角色可以充当哪个actor。

   所以说，相对于角色和岗位来说，actor是最细的，是针对某个Use Case的参与者。不要抽象（抽象的事后面再做，不在需求分析

阶段）

3、用例描述是否需要了解内部实现？
   系统用例关注是系统与用户之间的界面（交互情况），只关心这个接口界面。不要关注系统内部的实现方式。
   Use Cases把系统当作一个黑盒。

4、Use Case与原型是什么关系？
   原型是Use Case的进一步细化的结果，一般情况下，每个用例都可以做出来原型与之相对应。
   但在系统需求分析的初期不要太关注原型，如果我们一下子进入到了最细节的层面，省略了用例的分析，就会错过系统的价值分

析阶段，就不能从更高层面分析系统，抓不住重点/核心价值。
   所以，一定要先有用例，然后分析其价值，对核心用例才进行原型描述等，投入最多的精力。这样才能够突出重点。

5、Use Case只是一个一个椭圆圈住用例名称吗？
   不是的。Use Case很重要的内容是用例描述。每个用例都必须有一个描述，描述的内容有：
   a、主场景。即用户与软件系统交互的过程。比如：1、用户输入完整信息，点击“保存”按钮 2、系统提示“成功”或“失败”
   b、例外/备选场景。即备选交互过程
   c、信息项描述
   d、校验条件等

6、如何组织用例组成用例图？或如何划分？或一个用例图中应该包括多少个用例？
   一个用例图一定要有一个主题，即此用例图研究的对象。在用例图的框中框住的应该是与此主题相关的用例。
   不要把多个主题的用例放在一起，否则会造成理解不清晰。
   主题不要太大，也不要太小。