软件需求说明书为谁而编写个问题搞清楚是非常有意义的。
先讲个故事。
在软件项目开始时，需求及架构设计人员把需求和架构方案讲给开发人员听，开发人员还在设计“他那辆车”，没有听明白及架构设计人员接着写出一些列文档后，开发人员还在设计稍作调整“他那辆车”，沟通出现了问题了吗完成后，最后结果仍是开发人员所设计的，已经变形的“他那辆车”。
首先，我们先回顾软件工程中的需求分类和需求层次。
需求的分类
- 软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束三个方面的内容；
- 业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求；
- 用户需求是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，然后建立的从用户角度的需求；
- 系统需求是从系统的角色来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束。
需求的层次
需求包括三个不同的层次：业务需求、用户需求和功能需求，也包括非功能需求。
在需求调研、需求分析、编写需求说明书时，上述需求分类和层面都应涉及，否则，将缺项，让人无法了解全面。如下表1“业务流程需求”为例所示，用户层次及角色至少分为8个层面，他们的需求及视角很多都不同。
图1
如何解决这些问题呢p>
首先，必须写需求说明书，而且写成相关各个用户层次都能看到各自关注内容，满足现有业务需求，并高于现有的业务，也就是业务建模。只有这样，需求变更才恢复到本来的面貌，而不是理解偏差出现的变更。
下面列表是早期写的需求说明书目录内容截取，需求内容非常的多。例如：用户有很多待建流程，如果逐一展开写到文档中，先不说写的工作量，还有谁看呀！
需求分析真的需要丰富的经验，领域专家。企业管理方面呢是需要企业老总呢管理专家又是谁指点流程能力、执行力、效率、效益……。所以，从各个视角关注流程是非常必要的，而且，要体现这些，需要在需求说明书中编写。
软件需求说明书参考模版如下列表所示。
项目经验之谈分享，精力有限，难免有误，仅供参考，欢迎讨论、再补充完善。
参考：
百度百科.“软件需求”
使用云技术升级改造现有应用系统的思考 2013.11 肖永威
面向集团客户的云计算运营平台概述——之云计算运营平台方案（一） 2013.12 肖永威
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！