1.3.4 需求规格说明书
需求规格说明书这里我不方便列出，下面是一个通用的需求规格说明书格式，我们在编写文档的过程中可以直接套用该格式即可。
|
1前言 1.1目的 描述实际软件需求规格的目的； 说明软件需求规格所预期的使用者。 1.2定义、缩略语 提供全部需求的术语、缩写词及略语的定义，以便对软件需求规格进行适当的解释。 1.3参考资料 在软件需求规格中所参照的文件的全部清单，如方案、合同等； 列出其他参考资料； 详细说明得到的该参考文件的来源。 2系统需求 [说明系统的总体需求和非功能型的需求，不涉及到具体的业务需求； 说明构件对需求的分配，每一个构件所包含的主要需求内容，这一部分的内容与技术解决具有一定的重合，技术解决定义的时候可能会涉及这一部分的调整； 面向对象需求分析方法： a) 标识构件、并且分配每一个构件的需求，验证需求是否已经全部分配； b) 针对每个构件标识业务对象，即业务系统的概念模型； c) 标识业务对象结构，例如：关联、组成、部分整体等； d) 标识对象的属性和对象之间的实例连接关系； e) 定义对象的服务及服务调用方式；如果可能，可以画出时序图； 3构件1 [构件没有固定的表现形式，其具体的实现可以是一个Exe、Dll等，如果系统比较简单，可以只有一个主程序，就是一个构件，如果系统比较复杂，可以建立多个构件。比如常用的系统组成方式：主程序、权限组件COM，系统初始化工具Exe等] 3.1 XX模块（XX） 3.1.1具体需求 [描写本模块的处理要求，可以描述清楚业务的处理流程和特殊要求（可以使用面向对象的分析方法标识对象、对象结构、对象之间服务的调用方式）] 3.1.2业务数据实体 [确定本模块的业务对象的数据实体，需要确定每一个实体的含义和属性，以及实体之间的相互关系。技术解决中的数据库模型可以通过这里的定义产生] 3.1.3界面要求 [确定界面显示的要求，比如树形、列表等] A功能（XX-001） [每一个功能可以对应到一个具体的业务对象，使用面向的分析方法对具体对象的属性、服务等进行标识和描述] B功能（XX-002） YY模块（YY） 3.3模块接口定义 通过表格定义模块之间的接口，可以使用如下表格
4构件接口定义 定义构件接口，如果只有一个构件或者所有的构件均独立运行，则这一部分可以省略
5用户最终环境 [确定用户使用系统最终运行的软件环境和硬件环境] 6建立测试用例 7验证需求 根据测试用例和场景判断是否满足需求； 通过原型等方法向用户验证需求； |
需求分析只写到这里，以上有些观点只代表我个人，另外在实际的操作过程中可能远远不止这些东西，我这里只想做一个“抛砖引玉”，如果大家有兴趣可以买上这方面的书进行专门的研究院，事先声明，上面的所写的这些东西只代表我个人的看法。
1.4 关于软件文档编写的一些看法
这里我想谈谈软件文档编制，很多开发人员都对文档编制很是头痛，往往让他们加班写一段代码也不愿意抽出一点时间去写文档，笔者初入这一行时也是这样，对文档极其的反感，认为我们是技术人员，是写代码的，不是天天去写文档的，后来随着接触开发的项目越来越多，我也越来越感觉到了文档的重要性。
l 文档可以有效的提高软件开发过程中的可视度，满足用户、管理人员和开发人员不同视角的需求。
l 在文档编制的过程中可以更早的发现问题，提高开发效率
l 便于项目的管理
l 详细的信息记录，可以为开发人员、维护人员提供支持
l 能够促进软件开发过程中的规范化
不过，值得注意的是，我们在实际操作过程中，不要过分的强调文档，毕竟文档不是你软件系统的全部，现在经常见到一些个“滥用文档”的现象，一味的追求文档厚度、完整型，甚至花很长的时间和很大的精力去美化文档、不断去更新一些不重要的文档，这样不仅不会给软件开发带来帮助，反而增加了开发人员的负担，降低了开发效率。
那么什么是重要的文档呢，其实在软件工程师考试大纲里也提出来了，一般比较重要的文档包括：可行性研究报告、项目开发计划、需求规格说明书、数据库设计说明书、详细设计说明书、测试计划、测试报告、用户手册、操作手册等，这里面最重要的是需求规格说明书、数据库设计说明书及详细设计说明书（个人观点），这三个文档是我们整个软件系统的核心部分，是需要我们不断更新的。其它的文档相对而言没有这三个文档重要。为什么这样说呢，其实可以从文档最本质的三个作用来分析一下
1) 在开发过程中实现有效的沟通、包括开发人员、管理人员、用户等
2) 为下一次的开发提供数据和可以复用的经验
3) 为后期的系统维护人员提供技术参考
现在很多软件公司都在搞ＣＭＭＩ、ISO9000，这些从本质上来说都是通过大量的文档来规范管理，对于一些大型的软件公司来说，这些手段都是很好的管理手段，而对于我们这些个所谓的“三五个人、十来杆枪”的小单位来说，做这些工作简单就是在折磨自己的研发人员，曾听过一位专搞CMMI认证的培训人讲过，一个正规的软件公司如果要搞CMMI，那么他的员工数量至少要在40人以上（指开发人员），而我们现在很多的软件公司都只是十几或二十个人左右，而且很多人还是搞兼职，调研、设计、编码、测试一个人全做了，这样的企业搞CMMI只会给开发人员增加负担，带来的只是无尽的加班和员工心里的反感。
在笔者这几年的工作实践中，得出一个经验：文档量的多少是一个度的问题，有些大型的项目，文档要求就要严格，有些中小型的项目文档数量就应当相应的减少，只出那些必要的文档即可，对于一个高效的开发团队，文档过多反而会引起反效果。
因此文档的编写应该注重的是实效，而非形式。