关于系统用例的粒度解决方法
关于系统用例的粒度我画用例图时往往就做成function list了，看了很多资料，理解还是不深入，请各位大侠指教。
关于系统用例的粒度
我画用例图时往往就做成function list了，看了很多资料，理解还是不深入，请各位大侠指教。
系统用例应该是一个什么粒度？
像系统支撑类的功能应不应该画成系统用例，例如登录，用户管理，角色管理等。
[解决办法]
粒度问题没有什么“应该”，只要“自己说清楚了，别人能看懂”即可
可以先细后粗也可以先粗后细，重构嘛~~
[解决办法]
[解决办法][解决办法][解决办法]哦对了，有一种挺有意思的事情，有些人在需求修改后去反复修改用例。我认为这是需求表述中最大的毛病。
只要是兼容的需求，当需求进化、提出新的补充时，包括对原有需求的更新当时没有否定原有的需求，应该增加新的用例。
学究就喜欢举出几个用例然后就在上边不断玩文字游戏反复重构。但是你是工程管理人员，你不是学究，你不应该学学究的那套最终做法（只应该学他们的基础理论）。用例变化时不要修改，而应该尽量继承。
[解决办法][解决办法]还有就是，好测试用例的标准我总结的是：
可以通过拆分和记录更有效的帮助开发者认定和修正问题的用例才是好用例。
[解决办法]你可以先把涉及的业务划分成不同问题域。
针对每个问题域再制作业务用例，用活动图来描述每个业务用例的事件处理流程。
然后再制作系统用例，活动图中的每个活动都有可能成为系统用例的用例。
业务用例我认为可把每个事件的起点作为一个用例。
例如买一件衣服，你可能要挑衣服，信用卡支付，这些都不是起点，可以不用作为业务用例。
而只有买衣服才是一个业务用例。或者从客户的角度去考虑，不要太深入细节。系统用例时再进一步拆分。
lz说的支撑类我在系统用例中一般也是画出来的。
