做事情不难！难在做什么事儿？
我们经常听到这样的夸赞：“谁谁谁真会做事儿！”，说的就是某人做事讲究方法和策略。跟业务领域的多样性类似，方法论的也是多样的，每人的理解各不相同
跟大家分享一种基于角色关系的领域分析方法论
为什么是基于角色关系？
上一篇文章中说过，软件系统是为了解决现实中某类问题，所以，可以说软件系统就是满足提出这个问题的角色的诉求（注意这里说的是诉求，不是需求），系统需求就是通过对角色和角色关系的分析一点点归纳出来的。所以从角色和角色关系深入挖掘是一种不错的系统分析选择
拿电商招商的场景举个例子：
1）电商平台的核心诉求是找到商家并入驻，这样就很自然的挖掘出核心关系“平台和商家”
2）为了建立这层关系并实现诉求需要一系列的手段来支持，比如“入驻、报名、选品”等，这样招商业务的轮廓就比较清晰了
3）之后就到了具体的执行环节，需要系统提供一系列的技术能力来实现上述的方案
4）在能力建设过程中通过对系统的设计和需求梳理会归纳出一系列的业务实体和业务规则
总结上述例子中提到的核心概念术语，一共有8个：角色、诉求、关系、方案、业务域、能力域、实体、规则
下面详细阐述上述术语的解释：
》角色：
参与到业务活动并发生数据交互的主体，电商平台有偿为商家提供虚拟场所供商家经营，收取费用两者发生了数据交换
》诉求：
特指角色的诉求，是发生商业交换的前提，相互间的诉求正好匹配、互相满足，就形成了数据交换。需求不等于诉求，诉求是对问题本质的挖掘，包含充分的演绎和归纳。比如，客户要买一张凳子，这是需求，但不是诉求，这背后是有了凳子就能踩上去换坏了的灯泡。可能想到买梯子更好，但这也不是诉求。如果提供快速更换灯泡的服务，口碑良好的工人带上灯泡上门，也许客户更愿意买单，这更靠近本质。对诉求的挖掘和识别没有止境，越接近越真实，才能持续的支撑方案的良性运转。买方市场下，买家的诉求在关系中占主要地位
》关系：
角色间彼此的诉求，通过介质发现彼此，进一步了解、契合、建立关系，进而发生数据交换，诉求的强烈程度和时效性，也决定了关系的紧密和持久度。主要角色间的关系，推导出方案，方案的完备又旁生出支撑关系
》方案：
方案是为了促进角色间流畅的数据交换而拟定的计划和资源准备。方案进一步完善又加入了次要角色的支撑关系。因此，完整的方案是包含所有参与活动的角色，角色的诉求，角色间建立的关系，要发生数据交换，还需要一系列成套路运营支撑，构成了方案的全貌
》业务域：
角色间关系的建立和交换的发生过程，由多个连贯的域构成来表达，首先是角色和实体的信息化，并和平台建立关系，通过平台，角色彼此发现对方，建立关系，发生交换，履行过程进行，双方互评等。各业务域内又通过流程和操作完成关系建立，实体属性值的变换，成为下个承接环节的输入
主要角色两两关系确定一个业务域，偏角色之间交互操作，用来确定角色在某个环节相互作用的业务流程和操作，便于管理和复用
流程
为了实现角色的诉求，所进行的一些列的活动，过程中伴随着实体属性值的变更，从表单的提交，到审核，再到变更生效是一个多个环节组成的过程。流程的每个环节是一个操作，流程包含操作
操作
指角色或依附角色的员工在系统交互层面，通过一些列的操作活动，从而改变实体的属性值，强调一个交互内的动作，体现人的认知和理解对系统的投射。可以认为一个环节的流程就是操作
》能力域：
与具体业务无关，却又有商业含义的基础服务，用来改变对应实体属性值，或对操作进行约束，或创建，合并，拆分实体等，通过扩展点开放给上层业务进行定制
对实体属性值或状态进行操作的作用力，增、删、查、改、合并、拆分、限制等，具有商业含义，与具体一个业务无关按照被作用的实体，作用的目的及用途进行划分
》实体：
采用带有商业规则的模板所创建的对象，被业务域流程和操作作用的对象，或商业交换过程用到的载体，偏名词性，有外观或功用类的描述性信息，和状态信息
》规则：
规则具有行业特征，是平台为了满足多角色的权益制定的底线要求
角色、诉求、规则、业务域、方案，偏业务分析
能力域、实体、规则，偏技术设计
这里在分享一个表格用于辅助分析过程，供大家参考
image.png
预告，下一篇文章跟大家分享设计实战
网友评论