10年间,致力于中国最专业的UML解决方案
UML一站式解决方案   Trufun QQ:344593239   咨询热线:029-62375359 13379288210  

用户、业务用例和业务场景


时间: 2017-08-10    来源: 楚凡科技

  让我们先回头看看需求吧,图书馆主任是这么说的:
    我们原本是一个传统的图书馆,传统的借书方式要求读者亲自来到图书馆,这显得非常不方便,而且随着藏书的增加和读者群的增长,尤其而且大量的读者到图书馆,使得图书馆的场地不足,工作人员也不够了。所以想到借助网络,让读者通过网络借/还书,这样可以省掉大量的场地维护和工作人员成本支出,同时计算机可以方便的检索目录,让读者可以足不出户借到需要的书。为了把书送到借阅人手里,我们已经联系了A特快专递公司和B城市物流公司,初步达成协议,由他们往返借阅人和图书馆之间把图书送出和收回。读者在网上出示和验证借书卡,找到他们需要的书,提交申请,图书管理员确认后,就会通知物流公司来取书,当读者拿到书之后,物流公司需要把读者的签单拿回来以证明读者已经拿到了书。当然这个过程中,读者是需要付费的。还书也是基本同样的过程。
    还记得上一篇是怎么说的吗?第一步骤是从涉众中找出用户。并定义这些用户之间的关系。 这里的用户是指将与要建设的系统发生关系的那些涉众。通过下图表示。这张图里要绘出所有用户,以及它们之间的关系。需要说明的是,这里的用户指的是业务用户,并非将来系统中的“角色”,虽然将来它们可能就是。这张图的意义在于,清楚的表明将来的系统是为谁在服务,他们都是干什么的,有什么特点,有什么关系。对用例方法来说,这是最基本的出发点。用例,是以人为本的。
    第二步,找出每个用户要做的事,即业务用例。业务用例来自于系统分析员对上一步中所有用户的访谈,总结和归纳(笔者正在考虑写一写系统分析员调研技巧方面的文章,会对访谈技巧,归纳方法有所描述)。笔者建议从每个用户的角度以及从每项业务的角度来绘制业务用例图。从用户视角查看每个用户在系统中将参与什么业务。这个视图的意义在于,调研对象一眼就能看出来,这个模型是否已经涵盖了他所有需要做的事。
从业务的视角查看每项业务是由哪些用例和哪些角色参与完成的。这个视图的意义在于,需求研讨会上业务专家可以一眼看出这个模型是否已经能够完整的表达业务。
   第三步,针对每项业务视图,应该绘制业务场景图,用活动图详细描述这些用户、用例是如何交互来完成这项业务的。
    业务场景图可能不止一个。同样一项业务,会有很多种不同的业务实现方式,例如借阅图书业务,就有可能第一次借书,又还书又借书,VIP客户借书,借书时借证已经到期....等等许多种场景。对于这些场景来说,每一个都不能漏掉或省略,至少必须在文档中体现出来,除非已经很明确这个业务场景不包括在系统范围之内。这些业务场景图的意义在于,它已经绘制出了一份系统蓝图,将来的系统建设很大程度将依据这些场景图进行。
    经过上面的三个步骤,我们得到了用户、业务用例以及业务场景。这三项工作成果已经形成了基本的需求框架,并圈定了业务范围。就笔者的工作习惯而言,在得到这三个成果后,就会暂停调研,而通过评审会,研讨会等形式充分论证这些成果的正确性和完备性。求得业务专家,用户代表,开发方,项目经理等各方的一致认可,将其作为第一份基线。笔者很少在这个基线形成之前深入细化需求,因为需求过程,或说用例过程是一个自顶向向下的过程,RUP中的每一个迭代实际上仍然是一个瀑布模型,大家都知道,如果上一步没有形成基线就进行下一步,对瀑布模型来说是无法控制的。

Trufun十五年专注致力于软件工程全过程解决方案,提供从需求、分析、设计、开发到测试的完整管理开发过程,愿与各方进行科研、开发等方面的合作。
分享到: