每个角色在看说明书的时候都会有不同关注点：
1需求提出者关心的是他们的功能是否都已经在说明书种得到体现。
2提出者的管理层关心提出功能是否能够满足现有业务提高工作效率。
3技术人员关心的是这些需求能否变成程序实现。
4项目经理关心的是这些需求需要的成本。
一份需求做到面面具到是不可能的但是完全可以做到一种平衡状态。刚才说了使用者很多，但是要能找到的关键的。技术肯定一开始总是要翻看找解决方案，提出者是委托方委以重任的关键人肯定看的时候也会少。项目经理要了解情况分配资源，给一个总体认识就好，而委托方的经理要看到效果那就给他几个点让他看。
说了主要观看对象，要说书写的内容了。
个人认为内容应该由一下几个部分组成。（个人意见只供参考）
1、整体项目概述，写清项目的由来，要达成的目标。这个部分主要阅读对象是项目经理和管理层。
注：在段中尽量写清开发范围，业务边缘定义等。这样可以有效阻止需求膨胀，很多项目组不注意这些细节，结果无法按时完成。
2、项目整体功能概述，写清项目功能的组织结构，项目功能达成的工作目标。这是整体项目的认识要写清楚。
3、功能概述及描述，尽量详细的叙述每个功能（应有业务流程图配合）。
必须包括的几个点是
a功能名称
b功能商业目的，写明这点这点很重要，它是这个业务出现的根本原因。有很多作需求的朋友总是在抱怨需求老是在变，其实是没有抓住根本的症结所在。大家可以试想一下，一个行业或是一个公司它的业务流程如果是天天变化的，那是一件多么可怕的事情呀。举个例子好了，比如一家保险公司的投保人录入系统，这样一个流程：1输入客户信息到核心系统。2根据提供的信息呼出用户电话。3客户回复电话记录相关未提供信息。4抽捡客户信息真是性呼出登记电话。
这是个功能流程，换做商业目的应该是1保存客户信息，一备以后历史查询或挖掘新客户用。2需要客户确认信息真实性。3填补公司想知道的客户其他信息。4查阅座席工作质量
你会看到这些本来已经有的商业目的是很久都不会变一次的。
注：业务流程图不是功能流程，在作图和话述的时候尽量避免出现技术专业词汇。
c功能目标，使用者、完成功能、完成后的预期结果等。
d功能流程图和话述
e输入输出内容。详细说明
f参考原始业务模型，比如图表之类，二期开发可以参考原始系统等。
4、其他相关业务要求
5、其他待办项
基本说 这样的一个文档 谁看了都会比较满意顺心的。
这些是我自己的在工作中遇到困难后的解决之道，热烈欢迎大家指正。