想学习架构师构建流程请跳转：
拿着需求文档，那你去逐字逐句去读，那么怎么读呢？审读就带着思考性的去审视它，去阅读它。
那么这个方法的主要目的呢，就是要发现功能点和业务流程。当然啊一份文档你真的要读，也不是说读一遍就结束，也可能反反复复要读很多遍。那么这个中间的过程呢，咱们也会采用迭代的思路。
我们做需求分析也是这样，不是说一步到位，一下就把所有的功能点、业务流程理解的特别透彻，也是采用迭代的方式。我首先去发现这里面有哪些业务功能点，还有了相应的业务流程，你看这就可以做一个迭代周期。当我发现了这些功能点和业务流程过后，后面呢咱们还会有具体的方法来帮助大去继续明确这些业务功能点的业务功能。还有呢去分析每一个业务流程，咱们也会有相应的方法。
所以说呢逐字逐句审读法最主要的目的就是来发现功能点和业务流程。
这个方法呢咱们在实际的工作当中用的非常的多，一起来看一下。首先我们来看一下业务走查法的主要目的。第一个业务走查法呢是为了加深对业务的理解。
大家都知道我们面临的业务是千差万别的，有些业务可能比较简单，但是有些业务会比较复杂，尤其是专业性比较强。作为需求分析人员，怎么能够加深对业务的理解呢？其实业务走查法就是一个非常好的方法。
假定在某一个场景下，那a发起了一件什么事，那么这就是起点，然后就按照你这个业务的流向，他发起这件事了。过后该到b好，我就走到b来看看b我想明白没有？然后b做完可能会到c那我就再去看看c我想明白没有？就这样一路把整个这个业务走一遍，直到你这个业务正常结束。
那好了，我这个业务走查就走完了。如果每一步我都能够理解的话，你这个业务我基本上也就理解了。所以说呢业务走查法有一个很重要的目的，就是用来加深对业务的理解。
一般来说啊，在需要通过业务走查法来加深对业务理解的话，这一块的业务可能是比较复杂的，相对是重难点的业务。
因为简单的业务根本用不上业务走查法，需求分析人员一看就明白了。那这次呢第一个目的，再看第二个目的，使用业务走查法呢来检查业务的完整性。刚才咱们讲到右走查法是从业务的起点开始，一步一步把你业务所经过的所有环节全部走一遍。当然啊这个走一遍肯定是模拟的逻辑上的走一遍。
并不是说你已经把软件做出来了，咱们现在还在做需求分析呢，软件是不存在的对吧？
基本上从需求分析到架构设计的全流程，都可以用上这个业务走查法。所以说呢在整个架构设计阶段，业务走查法是一个非常重要的常用的方式。那说了这么多，到底咱们如何进行业务走查法，咱们简单的来演示一下。当然这个业务呢咱们还可以用桨前一个业务的时候用的这这个业务。
大家看一下，咱们前面讲逐字逐句业务的的时候，是不是这给了一个业务的需求。虽然就只有两段话呢，但是可以认为我的一个需求就是这样。
那好，我们拿到它过后，现在呢就来应用业务走查法看看我们来检查啊，就说一个是加深对业务的理解，就按照刚才咱们这儿讲的这几个目的，一个是加深对业务的理解，第二个我们可以检查业务的完整性。
但是第二个检查业务的完整性，咱们已经可以。做了。因为呢咱们前面使用逐字逐句审读法，我们演示了一下，做出了一些业务的分析。就是我们做了一定需求分析，那我们现在就可以通过业务走查法来看看我们分析的完整不完整，可以的吧？好，那我们来看一看，还是这样啊，开始读吧。
这样的话大家会发现业务是不是才是完整的那大家自己对比一下，我们通过业务走查法，现在发现出来的这些业务和前面逐字逐句读发现的功能进行比较的话，哪一个更完整？很明显咱们现在形成的这个业务，你看从头到尾是不是才能真正走通。当然啊并不是说业务走查法比这个逐字逐句审读法更好。很多方法实际上是要综合起来应用的，并不是说你单一用某一个方法它能做到最好，而是把这些方法综合起来，那么效果是最好的。也就是说我们前面通过逐字逐句审读法得到了一些功能，但是这里头可能会不完整。那这个时候我们就采用业务走查法来把它走通，补充完整。
咱们总之不能留死角，千万不要咱们自己一拍脑袋，我们替用户去做主。
那这会完蛋了，千万记住我们是在帮用户做软件。所以说遇事不明，遇事不决寻找客户问，不要自己拍脑袋想咱们想的业务不靠谱。
好，那如何进行业务走查？那这个方法呢大家应该就能体会到了。事实上业务走查法呢可以用在架构设计的全流程。这个咱们前面呢也讲到了，就说右手查法不仅仅是在需求分析的时候用。
其实你高层架构设计的时候，概要设计的时候，详细设计的时候都可以用这个方法。
因为你在向前推进你的业务的时候，每一步你都可以停下来审视你的内部。
我们先来看看问题挖掘法在需求分析阶段的主要目的，主要就是全方位、多角度的进行业务的理解。
因为对于需求分析前面也讲过，它的目标就是要尽可能准确、全面、深入的去理解业务。
那么怎么做到要准确、要全面、要深入呢？问题挖掘法就是一个非常好的方法。
当然这个方法呀并不局限于在这个需求分析阶段用，事实上这个方法也可以用在架构设计的全流程。
那么这这个方法也是一种普适的方法，就是普遍适用的这样子的一种方法。
所以说刚才咱们讲过讲的这个主要目的是需求分析阶段的主要目的。
那么换另外一个阶段，它的目的可能又不一样了。
那么这么说呢，大家觉得这个东西的比较方法，那我们这个方法啊具体的来看一看去。
需求分析阶段如何使用问题挖掘法。
那大家看我们前面通过逐字逐句审读法，还有业务走查法等方法，我们已经得到了这样子的一些业务功能。那我们前面讲的这每一个椭圆其实都可以视作一个功能。虽然他们最后能够连起来做一个完整的业务流出现，但是每一个功能是不是也是独立的，算一个比较小的功能点。那对于这个功能点，我们要怎么样才算是准确全面深入的理解了。那肯定不是说这理解到填写预约下架单，就是要把这个功能点理解了。
那我们怎么能做到呢？
就要利用我们刚才讲的业务挖掘法，那我们怎么来挖掘呢？
当然这个具体的业务啊，大家看一下是不是还是咱们前面的这个业务，我就抄过来的，没有去改它。
我们现在呢就来说一下。
问题挖掘法该怎么去应用？
其实问题挖掘法大家很好理解，就是不断问问题，通过寻找问题的答案来逐渐加深对你这个功能点的理解。这个可以写一下吧，就是不断问问题。通过寻找。不可能。 问题的答案。来不断加深。对。业务功能点的。理解。最终呢。朝着。咱们前面说了准确。全面。深入到。理解每个。业务功能点。前进。是不是朝着这个方向前进呢？
好，这就是具体的这个方法。那么说一千道一万到底咋问嘛？比如说我这儿就有个填写预约下架单，这已经是个功能了。
那大家看一下，这儿呢就是给大家提个醒，就对一个功能点，那我们可以去问很多东西。
一般来说首先搞清楚功能点本身，就是谁来操作这个功能点，操作这个功能点的数据大概是什么？
这个功能点本身的功能是什么？先把自己的事儿大概捋清楚，完了过后就去想前置条件是啥？
要操作到这个功能，我有一些什么样的前置条件。这些考虑清楚了过后，这是前中后嘛，对不对？
然后操作中明白了，操作前明白了，那就考虑我这个功能操作完之后又会怎么办，或者说后续业务什么。你看。按照这些方式来思考同样的道理，那么你操作设计的数据也是这样。来源，自己怎么处理，去向都是这样。
三段式，前中后。把这些问题都问清楚了，基本上你这一个功能点也搞明白了，是这个道理吧？这就是问题挖掘法的一个应用。当然啊在不同的阶段，问题挖掘法他问的这个角度，问的这些问题可能会不一样。但咱们现在谈的是需求分析阶段。那你说在概要设计阶段或者是详细设计阶段，我去应用问题挖掘法，是不是还问这些呢？当然不是了，不同的阶段那你问的东西肯定不一样。但是在我们现在做需求分析的阶段，我们这些是最基本的要问清楚的。当然啊应该是包含但不限于这一点，大家对这儿只是做思路引导。包含但不限于。如下。这些角度。喂。问题的角度。那么如果这个功能点本身比较复杂，你可能还会接着这个功能自身又往下问。就比如说我这个功能点是一个产品信息描述，那我们可能就会接着自己来问自己，那我要是实物产品也用这个描述吗？
虚拟产品有这个描述吗？或者是未来我还增加一些其他的产品类型也用这个描述吗？比如说福利商品等等的这也算是问题挖掘法。当然这种呢就没有办法像这样统一的拿出一个大家可供参考的角度。
因为不同的业务可能你问的问题是不一样的。那我们先把这些大面的大家都能够想到，能够问到的这些功能先把它搞清楚，是不是你这个功能点也就理解差不多了。
实际上大家可以拿这些功能点，每一个都去做练习。回头你再看这个需求文档，那差的不是一点半点儿太多太多的内容在里面是没有描写的。另外大家看短短几句话，我们前面给大家讲了就有错误，有漏掉的，有不明确的。所以说大家可以体会得到啊，咱们去看前面的这些文档是给我们挖了多少的坑。那如果你作为一个合格的架构师的话，你就得把这些坑规避了，并且要想办法把这些坑填出来。
因为你只有把这些坑都填了，你才能够对这个业务完整的、全面的、准确的理解。
这对后续的架构设计，包括系统的落地开发实现都是有非常大的意义的。
所以说呢咱们前面也反复强调需求分析这个阶段非常的重要。
那咱们这里给大家讲的这些方法呢。大家也可以在这里啊去反复的练习。你随便找一个功能点，按照这些方式啊去思考一下，那么就能体会到了这些方法的妙处了好。
拿到一个功能点过后，我们先要去看它的功能点描述。当然这个功能点如果有准确的描述更好。
如果没有单独的这个描述，是我们从这个需求文档里面去挖掘出来的这样的功能点，那我们自己就要对它进行准确的描述。这就是咱们进行需求分析的过程当中，咱们自己要记录的写的一些东西。
也就是说对我分析出来的这些功能点要进行详尽的描述。
那么这个要求呢就是越具体越好，越准确越好。
比如说这个功能点不能太大，咱们前面也讲过，准确的含义最好呢是细化到不可分割的功能点，比方说增删改查是这样子的。如果说这个功能点还太大，很简单，咱们继续运用前面的方法，对这个功能点进行深入的理解和分解。直到把这个功能点细化到不可分割的功能点，然后我们就可以来进行功能点描述了。
那一般我们在实际工作当中呢，是做成这种啊功能点的卡片。注意啊不是大家在敏捷里玩的那个故事卡片啊，也不是在滴滴滴的玩的什么事件风暴法之类的。就我们这个呢就是针对每一个功能点有这样一些需要大家描述的事项。当你把这些事项都描述清楚了，那基本上这个功能点也就理解清楚了。
当然这里头要描述的第一个就是这个功能点的描述。那么大家可能会看到，咱们这个要求呢是非常具体的，可能跟大家在敏捷里面玩的什么故事卡片这些是不一样的。那个东西写的太笼统，为了快嘛，他是把前面分析的很多细节工作逐渐向后推，甚至一直推到开发人员拿到一个功能就给了他张卡片，然后他开始开发。他其实开发之前还是需要把这些问题搞清楚。只不过在敏捷里面，他把搞清楚一个功能点的细节的这个时间分成了很多段。你做需求分析的时候，可能有一个大致的故事卡片就完了。那么在每个迭代周期里面对他进行一定的细化。到了真正的开发人员手里，他拿着这个还得再去进行细化。也就是说拿这个故事卡片，其实他是没有办法开始干活的。也就是事情还是那个事情，要么你开始搞清楚，要么在这个过程当中分成很多段，一步一步去搞清楚。
总之在你真正动手开始干活之前，必须要把这些东西都要搞清楚，否则的话你没有办法干活。
所以说呢咱们现在讲的这方法，并不一定你非得在需求阶段一步到位。你把它放到什么阶段来做这些功能点分析都是可以的。不管你中间过程怎么去划分，但是最终你要把这些事儿都搞明白。所以说呢这就是我们说相当于最终的一个功能点分析的这么一个卡片。那这里面呢就有很多提示项，你要把这这些提示项都考虑清楚，这样就可以了。好，接着来看第二个。就是去描绘出操作人还有角色。
意思就是谁会来操作这个功能，谁能够操作这个功能。大家听清楚啊，一个是谁来操作，一个是谁能操作，这是不一样的。尤其谁能操作呢？这个东西它是带有一定的业务权限的，有可能是安全的要求，有可能是数据方面的要求。比如说我自己写的数据我才能改等等的。
比如说这个功能点是人工点击，比方说这是界面上的一个功能，那做完过后点按钮，这是一种触发方式。另外呢就是某个操作的连带功能，那这个功能你不用人工去参与，最典型的就是页面上的这种联动组件。当我选了a过后，或者a前的值过后，紧接着b就根据a的值来计算，或者说显示出一个新的值。比如说这个值，它是根据a的值连带来的。这也是一种触发方式，又或者是由系统定时触发。
比方说这是个定时功能等等的那你也要考虑清楚这个功能点是如何被触发的。第四节课我们要去分析这个功能点的执行周期。比如说是一次执行或者说是周期执行。当周期执行这种呢最主要的就是有这个定制功能。那要有周期的话，其实要进一步考虑周期是多长。另外呢是一直执行下去，还是达到某一个条件的时候它就不再执行了，那这些问题我们都要考虑清楚。
就是要满足什么条件才能够执行这个功能。比如说这个功能要求啊它的状态是已支付，或者说是已审核，或者是要求进行数据校验，当然肯定是要通过的校验等等的。这些就是执行我这个功能的前置条件有没有有哪些，这都是需要去思考的。第六的一个就要去思考我这个功能点所操作的数据的一些明细描述。比如说我这个功能点具体要操作哪些数据，当这个啊最好是分字段来描述它，又包含了下几个子问题，一起来看一下。
第一的一个呢就是数据的一些常见属性。因为你这个功能你要操作这些数据嘛，所以说呢要对这些数据进行一个准确的描述。比方说类型啊、长度啊，是否允许为空啊等等的那有些人一看说这好像是在做一些跟数据库设计相关的东西。没错，这儿啊就是要把相关的一些数据先分析出来，作为你后面进行数据库设计的依据。你数据库设计也不是凭空出来的呀，为什么要设计这几个字段呢？是业务需要啊，是这个道理吧？
再来看第二一个就是操作数据的来源。
就你这个功能点要操作这些数据，那这数据都从哪来呀？
比如说操作的数据是从界面来呀，还是从数据库来呀，还是某个模块获取啊。
或者说就是人工填写进来的呀，那总得有个来源吧。
第三的一个就是本功能对数据会做什么样的操作。比如说我这个功能执行完了会修改或者设置了某些字段的值啊。
那这些也要明确下来。
第四的一个就是操作产生的这些数据的一个去向。就我功能点不是操作了一些数据嘛，产生这些数据它的去向是什么？比如说我产生了什么数据，是新增的一条修改的一些数据还是怎么样？
那么产生的这些数据是否需要存储，如何存储？
存储到什么地方？是不是要把某些数据返回。
比方说我们在执行某些新增功能的时候，可能要求他把他的这个id返回出去等等的。
所以大家会发现，这就是对操作数据的来源，自己做什么操作，以及操作后的去向，就操作前、操作中和操作后都要分析清楚。
就这个啊当咱们刚开始如果是设计后台的时候，可以先不考虑。
但是一般来说呢在做需求调研的时候，咱们前面也讲了，就要求去画了原型，要求去画了一些展示的html等等的。
就这个具体的在界面上的表现形式，应该说都是跟客户已经确认过了的。
那么这个时候如果有的话，在跟咱们现在后台设计结合起来，这样数据就从表现到操作就都有了。
那这些呢是对咱们这个功能点涉及到的一些操作数据的思考和分析的方面。
比如说执行完本功能过后，会连带的处理什么功能？这个很多啊。
比如说大家去做了一个下单的功能，那下单完成过后它就会有很多后续的业务。
比如说给用户发放积分呢，比如说更新统计数据呢等等的吧。
那么这些就叫做连带的业务功能。
所以说我们对每一个功能点分析的时候，也要考虑清楚它会不会有连带的业务功能。
那么第八的一个就是连带操作需要的数据。
如果说前面判断是有连带的业务功能，那好了我就要考虑我要去操作连带功能。
那么连带功能需要什么数据？
我这儿有没有？
我该不该给他准备数据，准备的数据的格式是什么？
这些咱们在进行功能点分析的时候都要分析出来。
当然有一些人可能会说，像格式这些东西就留给开发人员自己去设计，那没有关系。
但是要传哪些数据，需要准备什么样的参数，这个东西你得有吧。
好，那差不多到这个地方把这方方面面都思考清楚了，基本上咱们一个功能点也就分析清楚了。
那前面咱们也提到过，就算是你不在需求分析这个阶段，一步到位把每个功能点都理解到这么细。
就算你也学敏捷，往后一步一步去递延这个过程，但是终归有一个节点。
必须在这个节点之前把这些事儿都要考虑清楚，否则开发人员没有办法去开发这些功能。
所以说开发人员那就是最后一关，最不济到了他那儿，他也得把这些东西考虑清楚。
所以说呢前面也建议大家把我们现在讲的这些东西做成功能点的卡片。
当然这里说的卡片并不一定是你真的做成一张一张的卡片。
其实呢你就是做成表格形式，让大家一个一个的填写。
那么一张卡片呢就写一个功能点，把这一个功能点在这里面填全了，填准确的那这个功能点呢就ok了。所以说呢这个东西既可以把它当成咱们需求分析的一个方法，也可以反过来作为咱们对一个功能点进行思考和分析的这么一个指南。当我拿到一个功能点不知道该怎么去思考的时候，最不介意按图索骥嘛。你就可以看这张卡片，卡片上要你填什么，那你就去思考什么，这样做下来也不会太差。
也就是说呢可以把这个方法当成是一个思考指南。
事实上咱们在进行需求分析的时候，最终整个业务系统的功能都会落实到一个一个的功能点，还有呢一个一个的业务流程。当然啊业务流程里面又包含着很多步，如果单纯从某一步来看，它其实也是一个功能点。所以说呢咱们先讲的功能点的分析，这节课呢来看一下业务流程的分析。
具体来看看咱们该如何进行业务流程的详细分析。
也就是说呢在业务流程分析的这个卡片，当然跟咱们前面功能点分析一样，也建议大家来做成这样子的分析的卡片。
其实就类似于去指导我们做业务流程分析，到底该分析些啥？
是不是照着这个卡片去填，差不多呢就能把整个业务流程分析下来。
所以说第一个呢就是对右流程的右背景，就类似于啊这个业务流程是哪个部门的，做什么事儿的提出来的这么一个业务流程。
那么这个业务流程呢主要干什么？
就是整体功能要进行一个详细的描述。
那这是第一步。
既然谈到业务流程，咱们必不可少的就是流程图。
当这个流程图严格意义上说呢，应该在需求调研的时候就应该画。
比如说需要去跟用户确认这个东西。
如果说在需求调研的时候没有画，那咱们现在就得按照需求调研的这个说明书啊，把这个业务流程给我画成业务流程图。
总之呢我们是通过阅读这个业务流程图来加深对业务的理解。
那第三个一步呢就是针对流程当中的每个节点来进行分析。
刚才也提到了，如果单纯的来看业务流程里面的每个节点，其实它都是一个一个的功能点。
所以说业务流程分析的大头到最后还是进行功能点的分析。
只不过呢这里的这个节点的功能和咱们前面讲的功能点呢又稍微有一点点不一样。
大家要注意一下，比如说节节点的功能可能会比较大。
那这个时候呢我们还需要继续细化，要把它细化到咱们前面所讲的一个一个准确的功能点，然后再进行功能点分析。
另外一种可能呢就是流程当中的这个节点呢，它本身代表的就是一个子流程。
那么这个时候我们需要进入到子流程里面去，然后呢再按照刚才讲的进行业务流程的分析的过程来进行相应的流程分析。
所以说呢流程当中的每个节点呢并不完全等同于咱们前面所讲的功能点，还是会有一点点差别的。
但不管怎么说，业务流程分析的大头就是对这每一个节点进行分析。
那接下来我们就来看看每一个节点该如何去进行分析，它又有它的方法和步骤。
先来看第一个，就是节点具体的功能描述。
当这里的一些方法或者说思路呢跟咱们前面讲功能点分析是非常类似的，大家可以结合起来思考。
第一个呢就是对节点本身的这个功能啊要进行具体描述。
实际上就是说这个节点到底要干什么，一二三四五啊就列出来。
因为咱们现在在需求分析阶段嘛，就是要搞清楚到底要做什么事，我们不关心怎么做。
那么理解了自己这个节点要干的事儿过后，那就到了第二步前置条件。
就说你要到这个节点，要来执行我这个节点的功能，它一定是有前置条件的。
因为在流程里面嘛，那这个时候呢要包括两个方面。
一个方面叫前置的逻辑要求。
比如说要执行我这个节点的业务功能，要求这个状态为已支付，这就是一种前置的逻辑要求。
如果你的状态不是已支付，对不起，我不会执行这个业务功能。
所以这一点啊跟咱们前面的这个单独的功能点分析，可能会略微有那么一点点不一样。
毕竟呢我现在这个节点是在一个流程里面，它是有前有后的，所以相互之间呢还是有一些约束的。
第二的一个呢就是前置的数据要求。
就比如说要执行我这个业务功能，要求你一定要具有哪些数据。
因为我接下来的这个功能操作就是要对这八个数据进行处理。
所以说你要想执行我的功能，你必须要有这些数据。
所以说这种可以看成是一种前置数据要求。
总之呢我们要去思考执行每个节点功能的前置条件到底有哪些。
那么通过了前置条件过后，就可以来执行自己的这个功能了，是这个道理吧？
然后我们接着往下看。
比如说我这个节点的功能是直接领导审核，那好，这很明显是一个角色。
这就意味着我要找到整个前面这个业务数据里头，比方说申请者是谁，再找到他的这个直接领导是谁。
这是参与我这个节点功能的的参与者，是这个道理吧。
那么还有呢可能这个参与者呢是一些条件，甚至我可能需要去外部获取能够参与我这个节点操作的这些参与者。
所以说咱们在行业业务流程分析的时候，就要分析出来能够参与我这个节点功能操作的。
都有哪一些参与者，或者是哪一些角色？
那么第四的一个呢，就是去考虑我这个节点所涉及到的操作页面。
因为有些时候啊咱们的业务功能呢要连带着页面来一起思考。
包括我们业务走查的时候，可能起点就是从页面的某一个按钮开始，从这个地方点击，然后一步一步去走查我的业务。
所以说呢我们分析每个节点的时候，如果它涉及到操作界面的话，咱们应该考虑一下操作界面是谁？
大概界面长什么样，大概上面都有些什么字段，显示成什么样子，会有什么样的功能。
等等的。
这个呢还是跟前面一样，就是数据来源呢自己操作些啥呀，以及数据去向啊这么几大块。
第一个呢当然就是考虑数据来源，这个就跟功能点分析理念是一样的，那我就多说。
第二个呢就是数据操作的一些权限。比如说啊有些是只读的，有些是能够改的等等。
第三呢，就是要考虑我的这个节点对这些数据到底要做什么样的操作。
就说有来源嘛，有操作。然后呢就是去讲这是咱们前面讲这个功能点分析这个套路就是这样子的。所以这里啊类似，那我就不去多讲了。
第四一个呢就要考虑数据操作过后的去向。这一块呢是针对操作数据的分析。
那这个分析清楚了过后，基本上这一个节点本身就差不太多了。你看自己的功能是啥有了前置条件是啥？有了就前置的逻辑，前置的数据这些都考虑了。参与者角色有了，操作界面有了，然后呢自己这个节点的功能，要操作的数据这些也都分析了。那接下来是不是该考虑我这个节点功能咨询完过后的一些事情呢？
那么第六的一个就是考虑我这个节点功能的连带功能。
就我做完过后，我的连带引起一些什么？比如说引起其他业务的变化。就像咱们前面举的例子，你下了一个单过后，可能引起统计数据上的一些变化，也可能会引起个人积分上的一些变化，这些就是带功能。又比如说呢我这个功能做完了过后，我可能要去发一些通知消息或者说是邮件等等的，这些也都要考虑一下，因为这是从功能上来做的要求。
那么第七的一个呢就是节点后续的转向控制。
那么当我这个节点自己的功能完成过后，那我何去何从呢？就要考虑我该往后怎么去转向了。
包括转向的逻辑条件，还有数据。就说根据业务逻辑或者业务流程图，我做完过后应该能往哪里转，这就看上面画了哪些转移。咱们讲过活动图，一个活动做完过后，是不是就要考虑它能够转向下一个的活动。当然可能呢这个活动做完过后有三个方向，那这个时候呢就涉及到转移的一些条件了。
可能满足a条件你去了a满足b条件你去了b满足c条件你可能去了c所以说呢这个时候我们就要考虑转的逻辑条件，还有呢转向的数据。因为判断总是需要一些业务数据做支撑的那这些东西咱们都要分析一下。一般来说呢把这些内容都分析清楚了，应该说一个业务流程也就分析的差不多了。
所以说呢我们也建议大家把这些内容做成业务流程分析的卡片，用来指导大家的。分析思考的工作。然后填写完这些卡片形成的这个记录，自然就是咱们需求分析的成果物所以说呢是一举多得的当这个具体的业务流程分析的实战呢，放到后面进行需求分析实战的时候一起来做。因为需求分析实战最重要的就是对功能点进行分析，对业务流程进行分析。所以说呢咱们这里就不单独安排演示了。
好，关于业务流程分析呢，咱们先讲到这个地方。
我们做事情的时候，基本上都会遵循从大到小，从粗到精，逐步细化这样一个过程来做。
当然啊咱们这个需求分析也不例外。
事实上需求分析的整体过程，我们可以把它总结为逐层推进，逐步去理解系统的业务边界、业务功能和业务流程。当然你一层一层往下推推到无路可走，推到没有下一个层次了，那么基本上你的需求分析也就可以结束了。比如说里面涉及的所有的业务功能块、业务功能点、业务流程你都理解清楚了。
那我们来看看这个图，这个图呢是咱们前面讲需求分析方法的时候，咱们讲到了要明确系统边界。
实际上你看在刚开始的时候，看到的就是一个特别高层的这样子的一个图。
这里面的每一个功能都是非常的大，是这样子的吧。
那么这个就可以认为是一层。
也就是说我站在用户的角度来看待这个系统。
那么这个时候呢我需要你这个系统给我提供用户管理、商品管理、订单管理等等的这些功能对我们来讲都太大了，根本没有办法落地去执行。
按照咱们前面讲需求分析要尽量准确全面深入的理解。
我们特别讲到一个功能块呢不能太大，因为这个东西肯定不准确，那我们需要逐层递进，就是往下去细化。
你看咱们前面画过这个，如果说把这一块用户管理当成一个新的系统的话，那这个时候它里面又包含它里头的一级的这些功能块。
那如果这个还太大怎么办？那就以它为系统接着往下去画，就画出下一个某某某子系统。
里面又包含一些功能块，就是采用这样的方式逐层推进去理解整个系统的右边界。
就每一层每一个系统都有它自己的业务边界，去理解整体的业务功能，还有里面所包含的业务流程。
那这整个呢就是需求分析的整体过程就是这样做的那把这个过程或者说是思想落实到需求分析的方法上来呢，那就是持续分解。
我们需要不断的去进行功能的分解，把一些复杂的较大的功能，你看这些是不是复杂的较大的。
比方说这些吧，很明显比较大，比较复杂。
咱们就对它进行一个持续的分解，分解为颗粒度较小的功能，直至不可再分，基本上分到了不可再分，基本上也就到了增删改查这样子的层级了。那这个方式就是咱们所说的持续分解。那这里大家注意持续分解不是抓着一个点就做深入性的分解，而是呢要跟需求分析的整体过程配合起来用。比如说是采用逐层推进的方式，啥意思呢？
就说在这个地方我并不是抓到一个点用户管理，然后呢我就把它一直往下去深入。
因为你用户管理往下可能有多个，对吧？
那这里头你要抓住第一个又接着往下，那这样子的话很多业务都孤立了。
因为在这一层它很多业务还有相关性，所以说呢咱的这个持续分解的应该配合着逐层推进的方式。
比如说我一层一层往前进。就是我到这一层好理解这一层面上能够有哪些功能，以及这些功能的关系能把这一层理解了。好，我再来挑一个开始往下去深入。
那深入的时候呢也是先看这一层有哪些功能，这些功能之间都什么关系。
而不是说啊我抓着一个功能就从头到尾把它一直分解到最小的颗粒度，不是这样子的。
所以说呢咱们是先广度再深度，逐层推进，这一点大家要注意一下。
那么在这个推进的过程当中呢，像咱们前面讲过的一些方法，比如说像什么业务走查法呢，问题挖掘法呢，这些都是可以用的。
就比如说前面这个你的业务走查法，在这么高层的模块上你也是可以用的呀。
比如说你从用户的角度又说我要到你网上购物，那然后呢我是你的一个用户。
我首先去浏览商品，那这个我就可以归结成是商品管理的功能。
回到这边，那大家会发现持续分解其实呢是咱们在需求分析当中不断在做的一件事情。你也可以把它理解成是咱们需求分析的一个落地的指导思想。就是要把这些大的复杂的功能逐步分解成为比较小的功能。然后以不可再分的功能点，然后咱们再用前面讲过的功能点的分析，业业务流程的分析去把它理解清楚。所以说呢既可以把它看成是一个方法。也可以看成是一个落地的指导思想。
一个呢叫可视化辅助，就是原型图。那另外一个呢就是业务流程梳理的辅助，就是画流程图。当然咱们这节课啊并不会教大家怎么样去画原型，怎么样去画流程图。主要是告诉大家这两个方法很重要，用来辅助我们做需求分析呢是非常好的手段。那我们先看第一个可视化辅助。
这个呢按照咱们前面讲需求调研的时候就提到，在需求调研的过程当中呢，就建议需求调研的人员去画出圆形图，或者说是用html等等去画出界面。实在不行你就拿白纸画一画界面的大概样子，去跟用户讨论，去跟用户确认。也就是说呢在需求分析的时候，正常情况下啊应该是已经拿到这些原型图。
也就是我们已经有了这些可视化的材料了，它能够辅助我们去进行这个需求分析。
那就一个字就是补到这儿啊，重要的事情多说几遍。当对原型呢我们不用拘泥于形式，不用飞流化成规规矩矩的圆形图，我们说了用html或者是用其他的图形化的展示工具来展示你的这个界面或者是原型都是可以的。关键的问题是需要把你的业务功能可视化的展示出来，这才是重点。
我们把这些功能可视化的展示出来有什么样的作用呢？一个就是加深对业务的理解。
那大家都知道当我们能够看到一个功能的对应界面的时候，我们就能够很容易的去理解这个功能。包括我们后面进行业务走查的时候，很多业务走查的功能它的起点就在界面上。
因为人工操作嘛，他要在这儿点按钮，那么就从这个地方开始向后去进行业务走查。所以说呢把功能里面能够可视化的部分都可视化的展示出来，对我们进行需求分析是一个非常好的辅助手段。
那咱们这里呢并不会去教大家画圆形图，这里呢只是让大家去认识到有这样子的辅助手段，把能够可视化的部分可视化出来，对于我们做需求分析是非常有帮助的。强调一下这个方式。
那再看第二个业务流程梳理的辅助。当大家一看就知道画流程图嘛，那正常情况下呢，流程图也应该在需求调研阶段都已经画的差不多了，但是呢难免会有遗漏的，所以说呢对于缺的话还是一样，那就是给我补。事实上啊在项目过程当中，我对于文档的要求也是零精勿烂。几乎所有做开发的人员都不是特别喜欢去长篇累牍的写文档。但是呢有一些必要的文档还是要有的，比如说原型流程图这种特别核心的文档，那还是应该有的。无论我们如何去敏捷，该有的东西必须要有，否则的话就会为了偷这点小榄而后面吃大亏。那流程图呢同样是能够让我们加深对业务的理解，因为你本身就是在展示整个业务流程嘛。另外呢也能够配合我们去做业务走查。事实上画流程图的过程就已经算是一个纸面上的逻辑上的业务的走查了。因为你画着画着就会发现，那这里不同意怎么走啊，你看业务功能上还没有呢。所以说呢你画的过程从某种意义上就已经是在做业务走查了。
当然后面你去应用业务走查法的时候，你也可以按照这个图来走查。
尤其是你做了一些设计过后，那我就可以按照这个图一步一步来检查你里面做的对不对，合不合理，有没有做漏掉的东西等等的。所以说呢流程图对我们来讲也是非常非常重要的。
咱们在做需求分析的时候看到的功能，要么就是跟业务功能相关的，要么就是跟业务功能无关的要求。那跟业务功能无关的这些要求，咱们就称之为非功能。非功能性的需求通常呢就包含两大类，一类呢就是质量要求，另外一类就是约束。
先看一下质量要求，它指的呢就是对软件的质量提出的要求。
比如说像性能啊、响应时间呢、可靠性、健壮性、可维护性等等的那这些统称为啊是质量要求。
所谓约束呢通常是对软件实现提出的一些约束和规约。
比方说要求你这个软件必须使用什么样的语言，必须使用什么样的版本，必须安装什么样的软件，必须支持什么样的环境等等的。
比如这个软件要求你必须使用java，必须使用1.8的版本。必须要使用mysql，必须要能够部署到云端环境，或者说必须要部署到linux的环境上。你看这些都叫做约束。所以说质量要求和约束啊是不一样的，大家注意区分一下。那么咱们在需求分析阶段呢，通过去审读前面需求调研的文档，应该能够很容易的去找到质量要求还有约束。
一般来说呢用户他的约束都是明确提出来写在文档里头。
而质量要求呢可能稍微麻烦一点，它有一些呢是明确的写出来了的，那还有一些呢它可能是隐含在功能的要求里面。
所以说我们在审读需求调研报告的时候，要注意去把这些质量要求呢抓出来。
那接下来呢，咱们就看一下在需求分析阶段常见的一些质量属性。
但对于软件的这个质量要求的要求是很多的。
在国标里面就是国家对每行每业啊都发布有一些行业标准。软件行业也不例外。那么在国标对软件行业的要求里面，他也提出了对软件系统的很多的质量的要求。那咱们这里并不去讲完整的这个质量属性，那个东西啊太多了，咱们讲一讲咱们在需求分析阶段经常能够碰到的一些质量属性。第一个呢就是易用性，所谓易用性呢就是指的软件系统易于被使用的程度。
它指的呢就是软件系统及时提供相应服务的能力。
那这个可能是大家在需求调研文档里面看到的最多的质量属性的要求。用户可能会要求你能够支撑的在线人数、并发人数，以及能够支撑的高峰的人数。要求你系统能够支撑的每日的pv uv，以及你系统能够处理的数据量的要求。另外呢就是对响应性的一些要求。
比方说常见的功能，它要求你一秒之内要能够返回到界面。
那么对于比较复杂的涉及统计的一些功能，可能它要求的三秒必须要能够响应完成等等的。
也就是说在需求调研的文档上，你会见到很多这样跟性能有关的一些指标。
那这些呢就是咱们要重视的一些质量属性。
所谓安全性呢指的是软件系统同时兼顾向合法用户提供服务，以及呢阻止非授权用户使用的这个能力。那用户呢在需求调研文档里面，一般会要求你要达到一个什么样的安全等级。尤其是涉及到支付啊，电商啊这样的系统。
他可能会明确告诉你，我们会请第三方的安全公司来对系统进行安全验收，要求你达到什么什么样能力，这些也是常见的质量属性。那么第四的一个呢就是可靠性。可靠性指的是软件系统在一定的时间之内无故障运行的能力。那用户可能会要求这个软件系统一年的可靠运行时间应该是百分之九十九点九九九九之类的。但一般来说啊要求到小数点后两位三位也就ok了。这个呢一般也会在这个需求调研文档里面明确的写出来。
可伸缩性指的是当用户数和数据量增加的时候，软件系统维持高服务质量的这个能力。听起来呢有点不太好理解，简单点说就是随着用户数还有数据量的增加，能不能够通过扩展机器就能够支撑住，而且呢性能不受影响。
这个呢需求调研的时候，用户一般也会明确提出来。只不过呢这个时候用户可能会给出一个上限值。比方说他会有个预估，未来的三年或者五年能够达到的一个用户数，能够达到的一个数据量大概会多大要求的系统呢要能够支撑这么多。那这几个呢就是咱们在需求分析阶段呢最常见到的几个质量属性。
咱们需求分析这个阶段形成一些什么样的成果物。
当然咱们这里啊只讲最重要的一些成果物。
第一个呢就是要形成功能点列表。
那啥是功能点列表呢？再想想咱们前面做需求分析的时候，已经分析出来了一个一个具体的功能。
就是说我这个大的功能的列表，然后又分分了多少个功能能这么持续分解表呢到不可再分。
那那我们是不是就形成了一个最终的功能点的列表。一般来说呢我们就会用excel把这个功能点呢都罗列在里面，这个呢就叫做功能点列表。这个我们是一定需要的，一个呢是能够整体的了解到这个功能的规模，得看功能点的多少，就有一个功能的列表。另外呢就是后面进行工作分配等等的，还有呢迭代划分，那么都会参考这个功能点列表。所以说这是第一个我们分析的成果物。
那么第二的一个呢，当然就是需求分析说明文档了当这个地方说明一下，并不一定是一份文档，也可以是多份文档。总之你做了需求分析过后，要写出一些文档来，那么会写哪些内容呢？
大家看一下，第一个就是功能点的详细描述。
那么这里面描述的内容呢，其实就是咱们前面讲功能点分析给大家建议的那些内容。
比如说功能点描述呢操作人呢、触发方式呢、执行周期啦等等的。也包括它里面操作的一些数据，什么数据来源呢？自己操作改了什么呢？数据的去向呢？把这些东西都详细的描述出来，那就是功能点的详细描述。实际上咱们前面也给大家建议了让大家做成卡片。
那么每一个功能点呢你就按照这个卡片去填。如果前面已经形成了这样子的文档，把这些功能卡片合到一起，就是咱们这儿说的。功能点的详细描述的文档。
但一般情况下到了文档里面，为了好区分呢，可能还会做一些编号。
你根据业务，根据模块大小，然后再编上号，那咱们这个呢就不去管它了，总之你的文档里头要把这些内容都包进来。第二的一大类呢就是业务流程的详细描述。
同样的道理，这个就是把咱们前面进行业务流程分析的那些内容都给我拿到文档里来。
如果前面已经一个流程一个流程的写了，也是建议大家做成卡片，那就是把这些东西合到一起就可以了。
所以说这个需求分析说明文档并不是要我们在需求分析结束过后重新来写，而是就是把咱们需求分析过程当中产生的这些内容聚合到一起形成文档，这样就可以了。
那么第三个一类呢，就是非功能质量要求和约束。那这个东西也需要形成文档。
因为这些内容对于我们后面的架构设计、概要设计、详细设计，甚至到开发部署运维都是有非常大的影响的。所以说也要把它拿出来。那这些呢也是咱们前面需求分析过程的产物。按照咱们的经验呢。
需求分析文档里面对后面有重大影响的就是这么三大块的内容。至于你是把它放到一个文档也好，还是形成三个大的文档也好，甚至把它拆分的更细。因为功能点太多了，我都一个模块出一个功能点的文档，这都可以。但是这些内容不能少，这是呢第二类大类成果物。那么第三个一大类呢就是交互界面。虽然前面咱们提到可视化的一些辅助，那么最低的要求呢是做出一些原型或者画一些原型图。
但是这里呢咱们进一步最理想的情况就是把所有的原型形成，最终的能够用于实际开发的交互界面。
比方说你做的就是h五，那么后面可能就直接用这个h五的页面，或者说你直接就已经是做成a p p的界面。
那后面开发呢只要去补功能就可以了。
所以说需求分析结束的时候，如果能够形成直接能够为后面开发所用的交互界面，这是最理想的。
最不济也得有相应的原型图，用来指导后面的架构设计以及呢开发。
那差不多呢这三个大项就是咱们需求分析最后形成的成果物，也是对后面的工作影响最大的三大块。
好，了解了需求分析最终成果之后呢。
我们再来看一下关于文档，关于这个事儿呢，我想讲两个点。
第一的一个点，对于文档应该更关注文档的内容。
因为对文档来讲主要就两块，一就是文档的格式，二就是文档的内容。
对于需求分析的文档格式呢来源很多。
比如说来自于cmm或者cmm 的要求，iso的要求，标的要求。
比如说来自于其他的这种软件的要求，比方说rup里面的要求。
也就是说呢你去写需求分析文档的时候可以有很多种的形式。
当然这个具体的呢就要看你所在公司的要求了。
另外呢很多公司并不是严格照搬这些标准的文档格式，它可能拿过来过后，会结合着公司的一些实际的需要进行一定的裁剪，形成了公司内部所要求的文档的格式，这都没有问题。
因为采用什么格式，这个东西只要拿到模板，咱们就可以照着这个格式去套就好了。
这个很简单，咱们更关注的是文档里面的内容。
因为这些内容对我后续的架构设计、概要设计、详细设计乃至开发都会产生极为重要的影响。
所以说我要的是这些内容。因此呢，我们在前面讲需求分析说明文档的时候，这儿提到有这么三大块。刚才也跟大家说了，至于采用什么样的形式我不关心。
但是这三大块的内容必须要有，而且呢要写的比较详细，比较准确。
因为我后面的架构设计、概要设计、详细设计，就整个设计阶段我们就会以这个文档作为依据。
如果你前面没有这些实际的内容，那么后面的工作就很难办了。
所以说呢这里要谈的第一点就是文档的形式或者格式，这个不重要。
但是文档的内容咱们一定要更加的关注。
那么第二的一个呢就是文档应该尽量少，但是该有的啊不能够省。其实呢我也特别赞同敏捷的一些方式，我们也实践过敏捷啊，极限编程啊很多的方法。那么我们也认同它尽量少写文档的理念。
事实上啊，所以说开发的人员没有几个愿意去写非常详细的文档的。
但是呢一些关键的核心的文档你是不能够省的。
你能审的就是一些可有可无，相对不那么重要，或者说里面套话废话连篇的那些东西，省的就省了。
但有一些文档，它里面放的就是直接影响你后续工作的那这些东西就不能够省。
比方说像咱们刚才提到需求分析说明文档里头功能点的描述，业务流程的描述，非功能质量要求和约束，这些东西能省吗？这些东西是不能省的，我不管你用什么形式，你都要把这些东西给我记录下来。是这个道理吧，所以说呢文档咱们都是希望尽量少，但是该有的千万不要省，这一点呢大家要注意。