软件需求分析审查准则.docx
《软件需求分析审查准则.docx》由会员分享,可在线阅读,更多相关《软件需求分析审查准则.docx(23页珍藏版)》请在课桌文档上搜索。
1、软件需求分析阐明书审查规范文献编号受控编号版本1.0编制日期生效日期密级编制审核同意文献修改控制修改记录编号修改状态修改位置及内容修改人审核人同意人修改日期1.2.3.4.5.6.7.8.目录软件需求分析阐明书审查规范错误!未定义书签。目录错误!未定义书签。1 .引言错误!未定义书签。1.1. 目的错误!未定义书签。1.2. 合用范围错误!未定义书签。1.3. 用阐明错误!未定义书签。2 .参照资料错误!未定义书签。3 .术语定义错误!未定义书签。4 .质量规定错误!未定义书签。4.1. 完整性错误!未定义书签。4.1.1. 整体内容完整性错误!未定义书签。4.1.2. 需求项信息完整性错误!
2、未定义书签。4.2. 对的性错误!未定义书签。4.3. 一致性错误!未定义书签。4.4. 可验证性错误!未定义书签。4.5. 划分优先级错误!未定义书签。4.6. 可用性错误!未定义书签。5 .附件错误!未定义书签。5.1. 某些编写提议错误!未定义书签。5.2. 部分参照实例错误!未定义书签。5.2.1. 需求项表格错误!未定义书签。5.2.2. 表格需求项实例错误!未定义书签。5.2.3. 优先级划分措施实例错误!未定义书签。5.2.4. 软件需求分析阐明书模板错误!未定义书签。.引言1.L目的软件需求分析阐明书在软件开发、测试、质量保证、项目管理以及有关项目功能中起着重要作用。为了保证软
3、件阐明书对质量,木文档详细描述了软件需求分析阐明书所要包括口勺内容及其编制所要抵达的质量规定。1.2. 合用范围作为软件需求分析阐明书与否可以进入正式评审的审查原则,符合该规范时可以提交正式需求评审;作为测试人员编制软件需求分析阐明书审查列表日勺根据;作为开发人员编制软件需求分析阐明书H勺指导原则;1.3. 使用阐明本文重点对需求分析阐明书的内容进行规定,对体现方式、措施未明确提出规定对视为不作规定;本文中的“应”、“必须”含义等同:本文中H勺“既有H勺技术水平”指与该需求有关的行业中,可获得的、已知的、可实际运用于生产H勺、可信的、通过验证H勺所有技术;本文中H勺需求可行性以通过审核公布的项
4、目可行性研究汇报为根据;2 .参照资料GB8566计算机软件开发规范受控编号?GB8567计算机软件产品开发文献编制指南受控编号?GB/T11457软件工程术语受控编号?SystematicSoftwareTestingRickD.Craig,StefanP.JaskielArtechHousePublishers2023-05-1统一软件开发过程RUP2023手册IBM企业2023年3 .术语定义GB/T11457所列术语和下列定义合用于本文需求系统必须符合的I条件或具有的)功能软件需求分析软件需求分析的基本任务是精确地定义未来系统的目日勺,确定为了满足顾客的需求,系统必须做什么。需求分析包
5、括需求获取和需求规约:需求获取是系统分析员通过学习以及同顾客的交往,熟悉顾客领域的知识,并获得对未来系统的I需求;需求规约是系统分析员在获得了顾客的初步需求后,必须进行i致性分析和检查,通过和顾客协商处理其中存在的二义性和不一致性,并以种规范的形式精确地体现顾客H勺需求,形成软件需求分析阐明书。软件需求分析阐明书(SoftwareRequirementsSpecifications,简称SRS):软件需求分析阐明书(也称软件需求规格阐明书、软件需求分析汇报)是软件需求分析阶段得到的最终文档,它以形式化的术语和体现对软件rJ功能和性能进行详细而详细的描述。它是顾客和开发者之间的技术协议,是软件设
6、计、编码阶段的)基础,也是软件测试和验收的根据。IEEE软件工程原则词汇表(1997年)中定义为:(1)顾客处理问题或抵达目的所需口勺条件或权能(CaPability)。(2)系统或系统部件要满足协议、原则、规范或其他正式规定文档所需具有H勺条件或权能。(3) 一种反应上面(1)或(2)所描述的条件或权能的文档阐明。软件质量IEEE610.12-1990中定义:一种系统、组件或过程满足客户或顾客的需求的程度,或满足期望值的程度。(“Thedegreetowhichasystem,component,orprocessmeetscustomeroruserneedsorexpectations.
7、,ISOIEC9126中定义:与软件产品满足规定的和隐含日勺需求的能力有关的特性或特性的全体。(Thetotalityoffeaturesandcharacteristicsofasoftwareproductthatbearonitsabilitytosatisfystatedorimpliedneeds.)软件质量保证软件质量保证,是为保证产品和服务充足满足消费者规定的质量而进行的J有计划、有组织的活动。软件质量保证是面向消费者的活动,是为了使产品实现顾客规定的功能,站在顾客立场上来掌握产品质量的I。软件的质量保证就是向顾客及社会提供满意的高质量的软件产品。可跟踪性指假如每一种需求的来源、
8、变更历史是清晰的,在深入产生和变化文献编制时,可以以便地引证每一种需求,则该软件需求分析阐明书就是可追踪H勺。可修改性指假如一种软件需求分析阐明书的构造和风格在需求有必要变化时是易于实现的、且变化后仍然完整、一致於J,那么这个软件需求分析阐明书就是可修改的。可行性指在规定的时间限制和开销下、在特定的环境制约下、运用既有的技术、工具、资源和人力下,需求必须是可以实现的。详细包括:技术可行,既有H勺技术水平可以实现所有的需求;财政可行,有足够的资金来实现所有的需求,且实现H勺成本在可接受的范围内;时间可行,在指定的时间范围内可以实现所有的需求;资源可行,有足够的人力、物力来实现所有的需求;验证原则
9、用以判断需求被实现后,实现日勺成果与否对的的根据。如I:对于性能需求,其验证原则是详细的性能指标;对于功能需求,其验证原则是详细的功能效果描述。软件测试软件测试是为了度量和提高被测软件的质量,对测试件进行工程设计、实行和维护时整个生命周期过程。(SystematicSoftwareTesting)统一建模语言(UML)UML(UnifiedModelingLangUage)是一种构建软件系统和文档的通用可视化建模语言。UML能与所有的I开发措施一同使用,可用于软件开发的整个生命周期。UML能体现系统的静态构造和动态信息,并能管理复杂的系统模型,便于软件团体之间的合作开发。UML不是编程语言,但
10、支持UML语言的工具可以提供从UML到多种编程语言的代码生成,也可以提供从既有程序逆向构建UML模型。统一软件开发过程(RUP)RUP是一种通用软件过程框架,可以应付种类广泛的软件系统、不同样的应用领域、不同样H勺组织类型、不同样的性能水平和不同样的项目规模。“统一过程”是基于构件的,这意味着运用它开发H勺软件系统是由构件构成的,构件之间通过定义良好的接口互相联络。在准备软件系统H勺所有蓝图的时候,“统过程”使用的是“统建模语言(UnifiedMOdeIing1.anguage)”。实际上,UML是“统一过程”的有机构成部分一一它们是被同步开发的。然而,真正使“统一过程”与众不同样的方面可以用
11、三个句话来体现:它是用例驱动H勺、以基本架构为中心的、迭代式和增量性的。4 .质量规定合格的软件需求分析阐明书要满足如下质量规定:1 .完整性2 .对的性3 .一致性4 .可验证性5 .划分优先级6 .可用性下面我们分别对每个质量规定进行阐明,同步给出怎样满足各质量规定的!指导原则。4.1. 完整性完整性是指软件需求分析阐明书包括了所有应当具有的内容,由于不同样的产品、项目对软件需求分析阐明书所应当具有的内容口勺不完全相似,因此为了便于指导和规范文档的实际编制本规范将完整性划分为整体内容完整性、需求项信息完整性,并针对不同样的内容提出不同样日勺规定,包括:必须和可选,详细如下:4.1.1. 整
12、体内容完整性整体内容完整性用以确定整个软件需求分析阐明书中详细应当包括日勺内容和不应当包括的内容,详细如下:一.需求没有遗漏:确定在需求分析阐明书编制的过程中,没有遗漏需求获取阶段所确定的需求。其根据为包括但不仅限于通过正式审核的下列文档:1 .市场调研汇报;2 .顾客需求调查汇报;3 .需求分析讨论会议记录;二.需求没有冗余:即同一需求不能在软件需求分析阐明书中出现多次;三.不存在超过产品/项目范围H勺需求;四.除设计上的特殊限制之外,软件需求分析阐明书中不描述任何设计、验证或项目管理细节的内容;五 .软件需求分析阐明书必须包括下列信息:1 .目的:阐明编写这份软件需求阐明书的目的,指出预期
13、的读者2 .概述:阐明产品或项目的背景、总体描述、功能、顾客特点、一般日勺设计约束。只描述影响产品及其需求的一般原因,不阐明详细的需求,概述的目的仅近使需求更易于理解3 .参照资料:列出软件需求分析阐明书中所有用得到的所有参照资料,详细阐明参照资料的来源。内容包括但不仅限于:1)木产品或项目的通过核准的I计划任务书或协议、上级机关的批文;2)本项目的其他已通过审核Fl勺正式文档;3)企业内部制定公布的正式管理文献;4)各处引用的资料,如出版物、网络资讯;5)所要用到的软件开发原则。且每条参照资料记录中包括的内容及格式应满足下列规定(按类型划分):1)专著出版物:重要作者,其他作者,书名,版本,
14、出版地:出版者,出版年;2)持续期刊出版物:文献作者,文献其他作者,题名,刊物名,版本:在原文献中的位置;3)原则:原则编,号原则名,企业受控编号;4)文献:文献编号,文献名,文献版本5)网络资讯:作者,题名,公布网址,公布时间4 .术语定义:提供软件需求分析阐明书中用到日勺专门术语、缩写词、缩略语的定义,这部分信息可以在软件需求分析阐明书中用一种单独章节提供或者在附录中提供,也可以参照其他的文献;5 .详细需求:指产品或项目必须符合的条件或具有的功能,它包括软件开发者在建立设计时需要的所有细节。由于不同样於J产品项目其需求都不同样,同样的需求可以使用不同样的!分类措施进行划分,因此这里只列举
15、一种比较常见的划分方式,并分别加以阐明:1)功能需求:规定了在不考虑物理约束的状况下必须可以执行的动作,也就是一般所说的系统可以做什么;2)性能需求:是指软件功能在执行过程中需要满足Fl勺强加条件,如速度、效率、可使用性、响应时间、多种软件功能口勺恢复时间、吞吐能力、精度、频率、资源用途等等3)属性需求:可扩展性、可移植性、稳定性、可靠性、可维护性、兼容性、安全性、可配置性、可服务性、可安装性,可国际化性、可用性、易用性等方面H勺考虑原因;4)外部接口:顾客、硬件、其他软件和其他硬件的互有关系,如顾客接口、软件接口、硬件接口、通信接口等;5)强加的设计限制或实现约束:阐明必须遵守H勺技术原则和
16、软硬件限制等设计约束,如对硬件配置H勺规定,对软件开发环境限制、运行环境限制和对软件设计、实现方式的限制;六 .包括第五条中未列出但应当在需求分析阐明书中阐明的J其他信息;七 .对第五条第5项详细需求所列出的几类需求的规定:除功能需求总是必须的,其他需求根据产品/项目的实际状况进行增删淘汰。4.1.2.需求项信息完整性需求项信息完整性指每个详细需求的需求项需包括足够的信息,来详细明确定义需求要实现H勺目的。一.针对每个需求项,必须包括下列信息:1 .唯一标识:跟踪需求的标签,唯一且不变,提议采用“项目编号+内部编号”方式,使需求编号在整个企业的范围内都是唯一点;2 .简要描述:简朴描述该需求要
17、实现口勺目口勺;3 .类型:需求H勺类型,依所采用H勺需求分类措施而定;4 .目的:简要描述提出该需求的目的,若很明显则写“略”;5 .来源:谁提出该需求,详细可以是人(客户、顾客、员工)、企业、市场等;6 .详细描述:对该需求H勺详细阐明;由于不同样类型的需求其详细描述需要包括时内容不同样,下面分类列出详细应当包括的详细内容:A.功能性需求:应包括但不仅限于下列内容:1)环境规定,完毕该功能应当满足的详细条件,如什么状态、状况、什么样的软硬件环境下可以进行该功能;2)触发者,使该功能的执行的人或事,可以是顾客或是其他系统、定期事件等;3)输入:描述该功能执行前及在执行过程中所有输入的详细定义
18、。例如:数据类型输入的数据类型、数量、度量单位、源、时间关系、规定(如精度);功能执行过程中的顾客操作控制信息;事件类型输入的事件时间设定;所引用的用以统一定义输入的有关接口阐明或接口控制文献。4)处理:该功能所完毕的任务,即从输入到输出的变换操作过程。详细应包括但不仅限于下列内容:对所有输入H勺有效性检查;对所有输入的处理次序、流程或措施,即系统怎样把输入变换成对应输出,可以使用自然语言、方程式、数学算法、逻辑操作、图、表、状态机等不同样体现方式进行描述;对所有输出有效性的检查;对所有异常状况的处理及响应,例如,溢出、通信故障、要所有非合法输入的响应、错误处理等;5)输出:描述该功能所有最终
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 分析 审查 准则
链接地址:https://www.desk33.com/p-1053073.html