基于让老大们满意的目标，你可以先向老大们做个调研，了解一下他们对于需求文档的需求。

要看需求的人很多，设计人员、用户、测试人员通常都会要看。写成什么样子，跟这些人的要求有关系。
偏重流程的方式或偏重功能的方式，应该都可以。

学习...望高手展示他的需求作品,呵呵

个人理解：
针对客户的需求，可以解析为商业需求分析，
针对开发人员的需求，才是软件的需求分析，

这个我也不太清楚，我们一般只做功能方面的需求，其他好像很好设计，可能是因为我们做的系统比较小。应该跟系统的大小和复杂度有关吧，一个很小的系统，就没那么多讲究了，大的系统讲究应该会多些

以前的老大教的，描述一个需求围绕着what,when,where,how来说明就可以准确了，其他的就是修饰了

每个公司应该根据自己的产品类型定义自己的需求文档模版

我比较想知道一些公司如何做项目需求的checklist的

按写新闻的要求来写需求，基本上就已经很好了。
who也是需要的，特别是用户对不同角色的权限有要求的时候。这个也可能包含在how里了。

对需求的checklist，和对需求的评审有关系。如果公司里对需求有评审，每一次评审会提出的问题、评审人员思考的角度、曾经在需求中有过的经验教训，这些内容整理一下，就是一个checklist了。开过几次评审，就可以设计一个需求checklist的初稿，最开始的样子可能不太全面，但比较实用，以后再不断完善，checklist就越做越好了。

主要还是看需求的评审是怎么做的。

最近开始学习需求文档的编写,嘿,也看看