产品需求文档模板 4.docx
- 文档编号:27134938
- 上传时间:2023-06-27
- 格式:DOCX
- 页数:8
- 大小:17.98KB
产品需求文档模板 4.docx
《产品需求文档模板 4.docx》由会员分享,可在线阅读,更多相关《产品需求文档模板 4.docx(8页珍藏版)》请在冰豆网上搜索。
产品需求文档模板4
[本文给出产品需求文档的一个模板,实际使用时可根据具体情况选择其中的章节进行撰写,也可进行调整。
例如:
1)需求较简单时,第1至5章可压缩成一章“需求概述”。
2)如果整个需求就是对一两个页面进行描述,可以仅仅撰写7.2这样的内容。
]
[需求名称]产品需求文档
版本
时间
处理人
备注
1.0
[yyyy-mm-dd]
[写明本版本相对于上个版本的变更内容、变更原因、变更提出人等]
1.1
1背景描述2
1.1问题现状2
1.2问题分析2
1.3解决提议2
2愿景2
3项目目标2
4涉众2
5业务建模3
5.1用例图3
5.2对象关系图4
5.3页面关系图4
5.4流程图5
5.5菜单和权限7
6功能描述7
6.1功能列表7
6.2通用功能或规则描述7
7详细功能描述7
7.1功能模块:
[功能模块名称]8
7.1.1[具体功能(用例)名称]8
7.2[页面名称]9
8风险分析10
9非功能性需求10
9.1语言支持10
9.2浏览器10
9.3可靠性10
9.4可用性10
9.5可支持性10
9.6性能10
10附录10
10.1系统界面交互原型10
10.2系统相应文案信息10
10.3词汇表10
11参考资料10
1背景描述
1.1问题现状
[描述当前产品存在什么问题,或者市场存在什么机会,用户存在什么麻烦需要解决]
1.2问题分析
[就前面提到的产品问题、市场机会或用户麻烦进行分析,透过现象挖掘出问题的本质原因。
]
1.3解决提议
[承接前面对问题的分析,给出问题的解决方案。
]
2愿景
[该产品长远的发展规划和展望]
3项目目标
[该产品在本需求文档所涉及的项目范围内所期望达到的目标,最好是含有可检查的量化目标,例如产品发布1个月后,独立用户量达到日均100万]
4涉众
[在下表中列出该产品所涉及的所有利益方,每个利益方占一行。
例如一个网站广告系统的涉众主要为“广告主”、“网站用户”和“网站后台管理人员”]
涉众
涉众代表
涉众利益
优先级
要满足
网站后台管理用户
张三
[该涉众所关心的利益点。
例如对“网站用户”不能干扰正常使用网站,对“广告主”需要了解广告效果数据等]
[一般可分为“高”、“中”、“低”,也可以用P0、P1、P2、…数字越大优先级越低]
[填写“是”或“否”]
5业务建模
[业务建模主要是在业务层面上将产品规则描述出来,往往使用图表的方式,只有当业务层面的需求理清楚后,具体的用例描述和页面设计才有意义]
5.1用例图
[当用户交互功能较多的时候,需要画出用例图。
用例(UseCase)以动宾短语命名。
用例是测试人员测试功能点的最好依据]
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可支持性
9.6性能
10附录
10.1系统界面交互原型
10.2系统相应文案信息
10.3词汇表
11参考资料
12
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品需求文档模板 产品 需求 文档 模板