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、包含一个术语表