精品文档---下载后可任意编辑 需求分析是系统设计和开发的基础，需求分析的好坏会直接影响后继设计和开发的质量，严重时会影响到系统的成败
UML 中的用例图就是为了方便我们分析与沟通产品需求而生，同时也为我们把产品需求转化为系统需求提供方便
产品需求：一般反映的是现场的具体现象，常常是由产品工程师/销售人员收集或由用户直接提供，表现的较为松散、粗放，是一种比较切合现实的描述
系统需求：一般是在对产品需求进行一定的分析后，对其中不能实现或实现起来有困难的部分进行了一定的取舍，同时对一些较为笼统的需求进行明确和细化，甚至会对一些需求进行了一定的抽象和重组
有时也会结合具体应用加入了一些逻辑的描述（即现实以外的抽象术语），表现的更加切合软件系统
一般在评审通过后，系统需求会以《产品需求规格说明说》的方式提供，并成为系统开发的范围依据
接下来我将介绍一下本人在用例分析过程中的一些心得和休会
一、“Somebody do something”模式 在我们对需求进行分析时，我们可以本着“Somebody do something”的模式来寻找用例/关键用例，当然这里的“somebody”可以泛指人、物或其它系统等
我们可以以“做某件事”作为一个用例，而后成为系统的一项功能，即满足一点需求
假如能 DO 完所有的 THINGS，那么我们的系统也就成了
二、用例分析要注意事项1、单一场景，即每一个用例只为说明一件事，我个人反对包罗万象的“上帝”用例
2、简单原则，即每一个用例要通俗易懂，能非常明确、简洁地说明其某项功能和作用，无任何歧义及多余的想象空间
3、唯一性，即每一件事/场景只能出现一次，假如其它地方要用到同样的场景可以采纳“引用”的方式进行组合
三、分而治之个个击破的思想1、 N 阶的问题 精品文档---下载后可任意编辑 在对新员工面试时，我一般会问一个“汉诺塔”的问
