需求分析实用方法之——明确系统边界（C系架构设计法，sishuok）

需求分析实用方法之——明确系统边界（C系架构设计法，sishuok）

前面，我们聊了需求分析要做什么。接下来，我们就来聊聊，需求分析到底该如何去做，也就是做需求分析的一些基本方法。这块的内容会比较多，我们分成几次来写。

先来看做需求分析的基本的思维方式：我们只考虑具体要实现什么，明确具体的展现形式。也就说，我们只考虑我们现在这个系统，到底要干些什么事，系统最终展现出来是什么样子；而不去考虑，到底这个功能该如何去实现，这是一个非常基本的思维方式。

要跟大家强调一下，因为架构师通常都是从开发人员这样一步一步升上来的，有些刚开始做架构的架构师，他的这个思维方式，还带着浓厚的开发人员的思维，他一看到功能需求，看到这些功能点，脑袋里面马上就想到的是，我该用什么样的开发技术，用什么样的代码去实现这样的功能。

也就是说，他会自觉不自觉的就在思考该怎么实现，就差把代码写出来了。所以，这里特别提醒，在做需求分析这个阶段，我们只是去考虑：要做什么，而不去考虑具体如何做，至于具体如何做的事情，是接下来咱们的架构设计，概要设计，详细设计等阶段要去考虑的。

所以开始讲需求分析如何做的时候，咱们就要强调一下这个基本的思维方式，接下来，我们就正式的进入到讲需求分析方法的这个过程里面。

一般来说，开始做需求分析，第一步就是要去理解业务，通常会先要求需求调研的人员来给我们讲一讲业务，前面也讲了，需求调研完了过，已经形成了需求调研的说明书，也形成了相应的业务蓝图、具体的业务架构图等，这些东西都已经有了，我们现在理解业务，就是要来理解这些文档里面的内容，所以通行的方式，就是先让需求调研的人员，来给架构团队，还有开发团队，先整体的讲一讲这个业务是什么，让大家对整个业务有一个整体的了解，去理解整个业务的背景，理解相应的一些业务场景。

粗略理解整体业务过后，就开始进入到一个一个具体的业务流程或者业务功能的讲解，需求调研人员在讲解的过程当中，架构师会不断去思考和理解这些业务，当然，咱们是要站在架构师的角度来看待这些业务，这个过程，就要朝着咱们前面讲的需求分析的目标去前进，就说我们要尽可能的准确、全面、深入的去理解这些业务。

在这个过程当中，要是有一些东西没有想明白或者没有理解，可以及时跟需求调研人员去沟通。这个时候，其实你可以把需求调研人员当成是用户，相当于在边听他讲边来做一次内部的需求调研，方式是一样的。当然，由于有了很多的内容，还有资料的准备，这个过程会比纯粹的需求调研要快得多。

理解了细节业务过后，咱们就会继续向前，开始来明确系统的边界。首先，我们要明确系统一级的大功能，也就是说我们现在不关心内部的一些细节，如果我们把整个系统当成是一个大的黑盒的话，我们明确一下它里面的一些一级的功能就可以了。

比如假设我们这个项目就是去做一个电商系统的话，这个时候，我们只需要明确，这是我们的一个大系统，它里面有哪些一级的功能，比方说有用户、产品、商品，还有订单、库存等等的。咱们这个系统，可能有这么一些大的功能，这个就叫明确一级的一些功能。一般来说，在初次理解这个系统的业务的时候，这些东西都要定下来。

再来看第二个，去梳理使用系统的角色，这个对于我们后续的分析设计是非常有帮助的，尤其是咱们有一个方法叫业务走查，就是要模拟这些使用系统的角色，来完成实际的业务，就按照实际的业务场景来走查这个功能对还是不对。所以，这个地方要把使用系统的角色都梳理出来。另外一个，梳理这些角色，也有助于我们去理解这些业务功能。

思考的方式就是，站在系统的角度来思考，谁会使用我这个系统；哪些人用这个系统来完成他的日常工作；谁来维护这个系统；谁来管理这个系统；谁会从这个系统里面去查看一些信息等等的。

在这里，我们也可以去画UML的用例图。就是一个高层的，这么一个功能的边界，通过画图，我们会发现，会有哪些角色来使用系统。

第三个，就是“梳理系统”，梳理要使用的其他系统或资源。这个也是非常重要的，很多人容易把它忽略。啥意思呢？就是说，如果我们这个系统要想跑起来，刚才不是已经确定了这个功能边界了吗？说明内部只有这些功能，但是为了让我们的系统能够正常运转起来，可能还需要很多支撑的东西，或者说需要一些外围的系统。这些也要在这个阶段明确的定下来。

比如说用户管理的一部分功能，可能要来自于已有的一个软件系统，用户已经在使用的老系统，比方说来自CRM，也就是说，我们的用户管理会去使用CRM的一部分功能，也就是用户管理需要CRM这个系统的支撑。

类似的，订单管理可能会涉及到库存的一些功能，库存呢，也是已经做好的一些专业的库存软件，可能订单会去使用这个库存系统，这个时候就一定要搞清楚，我们要做的系统的边界到底在哪里，哪些是我们要做的，哪些是我们不做的。当然，订单管理，可能还会涉及到像支付、财务等系统，一般来说，像电商系统很少会直接自己去管财务这些东西，一般都会跟后端的，比方说ERP，或者说财务系统去对接，比较大型一些的企业，基本上用的可能都是SAP这类的。这个时候，也需要把它标识出来，因为这个也涉及到未来的一个对接，就说你需要跟他结合上。

这些咱们在做这个初步的需求分析的时候，就要把他们明确下来，头脑里就很清楚的知道有哪些角色在使用我们的系统，我们的系统内部有哪些功能是我们需要做的，我们需要使用到外部哪些资源或者系统，这些系统是不需要我们做的，这样的话，未来我们的这个架构设计，需要考虑的边界就出来了。