转载自:https://www.jianshu.com/p/f9bcf52f4321
一、任务突然从天而降
自己维护一个终端一年多,今天主管突然要求补写一下《软件需求规格说明书》,有些傻眼。自已可是一个转行来的非正规军程序员,根本没有经验写过这个。没办法,从网上下载一个模板吧,必须标准些,没商量!下载模板后一看,有些傻眼。模板目录如下:
二、首先要理解需求
看了目录,有些傻眼。不过很快,难不到哥,因为哥喜欢学习。经过哥一番努力研究之后,终于有些眉目了。
《软件需求规格说明书》简称SRS,英语全称懒得去查,主要是找到快捷的定义就行。SRS一般不是企业方(委托方)所做,而是开发方(被委托方)根据企业方的非标准文本或口述资料整理所得。SRS也不仅仅是为了明确需求,更是为了协调各方(企业用户、架构师、开发者、测试人员、部署人员)统一目标的第一个标准文档。一旦项目比较庞大,跨越多组织多部门时,这个文档就很重要,省去很多沟通上的众多麻烦。
所谓项目前期,核心就是需求(功能)。从企业用户而来的第一手需求,一条一条的就像列举清单一样,往往在逻辑上比较凌乱,开发方需要对其进行整理,整理之后便是SRS。这样的需求列表就是项目前期的核心内容,也是SRS的主要内容。
SRS并不是列出来后,放在文件柜中的资料,而是不断改进与完善的资料,是所有参与组织与部门的统一认可。如有改动,大家必须重新聚首讨论。
什么是需求,需求就是企业方对开发方的要求,必须这么做。企业方提出的需求并非越少越好。往往企业越细心,需求越详尽,开发方越轻松。
你要求的越多越详尽,我发挥的就越少,但往往就越轻松。
你要求的越少越细疏,我发挥的就越多,但往往就越困难。
一个项目真正复杂不复杂,是由真实的业务需求决定的,而不是由起初的需求描述量所决定的。
零乱的需求大体有规律可寻,需求经过整理后,SRS就是如此而来。一定有些不能归类的需求,毕竟好的软件都有自己的概念创新,可以添加需求条目,自定义需求名称,也可以归入”其它需求”。还是谨记一点,不要被这些分类所束缚。大胆描述需求,需求只要能被提出来,就是需求,归类是后期的事。
三、SRS文档解释
1、功能需求
需求首先要满足企业用户的业务功能,就是与企业生产管理运营相关的功能,用来与员工、用户、业务人员、领导进行交互的功能,有多少就列多少。这种需求是软件开发的最原始动机。
这种需求,先描述有多少参与者,再描述每种参与者有多少功能。
(如果软件为服务,则功能需求则是以接口形式服务于客户端程序)
除过功能需求外,以下需求并非个个都是可选项,根据自己软件的特征而定。
2、非功能需求类
2.1、安全性需求
如果系统账号出现纰漏,为软件参与者造成重大损失,这是最麻烦的。
还有如果系统被注入或被黑客攻入,软件宕机,为软件用户造成重大损失,为运营方造成重大市场影响,这也是最可怕的。
安全性需求是运营方、运营方网管、运营人员的基本需求。
2.2、维护性需求
维护成本,这是运营方要考虑的问题。如果运营方有技术人员,对源代码的标准化、文档的标准化是有要求的,为了降低维护性成本。
维护性需求是运营方技术人员的基本需求。
2.3、移植性需求
如果代码从一个平台,移植到另一种平台,编译是否仍然正常,这个很重要。当公司需要二次开发或再开发时,这个就太重要了。
移植性需求是二次开发人员、再开发人员的基本需求。
2.4、性能需求
软件占多少内存,运行速度,提交反馈速度,是否符合要求业务要求。
性能需求是运行系统、软件使用者的基本需求。
2.5、运行环境需求
软件运行系统版本的要求,运行环境,与协同软件协同工作需求,不能与协同软件相冲突的要求。这种需求常见于客服类软件。
运动环境需求是运行系统、运行环境、协同软件的需求。
2.6、可靠性需求
软件得出的数字或结论,必须可靠,因为它可能被用于决策、生产或再生产。
这是生产或经营决策者、客户端程序的需求。
3、外部接口需求类
3.1、硬件接口需求
如果软件被要求用特定的硬件,则会要求开发方必须按照某种形式对接硬件,而且必须要达到相关性能。
硬件接口是软件所使用硬件设备的基本需求。(如:短信猫设备、打印设备)
3.2、软件接口需求
如果软件某个模块必须对接某个软件接口,则会要求开发方必须按照某种规则对接此软件,而且必须要达到相关性能。
软件接口是协同软件的接口需求。(如:短信接口、验证码接口)
3.3、用户接口需求
如果软件的输入输出被要求必须用某种格式的文本或文件,或交互上有特殊要求,都可以写在这儿。
用户接口需求是协同系统、有导入导出需求用户的基本需求。
3.4、通讯接口需求
如果软件是某通讯主机的终端软件,或是某终端软件的服务端程序。则会对开发要求使用规定的通讯接口。
通讯接口需求是协同系统的通讯标准需求。
4、其它需求类
4.1、界面需求
需求可以更详尽,有些企业用户对界面有直接要求,而不是要求开发方先做几版,自己挑一版。这种情况下,对开发方来说,界面需求越详尽越好。
4.2、数据需求
只要项目,一般都会用到数据库,有些开发实力较强的企业方甚至对数据库、数据表、存储过程等有要求。
5、其它
最后就是假定与约束这个概念,值得一提了。
就是需求方的强制条件限制、开发时间、经费的限制等。
遇到什么意外,应该如何处理,资源应该如何分配的问题。
作者:剑心折手
链接:https://www.jianshu.com/p/f9bcf52f4321
來源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。