拆解CRM需求分析设计文档：从用例、权限到二次开发落地

简介《crm客户关系管理需求分析设计文档》面向企业信息化负责人、产品经理与CRM项目开发团队围绕客户信息整合、销售流程自动化、客户响应与忠诚度提升等目标提供一份成体系的需求分析蓝本。压缩包内共1个doc文件约1.66MB集中呈现项目背景、用户组织结构与相关业务、业务对象及术语定义、任务目标、运行环境、条件与限制以及功能需求、用例描述、数据概念结构图、系统业务流程图和界面原型等内容。已有189人学习适合在CRM选型、需求评审或开发交底阶段对照参考。读者可据此梳理功能边界、补全非功能约束并借助用例与数据流材料衔接后续设计与实现。1. 从一份六十页的文档说起接手一个 CRM 项目最怕的不是写代码而是拿到一份厚厚的《crm 客户关系管理需求分析设计文档》却不知道从哪下手。我见过不少团队把需求文档当摆设直接开干做到权限模块才发现“销售只能看自己客户”这条规则要推翻重来。这份文档的价值不在于写得多漂亮而在于它把客户关系管理里的角色、用例、数据流和运行环境全钉死了属于典型的“先想清楚再动手”型资产。它适合三类人正在做 crm 需求分析的产品准备接二手 CRM 项目的后端以及需要一份完整需求规格说明书当模板的开发者。下面按我拆文档的习惯从骨架、角色、模块一路讲到怎么改成能落地的开发任务。2. 文档骨架拆解六章正文里哪几节真正决定项目成败这份文档的目录是标准的软件需求规格说明书结构引言、任务概述、功能需求、性能需求、运行需求、参考资料。乍看很套路但真正决定后面开发顺不顺的其实只有三块——3.2 功能划分表、3.3.1 用例描述、3.3.2 实体关系图。其余章节是约束条件读的时候要带着“这会卡住哪个模块”的问题去看。2.1 目录结构与阅读顺序别从第一页顺着读顺着读最容易陷进 2.2.1 那段服务器采购清单里读完半小时还没碰到业务。我一般按这个顺序拆# 推荐的文档阅读顺序括号内是关注点 1. 3.1 总体功能需求 # 先建立角色和模块的全景 2. 3.2 功能划分表 # 拿到用例编号和优先级这是任务清单的雏形 3. 3.3.1 用例描述 # 逐条读事件流和业务规则这里藏着权限和状态机 4. 3.3.2 ER 图 # 把用例里的名词抽成实体 5. 3.3.3 业务流程图 # 校验实体之间的流转是否闭合 6. 2.2 运行环境 / 5.3 接口 # 最后看部署与集成约束这个顺序的逻辑是“先业务后技术”。3.1 那一段把系统管理员、主管、业务员三类角色的职责写得很直白读完就知道整个系统是围绕“业务员记录客户、主管把控意向、管理员管权限”这条主线转的。3.2 的表格更关键它把每个用例编了号、标了优先级5 最高等于提前给了你一份排期依据——优先级 5 的日程安排、邮件、审批必须先做优先级 3 的员工管理可以往后放。2.2 用例表字段拆解一张表就是一份开发任务用例描述是整份文档里信息密度最高的部分。以 CRM1.01 日程安排为例它的字段拆开看是这样的字段内容示例开发时对应什么用例编号CRM1.01任务编号、接口命名前缀主要参与者部门业务员、部门主管接口的鉴权角色前置条件已登录到系统平台拦截器 / 网关校验触发条件用户使用日程安排计划时触发页面入口、路由基本事件流点击日日程→新增→填写主题/起始时间/内容/关联客户→保存主流程接口备选流查询、修改、删除增删改查四个接口后置条件新增修改删除成功可通过检索验证验收用例业务规则销售人员只能对自己的日程信息增删改查数据权限过滤特殊需求无非功能补充读这张表要盯住两处。第一处是“关联客户”这个字段它说明日程不是孤立的时间记录而是挂在客户身上的后面建表时日程表必须有 customer_id 外键。第二处是业务规则那一行“只能对自己”五个字就是数据权限的源头很多人做 CRM 翻车就翻在只在前端隐藏了菜单后端接口照样能查到别人的数据。2.3 从用例到数据模型ER 图与流程图的交叉验证3.3.2 的实体关系图和 3.3.3 的业务流程图要对着看。ER 图告诉你有哪些实体流程图告诉你这些实体怎么流转。把用例里反复出现的名词抽出来大致是这些实体客户、客户分类、日程、日常事务、邮件、审批单、短信、部门、员工、角色权限。拿日常事务和日/周/月日程举例它们共享“主题、起始时间、内容、关联客户”这几个字段区别只在时间粒度。建表时有两种做法一是四张独立的表二是一张表加一个 type 字段区分。文档没有明说但从用例的备选流高度雷同来看我倾向于一张表加类型字段减少重复代码。对应的建表语句大概是这样-- 日程/事务统一表type 区分日常事务与日/周/月日程 CREATE TABLE crm_schedule ( id BIGINT PRIMARY KEY, owner_id BIGINT NOT NULL COMMENT 创建人对应业务员或主管, org_id BIGINT NOT NULL COMMENT 所属机构用于机构隔离, type TINYINT NOT NULL COMMENT 1日常事务 2日日程 3周日程 4月日程, subject VARCHAR(200) NOT NULL COMMENT 主题用例要求非空, start_time DATETIME NOT NULL COMMENT 起始时间, content TEXT COMMENT 日程内容, customer_id BIGINT COMMENT 关联客户可为空, status TINYINT DEFAULT 1 COMMENT 1正常 2已删除, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_owner_time (owner_id, start_time), KEY idx_org (org_id) ) COMMENT日程与日常事务;这段 DDL 里有三个参数值得说明。owner_id是数据权限的锚点所有“只能看自己”的查询都要带上它org_id对应文档 2.2.3 里“销售部门只能对自己管理范围内的系统进行管理”这条要求机构隔离靠它start_time上建索引是因为日/周/月三种视图本质都是按时间区间查。status用软删除而不是物理删除是因为用例的后置条件写了“可以通过检索的方式验证”删了还能查得到才符合这条。3. 角色与用例从三类角色到 CRM101~CRM305 的编号体系这份文档最值得学的一点是它用一套编号把角色、模块、优先级串起来了。3.1 总体功能需求里明确写了系统由三类角色组成系统管理员、主管销售部门和就业部门、业务员销售部门和就业部门。所有用例都是围绕这三类角色的权限边界展开的读懂了角色后面几十个用例就是同一套逻辑的重复。3.1 三类角色的权限矩阵把散落在各用例“业务规则”里的权限描述汇总起来能得到一张很清晰的矩阵功能系统管理员主管业务员客户分类管理增删改查看查看部门/员工管理任意机构下增删改本机构内增删改无日程安排无看下属、管自己只看自己、管自己日常事务无看下属、管自己只看自己、管自己我的申请无无提交、修改未通过、删除未审批我的审批无同意/不同意无指派人员/目标无可指派无邮件无收发自己的收发自己的数据库备份还原可操作无无这张表里有两处特别容易被忽略。一是“系统管理员可以在任何机构下创建用户机构管理员可以在自己机构下新建用户”这句话在 2.2.3 其它要求里说明管理员是分两级的建用户接口必须带 org_id 参数并做越权校验。二是“审批通过后就不能对结果进行删除、修改只能有查看的功能”这是审批模块的状态机约束不是简单的增删改查。3.2 用例编号的编码规律把 3.2 功能划分表里的编号排一下规律很明显CRM1xx日程、事务、邮件、审批、短信属于个人办公类CRM2xx客户管理、指派人员、指派目标属于业务协作类CRM3xx客户分类、数据库操作、权限设置、部门员工属于系统管理类编号第一位是模块大类后两位是序号。这个规律对开发很有用——接口路径可以直接按编号分组比如/api/crm1/schedule、/api/crm3/org前端路由也能按这个分。优先级列5 最高则直接对应迭代顺序CRM101 到 CRM120 这一批优先级普遍是 4 到 5属于第一迭代必须交付的CRM301 到 CRM305 优先级 3 到 4可以放到第二迭代。3.3 权限落地单点登录与机构隔离的接口约定文档 2.2.3 和 2.3 反复强调两件事需要单点登录但不要用 LDAP 或 AD能做成下拉列表的选项一定做成下拉列表。这两条约束直接决定了鉴权模块的设计。单点登录不用现成目录服务意味着要自建一套 token 中心登录成功后签发 token各业务模块拿 token 换用户身份和权限。接口层面我一般这么约定// POST /api/auth/login 的返回结构供各业务模块解析 { code: 0, data: { token: eyJhbGciOi..., // 后续请求放在 Header: Authorization userId: 10086, userName: sales_a, roleCode: SALES, // ADMIN / MANAGER / SALES orgId: 2001, // 机构ID所有查询强制带上 permissions: [CRM101, CRM102, CRM107] } }这段返回结构里roleCode决定角色级权限orgId决定数据范围permissions是细到用例编号的操作权限。业务接口收到请求后第一件事是从 token 里解析出orgId拼进查询条件而不是信任前端传来的机构 ID——这是机构隔离最容易被绕过的地方。文档里“销售部门只能对自己管理范围内的系统进行管理”这句话落到代码就是一条强制的 where 条件没有例外。下拉列表那条要求看着小实际影响面很大。客户分类、部门、员工、审批人这些字段在表单里都应该是下拉选择而不是手输。这意味着后端要提供一批字典接口比如/api/dict/customer-category、/api/dict/approver?orgId2001前端表单初始化时拉一次缓存起来。4. 功能模块与技术选型日程、邮件、审批、短信四条主线的数据流功能需求这一章占了文档一半以上篇幅但归归类其实就四条主线以日程和事务为核心的时间管理以收件箱/发件箱/废件箱为核心的邮件管理以申请和审批为核心的流程管理以及短信、组织架构、客户分类这些支撑模块。每条主线的数据结构不一样状态机也不一样拆的时候要分开看。4.1 日程安排模块四种时间粒度的统一建模日程安排包含日常事务、日日程、周日程、月日程四个用例基本事件流几乎一模一样进入界面、点击新增、填主题/起始时间/内容/关联客户、保存。区别只在展示维度。这意味着后端可以只做一套接口前端按视图切换查询区间。查询接口的设计要点是时间区间参数// 日程查询接口定义伪代码标注参数含义 // GET /api/crm1/schedule?type3start2024-06-01end2024-06-30 public ListScheduleVO listSchedule( RequestParam Integer type, // 1日常事务 2日 3周 4月 RequestParam String start, // 区间起ISO 日期 RequestParam String end, // 区间止 LoginUser user // 从 token 解析含 userId 和 orgId ) { // 强制注入数据权限业务员只看自己主管看本机构 Long ownerId user.isSales() ? user.getUserId() : null; return scheduleMapper.selectByRange(type, start, end, ownerId, user.getOrgId()); }这段代码的关键在ownerId那一行。业务员角色传自己的 userId主管角色传 null 表示看本机构全部机构 ID 始终作为硬条件。这样一套接口同时满足“业务员只能看自己”和“主管把控整体意向”两条业务规则。type参数让前端四种视图复用同一个接口日视图传当天区间周视图传周一到周日月视图传月初到月末。关联客户字段customer_id在保存时校验客户是否属于当前机构防止跨机构挂靠。4.2 邮件模块三个箱子的状态机邮件模块有写邮件、收件箱、发件箱、废件箱、查询邮件、账号配置、群发七个用例。表面看是七个功能实际是一个状态机在三个视图里的投影。一封邮件的状态流转是草稿/已发送 → 收件方正常 → 删除进废件箱 → 恢复或永久删除。用一张表加状态字段就能覆盖CREATE TABLE crm_mail ( id BIGINT PRIMARY KEY, sender_id BIGINT NOT NULL, receiver_id BIGINT NOT NULL, org_id BIGINT NOT NULL, subject VARCHAR(300), body MEDIUMTEXT, folder TINYINT NOT NULL COMMENT 1收件箱 2发件箱 3废件箱, is_read TINYINT DEFAULT 0, sent_at DATETIME, KEY idx_receiver_folder (receiver_id, folder), KEY idx_sender_folder (sender_id, folder) ) COMMENT邮件表folder 字段驱动三个箱子的视图;folder字段是这套设计的核心。收件箱查receiver_id 当前用户 AND folder 1发件箱查sender_id 当前用户 AND folder 2废件箱查folder 3。删除操作就是把 folder 从 1 或 2 改成 3恢复是改回去永久删除才是物理删。用例里“再次发送”功能不用新建记录复制原邮件重新走一次发送流程即可。文档特别写了“不同身份登录看到的邮件不同”这就是 receiver_id 和 sender_id 两个查询维度的区别别把收件箱和发件箱做成同一张视图。4.3 审批与短信申请单的流转与短信的双向记录审批管理有两个用例我的申请业务员提交和我的审批主管处理。业务规则写得很死——申请必须选一个审批人只能向自己的主管申请审批只能选同意或不同意通过后不能改不能删。这是一个标准的单向流程状态只有待审批、已通过、未通过三种。CREATE TABLE crm_approval ( id BIGINT PRIMARY KEY, applicant_id BIGINT NOT NULL COMMENT 申请人, approver_id BIGINT NOT NULL COMMENT 审批人提交时必选, org_id BIGINT NOT NULL, subject VARCHAR(200) NOT NULL COMMENT 主题用例要求非空, content TEXT, status TINYINT DEFAULT 0 COMMENT 0待审批 1通过 2未通过, approved_at DATETIME, KEY idx_approver_status (approver_id, status), KEY idx_applicant (applicant_id) ) COMMENT审批单;修改未通过申请的逻辑要特别处理不是原地改而是把 status 重置为 0 并清空 approved_at相当于重新提交。短信管理相对简单发送、已接收列表、已发列表、删除四件事本质是一张短信表加方向字段和邮件模块异曲同工不再展开。4.4 组织结构与系统管理部门、员工、客户分类的树形结构组织结构模块包含部门管理和员工管理系统管理模块包含客户分类管理、数据库备份还原、设置用户权限。这三块有个共同点——都是树形或层级数据。部门是树客户分类也是树员工挂在部门下。这类数据建表统一用 parent_id 自关联CREATE TABLE crm_department ( id BIGINT PRIMARY KEY, parent_id BIGINT DEFAULT 0 COMMENT 0表示根节点, org_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, path VARCHAR(500) COMMENT 物化路径如 /1/5/12/加速子树查询, KEY idx_parent (parent_id) ) COMMENT部门树;path字段是血泪经验。文档要求“系统管理员可以在任何机构下创建用户机构管理员只能在自己机构下新建用户”判断某部门是否属于某机构用 path 前缀匹配比递归查询快得多。客户分类管理同理只是把 org_id 换成全局可见。数据库备份还原属于运维功能文档里只写了“对数据库的备份或还原”实际落地一般做成定时任务加手动触发两个入口不在业务代码里直接执行 dump。5. 避坑与排查需求文档落地时最容易翻车的五个点需求文档写得再细落到代码还是有一堆坑。下面五条是我这类项目里踩过或见过别人踩的按“现象 → 原因 → 解决”记下来省得后来人再交学费。5.1 权限只做在前端接口裸奔现象业务员用浏览器开发者工具改一下请求参数里的 userId就能查到同事的客户和日程。原因开发时图快菜单按角色隐藏了后端接口却直接按前端传来的 ID 查询。解决所有查询接口强制从 token 解析当前用户机构 ID 和用户 ID 不接受前端传参主管角色的“看下属”通过服务层拼 where 条件实现不在 SQL 里信任任何外部输入。5.2 日周月日程的边界日期错位现象周日晚上建的周日程周一打开不见了跨月的月日程在月末最后一天显示不全。原因周起始日按周日算还是按周一算没统一月视图用字符串拼日期而不是日期函数。解决全系统统一周一为周起始数据库存 DATETIME查询区间用 start AND end半开区间避免边界重复或遗漏。这种日期问题多少带点玄学唯一靠谱的办法是写单元测试把每个边界日都跑一遍。5.3 单点登录做成两套账号现象文档明确写了不要用 LDAP开发还是接了一套目录服务结果用户要在两个地方维护密码。原因没仔细读 2.3 条件与限制。解决自建 token 中心登录、鉴权、刷新三个接口搞定权限数据存在自己的库里对外通过 WebService 暴露统一的权限校验接口供其他系统调用。5.4 邮件导出 Excel 正文截断乱码现象收件箱勾选多封邮件导出正文超过三万字被截断中文变问号。原因导出时用了默认字符集单元格长度没做限制。解决导出流指定 UTF-8 BOM正文按五万字截断并在末尾加提示导出走流式写出避免大邮件撑爆内存。5.5 照抄硬件清单当采购单现象按文档 2.2.1 的服务器型号去询价发现配置和现在的云环境对不上。原因那份清单是项目立项时的物理机方案属于容量参考不是采购指令。解决把 CPU 核数、内存、磁盘 IOPS、网络带宽这些指标抽出来当容量基线部署形态按实际环境选文档里的双机热备和光纤存储柜当作高可用设计的意图来理解而不是照着买。6. 二次开发把需求文档变成可执行任务的三个动作拿到这类文档做二次开发最忌讳的是从第一页开始逐字翻译成代码。我的做法是三个动作先建任务清单再定接口契约最后拿后置条件当验收标准。第一个动作是把 3.2 功能划分表整张导进任务系统一行一个任务用例编号当任务编号优先级列当排期依据。这张表本身就是半成品 backlogCRM101 到 CRM120 归到“个人办公”迭代CRM201 到 CRM206 归到“客户协作”迭代CRM301 到 CRM305 归到“系统管理”迭代。每个任务下面挂两个子项接口开发和页面开发责任人分开领。第二个动作是按用例的事件流定接口契约。基本事件流对应主接口备选流对应增删改查业务规则对应鉴权注解。这一步做完前后端就能并行。比如日程安排四个接口一次定清楚接口方法对应事件流鉴权规则/api/crm1/schedulePOST新增日程登录即可owner 取 token/api/crm1/schedule/{id}PUT修改日程仅 owner/api/crm1/schedule/{id}DELETE删除日程仅 owner/api/crm1/scheduleGET查询日程业务员限自己主管限本机构第三个动作是把每条用例的“后置条件”抄下来当验收用例。文档写“新增、修改或删除日程信息成功可以通过检索的方式验证”那验收脚本就照这个写建一条、改一条、删一条再查一次确认结果。审批模块的后置条件更严格“审批通过后不能删除修改”验收时要专门测一遍通过状态下调删除接口必须返回业务异常。有个技巧我每次都强调权限中心先于业务模块做。这类 CRM 的权限规则散在几十个用例里如果业务模块先做完再补权限等于每个接口回头改一遍翻车概率极高。先用一周把角色、机构、token、权限注解这套东西搭好后面每个业务接口加一行注解就能接上返工量能省一大半。从那以后我每次接需求文档类的项目都强制先把功能划分表导出成任务清单、把业务规则列成鉴权矩阵再动第一行代码。这份六十页的文档放在那儿不是给人看的是给人拆的——拆得越早后面写代码时踩的坑越少。希望帮到你。本文还有配套的精品资源点击获取