用议论文三要素，搞定需求分析（上）
软件开发流程大概分为需求阶段、设计阶段、编码阶段、测试阶段、运维阶段这五大阶段。
某项研究分析了63个软件开发项目，对于需求错误在软件开发项目的不同阶段，发现并改正所损失的成本进行了研究与评定，得到了如下表格：
由图表可以发现，越在后面的阶段，因为需求错误而带来的损失成本也就越大，而在需求阶段发现并改正的损失成本是最低的。这是因为越到后面投入的人力资源与时间越多，如果在初期能准确分析好需求，便不会带来之后的损失，故需求分析在软件开发中处于关键地位。
需求分析三要素
那需求分析怎么做呢？凡是都是有规律可循，需求分析也不例外。说白了，就有点像议论文写作。来来来，我们看一下百度百科对议论文的定义：
议论文，是一种剖析事物，论述事理，发表意见，提出主张（论点）的文体。作者通过摆事实、讲道理、辨是非等方法，来确定其观点正确，树立某种主张。议论文应该观点明确、论据充分、语言精炼、论证合理、有严密的逻辑性。
移花接木一下：
需求分析，是一种剖析参与者需求（老板、用户、业务人员等等），抽象事物，组织概念，建立业务模型的过程。产品经理通过明目标、理业务、面向对象等方法，来确定需求，建立业务模型。需求分析应当目标明确，用例充分、语言精炼，论证合理，有严密的逻辑感。
嗯，有点感觉。
既然议论文有三要素：论点、论据、论证，那需求分析有三要素吗？
- 论点：提炼抽象后的业务模型
- 论据：即论点的根据，业务模型的根据便是宏观上业务模型的整体结构，告诉你系统有什么。
- 论证：即用论据证明论点，从词性上判断，这是一个动词，同样证明业务模型其实就是强调怎么把系统整体结构的元素联系起来，告诉你系统怎么做。
毫无违和感，有木有。
开始bb！
业务模型
模型，即通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟、不限于平面与立体）。
相似地，建立业务模型的目的就是为了表示业务需求并获得对业务需求的理解，然后对业务需求进行便于理解的表达。这是能证明你是否正确且完全理解业务需求的工具，也是你与开发人员表达说明业务需求的利器，切记不能让你的理解停留在脑海里！
业务目标
我们先来思考这么一个问题：某餐厅老板想要为其餐厅设计一个餐厅管理系统。面对老板如此抽象的需求，你会如何去分析呢？
大部分的思路往往是先梳理大致的业务流程图，然后针对每一个步骤，进行用户访谈，询问业务中的细节。
可你有没发现，如果一这么做，就会陷入细节的泥坑。技术的细节、咦这个能不能实现；交互的细节，咦这样交互肯定不行的；UI的细节，咦这里设计成下拉框？这样的结果便是，自己的思路越来越凌乱，最终往往就是靠直觉做决定了！直觉可不给你背锅啊！
解决问题有这么一个方法：在面对问题的时候首先不要决定去通盘考虑，而是找出问题领域里包含的抽象角度。如果把抽象角度都找全了，并且这些角度都分析清楚了，问题也就解决了。
抽象角度的理解就好比：当问你刀与叉的区别是什么的时候，感觉自己无从回答。而问你刀与叉在使用上的区别是什么，便豁然开朗，一个是切，一个是叉。这里的使用角度就是一个抽象角度。
需求分析也是一样的，具体来说，做需求的时候，首要目的不是弄清楚业务是如何一步一步完成的，业务包含了哪些细节，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。
（这里便用到了面向对象分析方法，面向对象的好处便是可以集中注意力在要分析的对象上，排除其他因素的干扰。这也就是为什么程序员拿到需求之后，不是直接码代码，而是先建表，厘清一个个实体对象与它们之间的关系，就是这个道理。）
回过头来，首先找出系统的所有参与者，然后进行初步的用户访谈，明确业务目标，大致可以分为：
- 顾客：提供用餐自动化服务，提高点餐效率，方便顾客。
- 服务员：提供管理订单服务，记录每桌的点的菜品，检查每个订单的上菜、收费情况等。
- 店长：提供财务管理服务，记录每日的收银。
- ……
这里我们用数学简单的公式提炼一下，可得到这样一个公式:需求分析=∑（1到无穷）业务目标，意思便是：要全面地分析需求需要找到所有的业务目标（抽象角度）。
用例
所谓的用例便是，参与者带着目的去做一件件事情，这些事情都围绕着目标，而这些事情可以有很多不同的方法或是遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的。
这些不同情况便是场景。如图便是用例的构成:（小技巧：用例必须满足动宾结构）
就拿第一个业务目标：为顾客提供用餐自动化服务，提高点餐效率，方便顾客，这一业务目标来说，可以定义的边界为“顾客用餐服务”。从名字就可以明确业务目标是为顾客用餐服务的。
边界决定了系统首要的问题是解决顾客的期望，也就是说，系统首先要满足顾客的需求。用餐方式分为堂食和外卖，其用例便有点餐、下单、买单。如图所示：
这里又可以得到一个公式：业务目标=∑（1到无穷）用例
场景
那如何思考全场景呢？换句话说，我们需要思考全场景的抽象角度。场景的构成要素：时间，地点、人物、行为可以帮助我们分析。
- 时间：餐厅营业时下单，餐厅休息时下单
- 地点：堂食，外面吃（外卖）
- 人物：单人点，多人点
- 行为：添加菜品、删除菜品、修改菜品、查询菜品（增删改查）
以此类推，得到所有满足用例的场景。上公式：用例=∑（1到无穷）场景
小结
这一篇讲解了需求分析的论点——业务模型，以及业务模型的建模思路，取其精华，可以用如下图所示的公式来表示如何建业务模型。下一篇将着重讲讲需求分析三要素的论据与论证。
用议论文三要素，搞定需求分析（中）
先回顾一下上一篇文章的内容，主要讲业务模型这个“论点”的分析思路：以业务目标这个抽象角度作为分析的切入点，梳理需求；再引入用例，通过场景分析，对用例进行细化，最后得出分析业务模型的归纳公式：
讲完论点，此篇文章就来bb一下，需求分析的“论据”。需求分析的“论据”就是业务模型的整体结构，传达系统有什么？
为了更好地理解这个问题，回答之前，首先我们思考一下这个生活问题：西红柿炒鸡蛋有什么？换言之西红柿炒鸡蛋的食材有什么？
这点生活常识，我还是有的。
果断百度了一下，西红柿炒鸡蛋的食材：番茄3个，鸡蛋3个，油10g，盐5g， 鸡精3g。
so easy，但别小瞧这几个简单的数字与文字，它表示了各食材、佐料之间的数量关系（番茄与鸡蛋的数量关系、油、盐、鸡精之间的数量关系等），缺少某样食材或者各食材、辅料的数量关系不对，都会影响西红柿炒鸡蛋这盘菜的最后结果。
同样系统也是这个道理，而在软件中，这个物叫“类”，实际上就是一类事物的意思，一张桌子是一个对象，桌子就是一个类了，其实用户是很容易理解的，它就是“类型”的意思。很多商业系统只有1个、两个或三个核心的类，围绕着这几个类产生大量的处理流程，系统就是为产生和操纵这些东西开发的。
类的构成很简单，由类名、属性、操作组成。类名是类的名称、属性是类拥有的信息、操作是类提供的服务。
如图为类的表示方法：
回归正题，有没有发现，需求分析的“论据”就是用类映射现实世界，以类作为核心，描述系统的结构框架，来表示系统有什么？
那如何用类来做结构框架分析呢？
主要步骤包括这三个：
- 根据每个业务场景、流程，需要从中发现找出各种类；
- 再分析它们之间的数量关系、逻辑关系；
- 然后在明确物的属性与操作，最后得出结构框架。
讲完思路，下面就来小实战一下。
发现类
同样，还是以上篇文章中的“餐厅系统”为例。
就餐的大概流程：顾客在“真好吃”餐馆吃饭，通过手机扫描二维码进行点菜，翻阅菜单查看菜品，菜品种类有热菜、冷菜、小吃，点菜完成后，系统需要将小明点的菜品记录，生成订单，并生成送菜单发送给对应的厨师（负责热菜的、负责冷盘的、负责小吃的），厨师做完菜后，通知服务员端菜，服务员根据送菜单上的餐桌号，将菜端到顾客面前，顾客就餐完结账。
有一点不同的是现实生活的对象往往是具象的，类容易理解找出，系统的对象往往是抽象的，不容易找出与分辨，且具有十分多的属性需要分析，判断是否可以作为类。不过，也是有“名词动词法”去帮助我们去分辨。
“名词动词法”，其主要规则是从名词与名词短语中提取类与属性；从动词与动词短语中提取操作与关联；其实就是名词对应类或者类的属性，动词对应类的操作。而所有格短语通常表示属性（格式：xxx的xxx，例如：餐桌的号码牌，号码牌就是一个属性）。
名词有：顾客 “真好吃”餐馆 菜单 热菜 冷菜 小吃 菜品 订单送菜单 餐桌号 厨师 服务员。
很显然，并不是每一个名词都是可以作为类的，有些名词对于开发的系统来说是无关紧要的，甚至是系统之外的，而有些名词适合作为属性。
顾客，会对系统产生作用，会下订单，可以归类到“顾客”这个类中。
“真好吃”餐厅“厨师”“服务员”不对系统产生作用，是系统外的概念，不属于类。
热菜、冷菜、小吃都是菜品的类型，菜品是可以作为类的。
菜单作为统计菜品的主体，具有统计的操作方法，可以视为一个类。
订单包含了下单时间、餐桌号、顾客点的菜品与付款类型，是一个类。
送菜单包含了该菜的信息、餐桌号还有自身的编号，也是一个类。
餐桌号概念过小，只能作为订单的属性。
所以提炼出：菜单、菜品、顾客、订单、菜品单。
明确类之间的数量与逻辑关系
类之间最常见的逻辑关系有三类：关联、泛化、聚合/组合。
关联：说明两物有联系，用一条直线连接。比如顾客与订单之间有联系。
泛化：子类从父类中继承，使用空心箭头的实现表示。就如图上述例子，菜品是父类，热菜、冷菜、小吃作为子类继承了菜的特性，同时具有自己独特的属性。
聚合与组合关系：整体与部分的关系。区别在于，聚合中的部分可以独立于“整体”存在，而组合中的部分“完全依赖于整体”。这里菜品与菜单就是聚合的关系，菜品可以独立于菜单而存在。
并根据以上的逻辑关系，对每个类进行分析，同时思考他们的数量关系，分析过程如下：
综上，可以得出初步的类图。
明确类的属性与方法
当找出了系统的类，并厘清它们之间的数量关系与逻辑关系之后，就可以确定类的属性与操作了。根据目前的业务描述，可以找到以下的属性与操作：
- 菜品类：属性有菜品编号、菜品名称、菜品类型、价格
- 订单类：属性有下单时间、餐桌号、价格、付款类型
- 送菜单：属性有送餐单号
- 顾客：属性有人数
接着使用“名词动词法”，来找出类的操作，动词有：吃点记录、发送做通知端、统计。
当然动作都是由类发出的，根据第一步的找出的类，就可以排除掉不是类发出的动词：服务员的端、厨师的做、厨师的通知。另外顾客的吃不对系统产生影响，因此也排除，最后剩下：
- 订单：记录菜品；
- 送菜单：发送；
- 菜单：统计菜品。
将以上这些属性与操作加入原先的模型，就可以得到一个完整的类图了！如图所示：
小结
结构框架分析是一个自底向下的过程，先根据每个业务场景、流程，需要从中发现找出各种类；然后分析类之间的数量与逻辑关系，将类联系在一起，最后确定类属性与操作，绘制出“类图”，完成结构框架分析。
结构框架就如同议论文中的“论据”，它是“论点”的根据，它也是系统的根据，需要绘制出类全面且关系清晰、属性与操作明确的类图，可视化地表示系统有什么。
用议论文三要素，搞定需求分析（下）
业务流程是什么？
系统的核心价值之一是顺利推进业务，提高效率，尤其对于B端的产品，而业务则是由一个个的业务流程组成。
那什么是业务流程？
业务流程是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。流程是由每个人的活动组成的，每个活动又会有相应的执行步骤。
另外，从不同的角度来看，有不同的流程；流程会有大小之分；流程之中可能会有子流程等，诸如此类。
流程问题可能很复杂，我们需要系统化地分析好这些流程，清晰地描述事情在某段事件内是如何发展的，这些发展最后会达到怎样的效果。
表达完后，视情况对现有流程进行分析，设计出优化的业务流程，提高效率。
描述业务流程大家可能第一时间会想到用流程图，但流程图有许多局限的地方，例如不能表示同时进行的动作，只能有一个结束点等。所以，推荐使用活动图来描述业务流程，一种UML（Unified Modeling Language）模型。
业务流程的层次
在介绍活动图之前，首先需要明白，活动图是在与业务人员沟通需求时得来的，同时借助活动图，来验证业务流程是否正确。所以，需要根据业务人员的类型，画出对应层次的活动图。
业务流程天然可以分成三层：最宏观的是组织级流程，画的是部门、角色间的协作关系，供高层领导阅读；第二层是部门级流程，画的是岗位间协作关系，供中层领导阅读；第三层则是个人流程，画的是一个岗位的工作步骤，应该到业务场景分析时再细化。
活动图的画法
还是以餐厅管理系统为背景，来介绍一下怎么画活动图，如下就是一个基于宏观层面的顾客点外卖的活动图。
活动图的主要元素
1）开始点和结束点
开始点用一个实心圈表示，结束点用一个圆圈内加一个圆圈来表示。活动图只能有一个起点，但可以有多个终点的。
2）活动
当一个流程中有了分工时，必然会将一个业务事件拆成一系列更小的、相对独立的工作人物，这就是“活动”。活动用圆角矩形表示，例如图中的“顾客提交订单”“顾客选择支付方式“就是活动。活动可大可小，具体的粒度视流程图层次。
3）判断
菱形代表分支判断，表示从这里开始将根据条件选择其中一条分支继续下一个活动。
4）汇合与交叉
汇合与分叉必须组合使用，表示并发动作。分叉表示一个活动完成后产生后续的多个并行的活动；汇合表示多个活动全部完成后再进行下一个活动。
此外，你可以发现以上流程存在并行关系，当顾客提交订单后，会生成该订单给商家，同时顾客需要支付，这是一个并行关系。还存在顺序关系、异步关系等多种可能，这就是逻辑关系，在流程图中就是各个活动之间的连线。
如上便是正常的流程，但还需要考虑异常流程，比如顾客取消订单，或者订单超时导致的支付失败，完善一下。如果想让活动图清晰地表示对应的角色所负责的事情，便可以加入泳道，整理得出如下图：
总结一下，画活动图的基本步骤为：
- 选择合适的层次：根据读者的角色、流程类型选择合适的层次来描述流程分析的结果；
- 勾勒流程主体：厘清业务流程中的角色、活动、逻辑关系；
- 补充异常流程。
画完活动图之后，也可以用文字补充说明一下活动图的细节，输出业务流程描述，如图所示：
小结
活动图说明事情在某段事件内是如何发展的，这些发展最后会达到怎样的效果。
你有没有发现，这与我们在该系列的第一篇文章中的用例场景十分相似。确实，活动图就是来描述用例场景的，也就是通常所说的业务流程。
另外，在分析流程图中，有助于发现关键的类（上述例子中的订单），这又辅助《用议论文三要素搞定需分析（中）》所讲的类图。
所以，活动图这个“论证”，正好起到了证明类图（论据）是否正确支持了用例（论点）的作用。
最后，引用徐锋老师的一句话来做总结：
需求分析的过程就像在为一个大象画写真，如果你把眼睛放在离大象10厘米的地方，那么想要画完整是不可能的。因此，你需要先退到几米甚至是几十米的地方，把整个轮廓画下来；然后走近一点，将不同的组织部分分解开，最后将细节画出来。
如果放到需求中来，就是需要先厘清宏观部分（确认业务目标），再针对每个业务目标进行分解，细化成用例，建立业务模型。然后，描述系统的结构性特征（画类图），结构决定了这个系统能做什么。另一方面，我们需要描述业务流程（制作活动图），这些流程决定了系统怎么做。
经过以上三个步骤，才能把需求分析清楚。
最后的最后，不要忘记需求分析的核心问题以及目的——弄清楚客户到底想要什么的问题，设计解决方案为客户带来价值。