案例分析： UML大战需求分析.docVIP

　　案例分析： UML大战需求分析 本文会借着一个小的案例分析，来简单的说明下会常用到的几个UML图，主要包括顺序图、用例图、活动图以及状态机图，另外文章的最后部分会将这些UML的图例和我们平日工作里用到的泳道图、流程图做一些简单的对比总结。 以前的文章中也写过一些需求分析的内容，但是更多的其实是偏向于需求挖掘的理论知识，可实践性并不是很强，不管最终需求分析的结果如何，最终都是由相关人员去实现的。面向设计师的部分的主要产出物就是我们通常说的线框图，那面向开发测试人员的产出物呢？ 给到开发测试人员的需求产出物常见的组合形式就是需求说明书+流程图…而UML可以帮助我们更好的完成需求分析以及流程梳理这部分的工作，换言之，也就是线框图之前的部分工作。UML即Unified Modeling Language 叫做统一建模语言，适用于数据建模，业务建模，对象建模和组件建模。 之前就有朋友给我安利过产品经理应该懂点UML，后来我就去补了一下相关的知识，觉得是受益匪浅，尤其是在业务逻辑比较复杂的情况下，这套方法真的是很实用。虽然说UML的方法有些已经不太适用了，但是UML的思想却是仍然适用的，在我们平时画流程图的时候，很多都体现着UML的思想，可能我们自己都并不是很清楚罢了。 首先说明一下，我自己对UML的理解也并不是很深，只是将自己的一点理解和看法和大家分享一下，只是为了抛砖引玉，文中有不正确的地方望加以指正。而且文中只提到了UML中常用到的几种图例，关于更多的内容感兴趣的小伙伴可自行学习查阅相关资料… 另外文章的案例相关的部分是行文过程中初步考虑的，可能会存在考虑不周全的地方，而且相关流程图也只考虑了主线流程，未考虑分支流程和异常流程，不足以达到直接指导开发的程度。因为本文主要想传递的是一种方法论，一种思考方式，下面我们开始正文部分。 本文会借着一个小的案例分析，来简单的说明下会常用到的几个UML图，主要包括顺序图、用例图、活动图以及状态机图，另外文章的最后部分会将这些UML的图例和我们平日工作里用到的泳道图、流程图做一些简单的对比总结。 一．背景说明 平时在公司附近吃饭的时候，经常会和一些店铺的收银员、服务员以及老板打交道，这就是文中案例的灵感，没有详细的市场行业调研，也没有详细的用户访谈和数据支撑，只是简单的实地观察和部分访谈，以及主观的YY。 接下来为会大家展现一款点餐系统从0到0.5的思考全过程，该点餐系统主要的目标就是为了能够提高店铺的运营效率，提升顾客的就餐体验。之所以是0.5，是因为分析过程到原型设计之前就截至了，但是个人觉得原型是处于最表现层的东西，背后的支撑系统以及流程才是更重要的东西。 二. 用户及产品分析 产品是解决问题的手段，而不是说一定需要做产品，一定要切记这一点，最本质的其实是解决问题，产品只是一种手段。用户则是产品的最终使用人，可能会有一个或多个类型的用户群体。 1. 用户分析 经过这段时间在该店面的观察得知，该店面的角色主要分为4种，分别是收银员、服务员、厨师以及老板， 这几种角色可能都是需要使用点餐系统的，也可能只是部分需要使用。 2. 场景分析 在没有点餐系统之前，该店面是这样运转的，老板负责和顾客进行交流，确定点餐之后就记下来，然后将原件给到收银员，服务员拿着手抄的复印版给到后厨，后厨做好菜之后，由服务员进行上菜，最后由服务员进行结算，收银员进行记账。 这样的一个整体流程的弊端就不再赘述，除了在一些很小的门店，应该也会较少见到这种模式了。我们平时在其他地方的点餐流程基本都是收银员完成点餐、下单、收银的流程，然后通知到后厨，最后由服务员进行上菜，经过简单加不严谨的分析可以得出相关的需求如下： 3. 产品分析 接下来就到了需求分析和排优先级的时候了，是所有用户的需求都要满足么？肯定不是，即使是目标用户的合理的需求也肯定不会都满足，可以看到在这个点餐系统里的主要角色有老板和收银员，其余两个则属于支撑性的次要角色。 也就是说保证老板和收银员能够正常使用的话，这个点餐系统就能够正常的运转，只需要将相关的订单信息传递到服务员和后厨处即可，老板和收银员使用的肯定是两个不同的系统，经过分析之后可以得出，一个点餐系统+一个后台管理系统即能够初步满足大部分受众的需求。 三. 业务分析 因为本文的前提就是利用UML来进行分析的，所以这部分的分析会通过顺序图来完成，顺序图和我们平时使用的泳道图很像，说实话，我平常在这块也是用泳道图来进行相关业务分析的，只在某次涉及到系统之间对接的时候用过一次顺序图。 顺序图主要适用于多角色之间的交互，角色可以指人也可以指系统，主要是通过时间和顺序来表明发生的事情以及相应的信息传递，适用于对时效性要求较高且不太复杂的全局流程，不太适合用来表达分支流程和异常流程较多的情况。 在我们上述的案例中