如何写一个好的需求文档
来源:互联网 发布:阿里云移动开放平台 编辑:程序博客网 时间:2024/06/10 02:58
1、从用户角度的编写
2、使用Screen Shots
3、用简单的语言编写
a)保持简短的语句,把长的语句分解成多个小的语句。
b)避免大篇幅的连续文本,把他们分解成多个小的章节。
c)把大块文本内容分解成,screen shots,表格、重点列表等等。
4、小心的使用模板
我发现MRD模板非常有用。他们的几个好处包括:
a) 模板提供了一个标准的格式,使那些不得不阅读大量MRD的读者更加容易阅读。
b) 模板让新的产品经理快速的写MRD变得容易,因为公司与公司之间的MRD内容是不同的。
c) 模板确保你不会忘记所有需要在MRD中覆盖描述的部分;
5、区分需求的优先级
区分需求的优先级是一个最好的能帮助完成这个事情的办法。我发现把需求分等级就像P1,P2,P3...这样工作的刚刚好。在这个分类中-P1是最高优先级,P2是第二高优先级等等。
我们只要包括P1,P2,P3的需求在你的MRD中,在多数的项目中更低的优先级可能未必会实现。还有这样也让MRD变得更加容易读。
6、说明"是什么"和"为什么",但不要"如何"
为理解客户的需求负责,然后基于这些理解定义什么和为什么需要开发.
推荐-描述“是什么”,不推荐-描述“怎么样”。
有技术背景的产品经理尤其喜欢描述“如何实现”。如果这些描述的就是你,应该从现在开始不要再做这样的事了。工程师们将会感谢你。
7、覆盖非功能性需求
尽管功能性需求描述产品的功能,非功能性需求描述系统特性,如:
a)性能
b)可伸缩性
c)可用性
d)国际化
e)等等...
我注意到因为许多产品经理和产品市场人员认为这些是“技术细节”,而在MRD中被忽略。我发现这些是我的MRD中非常重要的一部分,工程师们会非常感激在MRD中定义这些需求。
要点:当写非功能性需求的时候,尽可能的是使他们可度量(可测试)。否则,QA不能测试它们,你将没有办法知道完成的产品是否已经实现了这些非功能性需求。
8、评审&修正
9、定义市场目标和定位
这些问题(谁将买和使用户你的产品和与竞争对手的产品比你的产品定位怎么样的)的确有一些正面价值,我发现许多工程师想知道为什么一个产品或特性要开发,谁将使用他们,什么是他们可以另外选择办法。
这些信息帮助他们和产品组的其他成员想象最终用户并从而更好的为创造成功的产品工作。我的建议的尽可能的(在MRD中)包含这些信息。- 它们不一定要很详细,只要包含几个段落就足够了。
10、包含一个术语表
- 如何写一个好的需求文档
- PM如何写好产品需求文档
- PM如何写好产品需求文档
- PM如何写好产品需求文档
- PM如何写好产品需求文档
- 如何写好一份产品需求文档
- 写需求文档的好帮手 Axure
- 一个程序如何写需求文档
- 如何写好PRD(产品需求文档)+范例
- 如何判断一个已经写好的MFC程序是单文档还是多文档?
- 如何写需求分析文档
- 如何写一个公司地址数据库的需求?
- 如何写一篇好的技术文档
- 如何写一篇好的技术文档
- 如何写一篇好的技术文档
- 如何写一篇好的技术文档
- 如何写出好的产品需求文档(PRD)?
- 弄清需求和写好需求文档,哪一个更难?
- 新书上市《Spring 2.0核心技术与最佳实践》
- 百姓的打油诗
- COM连接点C++客户使用注意事项
- ini文件纯C++读写代码
- vb.net 文本框只能输入数字和退格键
- 如何写一个好的需求文档
- Java学习总结
- Firefox的HTTP内容解压代码阅读
- 水晶报表CrystalReportViewer之“创建控件错误”
- Java 理论与实践: 正确使用 Volatile 变量
- SAX与DOM之间的区别
- TOMOS在线操作系统推出公测
- Linux系统下C语言编程基础知识介绍
- The differences between Direct3D9 And Direct3D10