结果要么用户不置可否，要么直接讲看不懂，为什么呢？一是开发人员在文档中分子系统、分模块、分功能点一层深入下去描述，不符合用户的思维习惯，他们希望能够从业务流程、业务活动的角度来考虑问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。
（3）用户IT主管与开发人员，包括设计人员、编码人员、同行的专家
大多数分析人员可能最擅长的就是些写这类的文档了，往往也是那这类的文档给所有的读者看，其问题我们上边都说了，这里我们就不赘述了。
需要注意的是在描述需求时候传统的做法是以功能为主线，来展开描述，实际上如果是以数据为主线来描述需求也是一种很好的办法，在我们上面谈到的五元组中，从数据的角度来分析系统可以更容易实现向OOA、OOD的切换。
（4） 项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等
把拿给开发人员看的需求文档给管理人员看，这也是分析人员常犯的毛病。管理人员实际上最关心的是需求列表。
在此基础上项目经理、质量保证人员可以据此来进入项目策划过程，测试人员可据此进入测试策划过程，需求管理员、配置管理员可以识别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开展他们的管理活动，也就谈不到最基本的需求复用了。在上述的表中，需求的优先级是很重要的一列，对项目经理进行项目管理的平衡决策是很重要的，实际上需求的优先级可能比需求本身更重要。
3 需求描述的表示技巧
上面我们谈到了，需求文档是人与人之间交互的文档，是不同类型的人之间交互的文档，因此需求文档的可读性是一个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法：
在文档的描述中，适当运用链接，增强文档的可读性；
多用穷举的方式，以便于发现遗漏的需求；
通过适当的换行来提高可读性 ；
采用黑体、斜体、下划线、颜色等多种方式来突出重要内容；
定义标准的术语，以减少二义性，减少文档的页数；
在功能需求的描述中，对于类似的、统一的功能可以单独地进行详细描述，其他地方进行引用，或做为术语进行定义，以简化文档，减少重复。如；
·录入功能
·打印功能
· 条件查询功能
·排序功能等等
结 语
尽管你按照上述的方法去做了，也不要期望能够编写出一份能体现需求应具备的所有特性的文档，无论你如何去细化、分析、评论和优化需求，都不可能达到完美，但是你能够做到“可接受”，写一份客户、用户、开发人员、管理人员都认可的一份需求，而不是完美的需求！ 转贴于：http://www.leadge.com
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
