产品需求文档实用模板.docxVIP

[ 本文给出产品需求文档的一个模板，实际使用时可根据具体情况选择其中的章节进行撰写， 也可进行调整。例如： 需求较简单时，第 1 至 5 章可压缩成一章“需求概述” 。 2) 如果整个需求就是对一两个页面进行描述，可以仅仅撰写这样的内容。 ] [需求名称 ]产品需求文档 版本  时间 [yyyy-mm-dd]  处理人  备注 [ 写明本版本相对于上个版本的变更内容、 变更原 因、变更提出人等  ] 目录 背景描述 1.1 问题现状 [ 描述当前产品存在什么问题，或者市场存在什么机会，用户存在什么麻烦需要解决 ] 1.2 问题分析 [ 就前面提到的产品问题、 市场机会或用户麻烦进行分析， 透过现象挖掘出问题的本质原因。 ] 1.3 解决提议 [ 承接前面对问题的分析，给出问题的解决方案。 ] 愿景 [ 该产品长远的发展规划和展望 ] 项目目标 [ 该产品在本需求文档所涉及的项目范围内所期望达到的目标，最好是含有可检查的量化目标，例如产品发布 1 个月后，独立用户量达到日均 100 万] 涉众 [ 在下表中列出该产品所涉及的所有利益方，每个利益方占一行。例如一个网站广告系统的涉众主要为“广告主” 、“网站用户”和“网站后台管理人员” ] 涉众 涉众代表 涉众利益 优先级 要满足 网 站 后 台 管 张三 [ 该涉众所关心的利益点。例如对“网站 [ 一般 可 [ 填 写 理用户 用户”不能干扰正常使用网站，对“广 分 为 “是” 或 告主”需要了解广告效果数据等 ] “ 高 ”、 “否” ] “ 中 ”、 “低”，也 可 以 用 P0、 P1、 P2、?数 字越大 先 越 低] 业务建模 [ 建模主要是在 面上将 品 描述出来，往往使用 表的方式，只有当 面的需求理清楚后，具体的用例描述和 面 才有意 ] 5.1 用例图 [ 当用 交互功能 多的 候，需要画出用例 。用例（ UseCase）以 短 命名。用例是 人 功能点的最好依据 ] 5.2 对象关系图 [ 当 象关系 复 ，需要画出 象关系 。 ] 5.3 页面关系图 [ 当所涉及的 面 多 ，需要画出 面关系 ，通 制 面关系 ，可以避免在 划 漏 面 ] 5.4 流程图 [ 当流程 复 ，需要画出流程 。通 流程 能直 清晰地了解整个操作流程所包括的各种分支 ] 5.5 菜单和权限 一 菜 二 菜 点 后 入的 面 的 限 Ranking 决 策 数据 表 看 表 目列表 面 表 看 限 工具 数据 表管理 表 目管理 面 表管理 限 功能描述 6.1 功能列表 [ 按功能点（往往也就是用例）列出来，分别标示优先级，方便在分阶段开发和发布时确定步骤 ] 模块  功能点（用例）  描述  优先级 6.2 通用功能或规则描述 [ 多个用例或页面中均存在的功能，在此统一进行描述，以避免重复描述和更新不便。例如每个页面都使用到的导航条、翻页条等 ] 详细功能描述 [ 如果是以操作功能为主的产品需求，可以以功能（用例）的维度一个功能接着一个功能地 来展开描述，如果功能较多，也可以先按功能模块对功能进行分组，如下面的例子 ] 7.1 功能模块： [ 功能模块名称 ] 7.1.1 [ 具体功能（用例）名称 ] 7.1.1.1 描述 7.1.1.2 涉众利益 7.1.1.3 角色 7.1.1.4 用户界面 7.1.1.5 辅助图例 7.1.1.6 操作入口 7.1.1.7 前置条件 7.1.1.8 基本流程 [ 一般是以用户或系统等为主语，相邻两个步骤一般是不同的主语，最后一个步骤是“用例结束”。例如： ] 用户选择要重新上传的数据的路径并触发重新上传操作。 系统提示“将首先删除已经上传的数据和报表，是否继续？” 用户确认提示。 系统执行删除和上传操作并提示“重新上传数据成功” 。 用户确认提示。 系统转到刷新后的“报表项目管理页面” 。 用例结束。 7.1.1.9 分支流程 [ 基本流程之外的流程都属于分支流程，分支流程中如果还有分支流程，就用下一级编号分层次展示。每个分支流程的最后一步也是“用例结束” 。例如： ] 系统提示用户是否继续时用户选择取消。 系统不做任何操作返回“报表项目管理页面” 。 用例结束。 7.1.1.10 后置条件 [ 后置条件一般用来描述该用例完成之后，所带来的影响，尤其是其他模块中的变化。例如 在后台中删除了一个用户后， 他之前所发表的内容是否还可见， 这些都需要在后置条件中一一列出来。这对按用例测试时帮助特别大 ] 7.1.1.11 商业规则 [ 与此功能点相关的具体的规则、逻辑都可以在这里描述 ] 7.1.1.12 词汇表 7.1.1.13