需求分析是系统设计和开发的基础，需求分析的好坏会直接影响后继设计和开发的质量，严重时会影响到系统的成败。UML中的用例图就是为了方便我们分析与交流产品需求而生，同时也为我们把产品需求转化为系统需求提供方便。产品需求：一般反映的是现场的具体现象，经常是由产品工程师/销售人员收集或由用户直接提供，表现的较为松散、粗放，是一种比较切合现实的描述。系统需求：一般是在对产品需求进行一定的分析后，对其中不能实现或实现起来有困难的部分进行了一定的取舍，同时对一些较为笼统的需求进行明确和细化，甚至会对一些需求进行了一定的抽象和重组。HYPERLINK有时也会结合具体应用加入了一些逻辑的描述（即现实以外的抽象术语），表现的更加切合软件系统。一般在评审通过后，系统需求会以《产品需求规格说明说》的方式提供，并成为系统开发的范围依据。接下来我将介绍一下本人在用例分析过程中的一些心得和休会。一、“Somebodydosomething”模式在我们对需求进行分析时，我们可以本着“Somebodydosomething”的模式来寻找用例/关键用例，当然这里的“somebody”可以泛指人、物或其它系统等。我们可以以“做某件事”作为一个用例，而后成为系统的一项功能，即满足一点需求。如果能DO完所有的THINGS，那么我们的系统也就成了。二、用例分析要注意事项1、单一场景，即每一个用例只为说明一件事，我个人反对包罗万象的“上帝”用例。2、简单原则，即每一个用例要通俗易懂，能非常明确、简洁地说明其某项功能和作用，无任何歧义及多余的想象空间。3、唯一性，即每一件事/场景只能出现一次，HYPERLINK如果其它地方要用到同样的场景可以采用“引用”的方式进行组合。三、分而治之个个击破的思想1、N阶的问题在对新员工面试时，我一般会问一个“汉诺塔”的问题，在这个过程中我并不看重答案，只在呼解决问题的方法。即递归中是如何把“N阶的问题转化成N-1阶，最后成为1阶的问题”的思想。其实需求分析也是一个要把错综复杂的N阶问题，最后转化成1阶问题的过程，这种从N至1的方法不仅在需求分析中能用上，其实在后继的其他设计中也一样很有用。2、自上而下或自下而上对需求的分析我们是可以采用自上而下或自下而上的进行分析，相信这些大家都有耳闻，在此不做详述。就我个人而言比较喜欢“自上而下”的分析方法，即由“宏观”到“微观”的过程，其实有点像我们任务分解中的WBS分解方式。对需求中描述的场景和所要解决的问题应用“单一场景”、“简单原则”和“唯一性”逐一分解，至到合乎要求为止。拿我们的“MusicStore”项目来说吧，系统无非是“系统出售唱片”（当然这个需求有点简单），但要满足这个要求就得提供“管理员提供唱片”和“客户购买唱片”等功能。以此类推“管理员提供唱片”可能会引发“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”等新的功能；同样“客户购买唱片”可能引发“客户添加唱片到购物车”、“客户移除购物车中的唱片”和“客户结帐”等功能。如此反复递归，我们最后会发现好像用户要的功能我们都能提供且足“单一场景”、“简单原则”和“唯一性”的要求。如果真是如此，那么我们的分析过程基本也就告一段落，之所以说是告一段落，是因为一些复杂的需求只对其表象进行分析是远远不够的，还得站在更高的全局的视角来进一步审视，可能还得对其进行一定的重组甚至抽象，直到满足系统的要求，后继我们将会有相关的例子。3、边界和委托边界，在需求定义的场景中，有一部分场景他们的工作背景和工作方式都比较类似，且彼此之间有着较为紧密的联系，那么这些用例就可以组成一个相对封闭的区间，这就是用例边界。有时候我们也会根据不同的actor来区分不同的边界。比如：“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”就可以认为是“管理唱片资料”这样一个边界。由于VS2010并未提供Boundary功能，而是以subsystem来提供。为了更好的说明问题所以此处提供2张图，第二张由EA绘制。有时我们会把同一个边界内具有相对内聚性的用例抽象成一个用例。委拖，在进行用例分析时，当出现有些用例已超出了当前的边界，但是与边界内的一些用例又有较为紧密的关系时，我们往往可以考虑使有“委托”的方式来，简化分析过程。就拿“客户结账”用例来说吧，它可能会引发出“系统查询帐户余额”、“系统转账”等一系列新的用例出来。此时我们可能会出现，其实我的目的就是“结帐”，至于怎么结帐及结账的细节并不是我在本场景的主要议题，由此可能可以确定“查询帐户余额”等已超出本用例的边界，从而我们可以“委托的方式”委派给“银联系统付款”，从而一笔带过。有