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