软件需求说明书为谁而编写？把这个问题搞清楚是非常有意义的。
先讲个故事。
在软件项目开始时，需求及架构设计人员把需求和架构方案讲给开发人员听，开发人员还在设计“他那辆车”，没有听明白？需求及架构设计人员接着写出一些列文档后，开发人员还在设计稍作调整“他那辆车”，沟通出现了问题了吗？项目完成后，最后结果仍是开发人员所设计的，已经变形的“他那辆车”。
问题的源头当然在需求，需求人员又如何把需求调研结果无损的分享给“相关人员”呢？其他原因，例如项目团队学习等不在本文中分析了。
首先，我们先回顾软件工程中的需求分类和需求层次。
需求的分类
- 软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束三个方面的内容；
- 业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求；
- 用户需求是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，然后建立的从用户角度的需求；
- 系统需求是从系统的角色来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束。
需求的层次
需求包括三个不同的层次：业务需求、用户需求和功能需求，也包括非功能需求。
在需求调研、需求分析、编写需求说明书时，上述需求分类和层面都应涉及，否则，将缺项，让人无法了解全面。如下表1“业务流程需求”为例所示，用户层次及角色至少分为8个层面，他们的需求及视角很多都不同。
表1
在需求调研中，表1中，很难访谈到领导层，其他各层也很难面面俱到，而写出来的需求说明书，这些人也看不到，或者说也不可能看，就是项目团队中的开发人员也很少看。这样，软件界的需求故事不停的上演。
图1
如何解决这些问题呢？
首先，必须写需求说明书，而且写成相关各个用户层次都能看到各自关注内容，满足现有业务需求，并高于现有的业务，也就是业务建模。只有这样，需求变更才恢复到本来的面貌，而不是理解偏差出现的变更。
下面列表是早期写的需求说明书目录内容截取，需求内容非常的多。例如：用户有很多待建流程，如果逐一展开写到文档中，先不说写的工作量，还有谁看呀！
调整思维后，需求说明书目录截图发生较大的变化，不是以往点、面的模式描述需求，而是立体模型方式描述需求，需求建模。而需求建模需要需求开发人员能力很多，例如属于这个方案业务专家或者管理方案的专家。
需求分析真的需要丰富的经验，领域专家。企业管理方面呢？是不是需要企业老总呢？企业管理专家又是谁?谁能指点流程能力、执行力、效率、效益……。所以，从各个视角关注流程是非常必要的，而且，要体现这些，需要在需求说明书中编写。
软件需求说明书参考模版如下列表所示。
总之，软件需求仅按用户需求直译方式去理解并开发，哪将是恶梦的刚刚开始。真正的需要是去伪求真的，真的需求不可能是由普通用户（业务接口人）能全部提供的，层次不够，覆盖面不够，真的来源于业务领域知识、国家政策法规、企业规章制度，以及社会及其信息化发展方向。把这些内容都体现到需求说明书中，就方便各层领导阅读了，也提供普通员工和开发人员的认识层次了。通过次需求说明书，开发人员知道并理解做什么，减少，最好防止“一千个人心中有一千个哈姆雷特”的情况发生。
项目经验之谈分享，精力有限，难免有误，仅供参考，欢迎讨论、再补充完善。