IEEE指南开发系统需求规格.docx
- 文档编号:26486280
- 上传时间:2023-06-19
- 格式:DOCX
- 页数:34
- 大小:78.27KB
IEEE指南开发系统需求规格.docx
《IEEE指南开发系统需求规格.docx》由会员分享,可在线阅读,更多相关《IEEE指南开发系统需求规格.docx(34页珍藏版)》请在冰豆网上搜索。
IEEE指南开发系统需求规格
IEEE指南:
开发系统需求规格
译者说明:
本指南中系统需求与产品需求相同,系统需求一般不同于硬件需求或软件需求,系统工程师将系统需求分别分配给硬件和软件后才形成硬件需求和软件需求,但是在一个纯软件的系统中,系统需求等同于软件需求。
关于这一点读者可以参考译者所写的《需求管理介绍》。
由于原文作为IEEE标准的特殊性,本译文力争做到准确地表达原文的内容。
对于译者无法准确领会或汉语难于表达其含义的词句,译者都留下关于原文内容的注释,一者供读者参考,二者期望得到读者的帮助。
对于原文本身难于理解的内容,译者根据自己的理解进行了注释。
望能得到读者的指正。
李发君于98.10.17
1.概述
1.1范围
本标准为开发满足已知需要的需求集提供指南,本标准中将这个需求集称为系统需求规格(SyRS),开发SyRS包括对需求进行标识、组织、表达和修改等内容,本指南涉及将运作概念、设计限制和设计配置需求合并到需求规格中的条件,本指南还包括单个需求和需求集合所必须具有的特征和质量。
本指南并非为工业范围内的系统规格定义标准,也不是必须遵循的系统需求规格,写作本指南的原因是认为当前的系统开发技术仍然停留在不能保证或支持正式的标准文档的状态。
2.引文
本标准应该与下述出版品一起使用:
ASTME623-89,StandardGuideforDevelopingFunctionalRequirementsforComputerizedSystems.
IEEEStd100-1992,TheNewIEEEStandardDictionaryofElectricalandElectronicsTerms(ANSI).
IEEEStd610.12-1990,IEEEStandardGlossaryofSoftwareEngineeringTerminology(ANSI).
IEEEStd730-1989,IEEEStandardforSoftwareQualityAssurancePlans(ANSI).
IEEEStd828-1990,IEEEStandardforSoftwareConfigurationManagementPlans(ANSI).
IEEEStd830-1993,IEEEGuideforSoftwareRequirementsSpecifications(ANSI).
IEEEStd1074-1995,IEEEStandardforDevelopingSoftwareLifeCycleProcesses(ANSI).
IEEEStd1220-1994,IEEETrial-UseStandardforApplicationandManagementoftheSystemEngineeringProcess.
ISO9000:
1994,Qualitymanagementandqualityassurancestandards:
Guidelinesforselectionanduses.
ISO9126:
1991,Informationtech.Softwaresystemevaluation,Qualitycharacteristicsandguidelinesfortheiruse.
MIL-STD-490/DI-CMAN-80008A/DI-CMAN-80008,MilitaryStandardSpecificationPractices.
MIL-STD498,MilitaryStandardDefenseSystemSoftwareDevelopment.
3.定义
下面定义的含义依其在本指南中的上下文而定,本标准中没有定义的词目可以在IEEE标准610.12-1990中找到。
3.1分析员:
技术团体的成员(如系统工程师或业务分析员,负责开发系统需求),该成员具有定义问题并分析、开发和表达算法的能力。
3.2附注:
伴随需求提供的进一步的材料,如背景信息和/或描述材料。
3.3基线:
经过正式评审并达成一致意见的系统规格,被用作进一步开发的基础,并且只有通过正式的更改控制程序才能进行修改。
3.4限制:
表达了系统的元素或功能的可度量的边界的陈述句,也就是说,限制是强加于解决方案上的因素,它可能限定或修改设计更改。
3.5客户:
所定义并开发的系统中,满足这些需求所服务的对象实体。
可以是完整系统的最终用户、与开发组织同一个公司中的组织(如系统管理部门)、进行开发工作的公司外部的公司或实体、或者这些实体的某种组合。
系统开发人员必须向他们提交所开发的系统满足指定系统需求的证明。
3.6派生需求:
从需求集合和需求组织演绎或推导出来的需求。
3.7元素:
系统的一个组成部分,可以包括设备、计算机程序或人。
3.8最终用户:
为了特定的目的而最终使用系统的个人或群体。
3.9环境:
将影响整个系统的境况(译者注:
circumstance)、对象和条件,包括政治、市场、文化、组织和物理的影响,同时包括决定系统必须做什么及必须怎么去做的标准和政策。
3.10功能:
为获得期望的成果必须完成的任务、行动或事务。
3.11模型:
现实世界中的过程、设备或概念的表现形式。
3.12原型:
关于系统或系统某一部分的试验模型,可以是功能模型,也可以不是功能模型。
为了改进并定义复杂的人机接口,为了进行可行性研究,为了标识需求,可以使用原型从用户处获得反馈。
3.13原始需求:
尚未被分析并格式化成良形需求(译者注:
well-formedrequirements)的环境需求或用户需求。
3.14表现形式:
逻辑地描绘物理、运作、概念上印象或概念上的情境的影像、图画、图形、块状图、描述或符号。
3.15需求:
(a)用户解决问题或达成目标所需的条件或能力。
(b)系统或系统的部分满足合同、标准、规格或其它必须遵循的正式文档所必须适用的条件和必须拥有的能力。
(c)(a)和(b)中的条件或能力,文档化的表现形式。
3.16系统:
相互依赖的人、物和步骤的组合,通过完成特定的功能,达成预定义的目标并扮演运行的角色。
完整的系统包括运行所需要的所有相关设备、设施、原材料、计算机程序、固件、技术文档、服务和个人,
3.17系统需求规格(SyRS):
系统需求规格由结构化的信息集合组成,该信息集合收录了系统的需求。
3.18可测试性:
对需求的陈述,是否允许为该需求建立测试准则,是否能完成对该需求的测试以判断测试准则得到了满足。
3.19可跟踪性:
开发过程所产生的两个或多个产品之间可以建立关系的程度,特别对那些彼此之间有先后或主从关系的产品,如,需求与给定系统元素的设计之间的匹配程度。
3.20验收(译者注:
validation):
在开发过程中或在开发过程结束的时候对系统或其构件进行评估的过程,以判断系统或其构件满足指定的需求。
(IEEE标准610.12-1990)
3.21验证(译者注:
verification):
为了判断给定开发阶段的系统是否满足了阶段开始时要求其遵循的条件,对系统或其构件进行评估的过程。
3.22良形需求:
一个陈述句,叙述可以得到验收的系统功能(能力),系统必须拥有或满足此功能,以解决客户的问题或达成客户的目标,该功能被可度量的条件所限定,并被限制所绑定。
4.系统需求规格
传统上,系统需求规格(SyRS)一直以可被浏览的文档的形式,向定义并构造系统的技术团体传达客户的需求,那些构成规格和其表现形式的需求在客户和技术团体这两个组之间起一个桥梁的作用,也必须被两者所理解。
建立系统过程中最困难的任务之一就是在这两组的子组之间进行沟通,这种类型的沟通一般需要不同的形式化和语言。
4.1定义
SyRS表现对需要、运作概念和系统分析任务进行定义的结果。
同样地,SyRS也是对系统的客户希望系统为他们做什么、系统期望的环境、系统用途剖析、系统性能参数和期望达到的质量和效率的描述,因此它表现了后面第5条所述SyRS开发过程的结果。
本指南提出,在结构化的信息集和将它们表现给各种读者的方式之间存在区别,SyRS应该采取适合其特定用途的表现形式,可以是印刷文档、模型、原型、其它非印刷的文档、或它们的任意组合,所有这些表现形式均可以从该SyRS推导出来,以满足特定用户的需要。
尽管如此,必须小心地保证从每种表现形式都可以追溯到公共的系统需求信息源,读者应该清楚,在所选定的表现形式之中,结构化的信息集仍然是解决歧义的本源。
本指南清楚划分了SyRS中包含的系统需求(系统必须做什么)与合同文档(如对工作内容的陈述)中包含的处理需求(如何构造系统)之间区别。
4.2特性
需求集应该具有下述特性:
a)唯一集合:
每个需求只被叙述一次。
b)规格化:
需求不应重叠,也就是说,它们不应引用其它的需求或其它需求的能力。
c)链接集合:
应该显式地定义各个需求之间的联系,以表明需求是如何关联着去形成一个完整的系统的。
d)完整性:
SyRS应该包括客户指出的所有需求,同时包括定义系统所需的那些内容。
e)一致性:
SyRS的内容应该一致,在详细程度、需求叙述样式和材料表现形式等方面没有冲突。
f)边界:
应该指明需求集合的边界、范围和上下文。
g)可修改性:
SyRS应该是可修改的,清晰的需求和不重叠的需求有助于此。
h)可配置的:
各版SyRS和版本时间得到维护。
i)粒化:
与所定义系统的抽象程度相同。
4.3目的
SyRS的目的,是根据系统与其外部接口之间的互动和接口,提供一个关于系统应该做什么的“黑盒”描述,SyRS应该完整地描述所有的输入、输出和输入输出之间所需的关系,SyRS在客户和技术团体之间对需求进行组织和沟通。
4.3.1组织需求
通过将系统需求按照概念进行分类,可以最好地达到SyRS的目的。
实际操作中,用户对系统的感知通常包括在定义“需求”的文档中,从这种感知中识别需求并将其分离有一定的难度,传统的用户步骤或用户或技术团体对如何实施的假设,通常遮盖了针对需要的基本陈述,分析员应该捕获客户和技术团体的基本需要并将之叙述出来,形成合适的需求,并按意义对它们进行组织和分组。
将非结构化的用户陈述组织成结构化的需求集合的时候,分析员应该在不要偏离到实现方法的情况下标明技术需求,在清楚理解需求之前就走到如何实现的歧路上,可以导致对需求的不恰当的陈述和错误的实现,洞察技术需求和技术实现之间的区别是对分析员的持续挑战。
对系统的描述应该以动作和逻辑的词目来进行叙述,涉及的问题包括所期望的系统运行能力、物理特征、性能参数及其期望值、与环境的接口、与环境的互动、文档需求、可靠性需求、后勤需求和个人需求。
需求应该以结构化的方式进行沟通,以确保客户和技术团体能够:
a)指明从其它需求推导出来需求
b)按不同的级别对不同详细程度的需求进行组织
c)核实需求集合的完整性
d)指明需求中的不一致性
e)为每个需求清楚指明能力、条件和限制
f)与客户之间就需求集合的目的和目标达成共识
g)指明需求,完成SyRS
分析将结构添加给需求集合,SyRS的表现形式以一种结构化的方式来沟通需求,两者都很重要。
第6条为显式也定义需求提供了原则。
4.3.2两个读者群间沟通
SyRS有两个读者群,从根本上来说被用来记录客户和技术团体之间达成的协议。
4.3.2.1客户
客户是一个集合性质的词目,可以包括所述系统的客户、投资代理、有权停止交货的验收人员和对系统的实现、运行和维护负有督导责任的经理。
所有客户在SyRS中都表达了自己的应该得到解决的兴趣和关心,此外,一些客户可能不清楚建立需求的过程和建立系统的过程,尽管在其责任领域和所定义系统的应用领域范围内他们是有能力的,但是总的来说,他们可能对通常用于定义需求的词汇和表现方法不熟悉。
系统需求分析的主要目标之一是要确保SyRS得到理解,因此有必要使用一种客户能理解的并且是完整的、简炼的及清晰的语言,来向用户表现SyRS。
4.3.2.2技术团体
SyRS也应该把客户的需求向技术团体传达。
技术团体包括分析员、估计人员(译者注:
estimators,此处应该指对工作量进行估计以便制定工作计划的人员)、设计人员、质量保证官员、认证人员、开发人员、工程师、集成人员、测试人员、维护人员和制造人员,对于这样的读者,SyRS的表现形式应该在技术上是精确的,并且是形式化的以便他们能以之为依据而设计、建立并测试所需要的系统。
4.4使用场合
对SyRS的使用,建议随开发周期的不同而不同。
如下述:
a)在系统设计过程中,需求被分配给子系统、硬件、软件、操作和系统其它的主要构件。
b)SyRS被利用于构造最终的系统,SyRS也被用于写作系统验证计划,如果系统包含硬件和软件,那么硬件测试计划和软件测试计划也从系统需求产生。
c)在实现阶段,测试步骤从SyRS定义而来。
d)在验收阶段,基于SyRS的验收程序被用作客户接受系统的基础。
如果需要对SyRS基线进行任何更改,它们必须在一个正式的改变管理过程的控制之下,此过程包括在受影响的成员之间进行协商,并进行相关的风险评估(如计划或费用)。
4.5收益
一个优秀的SyRS可以在生命周期的所有后续阶段上从几个方面获益。
SyRS记录了系统能力的全集,并提供下面的好处:
a)向客户保证技术团体明白客户的需要并对客户回应
b)客户和技术团体之间双向反馈的早期机会
c)在相对容易改正的时候为客户和技术团体提供一个识别问题和误解的方法
d)写作系统合格证明书的基础,该证明书说明系统满足客户需要
e)技术团体的护身符,为系统能力提供一个基线,并为判断系统何时已完成构建提供基础
f)支持开发人员的纲要计划、设计和开发努力
g)帮助评估不可避免的需求更改带来的影响
h)随着开发进展,防止客户与技术团体之间的误解
4.6系统需求的动态性
需求很少是静态的,永久地固定需求集合是一种奢望。
应该在客户和技术团体之间就那些可能改进的需求达成共识,但是需求的核心子集可以早早确定。
为某种目的新提交的需求所带来的影响必须经过评估,以确保需求基线的最初意向得到维护,而且对意向的改变一定要得到客户的理解和接受。
5.SyRS开发过程概述
本条简要描述SyRS开发过程的步骤。
总的来说,系统需求开发过程与三个外部代理--客户、环境和技术团体之间具有接口,每个外部代理在下文描述。
图1显示了开发SyRS所需各种代理之间的互动。
原始需求
客户反馈
技术反馈
客户表现形式
限制/影响
技术表现形式
图1--开发SyRS的上下文
5.1客户
客户是SyRS上下文的要素,他们是向SyRS过程提供他们的目标、需要或问题的主体。
客户和SyRS的开发人员之间交换的内容在下面讨论。
5.1.1原始需求
在SyRS的过程开始之前,或者是关于过程,或者是关于需要解决的问题,客户已经对系统有了一个想法,此时,关于系统的任何初始概念都可能是不准确并且未结构化的,需求经常与可能采用的设计方法方面的主意和建议混杂成一体,这些原始需求通常在与下述相近的初始文档中得到表达:
a)运行概念:
此类文档关注待实现系统的目标(译者注:
goals)、目的(译者注:
objectives)和所期望系统的一般能力,但不表明系统应该如何实现来实际达成目标。
b)系统概念:
此类文档包括关于运行信息的概念,但是也将包括初步的系统接口设计和其它的外在需求。
c)市场规格:
此类文档包括新系统或系统的特性列表(ofteninbulletformat),并指明特性的范围和为了建立市场优势实现这些特性的优先级(即必须实现的或很想要的),它也包括用来定义新系统如何与现存系统相互作用的上下文和边界。
可能还提供有成本/效益分析和发货时间表。
d)招标说明书(译者注:
RequestforProposal,不知所译当否):
某些情况下可能备有招标说明书,它可能包括一个或数个上述初始文档,其目的是招引多方投标来构造系统,或者简单地只是为产生系统初始文档而寻求帮助。
e)系统外部接口:
以逐字逐句或以引用的方式来完成对系统所有外部接口的定义,是在产生SyRS之间应该完成的最重要的(通常也是把握全局的)的事情之一。
对系统外部的全域的正确的定义,自然地绑定并限制了系统内部需要做些什么。
每个单独定义的接口的所有已知元素应该得到描述,此信息如果不是过分庞大的话可以包括在SyRS中,但多数情况下使用系统外部接口控制文档(ICD)更好。
系统外部可能有多种类型的接口,单个系统可能有不同类型的多个接口。
下面的列表提供了一些例子:
--运行的
--计算机与计算机间的
--电子的
--数据链路和协议
--电信线路
--设备与系统间、系统与设备间的
--计算机与系统间、系统与计算机间的
--环境感知和控制接口
5.1.2客户表现形式
对客户的反馈包括SyRS的表现形式,以及为使需求清晰和/或使需求得到确定而进行的交流和沟通。
5.1.3客户反馈
客户反馈包括对客户的目标、需要或问题进行更新的信息,和关于技术交流方面的需求更改,以及指明新的需求。
5.2环境
除了分析员和客户之外,环境也能够隐式地或显式地影响系统需求或对系统需求加以限制,分析员应该意识到对系统能力的这种影响。
在系统对环境敏感的情形下,由客户和分析员来确定环境对系统需求的影响,描述影响系统的环境。
环境影响可以被分成重叠的类别,如下述:
a)政治的
b)市场的
c)标准和技术规定的
d)文化的
e)组织的
f)物理的
这些类别在下面描述。
尽管如此,必须意识到这些描述只是应该考虑到的表现因素,列表内容尚不全面。
5.2.1政治影响
国际、联邦、州和当地政府机构有着影响系统需求的法律和法规,一些政府机构可能有强制性的组织来检查是否与法律和法规相一致。
这样的政府法律的例子有版权法、专利法和商标法,政府法规的例子有行政区划规定、环境危害规定、废物管理规定、回收规定、系统安全性规定及健康规定。
政治影响如同政治边界的功能一样改变,在某个环境中影响系统需求的那些东西可能与在另一个环境中完全不同,因此,为确保系统与所有的政府法律法规相一致,以系统制造或使用的政治环境来指引研究,是很重要的。
5.2.2市场影响
有三种类型的市场条件影响到系统规格的开发。
首先,通过市场研究或者通过开发与技术研究相匹配的市场,来将客户的需求与系统相匹配。
以客户的需求来匹配系统的方式通常预先影响到系统需求,并成为客户需求的一部分。
第二个市场影响是对要求进行满足的影响,此影响是图1中环境输入的一部分。
由于如何满足要求会影响到系统的分布性和可访问性,一定要考虑到此影响。
分布性和可访问性是对系统需求的补充。
例如,要求系统重量要轻以降低运输成本,或者系统尺寸要小以放入自动售货机。
在系统开发过程中和在系统制造或集成之前,为了使得需求能被合并到系统之中,必须先指明分布性和可访问性的需求。
如果不能方便地访问系统,系统的成功将会受限,因此,进行市场定位和考虑如何从市场信息导出系统需求都很重要。
第三个市场影响是竞争,了解竞争对手的系统将有助于定义系统需求。
为了保持竞争力,应该考虑下面的因素:
a)功能
b)价格
c)可靠性
d)持久性
e)性能
f)可维护性
g)系统保险性(译者注:
safety)和安全性(译者注:
security)
对竞争性的市场进行分析是一个持续的过程,且会同时影响到新系统和现存系统的需求。
系统能够逐渐进化成一个全新的系统,从而与客户最初的概念只有极小的共同之处。
5.2.3标准和技术规定的影响
系统需求受客户的直接影响,而客户必须遵守政府或工业界颁布的标准和技术规定。
技术规定、相关标准和指南有助于确保:
a)系统一致性
b)系统安全性(译者注:
safety)
c)系统可靠性和可维护性
系统一致性标准和指南通过提供关于应该如何实现特定系统的详细资料,规定了特定的需求。
为了帮助避免安全(译者注:
safety)方面的危险和潜在的法律问题,必须遵守工业安全性(译者注:
safety)标准,在系统需求文档中必须清楚指明顺从安全性(译者注:
safety)的需求(注:
玩具制造工业的安全性需求、UL认证、NationalElectricalCode需求)。
客户和技术可能要求系统必须遵循技术标准中规定的某些可靠性标准,SyRS中应该指明可靠性和可维护性需求。
这些需求可能以多种形式提出来,例如,它们可能是直接面向系统的,并可能要求关于最大损耗时间及最小无故障平均时间、或最小维修平均时间等方面的规格。
5.2.4文化影响
文化是代代相传的整体的人类行为模式,它是一种能通过学习掌握的经验,此经验产生于宗教信仰、国家起源、种族群体、社会经济发展水平、语言、媒体、职业厂所和当前的家庭。
为了理解地区文化或所定位市场的文化,必须了解人们的价值观和信仰。
由于能影响系统需求,开发系统时应该考虑到文化的影响。
5.2.5组织影响
系统需求受开发需求所在的组织的影响。
公司的组织影响能够以市场、内部政治、技术规定和内部标准的形式显现,公司对系统需求的影响与其它外围的影响相似,也就是说,各公司都有自己的文化、目的(译者注:
purposes)、价值和目标(译者注:
goals),而这些方面能够并将会影响到公司所开发、制造和/或销售的系统。
5.2.6物理影响
物理影响包括自然的和人为的影响如温度、辐射、潮湿、压力和化学。
5.3技术团体
图1中的技术团体,由那些涉及到系统设计、实现、集成、测试、制造、发布、操作和维护的人员组成,技术团体的所有成员应该尽早加入到SyRS的开发过程中来,这样能为SyRS的开发人员提供一种减少在系统生命周期的晚期才发现新需求或改变原始需求的可能性的机制。
5.3.1技术表现形式
为技术团体准备的需求集的表现形式,可以包括技术性的交流和沟通的内容,这些内容能使需求更清晰和确定。
5.3.2技术反馈
在各种活动中技术团体产生反馈,这种反馈能导致对需求集的修改、增加和/或删除,必要的时候通过细化SyRS来支持系统的后续生命周期阶段。
例如,在需求阶段之后,就要生成测试计划,在测试计划中将需求分配给特定的测试,这个过程将发现不可测试的需求并为了确保可测试性导致对SyRS的修改。
从技术团体来的其它反馈,可以向客户提供最新系统的特性、即将产生的新技术和对先进的实现方法的洞察。
6.良形需求
本条解释形式良好的需求的特性,提供一个良形需求的例子,并指出需求的陷阱。
6.1良形需求的定义
如前所述,良形需求是一个陈述句,叙述可以得到验收的系统功能(能力),系统必须拥有或满足此功能,以解决客户的问题或达成客户的目标,该功能被可度量的条件所限定,并被限制所绑定。
这个定义有助于将一般的客户需求分类,需求可以产生于客户的需要,也可以从技术分析推导出来。
此定义为区分作为能力的需求和那些需求的属性(条件和限制)提供了手段。
限制可以是功能性的也可以是非功能性的,一个非功能性的限制的例子是:
在系统的那些不需装饰效果的地方单独涂上一种特定的蓝色阴影。
本指南建议不要把处理需求的系统实现方法如指定一个特定的设计方法包括在SyRS中,对需求的处理应该包括在其它的系统控制技术文档如质
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IEEE 指南 开发 系统 需求 规格