产品需求文档模板.doc_第1页
产品需求文档模板.doc_第2页
产品需求文档模板.doc_第3页
产品需求文档模板.doc_第4页
产品需求文档模板.doc_第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

。本文给出产品需求文档的一个模板,实际使用时可根据具体情况选择其中的章节进行撰写,也可进行调整。例如:1) 需求较简单时,第1至5章可压缩成一章“需求概述”。2) 如果整个需求就是对一两个页面进行描述,可以仅仅撰写7.2这样的内容。 需求名称产品需求文档版本时间处理人备注1.0yyyy-mm-dd写明本版本相对于上个版本的变更内容、变更原因、变更提出人等1.1目 录1背景描述21.1问题现状21.2问题分析21.3解决提议22愿景23项目目标24涉众25业务建模35.1用例图35.2对象关系图45.3页面关系图45.4流程图55.5菜单和权限76功能描述76.1功能列表76.2通用功能或规则描述77详细功能描述77.1功能模块:功能模块名称87.1.1具体功能(用例)名称87.2页面名称98风险分析109非功能性需求109.1语言支持109.2浏览器109.3可靠性109.4可用性109.5可支持性109.6性能1010附录1010.1系统界面交互原型1010.2系统相应文案信息1010.3词汇表1011参考资料101 背景描述1.1 问题现状描述当前产品存在什么问题,或者市场存在什么机会,用户存在什么麻烦需要解决1.2 问题分析就前面提到的产品问题、市场机会或用户麻烦进行分析,透过现象挖掘出问题的本质原因。1.3 解决提议承接前面对问题的分析,给出问题的解决方案。2 愿景该产品长远的发展规划和展望3 项目目标该产品在本需求文档所涉及的项目范围内所期望达到的目标,最好是含有可检查的量化目标,例如产品发布1个月后,独立用户量达到日均100万4 涉众在下表中列出该产品所涉及的所有利益方,每个利益方占一行。例如一个网站广告系统的涉众主要为“广告主”、“网站用户”和“网站后台管理人员”涉众涉众代表涉众利益优先级要满足网站后台管理用户张三该涉众所关心的利益点。例如对“网站用户”不能干扰正常使用网站,对“广告主”需要了解广告效果数据等一般可分为“高”、“中”、“低”,也可以用P0、P1、P2、数字越大优先级越低填写“是”或“否”5 业务建模业务建模主要是在业务层面上将产品规则描述出来,往往使用图表的方式,只有当业务层面的需求理清楚后,具体的用例描述和页面设计才有意义5.1 用例图当用户交互功能较多的时候,需要画出用例图。用例(Use Case)以动宾短语命名。用例是测试人员测试功能点的最好依据5.2 对象关系图当对象关系较复杂时,需要画出对象关系图。5.3 页面关系图当所涉及的页面较多时,需要画出页面关系图,通过绘制页面关系图,可以避免在规划设计时遗漏页面5.4 流程图当流程较复杂时,需要画出流程图。通过该流程图能直观清晰地了解整个操作流程所包括的各种分支5.5 菜单和权限一级菜单二级菜单点击后进入的页面对应的权限Ranking决策工具数据报表查看报表项目列表页面报表查看权限数据报表管理报表项目管理页面报表管理权限6 功能描述6.1 功能列表按功能点(往往也就是用例)列出来,分别标示优先级,方便在分阶段开发和发布时确定步骤模块功能点(用例)描述优先级6.2 通用功能或规则描述多个用例或页面中均存在的功能,在此统一进行描述,以避免重复描述和更新不便。例如每个页面都使用到的导航条、翻页条等7 详细功能描述如果是以操作功能为主的产品需求,可以以功能(用例)的维度一个功能接着一个功能地来展开描述,如果功能较多,也可以先按功能模块对功能进行分组,如下面的例子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 基本流程一般是以用户或系统等为主语,相邻两个步骤一般是不同的主语,最后一个步骤是“用例结束”。例如:1) 用户选择要重新上传的数据的路径并触发重新上传操作。2) 系统提示“将首先删除已经上传的数据和报表,是否继续?”3) 用户确认提示。4) 系统执行删除和上传操作并提示“重新上传数据成功”。5) 用户确认提示。6) 系统转到刷新后的“报表项目管理页面”。7) 用例结束。7.1.1.9 分支流程基本流程之外的流程都属于分支流程,分支流程中如果还有分支流程,就用下一级编号分层次展示。每个分支流程的最后一步也是“用例结束”。例如: 1) 系统提示用户是否继续时用户选择取消。a) 系统不做任何操作返回“报表项目管理页面”。b) 用例结束。7.1.1.10 后置条件后置条件一般用来描述该用例完成之后,所带来的影响,尤其是其他模块中的变化。例如在后台中删除了一个用户后,他之前所发表的内容是否还可见,这些都需要在后置条件中一一列出来。这对按用例测试时帮助特别大7.1.1.11 商业规则与此功能点相关的具体的规则、逻辑都可以在这里描述7.1.1.12 词汇表7.1.1.13 补充说明7.2 页面名称如果是主要描述页面元素、UI交互的产品需求,则可以不按用例维度写,而是以页面维度,一个页面接着一个页面地展开描述。同一个文档也可能同时按页面和按功能来描述,只要根据实际情况合理划分章节即可。对页面进行描述时,需要先将页面的原型图贴出来。如果页面较复杂,可以先概要地对整个页面进行描述,然后对页面分区域分别进行描述8 风险分析9 非功能性需求9.1 语言支持9.2 浏览器9.3 可靠性9.4 可用性9.5 可支持性

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论