企业官网建设流程全解析

简介：这份CRM客户关系管理需求分析设计文档面向企业信息化项目中的产品经理、需求分析师与开发人员，围绕企业版CRM系统的建设目标，提供从需求梳理到设计落地的完整参考。文档系统覆盖引言、任务概述、功能需求、性能需求等章节，包含用户基本情况、组织结构与业务流程说明，并配有详尽的用例描述、数据概念结构图（实体—关系图）、系统业务流程图以及界面原型预览，帮助读者理解销售流程自动化、客户信息整合与数据分析支持等核心诉求。资源包为1个doc文件，约1.66MB，结构完整、目录清晰，可直接用于需求评审、方案撰写或教学参考。目前已有187人学习，适合需要快速掌握CRM需求分析方法、对照用例与数据流图完成系统设计的读者参考借鉴。

1. 从一份 60 页的 CRM 需求文档说起：它到底能帮你省下多少返工

接手过 CRM 项目的人大概都有过这种体验：需求评审会上大家点头如捣蒜，开发到第三周突然发现"客户信息管理"的权限边界没人说得清，销售主管到底能不能看到下属的日程安排，翻遍聊天记录也找不到结论。这份《CRM 客户关系管理需求分析设计文档》就是冲着这个场景来的——它不是一份泛泛而谈的模板，而是一份带编号、带用例、带业务规则的完整需求规格说明书，覆盖客户信息管理、日程安排、邮件系统、审批管理、短信管理、组织结构、系统管理七大模块，光用例编号就从 CRM101 排到 CRM305。

文档的骨架很清晰：引言交代编写目的和项目背景，任务概述锁定运行环境和条件限制，功能需求部分用大量用例描述把每个操作的前置条件、基本事件流、备选流、后置条件、业务规则全部写死，后面还跟着数据概念结构图和系统业务流程图。适合谁用？正在做 CRM 需求分析的产品经理、需要把需求翻译成代码的开发者、以及要拿这份文档去跟客户对齐验收标准的实施人员。如果你手上正缺一份能直接改改就用的需求底稿，这份文档的颗粒度值得你花时间拆一遍。

2. 需求文档的骨架怎么搭：从引言到功能划分的落地路径

2.1 引言和任务概述里藏着哪些必须锁死的参数

很多人拿到需求文档习惯直接跳到功能描述，结果开发到一半发现运行环境对不上。这份文档在引言和任务概述部分把该锁的东西全锁了，我建议你按下面的顺序过一遍。

先看编写目的和项目背景。文档明确写了读者对象是就业部、市场部门、系统维护人员，这意味着需求描述的详略程度是按"非技术背景也能看懂"来定的。项目背景里交代了用户组织结构是销售部门、就业部门、系统维护部门三层，这个结构直接决定了后面权限模型的设计——销售只能管自己范围内的客户，系统管理员可以在任何机构下创建用户，机构管理员只能在自己机构下新建用户。

再看运行环境。硬件部分写得很细：HP DL380G5 服务器，四核 E5430 2.66GHz 处理器，2G 内存，P400i RAID 卡支持 RAID 0/1/1+5/5，存储用 MSA1000 光纤磁盘柜。软件环境是 Windows XP SP2 + SQL Server 2000 + JDK 1.5 + WebSphere Application Server 6.1。这些参数在今天看来确实老旧，但它的价值在于示范了"运行环境该怎么写"——不是笼统写"主流服务器"，而是具体到型号、核数、内存、RAID 级别。

条件与限制部分有一条特别值得注意：用户不需要且不要使用 LDAP 服务，但需要单点登录功能。这是一个典型的约束条件，它直接排除了基于 LDAP 的 SSO 方案，逼着你在应用层自己实现会话共享。如果你在做一个类似的项目，这条约束一定要在需求阶段就确认清楚，否则架构选型会走弯路。

2.2 功能划分表怎么读：优先级和角色边界是重点

文档第 3.2 节的功能划分表是整份文档的索引，我把它整理成了一张更直观的表格：

这张表的核心价值在于两点：优先级标注和角色边界。优先级 5 的用例是必须最先实现的，优先级 3 的可以放到二期。角色边界则直接对应后面的业务规则——比如日程安排模块明确写了"销售人员只能对自己的日程安排信息进行查询、添加、修改、删除"，这条规则如果漏掉，开发出来的系统就会出现销售能看到主管日程的越权问题。

功能划分表还有一个容易被忽略的作用：它是需求变更的基线。当客户后期提出"能不能让销售也指派任务"时，你可以翻到这张表，指出指派功能的角色限制是主管，变更需要走评审流程。这比口头扯皮有效得多。

2.3 用例描述的三段式结构：前置条件、事件流、业务规则

文档第 3.3 节是重头戏，每个用例都按统一结构展开。以 CRM1.01 日程安排为例，它的结构是这样的：

前置条件：已登录到系统平台。这看起来是废话，但它定义了用例的起点——所有操作都必须在登录态下进行，意味着权限校验是每个用例的第一道关卡。

基本事件流：用户点击"日程安排"页面，菜单中有日常事务、日日程、周日程、月日程四个选项。以日日程为例，点击进入界面后点"新增"，弹出窗口，填写主题、起始时间、内容、关联客户，点击保存完成。这里的关键信息是"关联客户"字段——日程不是孤立的时间记录，它必须能关联到具体客户，这是 CRM 系统和普通日历应用的本质区别。

备选流：查询、修改、删除。查询是点击相应日期显示日程信息，修改是点击日程条目弹出窗体修改后保存，删除是点击条目后点删除。备选流覆盖了主流程之外的所有分支，开发时如果只实现基本事件流，用户一用就会发现"怎么改不了"。

业务规则：销售人员只能对自己的日程安排信息进行查询、添加、修改、删除。这条规则是整个用例的灵魂，它决定了数据权限的实现方式——每条日程记录必须带创建人 ID，查询时强制拼接当前用户 ID 作为过滤条件。

我一般会建议团队在评审用例时重点盯三样东西：前置条件是否完整、备选流是否覆盖了异常分支、业务规则是否可测试。这份文档在这三点上做得比较扎实，可以直接作为需求评审的检查清单。

3. 把用例翻译成代码：权限模型与数据结构的实现要点

3.1 角色权限模型怎么落地：三类角色的数据隔离方案

文档定义了系统管理员、主管、业务员三类角色，每类角色的数据可见范围不同。系统管理员可以跨机构操作，主管只能看本部门数据，业务员只能看自己的数据。这个权限模型用代码实现时，核心是在数据层加一个"数据范围"字段。

常见的做法是在用户表里加一个data_scope字段，取值分别为ALL、DEPT、SELF。查询时根据当前用户的data_scope动态拼接 SQL 条件。下面是一个简化的实现示例：

def build_query(user, base_query): """ 根据用户的数据范围构建查询条件 user: 当前登录用户对象，包含 role 和 dept_id base_query: 基础查询语句 """ if user.role == 'admin': # 系统管理员，不加任何数据过滤 return base_query elif user.role == 'manager': # 主管，只能看本部门数据 return base_query.filter(dept_id=user.dept_id) else: # 业务员，只能看自己的数据 return base_query.filter(owner_id=user.id)

这段代码的逻辑很直白：管理员不加过滤，主管按部门过滤，业务员按创建人过滤。参数说明一下——user.role来自登录时写入 session 的角色标识，user.dept_id是用户所属部门 ID，user.id是用户唯一标识。这三个字段在用户表设计时就要预留好，后期补加会很痛苦。

需要特别注意的是，文档里提到"系统管理员可以在任何机构下创建用户，机构管理员可以在自己机构下新建用户"，这意味着创建用户这个操作本身也需要做数据范围校验。我见过不少项目在查询上做了权限控制，但创建和修改接口忘了加，导致业务员可以通过构造请求把数据挂到别的部门下面。血泪经验是：权限校验要覆盖增删改查全部操作，不能只做查询。

3.2 日程安排模块的数据结构：关联客户字段怎么设计

日程安排是这份文档里描述最详细的模块之一，日日程、周日程、月日程三个子功能共享同一套数据结构。从用例描述里可以提取出这几个关键字段：主题、起始时间、内容、关联客户、创建人。

关联客户这个字段的设计有两种常见方案。一种是单客户关联，日程表里加一个customer_id外键；另一种是多客户关联，加一张schedule_customer中间表。文档里写的是"关联客户是指日日程计划中所涉及的客户信息"，用的是单数表述，但实际业务中一次拜访可能涉及多个客户，我一般会建议用中间表方案，扩展性更好。

-- 日程主表 CREATE TABLE schedule ( id INT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200) NOT NULL COMMENT '主题', start_time DATETIME NOT NULL COMMENT '起始时间', content TEXT COMMENT '内容', schedule_type TINYINT NOT NULL COMMENT '类型：1日 2周 3月', owner_id INT NOT NULL COMMENT '创建人ID', dept_id INT NOT NULL COMMENT '所属部门ID', created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 日程与客户关联表 CREATE TABLE schedule_customer ( schedule_id INT NOT NULL, customer_id INT NOT NULL, PRIMARY KEY (schedule_id, customer_id) );

建表时有两个细节容易翻车。第一，owner_id和dept_id必须冗余存储，不能只存owner_id然后关联用户表查部门——因为用户可能调岗，历史日程的部门归属应该保持创建时的状态。第二，schedule_type字段用来区分日、周、月日程，查询时按类型过滤，这样三个子功能可以共用一套后端逻辑，前端只传不同的 type 值。

3.3 邮件模块的文件夹模型：收件箱、发件箱、废件箱的状态流转

邮件模块在文档里占了很大篇幅，收件箱、发件箱、废件箱三个文件夹的操作逻辑各不相同。收件箱支持查看、回复、删除、导出、打印；发件箱支持查看、删除、导出、打印、再次发送；废件箱支持查看、恢复、永久删除、清空。

这三个文件夹本质上是一张邮件表加一个状态字段。我一般会这样设计：

CREATE TABLE mail ( id INT PRIMARY KEY AUTO_INCREMENT, sender_id INT NOT NULL COMMENT '发件人ID', receiver_id INT NOT NULL COMMENT '收件人ID', subject VARCHAR(500) COMMENT '主题', body TEXT COMMENT '正文', status TINYINT DEFAULT 1 COMMENT '状态：1正常 2已删除 3永久删除', folder TINYINT NOT NULL COMMENT '文件夹：1收件箱 2发件箱 3废件箱', send_time DATETIME COMMENT '发送时间', is_read TINYINT DEFAULT 0 COMMENT '是否已读' );

状态流转的逻辑是这样的：新邮件写入时status=1，folder根据是发送还是接收分别设为 2 或 1。删除操作把status改为 2，同时folder改为 3。废件箱里的恢复操作把status改回 1，folder改回原文件夹。永久删除把status改为 3，清空废件箱则是批量把当前用户废件箱里所有status=2的记录改为 3。

这里有个坑要注意：文档里写"不同身份登录看到的邮件不同"，这意味着查询邮件列表时必须同时按sender_id或receiver_id过滤当前用户。收件箱查receiver_id=当前用户 AND folder=1，发件箱查sender_id=当前用户 AND folder=2，废件箱查(sender_id=当前用户 OR receiver_id=当前用户) AND folder=3。漏掉任何一个条件都会导致越权看到别人的邮件。

4. 避坑与排查：需求文档落地时最容易翻车的五个地方

4.1 用例编号和功能编号对不上

现象：开发拿着 CRM1.03 去找对应的功能描述，发现文档里 CRM1.03 是"我的审批"，但功能划分表里 CRM114 才是审批管理，两个编号体系并行，对不上号。

原因：文档在编写过程中经历了多次修改，功能划分表用的是 CRM1XX 系列，用例描述里混用了 CRM1.0X 和 CRM1.XX 两种格式，没有统一。

解决：在需求评审阶段就要求统一编号规则。我的做法是建一张映射表，把功能划分表的编号和用例描述的编号一一对应，评审时逐条核对。如果文档已经定稿无法修改，就在开发任务拆分时以用例描述为准，功能划分表只作为模块索引使用。

4.2 备选流覆盖不全导致异常分支漏实现

现象：开发只实现了基本事件流，用户点击"修改"按钮时页面没反应，因为备选流里的修改逻辑没写。

原因：用例描述里基本事件流写得很详细，备选流往往只有几行，开发容易只盯着主流程。

解决：把每个用例的备选流单独抽出来做成检查清单，每条备选流对应一个开发任务。比如日程安排的备选流有查询、修改、删除三条，就拆成三个子任务，完成一个勾一个。这份文档的备选流写得还算完整，但像"我的申请"用例里写了"审批通过后就不能对结果进行删除、修改，只能有查看的功能"，这种状态约束很容易在开发时被忽略，需要在代码里加状态判断。

4.3 业务规则里的权限约束在代码层被绕过

现象：测试发现业务员 A 可以通过修改请求参数看到业务员 B 的日程安排。

原因：前端做了权限控制，隐藏了入口按钮，但后端接口没有做数据范围校验，直接根据前端传来的 ID 查询。

解决：所有查询接口强制拼接当前用户的权限过滤条件，不信任前端传来的任何 ID 参数。具体做法是在 DAO 层封装一个统一的查询方法，所有涉及数据范围的查询都必须走这个方法。文档里"销售人员只能对自己的日程安排信息进行查询、添加、修改、删除"这条规则，要在代码层面落实为WHERE owner_id = :currentUserId，而不是靠前端隐藏按钮。

4.4 运行环境参数与实际情况不符

现象：开发环境用 JDK 1.8 和 MySQL 8.0 开发，部署到生产环境发现是 JDK 1.5 和 SQL Server 2000，SQL 语法不兼容，启动直接报错。

原因：需求文档里写的运行环境是 2009 年的配置，但开发团队用的是新环境，没有提前对齐。

解决：项目启动前先确认运行环境，如果生产环境无法升级，开发环境就必须降级到相同版本。这份文档明确写了 JDK 1.5 和 SQL Server 2000，如果照着做，开发时就要避免使用 JDK 1.6+ 的语法特性和 MySQL 专有函数。我一般会在项目根目录放一个environment.md，把 JDK 版本、数据库版本、应用服务器版本写清楚，每次新人入职先看这个文件。

4.5 单点登录需求与 LDAP 限制的冲突

现象：文档要求单点登录但不使用 LDAP，开发团队按常规方案集成 LDAP 后发现不符合约束，返工重做。

原因：需求文档在"条件与限制"里明确写了"用户不需要且不要使用 LDAP 服务"，但这条约束在功能需求部分没有再次强调，开发容易忽略。

解决：把"不使用 LDAP"这条约束提升为架构决策记录，在技术方案评审时作为一票否决项。替代方案可以是用数据库做用户存储，通过共享 session 或 token 实现单点登录。具体做法是登录成功后生成一个 token 写入 Redis，其他系统通过校验 token 来识别用户身份，不依赖 LDAP 目录服务。

5. 从需求文档到可运行系统：一份用例的完整验证路径

文档读完了，代码也写得差不多了，怎么验证做出来的东西跟需求文档是一致的？我一般会挑一个用例走完整条链路，日程安排里的"日日程"模块就很适合拿来练手。

先看前置条件：已登录到系统平台。验证时先用业务员账号登录，确认能正常进入系统。然后走基本事件流：点击"日程安排"，进入日日程界面，点"新增"，填写主题、起始时间、内容、关联客户，点保存。保存成功后回到列表页，确认新增的日程出现在对应日期下。这一步验证的是主流程是否跑通。

接着走备选流。查询：点击相应日期，确认能显示该日期的日程信息。修改：点击日程条目，弹出修改窗口，改掉主题后保存，确认列表里的主题变了。删除：点击日程条目，点删除，确认列表里该条目消失。这三条备选流覆盖了增删改查的完整闭环。

然后验证业务规则。用业务员 A 的账号创建一条日程，退出后用业务员 B 的账号登录，确认 B 看不到 A 的日程。再用主管账号登录，确认主管能看到本部门所有业务员的日程。这一步验证的是数据权限是否生效。

最后验证后置条件：新增、修改或删除日程信息成功后，可以通过检索的方式验证。在列表页用日期筛选，确认筛选结果与操作结果一致。

这套验证路径走下来，基本能覆盖一个用例 80% 以上的场景。我习惯把每个用例的验证步骤写成测试用例，开发提交代码后先跑一遍，通过后再交给测试团队。从那以后我每次拿到需求文档，都会先挑一个用例走完整条链路，确认需求、代码、验证三者对得上，再批量推进其他模块。希望帮到你。

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