软件需求中用例的设计

 需求是软件的源头，如果源头没有做好，对整个软件影响是非常重大的。这个源头好做吗多年前看过一个漫画，分享一下：

  这个图片一方便说明信息在传递过程中的失真，另一个方便也说明流程规范的重要性，在这里我们推荐在整个软件开发生命周期内使用UML(统一建模语言)来交流,避免沟通的失真(据说我们在正常语言沟通过程，我们的信息最多百分之十五被对方理解，这的很可怕！)。这次我们探讨一下UML模型之用例设计(为了讲解方便，我们以目前订餐的业务为例说明，其中涉及人和事不要对 入座，只因这个业务大家都熟悉，而且简单)。

   科学发展观:第一，以人为本的发展观;第二，全面发展观;第三，协调发展观;

第四，可持续发展观。以人为本,我们UML用例也是以人为为本的。

一、参与者

1：参与者概念

参与者是系统之外与系统交互的人或物。

  公司甲员工中午需要订餐，去找前台交钱订餐；公司乙员工也需要订餐，去找前台交钱订餐，但是前台不在那里，乙员工由于忙将钱交给丙员工，请其帮忙定餐。

这个业务非常简单，对于这个业务我们来分析参与者，参与者一般满足下面三个条件：

a：有明确的愿望的目标

b：主动发出动作

c：系统为他服务

甲员工有明确的愿望目标：订餐；并且主动发现请求动作；最终系统将甲的饭定好，为甲服务，所以甲是参与者；乙同样也是参与者；而前台和丙员工都不满足条件，在没有其他员工发出订餐请求之前，他们不会做任何事情，系统也不是为他们服务，他们只是在员工订餐过程中协助。那前台和丙员工是什么确实参与业务，因为没有他们，这个业务是不完整，这个时候我们把前台和丙员工叫做业务的配角(也有叫做业务工人)，而把甲、乙员工叫做主角(真正参与者)。

这个时候我们回到参与者的定义中，注意参与者是系统之外，那说明甲、乙员工在系统之外，而前台和乙员工及订餐操作在系统内，这个时候我们确定这个业务系统的边界。

这里需要说明一下，参与者不仅仅是自然人，也可以是其他系统、事物等，假如我们订餐系统开通手机订餐系统，有个丁员工为来省事，在手机开发定时订餐的软件，那这个定时器或软件就是我们这个业务的参与者。

找到来参与者，对于我们有什么好处p>

a：我们需求调研人员和分析人员要以参与者的角度看待问题，不是自己的角度，更不能加入自己的主观判断。以前刚开始做需求分析的时候，因为有多年开发的背景，在搜集客户需求的时候，总是喜欢从计算机系统的角度去思考，第一时间考虑程序语言如何实现，并且向客户讲解，希望客户能够用这种方式来实现。客户由于不能理解计算机系统，更别说程序语言，但是处于对专业的信任，可能说：是的，就这样。但当最终系统放在客户面前的时候，客户抱怨的说：你们做的系统不是我们想要。而我这个时候却想：特别委屈!就是按照你（客户）的要求来做，你还确认的吧，当时不说，东西做出来说不好，你不是来找茬的吧。

b：可以整理功能需求，如果你发现客户提的一个需求没有主动发出者，或者没有参与者，那这个需求一定不是功能性需求，可能是一个需求的约束。比如：我们订餐系统客户，客户要求有美观的页面，而这个需求实际没有真正的触发者，那这一个需求就是一个约束，不是一个功能性的需求。

c：确立系统的边界，参与者是系统之外，与参与者交互则在系统之内。

d：做软件需求就是要解决参与者的愿望，如果你找到参与者的愿望，实际已经成功一半。

   2: 参与者与其他人员的关系

       参与者与干系人的关系。干系人是和项目有利益的人和事，所以参与者是干系人的代表。比如，我们订餐系统涉及到公司所有员工，那我们在做用例设计的时候不能把所有员工都画上，只要画上这个类别一个代表即可。

       参与者与用户的关系。用户指使用系统的人，用户是参与者代表。比如：我们订餐系统，部门经理可以帮助部门成员订餐，那这个时候，部门经理就是代理部门成员的参与者的功能。

       3:参与者具有核心的地位

          参与者具有核心的地位，系统是参与者的观点的决定，参与者对系统的描述，决定系统的功能 ，最后我们在需求设计问自己几个问题：

         a：是否找到所有的参与者

         b: 是否为每个参与者找到其功能

         c：参与者的功能是否具有相似，如果相同，则应该合并一个角色

         d: 如果两个以上参与者具有相同功能，那我们就抽象其父类(UML中叫泛化)

         e: 参与者是否以多个不同的方式使用系统，那将有多个参与者

    到这个时候，也许我们已经可以确定系统的参与者，从而可以确定系统大部分功能，下面我们探讨一下这些功能如何的呈现，并且与客户的沟通 (下次后续)。