软件需求分析审查准则.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勺技术原则和软硬件限制等设计约束，如对硬件配置H勺规定，对软件开发环境限制、运行环