关于系统用例的粒度我画用例图时往往就做成function list了，看了很多资料，理解还是不深入，请各位大侠指教。
关于系统用例的粒度
我画用例图时往往就做成function list了，看了很多资料，理解还是不深入，请各位大侠指教。
系统用例应该是一个什么粒度？
像系统支撑类的功能应不应该画成系统用例，例如登录，用户管理，角色管理等。
[解决办法]
粒度问题没有什么“应该”，只要“自己说清楚了，别人能看懂”即可
可以先细后粗也可以先粗后细，重构嘛~~
[解决办法]
用例不能太多，控制在50个以内吧
先识别actor（可以区分系统边界），之后再做用例
一家之言仅供参考
祝你成功
[解决办法]关于粒度问题，我也很难把握，一直想看一本how to write effective use case 的书，
不知道那本书里面有没有相关的解答
实际工作中，用例不会过多，用例描述相对比较复杂，如果用例描述过于复杂了就考虑是否把该用例拆分成几个用例
粒度问题还是要慢慢积累把握。量化的标准我还一直没有看到，比如一个用例最多包含多少功能点。
[解决办法]就从开发管理而言（而不是从给用户领导看），我处理的用例最多只要3天（理想状态下的）开发时间，把3天以上开发（包括功能测试）时间的任务应该分解掉。我们常常看到那样的现象，一两个功能交给一个小组（可能只有2个人）结果他们几个月还没有搞定，这种应该算是管理人员的责任，你没有量才用程序员或者你的用例设计就是模糊不清的。
[解决办法]哦对了，有一种挺有意思的事情，有些人在需求修改后去反复修改用例。我认为这是需求表述中最大的毛病。
只要是兼容的需求，当需求进化、提出新的补充时，包括对原有需求的更新当时没有否定原有的需求，应该增加新的用例。
学究就喜欢举出几个用例然后就在上边不断玩文字游戏反复重构。但是你是工程管理人员，你不是学究，你不应该学学究的那套最终做法（只应该学他们的基础理论）。用例变化时不要修改，而应该尽量继承。
[解决办法]很好，终于看到讨论用例拆分的专贴了。可以在这里跟sp1234讨论下。
有关用例、功能点、用例重用等等的争议历来就有。
1.用例的需求来源于软件需求，这个是不用争论的了吧。
2.需求和用例设计的细化可能造成时间延误，但是如果不细化可能造成的就是失败。
3.如果不细化，就无法进行功能点覆盖和测试覆盖的统计。
4.如果一个用例覆盖了过多的功能节点，由于功能的关联性，可能造成这个用例由于10种原因被回归执行了10次，但是在统计上仍然是一个用例在不断的被执行。实际上错误的位置已经转移了，开发者也进行了bug的修正。
5.我认为，如果一个用例覆盖了2个以上的业务提交并能清晰的分出输出，就应该进行用例拆分。
[解决办法]还有就是，好测试用例的标准我总结的是：
可以通过拆分和记录更有效的帮助开发者认定和修正问题的用例才是好用例。
[解决办法]你可以先把涉及的业务划分成不同问题域。
针对每个问题域再制作业务用例，用活动图来描述每个业务用例的事件处理流程。
然后再制作系统用例，活动图中的每个活动都有可能成为系统用例的用例。
业务用例我认为可把每个事件的起点作为一个用例。
例如买一件衣服，你可能要挑衣服，信用卡支付，这些都不是起点，可以不用作为业务用例。
而只有买衣服才是一个业务用例。或者从客户的角度去考虑，不要太深入细节。系统用例时再进一步拆分。
lz说的支撑类我在系统用例中一般也是画出来的。
