需求分析实用方法之——明确系统边界(C系架构设计法,sishuok)
需求分析实用方法之——明确系统边界(C系架构设计法,sishuok)
前面,我们聊了需求分析要做什么。接下来,我们就来聊聊,需求分析到底该如何去做,也就是做需求分析的一些基本方法。这块的内容会比较多,我们分成几次来写。
先来看做需求分析的基本的思维方式:我们只考虑具体要实现什么,明确具体的展现形式。也就说,我们只考虑我们现在这个系统,到底要干些什么事,系统最终展现出来是什么样子;而不去考虑,到底这个功能该如何去实现,这是一个非常基本的思维方式。
要跟大家强调一下,因为架构师通常都是从开发人员这样一步一步升上来的,有些刚开始做架构的架构师,他的这个思维方式,还带着浓厚的开发人员的思维,他一看到功能需求,看到这些功能点,脑袋里面马上就想到的是,我该用什么样的开发技术,用什么样的代码去实现这样的功能。
也就是说,他会自觉不自觉的就在思考该怎么实现,就差把代码写出来了。所以,这里特别提醒,在做需求分析这个阶段,我们只是去考虑:要做什么,而不去考虑具体如何做,至于具体如何做的事情,是接下来咱们的架构设计,概要设计,详细设计等阶段要去考虑的。
所以开始讲需求分析如何做的时候,咱们就要强调一下这个基本的思维方式,接下来,我们就正式的进入到讲需求分析方法的这个过程里面。
一般来说,开始做需求分析,第一步就是要去理解业务,通常会先要求需求调研的人员来给我们讲一讲业务,前面也讲了,需求调研完了过,已经形成了需求调研的说明书,也形成了相应的业务蓝图、具体的业务架构图等,这些东西都已经有了,我们现在理解业务,就是要来理解这些文档里面的内容,所以通行的方式,就是先让需求调研的人员,来给架构团队,还有开发团队,先整体的讲一讲这个业务是什么,让大家对整个业务有一个整体的了解,去理解整个业务的背景,理解相应的一些业务场景。
粗略理解整体业务过后,就开始进入到一个一个具体的业务流程或者业务功能的讲解,需求调研人员在讲解的过程当中,架构师会不断去思考和理解这些业务,当然,咱们是要站在架构师的角度来看待这些业务,这个过程,就要朝着咱们前面讲的需求分析的目标去前进,就说我们要尽可能的准确、全面、深入的去理解这些业务。
在这个过程当中,要是有一些东西没有想明白或者没有理解,可以及时跟需求调研人员去沟通。这个时候,其实你可以把需求调研人员当成是用户,相当于在边听他讲边来做一次内部的需求调研,方式是一样的。当然,由于有了很多的内容,还有资料的准备,这个过程会比纯粹的需求调研要快得多。
理解了细节业务过后,咱们就会继续向前,开始来明确系统的边界。首先,我们要明确系统一级的大功能,也就是说我们现在不关心内部的一些细节,如果我们把整个系统当成是一个大的黑盒的话,我们明确一下它里面的一些一级的功能就可以了。
比如假设我们这个项目就是去做一个电商系统的话,这个时候,我们只需要明确,这是我们的一个大系统,它里面有哪些一级的功能,比方说有用户、产品、商品,还有订单、库存等等的。咱们这个系统,可能有这么一些大的功能,这个就叫明确一级的一些功能。一般来说,在初次理解这个系统的业务的时候,这些东西都要定下来。
再来看第二个,去梳理使用系统的角色,这个对于我们后续的分析设计是非常有帮助的,尤其是咱们有一个方法叫业务走查,就是要模拟这些使用系统的角色,来完成实际的业务,就按照实际的业务场景来走查这个功能对还是不对。所以,这个地方要把使用系统的角色都梳理出来。另外一个,梳理这些角色,也有助于我们去理解这些业务功能。
思考的方式就是,站在系统的角度来思考,谁会使用我这个系统;哪些人用这个系统来完成他的日常工作;谁来维护这个系统;谁来管理这个系统;谁会从这个系统里面去查看一些信息等等的。
在这里,我们也可以去画UML的用例图。就是一个高层的,这么一个功能的边界,通过画图,我们会发现,会有哪些角色来使用系统。
第三个,就是“梳理系统”,梳理要使用的其他系统或资源。这个也是非常重要的,很多人容易把它忽略。啥意思呢?就是说,如果我们这个系统要想跑起来,刚才不是已经确定了这个功能边界了吗?说明内部只有这些功能,但是为了让我们的系统能够正常运转起来,可能还需要很多支撑的东西,或者说需要一些外围的系统。这些也要在这个阶段明确的定下来。
比如说用户管理的一部分功能,可能要来自于已有的一个软件系统,用户已经在使用的老系统,比方说来自CRM,也就是说,我们的用户管理会去使用CRM的一部分功能,也就是用户管理需要CRM这个系统的支撑。
类似的,订单管理可能会涉及到库存的一些功能,库存呢,也是已经做好的一些专业的库存软件,可能订单会去使用这个库存系统,这个时候就一定要搞清楚,我们要做的系统的边界到底在哪里,哪些是我们要做的,哪些是我们不做的。当然,订单管理,可能还会涉及到像支付、财务等系统,一般来说,像电商系统很少会直接自己去管财务这些东西,一般都会跟后端的,比方说ERP,或者说财务系统去对接,比较大型一些的企业,基本上用的可能都是SAP这类的。这个时候,也需要把它标识出来,因为这个也涉及到未来的一个对接,就说你需要跟他结合上。
这些咱们在做这个初步的需求分析的时候,就要把他们明确下来,头脑里就很清楚的知道有哪些角色在使用我们的系统,我们的系统内部有哪些功能是我们需要做的,我们需要使用到外部哪些资源或者系统,这些系统是不需要我们做的,这样的话,未来我们的这个架构设计,需要考虑的边界就出来了。
你看,除了要考虑我们系统内部的这些功能之外,我们还要考虑这些使用的外部系统,我们怎么跟已有的这些系统进行集成,或者说是交互,这个就涉及了交互的方式、通信的协议、包括来回传递数据的格式、数据安全性、调用的频次、性能等等一系列的问题。
所以,我们做需求分析的时候,就要把这些东西定下来,这些就是这儿说的明确系统边界。
当然明确系统边界,并不仅仅只是针对最大的一级系统,实际上随着视角往里走,这也是做架构设计的一个基本的思想,就是从大到小,由粗到精,逐步细化。当我这个角色从一级的系统,假如已经走到用户管理这里头来了,还是同样的方式,一样要去分析用户管理这个系统,它里面包含的下一级子系有哪些,就这样一级一级向下细化。
也就说每一个层级,都应该按照这里讲的这个方式去明确系统的边界,每次都是明确当前这一级的大功能,然后要去识别他的角色,他要使用的外部的资源和系统。这些对我们后续的具体功能的需求分析,还有架构设计都是非常有帮助的。
这个方法,我们就先讲到这个地方,当然需求分析的方法并没有讲完,这才刚刚开始,才刚到明确系统边界这个地方,另外,这些方法咱们一定要结合具体的应用去进行实战,否则,可能你听起来觉得都对,说的也蛮有道理,但是一到结合具体业务的时候,就搞不定了,不知道怎么去用,不知道怎么去做。
为了大家更好的交流架构设计的思想和知识,大家可以加sishuok,拉你进架构设计群,一起共同学习,共同进步。