PRD 文档书写的知识点序号主题 讨论点 说明1需求规格说明书定义：面对人群，解决什么问题2几种写PRD的形式3版本号4修订历史功能迭代版本说明5产品架构图6业务流程图7功能列表8数据模型设计实体设计：属性和操作9关系设计10功能优先级目的11标准12注意事项1314交互设计 视觉设计页面页面15术语表16功能性需求定义17用例定义18规则19非功能性需求定义：为实现功能性需求，而必须做到的基本条件或者说只有 在非功能性需求满足的情况下，功能性需求才是有效的201、量化的指标一一时实性、稳定性、吞吐量、性能指标等212、兼容性要求223、可维护性要求234、安全性要求245、界面要求256、明确的时间进度约束267、其它明确的要求（例如：安装包）…更多非功能需求？？27全局规范与说明父互统说明28统页面切换29统手势30局部刷新/重新加载31模态/非模态32333435363738394041424344454647功能规则提示操作说明适配说明账号登录状态好的PRD文档评估标准 文档更新和维护自适应/响应式页面风格页面布局弹框样式及方式各种常见约束条件：各种范围值网络中断访问异常（404, 500）…更多内容？ ？？ 文案？非正常情况状态常见操作 特殊操作 误操作标准注意点页面页面1•该文档是产品项目“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就 是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响到研发部门是否 能够明确产品的功能和性能。
1.需求规格说明书需求说明中包含的是针对现有版本需求的收集整理2■几种写PRD的形式开发工具推荐:Rat ional Rose**** 熟悉项目发生的相关业务行为visio 2007**** 将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统mind manager*** 把项目条目化，条理化，目录结构具体规定好Axure*** 前台结构布局，合理规范的将系统脱去朦胧的华纱Word*** ★★一穿针织网，把需求综合起来，整理成最终的产品需求文档WIKI*** ★★一可团队协同办公，能够记录文档的每一次变更3.版本号文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产 品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文件属于产品的哪个迭代 修改了几个版本文件命名的方法一般是通过版本号定义，比如简单的方法是， XX 产品V1.0PRD_V2，前面的V1.0是产品迭代的编号，后面的V2 PRD的版本号稍微详细点可以定 义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆4修订历史：记录文档的版本历史包括，编号、文档版本、章节、修改原因、日期、修改人。
编号只是为了记录修改的顺序， 文档版本显示的当前修改的内容属于文档的第几个版本（或第几次修改，一次修改一般为一 个版本），章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修 改原因说明为什么要修改该需求，让阅读者直观的了解原因日期是指需求文档修改的时间， 修改人是指需求内容的修改者16 功能定义对系统实施提出的要求，即参与者希望系统提供何种能力满足其需求17 用例定义系统、子系统或能够与外部参与者交互所执行的动作序列，包括各种序列以及出错序列的规 格说明用例是描述让系统做什么，而不是怎么做18 用例写作规则说明：18.1 参与者：参与者定义：说明当与系统直接交互时，一些外部实体采用的角色它可以表示用 户角色或由其它系统或者硬件所扮演的角色，是导致用例执行的本系统边界之外的 事物参与者不一定指人，例：当温度高于30°以上时，空调自动启动，此时系统 的参与者就是温度了解释：1、所有用例必须由参与者发起，也就是说每个用例最终都会对应一个或多个 参与者；2、参与者应该位于你的系统范围之外；3、它应该是直接导致动作执行的 原因（或称外因）；、参与者可能存在继承关系主要参与者：就是上面讲的参与者 次要参与者：在用例被触发之后，与用例进行交互的参与者 解释： 每个用例均只由一个参与者触发，相同的用例在不同时刻下可以被不同的参 与者所触发（但同一时刻只能由一个参与者触发），所以触发该用例的被称为主要 参与者，而可以触发该用例的其它参与者被称为次要参与者。
18.2 前置条件：在开始用例之前约束系统的状态它阻止参与者触发该用例直到满足所 有条件18.3 后置条件：在用例执行之后约束系统的状态解释：前置、后置条件是一个真与假的判断，就象Java里用到的assert （断言语 句）就是做方法的前置、后置条件判断的；一个用例可以没有前置、后置条件，用 none表示；前置、后置条件可以存在多个，可以交集（and）、可以并集（or）等18.4 主要事件流：用例中的主要场景描述主要事件流描述一个正常流程，主要事件流中可以带有流内分支（if...else），也可以存在流内循环（for, while），但无论 流内分支还是流内循环，都必须可以达到后置条件18.5 铺助事件流：用例中次要场景的描述，如：错误、分支或中断一个主要事件流可 能对应多个铺助事件流；铺助事件流反映主要事件流的错误处理、重大分支等18.6 include：表示用例之间的包含关系就是说明一个用例的功能由另一个用例包含 如果不包含这个用例，基础用例就不完整，或无法运作18.7 ext end：扩展点和扩展用例，为已存在的用例添加新的行为的一种方法在没有 扩展点的情况下，基础用例也很完整，类似锦上添加的功能设计。
18.8用例具体写作模板（注：用例规格没有指定格式，只要能够灵活运用用例规格说明 各个元素就可以了）27.全局规范与说明27、交互统一说明1. 字符限制 提高空间利用率，有时网页上的动态文字需要从数据库里提取部分然后截断处理2. 链接具体化很多网站都有对搜索结果的筛选设计(refine search),比如aliexpress搜索结果页左侧这块 区域的交互事件是非常复杂的类目和属性的不同如何处理 属性以及每条属性显示的属性值的条目是否有显示上的限制? 选中后,被选中的属性值是停留在原地,方便用户记忆,还是放到统一的位置,方便用户统 一查看?其他未被选中的属性值是否消失?3. 交互细节说明 尝试用图对小小且复杂的区域进行详细说明后,事情变得简单多了4 表单的校验 这也是一项不怎么有创意的事情,但是你若不事先想清楚,在项目过程中有点麻烦6. 浏览器的兼容性要求 你们的产品兼容所有浏览器简直是梦想,但是有时出于效率的要求,我们必须战略性放弃某 些浏览器，比如IE6、7、8你要求兼容的浏览器越多，标准越高，前端的工作量就会越大, 测试的工作量甚至也会翻倍28、统一页面切换统一页面切换，我觉得web端写这个的比较少，更多的体现在app端，展示方式如下琨換方贰:::::::::::::::::::::::::::1:::::；助檢亦式：::::::::: ：：：：：：转拒駆固::-::駛发育养；•里岌冇式「:「工； 区申竊再面］:::::::29、统一手势 手势操作：使用移动端产品时的操作方式。
比如滑动、放大、摇晃等比如在左右侧抽屉，左右划通常可以返回主界面;比如顶部有切换Tab,是采用左右划切换还 是点击切换;还比如有些应用双击可放大页面，两个手指按住并同时向中间滑动，表示缩小 页面，比如长按可能会弹出复制及粘贴的选择框PRD 主要功能列表介绍功能列表，从以下简要说明，场景描述，业务规则，界面原型，使用者说明，前置条件，后 置条件，主流程功能需求一般是由功能详情和主流程说明两大部分功能详情是所有的产品功能的描述和规划功能 详情包括以下内容简要说明介绍此功能的用途，包括其来源或背景，能够解决哪些问题场景描述产品在哪种情况下会被用户使用，就是用户场景模拟这也是产品经理讲“好”故事的必备 条件业务规则每上产品在开发时都有相应的业务规则，将这些规则清晰的描述出来，让开发、测试人员能 够直观的明白该规则，且没有产生歧义业务规则必需是完整的、准确的、易懂的业务规 则的描述上如果涉及到页面交互或者页面的修改，建议给出页面的草图或者页面截图在图上 说明要修改的内容另外也建议对页面的输入框、下拉框的内容格式、长度、控件之间的关 联性做出说明，什么时候可见，不可见，灰掉或点亮的条件在文档中都给出说明。
方便阅读 者理解业务规则界面原型如前所述，涉及到页面交互的部分，产品经理需要设计页面原型原型设计通常需要产品经 理和 UI 设计师一起来完成使用者说明 对产品使用者做出说明，可融入简要说明中前置条件 该需求实现依赖的前提条件比如，上传照片时，需要存有图像文件后置条件操作后引发的后续处理主流程把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点 说明（这是非常重要的）看过很多的PRD，文档中对既没有前提条件，也没有后置条件，只对主流程做了说明，但是 在描述主流程时却没有描写主流程中每个功能流程的各种走向，只有一个主走向，让人感觉 prd成了操作手册事实上，对分支的介绍是非常重要的，开发和测试中提出的各类问题均 与对分支的定义不明有关一个合格的PRD不仅要描述主流程，同时对分支流程所出现的各 类问题都要做详细阐述并给出解决办法PRD的特征一定是明确的、全面的阐述需求及各类 异常情况的处理而不是等到开发和测试阶段发现问题后再给以答案（虽然PRD不可能百分之 百的覆盖所有的可能，但是最大化的思考所有的业务问题是编制PRD时必须遵守的原则） 另外，在描写功能需求时给出的办法中不能出现“可能”、“或者”等词，一定是明确的， 唯一的描述。
如果有别的方案，建议写入“可选方案”，在产品构建的早期可选方案可以为 功能实现提供更多的选择，当方案确定后可在文档中注明本次使用了哪种方案推荐一个方法：“用例”，在面向对象的软件设计模型中，用例是一个被阐述的内容，用例 是对功能使用场景的解释用例很条理的介绍了每个功能的前置、后置条件，主流程介绍， 帮助开发、测试等角色快速的了解产品功能PRD 文档的写作标准网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己 的PRD规范，适合企业的需要的PRD才是真正PRD本期我们以淘宝的PRD为例，讲解一下 PRD 的主要内容1、文件命名（编号）文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品 名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变 动可以直接命名为''公司名-产品名-PRD-D1.01”，如果涉及。