专业,你们的交流使你获得了比这多的多的消息, 但无论如何, 你的经验会告诉你:你第一次获得的东
西永远都不可能是完备的,你也永远不要奢望第一次就能讲全部的需求都搞到手。
那么获得了这样一段并不完备的描述后,我们应该做些什么呢?继续追问?NO,能获得这样的需求在目
前看来我们已经做的足够好了。 自己去完善客户的需求并交付开发人员去开发?NO,要知道使用系统的
是客户而不是你。也许你可以为客户设计一套流程,或者一个订单的样式,但那可能并不是客户所需要的,
假如你认为客户不大会授权你去为他们在某些方面进行设计,你就千万不要去自作主张。当然绝大多数客
户都是懒惰的,大部分的情况是他们非常乐于让我们先帮他们思考,然后他们在我们思考的基础上给出些
意见就行了。是的,这就是我们下面要做的事――分析这段需求,找出这段需求中的隐藏信息,分析出他
们要做的这套系统究竟会涉及到哪些人(涉众),并简单的为每个涉众列出你所能想到的他所要做的事情,
然后将这些以易于客户理解的方式告诉他们所有相关的人员,然后她们就会在此基础上提出她们自己的想
法,你记录下她们的这些想法,对这些想法进行分析后将它们补充到你的需求里,之后再将你这个最新的
分析后的需求提交给客户审查,如此迭代,直到客户说 OK,我要的就是这个东西。
如果你没有和系统的所有相关者(涉众)进行过交谈,并获得了有用的信息。永远不要说你已经做好了需
求
下面我们就具体讨论一下如何去分析这段需求。此时用例开始登场。当然本文档讲的是一个推导过程,不
是一个迭代过程,故在下面的描述中我们不考虑迭代的因素,所有的分析都是假设在一个很顺利的环境中
进行,这样也许会让你觉得条理更清晰一些(包括上面那段不完备的描述在这里我们都假设他已经是很完
备的了)。
当然在继续往下介绍之前,为了更加专注于需求的功能要求,我会回避掉前面提到的一个概念“涉众”,而
改用“执行者”代替。执行者是涉众的一个子集,涉众是同你要开发的系统相关的一切人或物,而执行者则
是同你要开发的系统直接接触的一切人或物。从这两个定义上我们可以看出,涉众可能不是这个系统的直
接操作者,例如一个用于控制机床运作的系统,财务部门可能不会去使用,但因为项目的款项是由财务部
支出,所以财务部门是和本系统相关的人或物,所以它是涉众,但却不是执行者。
对于执行者的确定过程,本文档不再作相关的描述,下面只给出此描述里的执行者的相关 UML 图形
RUP 的所有分析都是从确定执行者开始的。以后的所有分析也都是基于执行者,整个需求的获取与分析
过程都是围绕着 某某执行者 做了 某某事 进行的。当然这也是面向对象的分析方式,非独 RUP。
确定了执行者,那么下面我们就开始为每个执行者确定其所有的用例,这里已经是第三次提到用例了。当
然在这里我还是不会给出他的定义,你目前要做的不是追问这个问题而是继续的往下看。然后在下面的分
析中总结一下自己对用例的理解,并自己给出一个定义或者不断的修改你的定义。当然在最后。我会在适
当的地方给出用例的定义。这时你可以拿它和你的定义进行比较。也许你会发现。其实你的定义比我给出