软件需求规格说明书

合集下载

软件需求规格说明书完整版

软件需求规格说明书完整版

软件需求规格说明书完整版[标题:软件需求规格说明书完整版]【引言】本软件需求规格说明书旨在详细阐述软件的需求,以便团队成员能清晰了解并实施开发计划。

本文档包括以下内容:需求概述、功能需求、性能需求、界面需求、可靠性需求、安全性需求、软件质量特性评估和约束等部分。

【需求概述】笔者制定本软件需求规格说明书的目的是为了明确软件的需求,让团队成员能够准确理解、明确开发方向。

软件旨在满足用户对于XX 功能的需求,通过XX实现目标。

为了持续优化软件,让用户能够更好地体验软件,我们将充分考虑功能需求、性能需求、界面需求、可靠性需求、安全性需求和软件质量特性评估等方面。

【功能需求】本软件需要实现以下功能:1. 功能1:描述功能1的具体需求。

2. 功能2:描述功能2的具体需求。

...N. 功能N:描述功能N的具体需求。

为了保证软件的流畅运行,我们需要考虑以下性能需求:1. 性能1:描述性能1的需求,如响应时间、处理速度等。

2. 性能2:描述性能2的需求,如并发性能、负载能力等。

...N. 性能N:描述性能N的需求。

【界面需求】软件的界面需求应满足以下要求:1. 界面1:描述界面1的需求,如界面布局、元素排列等。

2. 界面2:描述界面2的需求,如颜色搭配、字体样式等。

...N. 界面N:描述界面N的需求。

【可靠性需求】为了确保软件的可靠性,我们需要考虑以下方面:1. 可靠性1:描述可靠性1的需求,如错误处理、数据完整性等。

2. 可靠性2:描述可靠性2的需求,如灾备恢复、故障处理等。

...N. 可靠性N:描述可靠性N的需求。

为了保护用户数据和软件安全,我们需要考虑以下安全性需求:1. 安全性1:描述安全性1的需求,如访问控制、数据加密等。

2. 安全性2:描述安全性2的需求,如用户认证、防止攻击等。

...N. 安全性N:描述安全性N的需求。

【软件质量特性评估】为了保证软件质量,我们将评估以下特性:1. 质量特性1:描述质量特性1的评估方法和要求,如可维护性、易扩展性等。

软件需求规格说明书

软件需求规格说明书

软件需求规格说明书什么是软件需求规格说明书?在软件开发过程中,软件需求规格说明书是一份非常重要的文档。

顾名思义,它是用来记录软件需求的详细说明书。

软件需求规格说明书是指开发者或用户根据需求收集的所有信息,包括软件的功能、性能、安全、可维护性、可移植性、接口要求、开发环境和测试要求等方面,然后将这些内容记录下来,形成一份需求文档。

为什么需要软件需求规格说明书?软件需求规格说明书对于软件开发团队来说非常重要,因为它确保了软件的成功开发和交付。

它为软件开发过程提供了指导,防止开发者和用户之间出现误解和乱码。

还可以避免返工和浪费的情况,提高工作效率,降低产品开发的风险。

在软件开发之前,软件开发团队必须制定出一个全面、清晰明确的软件需求规格说明书,以确保所有涉及方面的需求得到记录和考虑。

这份文档还可以辅助编写测试用例,并为软件开发和测试过程提供一个基准,确保软件最终符合用户所期望的要求,并且可以满足业务需求。

如何编写软件需求规格说明书?编写一份有效的软件需求规格说明书不是一件容易的事情。

在编写这份文档时,必须紧紧把握着用户需求,以确保所有的指标和要求都被记录下来。

以下是一些编写软件需求规格说明书的指导原则:1. 归纳总结用户需求:首先,应该对用户的需求归纳总结,在将其写入软件需求规格说明书前加以整理和梳理,确保其充分、具体、清晰明了。

2. 尽可能的详细:该文档要求都要尽可能详细,这样可以为后续的软件开发、测试、维护等工作提供充分的信息。

3. 避免使用模糊的语言和术语:规格说明书应该避免使用模糊的语言和术语,所有描述都必须明确清晰。

4. 定义术语表:如有必要,可以提前定义术语表,以便在说明文档中使用。

5. 添加实例和解释:在说明文档中可以添加一些实例和解释,这可以为读者提供更好的理解和方便。

6. 与用户沟通:开发者和用户应该在说明文档中进行充分的沟通和交流,以确保所记录的内容足够充分和有效。

总结软件需求规格说明书是一项必要的文档,用来记录软件需求的详细说明。

软件需求规格说明书模板

软件需求规格说明书模板

软件需求规格说明书模板1. 引言
1.1 目的
1.2 范围
1.3 定义、缩略语和缩写词
1.4 参考资料
2. 总体描述
2.1 产品前景
2.2 产品功能
2.3 用户特征
2.4 约束和限制
2.5 假设和依赖关系
3. 具体需求
3.1 功能需求
3.1.1 功能需求 1
3.1.2 功能需求 2
3.1.3 ...
3.2 性能需求
3.2.1 性能需求 1
3.2.2 性能需求 2
3.2.3 ...
3.3 可靠性需求
3.3.1 可靠性需求 1 3.3.2 可靠性需求 2 3.3.3 ...
3.4 可支持性需求
3.4.1 可支持性需求 1 3.4.2 可支持性需求 2 3.4.3 ...
3.5 其他需求
3.5.1 安全需求
3.5.2 可用性需求
3.5.3 文档需求
3.5.4 ...
4. 验证需求
4.1 验证需求的方法和工具
4.2 验证需求的计划
5. 附录 A: 术语表
6. 附录 B: 参考文献
注意:以上仅为一个软件需求规格说明书模板的示例,实际应根据
具体情况进行适当修改和补充。

请在编写内容时参考所需软件的具体
要求,确保规格说明书的准确性和完整性。

(以上仅为文章的正文部分,已根据题目进行格式化。

标题、目录、页眉等内容需要根据实际情况自行添加。

希望这个模板对您有所帮助。

如有其他需要,请随时告知。

)。

软件需求规格说明书

软件需求规格说明书

文档编号:sm/cmmi/1103/系统软件需求规格说明书<版本号>编写人:编写日期:部门:审核人:审核日期:1.引言SRS的引言部分应当提供整个SRS的概述,包括以下各条:a目的;b范围;c定义、简称和缩略语;d引用文件;e综述.1.1.目的本条宜:a描述SRS的目的;b说明SRS的预期读者.1.2.范围本条宜:a通过名称识别要生产/开发的软件产品;b必要时,说明软件产品将做或不做什么;c描述规定的软件的应用,包括相关的收益、目标和目的;d如果上层规格说明如,系统需求规格说明存在,与上层规格说明类似的陈述保持一致.1.3.定义、简写和缩略词本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义,这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供.在本节应对需求的编号规则进行约定.1.4.引用文件本条宜:a提供SRS引用的所有文件的完整清单;b标识出每个文件的名称、报告编号适用时、日期、出版组织;c标明可以获得引用文件的来源.这些信息可以通过引用附录或引用其他文档的方式提供.1.5.综述本条宜:a描述SRS的其余章条包含的内容;b说明SRS是如何组织的.2.总体描述本章宜描述影响产品及其需求的一般因素,而不叙述具体的需求.相反,它提供需求的背景并使它们更易理解,而在SRS的后续章节将详细定义这些需求.本章通常由以下6条组成:a产品描述;b产品功能;c用户特点;d约束;e假设和依赖关系;f需求分配.2.1.产品描述本条宜把产品置于其他有关产品的全景之下.如果产品是独立的和完全自我包含的,这里宜如实给予陈述.正如常出现的那样,如果SRS定义的产品是较大系统的组成部分,则本章宜将软件的功能性与较大系统的需求相联系,而且宜识别软件和系统之间的接口.使用框图展示较大系统的主要部分、相互联系以及外部接口是有帮助的.本条也宜描述在各种不同的约束下软件如何运行.如,这些约束可包括:a运行环境;b用户界面;c接口;d运行模式;e现场适应性需求等.2.2.产品功能本条宜给出软件将执行主要功能的概要.例如,某个同城程序的SRS可在此部分关注业务发起、资金清算处理,而不涉及这些功能要求的大量细节.有时,本条需要的功能概要可直接从分配具体功能到软件产品的更高层规格说明如果存在中摘录.为了清晰,应当注意:a功能说明应以使顾客或第一次阅读该文件的任何读者对功能列表容易理解;b可以使用文本或图示的方法,显示不同的功能及其之间的关系.这样的图示不必显示产品的设计,但简要显示功能之间的逻辑关系.2.3.用户特点本条宜给出软件产品预期用户的一般特征,包括部门、角色、权限等.本条所说用户包括系统的隐含用户,例如银行客户.2.4.需求分配本条宜识别可能推迟到系统将来版本的需求.3.具体需求本章宜包括足够详细的所有软件需求,使设计人员能够设计系统以满足这些需求,并且使测试人员能够测试该系统满足这些需求.贯穿本章,对于用户、运行人员或其他外部系统,每个规定的需求应当是外部可理解的.这些需求至少应当包括,每个系统输入激励、每个系统输出响应以及系统通过响应某个输入或支持某个输出所执行的所有功能.对软件功能应根据软件的特征对需求项目进行适当的组织.就面前我公司多数项目而言,应根据软件功能的层次进行组织.对每一项需求应进行唯一编号.主要需求项目编号规则如下:其他类型的需求可在节中定义后使用.对于有层级关系的需求,可用以下方式进行表示:FC_1…FC_2…具体需求分为以下几个部分:3.1.功能需求功能需求宜定义软件在接收和处理输入以及处理和产生输出中必须发生的基本动作.一般情况下使用“系统应……”的方式来陈述.这些包括:a操作的流程;b输入与输出,包括:1数据的来源及输入/输出方式2从输入到输出转换的处理过程3输入/输出界面格式如有的话,例如生成的报表的格式c对输入有效性的核查;d访问的数据对象如数据表及对数据的修改e异常情况响应,包括:1溢出;2错误处理和恢复;尽管将功能需求划分为子功能或子过程可能是适当的,但这并不意味着软件设计同样以这样的方式划分.3.1.1.业务功能1需求编号:FC_0001需求概述:本功能用于实现xxxxxxxx功能优先级:高/中/低3.1.1.1.业务规则以自然语言形式对需求项所必须遵循的处理原则进行说明.形式如:系统应该xxxxxxxxxxxxxxx如xxxxxxxxxxxx,则xxxxxxxxxxx3.1.1.2.前置条件指功能需求进入执行状态需满足的各种条件.以同城系统中“工作场次切换”为例,其前置条件为系统时间到达预先设定的场次终止时间.3.1.1.3.输入包括输入数据的来源、格式、数据要求等3.1.1.4.处理流程以自然语言或流程图、或两者结合的形式描述功能项的处理流程.对处理流程的描述应包括正常处理流程及各种可能的异常处理流程.3.1.1.5.输出完成处理后的数据输出.包括格式、数据要求等.3.1.1.6.后置条件当功能项处理流程结束后产生的处理结果.针对不同的处理流程正常/异常,应分别说明.3.1.1.7.用户界面用草图或屏幕快照的形式展现界面.尽可能使用连串图的形式.3.1.2.业务功能n3.2.性能需求本条宜规定软件或人与软件互作用的整体静态的和动态的数量化需求.静态数量化需求可能包括:a支持的终端数量;b支持同时运行的交易并发数量;c要处理的信息量和类型.有时,静态数量需求包含在命名为“能力”的独立部分.动态数量化需求可能包括,如,在正常和高峰工作负载条件,在某时段内处理的事务处理数、任务数和数据量.所有这些需求宜以可测量的方式规定.如:应在小于is内处理95%的交易量.而不是:操作方不需等待事务处理结束.注:适用于某个具体功能的数量化限制,通常作为该功能处理描述部分予以规定.3.3.系统可靠性及安全性需求有一些软件属性可以作为需求.规定所要求的软件属性是重要的,这样才能客观地验证属性的实现情况.具体包括以下内容:a可靠性本条宜规定要求的因素,以便建立在交付时软件系统所要求的可靠性.b可用性为了确保整个系统已定义的可用性程度,宜规定所要求的因素,如,检查点、恢复以及重启动.c安全保密性由于事故、恶意访问、使用、修改、破坏或泄露,本条宜规定需要保护软件的因素.这方面可能的具体需求包括:1使用某些密码技术;2保留某些特定数据组的历史或记录;3分配某些功能到不同的模块;4在程序的某些域间限制通信;5对于关键变量检查数据的完整性.d可维护性本条宜规定与软件本身维护简易性有关的软件属性.可以对模块化、接口和复杂性等有一定的要求.但不宜仅因为是良好设计实践就将其作为需求.e可移植性本条宜规定与软件移植到其他主机和/或操作系统简易性相关的软件属性.这可能包括:1依赖主机代码模块的百分比;2依赖主机代码的百分比;3已证明可移植语言的使用;4特定编译器或语言子集的使用;5特定操作系统的使用.每一项可作为一个小节3.4.其他需求。

软件需求规格说明书

软件需求规格说明书

软件需求规格说明书一、引言本文档旨在详细描述软件需求规格,以确保软件开发团队和客户之间的沟通准确无误。

本规格说明书适用于XXX软件项目,包括对软件的功能、性能、界面和其他相关需求的详细描述。

二、目标本软件旨在满足以下目标:1. 提供一个功能强大、易于使用的软件平台,以满足客户的需求。

2. 提供高效的性能和稳定的运行环境,以确保用户的体验。

3. 提供清晰、友好的用户界面,以便用户能够轻松使用软件。

4. 提供可靠的数据存储和管理功能,以确保数据的完整性和安全性。

三、功能需求1. 用户管理1.1 用户注册:用户可以通过提供必要的个人信息进行注册。

1.2 用户登录:已注册用户可以使用用户名和密码登录系统。

1.3 用户权限管理:根据用户角色和权限,对用户进行管理和控制。

2. 数据管理2.1 数据录入:用户可以录入、修改和删除数据。

2.2 数据查询:用户可以根据特定条件查询数据。

2.3 数据导出:用户可以将数据导出为Excel或其他格式的文件。

3. 报表生成3.1 报表定义:用户可以定义报表的格式和内容。

3.2 报表生成:根据用户定义的报表格式和内容,生成相应的报表。

4. 通知和提醒4.1 通知管理:系统可以向用户发送通知和提醒。

4.2 提醒设置:用户可以设置提醒的方式和频率。

5. 系统设置5.1 用户管理:管理员可以管理用户信息和权限。

5.2 界面设置:用户可以自定义界面的样式和布局。

5.3 系统维护:管理员可以进行系统备份、恢复和升级。

四、性能需求1. 响应时间:系统应在用户进行操作后的2秒内给出响应。

2. 并发性能:系统应支持1000个并发用户的正常操作。

3. 数据处理能力:系统应能够处理每秒1000条数据的输入和输出。

五、界面需求1. 用户界面:界面应简洁、直观,符合用户使用习惯。

2. 响应式设计:界面应能够在不同的设备和屏幕尺寸上正常显示和操作。

3. 多语言支持:界面应支持多种语言切换。

六、安全需求1. 用户认证:用户登录时应进行身份验证,确保只有合法用户可以访问系统。

软件需求规格说明书模板

软件需求规格说明书模板

XXX软件需求规格说明书{产品名称} 软件需求规格说明书版本历史第0 页目录1.产品描述 (3)1.1.编写目的 (3)1.2.产品名称 (3)1.3.文档范围 (3)1.4.预期的读者和阅读建议 (3)1.5.参考文档 (3)1.6.缩略语和术语(可选) (3)2.产品需求概述 (3)2.1.用例简介 (3)2.2.运行环境 (3)2.3.条件与限制(可选) (4)3.用例描述 (4)3.1.用例1 (4)3.2.用例N (5)3.3.不支持的用例 (5)4.数据描述 (5)5.系统需求(可选) (5)6.运行需求(可选) (6)6.1.用户界面 (6)6.2.硬件接口 (6)6.3.软件接口 (6)6.4.通信接口 (6)7.其它需求(可选) (7)8.特殊需求(可选) (7)9.不确定的问题(可选) (7)10.编写人员及编写日期 (7)11.附录 (7)11.1.引用文件 (7)11.2.参考资料 (7)1.产品描述1.1.编写目的【说明编写本软件需求规格说明书的目的,指出预期的读者。

】1.2.产品名称【本项目的名称,包括项目的全名、简称、代号、版本号。

】1.3.文档范围【文档范围包括:产品介绍,产品面向的用户群体,产品应当遵守的标准与规范,产品范围,产品中的角色,产品的功能性需求,产品的非功能性需求。

】1.4.预期的读者和阅读建议【各种管理人员及开发人员:项目经理、系统工程师、软件开发人员、硬件开发人员、测试人员、型态管理人员、品质保证人员和软件使用客户】1.5.参考文档【说明编写本软件需求规格说明书涉及参考文档。

】1.6.缩略语和术语(可选)【对重要的或是具有特殊意义的名词(包括词头和缩写)进行定义,以便读者可以正确地解释软件需求说明。

】2.产品需求概述2.1.用例简介【对产品的基本用例做一个简介,包括:1.本产品的开发意图、应用目标及作用范围。

2.概略介绍了产品所具有的主要用例。

用UML用例包图和用例图描述功能结构。

软件需求规格说明书

软件需求规格说明书

软件需求规格说明书背景每个项目都需要软件来支持它的功能需求。

软件需求规格说明书描述了软件的功能需求,性能需求和软件约束。

开发团队使用此文档以确保完成一致的软件开发和测试。

定义软件需求规格说明书是一份详细的文件,描述软件的需求,包括要求和功能、性能和限制。

流程软件需求规格说明书的编写需要一些步骤:确定并编写关于所需软件的所有功能需求。

为所需软件编写约束文件,例如可用性、性能、安全性等。

组织并记录所需的所有信息。

分析数据以获得可执行项目的计划和步骤表。

记录并跟踪所有变化,以确保变化正确地反映在最新版本的文档中。

主要内容下面是软件需求规格说明书需要列明的基本部分:介绍将任务及其目标的简短描述与项目所涉及的人员和组织部门相关联。

支持的环境列出所有计算机、操作系统、其他设备(如打印机)和任何必需的软件。

也可以说明所需的任何其他特定硬件或软件。

功能需求描述软件的所有功能—必需和可选。

对于每个功能,提供一个简短描述和特定的用户需求,包括必需的输入和输出信息。

性能需求描述软件的性能特性和要求。

这通常包括响应时间、吞吐量和容量。

还可以包括在特定条件下的可靠性、可用性、可维护性和可支持性。

设计要求在这部分中,可以说明可能对实施绩效和其他特定要求的设计决策要求。

例如,可以规定哪些特定编程代码方案必须使用。

用户和培训要求说明用户和培训问题。

可以包括用户文档、培训材料、通信、认证和其他要求。

支持需求说明必需的支持,例如用户支持、维护和更新。

安全性要求说明所需的安全性要求,包括安全控制、应急响应和其他安全问题。

其他约束还可以列明其他必需的约束,例如法律和通信要求,行业要求,国家规定等。

结论软件需求规格说明书是一个重要的文档,用于规范软件开发团队的计划和步骤。

它应该被认真研究和编写,以确保软件开发和测试符合规范和要求。

软件需求规格说明书格式规范

软件需求规格说明书格式规范

软件需求规格说明书格式规范一、引言软件需求规格说明书旨在详细描述软件系统的需求,并为软件开发团队提供具体的指导。

本文档将按照以下格式规范进行编写。

二、文件头部1. 文档标题:需求规格说明书(软件名称)2. 文档编号:XXXXXXXX3. 版本号:1.04. 编写日期:XXXX年XX月XX日三、文档概述(此部分简要介绍软件的背景、目标和范围,不超过300字)四、功能需求(按照模块或功能点进行分类,详细描述软件的功能需求。

可以使用表格或列表来清晰地列出每个功能的描述、输入、输出以及相关约束条件)五、性能需求(详细描述软件的性能需求,包括但不限于响应时间、处理能力、可扩展性等。

可以使用表格或列表进行描述)六、界面需求(描述软件的用户界面需求,包括但不限于界面设计、布局、颜色和图标等。

可以使用截图或示意图来更加清晰地展示)七、数据需求(详细描述软件的数据需求,包括所需数据的类型、格式、存储位置、访问权限等。

可以使用表格或列表进行描述)八、安全需求(描述软件的安全需求,包括但不限于用户身份验证、数据加密、权限管理等。

可以使用表格或列表进行描述)九、软件质量特性需求(描述软件的质量属性需求,包括但不限于可靠性、可维护性、可测试性等。

可以使用表格或列表进行描述)十、其他非功能性需求(描述软件的其他非功能性需求,包括但不限于兼容性、易用性、国际化等。

可以使用表格或列表进行描述)十一、需求确认与验收标准(描述如何对软件需求进行确认和验收,可以使用表格或列表进行描述)十二、变更记录(记录需求规格说明书的变更历史,包括版本号、修改日期、修改内容等)十三、附录(提供软件需求文档中所用到的相关术语、缩略词的解释)以上是软件需求规格说明书的格式规范,按照此格式撰写的文档能够清晰、准确地描述软件的需求,为开发团队提供指导,确保软件开发过程的顺利进行。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件需求规格说明(SRS)(用例模型、领域模型、行为模型)用例模型:用例图+用例描述(3-5个)领域模型:不带操作的类图行为模型:1、交互图(时序图 3个)2、行为图(状态图2个,1个画系统的状态图,1个画类/对象的状态图;活动图2个,1个画系统的业务流程;1个画某个类的方法的计算流程。

说明:1.《软件需求规格说明》(SRS)描述对计算机软件配置项CSCI的需求,及确保每个要求得以满足的所使用的方法。

涉及该CSCI外部接口的需求可在本SRS中给出:或在本SRS 引用的一个或多个《接口需求规格说明》(IRS)中给出。

2.这个SRS,可能还要用IRS加以补充,是CSCI设计与合格性测试的基础。

软件需求规格说明的正文的格式如下:1围本章应分为以下几条。

1.1标识本条应包含本文档适用的系统和软件的完整标识,(若适用)包括标识号、标题、缩略词语、版本号和发行号。

1.2系统概述本条应简述本文档适用的系统和软件的用途,它应描述系统和软件的一般特性;概述系统开发、运行和维护的历史;标识项目的投资方、需方、用户、开发方和支持机构;标识当前和计划的运行现场;列出其他有关的文档。

1.3文档概述本条应概述本文档的用途和容,并描述与其使用有关的性或私密性要求。

1.4基线说明编写本系统设计说明书所依据的设计基线。

2引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期,也应标识不能通过正常的供货渠道获得的所有文档的来源。

3需求本章应分以下几条描述CSCI需求,也就是,构成CSCI验收条件的CSCI的特性。

CSCI 需为了满足分配给该CSCI的系统需求所形成的软件需求。

给每个需求指定项目唯一标识符以支持测试和可追踪性。

并以一种可以定义客观测试的方式来述需求。

如果每个需求有关的合格性方法(见第4章)和对系统(若适用,子系统)需求的可追踪性(见5.a条)在相应的章中没有提供,则在此进行注解。

描述的详细程度遵循以下规则:应包含构成CSCI验收条件的那些CSCI特性,需方愿意推迟到设计时留给开发方说明的那些特性。

如果在给定条中没有需求的话,本条应如实述。

如果某个需求在多条中出现,可以只述一次而在其他条直接引用。

3.1所需的状态和方式如果需要CSCI在多种状态和方式下运行,且不同状态和方式具有不同的需求的话,则要标识和定义每一状态和方式,状态和方式的例子包括:空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。

状态和方式的区别是任意的,可以仅用状态描述CSCI,也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。

如果不需要多个状态和方式,不需人为加以区分,应如实述;如果需要多个状态或方式,还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联,关联可在本条或本条引用的附录中用表格或其他的方法表示,也可在需求出现的地方加以注解。

3.2需求概述3.2.1目标a.本系统的开发意图、应用目标及作用围(现有产品存在的问题和建议产品所要解决的问题)。

b.本系统的主要功能、处理流程、数据流程及简要说明。

c.表示外部接口和数据流的系统高层次图。

说明本系统与其他相关产品的关系,是独立产品还是一个较大产品的组成部分(可用方框图说明)。

3.2.2运行环境简要说明本系统的运行环境(包括硬件环境和支持环境)的规定。

3.2.3用户的特点说明是哪一种类型的用户,从使用系统来说,有些什么特点。

3.2.4关键点说明本软件需求规格说明书中的关键点(例如:关键功能、关键算法和所涉及的关键技术等)。

3.2.5约束条件列出进行本系统开发工作的约束条件。

例如:经费限制、开发期限和所采用的方法与技术,以及政治、社会、文化、法律等。

3.3需求规格3.3.1软件系统总体功能/对象结构对软件系统总体功能/对象结构进行描述,包括结构图、流程图或对象图。

3.3.2软件子系统功能/对象结构对每个主要子系统中的基本功能模块/对象进行描述,包括结构图、流程图或对象图。

3.3.3描述约定通常使用的约定描述(数学符号、度量单位等)。

3.4 CSCI能力需求本条应分条详细描述与CSCI (Computer Software Configuration Item-计算机软件配置项)每一能力相关联的需求。

“能力”被定义为一组相关的需求。

可以用“功能”、“性能”、“主题”、“目标”或其他适合用来表示需求的词来替代“能力”。

3.4.x (CSCI能力)本条应标识必需的每一个CSCI能力,并详细说明与该能力有关的需求。

如果该能力可以更清晰地分解成若干子能力,则应分条对子能力进行说明。

该需求应指出所需的CSCI行为,包括适用的参数,如响应时间、吞吐时间、其他时限约束、序列、精度、容量(大小/多少)、优先级别、连续运行需求、和基于运行条件的允许偏差:(若适用)需求还应包括在异常条件、非许可条件或越界条件下所需的行为,错误处理需求和任何为保证在紧急时刻运行的连续性而引人到CSCI中的规定。

在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时,应考虑在本文3.5.x给出要考虑的主题列表。

对于每一类功能或者对于每一个功能,需要具体描写其输入、处理和输出的需求。

a.说明描述此功能要达到的目标、所采用的方法和技术,还应清楚说明功能意图的由来和背景。

b.输入包括:1)详细描述该功能的所有输入数据,如:输入源、数量、度量单位、时间设定和有效输入围等。

2)指明引用的接口说明或接口控制文件的参考资料。

c.处理定义对输入数据、中间参数进行处理以获得预期输出结果的全部操作。

包括:1)输入数据的有效性检查。

2)操作的顺序,包括事件的时间设定。

3)异常情况的响应,例如,溢出、通信故障、错误处理等。

4)受操作影响的参数。

5)用于把输入转换成相应输出的方法。

6)输出数据的有效性检查。

d.输出1)详细说明该功能的所有输出数据,例如,输出目的地、数量、度量单位、时间关系、有效输出围、非法值的处理、出错信息等。

2)有关接口说明或接口控制文件的参考资料。

3.5 CSCI外部接口需求本条应分条描述CSCI外部接口的需求。

(如有)本条可引用一个或多个接口需求规格说明(IRS)或包含这些需求的其他文档。

外部接口需求,应分别说明:a.用户接口;b.硬件接口;c.软件接口;d.通信接口的需求。

3.5.1接口标识和接口图本条应标识所需的CSCI外部接口,也就是CSCI和与它共享数据、向它提供数据或与它交换数据的实体的关系。

(若适用)每个接口标识应包括项目唯一标识符,并应用名称、序号、版本和引用文件指明接口的实体(系统、配置项、用户等)。

该标识应说明哪些实体具有固定的接口特性(因而要对这些接口实体强加接口需求),哪些实体正被开发或修改(从而接口需求已施加给它们)。

可用一个或多个接口图来描述这些接口。

3.5.x(接口的项目唯一标识符)本条(从3.5.2开始)应通过项目唯一标识符标识CSCI的外部接口,简单地标识接口实体,根据需要可分条描述为实现该接口而强加于CSCI的需求。

该接口所涉及的其他实体的接口特性应以假设或“当[未提到实体]这样做时,CSCI将……”的形式描述,而不描述为其他实体的需求。

本条可引用其他文档(如:数据字典、通信协议标准、用户接口标准)代替在此所描述的信息。

(若适用)需求应包括下列容,它们以任何适合于需求的顺序提供,并从接口实体的角度说明这些特性的区别(如对数据元素的大小、频率或其他特性的不同期望):a.CSCI必须分配给接口的优先级别;b.要实现的接口的类型的需求(如:实时数据传送、数据的存储和检索等);c.CSCI必须提供、存储、发送、访间、接收的单个数据元素的特性,如:1)名称/标识符;a)项目唯一标识符;b)非技术(自然语言)名称;c)标准数据元素名称;d)技术名称(如代码或数据库中的变量或字段名称);e)缩写名或同义名;2)数据类型(字母数字、整数等);3)大小和格式(如:字符串的长度和标点符号);4)计量单位(如:米、元、纳秒);5)围或可能值的枚举(如:0-99);6)准确度(正确程度)和精度(有效数字位数);7)优先级别、时序、频率、容量、序列和其他的约束条件,如:数据元素是否可被更新和业务规则是否适用;8)性和私密性的约束;9)来源(设置/发送实体)和接收者(使用/接收实体);d.CSCI必须提供、存储、发送、访问、接收的数据元素集合体(记录、消息、文件、显示和报表等)的特性,如:1)名称/标识符;a)项目唯一标识符;b)非技术(自然语言)名称;c)技术名称(如代码或数据库的记录或数据结构);d)缩写名或同义名;2)数据元素集合体中的数据元素及其结构(编号、次序、分组);3)媒体(如盘)和媒体中数据元素/数据元素集合体的结构;4)显示和其他输出的视听特性(如:颜色、布局、字体、图标和其他显示元素、蜂鸣器以及亮度等);5)数据元素集合体之间的关系。

如排序/访问特性;6)优先级别、时序、频率、容量、序列和其他的约束条件,如:数据元素集合体是否可被修改和业务规则是否适用;7)性和私密性约束;8)来源(设置/发送实体)和接收者(使用/接收实体);e.CSCI必须为接口使用通信方法的特性。

如:1)项目唯一标识符;2)通信/带宽/频率/媒体及其特性;3)消息格式化;4)流控制(如:序列编号和缓冲区分配);5)数据传送速率,周期性/非周期性,传输间隔;6)路由、寻址、命名约定;7)传输服务,包括优先级别和等级;8)安全性/性/私密性方面的考虑,如:加密、用户鉴别、隔离和审核等;f.CSCI必须为接口使用协议的特性,如:1)项目唯一标识符;2)协议的优先级别/层次;3)分组,包括分段和重组、路由和寻址;4)合法性检查、错误控制和恢复过程;5)同步,包括连接的建立、维护和终止;6)状态、标识、任何其他的报告特征;g.其他所需的特性,如:接口实体的物理兼容性(尺寸、容限、负荷、电压和接插件兼容性等)。

3.6 CSCI部接口需求本条应指明CSCI部接口的需求(如有的话)。

如果所有部接口都留待设计时决定,则需在此说明这一事实。

如果要强加这种需求,则可考虑本文档的3.5给出的一个主题列表。

3.7 CSCI部数据需求本条应指明对CSCI部数据的需求,(若有)包括对CSCI中数据库和数据文件的需求。

如果所有有关部数据的决策都留待设计时决定,则需在此说明这一事实。

如果要强加这种需求,则可考虑在本文档的3.5.x.c和3.5.x.d给出的一个主题列表。

3.8适应性需求(若有)本条应指明要求CSCI提供的、依赖于安装的数据有关的需求(如:依赖现场的经纬度)和要求CSCI使用的、根据运行需要进行变化的运行参数(如:表示与运行有关的目标常量或数据记录的参数)。

相关文档
最新文档