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