3个步骤，快速分析toB产品需求 - 168大数据

一拿到toB的产品需求总是抓耳挠腮，不知道从哪里开始，甚至开始了也混乱不堪。但经历几个产品后发现再复杂的系统也有章可循——通过自下而上的找点、连线、画面。那如何找点，怎样连线，用什么画面？

实体关系图的概念来源于关系型数据库，也就是ER模型，主要用在信息系统的设计。但我发现简化了其中的理论后用来做需求梳理也很好。

实体的官方解释：实体是客观存在并可相互区别的事物。就数据库而言，实体往往指某类事物的集合。

我认为需求中反复出现的名词、可用属性描述的事物都可以抽离出来作为真正实体的备选，然后反复对比、去重（名字不同实际相同）得到所有实体。

需求：客户希望做一个应用，这个应用能使巡检员看到企业的所有帮助文档、可以查看企业的最新资讯；可以通过巡检员在app的报修行为产生工单，工单可以通过管理员分派给维修人员进行维修，维修完成后管理员检查是否合格，如果合格关闭工单，如果不合格重新分派。

根据此需求可以抽象出如下实体：帮助文档、资讯、工单、用户、管理员、维修人员，并两两关联看是否有强关联（两个实体有关系），如果有则在两个实体之间画一条线。

举例：依旧按照问题1中的例子：显然一个维修员可以看多篇帮助文档，而1篇帮助文档可以被多个维修员看，那么维修员和帮助文档就是多对多的关系，两两对应后得出如下结论：

以前都是用Visio绘制，但现在有很多线上工具也很好用，比如我现在用的ProcessOn。线上工具的好处是：网站不定期提供很多素材和模板，使用体验也比传统的Visio好很多，重点是还可以和其他同事协作。

经过以上3个步骤后实体以及实体间的关系已经基本清晰了，也就是系统要做哪些模块大致确定，如果功力够深，系统的表结构都有了模糊的呈现。

举例：依旧按照问题1中的例子，系统的模块大致是用户管理、帮助文档管理、资讯管理、工单管理。

（如果想更深入的学习ERD，比如有在图上标识某些实体是否可以为空，了解ERD绘制的标准、在ERD中添加属性等等要求，有很多材料可供学习，在此就不赘述了。

参考：如何使用Entity Relationship Diagram (ERD) 建模 – 关系数据库设计）

功能权限、数据权限的问题在大型系统中是逻辑最为复杂的模块，牵连甚广。

在进行权限的梳理前要明确：使用系统的角色有哪些？角色是自由配置还是内置写死？

一般大型系统组织结构复杂，用户灵活多变，角色是需要自由配置的，而小型的系统可能根据真实场景内置几个定义好的角色就可以。

仍旧是这个例子：客户希望做一个应用，这个应用能使巡检员看到企业的所有帮助文档、可以查看企业的最新资讯；可以通过巡检员在app的报修行为产生工单，工单可以通过管理员分派给维修人员进行维修，维修完成后管理员检查是否合格，如果合格关闭工单，如果不合格重新分派。

这个需求的业务足够简单，角色只有：管理员、巡检员、维修员，可以采用内置于系统的方式。

角色是功能权限的集合，那么功能权限的梳理也就变成了：哪些角色对哪些功能可写（增删改），对哪些功能可读（查看），对哪些功能不可读不可写？而描述清楚这些问题的最好方式是表格。

举例：根据需求，管理员对用户管理、帮助文档、资讯、工单可读可写，而维修员对帮助文档、资讯可读不可写，对工单可读可写，梳理如下：

有了这张表，各个角色的功能权限就较为清晰了。但是为什么能看到同一模块的两个用户看到的数据却是完全不一样？这是因为他们的数据权限不一样。

两个用户在同一个模块看到的数据不一样是因为他们的数据权限不一样。梳理数据权限的意义在于明确不同用户可读或者可写的数据范围。

用户对哪些数据可读可写与角色、组织架构有关。有的组织是扁平组织，有的则是一层一层的树形组织。我很多时候仍旧是在功能权限说明表的基础上重新描述数据权限。

继续之前的例子，将功能权限表的内的“√”替换为数据权限说明：

根据功能权限说明表和数据权限说明表，维修员的权限就可以概述为：可读写工单，但只能读写自己的工单。

所以，以上只是从工具层面介绍如何梳理权限，但真实的系统往往更复杂，比如功能权限的粒度是更小的按钮或者接口，比如引入标签系统。如果想深入学习可以继续研究RBAC权限模型并结合实际项目不断练习。

系统要对哪些实体进行管理、系统如何进行权限访问控制两个问题理清后需要一条横向的线将业务串起来形成【面】，流程图便可以帮我们找到那条横向的【线】。

流程图是用来描述各个实体间的关系、系统作业顺序和信息流向的图表。任何的系统都有流程，只是简单和复杂的区别。

流程图可以帮我们理清很多业务流程和数据流向，也是原型之前对系统的逻辑思考，简单系统的业务流程通常用一个泳道图就画完了，而复杂系统可能需要分模块、分层级进行状态图、时序图、流程图等不同类型的图表的绘制才能大致解释清楚业务逻辑。

如果流程图只是作为需求阶段的中间输出物，天马行空地画也未尝不可，有时还能在某个点迸出创新的火花，但如果作为正式的输出物，可能就要拘泥于UML的标准了。

1. 根据需求从开始到终点绘制该角色的操作流程，如果某些活动涉及多种角色则使用泳道图；

系统逻辑经过流程图的绘制后就变得清晰了，系统的神秘面纱被慢慢揭开。原型图有了这些图表作为逻辑支撑，效率和可用性都会大大提升。

你可能学了假流程图，三步教会你绘制大厂流程图(第一篇)

制作人人喜欢的流程图，三步教会你绘制大厂流程图(第二篇)

任务和业务流程图分清用好，三步教会你绘制大厂流程图(第三篇)

三个步骤只是从“术”的层面简单地概括如何做toB产品的需求分析，但是不同的系统需求也不尽相同，需要灵活使用和长期的微观体感，如果文章中的内容存在什么问题欢迎指正，也希望大家在需求分析的道路上每天有所进步。