Java架构师必备基本功需求调研和分析

---

想学习架构师构建流程请跳转：Java架构师系统架构设计

1 导学

从零开始去剖析订单系统的业务，带领大家系统学习需求分析的方法，并结合项目进行实战，从零开始去透彻剖析订单系统的业务。首先我们会去学习需求分析的基础，也就是需求调研，然后来系统学习需求分析指导，明确在需求分析阶段我们该做什么，以及该如何去做。

2 需求调研

架构师啊真正发力应该是从需求分析开始发力，为什么我们要先聊聊需求调研呢？原因就在于需求调研的成果物就是需求分析的输入。也就是说呢我们只有大致先明白需求调研的过程，以及它会产出些什么。那么咱们再聊需求分析才知道从哪里开始往后去做。这是先要聊一聊需求调研的第一个原因。第二个原因呢是需求调研这个过程是无比无比的重要。不管我们是项目型的还是产品型的，它都是一个非常重要的环节。以我的经验来看，很多项目或者是产品最终失败，很大一部分根源就在于需求调研没有做好。做歪了，做偏了，甚至有一部分是错误的信息。

那你在一个错误的信息的基础之上去做了很多的工作，他照样还是错的，并不能满足用户的真正的需求。所以说呢需求调研做的不好，会导致项目或者是产品失败。也就是说这个阶段是非常重要的。因此呢我们还是要来聊一聊这个需求调研。
当然啊由于咱们整个课程的这个安排呢是专注去讲架构师的架构设计实战，所以说这个过程呢我们只是去讲相关的一些理论或者方法，我们不会去安排实战，这一点呢大家要注意。

2.1 调研人员

那我们先来看一下，既然要去做需求调研，我们到底该派什么样的人去。当然咱们这里呢就先以项目型为主来聊，其实项目型和产品型差别并不是太大，只不过项目型呢是到客户那一方，而产品型呢可能是公司自己内部有产品团队。
但是对于架构师来讲，不管是真实的客户，还是内部的这个产品团队，其实都差不多对象的团队来讲，都是需要去调研这些需求的，都存在派什么样的人去做这件事情的问题。那在我看来呢，要派去做需求调研的人，大体上应该具备如下的一些特点或者是能力。首先呢要懂业务，这个大家很好理解。如果你派出去的人不懂业务，到了用户那边，用户讲什么你根本就听不懂，大家鸡同鸭讲聊不下去，这个是一个必备的能力。

2.1.1 头脑灵活访谈

因为在需求调研的过程当中啊，很大一部分形式都是跟用户在类似于做访谈，大家在交流。那么对于需求调研的人员呢，头脑要非常的灵活，在高速运转，他不断在捕捉用户说的这句话的意思，那这个里面包不包含功能点。如果包含功能点是一个什么样的功能点？这个功能点是大还是小我能不能够准确的理解这个功能点等等的。
所以说呢在做需求调研的时候，需求调研人员的这个脑袋啊是高速运转的。一旦他发现到这里头有需求点，而他呢又不是很明确的话，那么他就会通过问问题的方式，不断的来把这个问题问清楚。
在这个过程当中就会把用户的一些真实需求都要挖掘出来。
所以说头脑灵活是一个非常重要的能力。

2.1.2 懂技术人员

那可能有些人就会觉得奇怪了，说我派去做需求调研的人员，主要是去听用户讲他需要什么。我们只要能听懂就好了，为什么还要懂技术呢？其实这里头有个非常重要的过程，就是在跟用户沟通交流的过程当中，要去引导客户。那么在实现同样功能的。这个前提下可以有不同的实现方式。那么用户在讲需求的时候，他可能呢也是参考了很多同类的这个场景，再加上他自己的思考，形成了他的一个需求。他会要求你做什么做什么。

但是对于懂技术的需求人员，一听这个会有问题，照这样做可能工作量会非常的大。那么在同样实现用户真实的意图或者真实的需求的前提下，懂技术的这个需求人员呢就应该去引导他的这个思维，要去告诉用户你这样做呢是可以的，但是这样做呢，可能会有什么什么什么样的问题。那我建议你采用另外一个方案，比方说换一种做法，那么同样能够达成你的目标，但是他可能就没有这些问题。也就是说这个技术储备是用在这种引导客户的过程当中使用的。
所以说呢最好是懂技术。当然啊可能有些人说我们公司派出去的这些业务调研人员或者说产品人员。对技术了解的都非常的少。那这就说明啊派出去的人的能力上是有所欠缺的，并不是说你派出去的这个就是合理的。
当然呢这个时候有可能不是派了一个人嘛，也有可能派的是一个团队。
那有些人业务很好，有些人懂一些技术，那大家可以配合起来做，这也是没有问题的。

2.1.3 擅长沟通人员

那这里呢要强调擅长沟通，不是说你去了过后滔滔不绝的讲，结果变成你讲用户听，那就完蛋了，主要还是要去听用户讲他的真实的需求。那擅长沟通呢就是能够很好的倾听到用户真实的意图。并且在用户讲着讲着，他可能有些地方他很熟，那么他不讲了，跳过了或者讲不下去的地方，那么擅长沟通的人呢就会很合理的去电个话，提个问等等的。
采用一定的方式让用户又能滔滔不绝的往下去讲，是指的这。方面的能力。

2.1.4 业务经验多

其实业务经验多跟刚才懂技术是有异曲同工之妙的。因为类似的业务我做过很多了。那一听用户这个业务的要求，根据经验我就知道这个东西是很复杂，还是相对比较简单。那么是真实有效的需求，还是说只是看上去很美。
所以说根据业务经验就可以跟用户去交流，去引导，告诉用户我们这么做可能会更好，那么最终跟用户达成一个一致。
这也意味着在需求调研的过程当中，虽然是以用户为主，但也不是用户说什么就是什么。派出去的是调研人员，不是记录员。如果只是去做一个记录员的话，这样的系统后面是很难做下去的。

2.1.5 情商要高

因为去跟客户交流，你可能会跟客户不同部门、不同角色、不同岗位、不同职级的人去沟通。每个人的说话方式关注点又是不一样的。那么需要呢咱们的调研人员能够有很好的情商去跟各种不同风格的人进行交流。派出去的人最好情商要比较高等等的吧。总之大家会发现真正派去需求调研的人员，其实综合能力要求还是蛮高的。而很多公司呢为了节约成本，就派一些相对比较普通，经验比较少的一些人觉得去跟用户调研嘛，就是用户说嘛，大部分用户说然后他寄回来，然后就可以了。
实际上这样做为整个项目后续的开发工作埋下了巨大的祸根。比如说你有些需求点漏了，那后面就得不断的来弥补。
因为你每次给用户一看缺这个缺那个，这个时候你才知道用户还有这么一堆需求，所以说呢你的整个周期就会不断的拉长，件也会经过一遍一遍的修改变得糟糕起来，这是一种非常常见的问题，就漏需求。另外一个就是理解错了或者是理解偏了。
那么后面的所有工作都是基于这个需求调研的结果来的。
那么大家都自认为这个东西是对的，朝着这个方向努力，花了很多的人力物力财力的成本，结果发现路子不对，走歪了、走偏了，理解错了，又是一通返工。经过这种反反复复的折腾，到最后用户不满意，公司不满意，项目团队人员也不满意，祸根就在需求调研没有做好。这个呢咱就不多说，总之呢大家体会到需求调研是非常非常重要的一个环节。

2.2 需求调研的目标

需求调研就是要尽可能多的去挖掘出用户的真实需求。那么这里面有几个关键词，第一个是挖掘，比如说需求调研，当然你能够得到的一部分需求。是用户自己认为他能表达出来的。但是如果以客观的用户的真实需求是一百分来看的话，用户能够很主动的清晰的把他的需求表达出来的不会超过百分之七十。一般来说有个百分之五六十就已经很不错了。所以说呢需要需求调研人员不断去挖掘，这是第一个关键词。

2.2.1 真实和尽可能的多需求

也就说这个过程当中，需求调研人员不能越俎代庖，把自己想象的一些需求就认为是用户的真实需求，这一点也是要注意的。
用户的需求一百分，基本上你是不可能把这一百分拿到手的。一般来说你能挖到百分之八十九十就已经很不错了。
所以说呢是尽可能多的去挖掘用户的真实需求。
这个啊就是需求调研的目标。好，知道需求调研派什么样的人去了也知道要做些什么样的事儿，也知道需要达成什么样的目标呢。那接下来呢我们就来看一下需求调研的方法。当咱们这里给大家讲的方法，都是咱们经过实践检验的行之有效的一些方法，并不是那种高大上的理论型的这种方法论。

2.2.2 调研之前我们该做些什么

一般来说啊如果这项目比较大去调研之前呢肯定要做一些功课。常见的方法啊就找相关的一些系统的资料，或者是找同类的产品，或者是找用户建议你看的一些参考的系统。那么通过了解这些类似的产品或者是项目，来预判咱们未来要做的这个系统大概会有哪些功能。也就是说做功课的阶段。就要去研究这些系统或者是软件产品，把相应的一些功能给我整合出来记录下来。
这有可能就是未来咱们要实现的一部分功能之一。那么在这个做功课的过程当中呢，有一些是能理解的，有一些是不太理解的。那么就把你碰到的思考到的一些疑问都要记录下来。像我们一般建议呢就是用一张白纸a四的白纸，在一张白纸上下写两个，就说开头写一个问题，中间写一个问题，然后呢上下都空白，那就留着到了用户那边，跟用户再去沟通交流的时候来确认。

总之呢你在去用户那边调研之前，你要先做足了功课，相当于是有一些准备的东西。
那么第二的一个呢就是假想系统，这个方法呢就是说你不是已经研究了很多参考的项目或者同类的软件产品嘛，那么你就假想如果你是用户的话。那么你希望这个系统是什么样的，或者是你希望得到一个什么样的系统。
也就是在需求调研人员的头脑里面，首先呢有自己的一套假想的系统。那这个有什么用呢？
它有两个作用，第一的一个在跟用户沟通交流的过程当中，能够更好的去理解用户讲的东西。

因为你脑袋里是有一个系统体系的，那么你就可以来进行相互印证，这是一个重要作用。那么第二的一个重要作用呢，就是引导客户就在讲到某个功能的时候，可能用户要求是abc这样子的。你做功课的时候，你已经发现类似的功能，那大家可能都是做成bcd那个样子。那你可以把它拿出来跟用户去讨论，说你们行业之内，我们见到其他的系统大概是这样这样这样子的，可以跟客户去商讨哪一种方式会更合适。所以说在调研之前我们要做足功课，要构建好自己的假想系统。当然啊这个一般来说是对比较大的，比较重要的系统在这么去做。因为这个还是比较花时间的。一般的小系统说实话不需要这么干，有一定的这个工作经验应该就能应对了。那这个呢是调研之前要做的那调研的过程当中该做一些什么事儿啊？
第一的一个当然就是认真听、认真记和认真想需求。调研的主题就是客户，那客户方的人员在给你讲他们的业务的时候啊，咱们肯定是要认真去听，然后记录他所讲的一些东西。那这里重要的一点要强调的就是头脑要灵活。
用户在讲某一个功能的时候，他会理所当然的认为你知道相关的一些知识或者相关的一些功能。

但实际上呢咱们作为软件行的人，不是他们行业内的人，可能很多东西我们其实是不明白的那这个时候我们要敏锐的去捕捉到用户讲的这里头哎有什么样的功能。这个功能还需要一些什么样的功能支撑，或者是它会影响到一些什么样的功能。
这个功能太大了，那我能够把它分解成多少个小功能。所以说我需要去仔细思考，然后跟用户去提问题，跟用户去确认。所以说呢这个想是非常重要的。如果只是去听和记，基本上就是个记录员。那最终用户表达了百分之五六十，可能你也就寄回来了。百分之五六十就会漏掉很多重要的功能，那这个呢是第一个。第二的一个方法呢，就是不断的去问问题。
问问题主要有两个目的，一个就是确认疑问。刚才不是说要认真思考去想嘛，那么想的过程当中肯定有不明白的地方。
那这个时候呢就要不断的通过问问题的方式去跟用户确认到底是怎么一回事，这是一个。那另外一个呢就是向下挖掘一种啊是非常重要的。这个问题太大了，用户啊他说的太笼统了。那我需要向下去挖掘，到底在这个笼统的这个功能背后有多少细节的功能。那我可以通过问问题的方式去向下挖掘。另外呢还有一类问题的来源，就是咱们做功课的时候，不是去参考了很多其他的系统嘛？有一些我们不太理解的，不是已经记录了一些疑问吗？
那这个时候我们就应该把相关的问题拿出来，跟用户去疑问问题的方式来确认这些疑问。
但在这个过程当中，同样要不断去思考。
通常一个问题只是开头，然后用户在回答的过程当中，你又能够找到新的问题，就这样不断的往下去追问，这就是问问题的方式。

2.2.3 尽量要可视化

这个方法很多啊，你可以画草图，比如说画一些余额毛图啊、线框图啊、流程图啊，甚至画一些界面啊等等的当这个画图的方式可以在纸上，也可以在白板上等等的。

可视化能够大大的提升跟用户交流的这个效率，而且呢很多东西能够尽快的明确下来。那么第四的一个呢，就是尽量把用户讲的这些东西画成圆形，也就是要圆形化，而且呢要确认一般来说呢我们是建议啊去需求调研的时候，当天就能够把今天收集到的这些需求，以html或者是圆形图的方式给它画出来。然后在第二天跟用户去沟通的时候，就能够对这些东西进行确认。
因为确认的过程当中肯定有理解偏差的或者是漏掉的一些东西，那么就可以及时的。去弥补或者修改这些东西。因为对用户来讲也是这样，他看到一个东西过后，那么他的很多需求才会冒出来。你光是这样语言的口头上的交流，他可能说着说着很多东西都忘掉了，他也没有说出来，没有表达出来。所以说呢咱们要可视化。另外呢一定要做成原型并且进行确认。

2.2.4 多要资料

实际上咱们去做的业务系统，从本质上来讲，只是去辅助用户完成他的日常的业务活动，并不是说他没有这些业务，他这个业务没有软件系统，或者是没有咱们做的软件系统。
人家照常展开，人家业务跑得很好。咱咱们的软件就是去在线这个过程，或者是说在某些程程去辅助用户能够更快更好的完成的业务。所以说呢咱们在需求调研的时候，一定要去多要一些资料。
比方说这个过程。要发出一个什么发货单好了，发货单什么样子？有纸质的拿纸质的，有电子版的拿电子版的这都是非常重要的资料。因为上面就有他们的业务所涉及到的一些业务的字段，甚至上面可能还有审批啊等等的签字的位置。
那么这些对于后面转化成为实际的业务，还有理解这个业务都是非常有帮助的。所以说呢调研当中咱们要注意这一点，可能很多人呢会忽略这个。好，那调研的过程当中呢，还有很多其他的方法，咱们就不去讲了。咱们先就讲这么一些，再来看看调研之后，那调研完了过后呢，肯定是要形成文档的。一般来说呢会有需求调研的说明书，然后呢会有相应的原型，或者说相应的这个html的这个页面。那么根据项目大小呢，可能会去构建业务蓝图，还有呢业务架构图。一般来说业务蓝图呢是给用户做的一个中长期的规划。而业务架构图呢是咱们这一次要真正落地要完成的一些事情，这两个是不一样的。
那后面呢就是得到一些实物资料等等的东西。一般来说呢调研之后形成的这些文档是需要去跟用户签字的，包括你的调研说明书啦、原型啊、蓝图啦，还有业务架构图啊等等的。因为最终验收的话，这些都是非常重要的依据。
那这个呢是老公管理上的事情，咱们就不去多说。

总之呢现在大家记住，我们已经得到了需求调研的说明书，已经拿到了原型，已经有了业务架构图，还有很多相应的实物的资料。那有关需求调研的成果物就作为咱们下一个阶段进行需求分析的输入。

3 需求分析要做什么

首先大家要理解需求分析是架构师开始做架构设计的第一步，对架构师来讲非常非常的重要。因为需求分析能够告诉我们到底我们要做什么，那我们的架构设计就是为了去完成这件事情而做的。那么接下来呢我们就从实战的角度来讲一讲需求分析的一些方法。都是咱们多年经验的总结。也许啊听上去或者说大家看上去没有那么高大上，但是呢是非常实用的知识。
从几十万的小项目到数千万的大项目，都可以用得上这些方法。那我们首先来看第一个需求分析，这个阶段它的目标是什么？咱们前面也反复给大家，咱们要做一件事情，首先要紧盯目标，这样你才能够找到自己前进的方向。
然后再盯脚下的路，找到具体做事的方法，一步一步认认真真去做，最终达到这个目标。

3.1 需求分析目标

大家看一下是尽可能准确全面深入的理解业务。那前面呢我们也聊了一下需求调研，大家还记得那句话吧，叫做尽可能多的挖掘用户的真实需求。你看这两句话是不是很像？那我们来仔细的理解一下这句话。
首先呢需求分析要做的事儿肯定是去理解业务，但是要达到什么样的程度才算是我们理解的这个业务呢？首先第一个尽可能到这来写一下啊。尽可能的意思呢就是你不太可能啊百分之百的完整的准确的去理解，就你做不到。那么我们只能说是尽自己最大努力去理解，就是说这个东西不可能做到。百分之百。因为理解性的东西，你不可能做到百分之百的理解性业务。那么第二个是准确，这个是这里头特别重要的关键词。准确的含义就是对每个功能点的理解要没有歧义，理解的这个功能点要不可再分。

3.1.1 没有歧义且不可再分

也就是说如果对一个功能点不同的人呢有不同的理解，那这就是有歧义。但是如果单纯只有文档，这个就是有歧义的，再往后看且不可再分，意思就是这个功能呢不能太大，不能说这个功能点还能够裂变成很多小功能点。如果他还能够裂变成很多小功能点的话，那这个功能点的理解是不够准确的。比如说他在文档当中来这么一句话，要求能够对日志进行管理。这个我也写一下，上面这个是奇异的例子。下面呢是不可再分的例子。

或者叫可再分的例子。你看啊文档上要求对日志进行管理。其实咱们最怕看到这种话。进行管理咋管？
有些什么样的功能？是只是对日志做一个保存，然后取出来进行查看之外，还有没有其他的真正管理性的功能。比如说审计，比如说对日志的一些数据分析。那你这个管理两个字大家看一下，我把它标红一下。这个选择为标红一下，你看这都是出问题的地方。你这一个管理它就可以再往下分出很多具体的功能。比如说我要把日志存储起来，那这些存储其实还涉及到我要存储多长时间的日志。我如何存储是集中式的存储分布式的存储。然后我对这些存储的日志，我有没有什么其他的功能要求。比如说查看，比如说审计，比如说进行数据分析。而数据分析我要分析哪些东西，那这些东西都属管理的内容。
那么你光给我一个要求，对日志进行管理，就这么一句话，你让架构师怎么设计，你让程序员怎么开发？
对的吧？这些呢就是不准确，大家能理解。听到这个地方可能很多人就会在想啊，咱们那自己的需求文档里头看过太多这样子的坑呢，往往是一两句话就一笔带过了，好大一个功能块。那么做着做着就发现问题了，最后为了去填坑，耗费出上月的人力和时间，这都是可能的。咱们没少吃这样子的亏。所以说呢咱们现在就要求对于需求分析来说啊，一定要尽可能准确的去理解。

3.1.2 全面

全面这个呢比较容易理解，就是说你所有的这个功能点啊，业务流程啊等等的，你都应该分析到，你不要漏东西，这个咱就不多讲了。再看后面一个叫做深入，那这个深入呢有两层含义。两层。含义。一个。就是对自己功能点的一个深入。
那么另一个呢。这样我把它挪到下面来。中间好举例子。另一个呢就是功能点之间的。深入理解。当时他们之间的关系啊。那么大概有这么两层含义。举个例来说。对自己功能点的深入。比方说这个咱们来个例子吧。需求文档这么写的，这个价格可以修改。被你修改。或者说被价格管理员修改，说的很清楚，对吧？它的价格。管理人员。修改。修改后。要进行审核。才能生效。大家可能需求文档里看到这样的语句，觉得说写的还算比较清楚啊。但是你仔细往下去分析，这个时候就有问题了。
你看啊价格可以被价格管理人修改，这句话应该说是没啥太大的问题，但是修改过后要进行审核才能生效，问题就来了。那你就想既然是审核，谁来审核？审核有没有流程？
审核有没有流程，是回到价格管理人员还是直接生效等等的那大家一听就知道这中间是有问题的了。那有人可能会说，这好像是对审核功能理解不准确。哎，不是。一般来说啊我们说最终的功能点，你看无外乎就增删改查审嘛，这些都算是相对比较单一的一些功能点了。那这里呢强调的是深入，它有可能并没有流程。但是我们深入一想要进行审核才能生效。
那么这个时候我们就要更加明确，比方说谁来审，如何审？它的审核结果对业务有什么影响，有没有审核流程等等的那我们就一定要把这些问题都要考虑清楚，这才是需求分析真正要做的。不是叫你表面上把拿到的这些需求文档啊读一遍，不是这样子的。你读完了觉得说这些字儿我都看懂了，然后大概意思我也就明白了。这样子的需求分析是不到位的，一定要像这样子一点一点的准确的、全面的、深入的去理解才行。因为在这个过程当中，你会发现很多不明确的地方。
而这些东西现在如果不把它找出来，那这些问题就往后推演，就遗留到开发期间。也就是这些问题，你在真正具体落地之前，开发之前一定要搞明白。否则你光写这句话，程序人员根本没有办法去做到。
所以说呢咱们越早分析清楚越好。因为呢这中间可能很多功能，那么需要我们在做架构设计，做概要设计、详细设计的过程当中，就需要把它考虑进去。而不是说把这个任务啊一直推到程序人员开发的时候。
因此呢架构师在做需求分析的时候，一定要分析的特别的仔细。再来看另外一个另外一个点呢是功能点之间的一些关系的深入理解。也就是说可能在这个文档里面并没有提到a功能和b功能之间有什么样的联系。但是经过我们的深入分析发现呢，他们之间是有联系的了。比如说我们也可以看个简单的例子，就来个大家最常见的请假的功能吧。当然请假是有业务流程的，但是我们这儿假设说把它开发成了一个单一的功能，就叫做短时间请假。比方说我有一个叫短时请假的功能。
那么这个功能呢，是要求请假人。填写。请假单。这是为了所谓的管理扁平化，反正由请假人去填写一个请假单，然后呢就直接由他的直接领导。三号。那么他的直接领导批准了，那这个请假就通过了。请假。成功了或者通过了。
你看啊看起来很简单，就是你前一张请假单，然后由直接领导审核，同意了就同意了不同意的也就不允许我请假了，就这么简单。但是这个功能你看你仔细来分析又有几个点。第一个短时请假啊，这个实际上是对自己功能点的一个深入理解。你看你短时，请问啥叫短时？一天两天、三天还是几个小时？这就意味着为了做短时请假，那么我们需要有一个配置。
那好，你看我这个时候就要想，我整个系统里面有没有这样子的配置的功能，能够去控制。
什么是短时请假，什么是长时间的请假，是这个道理吧。
那么可能由于我这儿的分析就引申出新的功能点来了，也可以算是一个功能点之间的关系。
第二再看这句话，由他的直接领导。什么叫他的直接领导？那有人说直接领导不就是他所在的一个部门的领导吧。那不一定。如果他的部门比较大，他可能是在某一个项目组里面。那项目组长或者听leader算不算他的直接领导，你看这都是问题啊。
所以说呢这又引申出来一个，从这个公司的员工管理里面，因为员工管理的时候一般都会有部门呢这样子的成绩结构。
然后把这些人员安排到每个部门每个岗位上去，对吧？
那么我们就要求这边要具有一个功能，就是能够设置每个人的直接领导，或者是能够取到每个人的直接领导，你看这就涉及到鼬有一套直接领导的这么一套设置的功能，另外呢，就是要求组织机构和人员这边要提供这样的功能，但这是功能点之间的个关系，是这个道理吧？如果那边不提供这个功能，请问我怎么判断谁是他的直接领导呢？
这个就叫做深入理解。所以大家看一下啊。需求分析真正要做好不是那么简单的，是需要大家花很多力气去认真仔细反复深入的思考的。总之呢大家需要理解需求分析的目标，就是尽可能准确全面深入的去理解业务。
就算咱不能百分之百做到，想要尽可能朝这个目标去努力。
当然呢理解业务其实主要就是两个大方面，一个就是理解每一个业务功能点。
另外一个就是去理清每一个业务流程，但业务流程又分很多部分啊，实际上就是把整个流程咱们要搞清楚，还有流程当中每一步都要搞清楚。但具体的怎么去理解每一个业务功能点，怎么去理清每一个业务流程，具体的方法是什么？
咱们后面再讲。我们后面不但要给大家讲方法，我们还要去实战。就真正的拿出业务流程，拿出业务功能来，咱们一起来做需求分析，看看能分析出什么样子的东西。

3.1.3 识别重难点业务

这个呢可能要求架构师有一定的业务经验，当然这个也算是架构师的一个基本功。
拿到需求过后，架构师呢要能够快速的识别出里面的一些重难点的业务，业务经验就能够告诉我们要做这样子的业务，里面有哪些功能是非常重要的，有哪些业务可能是比较难做的。
也就是咱们俗称的重难点的业务。那么识别出重难点业务有什么样的作用呢？
就是我们接下来再对他们进行分析设计的时候，我们可能就要重点去考虑这些重点业务、难点业务的实现。
如果能够把重难点的业务都解决了，一般来说啊这些常规的相对普通一些的业务功能，咱们的架构设计呢是能够很好的去满足的。因此呢这些重难点业务很可能会影响到咱们后面的，包括像技术选型啊，具体的架构设计啊，包括咱们的架构形式，它可能都会受到它的影响。毕竟呢软件啊只是一个工具，这个稍微给大家说一下。
这是一些很基本的思想。软件只是一个工具。那大家一听工具嘛，它不就是用来干活的嘛，那软件是用来干嘛的呢？
主要就是用来。帮助实现业务活动的这样子的工具。
当然是帮助用户啊或者客户来实现业务活动的工具。
那我们的架构设计是在干什么呢？架构设计是为了把软件做好。
当然也可以说他是为了软件服务的。是。跪了，怎么说吧？更好的。
开发和制作。软件这个工具。所以说我们要去识别重难点业务，因为软件只是工具嘛。
我就是来解决你这些业务问题的那我肯定首先盯的就是要解决你的重难点的业务。
这些解决了，那些普通业务我肯定能解决啊，是这个道理吧。
咱们的架构设计就是在考虑我怎么样能够把这个软件做好啊，因此呢对于重难点业务的把握呀，他可能就直接决定了架构设计的成败。因此啊，咱们一定要非常非常的重视。
当然这一点啊对于经验弱一些的架构师可能就是一个小小的问题了。因为刚开始呢他可能不能很快的去识别这些重难点的业务，但这个也没有关系，即使你刚开始没有识别出来，那你就尽量考虑的全面一些。
你比方说做完你的架构设计，那你在做验证的时候，你就多挑一些业务来验证你的这个架构设计，这样也能够避免出现一些问题。

3.1.3 识别非功能需求和质量约束

那啥叫非功能需求呢？就是除去了咱们的业务功能需求之外的，剩下的这些需求，咱们统称为非功能性需求。
通常呢也是软件质量约束的一部分。比如说啊我们对这个系统提出了一些要求，但是呢不是功能性的，我们可能说要求系统要达到什么什么样的性能，就性能方面的要求，可靠性方面的要求，可扩展性方面的要求，可维护性方面的要求。等等的。
当然了也还有其他的，比如说安全的要求，备份恢复的要求等等。
那么这些要求对于架构设计的影响是非常非常大，很多啊都是架构设计要重点考虑的一些问题。
比如说像性能问题、可靠性问题、高并发问题、海量数据的问题、可扩展的问题等等等等吧。那这些对咱们做架构设计都是有非常大的影响的。所以说呢咱们在做需求分析的时候，就要把这些识别出来。当常见的一些质量约束呢，我们在后面实战的时候会去给大家再讲一讲。
那这里呢咱们就不去啰嗦这个事情，有关于需求分析要做什么呢？我们就先讲这么多。
最后呢我们想要强调一点，就是需求分析对架构师而言是非常非常重要的。这个啊咱们到这边再强调一下。
就是需求分析。对于架构师而言。
非常。非常的重要。可以这么说，是。架构师做。
架构设计的起点。或者说是。其实。比如说这个事儿没有做好，你后面的全部都是在瞎做。所以说呢一定要把这件事情啊重视起来。因为呢需求分析会告诉我们到底要做什么。如果说您要做什么我们都不知道，这个问题都没有解决，让他想想谈什么架构设计。如果一片迷茫的情况下就去做所谓的架构设计，那请问这个架构设计为谁做的呢？做了干什么呢？
那么现在呢有一些所谓的架构师，他轻业务而重技术，成天高谈阔论很多新的技术，各种技术大词名词满天飞，为了技术而技术，但是他忘了架构设计的初心。刚才已经给大家讲了，架构设计的目的是为了软件服务的，是为了更好的去开发和制作软件这个工具，仅此而已，不是为了你去炫耀你的技术，你懂得多少个大词？这种做法是很不可取的。
可以毫不客气的说啊，这些人根本就算不上是真正的架构师。我们可以称之为是伪架构师，或者说是p p t架构师。
白话完了过后落不了地，因为落地必须跟业务结合，所以说有那么一句话，离开业务场景谈架构设计，那就是在耍流氓。
所以说呢大家一定要重视起来，业务很重要，需求分析很重要。

4 需求分析初步明确系统边界

初步确系统的边界。我们先回忆回忆咱们前面讲讲需求分析讲过的一些方法思路。那前面我们已经强调了啊，需求分析是架构分析的一个必备基本功。然后呢我们去讲了需求调研以及需求分析到底要做什么。那么重点呢是需求分析的这一个方法。前面咱们讲的，大家可以当成是需求调研人员，再给设计人员讲这些业务，相当于让大家初步去理解业务场景。这个呢咱们前面的
课程就是在做这个事儿。那么接下来呢我们就应该去明确系统边界。也就是说如果我们的这个系统简化到就是我们选取的这一个场景，就别的我都不做了，我们整个项目浓缩下来就只做这一个场景。那我们是不是也应该有一个明确的系统边界？那这一块呢单纯从咱们前面讲的这个业务流程上，是看不出来系统边界的。

因为我们前面讲过，所谓系统边界指的呢是看这个系统和其他外部系统之间的一个关系。那这个里头大家看好像没有涉及到外部的系统对吧,框子内的就是咱们的统一管理系统

这个图呢咱们就画到这个里头吧，就需求分析室上这个下头吧。咱们现在只是去画一个初步的这么一个系统边界图。随着咱们对业务的深入理解，还会进一步的来完善它。所以说我们先画一个，比方说这个框框就代表了我们现在要做的系统。
其实现在暂定的就是一个客户。正向。下单的业务流程。是这样子的吧。那好，那属于系统边界呢，你看这个黑线框就相当于是边界了嘛，那么框内的是我们内部要做的。框外的就是外部的系统。
所谓明确系统边界，就是明确我们这个系统和外部这些支撑系统之间的一个关系。

事实上呢对于整个项目来讲，它外部啊大概有大大小小的系统呢十几个，当然咱们这里呢不用去讲那么多，咱们讲几个呢意思一下，而且呢尽量跟咱们这个订单业务有关的外部系统。

4.1 SAP企业应用软件

要稍微写一下。那么他们的sap呢管理了他们内部的财务，还有生产制造，这些都在SAP里面。那么他和咱们要做的这个下单的业务是什么样的关系呢？这个我就先画一条线来表示它们之间有关系。在实际的这个下单业务要求里面，下完单过后，他是要推送订单给到SAP的。因为呢咱们的订单有信用支付，那么这些下单的细节必须要推送到SAP里面去，它的财务系统才能够道哪些订单是用的信用支付，哪些是现金支付。因为这个涉及到未来他和企业去对账的问题。
所以说呢咱们每一单呢都要推送到sap。这里面其实推SAP呢还有另外一个重要的原因。因为对SAP来讲是作为他的企业资源管理嘛，应该说是这家企业的大管家。那么在它里面一定要保证钱和物是匹配的。
而咱们现在做的这个订单呢，客户来下了单过后，大家注意他真正执行并不一定按照你下单来执行。这个呢也是to b业务的一个特色之处。就比如说客户向平台方去下了一个单说要买一万件a商品，然后付了一百万。
但是这个单子真正在执行的时候跟a半点关系都没有。用户他可能会告诉平台方说，你这个月给我发一万件b加三万件c只要他的这个钱没有超过这一百万，那么平台方就得按照用户的要求。随意的去更改这个单子，并且随意的去拆解这个单子。

4.2 ToB复杂的地方

就是没有规则没有规则。
这就意味着你的订单要能够灵活应对所有的情况，想怎么拆就怎么拆，想怎么合就怎么合。
所以说这个系统的订单部分实际上是非常非常复杂的。但是我们现在选取的这个业务场景呢，大大家看一下，刚好到下单就为止了，你看就是把单子下进来了。后续的处理咱们都不涉及，如果要涉及到后续的处理，咱们花的时间可能至少要翻倍。
根本讲不完这一点啊，大家要理解一下。所以说这种情况下，他就要求你的单子每一次的拆或者是合并都要再推一次i c p。
因为这才是真正的执行单SAP才知道最终发了哪些货，花了多少钱。
在它的体系里面才能够建立钱和物的对应关系。所以说呢这个地方它一定是和SAP有交互的这是一点。

4.3 WMS仓储管理的系统

那么大家都知道电商业务里面做的这个库存，实际上是个虚拟库存。
可以理解成是库存的一个记账，并没有做实物的库存管理。真正实物的库存管理是有专业的WMS在做，所以说呢这也是有关系的。你订单处理到后来你总在发货的吧。那么你的这个发货单的信息其实就给到相应的WMS系统。
然后呢，就会从相应的仓库去组织你这些货，然后安排运输。那后续的咱们就不管了，你看订单做完，然后发货就把这些东西扔给w m s去做了。那在这个里头呢，它还有一个系统是跟订单这边相关的。叫做比价系统。
这个是啥意思呢？咱们前面讲客户会跟平台方去签约，那么这个签约呢就会约定这些商品的价格。一般来说都会要求平台方供给这些客户的这个价格，不得高于其他平台给出来的价格。比方说京东也卖这个货，天猫也卖这个货。

那么客户在你平台方采购的同样的这个商品，比方说京东卖九块钱，天猫卖九块一毛钱，那你的平台你不能超过九块钱。你必须要保持是最低价。大概就这么个意思，这些他们都是要写入到合同里的，所以说他们就会有一个第三方的比价系统。
用来干什么呢？就是定期的进行价格的采集并进行比较。那么采集到同类的这个商品，这个外部平台的价格比他们内部定的这个价格低的话，在他们内部有一个业务就叫做价格违规。就说这个价格也要给到客户的话，客户可能是会投诉你的。
这个是可能会出问题的。所以说呢他们就会把这些价格高于其他平台的这些商品呢标识出来，然后呢进行人工的改价，人工的审核。以保证最终给到用户手里的这个价格呢，要比这个其他第三方平台的价格要低。

所以说这就是比价系统的作用。那这些啊都是典型的跟订单这儿相关的。因为这个比价系统呢对确定这个商品的销售价格是有很重要的作用的。那么在下单的过程当中，它比较浏览商品吧，它是不是要去看库存，要去看价格？
对的吧。所以说呢这些都是跟咱们现在选定的这个场景啊息息相关的一些第三方系统啊。咱们呢简单的先这么画一下，表示我们的系统会和SAP WMS还有比较系统有交互关系，也就是这里所说的初步明确这个系统边界。当然这个还比较粗略，那随我们对业务的进一步理解，后续呢还会对这个图啊进行进一步的细化。那咱们这里呢就先画这个样子就可以了。