1、需求文档应该包含什么内容？
需求文档到底要写什么内容，这个不可一概而论，应该根据具体的项目情况酌情考虑，选择最适合当前情况的文档格式。常规情况下，需求文档应该包含前面提到的产品定位、需求内容、需求优先级等，以及关于需求的详细描述说明。下面是关于标准需求文档的内容示例。
1.文档修改与审核记录
需求文档如有修改，需要简要记录。
2.目录
如内容过多最好提供目录。
3.背景描述
为什么要做这个产品、市场行情、业务目标、产品定位。
4.用户类型和特征
简单描述目标用户情况或现有使用人群的情况。
5.项目时间安排
何时启动，何时完成等。
6.信息结构
内容或页面的层级。
7.整体业务流程说明
对于涉及操作较多的产品/功能，需要业务流程图，帮助设计师和项目成员理解具体的业务逻辑。比如一个广告投放系统，当广告排期被占用时，用户是否可接受相关位置；如不接受，系统如何处理账户金额等等。
8.需求详细说明
每一条需求的详细说明。一个文档里会有若干条这样的说明。
9.需求文档的后续迭代
需求文档不可能一次到位。谁也不能保证一次把所有的问题想清楚。一般来说，在完成需求文档后，需要进行需求评审。评审时主要看需求有没有明显的漏洞、不合理的地方，在技术上有没有实现难度，能不能按期完成等。评审过后，产品经理会根据大家的意见重新修改。文档迭代3次以上是很正常的现象。
另外，有一些较细节的东西在需求阶段不容易考虑清楚，要到具体的设计阶段才会有更深入的思考。但一些产品经理为了方便大家理解，会在需求文档中增加一些UI示意图。
最后一点要注意的是，设计师不要严格按照需求文档来做设计。产品经理的考虑角度和设计师不可能完全一样，需求文档更多的是体现业务、产品要求、功能等内容，而设计师还需要更多地去考虑目标用户的特征、使用场景、痛点等。这些信息综合起来，才是设计的主要依据。如果设计师参与了之前的产品定位、需求采集与分析过程，就会对用户的情况比较了解。
因此，专业的交互设计师产出的设计结果一般都会和需求文档提供的内容不太一样，如信息结构、任务流程、内容、界面形式等。只要经过有效的沟通，产品经理一般都是可以接受的。这相当于是在交互设计阶段对文档进行了迭代。产品经理可以在设计完成后再修正需求文档，也可以让设计师把相应的修改部分注释在原型稿上，这样开发人员只看原型稿就可以了。
