1. 首页 > 智能数码 >

需求规格说明书版本 需求规格说明书版本怎么填

在软件开发中,需求规格说明书和系统设计说明书有什么区别?

1、内容有区别

需求规格说明书版本 需求规格说明书版本怎么填需求规格说明书版本 需求规格说明书版本怎么填


需求规格说明书主要是描述软件系统应该完成的功能,包含硬件、功能、性能、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等。

设计说明书是说明如何实现这些功能、性能的。设计书中会对功能进行重新的分解,并需要描述这些功能如何实现,甚至包括如何用代码实现。

2、目的不同

需求规格说明书的作用在于便于用户、开发人员进行理解和交流,反映出用户问题的结构,可以作为软件开发工作的基础和依据,并作为确认测试和验收的依据。

系统设计说明书编制的目的是说明对程序系统的设计考虑,包括程序系统的基本处理流程、程序系统的组织结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等,为程序的详细设计提供基础。

3、阅读对象不同

需求规格说明书主要从用户角度(需求或市场人员根据用户要求编写)描述软件需要实现的功能。

系统设计说明书主要从软件开发(程序员)角度描述软件需要实现功能。

参考资料:百度百科-软件需求说明书

参考资料:百度百科-概要设计说明书

什么是需求规格?

需求规格是系统需求主要是对内的。而且需求管理的时候也需要用到用户需求

是给程序员看的,这个东西少不得, 做的详细点是对自己负责, 后期意义重大需求阶段的工作主要分为两个方面,为“需求开发”和“需求管理”。

按经验来讲

需求分析报告:一般是对某个市场或者是客户群来讲的,类似于调研报告,重点是体现出产品要满足哪些功能,哪些是重点、热点。

需求说明书:是根据与现场实际客户进行沟通,把客户的需求进行整理,CMMI中有标准的模板,重点是站在客户的角度讲产品功能。

需求规格说明书:是从业务规则讲起的,细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能,里面要包含原型界面、业务接口、活动图等。

谁会写软件需求规格说明书啊?

规范化软件开发过程中的《需求说明书》的编写,使之成为整个开发工作的基础。

2 适用范围

本规范适用于集团开发项目的(软件)《需求说明书》的编写。

3 编写内容提示

1 引言

3.1.1 背景说明

说明被开发软件的名称,任务提出者,用户及实现该软件的计算机网络。

3.1.2 参考资料

列出有关资料(名称,发表日期,出版单位,作者等)。

3.1.3 术语和缩写词

列出本文件中用到的专门术语的定义,及术语缩写词。

3.2 软件总体概述

3.2.1 目标

软件开发的意图、应用目标、作用范围以及需说明背景材料。

3.2.2 系统模型

图示说明该软件的所有功能及其相互关系和数据传递情况。

3.2.3 假设和约束

说明影响软件开发、运行环境和系统能力(如预告出错类型的能力)的某些假设和约束。3.3 详细需求

详细描述此软件系统的功能需求和性能需求。

3.3.1 功能需求

对系统中每一个功能,要详细描述(图示或文字)。

概述 叙述功能名称,目标和作用。

输入 输入该功能的信息。

处理 描述该功能做什么,如何对输入信息进行加工并转换成输出信息。

输出 列出内部生成的文件。

3.3.2 性能需求

定量地描述此软件系统应满足的具体性能需求。可考虑以下方面:

3.3.2.1精度

说明系统的精度要求,如:

数据的精度要求。

数字计算的精度要求。

数据传送的误码率要求。

3.3.2.2 时间特性

说明系统的时间特性要求,如:

解题时间。

询问和更新数据文件的响应时间。

系统各项功能的顺序关系。

3.3.2.3 灵活性

说明当需求发生某些变化时系统的适应能力,指出为适应这些变化而需要设计的软件成分和过程。

3.3.2.4系统容量

包括系统的设计容量和理论(计算)容量。

3.3.3 输入和输出

解释各输入输出数据类型,并逐项说明某媒体、格式、数值范围等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。

3.3.4 数据管理能力

说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作估算。

3.3.5 故障处理

列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。

3.4 环境

描述所开发软件运行所需的环境。

3.4.1 设备环境

描述运行软件系统所需的设备能力,如:

处理器的型号和内存容量。

存储媒体的数量。

通信网络(包括说明网络结构,线路速度及通讯协议等)。

3.4.2 支持软件环境

列出与待开发的软件互相配合的支持软件(包括名称,版本号和文件资料),必要时还应列出测试软件,还要指出该软件用的编程语言,编译程序,作系统和数据管理系统。

3.4.3 接口

说明本软件与其他软件之间的接口、数据通信协议等。

3.4.4其他

说明本软件系统在安全和保密方面的要求以及用户对使用方便、可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求。

软件工程需求分析的模板

需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的

基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制,软件需求规格说明不应该包括设计、构造、测试或工程管理的细

节。

1)采用软件需求规格说明模版:

采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注

意,其目的并非是创建一种全新的模板,而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准

830-1998(IEEE 1998)描述的需求规格说明书模板。要相信模板是很有用的,但有时要根据项目特点进行适当的改动。

12

34

56

A引言

目的

文档约定

预期的读者和阅读建议

产品的范围

参考文献

B综合描述

产品的前景

产品的功能

用户类和特征

运行环境

设计和实现上的限制

假设和依赖附录

C外部接口需求附录

用户界面附录

硬件接口

软件接口

通信接口

D系统特性

说明和优先级

激励/响应序列

功能需求

E 其它非功能需求

性能需求

安全设施需求

安全性需求

软件质量属性

业务规则

用户文档

F其它需求

G附件

词汇表

分析模型

待确定问题的列表

表2 需求规格说明模板

a. 引言

引言提出了对软件需求规格说明的纵览,这有助于读者理解文档如何编写并且如何阅读和解释。

a . 1 目的

对产品进行定义,在该文档中详尽说明了这个产品的软件需求,包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系,那么就只定义文档中说明的部分或子系统。

a.2 文档约定

描述编写文档时所采用的标准或排版约定,包括正文风格、提示区或重要符号。

a.3 预期的读者和阅读建议

列举了软件需求规格说明所针对的不同读者,例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了适合于每一类型读者阅读文档的建议。

a.4 产品的范围

提供了对指定的软件及其目的的简短描述,包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容到这里。

软件需求规格说明书和系统需求规格说明书的区别

国内软件需求的书籍比较少,而且不是很全面。下面是我在美国看的软件需求的一本书上的对于软件需求的分层种类。希望对你有所帮助。

Requirements Level Classification(需求的分类)

To deal with the diversity in requirements types, Sommerville (2005) suggests

organizing them into three levels of abstraction:

User requirements

System requirements

Software design specifications

User requirements(用户需求) are abstract statements written in natural language with

accompanying informal diagrams. They specify what services (user functionality)

the system is expected to provide and any constraints. In many situations user stories

can play the role of user requirements.

System requirements(系统需求) are detailed descriptions of the services and constraints.

System requirements are sometimes referred to as functional specification or technical

annex. These requirements are derived from ysis of the user requirements.

They act as a contract between client and contractor, so they should be

structured and precise. Use cases can play the role of system requirements in

many situations.

Software design specifications(软件需求) emerge from the ysis and design

documentation used as the basis for implementation by developers. The software

specification is essentially derived directly from ysis of the system specification.

The software requirements specification document (SRS) is the “contractual” document

that we generally refer to when we speak of a “software” or “system” requirements

specification.In the case of a hybrid hardware/software system,(考虑软件和硬件系统) the SRS would include both detailed design elements for the software as well as hardware

(e.g., schematic diagrams and logic diagrams). In the case of a purely mechanical

system, design drawings take the place of the SRS.

没区别。不同叫法而已,开发流程是这样的:分配需求->软件规格说明->概要设计->详细设计->coding->test->release。

《软件需求规格说明书》的目的?

《软件需求规格说明书》的目的是作为用户和软件开发人员达成的技术协议书,作为着手进行设计工作的基础和依据,系统开发完成以后,为产品的验收提供了依据。由于用户要能看得懂,并且还能发现和指出其中的错误,这对于保证软件系统的质量有很大的作用。

扩展资料:

《软件需求规格说明书》必须用统一格式的文档进行描述,为了使需求分析描述具有统一的风格,可以采用已有的且能满足项目需要的模板,也可以根据项目特点和软件开发小组的特点对标准进行适当的改动,形成自己的模板。

软件需求说明主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。软件需求说明书应该完整、一致、、无二义性,同时又要简明、易懂、易修改。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至836084111@qq.com 举报,一经查实,本站将立刻删除。

联系我们

工作日:9:30-18:30,节假日休息