项目笔记五

 

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模块接口定义

通过表格定义模块之间的接口,可以使用如下表格

提供接口模块

调用接口模块

接口名称

输入

输出

备注

XX模块

YY模块等

4构件接口定义

定义构件接口,如果只有一个构件或者所有的构件均独立运行,则这一部分可以省略

 

构件名称

接口名称

方法名称

输入

输出

5用户最终环境

[确定用户使用系统最终运行的软件环境和硬件环境]

6建立测试用例

7验证需求

根据测试用例和场景判断是否满足需求;

通过原型等方法向用户验证需求;

需求分析只写到这里,以上有些观点只代表我个人,另外在实际的操作过程中可能远远不止这些东西,我这里只想做一个“抛砖引玉”,如果大家有兴趣可以买上这方面的书进行专门的研究院,事先声明,上面的所写的这些东西只代表我个人的看法。

1.4 关于软件文档编写的一些看法 

这里我想谈谈软件文档编制,很多开发人员都对文档编制很是头痛,往往让他们加班写一段代码也不愿意抽出一点时间去写文档,笔者初入这一行时也是这样,对文档极其的反感,认为我们是技术人员,是写代码的,不是天天去写文档的,后来随着接触开发的项目越来越多,我也越来越感觉到了文档的重要性。

文档可以有效的提高软件开发过程中的可视度,满足用户、管理人员和开发人员不同视角的需求。

在文档编制的过程中可以更早的发现问题,提高开发效率

便于项目的管理

详细的信息记录,可以为开发人员、维护人员提供支持

能够促进软件开发过程中的规范化

不过,值得注意的是,我们在实际操作过程中,不要过分的强调文档,毕竟文档不是你软件系统的全部,现在经常见到一些个“滥用文档”的现象,一味的追求文档厚度、完整型,甚至花很长的时间和很大的精力去美化文档、不断去更新一些不重要的文档,这样不仅不会给软件开发带来帮助,反而增加了开发人员的负担,降低了开发效率。

那么什么是重要的文档呢,其实在软件工程师考试大纲里也提出来了,一般比较重要的文档包括:可行性研究报告、项目开发计划、需求规格说明书、数据库设计说明书、详细设计说明书、测试计划、测试报告、用户手册、操作手册等,这里面最重要的是需求规格说明书、数据库设计说明书及详细设计说明书(个人观点),这三个文档是我们整个软件系统的核心部分,是需要我们不断更新的。其它的文档相对而言没有这三个文档重要。为什么这样说呢,其实可以从文档最本质的三个作用来分析一下

1)        在开发过程中实现有效的沟通、包括开发人员、管理人员、用户等

2)        为下一次的开发提供数据和可以复用的经验

3)        为后期的系统维护人员提供技术参考

现在很多软件公司都在搞CMMI、ISO9000,这些从本质上来说都是通过大量的文档来规范管理,对于一些大型的软件公司来说,这些手段都是很好的管理手段,而对于我们这些个所谓的“三五个人、十来杆枪”的小单位来说,做这些工作简单就是在折磨自己的研发人员,曾听过一位专搞CMMI认证的培训人讲过,一个正规的软件公司如果要搞CMMI,那么他的员工数量至少要在40人以上(指开发人员),而我们现在很多的软件公司都只是十几或二十个人左右,而且很多人还是搞兼职,调研、设计、编码、测试一个人全做了,这样的企业搞CMMI只会给开发人员增加负担,带来的只是无尽的加班和员工心里的反感。

在笔者这几年的工作实践中,得出一个经验:文档量的多少是一个度的问题,有些大型的项目,文档要求就要严格,有些中小型的项目文档数量就应当相应的减少,只出那些必要的文档即可,对于一个高效的开发团队,文档过多反而会引起反效果。

因此文档的编写应该注重的是实效,而非形式。

原文地址:https://www.cnblogs.com/hzj3099/p/1501113.html