用例建模时总是把握不住宏观与细节程度，并且对于一些用例本身不能很好描述的需求进行建模。几乎每次分析都是步履艰难。最近找了些资料看，才发现犯忌讳。。。赫赫。。
    吸取了之前教训，现在个人吧用例建模分为两大步骤。首先是宏观的完全出自用户的功能事例。当上一部基本完成后，就需要需求分析人员作进一步细化，并最终通过用户审核的。之前一步可以称为基础需求用例，后者就是次用例了。。：）
    基础用例建模可以遵照经典用例分析的一些步骤。有一点区别，对于本系统完全被动的参与者也可以作为首选分析对象。因为有时候用户虽然不知道要对系统干啥，但是却非常关注自己得到系统的服务。一个用例建立可以有如下步骤:
    1。选择外部系统的参与者，包括对于本系统完全被动的参与者。
    2。从参与者角度出发, 对参与者交互的每件事列出步骤。
    3。不作任何多余的分析。。记住了，这要用户给出就写下来。。
    这样只要用户可以给出的都要记录下来,其他都不作。那还有很多参与者并不是人，怎么办？？。。。很遗憾只能靠分析人员自己站在这些参与者角度假设了。同样不要做过多分析，只要假设这些参与者只了解系统的边界部分即可。
    一般对于快速开发的项目基础用例建立完成就可以直接进行设计甚至编码工作了，因为之后的分析可能会消耗大量时间。把这些事留给重构，或下一个迭代版本吧。。。咔咔咔。。。只要你不担心这些的后果。。。
    次用例建模完全建立在基础用例上。这是为了分析出进一步需求或者说对于基础需求中不明确的部分作出描述。该步骤分析人员可以完全先自己分析，但必须得到用户审核。
    步骤如下：  
    1。考虑一些可变情况，把他们创建为扩展用例。
    2。复审不同用例的描述，找出其中的相同点，抽出相同点作为共同的用例。
    3。分析之前没有主动参与者的用例，使其必须由参与者。（还记得基础用例可以有对于本系统完全被动的参与者么？？ ：）
    注意点：虽然一般用例在建模时有很多限制，但是个人觉得在作次用例建模时，应该放开自由发挥只要能说明问题即可。include extends use ... 随便,不用太担心这些东西的定义。

    对于有经验的领域可以多次进行次用例迭代，从而减少系统整体开发的迭代次数。只要做得好完全可以做到只用瀑布式方式开发。（当然个人觉得不太可能做到赫赫，用户是善变的。）

    参考：
   咏武的“用例建模”