简介这份CRM客户关系管理需求分析设计文档面向企业信息化负责人、产品经理与开发团队聚焦企业版客户关系管理系统从立项到落地的需求梳理帮助读者明确销售流程自动化、客户信息整合与数据分析支持等目标。压缩包仅含1个doc文件大小约1.66MB正文按引言、任务概述、功能需求、性能需求等章节组织依次交代项目背景、用户组织结构、业务对象与术语、运行环境及条件限制并给出用例描述、数据概念结构图、系统业务流程图和界面原型预览。已有189人学习适合作为需求分析模板或课程设计参考。读者可从中获得较完整的CRM需求文档骨架、业务场景拆解方式与用例编写思路也能借助数据流图和原型理解客户管理、销售协同等模块的交互边界用于快速搭建自己的需求说明或对照检查遗漏项。1. 一份 2009 年定稿的 CRM 需求文档为什么现在还有人翻上周有人丢给我一份 60 页的需求规格说明书让我判断“这套 crm 客户关系管理需求分析还值不值得作为新项目的底稿”。我翻到第三页就明白了它的价值不在功能列表而在用例编号、角色权限矩阵和界面原型清单这三样东西上。crm 需求分析最容易出问题的地方从来不是功能写不全而是权限边界模糊、状态流转缺失这份文档恰好在这两处给了能直接抄的骨架。它适合正在做客户关系管理系统立项、需要一份需求分析模板打底的后端和产品也适合手里有旧系统、想拿旧文档反推改造清单的维护人员。至于它跑在什么环境上、哪些约束今天已经失效后面几章逐条拆。2. 运行环境与技术栈从硬件清单反推部署边界很多人读需求文档习惯从第三章功能需求开始直接跳过第二章的运行环境。这是典型的图省事做法后面一定会遇到问题。环境章节写的是约束约束决定了你后面所有设计的上限——数据库版本锁死、单点登录不能用现成方案、内存配置撑不起并发这些问题在功能章节里一个字都看不出来。这份文档的第二章信息密度不低硬件、软件、其它要求三块拼起来基本能还原出当年的部署拓扑。2.1 硬件清单里的三个关键参数把原文的设备描述压成表格盯住三列就够了算力、存储路径、冗余级别。设备类型文档中的关键参数对部署的实际约束应用/数据库服务器双路四核 2.66GHz、2GB DDR2、双千兆网卡、RAID 卡带 256MB 电池缓存、8 盘位内存是硬瓶颈应用与数据库同机部署时连接池不能开大光纤磁盘柜14 盘位、2Gb/s SFP 接口、支持 RAID 0/1/01/5/ADG走 SAN 而不是本地盘说明当初就预留了扩容和第二台应用机的空间SAN 交换机4Gb 模块、5 米 LC-LC 多模光纤光纤链路是单点交换机故障会直接切断存储访问三个参数值得单独说。第一是 2GB 内存2009 年是标准配置放到今天连一个中型 Java 应用的堆都不够分如果照这份文档原样复刻JVM 堆最多给到 1GB剩下的留给操作系统和数据库连接池上限要压到 20 以内。第二是 RAID 卡的 256MB 电池缓存它决定写性能电池失效后缓存策略会自动切到直写数据库插入延迟会明显上升运维巡检要单独看这一项。第三是单电源与冗余电源的差异文档里服务器标了热插拔电源但没写数量存储柜明确写了冗余电源和风扇这个不对称在机房断电演练时会暴露出来。2.2 软件栈的版本锁链软件环境这一节只有四行但四行互相咬合动一个就要连带评估。层次组件版本约束说明客户端操作系统Windows XP SP2浏览器兼容基线界面原型里的打印、导出都按这个环境验证数据库SQL Server2000页大小、排序规则、varchar 长度上限都和老版本绑定运行时JDK1.5泛型、注解可用但 try-with-resources 这类语法不存在应用服务器WebSphere Application Server6.1类加载器策略、会话复制方式与后来的版本差异很大这条锁链的关键在于“没有一个是能单独升的”。SQL Server 2000 升到更高版本排序规则和日期类型行为会变历史数据迁移要先做字符集核对JDK 1.5 升到 8WebSphere 6.1 根本不支持得连应用服务器一起换。所以拿到这份文档做新项目时正确做法不是照抄版本号而是把它当成“已知可运行的最小组合”在这个组合上评估哪些约束今天必须打破。我一般会把这张表复制到立项文档里每行后面加一列“是否允许升级”让架构评审时逐行签字避免后面有人偷偷换版本导致联调失败。2.3 环境章节怎么转成验收项环境描述最容易写成一堆产品型号的罗列验收时没法逐条打勾。一个可执行的做法是把它拆成部署检查表每条都能用命令或界面操作验证。第一步把“网络及硬件环境”拆成资源核对项CPU 核数、内存总量、磁盘可用空间、网卡链路状态、RAID 级别与电池状态。每一项写清楚期望值和核对方式比如内存用系统信息页核对RAID 电池状态用阵列卡管理工具看。第二步把“支持软件环境”拆成版本核对项操作系统补丁级别、数据库实例版本与排序规则、JDK 版本、应用服务器版本与补丁号。排序规则这一项特别容易被漏掉它影响中文排序和唯一索引行为上线后才发现要改代价是整库重建。第三步把“其它要求”里的两条硬约束单独拎出来客户信息按管理范围隔离、能做成下拉列表的选项一定做下拉。前者是权限验收项后者是交互验收项都要在原型评审阶段逐页确认不能留到测试阶段再补。提示环境章节的验收项要在部署前全部核对一遍尤其是数据库排序规则和 JDK 小版本号这两项在联调阶段才暴露的话回滚成本很高。3. 角色与权限模型三类角色怎么落到用例编号上这份文档最值得抄的部分是第三章开头那张角色划分。它把系统切成系统管理员、主管、业务员三类每类的数据可见范围和可执行操作写得很死后面的用例基本都是这张表的展开。需求分析阶段最怕的就是权限写成“管理员可以管理所有数据”这种一句话开发照着做做完发现业务员能看到别人的客户返工时整张权限表重来。3.1 三类角色的权限边界把原文散落在各用例里的规则收拢能得到一张相对完整的权限矩阵。角色可见数据范围可执行操作对应模块系统管理员所有机构客户分类增删改、数据库备份还原、用户权限设置、部门与人员增删改系统管理、组织结构主管销售/就业本部门业务员数据审批、指派人员、指派目标、查看下属日程与客户审批管理、指派业务员本人数据客户信息增删改查、本人日程与事务、本人申请、邮件与短信客户信息、日程、邮件、审批发起矩阵里有两个容易写漏的边界。第一个是“主管可以直接和客户沟通”原文在总体功能需求里提了一句意味着主管对客户信息不只是只读还要有写权限具体写到什么程度文档没细说落地时要补一条“主管可编辑下属名下客户但编辑动作记入操作日志”。第二个是“系统管理员可以在任何机构下创建用户机构管理员只能在自己机构下新建用户”这句话把管理员分成了两级但文档的角色定义里只写了“系统管理员”机构管理员是隐含角色做权限表时要显式补上否则实现时很容易把两级管理员合并成一个超级管理员。3.2 用例编号的编码规则与断裂点文档给每个用例编了号前缀 CRM 加三位数字按模块分段101 到 104 是日程与事务107 到 118 是邮件、审批、短信119 到 120 是组织结构201 到 206 是客户信息与指派301 到 305 是系统管理与组织管理。这套分段规则本身是好东西开发和测试对需求时直接报编号比报“那个改日程的功能”高效得多。但这套编号在文档内部就断过一次。第三章里“我的审批”这个用例标题写的是 CRM1.03表格里的用例编号栏却填了 CRM015紧接着“我的申请”标题是 CRM1.04编号栏写 CRM016。同一份文档里出现了两套编号风格前面用点分三位后面用连续三位。这种断裂在需求评审时不起眼等到测试用例要按编号追溯时就会对不上号测试写 CRM015开发在代码注释里写 CRM1.03两边搜不到一起。血泪经验是接手任何带编号的需求文档第一件事是做一张编号对照表把标题编号、表格编号、目录编号三列并排放不一致的当场标红找原作者确认。这份文档如果直接拿来当基线CRM1.03 和 CRM015 必须统一成一个我一般保留点分风格因为它能表达“模块.序号”的层级连续数字丢了模块信息。统一之后再把对照表附在需求文档末尾后面加需求就按这个规则续号不再出现两套。3.3 单点登录与 LDAP 的取舍文档在“其它要求”和“条件与限制”里各写了一句需要单点登录功能但不使用 AD 或其他 LDAP 系统用户不需要且不要使用 LDAP 服务。两句话说的是同一件事但位置分散读快了容易只看到“需要单点登录”就去找现成方案结果接了一套目录服务验收时被业务方一句“我们不用那个”打回来。不用 LDAP 意味着什么得拆开看。LDAP 提供的是统一身份存储和认证协议不用它账号密码就得存在应用自己的库里单点登录的票据也得自己发。常见做法是自建一个认证中心登录成功后签发 token各子系统拿 token 回调认证中心校验token 里带用户 ID 和角色。这套东西在 2009 年的 WebSphere 环境里更可能是用应用服务器的会话共享加统一登录页实现的而不是现在流行的 JWT。落地时要注意两点一是会话过期时间要统一配置各子系统不能各设各的二是注销要广播一个子系统退出其他子系统的会话要同步失效否则用户以为退了实际还能操作。注意文档明确排除 LDAP 和 AD做技术选型时不要推荐目录服务方案哪怕它更成熟这是需求约束不是技术偏好。4. 功能模块落地日程、邮件、审批三条主干怎么拆第三章的功能描述占了全篇一半以上篇幅但真正需要动手拆的是三条主干日程安排、邮件系统、审批管理。剩下的客户信息管理和短信管理相对直白组织结构与系统管理是配套。这一章按主干逐条拆字段、状态和边界拆完基本能还原出数据库表结构和接口清单。4.1 日程与事务的字段和视图日程安排分四种日常事务、日日程、周日程、月日程。四者共用一套字段从原文的新增流程能抽出来主题、起始时间、内容、关联客户。关联客户是重点原文特意解释“是指日程计划中所涉及的客户信息”说明它不是可选的备注字段而是要把日程挂到具体客户上后面主管查看下属日程时才能按客户维度聚合。日常事务和另外三种日程的关系要理清。日常事务是独立实体有新建、修改、删除、查看四个操作没有日期视图的概念日、周、月日程是同一份数据的不同展示粒度新建周日程和新建日日程存的是同一张表只是界面入口不同。实现上不建议分三张表否则同一条日程在日视图改了、周视图没同步会出现数据不一致。我一般会建一张日程表用 start_time 和 end_time 定范围日周月视图只是查询条件不同。字段落地还有两个细节。起始时间只写了开始没有写结束实际排日程需要时长至少要补一个结束时间或持续时长字段否则日历上画不出块。内容字段的长度文档没给按业务场景估日程描述给到 500 字够用关联客户如果支持多个要单独建关联表而不是在日程表里存逗号分隔的客户 ID。4.2 邮件模块的状态机邮件系统是这份文档里状态最多的一块收件箱、发件箱、废件箱三个箱体加上查询、账号配置、群发三个辅助功能。状态流转写清楚实现才不会乱。收件箱的邮件可以查看、回复、删除、导出 Excel、打印。删除不是真删是移到废件箱。发件箱的邮件可以查看、删除、导出、打印、再次发送删除同样是移到废件箱。废件箱的邮件可以查看、恢复、永久删除、清空恢复是移回原来的箱体永久删除才是真删。这条链路的关键是“删除”这个动作在不同箱体里语义不同收件箱和发件箱里的删除是软删废件箱里的删除是硬删界面上按钮文案最好区分开一个叫“删除”一个叫“永久删除”原文在废件箱的备选流里确实是这么写的照着做就不会让用户误操作。导出 Excel 和打印是两个容易被低估的功能。导出要处理中文编码SQL Server 2000 时代的默认排序规则下导出文件用 UTF-8 还是 GBK 会影响 Excel 打开是否乱码这条放到避坑章节细说。打印依赖浏览器文档写的是“浏览器中显示邮件的所有内容点击打印完成”意味着打印样式要做单独的 CSS把导航和按钮隐藏掉只留正文。邮件账号配置这一项文档只列了用例名没展开字段。按常规实现至少要存邮件地址、显示名、SMTP 服务器、端口、是否 SSL、用户名、密码。密码存储不能明文哪怕是内部系统也要做可逆加密或单独的密钥管理这一条在需求评审时补进去别等安全扫描报出来再改。4.3 审批流的两个方向审批管理拆成两个用例我的审批和我的申请。前者是主管视角后者是业务员视角两者共享同一份审批单数据只是查询条件和可执行操作不同。我的申请由业务员发起字段至少要有主题、申请内容、审批人。原文写了两条硬规则主题和内容不能为空必须选择一个审批人。这两条要写成表单校验不能只靠前端提示后端接口也要拦。申请提交后状态是待审批主管审批后变成通过或不通过。业务规则里写“审批通过后就不能对结果进行删除、修改只能查看”这条是状态机的锁实现时要在更新接口里判断当前状态已通过的单子拒绝任何写操作不能只靠界面隐藏按钮。我的审批由主管操作只能看到自己作为审批人的单子审批结果只有同意和不同意两个选项没有“退回修改”这种中间态。这一点和很多现代审批流不同做惯了多级审批的人容易顺手加一个“退回”加了就和需求不符。要退回修改业务员只能对“未通过”或“未审核”的申请做修改这是原文在我的申请备选流里写的修改的是申请本身不是审批环节。指派功能挂在客户信息管理下面用例编号 CRM205 和 CRM206只有主管能指派人员和指派目标。指派目标和审批的区别在于指派是主管主动分配客户归属审批是业务员发起、主管决策两条线不要混在一张表里。4.4 界面原型清单当验收条目用文档第五章列了 25 项界面清单从添加发送短信、查看已接收短信列表到写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置再到日常事务和日常安排的增删改。这份清单看起来是目录实际是现成的验收条目表。用法很简单把 25 项抄进测试用例模板的第一列第二列写进入路径第三列写关键字段第四列写预期结果。比如“添加发送短信”这一项进入路径是短信管理下的发送入口关键字段是接收人、短信内容预期结果是发送成功且能在已发列表里查到。25 项逐个填完功能测试的覆盖面基本就齐了剩下的边界条件再按用例的备选流补。这份清单还有个隐性价值它能反推页面数量。25 项界面意味着至少有 25 个页面或弹窗排期时按页面估工作量比按功能点估更准因为页面里的字段校验、权限判断、异常提示都是实打实的工作量。5. 常见问题与排查需求文档里最容易出问题的五处需求文档写得再细落地时该出的问题一样会出。下面五条是这类 CRM 需求分析文档在实现阶段最高频的翻车点每条按现象、原因、解决三段写照着排查能省不少返工。5.1 关联客户留空日程变成孤立记录现象日程功能上线后主管想看某个客户名下的所有跟进安排发现查不出来日程列表里全是散落的主题点进去才知道对应哪个客户。原因新增日程的表单里关联客户字段做成了非必填业务员图快直接跳过数据入库后 customer_id 为空。原文虽然解释了关联客户的含义但没在业务规则里写“必填”实现时就按可选处理了。解决把关联客户改成必填前端加校验后端接口也拦一道。存量数据做一次清洗空关联的日程导出来让业务员补录补不完的挂到一个“未分类”虚拟客户下至少保证按客户聚合时能查全。5.2 权限只在前端藏按钮接口没校验现象安全测试时用业务员账号直接调主管的审批接口返回 200审批单被改掉了。原因权限控制做在页面层主管登录才渲染审批按钮接口层默认信任前端传上来的角色。原文的业务规则写了“销售主管只能对自己审批的内容进行审批”但这条规则没有落到接口鉴权上。解决所有写接口统一加一层角色校验从会话里取角色不信任请求参数里的角色字段。审批接口还要加数据级校验校验当前用户是不是这张单子的指定审批人不是就拒绝。这两层校验缺一不可角色校验防越权数据校验防横向越权。5.3 邮件导出 Excel 中文乱码现象收件箱勾选几封邮件点导出下载的 Excel 打开是乱码英文正常中文全变成问号或方块。原因导出时用默认编码写文件SQL Server 2000 的排序规则和 JVM 默认字符集不一致中文在写出过程中被转了一次。文档只写了“导出 Excel”这个动作没写编码要求实现时就用了平台默认值。解决导出流明确指定 UTF-8并在文件头写 BOM让 Excel 能识别编码。如果目标用户还在用旧版 Office改成导出 CSV 加 GBK 编码更稳。这条要在接口文档里写死不能留给开发自己选。5.4 用例编号断裂测试追溯对不上现象测试写用例时引用 CRM015开发在代码注释里写 CRM1.03两边搜不到一起评审会上互相说对方编号错了。原因文档内部存在两套编号风格前面点分三位后面连续三位同一份文档里“我的审批”标题和表格编号就不一致。需求阶段没人做统一到测试阶段才暴露。解决接手文档第一件事做编号对照表三列并排标题编号、表格编号、目录编号不一致的标红统一。统一后把对照表附在文档末尾新增需求按统一规则续号。已经写进代码的旧编号不用改在对照表里留一列“历史编号”做映射即可。5.5 审批通过后仍能修改状态机没锁死现象主管点了同意业务员回头还能编辑这张申请的内容改完再提交审批记录和申请内容对不上。原因更新接口只判断了“是不是本人的申请”没判断当前状态。文档写了“审批通过后就不能对结果进行删除、修改只能查看”但这条规则停留在业务描述层没有转成接口里的状态判断。解决在更新和删除接口入口加状态机校验状态不是“未通过”或“未审核”就直接拒绝。状态字段用枚举而不是数字代码里可读性更好。这条规则要写进接口文档的“前置条件”一栏和后端约定死。提示这五条里第 2 条和第 5 条属于同一类问题——业务规则写在需求里但没落到接口约束上。需求评审时把每条业务规则追问一句“这条在哪个接口里拦”能提前暴露大半。6. 进阶用法拿需求文档反推测试矩阵和验收清单需求文档写完不是终点它最大的剩余价值是能直接反推测试矩阵。我的习惯是把每个用例的基本事件流和备选流拆成两列基本流正常跑一遍算主路径备选流每条单独设计一个异常用例这样测试覆盖率不依赖测试人员个人经验。以日程安排为例基本流是新增日程备选流有查询、修改、删除三条加上业务规则里的“只能操作本人日程”四条异常用例就出来了查别人的日程应无权限、改别人的日程应拒绝、删别人的日程应拒绝、新增时不填关联客户应拦截。这四条不需要额外想从文档里逐句抠就行。功能点主路径异常路径验收依据日程新增填主题、时间、内容、关联客户后保存成功关联客户为空拦截、时间格式非法拦截用例 CRM1.01 基本流与业务规则我的申请填主题、内容、选审批人后提交主题为空拦截、未选审批人拦截用例 CRM1.04 后置条件我的审批主管查看待审批单并提交同意或不同意非指定审批人调用接口拒绝用例 CRM1.03 业务规则邮件删除收件箱删除后进入废件箱废件箱永久删除后不可恢复用例 CRM1.06 与 CRM1.08 备选流权限隔离业务员只能看到本人数据越权访问他人数据返回拒绝角色权限矩阵这张表填满之后验收清单也就有了。验收时不用再翻 60 页文档拿着矩阵逐行过每行对应一个可演示的操作通过就打勾不通过就记缺陷号。我在一个模拟项目上试过这套方法需求评审到测试用例设计的时间压缩了将近一半因为大部分用例是从文档里长出来的不是凭空想的。还有一个技巧是拿界面原型清单反查遗漏。25 项界面里如果有某一项在功能用例里找不到对应的基本流说明要么界面多余要么用例漏写两种情况都要在评审时提出来。这种交叉核对比通读文档更容易发现问题因为它是机械比对不依赖人对业务的理解深度。从那以后我每次接手这类需求规格说明书都强制走一遍“编号对照表 测试矩阵 界面清单交叉核对”三步哪怕文档看起来再完整。这份 2009 年的 CRM 需求分析文档能留到今天还有参考价值靠的就是用例编号、权限矩阵、界面清单这三样结构化信息而不是那些写得漂亮的功能描述。希望帮到你。本文还有配套的精品资源点击获取