“软件需求规格说明书”写作技巧详解.docxVIP

“软件需求规格说明书”写作技巧详解 一、首先要理解需求 《软件需求规格说明书》简称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、其它 最后就是假定与约束这个概念，值得一提了。 就是需求方的强制条件限制、开发时间、经费的限制等。 遇到什么意外，应该如何处理，资源应该如何