关于文档，我最近探索如下写法写文档，拿一个相对明确的功能来说（没人要求，我自己摸索的，我们用的是scrum，不怎么要求文档）：
1 需求
该部分希望需求人员给予评审，确认，测试人员对该部分理解认可以。
1.1 用户需求
用“作为一个……，我希望……，以便于……”句式整理用户需求，重点是“以便于”部分。
这部分应该不会有太多条，多于五条则要反思是否对需求理解有误。
1.2功能需求
以“A应该……”句式整理功能需求。主要就是需求求，需要系统实现哪些功能。
1.3 限制与依赖
列出该需求受哪些限制，依赖于什么。这部分是写给自己和测试人员看的，知道了限制与依赖，不要写出不必要的测试用例。这部分需要得到测试人员的认可与理解。
1.4 假设
要实现功能，有很多假设，一定要罗列出来，并与人交流。此处也需要得到测试人员的认可与理解。

其实这些真正写起来没有多少，我写的时候也没出现没思路或生搬硬套的问题。但是这些是整理需求过程中的工具，及在理解需求后的整理。
最近在看《软件需求 第三版》，此部分是对该书内容的应用与演练。

在整理完需求后，我一般会画一个关联图，确认一下需求的边界与交互对象及主要交互。

2 针对需求的测试用例
针对上面需求而整理的测试用例，此处需测试人员的参与与评审。有了前面的需求，此处写起来很快，也不会有太多的测试用例。
3设计
大体描述一下设计，我很多时候主要用来整理思路。
4 针对设计的测试用例
这一块针对设计写一些测试用例，要覆盖针对需求的测试用例。这一块测试用例主要自己用，在编码完成后知道怎么验证。
5时序图
编码完成后，画一下时序图，以便别人了解自己代码的调用流程。如果是OO代码，我打算在此处放置一下类图，并添加一个类作用的表格。