简介这份CRM客户关系管理需求分析设计文档面向企业信息化负责人、产品经理与软件开发团队用于指导企业版CRM系统的需求梳理与落地实施。文档围绕提升销售效率、整合客户信息、增强客户忠诚度等目标系统展开项目背景、用户组织结构、业务流程、业务对象与术语定义并给出任务目标、网络硬件与软件运行环境、条件与限制等约束说明。后续章节深入功能需求、用例描述、数据概念结构图实体—关系图、系统业务流程图及界面原型帮助读者理解信息在系统中的流动路径与交互设计。资源包为1个doc文件约1.66MB结构完整、目录清晰可直接作为需求评审、开发交底与测试用例编写的参考底稿。已有188人学习适合需要撰写CRM需求规格说明书或搭建客户管理系统的读者借鉴。1. 从一份真实需求文档说起CRM客户关系管理需求分析设计文档要解决什么很多同学做 CRM 毕设或课程设计第一反应是打开 IDE 建表写接口结果做到一半发现角色权限理不清、日程和客户关联不上、审批流走不通回头改需求比重新写还痛苦。这份 CRM 客户关系管理需求分析设计文档解决的正是这个前置问题在写第一行代码之前把系统管理员、主管、业务员三类角色的边界、客户信息管理这条主线、以及日程安排、邮件、审批、短信、组织结构这些支撑模块全部定义清楚。它适合正在做 CRM 需求分析毕设的学生、需要交付需求规格说明书的从业者也适合把这份文档当作课程设计模板直接套用的场景。文档本身是一份完整的软件需求规格说明书包含用例描述、数据概念结构图、业务流程图和界面原型清单下面我按方案落地的顺序把它拆开讲。2. 需求分析设计文档的总体结构六大部分与三类角色的职责划分2.1 文档骨架怎么搭从引言到参考资料的六段式一份能直接交给导师或甲方评审的需求分析文档结构上通常遵循固定骨架。这份文档的目录给出了一个很标准的六段式引言、任务概述、功能需求、性能需求、运行需求、参考资料。这个顺序不是随便排的它对应的是评审时的阅读逻辑——先知道为什么做引言再知道做成什么样任务概述然后看具体做什么功能需求接着看做到什么程度性能需求再看跑在什么环境上运行需求最后给出引用来源。我一般会建议把引言拆成四块写编写目的、项目背景、业务对象说明及术语定义、参考资料前置。其中项目背景又要细到用户基本情况、开发目标、用户组织结构、用户相关业务。很多同学写引言只写两句话评审时第一个被问倒的就是“你这个系统到底给谁用、解决他什么痛点”。这份文档在 1.2 节把用户基本情况、开发目标、组织结构、相关业务四块分开写就是为了让评审一眼看到需求来源。任务概述部分的核心是目标和运行环境。目标要写清楚系统定位比如这份文档写的是“为客户关系管理系统的基础模块提供完善的用户管理和授权管理通过标准的 WebService 为其他软件系统提供统一的权限管理服务”。运行环境则要分网络及硬件环境、支持软件环境、其它要求三块硬件要写到服务器型号、CPU、内存、RAID 卡、存储设备这一级软件要写到操作系统版本、数据库版本、JDK 版本、应用服务器版本。这不是炫技而是让后续开发和部署有据可依。2.2 三类角色怎么分系统管理员、主管、业务员的权限边界功能需求这一章最怕写成功能列表。这份文档的做法是先做功能划分再做功能描述最后补数据概念结构图和业务流程图。功能划分里把系统管理员、主管、业务员三类角色的用例编号、名称、优先级、备注列成表这一步非常关键因为它把“谁能在什么条件下做什么”提前锁死了。三类角色的职责边界可以这样理解业务员是数据的生产者负责记录客户信息、写日程、发邮件、提申请主管是数据的审核者和把控者负责审批、指派人员、指派目标、看下属日程来把握客户整体意向系统管理员是规则的维护者负责客户分类管理、数据库操作、用户权限设置、组织结构和人员管理。这份文档在 3.1 节明确写了“销售部门只能对自己管理范围内的系统进行管理”“系统管理员可以在任何机构下创建用户机构管理员可以在自己机构下新建用户”这就是权限边界的具体化。提示角色划分不要只写角色名一定要写到“这个角色能看到哪些数据、能改哪些数据、不能碰哪些数据”。评审时被问最多的就是越权问题。2.3 功能模块怎么切客户信息管理为主线日程、邮件、审批、短信为支撑功能划分表里列了客户信息管理、日程安排、指派员工、指派目标、邮件系统、审批管理、短信管理、组织结构、系统管理九大块。其中客户信息管理是主线贯穿整个项目其他模块都是围绕这条主线做支撑。日程安排关联客户邮件系统服务客户沟通审批管理支撑业务决策短信管理做消息触达组织结构决定数据可见范围系统管理维护基础规则。这种切法的好处是每个模块都能独立开发、独立测试最后通过客户信息这条主线串起来。如果按“增删改查”来切模块做到后面会发现客户、日程、邮件之间的关联关系散落在各处改一处牵动全身。按业务对象切每个模块的边界清晰接口也好定义。3. 核心功能模块的用例设计日程、审批、邮件三条线的落地写法3.1 日程安排模块日常事务、日日程、周日程、月日程的四层结构日程安排模块的用例编号是 CRM1.01优先级 5主要参与者是部门业务员和部门主管。这个模块的设计有个容易被忽略的点它把日程分成了日常事务、日日程、周日程、月日程四层。日常事务是待办清单性质日日程是按天排的计划周日程和月日程是按周和按月维度的视图。四层结构对应的是不同的使用场景——业务员每天看日常事务和日日程主管看周日程和月日程来把握团队节奏。用例的基本事件流写得很细以日日程为例点击“日日程”进入界面点击“新增”弹出窗口填写主题、起始时间、内容、关联客户后保存。其中“关联客户”这个字段是日程模块和客户信息管理主线的连接点没有这个字段日程就只是一个独立的日历工具和 CRM 没关系了。备选流覆盖了查询、修改、删除三种操作。查询是点击相应日期显示当天日程修改是点击日程条目弹出窗体修改后保存删除是点击条目后点删除。业务规则里明确写了“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”这条规则在实现时通常落到数据层的 where 条件上用当前登录用户 ID 过滤。-- 日程表核心字段设计以日日程为例 CREATE TABLE crm_schedule ( schedule_id BIGINT PRIMARY KEY, -- 日程主键 schedule_type TINYINT NOT NULL, -- 1日常事务 2日日程 3周日程 4月日程 subject VARCHAR(200) NOT NULL, -- 主题 start_time DATETIME NOT NULL, -- 起始时间 content TEXT, -- 日程内容 customer_id BIGINT, -- 关联客户可空 owner_id BIGINT NOT NULL, -- 所属业务员权限过滤依据 create_time DATETIME DEFAULT NOW(), update_time DATETIME DEFAULT NOW(), INDEX idx_owner_time (owner_id, start_time) );这段建表语句里schedule_type用枚举值区分四层日程避免建四张结构一样的表customer_id允许为空因为不是所有日程都关联客户owner_id是权限过滤的关键字段所有查询都要带上它。索引建在owner_id和start_time上因为最高频的查询是“查某个业务员某段时间的日程”。3.2 审批管理模块我的申请与我的审批的双向流程审批管理拆成两个用例CRM1.03 我的审批和 CRM1.04 我的申请。我的审批的主要参与者是销售主管基本事件流是进入审批管理界面、查看审批列表和内容、提交审批结果备选流支持查询审批信息。业务规则明确写了“审批只能选择同意或不同意”后置条件也写死了“审批只能选择同意或不同意”。我的申请的主要参与者是销售人员基本事件流是进入我的申请界面、查看申请列表、删除申请、修改未通过或未审核的申请。业务规则里有两条很关键一是“销售人员的申请只能对销售主管进行申请”二是“销售人员进行审批的必须有选择一个审批人”。特殊需求里还有一条“审批通过后就不能对结果进行删除、修改只能有查看的功能”。这两条规则合起来定义了一个完整的状态机申请提交后处于待审批状态主管审批后变为通过或未通过未通过的可以修改后重新提交通过的只能查看。实现时通常用状态字段加状态流转表来控制。// 审批状态流转的核心校验逻辑 public class ApprovalService { // 允许的状态流转待审批-通过/未通过未通过-待审批修改后重提 private static final MapInteger, ListInteger ALLOWED_TRANSITIONS Map.of( 0, List.of(1, 2), // 待审批 - 通过 / 未通过 2, List.of(0) // 未通过 - 待审批 ); public void updateStatus(Long applyId, Integer targetStatus, Long operatorId) { Apply apply applyMapper.selectById(applyId); // 校验当前操作人是否为指定审批人 if (!apply.getApproverId().equals(operatorId)) { throw new BizException(无权审批该申请); } // 校验状态流转是否合法 ListInteger allowed ALLOWED_TRANSITIONS.get(apply.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BizException(当前状态不允许该操作); } apply.setStatus(targetStatus); applyMapper.updateById(apply); } }这段代码把业务规则翻译成了可执行的校验先校验操作人是不是指定审批人再校验状态流转是否在允许范围内。ALLOWED_TRANSITIONS这个 Map 就是状态机的定义后续如果要加“撤回”功能只需要在这里加一条流转规则不用改业务逻辑。3.3 邮件系统模块写邮件、收件箱、发件箱、废件箱、查询、账号配置的完整闭环邮件系统是这份文档里用例最多的一块从 CRM1.05 到 CRM1.11 覆盖了写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、删除邮件、群发邮件。这个模块的设计难点不在单个功能而在邮件状态的流转和不同身份看到不同邮件的权限控制。写邮件的用例很直接进入邮件管理、点击写邮件、填写内容、点击立即发送。收件箱支持查看、回复、删除、导出、打印五种操作发件箱支持查看、删除、导出、打印、再次发送废件箱支持查看、恢复、永久删除、清空。业务规则里反复出现同一条“不同身份登录看到的邮件不同”。这条规则实现时通常落到邮件表的收件人字段和查询条件上。收件箱查询条件是收件人等于当前用户发件箱查询条件是发件人等于当前用户废件箱查询条件是收件人或发件人等于当前用户且删除标记为真。导出功能通常用 POI 或 EasyExcel 把邮件列表写成 Excel打印功能用浏览器自带的打印接口。// 邮件列表查询的前端参数组装以收件箱为例 function buildInboxQuery(currentUserId, page, size) { return { receiverId: currentUserId, // 收件人等于当前用户 folder: INBOX, // 文件夹标识 deleted: false, // 未删除 page: page, size: size, orderBy: send_time desc // 按发送时间倒序 }; } // 废件箱查询收件人或发件人是当前用户且已标记删除 function buildTrashQuery(currentUserId, page, size) { return { userId: currentUserId, // 收件人或发件人 folder: TRASH, deleted: true, page: page, size: size }; }前端组装查询参数时核心是把当前用户 ID 和文件夹标识传进去后端根据这两个参数拼 SQL 的 where 条件。这样同一套接口可以服务收件箱、发件箱、废件箱三个页面只是参数不同。4. 非功能需求与运行环境设计性能、安全、界面、故障恢复怎么写才不被挑刺4.1 性能需求数据精确度和时间特性的量化写法性能需求这一章很多同学写得很虚比如“系统响应要快”“数据处理要准确”。这份文档给了两个可量化的维度数据精确度和时间特性。数据精确度要写到字段级比如金额保留两位小数、时间精确到秒、百分比保留一位小数。时间特性要写到操作级比如页面加载不超过 3 秒、查询响应不超过 2 秒、批量导出不超过 30 秒。我一般会建议按操作类型分别写普通查询类操作响应时间、复杂统计类操作响应时间、批量导入导出类操作响应时间、页面首次加载时间。每类给一个上限值并说明测试条件比如“在 100 并发用户、数据量 10 万条的条件下”。这样评审时没法挑刺因为你有明确的测试前提。4.2 安全性设计单点登录、权限过滤、数据备份的三层防护运行需求里的安全性部分这份文档提到了单点登录、用户权限设置、数据库备份还原。单点登录明确写了“需要单点登录功能但不使用 AD 或其他 LDAP 系统”条件与限制里也写了“用户不需要且不要使用 LDAP 服务”。这是一个很具体的约束实现时通常用 token 或 session 共享来做不引入外部目录服务。权限过滤分两层功能权限和数据权限。功能权限控制菜单和按钮的可见性数据权限控制查询结果的可见范围。数据权限的实现方式通常是在 SQL 的 where 条件里拼机构 ID 或用户 ID比如销售部门只能看自己管理范围内的数据系统管理员可以看所有机构的数据。数据库备份还原是系统管理员的职责通常做成定时任务加手动触发两种方式。定时任务每天凌晨全量备份手动触发用于重大操作前的临时备份。恢复时要支持按时间点恢复这需要数据库开启日志归档。4.3 界面设计下拉列表优先、操作路径最短、反馈及时界面设计部分这份文档给了一条很实用的原则“能做成下拉列表的选项一定做成下拉列表方便用户”。这条原则看起来简单但落地时能省很多事。客户分类、客户状态、审批结果、邮件文件夹这些字段用下拉列表比用输入框好既减少输入错误又统一数据格式。界面原型清单里列了添加发送短信、查看已接收短信列表、删除已接收短信、查看已发短信列表、删除已发短信列表、查看审批列表、添加审批信息反馈、查看我的申请列表、添加我的申请、删除我的申请、修改未通过的申请、写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、添加事务、日常事务列表、日常事务删除、修改日常事务、添加日常安排、修改日常安排、删除日常安排、客户信息管理。这份清单可以直接当作前端页面的开发任务列表每完成一个勾一个。注意界面原型不要只画主流程异常状态空列表、加载失败、无权限也要画。评审时经常被问“如果查不到数据页面显示什么”。5. 需求分析文档的避坑与常见问题排查5.1 用例描述写成功能列表缺少前置条件和后置条件现象用例描述只有基本事件流没有前置条件、后置条件、业务规则评审时被问“这个操作在什么状态下才能做”答不上来。原因把用例当成了功能说明只写了“用户点击什么、系统返回什么”没有定义操作的上下文。解决每个用例强制写四块——前置条件操作前系统必须处于什么状态、基本事件流正常路径、备选流异常和分支路径、后置条件操作后系统状态如何变化。这份文档在日程安排用例里写了“前置条件已登录到系统平台”“后置条件新增、修改或删除日程信息成功可以通过检索的方式验证”这就是标准写法。5.2 角色权限只写角色名没写数据可见范围现象功能划分表里写了系统管理员、主管、业务员三类角色但没写每类角色能看到哪些数据开发时靠猜测试时靠试。原因把角色当成了功能权限的集合忽略了数据权限。解决在功能划分表里加一列“数据范围”明确写每个角色能看到哪些机构、哪些部门、哪些人的数据。这份文档在业务规则里写了“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”这就是数据权限的具体化。实现时通常落到 SQL 的 where 条件上。5.3 运行环境写得太笼统部署时发现版本不兼容现象运行环境只写了“Windows 操作系统、SQL Server 数据库、Java 环境”部署时发现 JDK 版本不对、应用服务器版本不兼容、数据库驱动缺失。原因运行环境没有写到具体版本号开发和运维各拿各的版本。解决硬件写到型号和配置软件写到版本号。这份文档写了“操作系统Microsoft Windows XP SP2”“数据库软件Microsoft SQL Server 2000”“编译程序JDK 1.5”“应用服务器IBM WebSphere Application Server 6.1”虽然版本较老但写法是对的。实际项目中要写当前使用的版本并注明是否允许向上兼容。5.4 功能优先级标了但没用于排期导致核心功能延期现象功能划分表里标了优先级 5 最高但开发时按模块顺序做做到最后发现优先级 5 的功能还没做完。原因优先级只标了没用排期时没有按优先级排序。解决优先级要落到开发排期上优先级 5 的功能必须在第一轮迭代完成优先级 4 的功能在第二轮完成优先级 3 及以下可以放到后续迭代。这份文档里日程安排、写邮件、收件箱、发件箱、废件箱都是优先级 5客户信息管理也是优先级 5这些就是第一轮必须交付的。5.5 数据概念结构图和业务流程图缺失开发和测试对不上现象功能描述写得很细但没有数据概念结构图和业务流程图开发时表结构设计各写各的测试时流程走不通。原因把需求文档当成了功能说明书忽略了数据模型和流程模型。解决功能描述之后必须补两张图——数据概念结构图实体关系图和业务流程图程序流程图或活动状态图。这份文档在 3.3.2 和 3.3.3 节留了这两块的位置。实体关系图定义表与表之间的关联业务流程图定义操作与操作之间的流转两者缺一不可。6. 需求分析文档的验收与答辩怎么证明这份文档能指导开发验收一份需求分析文档核心看三点完整性、一致性、可执行性。完整性看目录结构是否覆盖引言、任务概述、功能需求、性能需求、运行需求、参考资料六大部分一致性看功能划分表、用例描述、数据概念结构图、业务流程图四者是否对得上可执行性看开发人员能否根据文档直接建表、写接口、做页面。答辩时最常被问的问题有三类。第一类是“这个功能为什么这么设计”比如为什么日程要分日常事务、日日程、周日程、月日程四层回答时要落到使用场景上——业务员每天看日常事务和日日程主管看周日程和月日程来把握团队节奏。第二类是“这个规则怎么落地”比如“销售人员只能对自己的日程做增删改查”回答时要落到实现上——在 SQL 的 where 条件里拼当前用户 ID。第三类是“异常情况怎么处理”比如审批通过后还能不能改回答时要落到业务规则上——审批通过后只能查看不能删除和修改。我一般会建议在答辩前做一次自查用下面这张表逐项核对检查项合格标准常见扣分点用例描述每个用例有前置条件、基本事件流、备选流、后置条件、业务规则只有基本事件流缺前置和后置角色权限每个角色有功能权限和数据权限两层定义只写角色名没写数据可见范围运行环境硬件到型号、软件到版本号只写操作系统和数据库类型功能优先级优先级落到开发排期上标了优先级但没用于排期数据模型有实体关系图表与表关联清晰只有文字描述没有图业务流程有流程图操作流转清晰只有功能列表没有流程从那以后我每次做需求分析文档都会在提交前用这张表走一遍尤其是用例描述的前置条件和后置条件缺一个就补一个。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/19 6:02:39 · 阅读 1.2k CRM需求分析设计文档：角色权限、用例设计与避坑指南
简介这份CRM客户关系管理需求分析设计文档面向企业信息化负责人、产品经理与软件开发团队用于指导企业版CRM系统的需求梳理与落地实施。文档围绕提升销售效率、整合客户信息、增强客户忠诚度等目标系统展开项目背景、用户组织结构、业务流程、业务对象与术语定义并给出任务目标、网络硬件与软件运行环境、条件与限制等约束说明。后续章节深入功能需求、用例描述、数据概念结构图实体—关系图、系统业务流程图及界面原型帮助读者理解信息在系统中的流动路径与交互设计。资源包为1个doc文件约1.66MB结构完整、目录清晰可直接作为需求评审、开发交底与测试用例编写的参考底稿。已有188人学习适合需要撰写CRM需求规格说明书或搭建客户管理系统的读者借鉴。1. 从一份真实需求文档说起CRM客户关系管理需求分析设计文档要解决什么很多同学做 CRM 毕设或课程设计第一反应是打开 IDE 建表写接口结果做到一半发现角色权限理不清、日程和客户关联不上、审批流走不通回头改需求比重新写还痛苦。这份 CRM 客户关系管理需求分析设计文档解决的正是这个前置问题在写第一行代码之前把系统管理员、主管、业务员三类角色的边界、客户信息管理这条主线、以及日程安排、邮件、审批、短信、组织结构这些支撑模块全部定义清楚。它适合正在做 CRM 需求分析毕设的学生、需要交付需求规格说明书的从业者也适合把这份文档当作课程设计模板直接套用的场景。文档本身是一份完整的软件需求规格说明书包含用例描述、数据概念结构图、业务流程图和界面原型清单下面我按方案落地的顺序把它拆开讲。2. 需求分析设计文档的总体结构六大部分与三类角色的职责划分2.1 文档骨架怎么搭从引言到参考资料的六段式一份能直接交给导师或甲方评审的需求分析文档结构上通常遵循固定骨架。这份文档的目录给出了一个很标准的六段式引言、任务概述、功能需求、性能需求、运行需求、参考资料。这个顺序不是随便排的它对应的是评审时的阅读逻辑——先知道为什么做引言再知道做成什么样任务概述然后看具体做什么功能需求接着看做到什么程度性能需求再看跑在什么环境上运行需求最后给出引用来源。我一般会建议把引言拆成四块写编写目的、项目背景、业务对象说明及术语定义、参考资料前置。其中项目背景又要细到用户基本情况、开发目标、用户组织结构、用户相关业务。很多同学写引言只写两句话评审时第一个被问倒的就是“你这个系统到底给谁用、解决他什么痛点”。这份文档在 1.2 节把用户基本情况、开发目标、组织结构、相关业务四块分开写就是为了让评审一眼看到需求来源。任务概述部分的核心是目标和运行环境。目标要写清楚系统定位比如这份文档写的是“为客户关系管理系统的基础模块提供完善的用户管理和授权管理通过标准的 WebService 为其他软件系统提供统一的权限管理服务”。运行环境则要分网络及硬件环境、支持软件环境、其它要求三块硬件要写到服务器型号、CPU、内存、RAID 卡、存储设备这一级软件要写到操作系统版本、数据库版本、JDK 版本、应用服务器版本。这不是炫技而是让后续开发和部署有据可依。2.2 三类角色怎么分系统管理员、主管、业务员的权限边界功能需求这一章最怕写成功能列表。这份文档的做法是先做功能划分再做功能描述最后补数据概念结构图和业务流程图。功能划分里把系统管理员、主管、业务员三类角色的用例编号、名称、优先级、备注列成表这一步非常关键因为它把“谁能在什么条件下做什么”提前锁死了。三类角色的职责边界可以这样理解业务员是数据的生产者负责记录客户信息、写日程、发邮件、提申请主管是数据的审核者和把控者负责审批、指派人员、指派目标、看下属日程来把握客户整体意向系统管理员是规则的维护者负责客户分类管理、数据库操作、用户权限设置、组织结构和人员管理。这份文档在 3.1 节明确写了“销售部门只能对自己管理范围内的系统进行管理”“系统管理员可以在任何机构下创建用户机构管理员可以在自己机构下新建用户”这就是权限边界的具体化。提示角色划分不要只写角色名一定要写到“这个角色能看到哪些数据、能改哪些数据、不能碰哪些数据”。评审时被问最多的就是越权问题。2.3 功能模块怎么切客户信息管理为主线日程、邮件、审批、短信为支撑功能划分表里列了客户信息管理、日程安排、指派员工、指派目标、邮件系统、审批管理、短信管理、组织结构、系统管理九大块。其中客户信息管理是主线贯穿整个项目其他模块都是围绕这条主线做支撑。日程安排关联客户邮件系统服务客户沟通审批管理支撑业务决策短信管理做消息触达组织结构决定数据可见范围系统管理维护基础规则。这种切法的好处是每个模块都能独立开发、独立测试最后通过客户信息这条主线串起来。如果按“增删改查”来切模块做到后面会发现客户、日程、邮件之间的关联关系散落在各处改一处牵动全身。按业务对象切每个模块的边界清晰接口也好定义。3. 核心功能模块的用例设计日程、审批、邮件三条线的落地写法3.1 日程安排模块日常事务、日日程、周日程、月日程的四层结构日程安排模块的用例编号是 CRM1.01优先级 5主要参与者是部门业务员和部门主管。这个模块的设计有个容易被忽略的点它把日程分成了日常事务、日日程、周日程、月日程四层。日常事务是待办清单性质日日程是按天排的计划周日程和月日程是按周和按月维度的视图。四层结构对应的是不同的使用场景——业务员每天看日常事务和日日程主管看周日程和月日程来把握团队节奏。用例的基本事件流写得很细以日日程为例点击“日日程”进入界面点击“新增”弹出窗口填写主题、起始时间、内容、关联客户后保存。其中“关联客户”这个字段是日程模块和客户信息管理主线的连接点没有这个字段日程就只是一个独立的日历工具和 CRM 没关系了。备选流覆盖了查询、修改、删除三种操作。查询是点击相应日期显示当天日程修改是点击日程条目弹出窗体修改后保存删除是点击条目后点删除。业务规则里明确写了“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”这条规则在实现时通常落到数据层的 where 条件上用当前登录用户 ID 过滤。-- 日程表核心字段设计以日日程为例 CREATE TABLE crm_schedule ( schedule_id BIGINT PRIMARY KEY, -- 日程主键 schedule_type TINYINT NOT NULL, -- 1日常事务 2日日程 3周日程 4月日程 subject VARCHAR(200) NOT NULL, -- 主题 start_time DATETIME NOT NULL, -- 起始时间 content TEXT, -- 日程内容 customer_id BIGINT, -- 关联客户可空 owner_id BIGINT NOT NULL, -- 所属业务员权限过滤依据 create_time DATETIME DEFAULT NOW(), update_time DATETIME DEFAULT NOW(), INDEX idx_owner_time (owner_id, start_time) );这段建表语句里schedule_type用枚举值区分四层日程避免建四张结构一样的表customer_id允许为空因为不是所有日程都关联客户owner_id是权限过滤的关键字段所有查询都要带上它。索引建在owner_id和start_time上因为最高频的查询是“查某个业务员某段时间的日程”。3.2 审批管理模块我的申请与我的审批的双向流程审批管理拆成两个用例CRM1.03 我的审批和 CRM1.04 我的申请。我的审批的主要参与者是销售主管基本事件流是进入审批管理界面、查看审批列表和内容、提交审批结果备选流支持查询审批信息。业务规则明确写了“审批只能选择同意或不同意”后置条件也写死了“审批只能选择同意或不同意”。我的申请的主要参与者是销售人员基本事件流是进入我的申请界面、查看申请列表、删除申请、修改未通过或未审核的申请。业务规则里有两条很关键一是“销售人员的申请只能对销售主管进行申请”二是“销售人员进行审批的必须有选择一个审批人”。特殊需求里还有一条“审批通过后就不能对结果进行删除、修改只能有查看的功能”。这两条规则合起来定义了一个完整的状态机申请提交后处于待审批状态主管审批后变为通过或未通过未通过的可以修改后重新提交通过的只能查看。实现时通常用状态字段加状态流转表来控制。// 审批状态流转的核心校验逻辑 public class ApprovalService { // 允许的状态流转待审批-通过/未通过未通过-待审批修改后重提 private static final MapInteger, ListInteger ALLOWED_TRANSITIONS Map.of( 0, List.of(1, 2), // 待审批 - 通过 / 未通过 2, List.of(0) // 未通过 - 待审批 ); public void updateStatus(Long applyId, Integer targetStatus, Long operatorId) { Apply apply applyMapper.selectById(applyId); // 校验当前操作人是否为指定审批人 if (!apply.getApproverId().equals(operatorId)) { throw new BizException(无权审批该申请); } // 校验状态流转是否合法 ListInteger allowed ALLOWED_TRANSITIONS.get(apply.getStatus()); if (allowed null || !allowed.contains(targetStatus)) { throw new BizException(当前状态不允许该操作); } apply.setStatus(targetStatus); applyMapper.updateById(apply); } }这段代码把业务规则翻译成了可执行的校验先校验操作人是不是指定审批人再校验状态流转是否在允许范围内。ALLOWED_TRANSITIONS这个 Map 就是状态机的定义后续如果要加“撤回”功能只需要在这里加一条流转规则不用改业务逻辑。3.3 邮件系统模块写邮件、收件箱、发件箱、废件箱、查询、账号配置的完整闭环邮件系统是这份文档里用例最多的一块从 CRM1.05 到 CRM1.11 覆盖了写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、删除邮件、群发邮件。这个模块的设计难点不在单个功能而在邮件状态的流转和不同身份看到不同邮件的权限控制。写邮件的用例很直接进入邮件管理、点击写邮件、填写内容、点击立即发送。收件箱支持查看、回复、删除、导出、打印五种操作发件箱支持查看、删除、导出、打印、再次发送废件箱支持查看、恢复、永久删除、清空。业务规则里反复出现同一条“不同身份登录看到的邮件不同”。这条规则实现时通常落到邮件表的收件人字段和查询条件上。收件箱查询条件是收件人等于当前用户发件箱查询条件是发件人等于当前用户废件箱查询条件是收件人或发件人等于当前用户且删除标记为真。导出功能通常用 POI 或 EasyExcel 把邮件列表写成 Excel打印功能用浏览器自带的打印接口。// 邮件列表查询的前端参数组装以收件箱为例 function buildInboxQuery(currentUserId, page, size) { return { receiverId: currentUserId, // 收件人等于当前用户 folder: INBOX, // 文件夹标识 deleted: false, // 未删除 page: page, size: size, orderBy: send_time desc // 按发送时间倒序 }; } // 废件箱查询收件人或发件人是当前用户且已标记删除 function buildTrashQuery(currentUserId, page, size) { return { userId: currentUserId, // 收件人或发件人 folder: TRASH, deleted: true, page: page, size: size }; }前端组装查询参数时核心是把当前用户 ID 和文件夹标识传进去后端根据这两个参数拼 SQL 的 where 条件。这样同一套接口可以服务收件箱、发件箱、废件箱三个页面只是参数不同。4. 非功能需求与运行环境设计性能、安全、界面、故障恢复怎么写才不被挑刺4.1 性能需求数据精确度和时间特性的量化写法性能需求这一章很多同学写得很虚比如“系统响应要快”“数据处理要准确”。这份文档给了两个可量化的维度数据精确度和时间特性。数据精确度要写到字段级比如金额保留两位小数、时间精确到秒、百分比保留一位小数。时间特性要写到操作级比如页面加载不超过 3 秒、查询响应不超过 2 秒、批量导出不超过 30 秒。我一般会建议按操作类型分别写普通查询类操作响应时间、复杂统计类操作响应时间、批量导入导出类操作响应时间、页面首次加载时间。每类给一个上限值并说明测试条件比如“在 100 并发用户、数据量 10 万条的条件下”。这样评审时没法挑刺因为你有明确的测试前提。4.2 安全性设计单点登录、权限过滤、数据备份的三层防护运行需求里的安全性部分这份文档提到了单点登录、用户权限设置、数据库备份还原。单点登录明确写了“需要单点登录功能但不使用 AD 或其他 LDAP 系统”条件与限制里也写了“用户不需要且不要使用 LDAP 服务”。这是一个很具体的约束实现时通常用 token 或 session 共享来做不引入外部目录服务。权限过滤分两层功能权限和数据权限。功能权限控制菜单和按钮的可见性数据权限控制查询结果的可见范围。数据权限的实现方式通常是在 SQL 的 where 条件里拼机构 ID 或用户 ID比如销售部门只能看自己管理范围内的数据系统管理员可以看所有机构的数据。数据库备份还原是系统管理员的职责通常做成定时任务加手动触发两种方式。定时任务每天凌晨全量备份手动触发用于重大操作前的临时备份。恢复时要支持按时间点恢复这需要数据库开启日志归档。4.3 界面设计下拉列表优先、操作路径最短、反馈及时界面设计部分这份文档给了一条很实用的原则“能做成下拉列表的选项一定做成下拉列表方便用户”。这条原则看起来简单但落地时能省很多事。客户分类、客户状态、审批结果、邮件文件夹这些字段用下拉列表比用输入框好既减少输入错误又统一数据格式。界面原型清单里列了添加发送短信、查看已接收短信列表、删除已接收短信、查看已发短信列表、删除已发短信列表、查看审批列表、添加审批信息反馈、查看我的申请列表、添加我的申请、删除我的申请、修改未通过的申请、写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、添加事务、日常事务列表、日常事务删除、修改日常事务、添加日常安排、修改日常安排、删除日常安排、客户信息管理。这份清单可以直接当作前端页面的开发任务列表每完成一个勾一个。注意界面原型不要只画主流程异常状态空列表、加载失败、无权限也要画。评审时经常被问“如果查不到数据页面显示什么”。5. 需求分析文档的避坑与常见问题排查5.1 用例描述写成功能列表缺少前置条件和后置条件现象用例描述只有基本事件流没有前置条件、后置条件、业务规则评审时被问“这个操作在什么状态下才能做”答不上来。原因把用例当成了功能说明只写了“用户点击什么、系统返回什么”没有定义操作的上下文。解决每个用例强制写四块——前置条件操作前系统必须处于什么状态、基本事件流正常路径、备选流异常和分支路径、后置条件操作后系统状态如何变化。这份文档在日程安排用例里写了“前置条件已登录到系统平台”“后置条件新增、修改或删除日程信息成功可以通过检索的方式验证”这就是标准写法。5.2 角色权限只写角色名没写数据可见范围现象功能划分表里写了系统管理员、主管、业务员三类角色但没写每类角色能看到哪些数据开发时靠猜测试时靠试。原因把角色当成了功能权限的集合忽略了数据权限。解决在功能划分表里加一列“数据范围”明确写每个角色能看到哪些机构、哪些部门、哪些人的数据。这份文档在业务规则里写了“销售人员只能对自己的日程安排信息进行查询、添加、修改、删除”这就是数据权限的具体化。实现时通常落到 SQL 的 where 条件上。5.3 运行环境写得太笼统部署时发现版本不兼容现象运行环境只写了“Windows 操作系统、SQL Server 数据库、Java 环境”部署时发现 JDK 版本不对、应用服务器版本不兼容、数据库驱动缺失。原因运行环境没有写到具体版本号开发和运维各拿各的版本。解决硬件写到型号和配置软件写到版本号。这份文档写了“操作系统Microsoft Windows XP SP2”“数据库软件Microsoft SQL Server 2000”“编译程序JDK 1.5”“应用服务器IBM WebSphere Application Server 6.1”虽然版本较老但写法是对的。实际项目中要写当前使用的版本并注明是否允许向上兼容。5.4 功能优先级标了但没用于排期导致核心功能延期现象功能划分表里标了优先级 5 最高但开发时按模块顺序做做到最后发现优先级 5 的功能还没做完。原因优先级只标了没用排期时没有按优先级排序。解决优先级要落到开发排期上优先级 5 的功能必须在第一轮迭代完成优先级 4 的功能在第二轮完成优先级 3 及以下可以放到后续迭代。这份文档里日程安排、写邮件、收件箱、发件箱、废件箱都是优先级 5客户信息管理也是优先级 5这些就是第一轮必须交付的。5.5 数据概念结构图和业务流程图缺失开发和测试对不上现象功能描述写得很细但没有数据概念结构图和业务流程图开发时表结构设计各写各的测试时流程走不通。原因把需求文档当成了功能说明书忽略了数据模型和流程模型。解决功能描述之后必须补两张图——数据概念结构图实体关系图和业务流程图程序流程图或活动状态图。这份文档在 3.3.2 和 3.3.3 节留了这两块的位置。实体关系图定义表与表之间的关联业务流程图定义操作与操作之间的流转两者缺一不可。6. 需求分析文档的验收与答辩怎么证明这份文档能指导开发验收一份需求分析文档核心看三点完整性、一致性、可执行性。完整性看目录结构是否覆盖引言、任务概述、功能需求、性能需求、运行需求、参考资料六大部分一致性看功能划分表、用例描述、数据概念结构图、业务流程图四者是否对得上可执行性看开发人员能否根据文档直接建表、写接口、做页面。答辩时最常被问的问题有三类。第一类是“这个功能为什么这么设计”比如为什么日程要分日常事务、日日程、周日程、月日程四层回答时要落到使用场景上——业务员每天看日常事务和日日程主管看周日程和月日程来把握团队节奏。第二类是“这个规则怎么落地”比如“销售人员只能对自己的日程做增删改查”回答时要落到实现上——在 SQL 的 where 条件里拼当前用户 ID。第三类是“异常情况怎么处理”比如审批通过后还能不能改回答时要落到业务规则上——审批通过后只能查看不能删除和修改。我一般会建议在答辩前做一次自查用下面这张表逐项核对检查项合格标准常见扣分点用例描述每个用例有前置条件、基本事件流、备选流、后置条件、业务规则只有基本事件流缺前置和后置角色权限每个角色有功能权限和数据权限两层定义只写角色名没写数据可见范围运行环境硬件到型号、软件到版本号只写操作系统和数据库类型功能优先级优先级落到开发排期上标了优先级但没用于排期数据模型有实体关系图表与表关联清晰只有文字描述没有图业务流程有流程图操作流转清晰只有功能列表没有流程从那以后我每次做需求分析文档都会在提交前用这张表走一遍尤其是用例描述的前置条件和后置条件缺一个就补一个。希望帮到你。本文还有配套的精品资源点击获取