简介这是一份可直接使用的中文产品需求文档(PRD)模板适合产品经理、项目管理者与软件开发团队在需求调研、方案评审及项目启动阶段高效搭建文档骨架。模板清晰规划了从项目总体说明到功能范围、用户范围、词汇表、非功能需求等关键章节并专设UC用例部分内置“用户可以在网上退票”等示例演示编号、名称、使用角色、优先级和操作描述的标准写法帮助读者快速理解PRD的模块结构与撰写要点。文件为单个docx文档压缩包仅463KB轻量易用兼容主流Office与WPS。目前已有1464人学习下载模板基于常用企业PRD编写规范整理适合需要统一团队文档格式或快速产出规范需求文档的读者。1. 产品需求文档模板怎么用从 12306 退票用例说起一份 PRD 写得好不好不看它写了多少页看它的用例能不能直接交给开发排期、交给测试写用例。手里这份模板来自 12306 中国铁路客户服务中心的真实需求文档目录从总体说明一路铺到 UC 正文还附了一份班级事务管理系统的需求说明书当示例。它的价值不在于封面多漂亮而在于把修订历史、功能范围、用户范围、用例描述这些最容易被写空的条目全部用真实字段填好了。产品经理可以拿它当骨架需求分析师可以拿它当检查清单后端和前端工程师在评审前翻一遍能提前堵住大部分“需求没说清”的争议。模板能解决的核心问题就一个让需求从口头共识变成字段级可验收。2. 总体说明七个子项修订历史、功能范围、用户范围怎么填才不被追问2.1 修订历史四列模型里“说明”列才是灵魂模板的 1.1 修订历史给的是一个四列表格日期、版本、说明、作者。很多团队做修订历史只认真填前三列说明列写“修改”两个字就完事结果评审时被问“这次改了什么、为什么改”翻遍文档找不出依据。模板里这一行示范值得注意2015.10.08V0.1112306 中国铁路客户服务中心部分功能修改石进珍。“部分功能修改”其实还是有点笼统换作我来写会拆得更细比如“修改退票用例增加已支付订单状态校验”。修订历史的真正用途不是记账是给后来人留后悔药——三个月后有人问“这个字段当时为什么删掉”翻修订历史就一目了然。这里的版本号用 V0.11 而不是 V1.0说明文档还在评审修订期0.x 版本阶段每次改动都要留痕定稿才升 1.0。要让这个表真正起作用我一般会给自己定三条规则。第一每次评审后当天更新不让版本号跨周跨周的修订历史等于没写。第二说明列必须写“改了什么 为什么改”禁止单独出现“修改”“更新”这类词写不出理由的改动说明你自己也没想清楚。第三作者列写实际改文档的人不写部门名方便回溯时直接找人确认上下文。这三条规则比任何模板都值钱模板只负责给表格框架填法才是决定文档质量的部分。2.2 项目概述写给前端和视觉看的文档不写公司愿景模板 1.2 项目概述这段值得细看。它明确写了“本文档主要读者为技术部门的前端工程师以及视觉部门的视觉设计师”然后接着定义“文档的目的主要是清晰、有层次地定义页面原型中各个模块的内容来源和相关逻辑”。请注意这段话的落点读者是谁、文档要产出什么两句话就说完了。模板还补了一段背景说明提到互联网深入生活、传统购票形式不能满足需求但这段没有无限展开写完就收住。很多项目的概述写成了产品宣传稿从行业趋势写到公司战略三千字过去还没有出现一个模块名。正确做法是第一段交代背景第二段直接写读者对象和文档边界。工程师读概述只想确认两件事——这份文档和我有没有关系、我应该从哪一节读起。模板里这段的结构可以照抄背景说明加读者对象加文档范围三段各一两句别超过半页。多出来的篇幅留给功能范围和 UC 正文那才是真正消耗评审时间的地方。2.3 功能范围功能点加优先级和后面的 UC 对得上模板 1.3 功能范围给了三样东西总体流程图、功能模块优先级表、以及车次站点管理的职责描述。优先级表只有三列——功能模块、主要功能点、优先级却把 12306 首批需求分成了七个功能点登录验证高、管理员车次管理高、普通用户车票与个人信息管理高、网站相关资讯介绍低、列车时刻表查询中、票价查询中、余票查询高。这七个功能点的优先级划分有明显逻辑登录验证是入口没有它后面全是空谈余票查询直接决定用户能不能买到票所以标高时刻表和票价查询只是辅助决策信息标中网站资讯介绍不涉及交易标低。优先级的价值在于告诉开发和测试先做什么、后做什么也让产品经理自己心里有数——资源不够时先砍掉“低”而不是砍掉“高”再跟业务方解释。这里有个关键动作功能范围表不是写完就完它是 UC 部分的索引。“管理员实现车票和车次管理”标了高UC 正文里就必须有对应的管理员用例“余票查询”标了高UC 里就应该有查询用例。如果功能范围里有“高”但在 UC 部分找不到对应用例文档内部已经矛盾了这个问题我在第 4 章展开讲。2.4 用户范围与词汇表五类角色一次说清1.4 用户范围把角色分了五类普通用户、游客、管理员、审核员、合作方。普通用户拥有网上购票权限需要注册登录游客只能浏览和查询车次车票信息无购票权限管理员拥有全部权限负责维护车次和车票信息审核员审核乘客信息合作方是网上购票支付方式的支持者。这个划分比“用户/管理员”两分法实用得多原因是它把审核员和合作方单列了出来。审核员在大多数系统里容易被塞进管理员角色但审核和管理权限边界完全不同管理员能改车次、能删票审核员只能核验乘客信息两者混在一起很容易出现越权操作。合作方代表支付渠道它和业务系统的交互方式是接口对接不是页面操作单列出来以后UC 里的“使用角色”字段才不会写乱。词汇表部分模板只留了一行“术语与缩写的描述”当作说明没有填实际内容。我的建议是只收录项目内部会用的缩写比如 UC、PRD 这类通用词不必收录否则词汇表会膨胀成没人翻的字典。词汇表更重要的是统一叫法有人写“退票”有人写“改签”文档里必须二选一并在词汇表里说明这能省掉后期大量沟通成本。3. UC 正文把网上退票拆成九个可验收字段3.1 UC 模板的九个字段编号到其他说明逐个过UC 部分是全篇最有参考价值的地方。模板对单个 UC 定义了九个字段编号、名称、使用角色、优先级、描述、前置条件、后置条件、界面、规则描述与其他说明。这九个字段不是随便列的它们覆盖了一个业务需求从“是谁在什么状态下做什么事”到“做完之后系统变成什么状态”的完整链路。我习惯先把这九个字段翻译成一份 YAML 结构方便评审会上逐项对照也让开发可以直接把字段名映射到测试用例的标题UC-1: 编号: UC-1 名称: 用户可以在网上退票 使用角色: 用户 优先级: 高 描述: - 1. 用户登录个人账号进入我的12306 - 2. 点击已完成订单改/退 - 3. 选择要退的火车票点击退票 - 4. 确认退票操作成功 前置条件: 用户有已完成订单并进入已完成订单界面 后置条件: 查看订单详情即可看到退票后的新状态 界面: 待补充原型编号 规则描述: 待补充 其他说明: 待补充这段 YAML 的意义在于把 Word 表格里散落的字段压缩成一份开发可以直接参照的结构。编号用 UC-N 的形式N 不允许重复这是文档内部引用和测试用例追溯的依据名称必须是用户能理解的业务动作“用户可以在网上退票”这种句式比“退票功能”更规范因为它把主语和对象说全了优先级写高、中、低三档它直接决定迭代排期和测试用例的覆盖深度——高优先级的用例测试用例要覆盖异常流低优先级可以只保基本流。3.2 描述怎么写用户视角的动作序列不是实现方案模板里 UC-1 的描述只有三个步骤登录进入已完成订单界面、选择车票点击退票、确认成功。注意这里没写“调用退票接口”“更新订单状态”这类实现语言它站在用户视角描述做什么把怎么做留给后面的规则描述和界面原型。我见过不少 PRD 把描述写成了技术方案比如“点击退票按钮后前端调 /api/refund后端校验订单状态后返回”。这种写法有两个问题。一是技术实现随时会变今天用接口明天可能换成消息队列文档就得跟着改二是开发看到这种描述会认为需求已经定型反而放弃追问业务规则。描述部分正确的粒度是让测试能照着写出操作步骤让开发能判断功能边界但不需要指导具体实现。“点击已完成订单改/退”这句就有明确边界用户进入了改签和退票的入口具体点哪个按钮由界面原型决定。模板里描述下面还有“界面”“规则描述”“其他说明”三个字段。界面留给原型图编号规则描述放业务约束其他说明放例外情况。这三个字段宁可留空也不要塞无关内容留空说明这部分还需要评审时确认塞了内容反而会让开发分不清哪个是最终结论。3.3 前置条件与后置条件状态前后要能验证前置条件写的是“用户有已完成订单进入已完成订单界面”后置条件写的是“查看订单详情即可选择退票”。前后条件是一对状态断言作用是让测试知道用例从哪个状态开始、在哪个状态结束。这里常见的错误是把前置条件写成操作步骤比如“用户点击退票按钮”——那是描述里的内容不是前置条件。判断标准很简单前置条件必须能用一条查询或一次页面跳转来验证比如“用户处于已登录状态”“订单状态为已支付”。如果一条前置条件需要用三步操作才能验证它就该被挪到描述里去。后置条件的写法也有讲究。模板写的是“查看订单详情即可选择退票”这表示退票操作完成后订单状态发生了变化用户可以再次基于新状态做后续操作。如果后置条件写的是“退票成功”测试就没法判断系统到底处于什么状态——是弹窗提示成功还是订单列表刷新还是收到了短信通知。后置条件应该描述成系统可观察的状态变化而不是用户的主观感受。4. 避坑清单模板往项目里套的五个翻车现场4.1 翻车一修订历史只记版本不记原因现象文档发出去评审开发指着新版功能范围问“为什么余票查询变成高了上一版还是中”你翻修订历史只看到一行“V0.12 修改功能范围”给不出理由场面直接尴尬。原因修订说明列没写改动动机版本记录成了流水账。模板 1.1 里那行“12306 部分功能修改”就是典型——知道改了“部分功能”但改了哪些、为什么改全靠猜。解决把说明列从一句改成两句格式固定为“改动点 改动原因”比如“余票查询由中调高高峰期查票失败占客诉 60%”。从那以后我每次评审完都在当场更新修订历史不让版本号过夜隔夜就忘忘了就再也补不回来。4.2 翻车二功能范围写了高优先级UC 部分找不到对应用例现象功能范围表里“管理员实现车票和车次管理”标了高但 UC 正文里从头到尾只有 UC-1 网上退票管理员相关的用例一个都没有。评审时问“管理员怎么管理车次”产品经理解释“这块后面补”开发和测试面面相觑。原因功能范围是产品经理凭模块清单列的UC 是按开发排期零散补的两者各写各的互相不对齐。功能范围表只写了“有什么”UC 部分没回答“怎么用”。解决把功能范围表当成 UC 的索引每个功能点后面标注对应的 UC 编号。评审前检查一遍凡是高优先级的功能点必须至少有一个 UC 支撑找不到就说明需求还没想清楚宁可不写也不能挂着。这一步做完文档内部的矛盾基本能被消灭干净。4.3 翻车三前置条件写成了操作步骤现象测试拿到的用例是“用户登录账号点击我的订单进入已完成订单页面”这三步被写在了前置条件里描述里反而只有一个“点击退票”。测试按前置条件操作完发现还没到退票入口用例根本没法执行。原因模板里“描述”和“前置条件”没有严格区分写的人把用户到达该页面之前的完整路径都塞进了前置条件以为前置条件就是“操作前要做的事”。解决前置条件是系统状态描述是用户动作。“用户已完成一笔订单且该订单状态为已支付”是前置条件“点击退票并确认”是描述。发现前置条件里出现“点击”“进入”这类动词停下来把动作挪到描述里去。状态描述用名词和形容词动作描述用动词开头这条规则基本不会错。4.4 翻车四UC 编号和标题错位Word 重排后没人发现现象模板里 2.2.1 的标题是“UC_用户可以在网上退票”编号却出现在 2.2.2 里正文才写着“编号 UC-1”。这个错位在模板里就存在复制到新项目时如果不改整份文档的引用关系就乱了。原因Word 里重排章节后没有同步更新编号或者复制模板时漏改了小节序号。文档越长这种错位越隐蔽肉眼很难发现。解决文档定稿前做一次全量搜索把“UC-”后跟的所有数字列出来确认没有跳号、没有重号。如果项目大我一般把 UC 清单单独提到一张表里每个用例的编号直接写在标题上正文只描述内容彻底避免段落序号和用例编号两套体系互相污染。4.5 翻车五非功能需求写成口号性能指标全靠玄学现象模板 1.6 里写着“前端用户购票体验需要滚动流畅”“页面布局合理可任意缩放到合适比例”评审会上问开发“滚动流畅是什么标准”没人能回答最后全按默认实现糊弄过去。原因非功能需求没有量化。性能、安全、体验这些指标如果不给数字开发和测试没有验收依据后期出了问题也没有追溯凭据。解决把每一条改成可测量的描述。“滚动流畅”改成“订单列表页在主流安卓机型的滚动帧率不低于 55fps”“自动刷新数据”改成“余票查询结果每 30 秒自动刷新一次刷新时页面不阻塞”。模板里已有的句子可以当作方向提示但不能直接交付。非功能需求部分写得越具体测试用例就越容易写上线前的性能压测也有对标基准。5. 用例描述写厚从综合测评看基本流、业务规则和异常流5.1 三层步骤基本活动、可选活动、例外活动附录这份班级事务系统需求说明书的最大亮点是把每个用例的场景拆成了三层基本活动步骤、可选活动步骤、例外活动步骤。这三层对应的是用户最常走的路径、偶尔走的路径、以及出错后的路径。模板里 UC-1 只写了基本流登录、选择、退票、确认各一步比较薄附录把三层都展开了厚度完全不一样。基本流是功能能成立的最小步骤集。综合测评用例的基本流有三段录入期末成绩、计算学分、提交审核。可选活动步骤处理的是分支比如活动加分项需要班委根据学生提交的证明材料在系统中登记这就是基本流之外的分支它不影响主路径但不可或缺。例外活动步骤处理的是异常比如检查期内学生对成绩有疑问需要“匿名交由审批教师处理”——这是正常流程之外的特殊通道如果不写开发大概率会漏做匿名投诉这个入口。三层步骤写清楚以后开发和测试的分工就明确了开发按基本流搭主框架再按可选流补分支最后按例外流处理异常测试按三层各写一组用例基本流保证主功能不挂可选流保证分支不丢例外流保证异常不出事故。5.2 综合测评用例怎么拆录入、计算、审核三段综合测评用例的业务规则写得很具体“期末考试总成绩×70% 学分总数×30% 综合测评成绩”。而学分总数又拆成四项学期每天出勤 4 分、上课全到 15 分、期末考试全过 12 分、各项活动加分按《大学生手册》规定。这个公式直接放在“约束业务规则”字段里没有埋在描述段落中测试可以对着公式一条条写校验用例。这个拆法有三点值得抄。第一公式先落在约束字段不在描述里展开描述只写“录入期末总成绩”这个动作公式变了只改约束字段不影响用例结构。第二“录入期末成绩”这一步特别写了“将原有的成绩系统中的学生成绩保存为文档模式例如 xls本系统将识别文档录入学生成绩”——这说明是批量导入不是手工录入开发看到这句就知道要先规划 Excel 解析模块测试也知道要准备批量导入的测试数据。第三“提交审核”之后给了“2 天期限”的监督窗口并说明学生可以匿名提交疑问、教师作出鉴定后审批通过这给开发划出了倒计时任务和匿名信息处理的边界。把“完成综合素质评审”这一句话扩成录入、计算、审核三段再给每段配上约束公式和异常处理用例的可验收程度完全不同。测试能直接数出要写多少条用例公式校验至少三组正常、边界、超范围导入校验至少两组格式正确、格式错误审核流程至少两组有质疑、无质疑。5.3 业务规则的写法差异请假、班费、考勤三组对照附录里的请假审批、班费收支统计、考勤记录三个用例业务规则的写法各有侧重放在一起看正好是三套范式我整理了一张对照表用例关键业务规则写法特点请假审批申请时间到假期结束期间不允许第二次请假假条未通过可自行修改已通过可提续假用状态机约束用户行为把“改、续、禁”三种情况说全班费收支统计系统自动进行财务统计生成消费记录并公示强调流程闭环支出必须先有单据再录入考勤记录旷课 10 次自动提醒“该生旷课 10 次请注意学生状态”给出具体阈值和触发动作可直接写测试断言请假审批这条规则尤其值得细读。“请假条提交后在申请时间到假期结束时间段内不允许第二次提出请假申请”这句话用了一个时间区间加一个禁止动作把系统互斥约束明确下来。如果文档没有这条开发大概率会做成允许重复提交测试也想不到去验证这个场景。后面又补了“假条未通过前可自行修改已通过后可提出续假申请”这就是状态机的三个分支待审批可改、已通过不可改但可续、请假期间不可再请。一条规则把三种状态全约束住了。考勤记录的规则写法是另一类范式“旷课 10 次自动提醒‘该生旷课 10 次请注意学生状态’”这里的 10 是阈值提醒文案是触发动作。测试拿到这条规则可以直接写出一条断言用例模拟 9 次旷课不触发第 10 次必触发。业务规则写到这个粒度开发和测试都不会有歧义。班费收支统计的规则强调闭环收入向学生收取支出必须“索取本次消费单据根据单据录入电子单据系统自动进行财务统计生成消费记录”。这个写法把业务合规要求变成了系统流程约束——没有单据就不能录入支出避免了手工记账的随意性。三组对照下来规律很明显业务规则写得越具体边界越清晰后面的开发和测试就越省事。6. 模板不躺灰的三个习惯回填、对照、反推模板拿到手关键在用。我自己常用的方法有三个。第一个是回填先按“订单列表→退票入口→确认弹窗”这样的顺序把界面流程画成草图根据画出来的页面把用户要做的动作逐一记下来再回填到 UC 模板里而不是先写 UC 再画页面。界面流程草图是很好的组织工具画的过程会逼你把页面状态想清楚状态清楚之后前置条件和后置条件就自然对位了。我以前是先写文档再画图结果经常出现文档里写的页面和原型对不上返回去改文档反而更费时间。第二个是对照原始模板里从 12306 退票到班级事务系统的完整示例是很好的参照物。换项目时我会复制一份留存只改字段值不动结构写完拿两个版本对照检查有没有漏改的地方。特别是用户范围里的角色名称最容易漏改——模板里写着普通用户、管理员新项目可能叫学生、教师我见过不止一次因为忘了替换角色名导致需求文档里残留旧项目角色的情况。但交付之前务必把示例删干净模板里那些 12306 特有的字段比如“已完成订单改/退”如果不删开发会以为新项目也要做改签。第三个是反推先从评审日期反推写文档的节点。评审前一周要冻结功能范围评审前三天完成用例初稿评审前两个工作日做内部自查。没有这个时间轴PRD 永远是评审前一天才开始动工一赶工就漏字段一漏字段评审就翻车。我自己吃过这个亏那次通宵写完直接发评审结果前置条件和描述混在一起被开发当场指出来从那以后我再也不干这种事了。这三条做完以后我养成了一个比较固定的习惯每次把模板发给开发之前强制自己走一遍自查流程——修订历史有没有写清楚改动原因、功能范围里高优先级的功能点有没有对应 UC、前置条件里有没有混入操作步骤、示例内容有没有删干净。四步走完才会把文档发出去。从那以后需求评审会上“这个字段为什么要存在”的追问就慢慢少了。希望帮到你。本文还有配套的精品资源点击获取
