企业官网建设流程全解析

简介：这份CRM客户关系管理需求分析设计文档面向企业信息化项目团队、产品经理、需求分析人员及开发测试人员，用于厘清企业版CRM在客户信息整合、销售流程自动化、数据分析与客户服务等场景下的需求边界，并为后续设计开发提供统一依据。压缩包内仅含1个doc文件，大小约1.66MB，以单文档形式组织，便于按章节查阅和复用。文档从项目背景、用户组织结构与相关业务入手，依次给出任务目标、运行环境、条件与限制、总体功能需求、功能划分、用例描述、数据概念结构图、系统业务流程图及性能需求等内容，对业务对象和术语也作了统一定义。已有189人学习下载，可作为CRM需求分析模板、用例编写和业务流程梳理的参考，也适合用于课程设计或企业项目立项阶段的需求对标。

1. 需求先立住：CRM需求分析文档到底要回答哪几个问题

不少团队做客户关系管理项目，代码写到一半才发现"主管能不能看下属的客户""审批通过后还能不能改"这类事，谁都没拍过板。反直觉的地方在于，CRM 需求分析最难的从来不是画用例图，而是把角色、数据范围和状态流转这三件事在同一份文档里对齐。这份 CRM 客户关系管理需求规格说明书要解决的就是这件事：它把系统管理员、部门主管、业务员三类角色，七个业务模块和几十条用例固定下来，同时给出运行环境、性能指标与 WebService 接口约定。适合正在做 CRM 需求分析课程设计、毕业设计，或者要给团队出一版可交付需求文档的人——改掉角色名和模块名，主体结构就能直接用。

2. 角色与权限建模：三类角色、七个模块的职责边界怎么划

CRM 项目里最容易扯皮的部分不是功能多少，而是"谁能看谁的数据"。业务员录入的客户，主管要不要看得到？系统管理员能不能直接改销售名下的客户？这些问题在编码阶段暴露出来，返工成本比写文档高一个量级。所以这份文档在功能需求之前先定死了角色：系统管理员负责客户分类、用户信息和数据安全；主管（销售部门和就业部门各一组）通过业务员记录的客户信息和日程安排把握客户意向，也能直接与客户沟通；业务员负责记录客户信息、反馈客户意愿。三类角色不是并列的菜单权限，而是一条数据归属链，后面所有用例的业务规则都从这条链上长出来。

2.1 角色-模块矩阵与数据可见范围

把角色和模块铺成一张矩阵，是这份文档里性价比最高的一页。它同时解决两个问题：开发知道每个菜单该给谁看，测试知道每个角色该造哪些账号。下面这张表按正文的功能划分整理，优先级沿用原文的 5 分制（5 最高）。

矩阵里"本人""本部门""跨机构"这三个词不是形容词，是数据范围谓词，必须在设计阶段翻译成可执行的过滤条件。我一般会把它写成一条统一的取数规则：业务员查询时强制拼接owner_id = 当前用户，主管查询时拼dept_id = 当前用户所属部门，系统管理员不加部门条件但保留机构条件。这条规则写进文档的"其它要求"一节，比散落在几十条用例的备注里可靠得多。

-- 客户列表取数：同一句 SQL 通过数据范围参数适配三类角色 SELECT c.customer_id, c.customer_name, c.category_id, c.owner_id FROM crm_customer c WHERE c.status = 1 -- scope_type = 'SELF'：业务员，只看自己名下 AND ('SELF' <> #{scopeType} OR c.owner_id = #{userId}) -- scope_type = 'DEPT'：主管，看本部门 AND ('DEPT' <> #{scopeType} OR c.dept_id = #{deptId}) -- scope_type = 'ALL'：系统管理员，只受机构条件约束 AND ('ALL' <> #{scopeType} OR c.org_id = #{orgId}) ORDER BY c.created_at DESC;

这段 SQL 的关键在于把"角色判断"放在应用层，把"数据过滤"收敛到一条语句里，三个参数scopeType、userId、deptId全部由登录态注入，前端不传也不接受。这样做的好处是新增角色时只改参数映射，不用去翻每个 DAO。原文里"销售部门只能对自己管理范围内的系统进行管理"这句模糊要求，落到这里就是scopeType的取值约定，测试也能照着造三条边界数据。

2.2 权限落到用例：业务规则怎么写才不打架

很多需求文档的"业务规则"一栏写的是"销售人员只能管理自己的客户"这类话，开发看完还是不知道该在哪个接口拦。合格的写法是把规则拆成"主体 + 动作 + 约束条件 + 违反后的表现"四段。以日程安排为例，原文的业务规则是"销售人员只能对自己的日程安排信息进行查询，添加，修改，删除"，拆开之后是：主体为业务员，动作为日程的增删改查，约束为owner_id = 当前用户，违反时返回 403 并在页面提示"无权操作他人日程"。

再往下走一层，就要区分"界面隐藏"和"服务端拦截"。界面上不显示别人的日程条目只是体验，真正的边界在服务端：任何带主键的写操作，都必须先用主键查一次归属，再比对当前用户。只靠前端隐藏按钮的权限控制，在接口层面等于没有，这是踩过的坑。

// 日程写操作统一前置校验：先查归属，再判角色 public void assertScheduleOwner(Long scheduleId, LoginUser user) { Schedule s = scheduleMapper.selectById(scheduleId); if (s == null) { throw new BizException("日程不存在"); } // 主管可查看下属，但不可代替下属修改；管理员不参与业务数据 boolean isOwner = s.getOwnerId().equals(user.getUserId()); boolean isLeaderRead = "LEADER".equals(user.getRoleCode()) && s.getDeptId().equals(user.getDeptId()); if (!isOwner && !isLeaderRead) { throw new BizException("无权操作他人日程"); } }

这段校验放在 Service 层入口，所有写接口复用它，参数只有日程主键和登录态两个，返回的是业务异常而不是布尔值，方便统一转成 403。注意这里刻意让主管"可读不可写"——原文没有明说主管能改下属日程，但从"主管通过业务员记录的日程把握客户意向"的定位看，只读是更稳妥的解释，我在文档里会把它写成一条显式规则，避免开发各自理解。

2.3 组织结构与单点登录的三条硬约束

组织结构这块原文给了两个角色边界：系统管理员可以在任何机构下创建用户，机构管理员只能在自己机构下新建用户。这句话翻译成表结构，就是用户表必须带org_id，并且新建用户接口的org_id不接受前端传参，只能从登录态取。否则一个机构管理员改个请求体就能往别的机构塞账号，这类翻车在验收阶段特别难查。

单点登录是另一处容易写虚的地方。原文明确要求"需要单点登功能，但不使用 AD 或其他 LDAP 系统"，同时"用户不需要且不要使用 LDAP 服务"。这句话的价值在于把选型锁死了：不要在设计文档里画一套 LDAP 目录同步的方案，那和需求是相反的。通常的做法是自己发令牌，业务系统统一走一次鉴权接口拿用户、角色、部门三个值，令牌有效期和续期策略写进"接口要求"一节。

第三条约束是交互层面的："能做成下拉列表的选项一定做成下拉列表"。看起来是界面细节，实际影响数据模型——凡是下拉，就意味着背后有一张字典表或枚举，客户分类、部门、岗位、审批人这些字段都不能存自由文本。把这条写进文档，后面做数据校验和统计分组会省很多事。

3. 用例描述规范：从日程安排到查询邮件的统一写法

这份文档的主体是几十条用例，从 CRM1.01 日程安排一路排到短信和系统管理。用例写得好不好，直接决定开发和测试能不能各干各的还不跑偏。我在看这类文档时有个习惯：先翻三条不相邻的用例，如果它们的字段顺序、事件流粒度、备选流编号方式一致，这份文档基本可用；如果每条长得都不一样，后面一定会在"这个分支算主流程还是异常"上吵起来。所以这一章讲的是模板，不是某一条具体用例。

3.1 用例模板的九个字段与填写口径

原文的用例描述包含用例名称、编号、作用域、版本、优先级、主要参与者、涉众、前置条件、触发条件、基本事件流、备选流、后置条件、业务规则、特殊需求这些字段，数量偏多，实际填起来容易空着。我一般收敛成九项必填，其余可空，并且给每项定一个填写口径。

表格里最值得盯的是"后置条件"和"业务规则"两栏。原文在这两栏其实做得不错，比如日程安排的后置条件写的是"新增、修改或删除日程信息成功，可以通过检索的方式可以验证"，这句话给了测试一个动作：去列表检索，看得到就是通过。比"操作成功"这种无法验证的写法强很多。业务规则那栏则反复出现"只能对自己""只能对销售主管申请"这类约束，填的时候只要补齐违反后的表现，就能直接转成接口校验点。

优先级这一栏也别浪费。原文用 5 分制，客户信息管理、邮件系统、日程安排都是 5，组织结构是 4，这种分布本身就说明了迭代顺序：第一期先做客户、邮件、日程三条主线，组织结构和系统管理可以第二批交付。把优先级写清楚，答辩时被问"如果只有两个月怎么做"，你就有现成答案。

3.2 主事件流与备选流的拆分：以日程安排为例

日程安排是整套用例里结构最完整的一条，它把日常事务、日日程、周日程、月日程四个入口收在同一个用例下，主事件流按入口分三段，每段都是"点击进入 → 弹出新增窗口 → 填写主题/起始时间/内容/关联客户 → 保存"。这里有个设计点值得单独拎出来：四个入口共用同一张日程表，靠schedule_type区分粒度，而不是建四张表。原文虽然没有写表结构，但从"关联客户"在四个入口里都出现这一点看，共用实体是唯一合理的解释。

拆分备选流时，我一般按"查询、修改、删除"三组走，每组写清入口动作和结果。原文的写法是先给主流程，再在备选流里列 a) 查询 b) 修改 c) 删除，每条都是"点击条目 → 弹窗 → 操作 → 保存"。这种结构的优点是实现时可以直接映射成四个接口：列表查询、详情、保存（新增和修改合一）、删除。

用例：CRM1.01 日程安排 主事件流： 1. 用户进入日程安排页，选择 日常事务 / 日日程 / 周日程 / 月日程 2. 点击"新增"，弹出事务窗口 3. 填写主题、起始时间、内容、关联客户 4. 点击保存，写入日程表，schedule_type 记录粒度 备选流： A1 查询：点击日期块 -> 按 owner_id + 日期区间查列表 A2 修改：点击条目 -> 回填表单 -> 保存时校验归属 A3 删除：点击条目 -> 二次确认 -> 逻辑删除 业务规则： R1 业务员仅能操作 owner_id = 本人的日程 R2 主管可查看本部门日程，不可代改 R3 关联客户必须存在于当前用户可见的客户范围

这段文本不是代码，但它比代码更适合放进需求文档：开发和测试都能照着它写接口和用例。R3 这条是我补的，原文只在窗口字段里提了"关联客户"，没写校验。按这个项目的场景，如果不校验关联客户的可见范围，业务员完全可以把别的部门的客户挂到自己日程上，等于绕开了数据隔离，这是典型的"文档没写、上线才发现"。

日常事务（CRM1.02）的结构更简单，只有列表、新建、修改、删除四步，但它的后置条件同样要求"可以通过检索的方式验证"，说明这条用例的验收动作是固定的：改完去列表搜一下。我的审批（CRM1.03）和我的申请（CRM1.04）则引入了状态，放到下一节单独说。

3.3 审批与申请的状态机约束

审批这条线是全篇最容易写漏的地方。原文给了一条很关键的规则："审批通过后就不能对结果进行删除，修改。只能有查看的功能。"这句话如果只写在特殊需求里，开发很可能理解成"前端把按钮置灰"，结果接口照样能改。正确的做法是把申请单抽象成状态机，把规则写成状态迁移表。

有了这张表，"通过后不能改"就变成了"已通过状态不接受 update 和 delete 请求"，实现和测试都有明确依据。原文还提到"销售人员的申请只能对销售主管进行申请""进行审批的必须选择一个审批人"，这两条对应到表里就是approver_id非空约束和审批人角色校验。

# 申请单状态迁移校验：所有写操作先过这一关 ALLOWED = { ("DRAFT", "SUBMIT"): "PENDING", ("PENDING", "WITHDRAW"):"DRAFT", ("PENDING", "APPROVE"): "APPROVED", ("PENDING", "REJECT"): "REJECTED", ("REJECTED", "SUBMIT"): "PENDING", ("REJECTED", "DELETE"): "DELETED", } def transit(current, action, operator, apply_row): key = (current, action) if key not in ALLOWED: # 已通过、已删除等终态在这里被拦住 raise BizError("当前状态不允许该操作") if action in ("APPROVE", "REJECT") and operator != apply_row["approver_id"]: raise BizError("非指定审批人") if action in ("SUBMIT", "WITHDRAW", "DELETE") and operator != apply_row["applicant_id"]: raise BizError("非申请人") return ALLOWED[key]

这段函数只做三件事：查迁移表、校验操作人、返回目标状态。参数current是数据库里的状态值，action是接口动作，operator从登录态取，apply_row是申请单原始记录。把它放在所有写接口的最前面，状态混乱的问题基本不会出现。剩下的就是让数据库状态值和文档里的中文状态名一一对应，别出现库里存2、文档写"已通过"、代码判断"PASS"的三方对不上。

4. 数据结构与运行环境：ER 图、数据字典与一份可落地的部署清单

需求文档写到功能为止是不够的，评审时一定会有人问"数据怎么存""部署在哪"。原文在第三章给了数据概念结构图和业务流程图的位置，在第二章给了相当详细的服务器配置，这两块经常被当成凑数内容，实际上它们决定了项目能不能在验收环境里跑起来。这一章把实体关系和运行环境各拆一层，给出可以直接抄的字段和检查清单。

4.1 实体关系与核心表设计

按功能模块推，这套系统至少要十张核心表：客户、客户分类、联系人、日程、日常事务、邮件、邮件账号、审批单、短信、部门、员工（用户）、角色权限。关系的骨架是：部门 1:N 员工，员工 1:N 客户，客户 1:N 联系人，员工 1:N 日程，员工 1:N 邮件，员工 1:N 审批单。原文的数据概念结构图没有展开到字段级，我按项目场景补一版最小可用的核心表。

-- 客户主表：数据范围过滤依赖 owner_id 和 dept_id 两个字段 CREATE TABLE crm_customer ( customer_id BIGINT NOT NULL COMMENT '客户主键', customer_name VARCHAR(120) NOT NULL COMMENT '客户名称', category_id INT NOT NULL COMMENT '客户分类，关联分类字典', owner_id BIGINT NOT NULL COMMENT '归属业务员', dept_id BIGINT NOT NULL COMMENT '归属部门，主管可见范围依据', org_id BIGINT NOT NULL COMMENT '所属机构，管理员范围依据', source TINYINT DEFAULT 1 COMMENT '来源：1自拓 2转介绍 3合作企业', status TINYINT DEFAULT 1 COMMENT '1正常 0归档', created_at DATETIME NOT NULL COMMENT '创建时间', PRIMARY KEY (customer_id), KEY idx_owner (owner_id, status), KEY idx_dept (dept_id, status) ); -- 日程表：四个入口共用，用 schedule_type 区分粒度 CREATE TABLE crm_schedule ( schedule_id BIGINT NOT NULL COMMENT '日程主键', owner_id BIGINT NOT NULL COMMENT '所属业务员', dept_id BIGINT NOT NULL COMMENT '冗余部门，避免联表过滤', schedule_type TINYINT NOT NULL COMMENT '1日 2周 3月 4日常事务', subject VARCHAR(200) NOT NULL COMMENT '主题', start_time DATETIME NOT NULL COMMENT '起始时间', content VARCHAR(2000) COMMENT '内容', customer_id BIGINT COMMENT '关联客户，可为空', deleted TINYINT DEFAULT 0 COMMENT '逻辑删除标记', PRIMARY KEY (schedule_id), KEY idx_owner_time (owner_id, start_time) );

两张表有两个共同的设计取舍：一是dept_id冗余，避免每次列表查询都去 join 用户表拿部门，主管看下属数据的场景下这个冗余很值；二是逻辑删除，日程和客户都不做物理删除，否则主管的统计口径会随删除动作变化。customer_id允许为空是刻意的——日常事务不一定关联客户，原文的日常事务用例里也没有强制关联，如果设成非空，反而会把"记录待办"这类用法挡在门外。

客户分类、部门、岗位这几个字段都对应字典表，正好呼应 2.3 里"能下拉就下拉"的要求。字典表不要图省事做成一张大表加type字段，客户分类有层级（原文提到"客户分类列表节点"，说明是树），部门也是树，两类树混在一张表里，后面做递归查询会很难受。分开建，各留parent_id和sort_no。

4.2 部署环境参数与接口约定

运行环境这部分，原文写得相当实在：2U 机架式服务器、双路四核处理器、2G 内存起步、RAID 卡带电池保护缓存、8 个热插拔盘位，存储侧配光纤磁盘柜（14 盘位、双控制器、256MB 带电池保护缓存）和 SAN 交换机，客户端是 Windows XP SP2，数据库 SQL Server 2000，编译环境 JDK 1.5，应用服务器 WebSphere 6.1。这套配置放在今天看明显偏老，但作为需求文档的写法它是对的：把服务器、存储、网络、软件四层列清楚，采购和部署才有依据。

接口这行是原文里容易被忽略但很重要的一条：系统要为其他应用提供统一的权限管理服务。这意味着鉴权不是内部方法，而是对外契约，方法签名要提前定死。

部署前我习惯跑一遍自检脚本，把版本类问题挡在启动之前。这类问题在验收现场特别致命，容器一起来就报类找不到，排查半天发现是编译和运行的 JDK 不一致。

#!/usr/bin/env bash # 部署前环境自检：任一项不通过就退出，避免带病启动 set -e echo "[1/4] 检查 JDK 版本" java -version 2>&1 | head -n 1 # 必须与编译期一致，不能一个 1.5 一个 1.6 echo "[2/4] 检查数据库连通性" # 用配置文件里的地址连一次，确认账号密码和库名都没写错 sqlcmd -S "$DB_HOST" -U "$DB_USER" -P "$DB_PASS" -Q "SELECT 1" > /dev/null echo "[3/4] 检查应用服务器端口" nc -z "$APP_HOST" "$APP_PORT" # 端口不通就先查防火墙和实例状态 echo "[4/4] 检查存储挂载点容量" df -h "$DATA_MOUNT" | awk 'NR==2{print "可用:", $4}'

脚本四步分别对应四类高频故障：版本不一致、连错库、端口没开、磁盘写满。参数DB_HOST、APP_HOST这些从部署环境的配置文件读，不要写死在脚本里。跑通这四步再启动应用，能省掉大量"环境问题还是代码问题"的争论。

5. 避坑与常见问题排查：需求文档里最容易翻车的五个点

需求文档的问题有个共同特征：写的时候不疼，开发和验收的时候集中爆发。下面五条是我在这类 CRM 文档里反复见到的，每条按现象、原因、解决三段写，能对上号的直接改。

5.1 编号与范围类问题

现象：功能清单里写 CRM201 客户管理、CRM101 日常事务，用例章节里又冒出 CRM1.01 日程安排、CRM015 我的审批，测试建用例库时对不上号，最后只能人工比对。原因：文档由多人分章撰写，编号规则没有在动笔前统一，有人按模块三位数，有人按章节小数位。解决：开工前定一条编号规则并写进文档首页——模块两位 + 序号三位，全篇唯一，功能清单和用例章节共用同一套编号，评审时专门花十分钟抽查一遍。这条看着琐碎，但它是后面需求覆盖矩阵能不能自动对齐的前提。

现象：数据范围写了"销售部门只能对自己管理范围内的系统进行管理"，开发理解为"本部门"，测试理解为"本人"，两边都没错。原因：范围谓词没有落到字段，文档里全是"管理范围""相关部门"这类词。解决：把所有范围描述统一替换成字段级表达，本人写owner_id，本部门写dept_id，跨机构写org_id，一个词都不留。改完之后文档会长一点，但歧义没了。

5.2 状态与数据类问题

现象：审批通过的单子还能被申请人删掉，或者被审批人再批一次，数据出现两条审批记录。原因：状态只写在页面上，接口层没有状态机校验，前端置灰被绕过就全线失守。解决：按 3.3 的迁移表在服务端做统一入口校验，终态（已通过、已删除）不接受任何写动作，同时给审批单加唯一索引(apply_id, approver_id)防重复审批。

现象：废件箱里的邮件"恢复"之后，原文件夹里出现两份。原因：邮件表只有一个folder字段，删除时把值改成废件箱，恢复时没有记录原文件夹，只能默认扔回收件箱。解决：邮件表加prev_folder字段，删除时先存原位置再改状态，恢复时按prev_folder回写。这个字段在需求文档里就该写出来，属于"删除、恢复"用例的后置条件。

5.3 环境与接口类问题

现象：开发环境跑得好好的，到验收环境启动就报错，日志里全是类加载失败。原因：编译用 JDK 1.5，运行环境装的是另一个版本，或者应用服务器版本和文档写的不一致。解决：把 4.2 的自检脚本纳入部署流程，版本号在文档里写死，不用"最新稳定版"这种表述。另一个高频坑是接口：文档只写"通过 WebService 提供统一权限服务"，没定方法名和返回结构，对接方各写各的，最后靠改代码对齐。接口清单必须在需求阶段就定下来，哪怕只定三个方法。

6. 验收与答辩：一张需求覆盖矩阵把闭环讲清楚

这类需求文档的验收，核心不是看页数，而是看每一条需求能不能追到实现、追到测试。我一般会做一张覆盖矩阵，四列：用例编号、对应功能点、验收方式、证据形式。验收方式分三种——界面走查、接口调用、数据核对；证据形式就是截图、接口返回、SQL 查询结果。矩阵填满，文档就站得住；有空行，就是评审时会被追问的地方。

答辩时的讲述顺序也有讲究。很多人上来就讲技术栈，听完不知道系统解决什么问题。我的习惯是先讲角色和数据范围——三类角色、谁能看谁的数据，两分钟讲完；再挑一条最完整的用例，把主事件流和备选流走一遍，比如日程安排；最后讲状态机，说明"审批通过后不可改"是怎么在服务端落住的。这三段讲完，评委基本不会再问"你这系统有什么特别的"，因为边界和约束已经说明白了。

有个细节容易被忽略：验收时要准备两套账号。一套是业务员，一套是主管，最好再有一个系统管理员。很多权限问题只有在切换账号时才会暴露，比如主管能看到下属日程但点进去报 500。我吃过一次亏，单账号自测全绿，验收当天切到主管账号，列表页直接白屏，原因是查询条件里dept_id取了登录态但主管表里没这个字段。从那以后我每次做权限相关的验收，都强制走一遍"两个角色、三条边界数据"的流程——本人数据、本部门他人数据、跨部门数据，各查一次、各改一次，看返回对不对。

这套矩阵和流程不复杂，但它能把一份几十页的需求文档变成可交付、可复现的东西。如果你手上正卡在 CRM 需求分析这一关，把角色矩阵、用例模板、状态迁移表这三样先补齐，剩下的内容往里填就行。希望帮到你。

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