CRM客户关系管理系统需求文档落地实战：权限模型、数据建模与避坑指南

简介：这份CRM客户关系管理需求分析设计文档面向企业信息化负责人、产品经理与软件开发团队，用于指导企业版CRM系统的设计与落地，帮助解决销售流程自动化、客户信息整合与数据分析支持等核心问题。压缩包内共1个doc文件，约1.66MB，内容为完整的Word版需求分析文档，便于直接查阅与二次编辑。文档结构清晰，涵盖引言、项目背景、用户组织结构与相关业务说明、业务对象及术语定义、任务概述、运行环境与条件限制，并深入展开功能需求、用例描述、数据概念结构图、系统业务流程图及界面原型预览，可帮助读者快速理解系统边界与交互设计。目前已有188人学习，适合作为需求分析写作范本、课程设计或项目立项的参考材料，读者可从中获取需求建模思路、数据流梳理方法与界面原型设计要点。

1. 从一份 60 页的需求文档说起：CRM 客户关系管理到底该怎么落地

很多做企业信息化的开发者都遇到过这种场景：产品经理甩过来一份几十页的 Word 需求规格说明书，说“照着这个把 CRM 客户关系管理系统搭出来”。打开一看，用例描述、数据流图、界面原型全都有，但真要动手写代码，还是不知道从哪下手。这份《CRM 客户关系管理需求分析设计文档》就是典型的这类资料——它不是代码，而是一份完整的、编号到 CRM305 的用例级需求规格，覆盖客户信息管理、日程安排、邮件系统、审批管理、短信管理、组织结构、系统管理七大模块。适合谁看？一是正在做 CRM 需求分析、需要一份可参照的用例模板的开发者；二是拿到类似文档但不知道怎么把用例翻译成数据库表和接口的后端同学；三是想理解企业级 CRM 权限模型（系统管理员/主管/业务员三层角色）怎么设计的产品和架构人员。下面我按“文档讲了什么 → 怎么把它变成可运行的系统 → 怎么改”这条线，把这份资料拆开讲。

2. 需求文档结构拆解：七大模块和三层角色的权限模型

2.1 文档整体骨架：从引言到参考资料的六段式

这份文档的目录结构非常标准，是典型的企业级需求规格说明书写法。第 1 章引言交代编写目的、项目背景、用户组织结构和术语定义；第 2 章任务概述给出运行环境（硬件、软件、网络）和条件限制；第 3 章功能需求是重头戏，包含总体功能需求、功能划分表、以及每个用例的详细描述；第 4 章性能需求；第 5 章运行需求，里面藏着大量界面原型描述；第 6 章参考资料。

对开发者来说，真正要精读的是第 3 章和第 5 章。第 3 章的功能划分表把每个用例都编了号，比如 CRM201 客户管理、CRM101 日常事务、CRM107 发邮件、CRM114 我的审批、CRM301 客户分类管理，优先级从 3 到 5 不等。这个编号体系直接可以映射成开发任务列表——优先级 5 的先做，优先级 3 的排后面。

第 5 章运行需求里列了 25 个界面原型描述，从“添加发送短信”到“客户信息管理”，每个界面都写了操作流程。这部分内容在开发时可以直接当 UI 验收清单用。

2.2 三层角色权限模型：系统管理员、主管、业务员

这份文档最核心的设计是权限模型。系统里定义了三类角色：

这个模型的关键约束在文档里写得很明确：“销售部门只能对自己管理范围内的系统进行管理”“系统管理员可以在任何机构下创建用户，机构管理员可以在自己机构下新建用户”。翻译成代码就是：每个业务员属于一个部门，主管管理本部门业务员，系统管理员跨部门。

注意：文档特别强调“用户不需要且不要使用 LDAP 服务”，但同时又要求“单点登录功能”。这意味着认证要自己实现，不能用现成的目录服务。常见做法是用一张用户表加一张角色权限关联表，登录时签发 token，各模块统一校验。

2.3 功能模块划分与用例编号体系

把功能划分表整理一下，能清楚看到模块之间的依赖关系：

• 客户信息管理（CRM201）：客户管理，优先级 5，是整个系统的数据基础
• 日程安排（CRM101-104）：日常事务、日日程、周日程、月日程，优先级 5
• 指派管理（CRM205-206）：指派人员、指派目标，主管专属
• 邮件系统（CRM107-113）：发邮件、收邮件、废件箱、查询、账号配置、删除、群发
• 审批管理（CRM114-115）：我的审批（主管）、我的申请（业务员）
• 短信管理（CRM116-118）：发送、查询、删除
• 组织结构（CRM119-120）：部门管理、员工管理
• 系统管理（CRM301-305）：客户分类、数据库操作、权限设置、部门/人员增删改

这里有个设计细节值得注意：日程安排被拆成了四个粒度（日常事务、日、周、月），但底层数据结构其实可以统一成一张日程表，用 type 字段区分粒度。文档把它们分成四个用例，更多是从用户操作视角出发的。

3. 从用例到代码：核心模块的数据模型和接口设计

3.1 客户信息管理：CRM 系统的数据地基

客户信息管理是优先级最高的模块，文档里 CRM201 的描述虽然简短，但结合“客户信息管理是本系统的重点，贯穿于整个项目”这句话，可以推断客户表是整个系统的核心外键来源。日程要关联客户、邮件要关联客户、审批也可能关联客户。

按这个场景下合格开发最可能用的做法，客户表至少需要这些字段：

-- 客户信息主表 CREATE TABLE crm_customer ( id BIGINT PRIMARY KEY AUTO_INCREMENT, customer_name VARCHAR(128) NOT NULL COMMENT '客户名称', industry VARCHAR(64) COMMENT '所属行业', contact_name VARCHAR(64) COMMENT '联系人', contact_phone VARCHAR(32) COMMENT '联系电话', contact_email VARCHAR(128) COMMENT '联系邮箱', category_id BIGINT COMMENT '客户分类ID，关联分类表', owner_id BIGINT NOT NULL COMMENT '负责业务员ID', dept_id BIGINT NOT NULL COMMENT '所属部门ID', status TINYINT DEFAULT 1 COMMENT '状态：1正常 0禁用', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, INDEX idx_owner (owner_id), INDEX idx_dept (dept_id), INDEX idx_category (category_id) ) COMMENT '客户信息表';

这里owner_id和dept_id是关键。文档说“销售部门只能对自己管理范围内的系统进行管理”，所以查询客户列表时，业务员只能看到owner_id = 自己的记录，主管能看到dept_id = 本部门的所有记录，系统管理员不加限制。这个权限过滤逻辑建议放在 Service 层统一处理，不要散落在每个 SQL 里。

对应的查询接口大概长这样：

// 客户列表查询，带数据权限过滤 public PageResult<CustomerVO> listCustomers(CustomerQuery query, UserContext ctx) { // 根据角色拼接数据权限条件 if (ctx.isAdmin()) { // 系统管理员：不加限制 } else if (ctx.isManager()) { query.setDeptId(ctx.getDeptId()); // 主管：本部门 } else { query.setOwnerId(ctx.getUserId()); // 业务员：仅自己 } return customerMapper.selectPage(query); }

参数说明：UserContext从登录 token 里解析出来，包含 userId、role、deptId；CustomerQuery是前端传来的查询条件，包含客户名、分类、分页参数。这样写的好处是权限逻辑只有一处，后面加角色或改规则不用满项目找。

3.2 日程安排模块：四种粒度的统一建模

文档把日程拆成日常事务、日日程、周日程、月日程四个用例，但从数据角度看，它们都是“某个用户在某个时间段要做的事”。我一般会统一成一张表：

CREATE TABLE crm_schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL COMMENT '所属用户', schedule_type TINYINT NOT NULL COMMENT '1日常事务 2日日程 3周日程 4月日程', subject VARCHAR(256) NOT NULL COMMENT '主题', content TEXT COMMENT '内容', start_time DATETIME NOT NULL COMMENT '开始时间', end_time DATETIME COMMENT '结束时间', customer_id BIGINT COMMENT '关联客户ID', status TINYINT DEFAULT 0 COMMENT '0待办 1完成', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_time (user_id, start_time) ) COMMENT '日程安排表';

文档里反复出现“关联客户”这个字段，说明日程和客户是多对一关系。业务规则写得很清楚：“销售人员只能对自己的日程安排信息进行查询，添加，修改，删除”。所以增删改查都要带上user_id = 当前用户的条件。

周日程和月日程的展示逻辑不同，但存储是一样的。前端按周或月查询时，传时间范围给后端：

// 按时间范围查询日程，用于周视图/月视图渲染 public List<ScheduleVO> listByRange(Long userId, Date rangeStart, Date rangeEnd) { return scheduleMapper.selectByUserAndTime(userId, rangeStart, rangeEnd); }

3.3 邮件系统：收件箱、发件箱、废件箱的状态流转

邮件模块的用例最多，从 CRM107 到 CRM113 一共七个。文档描述了收件箱的查看/回复/删除/导出/打印，发件箱的查看/删除/导出/打印/再次发送，废件箱的查看/恢复/永久删除/清空。这其实是一个典型的邮件状态机。

邮件表设计时，关键字段是folder和status：

CREATE TABLE crm_mail ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sender_id BIGINT NOT NULL COMMENT '发件人', receiver_id BIGINT NOT NULL COMMENT '收件人', subject VARCHAR(256) COMMENT '主题', body TEXT COMMENT '正文', folder TINYINT NOT NULL DEFAULT 1 COMMENT '1收件箱 2发件箱 3废件箱', is_read TINYINT DEFAULT 0 COMMENT '是否已读', send_time DATETIME COMMENT '发送时间', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_receiver_folder (receiver_id, folder), INDEX idx_sender_folder (sender_id, folder) ) COMMENT '邮件表';

删除操作不是物理删除，而是把folder改成 3（废件箱）；恢复就是改回 1 或 2；永久删除才是DELETE。文档里“废件箱”用例明确写了“恢复”和“永久删除”两个操作，说明设计上就是软删除。

提示：文档要求“不同身份登录看到的邮件不同”，这个在查询时用receiver_id = 当前用户 AND folder = 1就能实现，不需要额外权限表。

3.4 审批与申请：主管和业务员的双向流程

审批模块是两个用例配合的：业务员提交“我的申请”（CRM115），主管在“我的审批”（CRM114）里处理。文档规定“审批只能选择同意或不同意”“审批通过后就不能对结果进行删除、修改，只能有查看的功能”。

申请单表需要记录审批状态和审批人：

CREATE TABLE crm_approval ( id BIGINT PRIMARY KEY AUTO_INCREMENT, applicant_id BIGINT NOT NULL COMMENT '申请人', approver_id BIGINT NOT NULL COMMENT '审批人', subject VARCHAR(256) NOT NULL COMMENT '申请主题', content TEXT COMMENT '申请内容', status TINYINT DEFAULT 0 COMMENT '0待审批 1已通过 2已驳回', approve_time DATETIME COMMENT '审批时间', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_applicant (applicant_id), INDEX idx_approver (approver_id) ) COMMENT '审批申请表';

业务规则里有一条容易漏掉：“销售人员进行审批的必须有选择一个审批人”。所以提交申请时approver_id是必填的，前端要做校验，后端也要做非空判断。

4. 避坑与常见问题：需求文档落地时最容易翻车的五个点

4.1 权限过滤写在 Controller 层，导致越权查询

现象：业务员 A 通过修改 URL 参数能查到业务员 B 的客户列表。原因：权限判断写在了 Controller 的参数校验里，只校验了“是否登录”，没校验“数据归属”。解决：把数据权限过滤下沉到 Service 层或 MyBatis 拦截器，统一在 SQL 里拼owner_id或dept_id条件。文档里“销售部门只能对自己管理范围内的系统进行管理”这句话，必须在数据层落实。

4.2 日程的四种粒度共用一张表但查询条件写错

现象：周日程页面显示了日常事务的数据。原因：查询时忘了加schedule_type条件，或者前端传的 type 值和数据库定义对不上。解决：在枚举类里统一定义 type 值，前后端共用一份常量。查询接口强制要求传 type，不传就报错而不是返回全部。

4.3 邮件删除后收件箱还能看到

现象：用户删除邮件后，刷新收件箱列表邮件还在。原因：删除操作只改了is_deleted字段，但查询收件箱时没加这个条件。解决：统一用folder字段做状态管理，收件箱查询固定folder = 1，删除就是UPDATE folder = 3。所有查询都走同一个 Mapper 方法，避免条件遗漏。

4.4 审批通过后仍能修改申请内容

现象：业务员在申请通过后还能编辑申请单。原因：修改接口没有校验status字段。解决：在 Service 层的 update 方法里加判断：if (status != 0) throw new BusinessException("已审批的申请不可修改")。文档里“审批通过后就不能对结果进行删除，修改”这条规则，要在每个写操作入口都检查。

4.5 单点登录和 LDAP 的矛盾没处理好

现象：系统要求单点登录，但又不让用 LDAP，开发时不知道 token 怎么共享。原因：文档只说了“需要单点登录功能，但不使用 AD 或其他 LDAP 系统”，没给具体方案。解决：常见做法是自建认证中心，用 JWT 或 Session 共享。各子系统跳转时带上 token，认证中心统一校验。如果系统规模不大，直接用 Spring Security + JWT 就够了，不用引入 CAS 这种重方案。

5. 二次开发与改造：把需求文档变成可维护系统的几个技巧

拿到这份需求文档做二次开发，最怕的是把用例一条条硬编码成 if-else。我的习惯是先抽三层：数据权限层、状态机层、界面配置层。

数据权限层就是前面说的，用拦截器或 AOP 统一处理owner_id/dept_id过滤。这样后面加“区域经理”这种新角色时，只需要改拦截器里的角色判断，不用动业务代码。

状态机层针对邮件和审批这两个有状态流转的模块。邮件有“收件箱→废件箱→永久删除”和“废件箱→收件箱”的流转，审批有“待审批→通过/驳回”的流转。用枚举定义状态和允许的操作，比散落的 if 判断好维护得多：

public enum MailFolder { INBOX(1, "收件箱"), SENT(2, "发件箱"), TRASH(3, "废件箱"); private final int code; private final String desc; // 构造和 getter 省略 // 定义允许的状态流转 public static boolean canMoveTo(MailFolder from, MailFolder to) { if (from == TRASH && to == INBOX) return true; // 恢复 if (from == INBOX && to == TRASH) return true; // 删除 if (from == SENT && to == TRASH) return true; // 删除 return false; } }

界面配置层是因为文档第 5 章列了 25 个界面，如果每个界面都写死，后面改需求会疯。我一般会把下拉选项、列表列定义这些做成配置表或 JSON 配置，前端动态渲染。文档里说“能做成下来列表的选项一定做成下拉列表”，这种统一规则正好用配置层实现。

还有一个改造点是编号体系。文档里的 CRM101、CRM201 这些编号，可以直接做成权限资源表的resource_code，和角色权限关联。这样新增功能时，只要在资源表里加一条记录，角色配置界面就能勾选，不用改代码。

验证改造是否成功，我通常跑三个检查：一是用业务员账号登录，确认只能看到自己的数据；二是用主管账号登录，确认能看到本部门数据但不能跨部门；三是把一条邮件从收件箱删到废件箱再恢复，确认状态流转正确。这三个检查过了，基本的数据权限和状态机就没大问题。

从那以后我每次拿到需求规格说明书，都强制先做一件事：把用例编号抄到数据库设计文档里，每个模块的表和接口都标注对应的用例号。这样开发和验收时能一一对应，不会出现“文档写了但代码没做”或者“代码做了但文档没提”的情况。希望帮到你。

本文还有配套的精品资源，点击获取