企业官网建设流程全解析

简介：这份CRM客户关系管理需求分析设计文档面向企业信息化项目负责人、需求分析师与开发团队成员，围绕企业级客户关系管理系统的立项与设计展开，重点解决客户信息整合、销售流程自动化与数据分析支撑等需求梳理难题。压缩包内仅含1个doc文件，约1.66MB，是一份结构完整的Word版需求规格说明书，正文按引言、任务概述、功能需求、性能需求等章节推进，涵盖项目背景与用户组织结构、业务对象与术语定义、运行环境与条件限制，以及总体功能划分、用例描述、数据概念结构图（实体—关系图）、系统业务流程图和界面原型预览，可作为需求评审与开发交底的参考底稿。目前已有189人学习下载。需要撰写需求文档或搭建CRM原型的读者，可从中获取章节框架、用例编写规范与业务流程建模思路，减少从零起步的整理成本。

1. 一张被退回三次的用例表：CRM 需求分析文档要解决什么

CRM 需求分析这件事，很多人第一反应是画几张用例图、把功能列成一张清单就交差。我见过一份模拟项目的客户关系管理需求文档，第一版就是这么写的，评审被退回三次，理由很一致：整份文档找不到一句话能回答“业务员能不能看到同事名下的客户”。需求分析的价值不在功能写全，而在把角色、数据范围、状态流转这三件事固定下来。这份 CRM 需求分析设计文档面向的是要在两三周内交出一份能评审、能照着开发的需求规格说明的人——学生拿它当毕设或课设的需求章节骨架，从业者拿它当内部需求基线改。下面按角色建模、功能拆解、数据接口、避坑、验收的顺序走一遍。

2. 需求边界与角色建模：三类角色、七块业务怎么切

大多数 CRM 需求文档出现的主要问题，是从“系统能做什么”开始写，而不是从“谁在什么范围内做什么”开始写。功能清单谁都能列，难的是把权限边界和数据范围写成可以判定真假的句子。这份文档的结构值得借鉴：引言讲编写目的与项目背景，任务概述讲运行环境与条件限制，然后才进入功能需求，功能按用例逐条描述，最后是性能需求与运行需求。这个顺序看着朴素，实际是把“为什么做、在什么条件下做、做到什么程度”排在“做什么”前面，评审时对方顺着读下去不会跳着挑毛病。

在中间层，功能被切成七块：客户信息管理、日程安排、邮件系统、审批管理、短信管理、组织结构、系统管理。切分依据是操作对象，而不是操作人，这样每一块都能独立指派负责人，也方便后面按模块写验收用例。系统管理这块容易被当作杂项随意处理，实际上客户分类、数据库备份还原、用户权限设置三项都在里面，其中权限设置是整个系统的基础，后面所有“只能看自己范围内”的说明都以它为落点。通常的做法是把它单独拆成一章，而不是和其他业务功能混在一起。

2.1 角色与权限矩阵：系统管理员、主管、业务员各自的数据范围

系统只定义三类角色：系统管理员、主管（销售部门与就业部门各一组）、业务员（同样分两个部门）。角色只有三类，但每个角色在每块功能上的“可见范围”和“可写范围”不一样，这是需求文档里最需要写满的一节。我一般会直接给一张矩阵表，任何一行填不出明确答案，就说明这条需求还没想清楚。

这张表要把数据范围理解为三个层级，按由小到大是本人、本部门、全机构，不要只写“只能管理自己范围内的”。我在审核时看到“自己范围内”这四个字，默认判定为未完成，因为它至少可以指三种不同的数据过滤条件：按创建人过滤、按负责人过滤、按部门归属过滤。文档里要明确选哪一种。以客户管理为例，业务员看到的列表按“当前负责人”过滤，主管看到的按“归属部门”过滤，管理员不受限制——这三条必须各写一句，不能合并成一句模糊表述。

还有一条容易遗漏的约束：系统管理员可以在任何机构下创建用户，机构管理员只能在自己机构下新建用户。这属于“跨层级建号”的规则，看着只是一句话，落地时直接决定登录接口要不要带机构参数、用户表要不要冗余机构字段。单点登录也是同理，文档明确写了需要单点登录、但不使用 AD 或其他 LDAP 系统，这句话的价值在于它排除了一个主流方案，开发和评审都不用再反复讨论。

2.2 用例编号与优先级编排：CRM101 到 CRM305 的命名规则

用例编号是需求文档的检索入口，也是后面追溯测试用例的关联依据。这份文档的编号分段有明确规律，按模块划分区间，编号首位表示模块层级，后两位表示顺序：

优先级用 1 到 5 标注，5 最高，这个字段不是装饰。排期紧张时，评审直接按优先级砍范围：优先级 5 的客户管理、指派、审批必须先上，优先级 3 的短信管理可以延到二期。写需求时把优先级填上，等于提前替项目经理做了一次排序决策，评审会上少吵半小时。

每个用例的固定字段我建议照抄这套：用例名称、用例编号、作用域、版本、优先级、主要参与者、涉众、前置条件、触发条件、基本事件流、备选流、后置条件、业务规则、特殊需求。其中“后置条件”经常被写成一个敷衍的“操作成功”，这篇文档写得更好一些：新增、修改或删除日程信息成功，可以通过检索的方式验证。这句话把验收方法直接写进了需求，测试人员不必再自己设计验证路径。

2.3 术语与业务对象定义：把机构、岗位、工作组说成同一件事

术语表是最不起眼、最省事、也最能减少返工的一节。这份文档定义了五个词：用户（销售人员、就业部门人员）、管理员、组织机构、岗位（系统中表示为工作组）、CRM。数量不多，但每一个都能对应到数据库里的一个字段或一张表。

真实项目里出现问题时，往往不是某个词没定义，而是同一个概念在两处用了不同的词。比如“机构”和“部门”在组织结构里是一套层级，在客户归属里又是一套层级，如果需求文档不明确说明客户归属挂在哪一级，开发就会按个人理解建两张不同的表，最后联调时对不上。我通常会在术语表后面补一句话：客户归属到部门，部门归属到机构，客户不直接挂机构。这种句子写起来枯燥，但它是数据模型的基础，省掉这一句后面要花好几天去改。

术语表还有一个不明显的用途：它是需求文档和界面原型的共同语言。文档里列了几十个界面操作，从添加发送短信、查看已接收短信列表、删除已接收短信，到查看审批列表、添加审批信息反馈、修改未通过的申请，再到写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、添加事务、日常事务列表、日常事务删除、修改日常事务、添加日常安排、修改日常安排、删除日常安排、客户信息管理。这些界面名如果和需求里的用例名对不上，验收时没人说得清“修改未通过的申请”到底属于哪个用例。统一命名听起来是小事，实际是文档能否被当成基线用的分界线。

3. 功能需求拆解：从客户信息到邮件审批的模块落地

功能需求这一章最忌讳两种写法，一种是把界面元素逐条转成文字，写成一份说明书；另一种是只写一句“实现客户管理功能”，等于什么都没写。合格的做法是每个模块写到三层：这个模块解决什么业务动作、操作在什么条件下被允许、操作完成后系统里留下什么痕迹。下面四块是这类系统里返工率最高的地方，逐块说明。

3.1 客户信息管理与客户分类：分类树只允许挂叶子节点

客户信息管理是整份文档的重点，原文档直接写了一句：客户信息管理是本系统的重点，贯穿于整个项目。它包含两个动作，一个是客户本身的增删改查，另一个是“指派人员”和“指派目标”，而后两个动作只有主管才能做。这条约束必须在需求里写死，因为它决定了界面上按钮的显隐逻辑，也决定了接口层要不要做二次校验。

客户分类由系统管理员维护，本质上是一棵树。这里有个必须写清楚的规则：客户只能挂在叶子节点上，不允许挂中间节点。原因很实际，如果允许挂中间节点，后面按分类统计客户数时，父节点的数字到底是只算自己还是算上子节点，会成为反复争论的问题。我一般会在需求里补一句：统计按子树汇总，明细按叶子展示。把这两条写下来，开发和测试都不用再猜。

客户表的关键在于支撑数据范围过滤，字段设计要能同时满足“业务员看自己”和“主管看本部门”两个查询，不必在应用层拼字符串：

-- 客户主表：dept_id 与 assign_user_id 两级字段支撑数据范围过滤 CREATE TABLE crm_customer ( customer_id VARCHAR(32) NOT NULL PRIMARY KEY, customer_name NVARCHAR(100) NOT NULL, -- 客户全称，重名时以外部唯一编码兜底 category_id VARCHAR(32) NOT NULL, -- 指向客户分类，只允许叶子节点 dept_id VARCHAR(32) NOT NULL, -- 归属部门，主管按此字段过滤 assign_user_id VARCHAR(32) NOT NULL, -- 当前负责人，业务员按此字段过滤 source NVARCHAR(50), -- 客户来源，用于后续转化统计 status TINYINT NOT NULL DEFAULT 1, -- 1 跟进中 2 已成交 3 已流失 created_at DATETIME NOT NULL DEFAULT GETDATE(), updated_at DATETIME NOT NULL ); -- 复合索引对应最常见的两个列表查询条件 CREATE INDEX idx_customer_scope ON crm_customer(dept_id, assign_user_id);

这段建表语句的重点不在字段多少，而在dept_id和assign_user_id两个字段同时存在。只留负责人字段，主管查本部门要绕道用户表做子查询；只留部门字段，业务员过滤要靠人员列表拼 IN 条件，数据量一大就会拖慢查询。索引顺序也有讲究，dept_id在前是因为主管视图的过滤条件更粗、命中行数更多，把区分度低的列放前面可以减少回表次数。

“指派目标”常被理解成给客户打标签，实际上它指的是主管给业务员设定阶段性跟进目标，和客户本身的字段没有关系。这一点如果需求里含糊带过，开发很容易把它做成客户表上的一个备注字段，最后发现主管要看“本月目标完成率”时数据取不出来。文档里至少要写清：目标是按人、按周期、按数量三个维度记录的，和客户是多对多的关系。

3.2 日程安排：日常事务、日日程、周日程、月日程的边界

日程安排这一块最容易被写成四个功能，实际上只有两类东西。第一类是日常事务，没有具体时间点的事务清单，可以新建、修改、删除、查看，属于“待办事项”性质；第二类是日程，有主题、起始时间、内容和关联客户，按日、周、月三种视图呈现。日日程、周日程、月日程的差别只在展示粒度，底层是同一张表的不同查询方式。这个判断要在需求里说清楚，否则开发很可能照着界面建三张表，最后数据互相同步，成为噩梦。

按原文档的描述，日日程的操作路径是：点击“日日程”进入界面，点击“新增”，弹出窗口，填写主题、起始时间、内容、关联客户，保存。周日程和月日程的路径几乎一致，区别只在入口是日期块。既然基本事件流一模一样，需求就可以合并写一条，再把三种视图的差异放在备选流里说明。文档篇幅省下一半，开发也不会误解成三个独立模块。

“关联客户”字段要不要必填，是个需要给出结论的点。我倾向于设为可空：日程既可以关联具体客户，也可以是内部事务。但一旦关联了客户，客户详情页就要能反查相关日程，这条反向查询是需求里必须写的，很多人只写了正向填写，没写反查，导致客户跟进记录和日程两张表各记各的。

业务规则还有一条：销售人员只能对自己的日程信息进行查询、添加、修改、删除。这条和客户管理的规则性质不同，客户是“看得见别人但不能改”，日程是“连看都看不见”。同样是“数据范围”四个字，落到两个模块上是两种过滤强度，这也是为什么矩阵表要按模块逐行填写。

3.3 邮件与短信：收件箱、发件箱、废件箱的状态流转

邮件模块的界面数量最多，写邮件、收件箱、发件箱、废件箱、查询邮件、邮件账号配置、删除邮件、群发邮件，一共八项。看着繁琐，其实核心只有一个：邮件是有状态的，状态决定它出现在哪个箱子。收件箱、发件箱、废件箱都是同一批数据的“视图”，不必是三个物理位置。

这张表要写进需求文档，而不是留给开发自己定。原因在于“删除”这个词在三个地方含义完全不同：收件箱点删除，是进废件箱；废件箱点删除，是永久删除；清空废件箱，是批量永久删除。如果文档只写“支持删除邮件”，验收时根本判定不了行为是否正确。

-- 邮件表：用 status 表达草稿、正常、废件箱、彻底删除四种状态 CREATE TABLE crm_mail ( mail_id VARCHAR(32) NOT NULL PRIMARY KEY, owner_id VARCHAR(32) NOT NULL, -- 邮件归属人，收件箱与发件箱都按此过滤 direction TINYINT NOT NULL, -- 1 收件 2 发件 subject NVARCHAR(200) NOT NULL, body NVARCHAR(MAX), status TINYINT NOT NULL, -- 0 草稿 1 正常 2 废件箱 3 彻底删除 sent_at DATETIME, CONSTRAINT ck_mail_status CHECK (status IN (0,1,2,3)) ); -- 列表查询按归属人加状态走，避免全表扫描 CREATE INDEX idx_mail_owner_status ON crm_mail(owner_id, status);

owner_id这个字段的设计比状态更关键。业务规则里写了“不同身份登录看到的邮件不同”，如果邮件表只有收件人和发件人两个字段，业务员登录后查收件箱是to_user = me，主管查发件箱是from_user = me，两套查询条件散落在各处，一旦要加“本部门共享邮件”就会全部推倒。把归属人独立出来，视图查询统一成按owner_id加status过滤，扩展时只改数据写入逻辑。

邮件账号配置这一项要单独提醒一句：它涉及外部邮箱凭据的存储。需求文档里要写明凭据不可明文保存、界面上不回显完整密码、修改时留空表示不修改。这三条现在看是常识，当年很多文档里就是一个“配置邮箱账号”的输入框，后面出了安全问题才发现需求阶段没约束。

短信模块相对简单，发送短信、查看已接收和已发送列表、删除短信，三个动作。要注意的是短信和邮件在“群发”上的差别：邮件群发可以按客户分组选择，短信群发通常有运营商侧的条数限制，需求里要给出单次发送上限，否则上线当天就会被业务方一次性勾选上千个号码。

3.4 审批与申请：一条不可逆的状态链

审批管理只有两个用例，“我的审批”和“我的申请”，但业务规则密度最高。基本流程是业务员提交申请，主管审批，审批结果只有两种：同意或不同意。规则有四条必须写明：申请必须选择审批人；申请的主题和内容不能为空；审批通过后不能删除和修改，只能查看；申请只能提交给自己的主管，不能跨部门。

第二条里有个细节，原文档写的是“要输入主题，不有申请内容。要验证不两样不能为空的”，意思就是两个字段都不能为空。这类表述在原始文档里很常见，抄的时候不要照抄病句，要转成明确的校验规则：主题与内容均为必填，长度上限分别是 100 和 2000 字符，前端做非空校验，接口层二次校验。

“通过后不可修改”这条是整个审批模块最容易被违反的规则。我见过不止一个项目，界面上灰掉了编辑按钮，但接口没拦，改个请求参数照样能改。需求里应该把这条写成两条：界面层不提供入口，服务层拒绝状态非法的写操作。状态链就三个值：待审批、已通过、已驳回。驳回的申请允许修改后重新提交，通过的不允许任何写操作。

还有一个高频遗漏点：删除未通过的申请，这个操作到底是从列表里消失，还是保留一条“已撤销”记录。我建议保留记录并把状态改为已撤销，理由是审批本身要留痕，业务员删除申请如果物理删除了，主管那边的审批记录就对不上了。这类判断在需求文档里写一句，能省掉后面一次数据库改动。

4. 数据与接口设计：实体关系、核心表与 WebService 权限契约

需求文档里要不要有数据设计，取决于它交付给谁。这份文档的定位是“需求规格说明书”，但真正被开发拿去用的部分，恰恰是数据概念结构图和业务流程图。我的做法是保留实体关系描述和核心表的关键字段，不写完整物理设计，既够开发建表，又不会因为字段微调反复改文档。

4.1 实体—关系梳理：十张表撑起七个模块

把七块业务功能拆成实体，核心表不超过十张：客户、客户分类、用户、部门、日程、日常事务、邮件、短信、申请、审批记录。关系上，客户挂分类和部门，用户挂部门，日程和事务挂用户、可挂客户，邮件和短信挂用户，申请挂申请人、审批人。

其中两处关系要特意标注。第一处是客户与用户的多对多：客户有当前负责人，但历史上可能换过负责人，所以需要一张指派记录表来保存变更历史，否则主管问“这个客户上个月谁在跟”时无法回答。第二处是申请与审批记录的一对多：一次申请可能有多轮审批，虽然当前版本只支持单级审批，但表结构上留出轮次字段，后续加多级审批不用改表。

4.2 统一权限 WebService 与单点登录的接口契约

原文档明确写了：通过标准的 WebService 为其他软件系统提供统一的权限管理服务，并且需要单点登录功能，但不使用 AD 或其他 LDAP 系统。这条约束意味着权限校验必须做成一个独立服务，由业务系统调用，不能把权限判断散落在每个业务接口里。

接口设计的关键是返回什么。很多权限接口只返回 true 或 false，业务层拿到 true 还要自己再拼一次数据范围过滤条件，等于把权限逻辑写了两遍。正确的做法是权限接口同时返回数据范围档位：

// 权限校验请求：会话票据 + 资源码 + 调用上下文 { "token": "ST-9f2c41a8", // 单点登录后签发，服务端不落明文 "resource": "crm.customer.list", // 资源码，与权限点一一对应 "action": "read", "context": { "orgId": "ORG-01", // 机构，管理员建号时决定 "deptId": "D-07", // 部门，主管视图的过滤依据 "userId": "U-1024" // 当前登录人 } }

// 校验响应：allowed 决定能不能进，dataScope 决定能看多少 { "code": 0, "data": { "allowed": true, "dataScope": "SELF", // ALL 全机构 / DEPT 本部门 / SELF 本人 "expireAt": "2025-06-01T10:30:00+08:00" }, "message": "ok" }

dataScope这一项是整个接口的核心。业务层拿到SELF就在查询里加上负责人条件，拿到DEPT就加上部门条件，拿到ALL则不加条件，三档对应三条固定分支，不写任何动态拼接。expireAt用于前端判断票据是否临近过期，避免用户在填表单填到一半被踢回登录页。

单点登录在不使用外部目录服务的前提下，通常的做法是自建票据中心：登录成功后签发一张短期票据，票据只存在服务端缓存里，客户端每次携带票据访问，权限服务按票据取上下文。这里有个需要注意却容易遗漏的地方：票据超时时间要写进需求，通常设为 30 分钟无操作失效，且要支持续期。不写这一条，不同开发会给出从 10 分钟到 8 小时不等的实现，测试无法判定哪个是正确行为。

另外，“能做成下拉列表的选项一定做成下拉列表”这条要求看着像界面偏好，实际对接口有影响。下拉列表的数据必须有统一来源，通常是一个字典接口，按字典类型返回有序键值对。如果前端各自硬编码选项，后面客户分类一调整，全系统都要改。

4.3 非功能需求怎么写才验收得了

性能需求这一章最容易被敷衍成“响应速度快”“界面友好”。这类句子在验收时无法判定，等于没写。可判定的写法是给区间和条件：数据精确度上，金额保留两位小数、时间精确到秒；时间特性上，常规列表查询在 1 万条数据量下 3 秒内返回，导出 Excel 单次不超过 1 万条且 30 秒内完成；适应性上，页面在 1024×768 及以上分辨率正常显示，主流浏览器内核下布局不错乱。

安全性方面至少写三条：用户密码不可逆加密存储；邮件账号凭据加密存储且界面不回显；关键操作记入日志，包含操作人、时间、对象和结果。故障处理与恢复要给两个数字：数据库每日全量备份，故障后恢复时间不超过 4 小时，数据丢失窗口不超过 24 小时。这两个数字比“保证数据安全”有用得多，它们是运维验收时的唯一依据。

运行环境这一节，原始文档写的是当年的基线：2U 机架式双路服务器、光纤存储柜加 SAN 交换机、JDK 1.5、SQL Server 2000、WebSphere 6.1、Windows XP SP2 客户端。照抄需要谨慎，我的建议是写能力不写型号：应用服务器 2 台（可双机热备）、数据库服务器 1 台、存储容量按三年数据增量估算、客户端支持主流浏览器。写能力的好处是采购和迁移都不受约束，写死型号的结果往往是项目上线时发现某个版本已经停止维护，环境搭不起来。

5. 避坑与常见问题：需求文档里最容易误导开发的五个地方

5.1 编号与命名类的坑

现象：同一份文档里，日程安排的编号在功能划分表里是 CRM101，在用例描述里写成 CRM1.01；我的审批在功能表里是 CRM114，到了用例章节标题写成 CRM015；写邮件在功能表里是 CRM107，用例里是 CRM04。评审时有人按编号检索，找出三处对不上的地方，整份文档的可信度直接下降。

原因：文档由多人分章节撰写，编号规则只在开头提了一句，没有人在合并时统一校对。这类问题在多人协作的需求文档里几乎必然出现。

解决：把编号规则写成一条硬约束——一级模块两位、二级用例两位，全篇只用一种格式，合并稿时用文本检索逐个核对。更省事的办法是先在功能划分表里把全部编号定稿，用例章节只允许引用，不允许新造编号。

5.2 数据范围描述模糊的坑

现象：需求里写“销售部门只能对自己管理范围内的系统进行管理”，开发按创建人过滤，测试按负责人验证，双方各说各话，最后发现主管看不到本部门任何客户。

原因：“管理范围”是一个业务词，不是一个数据条件。文档没有把它落到具体字段上，等于把判断权交给了实现者。

解决：每个涉及数据范围的模块都补一句可执行的描述，例如“客户列表按当前负责人过滤；主管视图按归属部门过滤；管理员不过滤”。三档写成三句，不合并。

5.3 状态与操作语义不清的坑

现象：邮件删除、申请删除、日程删除三处都叫“删除”，行为完全不同。邮件删除进废件箱，申请删除是撤销，日程删除是直接消失。测试人员按同一套理解去验证，必然有两条判为缺陷。

原因：需求只描述了操作入口，没描述操作后果。界面上的按钮文字相同，掩盖了底层状态机的差异。

解决：凡是带状态的对象，都在需求里给一张状态表和一张操作—状态迁移表。状态值不超过五个的时候，一张表就能说清，成本极低。

5.4 非功能需求不可测的坑

现象：性能需求一栏写着“系统响应及时”“界面操作流畅”，验收阶段无法判定是否达标，最后靠演示时“看着挺快”过关。等到真实数据量上来，列表页转圈十几秒，没人能说这是不是缺陷。

原因：非功能需求没有量化，也没有测试条件。写的人觉得反正测不了，读的人也默认跳过。

解决：每条非功能需求都带三个要素——数据量、操作、时限。比如“1 万条客户数据下，按部门筛选的列表页 3 秒内返回首屏”。写不出这三个要素的条目，直接删掉，不要留在文档里充数。

5.5 界面细节被当成需求、业务规则被漏掉的坑

现象：文档里花了三十多页描述每个界面的按钮位置和弹窗文案，但“审批通过后不可修改”“申请必须选择审批人”“客户只能挂分类叶子节点”这些决定系统行为的规则，散落在用例的注释里，甚至没写。

原因：写文档的人把界面原型当成了需求本身。原型能表达“长什么样”，表达不了“什么条件下允许做”。

解决：每个用例固定一个“业务规则”字段，强制填写，填不出就说明这个用例还没想清楚。界面描述可以精简到一句话加一张原型索引，把篇幅让给规则。我一般会要求业务规则至少写三条，少于三条的用例重新过一遍。

6. 验收与答辩：用一张追溯矩阵把文档变成可交付物

需求文档的验收不是“读一遍觉得没问题”，而是能被逐条追溯。我通常会用一张矩阵表把四样东西串起来：需求编号、用例名称、界面原型编号、测试用例编号。矩阵里任何一行有空列，就说明这条需求要么没设计、要么没实现、要么没验证。

答辩或评审时，讲述顺序建议固定为三段：先讲角色与数据范围，用矩阵表说明谁能看什么；再讲状态机，用邮件和申请两个例子说明什么操作会把对象推到哪个状态；最后讲非功能指标，给出三个带数据量的时限数字。这个顺序的好处是评审人最容易挑毛病的前两段先讲透，后面基本不会被打断。反过来，如果开场先讲技术栈和框架选型，评审人的注意力会全部跑到“为什么用这个不用那个”上，业务规则反而没人听。

有个细节值得单独说：答辩时不要照着文档逐页念。挑三个用例现场走一遍事件流，比念二十页目录有效得多。选日常事务（流程最短）、我的申请（状态链最长）、客户管理（权限规则最多），三个用例覆盖了简单流程、状态流转、数据范围三类问题，评委想挑刺也有地方下嘴，你能答上来，基本就过了。

讲个我自己的教训。早年交一份需求文档，功能写得满满当当，评审前一天晚上才想起来补非功能章节，随手写了“系统应具备良好的性能和安全性”。第二天被问“良好是多好”，当场答不上来，整场评审从技术讨论变成了态度质疑。从那以后我每次交文档前，都强制走一遍“随便挑三条需求，问自己怎么证明它做到了”的自检，答不上来的条目当场改写成可测的句子。希望帮到你。

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