产品需求文档模板.docxVIP

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