软件需求规格说明书检查点
软件项目需求说明书编写规范
文件编号：版本号：发放号：项目编号：产品需求分析说明书项目名称编制人：完成日期：年月日审核人：完成日期：年月日批准人：完成日期：年月日XXXX股份有限公司版本历史文件更改记录追溯性。
目录1 引言 (1)1.1 编写目的 (1)1.2 范围 (1)1.3 定义 (1)1.4 参考资料 (1)2 项目概述 (2)2.1 产品描述 (2)2.2 产品功能 (2)2.3 用户特点 (2)2.4 一般约束 (2)2.5 假设和依据 (3)3 具体需求 (3)3.1 功能需求 (3)3.1.1 功能需求1 (3)3.1.2 功能需求2 (4)3.1.n 功能需求n (5)3.2 外部接口需求 (5)3.2.1 用户接口 (5)3.2.2 硬件接口 (5)3.2.3 软件接口 (5)3.2.4 通信接口 (6)3.3 性能需求 (6)3.4 设计约束 (6)3.4.1 其他标准的约束 (6)3.4.2 硬件的限制 (7)3.5 属性 (7)3.5.1 可用性 (7)3.5.2 安全性 (7)3.5.3 可维护性 (7)3.5.4 可转移＼转换性 (8)3.5.5 警告 (8)3.6 其他需求 (8)3.6.1 数据库 (8)3.6.2 操作 (8)3.6.3 场合适应性需求 (9)4 附录 (9)1 引言1.1 编写目的说明编写这份软件需求说明书的目的，指出预期的读者范围。
1.2 范围说明：a．待开发的软件系统的名称；b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么；c．描述所说明的软件的应用。
应当：1）尽可能精确地描述所有相关的利益、目的、以及最终目标。
2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。
1.3 定义列出本文件中用到的专门术语的定义和缩写词的原词组。
1.4 参考资料列出要用到的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。
软件项目之用户需求说明书(模板1)
XXXXXX系统用户需求说明书(V1.0)XXXXXX公司20XX年XX月'为了保证系统的可用性，软件必须采用检查点、恢复、重启动机制。
在每日9 小时、每周七日操作的情况下，本软件之可用性应在99.5%以上。
•可移植性若有可移植性要求，即要求软件能方便地从一个环境转移到另一个环境，那么应该在此明确指出，并指明转移之程序，以及界面限制等。
•其它安全与保密需求1）安全说明为防止可能发生的人员、财物或实体环境伤害而对软件设计提出的安全需求。
例如：•通过提供数据的备份和恢复功能，来保证数据文件的安全（当系统中的数据文件遭到破坏时，可以把备份数据读入系统，使系统能够继续运行）。
•通过数据库管理软件提供的各式数据备份/恢复功能，来保证数据库/表的安全。
2）保密说明保护系统免遭意外或恶意的存取、使用、修改、破坏或泄密的需求。
包括：•利用某种密码技术；•设置专门的日志或历史数据集；•给不同的模块分配不同的功能；•对一个程序中各部分之间的通讯实施限制；•对关键的量实施“检查和”校验等等。
4.6扩展性需求提示：扩展性需求描述。
4.7其他需求提示：其他需求描述。
第5章附录可附需求访谈记录表、客户调研会议纪要、调研报告等。
修订记录目录第1章文档简介I文档目的I1.1 范围1名词定义11.2 参考文件1第2章系统概述1系统介绍22.1 系统目标2系统范围22.2 系统面向用户群体2遵循的标准与规范2第3章功能需求2系统总体功能23.1 功能需求13功能/模块概述33.1.1 业务流程和业务规则3子功能133.1.2 子功能23子功能343.2 功能需求24功能/模块概述43.2.1 业务流程和业务规则4子功能143.2.2 子功能24子功能34第4章非功能需求5用户界面需求54.1 软硬件环境需求5接口需求54.2 性能需求5品质需求54.3 安全与保密需求6扩展性需求64.4 其他需求6第5章附录6第1章文档简介本章将简要地说明用户需求说明书（以下简称本说明书）的目的、范围、读者对象、名词定义和参考文件文档目的本说明书的目的在于阐明XXXXXX系统（以下简称本系统）的用户需求。
计算机软件测试题库,带答案（单选,多选,判断,问答,分析）
计算机软件测试题库,带答案（单选,多选,判断,问答,分析）计算机软件测试题(单选，多选，判断，问答，分析)(总分：150分考试时间：90分钟)班级：姓名：分数：第一大题:单选题（60分，每小题1.5分）1. 测试工程师一般分为两类：测试开发工程师和（A ）A. 软件测试工程师B. 软件开发工程师C. 通信开发工程师D. 黑盒测试工程师2. 一个完整的测试部门，一般不包含以下角色（D ）A．测试主管B．测试工程师C．测试设计人员D．培训师3. 测试工程师由不包含以下哪一类（B）A. 白盒测试技术人员B. 前台美工技术人员C. 黑盒测试技术人员D. 自动化测试技术人员4. OSI7层模型不包括下面哪一层（C）A. 物理层B. 数据链路层C. 控制层D. 网络层5. 测试工程师的能力不包括（D）A. 能够熟练应用测试方法B. 能够独立编写测试计划C. 能够独立编写测试总结分析报告D. 能够编写入侵脚本攻击软件6. 软件测试的目的是（B ）A 避免软件开发中出现的错误B 发现软件开发中出现的错误C 尽可能发现并排除软件中潜藏的错误，提高软件的可靠性D 修改软件中出现的错误7. 坚持在软件的各个阶段实施下列哪种质量保障措施，才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期（A ）。
A 技术评审B 程序测试C 改正程序错误D 管理评审8. 为了提高测试的效率，正确的做法是（ A ）。
A 选择发现错误可能性大的数据作为测试用例B 在完成程序的编码之后再制定软件的测试计划C 随机选取测试用例D 使用测试用例测试是为了检查程序是否做了应该做的事9. 以下那一种选项不属于软件缺陷（D ）。
A 软件没有实现产品规格说明所要求的功能B 软件中出现了产品规格说明不应该出现的功能C 软件实现了产品规格没有提到的功能D 软件实现了产品规格说明所要求的功能但因受性能限制而未考虑可移植性问题10. 单元测试中设计测试用例的依据是（ D ）。
软件需求规格说明书
文档编号：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.其他需求。
软件设计与开发评审检查表
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、switch/case）？ 是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
软件需求规格说明模板(GBT9385-2008)
XXX项目软件需求规格说明书XXXX20 年月日I文档信息修订历史文档编制、审核与批准目录1引言 (1)1.1 目的 (1)1.2范围 (1)1.3定义、简写和缩略语 (1)1.4引用文件 (1)II1.5综述 (2)2总体描述 (2)2.1产品描述 (2)2.1.1系统接口 (2)2.1.2用户界面 (2)2.1.3硬件接口 (3)2.1.4软件接口 (3)2.1.5通信接口 (3)2.1.6内存约束 (3)2.1.7操作 (4)2.1.8现场适应性需求 (4)2.2产品功能 (4)2.3用户特点 (4)2.4约束 (4)2.5假设和依赖关系 (5)2.6需求分配 (5)3具体需求 (5)3.1外部接口 (5)3.2功能 (6)3.3性能需求 (8)3.4数据库逻辑需求 (8)3.5设计约束 (8)3.5.1标准依从性 (8)3.6软件系统属性 (9)3.6.1可靠性 (9)3.6.2可用性 (9)3.6.3安全保密性 (9)3.6.4可维护性 (9)3.6.5可移植性 (9)3.7具体需求的组织 (10)3.7.1系统模式 (10)3.7.2用户类型 (11)3.7.3对象 (11)3.7.4特征 (11)3.7.5激励 (11)3.7.6响应 (11)3.7.7功能层次 (11)3.8附加说明 (12)4附录 (12)III1引言本部分应当提供整个SRS的概述1.1 目的本条宜：a)描述SRS的目的；b)说明SRS的预期读者。
1.2范围本条宜：a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统(DBMS)、报告生成器等）；b)必要时，说明软件产品将做或不做什么；c)描述规定的软件的应用，包括相关的收益、目标和目的；d)如果上层规格说明（如，系统需求规格说明）存在，与上层规格说明类似的陈述保持一致。
1.3定义、简写和缩略语本条宜提供对正确解释SRS所要求的所有术语、简写和缩略语的定义，这些信息可以通过引用SRS中的一个或多个附录、或者引用其他文件的方式来提供。
《软件工程》标准答案
2018年5月[0010]《软件工程》作业标准答案1、（ ）是用户和设计交换最频繁的方法。
原型化方法螺旋模型方法构件组装模型瀑布模型方法2、在人工智能领域，目前最广泛使用的高级语言是 ( )。
LISPAda FORTRANCOBOL3、模块内聚度越高，说明模块内各成分彼此结合的程度越（ ）相等 无法判断 紧密松散4、“软件危机”产生的主要原因是（）。
没有维护好软件 开发方法不当开发人员编写程序能力差 软件日益庞大5、软件维护申请报告由( )填写。
维护负责人 用户专家维护程序员6、程序语言的编译系统和解释系统相比，从用户程序的运行效率来看 ( )。
两者大致相同 前者运行效率高后者运行效率高不能确定7、软件维护是软件得以正常运行的重要环节，按照软件工程方法的理解，一般软件维护应开始于（）。
E. 查阅测试记录分析软件结构阅读设计文档理解程序代码8、软件设计中划分模块的一个准则是（）。
低内聚高耦合高内聚低耦合低内聚低耦合高内聚高耦合9、维护阶段产生的文档包括( )。
开发进度报告软件问题报告维护申请报告软件修改报告10、从工程管理的角度来看，软件设计分两步完成（）系统分析、模块设计总体设计、详细设计详细设计、总体设计模块设计、详细设计11、SA法的主要描述手段有（）系统流程图和模块图DFD图、数据词典、加工说明功能结构图、加工说明软件结构图、加工说明12、采用甘特图表示软件项目进度安排，下列说法中正确的是（）。
能够反映多个人物之间的复杂关系能够直观表示任务之间相互依赖的制约关系能够表示哪些任务是关键任务能够表示字人物之间的并行和串行关系13、画DFD图的主要目的（）对系统的数据结构进行描述。
对目标系统的层次结构进行描述。
解决系统是“如何做的问题”。
作为需求分析阶段用户与开发者之间交流信息的工具。
14、数据字典是数据流图中所有元素的定义的集合，一般由以下4类条目组成（）。
A. 数据流条目、数据存储条目、数据源条目、加工条目数据说明条目、控制流条目、加工条目、数据存储条目数据源条目、数据流条目、数据处理条目、数据文件条目数据流条目、数据项条目、文件条目、加工条目15、在下列的基本成分中，哪个不是数据流程图的基本成分？（）信息处理系统状态信息存储外部实体16、数据流图中，当数据流向或流自文件时（）。
软件需求规格说明模板GBT
软件需求规格说明模板(GBＴ-)————————————————————————————————作者: ————————————————————————————————日期：ﻩXXX项目软件需求规格说明书XXXX2０年月日文档信息文档标题XXX项目需求规格说明书归档日期所有者修订历史版本编号版本日期修订内容备注V0.1 初始版本V0.２V0.3Ｖ0．4V０.５Ｖ０．6V0.7V０．8V０.9V１.0文档编制、审核与批准签字日期编制审核批准目录1引言 (1)1.1 目的 (1)1.2范围 (1)1.3定义、简写和缩略语 (1)1.4引用文件 (1)1.5综述 (1)2总体描述 (2)2.1产品描述 (2)2.1.1系统接口 (2)2.1.2用户界面 (2)2.1.3硬件接口 (2)2.1.4软件接口 (3)2.1.5通信接口 (3)2.1.6内存约束 (3)2.1.7操作 (3)2.1.8现场适应性需求 (3)2.2产品功能 (3)2.3用户特点 (4)2.4约束 (4)2.5假设和依赖关系 (4)2.6需求分配 (4)3具体需求 (4)3.1外部接口 (5)3.2功能 (5)3.3性能需求 (7)3.4数据库逻辑需求 (7)3.5设计约束 (7)3.5.1标准依从性 (7)3.6软件系统属性 (8)3.6.1可靠性 (8)3.6.2可用性 (8)3.6.3安全保密性 (8)3.6.4可维护性 (8)3.6.5可移植性 (8)3.7具体需求的组织 (8)3.7.1系统模式 (9)3.7.2用户类型 (9)3.7.3对象 (9)3.7.4特征 (9)3.7.5激励 (9)3.7.6响应 (9)3.7.7功能层次 (9)3.8附加说明 (10)4附录 (10)1引言本部分应当提供整个SRS的概述１．１目的本条宜：ａ）描述SRＳ的目的；b)说明SRS的预期读者。
1．２范围本条宜：a)通过名称识别要生产／开发的软件产品(例如，宿主数据库管理系统（DＢMS)、报告生成器等）；ｂ)必要时,说明软件产品将做或不做什么;c）描述规定的软件的应用,包括相关的收益、目标和目的;d)如果上层规格说明(如，系统需求规格说明）存在,与上层规格说明类似的陈述保持一致。
软件项目需求规格—说明书模板
软件项目需求规格—说明书模板组态建模工具需求规格说明书概述本文档旨在描述组态建模工具的需求规格，以便于开发人员能够按照规格开发出符合用户需求的软件。
本文档适用于所有与组态建模工具相关的人员。
编写目的本文档的编写目的是为了明确组态建模工具的需求规格，以便于开发人员能够按照规格开发出高质量的软件。
同时，本文档也为用户提供了一个清晰的需求规格，以便于用户能够更好地理解软件的功能和特性。
编写依据本文档的编写依据包括用户需求调研、市场需求分析、技术可行性分析等，同时也考虑了相关标准和规范的要求。
术语和缩略词本文档中使用的术语和缩略词包括但不限于以下内容：组态建模工具：一种用于建立系统组态模型的软件工具。
用户：使用组态建模工具的人员。
开发人员：负责组态建模工具开发的人员。
软件概要软件总体描述组态建模工具是一种用于建立系统组态模型的软件工具。
该工具可以支持多种模型类型，包括但不限于物理模型、逻辑模型、过程模型等。
用户可以通过该工具快速地建立系统组态模型，并进行模型的分析和优化。
软件设计约束及有关说明在软件设计过程中，需要考虑以下约束和相关说明：该工具需要支持多种模型类型，包括但不限于物理模型、逻辑模型、过程模型等。
该工具需要支持多种数据格式的导入和导出，以便于用户能够方便地进行数据交换和共享。
该工具需要具备良好的可扩展性和可维护性，以便于后续的开发和维护工作。
该工具需要具备良好的用户交互性和易用性，以便于用户能够快速上手并进行操作。
该工具需要具备良好的性能和稳定性，以便于用户能够进行大规模的模型建立和分析。
4.2 功能需求本系统需要实现以下功能：1.用户登录：用户可以通过输入用户名和密码登录系统，进入系统后可以进行相关操作。
2.信息录入：用户可以录入相关信息，包括客户信息、产品信息、订单信息等。
3.信息查询：用户可以根据不同条件查询相关信息，如客户名称、产品型号、订单编号等。
4.信息修改：用户可以对已录入的信息进行修改。
软件需求规格说明模板
软件需求规格说明模板软件综合课程设计<仓库管理系统>软件需求规格说明姓名：马良学号：070604113 班级：0706041引言 (3)1.1标识 (3)1.2系统概述 (3)1.3文档概述 (3)2引用文件 (3)3需求 (3)3.1要求的状态和方式 (4)3.2需求概述 (4)3.2.1系统总体功能和业务结构 (4)3.2.2硬件系统的需求 (4)3.2.3软件系统的需求 (4)3.2.4接口需求 (4)3.3系统能力需求 (4)3.3.x(系统能力) (4)3.4系统外部接口需求 (5)3.4.1接口标识和接口图 (5)3.4.x(接口的项目唯一标识符) (5)3.5系统内部接口需求 (6)3.6系统内部数据需求 (6)3.7适应性需求 (6)3.8安全性需求 (7)3.9保密性和私密性需求 (7)3.10操作需求 (7)3.11可使用性、可维护性、可移植性、可靠性和安全性需求 (7)3.12故障处理需求 (7)3.12.1软件系统出错处理 (7)3.12.2硬件系统冗余措施的说明 (7)3.13系统环境需求 (7)3.14计算机资源需求 (8)3.14.1计算机硬件需求 (8)3.14.2计算机硬件资源利用需求 (8)3.14.3计算机软件需求 (8)3.14.4计算机通信需求 (8)3.15系统质量因素 (8)3.16设计和构造的约束 (9)3.17相关人员需求 (9)3.18相关培训需求 (9)3.19相关后勤需求 (9)3.20其他需求 (9)3.21包装需求 (9)3.22需求的优先次序和关键程度 (10)4合格性规定 (10)5需求可追踪性 (10)6非技术性需求 (10)7尚未解决的问题 (10)8注解 (11)附录 (11)1引言1.1标识本条应包含本文档适用的系统和软件的完整标识，(若适用)包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、操作和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划中的运行现场；列出其他有关的文档。
软件需求规格说明书模板(超详细的哦)
X X X X X X单位X X X X X X X项目软件需求规格说明书金碧信息科技目录第一章引言 (5)1编写目的 (5)2软件需求分析理论 (5)3软件需求分析目标 (5)4参考文献 (6)第二章需求概述 (7)1.项目背景 (7)2.需求概述 (7)3.条件与限制(可选) (8)4.移动办公系统结构 (8)5.移动办公网络拓扑图 (9)第三章系统功能需求 (10)1.移动办公系统升级改造需求 (10)✓界面显示要求 (11)✓待办公文列表 (11)✓待办公文列表排序 (11)✓公文详细信息界面元素 (11)✓网站信息审批 (12)✓会议申请 (12)✓意见录入 (12)✓移动邮件 (12)✓会议管理 (13)✓通知通告 (13)✓通讯录管理 (14)2.车辆管理模块升级改造需求 (14)✓系统功能架构 (14)✓网络拓扑结构 (15)3.电子公文预览需求 (15)✓电子公文交换网络 (16)✓电子公文交换流程 (18)4.政务信息管理系统平台功能需求 (19)第四章软硬件或其他外部系统接口需求 (21)1.用户界面 (21)2.硬件需求 (22)3.网络需求 (22)4.接口需求 (22)5.通信需求 (23)6.运行环境 (23)第五章其他非功能需求 (24)1.性能需求 (24)2.安全设施需求 (25)3.安全性需求 (25)4.扩展性需求 (26)5.可移植性需求 (26)第一章引言1编写目的为明确软件需求、安排项目规划与进度、组织软件开发与测试，撰写本文档。
2软件需求分析理论软件需求分析（Software Reguirement Analysis）是研究用户需求得到的东西，完全理解用户对软件需求的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本依据。
软件需求分析是一个项目的开端，也是项目实施最重要的关键点。
据有关的机构分析结果表明，设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的，而且由于需求分析错误造成根本性的功能问题尤为突出。
软件工程填空题(18套试题及答案)
《软件工程》填空题二、填空题（请把答案写在相应的横线上,每小题1.5分）1、软件是数据、计算机程序及其说明程序的各种文档。
2、概要设计主要是把各项功能需求转换成系统的体系结构。
3、面向对象开发方法包括OOA 、OOD 、OOP 三部分。
4、结构化设计中以数据流图为基础的两种具体分析设计方法是变换分析、事物分析设计。
5、在单元测试时，需要为被测模块设计驱动模块和桩模块。
6、CMM把软件过程从无序到有序的进化分成5个阶段，排序而形成5个逐层提高的等级，分别是初始级、可重复级、已定义级、已管理级和可优化级。
7.子类自动共享父类的属性和操作的机制称为继承。
8. 软件工程管理的具体内容包括对开发人员、组织机构、用户、文档资料等方面的管理。
9、可行性研究的三个方面是技术可行性、社会可行性和__经济可行性__。
10、在软件概要设计阶段，建立软件结构后，还应为每个模块写一份处理说明和_接口说明__。
11、在画分层的DFD时，父图与子图的输入输出数据流要__平衡__。
12、在详细设计阶段，除了对模块内的算法进行设计，还应对模块内的__数据结构_进行设计。
13. 对象的抽象是___类___。
14. 基线的作用是把各阶段的开发工作划分得更加明确，便于检查与确认阶段成果。
因此，基线可以作为项目的一个___检查点__。
15. 软件工程包括软件开发技术和__软件工程管理__两大部分内容。
16、开发过程管理包括项目计划、控制和___任务管理__等。
17、CASE是多年来在软件开发管理、软件开发方法、软件开发环境和__软件工具__等方面研究和发展的产物。
18、数据字典中有四类条目，分别是___数据流、数据项、数据存储、基本加工。
19、用于描述基本加工的小说明的三种描述工具是结构化语言、判定表、判定树_。
20、子类只继承一个父类的属性和操作,这称为__单重继承__。
21、McCabe复杂性度量又称__环路度量_。
22、喷泉模型是一种以用户需求为动力，以__对象__为驱动的模型。
软件需求说明书编写规范
＜项目名称＞软件需求说明书作者：王浩天完成日期： 8.23 签收人：签收日期：修改情况记录：目录1 引言 (1)1.1 编写目的 (1)1.2 范围 (1)1.3 定义 (1)1.4 参考资料 (1)2 项目概述 (1)2.1 产品描述 (1)2.2 产品功能 (2)2.3 用户特点 (2)2.4 一般约束 (2)2.5 假设和依据 (2)3 具体需求 (2)3.1 功能需求 (2)3.1.1 功能需求1 (2)3.1.2 功能需求2 (3)3.1.n 功能需求n (3)3.2 外部接口需求 (3)3.2.1 用户接口 (3)3.2.2 硬件接口 (4)3.2.3 软件接口 (4)3.2.4 通信接口 (4)3.3 性能需求 (4)3.4 设计约束 (5)3.4.1 其他标准的约束 (5)3.4.2 硬件的限制 (5)3.5 属性 (5)3.5.1 可用性 (5)3.5.2 安全性 (6)3.5.3 可维护性 (6)3.5.4 可转移＼转换性 (6)3.5.5 警告 (6)3.6 其他需求 (6)3.6.1 数据库 (6)3.6.2 操作 (7)3.6.3 场合适应性需求 (7)4 附录 (7)1 引言1.1 编写目的详细列出用户对该软件期望实现的功能。
1.2 范围Linux下的FlowerMail邮件系统是由北京理工大学实训小组受NEUSOFT委托为其开发的一套局域网内部的邮件通信系统。
公司使用这套系统后，可以使日常的信息交流，文件传递更加便捷，从而使工作效率得到了极大的提升，增加了员工之间的友好交流，增进了友谊。
实训小组作为这款软件的开发商，提高了自己编写程序的能力。
1.3 定义//1.4 参考资料a、Linux系统下邮件系统项目要求说明书2 项目概述2.1 产品描述软件开发是为了解局域网下公司员工之间邮件交流困难的问题，预期将实现局域网下邮件的收发，存储等功能方便员工相互之间的交流，作用范围是公司局域网上的所有员工。
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
信息系统监理师(基础知识、应用技术)合卷软件资格考试(中级)试题与参考答案(2024年)
2024年软件资格考试信息系统监理师(基础知识、应用技术)合卷(中级)复习试题(答案在后面)一、基础知识（客观选择题，75题，每题1分，共75分）1、在软件生命周期模型中，螺旋模型是在瀑布模型的基础上增加了什么特性？A. 需求分析B. 设计与实现C. 风险分析D. 维护与支持2、下列哪个不属于信息系统项目管理中的三要素？A. 范围B. 时间C. 成本D. 质量3、在信息系统工程中，以下哪个阶段是项目整体管理的关键阶段？A. 需求分析阶段B. 设计阶段C. 开发阶段D. 验收阶段4、以下哪个选项不属于信息系统工程质量保证活动的范畴？A. 编写测试用例B. 代码审查C. 系统集成测试D. 项目进度跟踪5、关于项目管理中的风险管理，下列说法错误的是：A. 风险识别是在项目早期进行的一次性活动。
B. 风险评估包括定性和定量两个方面。
C. 应急计划是风险应对策略的一部分。
D. 风险监控涉及在整个项目生命周期中持续跟踪已识别的风险。
6、在信息系统开发过程中，哪一项不属于需求分析阶段的工作内容？A. 分析用户需求B. 定义系统边界C. 编写详细的设计文档D. 建立需求规格说明书7、以下关于软件工程中软件需求规格说明书（SRS）的描述，不正确的是（）A. SRS是软件项目开发过程中必须的文档之一B. SRS应描述软件的功能需求和性能需求C. SRS应避免使用非功能性需求描述D. SRS的目的是为了指导软件开发和维护8、在软件测试过程中，以下哪种测试方法主要关注系统在特定条件下的性能表现？（）A. 单元测试B. 集成测试C. 系统测试D. 性能测试9、在信息系统项目管理过程中，监理单位的主要职责是什么？A. 制定项目计划B. 执行系统开发任务C. 对项目的实施过程进行监督与控制D. 负责系统的最终验收 10、信息系统工程监理工作的“四控三管一协调”指的是什么？A. 控制质量、进度、成本和范围；管理合同、信息和安全；协调各方关系B. 控制质量、进度、成本和变更；管理合同、信息和风险；协调各方关系C. 控制质量、进度、成本和需求；管理合同、信息和人员；协调各方关系D. 控制质量、进度、成本和风险；管理合同、信息和文档；协调各方关系11、在信息系统监理过程中，以下哪项工作不属于监理工程师的职责范围？A. 审查项目合同B. 监督项目进度C. 审核项目预算D. 设计项目架构12、在信息系统监理过程中，以下哪种方法不属于风险评估的方法？A. 专家调查法B. 概率分析法C. SWOT分析法D. 故障树分析法13、在信息系统监理过程中，以下哪个阶段是监理工程师最关注的信息安全风险点？A. 系统设计阶段B. 系统开发阶段C. 系统实施阶段D. 系统运行阶段14、以下关于项目沟通管理的说法，正确的是：A. 项目沟通管理只关注内部团队成员之间的沟通B. 项目沟通管理不包括与项目干系人的沟通C. 项目沟通管理的目标是确保项目信息的准确、及时传递D. 项目沟通管理只关注沟通的形式，不考虑沟通内容15、在软件工程中，需求分析阶段的主要任务是：A. 确定软件的功能和非功能需求B. 设计软件的架构和模块C. 编写软件代码D. 测试软件的功能16、在软件工程中，UML（统一建模语言）主要用于：A. 编程语言设计B. 软件需求分析C. 软件测试用例设计D. 软件代码审查17、在信息系统监理过程中，下列哪个不属于监理工作的基本内容？A. 监理计划的制定B. 监理合同的签订C. 监理报告的编制D. 监理团队的组建18、以下关于信息系统监理师的职业道德要求，错误的是：A. 诚实守信B. 客观公正C. 隐私保护D. 损人利己19、题干：在信息系统监理工作中，以下哪项不属于监理单位的基本职责？A. 对信息系统工程项目的进度、质量、投资进行监控B. 对信息系统工程项目的变更进行管理C. 对信息系统工程项目的验收进行审核D. 对信息系统工程项目的保密性进行审计 20、题干：在信息系统监理过程中，以下哪种情况不属于监理工程师应采取的预防措施？A. 对项目团队成员进行培训，提高其项目管理的意识和能力B. 对关键设备进行备份，以防故障发生C. 对项目进度计划进行定期审查，确保其符合项目目标D. 对项目文档进行严格审查，确保其符合国家相关标准21、在软件开发过程中，以下哪项不是需求分析阶段的工作内容？A. 确定软件的功能需求B. 分析用户界面设计C. 确定软件的性能需求D. 编写测试用例22、关于软件架构设计，以下说法错误的是：A. 软件架构设计应遵循模块化原则B. 软件架构设计应关注系统的可扩展性和可维护性C. 软件架构设计只关注系统的高层设计D. 软件架构设计应考虑系统的安全性23、在信息系统工程中，以下哪项不属于信息系统监理师的基本职责？（）A. 监督信息系统工程项目的实施过程B. 协调项目各方关系C. 负责信息系统工程项目的质量、进度、投资控制D. 直接参与信息系统工程项目的开发工作24、以下关于信息系统工程监理质量控制的描述，正确的是（）。
软件需求规格说明
并发用户数
系统应支持至少1000个并发用户同时操作，保 证系统稳定性和可靠性。
资源利用率
系统资源利用率应合理，避免浪费和不必要的开 销。
软件界面需求
界面风格
界面设计应简洁、美观、易用 ，符合用户操作习惯。
交互方式
支持鼠标、键盘等多种交互方 式，提供快捷键操作，提高用 户操作效率。
信息显示
清晰、准确地展示数据和结果，包括图表、图像和文 本等多种形式。
硬件接口
01
02
03
设备连接
支持标准的硬件接口，如 USB、HDMI等，以便与 外部设备连接。
数据传输
确保数据的稳定、高效传 输，包括输入、输出和处 理过程中的数据传输。
硬件控制
提供对硬件设备的控制功 能，如启动、停止、配置 等操作。
在不同硬件和软件环境下 运行软件，检查是否存在 兼容性问题。
测试环境和工具
测试环境
包括硬件环境（如服务器配置、网络 环境等）和软件环境（如操作系统、 数据库、浏览器等）。
测试工具
自动化测试工具如Selenium、Junit等 ，性能测试工具如LoadRunner、 JMeter等，安全测试工具如 Metasploit、Nessus等。
02 性能稳定性 软件在各种负载条件下应保持稳定，不出现崩溃、卡 顿等问题。
03
兼容性
软件应能在规定的硬件和软件环境下正常运行，且与 其他相关系统或软件兼容。
04
安全性
软件应符合相关安全标准，不存在安全隐患，如数据 泄露、系统漏洞等。
05
易用性
软件界面友好，易于操作和理解，符合用户的使用习 惯。
软件需求规格说明(规范)
GC508.04 密级：（软件项目名称）软件需求规格说明标识：版本：页数：拟制：SQA审核：审核：批准：拟制部门：年月日修改文档历史记录：日期版本说明修改人目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)2 引用文档 (1)3 需求 (1)3.1 要求的状态和方式 (1)3.2 CSCI能力需求 (2)3.2.X（CSCI能力） (2)3.3 CSCI外部接口需求 (2)3.3.1 接口标识和接口图 (2)3.3.X（接口的项目唯一的标识符） (2)3.4 CSCI内部接口需求 (3)3.5 CSCI内部数据需求 (3)3.6 适应性需求 (3)3.7 安全性需求 (3)3.8 保密性需求 (3)3.9 CSCI环境需求 (4)3.10 计算机资源需求 (4)3.10.1 计算机硬件需求 (4)3.10.2 计算机硬件资源使用需求 (4)3.10.3 计算机软件需求 (4)3.11 软件质量因素 (4)3.12 设计和实现约束 (4)3.13 人员需求 (4)3.14 培训需求 (4)3.15 后勤保障需求 (4)3.16 其它需求 (4)3.17 验收、交付和包装需求（修改有关内容） (4)3.18 需求的优先顺序和关键程度 (5)4 合格性规定 (5)5 需求可追踪性 (5)6 注释 (5)1 范围1.1 标识【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号及发布号。
】1.2 系统概述【本条应概述本文档所适用的系统和软件的用途。
它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构；标识当前和计划的运行现场；列出其它有关文档。
】1.3 文档概述【本条应概述文档的用途和内容，并描述与它的使用有关的保密性方面的要求。
】2 引用文档【本章应列出引用文档的编号、标题、编写单位、修订版及日期，还应标识所有不能通过正常采购活动得到的文档的来源。
酒店点餐系统需求规格说明书
酒店点餐系统需求规格说明书«酒店点餐系统»1.0版本制造人：XXX2010-12-5D.3.1引见--------------------------------------------------------------------------------------31.目的----------------------------------------------------------------------------------------32.项目范围和产品特征-------------------------------------------------------------------33.参考文献----------------------------------------------------------------------------------3D.3.2 总体描画------------------------------------------------------------------------------31.产品远景规划----------------------------------------------------------------------------32.用户类和用户特征----------------------------------------------------------------------43.运转环境----------------------------------------------------------------------------------54.设计和完成条件约束-------------------------------------------------------------------55.用户文档----------------------------------------------------------------------------------56.假定和依赖-------------------------------------------------------------------------------6D.3.3 系统特性-------------------------------------------------------------------61．生成、修正、检查菜单------------------------------------------------------------6 〔1〕描画和优先级-----------------------------------------------------------------------6 〔2〕鼓舞/照应序列----------------------------------------------------------------------6 〔3〕功用性需求--------------------------------------------------------------------------6 2．管理员添加、检查、更改员工信息---------------------------------------------7 〔1〕描画和优先级-----------------------------------------------------------------------7〔2〕鼓舞/照应序列----------------------------------------------------------------------7 〔3〕功用性需求--------------------------------------------------------------------------8 3．支付账单-------------------------------------------------------------------------------9 4．用户生成、修正、删除点餐-------------------------------------------------------9 〔1〕描画和优先级-----------------------------------------------------------------------9 〔2〕鼓舞/照应序列----------------------------------------------------------------------9 〔3〕功用性需求--------------------------------------------------------------------------10 5．用户要求加菜------------------------------------------------------------------------11 6．效劳人员检查点餐------------------------------------------------------------------11 7．效劳人员送餐给顾客或房客------------------------------------------------------11 8．收银人员对账单存根---------------------------------------------------------------11 9．厨师检查用户要求的菜品并完成菜品------------------------------------------11D.3.2 外部接口需求------------------------------------------------------------111.产品远景规划-------------------------------------------------------------------------112.硬件接口-------------------------------------------------------------------------------113.软件接口-------------------------------------------------------------------------------124.通讯接口-------------------------------------------------------------------------------12D.3.5 其他非功用性需求------------------------------------------------------121.平安性需求----------------------------------------------------------------------------132.软件质量属性-------------------------------------------------------------------------13D.3.1引见1.目的软件需求规格说明书描画了〝酒店点餐系统〞1.0版本的软件功用性需求和非功用性需求。
软件需求规格说明书检查点
软件需求规格说明书检查点文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-软件需求规格说明书检查点以下基本问题应得到解决：o功能：本软件有什么用途o外部接口：此软件如何与人员、系统硬件、其他硬件及其他软件进行交互o性能：不同软件功能都有什么样的速度、可用性、响应时间、恢复时间等o属性：在可移植性、正确性、可维护性、安全性等方面都有哪些事项要考虑o对实施强加的设计约束：是否有必要的有效标准、实施语言、数据库完整性策略、资源限制、操作环境等是否指定了在 SRS 范围之外的任何需求这里表明 SRSo应正确定义所有的软件需求，o不应说明任何设计或实施细节，o不应该对软件附加更多约束。
SRS 是否合理地限制了有效设计的范围而不指定任何特定的设计SRS 是否显示以下特征o正确性：SRS 规定的所有需求是否都是软件应该满足的o明确性每个需求是否都有一种且只有一种解释是否已使用客户的语言是否已使用图来补充自然语言说明o完全性SRS 是否包括所有的重要需求（无论其与功能、性能设计约束、属性有关还是与外部接口有关）?是否已确定并指出所有可能情况的输入值的预期范围?响应是否已同时包括在有效输入值和无效输入值中所有的图、表和图表是否都包括所有评测术语和评测单元的完整标注、引用和定义是否已解决或处理所有的未确定因素o一致性此 SRS 是否与前景文档、用例模型和补充规约相一致它是否与更高层的规约相一致它是否保持内部一致，其中说明的个别需求的任何部分都不发生冲突o排列需求的能力每个需求是否都已通过标识符来标注，以表明该特定需求的重要性或稳定性是否已标识出正确确定优先级的其他重要属性o可核实性在 SRS 中说明的所有需求是否可被核实是否存在一定数量可节省成本的流程可供人员或机器用来检查软件产品是否满足需求o可修改性SRS 的结构和样式是否允许在保留结构和样式不变的情况下方便地对需求进行全面而统一的更改是否确定和最大限度地减少了冗余，并对其进行交叉引用o可追踪性每个需求是否都有明确的标识符每个需求的来源是否确定是否通过显式引用早期的工件来维护向后可追踪性SRS 产生的工件是否具有相当大的向前可追踪性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件需求规格说明书检
查点
文稿归稿存档编号：[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-
软件需求规格说明书检查点
以下基本问题应得到解决：
o功能：本软件有什么用途
o外部接口：此软件如何与人员、系统硬件、其他硬件及其他软件进行交互
o性能：不同软件功能都有什么样的速度、可用性、响应时间、恢复时间等
o属性：在可移植性、正确性、可维护性、安全性等方面都有哪些事项要考虑
o对实施强加的设计约束：是否有必要的有效标准、实施语言、数据库完整性策略、资源限制、操作环境等
是否指定了在 SRS 范围之外的任何需求这里表明 SRS
o应正确定义所有的软件需求，
o不应说明任何设计或实施细节，
o不应该对软件附加更多约束。
SRS 是否合理地限制了有效设计的范围而不指定任何特定的设计SRS 是否显示以下特征
o正确性：SRS 规定的所有需求是否都是软件应该满足的
o明确性
每个需求是否都有一种且只有一种解释
是否已使用客户的语言
是否已使用图来补充自然语言说明
o完全性
SRS 是否包括所有的重要需求（无论其与功能、性能设计约束、属性有关还是与外部接口有关）?
是否已确定并指出所有可能情况的输入值的预期范围?
响应是否已同时包括在有效输入值和无效输入值中
所有的图、表和图表是否都包括所有评测术语和评测单元的完整标注、引用和定义
是否已解决或处理所有的未确定因素
o一致性
此 SRS 是否与前景文档、用例模型和补充规约相一致
它是否与更高层的规约相一致
它是否保持内部一致，其中说明的个别需求的任何部分都不发生冲突
o排列需求的能力
每个需求是否都已通过标识符来标注，以表明该特定需求的重要性或稳定性
是否已标识出正确确定优先级的其他重要属性
o可核实性
在 SRS 中说明的所有需求是否可被核实
是否存在一定数量可节省成本的流程可供人员或机器用来检查软件产品是否满足需求
o可修改性
SRS 的结构和样式是否允许在保留结构和样式不变的情况下方便地对需求进行全面而统一的更改
是否确定和最大限度地减少了冗余，并对其进行交叉引用
o可追踪性
每个需求是否都有明确的标识符
每个需求的来源是否确定
是否通过显式引用早期的工件来维护向后可追踪性
SRS 产生的工件是否具有相当大的向前可追踪性。