《软件需求规格说明书》？ |
您所在的位置：网站首页 › 产品需求规格说明书由谁写 › 《软件需求规格说明书》？ |
|
首先，什么是《软件需求规格说明书》？
《软件需求规格说明书》简称SRS，software requirements specification。SRS一般不是企业/客户（委托方）所做，而是软件开发团队（被委托方）根据企业的非标准文本或口述资料整理所得。SRS也不仅仅是为了明确需求，更是为了协调各方（企业用户、架构师、开发者、测试人员、部署人员）统一目标的第一个标准文档。一旦项目比较庞大，跨越多组织多部门时，这个文档就很重要，省去很多沟通上的众多麻烦。
项目前期中的核心就是需求（功能）。从企业用户而来的第一手需求，一条一条的就像列举清单一样，在逻辑上往往比较凌乱，软件的开发方需要对其进行整理，整理出来的文档便是SRS。这样的需求列表就是项目前期的核心内容，也是SRS的主要内容。
SRS是与软件开发周期息息相关的，并不是将需求列举出来后，就尘封起来不再使用的资料，而是需要不断改进与完善的资料，是所有参与组织与部门的统一认可。如果有新的改动出来，大家必须重新进行讨论，然后再完善和更新SRS。
那么，什么是需求？ 需求就是企业对软件开发团队的具体要求，到底需要开发团队去实现什么。企业提出的需求并不是越少越好。一般企业提出需求越是详尽，开发团队的工作就越是轻松。你要求的越多越详尽，我发挥的就越少，但往往就越轻松。相反你要求的越少越细疏，我发挥的就越多，但往往就越困难。 一个项目真正复杂不复杂，是由真实的业务需求决定的，而不是由起初的需求描述量所决定的。 企业提出的非标准的零乱需求大体有规律可寻，这些需求经过整理之后后，就可以得到所谓的SRS。而在进行需求分析之时，开发团队一定会遇到有些不能归类的需求，毕竟好的软件都有自己的概念创新，此时就可以添加需求条目，自定义需求名称，或者也可以归入“其它需求”。反正就是要明白，做需求文档，不要被所谓分类所束缚；大胆地去描述需求，需求只要能被提出来，就是需求，归类是之后的事。 那么，我们该怎么去写SRS呢？大致可遵循的架构如下： 1.产品描述 1.1 编写目的 说明编写本软件需求规格说明书的目的，指出预期的读者。 1.2 产品名称 本项目的名称，包括项目的全名、简称、代号、版本号。 1.3 名词定义（可选） 对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。2.产品需求概述 2.1 功能简介 对产品的基本功能做一个简介，包括： 本产品的开发意图、应用目标及作用范围； 概略介绍了产品所具有的主要功能，可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等； 说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。可以用 表示外部接口和数据流的系统高层次图，或者方框图说明。 2.2 运行环境 硬件环境： 详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置( 如主机、显示器、外部设备等) 以及其它特殊设备。 软件环境： 如操作系统、网络软件、数据库系统以及其它特殊软件要求。 2.3 条件与限制（可选） 说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的组件。等等3.功能需求 功能需求描述系统特性，即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。 3.1 功能划分（可选） 此部分从用户的角度描述将软件划分成不同的部分，并给出总体功能结构。对于复杂的系统，还需要对主要子系统中的基本功能进行描述。描述方法包括结构图、流程图或对象图等等。但应注意此处划分成的部分并不对应于最终程序实现时的不同功能模块。 3.2 功能1 细化由功能划分所生成的各部分的内容，包括下列内容： 此功能的编号、简要说明和优先级 对此功能的详细描述, 包括：本功能的输入信息、详细的系统响应，输出信息等等。 3.3 功能N 3.4 不支持的功能 列出本软件所不支持的各项功能以及相应的原因。此部分内容务必详细准确、无二义性，以作为将来验收和测试的标准。4.数据描述 说明本产品的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。描述的方式跟分析模型相关。例如： 输入输出数据的类型及格式。 数据库描述( 可选) ：根据系统的总目标和范围，定义数据库的逻辑特性及物理特性。 数据流图；从数据传递和加工的角度描述的数据流图，此数据流图不包含任何有关实现的内容，只是从最上层对有关内容加以描述。数据流图的表述形式参见软件工程中的有关规定。 数据词典：对于数据流图中出现所有被命名的图形元素在数据词典中作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。5.性能需求（可选） 阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。这些性能需求例如： 数据精确度：根据实际情况，确定软件最终输出数据( 包括传输中) 的数据精确度。 时间特性：说明开发的软件在响应时间、更新处理时间、数据转换与传输时间、运行时间等方面所需达到的时间特性。 相互合作的用户数或者所支持的操作； 容量需求，例如存储器和磁盘容量的需求或者存储在数据库中表的最大行数等等6.运行需求（可选） 6.1. 用户界面 描述用户界面方面的需求，包括：本软件的人机界面风格；屏幕布局或解决方案的限制；将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）；快捷键；错误信息显示标准，等等； 6.2. 硬件接口 描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间的交流的数据和控制信息的性质以及使用的通信协议。 6.3. 软件接口 描述该产品与其他外部组件（由名字和版本识别）的接口，包括数据库、操作系统、工具、库和集成的商业组件等。对于每个需要的软件，应提供： 接口名称 规格说明 版本号 6.4. 通信接口 描述与产品所使用的通信功能相关的，包括电子、Web 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。7.其它需求（可选） 如健壮性、安全保密性、复用性、灵活性、易用性、可维护性、可移植性等。指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植优于有效性。 健壮性：说明软件在容错能力，故障处理能力上需要达到的目标，保证系统稳定可靠； 安全保密性：包括用户身份确认或授权方面的需求，保密性策略，产品所创建或使用的数据的保护等等； 复用性：说明本项目是否可以复用已有软件、是否可为其它产品复用； 灵活性：说明在运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。8.特殊需求（可选） 由用户提出的，或是本公司要求的特殊要求、特殊的情况等。 9.不确定的问题（可选） 说明目前尚未确定的问题及处理的计划。例如：编辑一张在软件需求规格说明中待确定问题的列表，为每一表项都是编上号的，以便于跟踪调查。 10.编写人员及编写日期 列出参与编写的人员的名字，并标明负责人。 11.附录 11.1 引用文件 没有引用文件时删除此项，否则依次列出本指南所引用的文件，如需求备忘录，需求调查报告等，如有多种，其序号使用1. 、2. 、……， 11.2 参考资料 没有参考资料时删除此项，否则依次列出本指南所引用的参考资料，如有多种，其序号使用1. 、2. 、…… Previous 使用Swagger Editor来设计和管理API文档 Next 《软件设计文档》？ |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |