转载自：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://javaforall.net/227068.html原文链接：https://javaforall.net
