IEEE指南：开发系统需求规格

 

IEEE指南：开发系统需求规格 

译者说明：

本指南中系统需求与产品需求相同，系统需求一般不同于硬件需求或软件需求，系统工程师将系统需求分别分配给硬件和软件后才形成硬件需求和软件需求，但是在一个纯软件的系统中，系统需求等同于软件需求。关于这一点读者可以参考译者所写的《需求管理介绍》。

由于原文作为IEEE标准的特殊性，本译文力争做到准确地表达原文的内容。对于译者无法准确领会或汉语难于表达其含义的词句，译者都留下关于原文内容的注释，一者供读者参考，二者期望得到读者的帮助。对于原文本身难于理解的内容，译者根据自己的理解进行了注释。望能得到读者的指正。

李发君于98.10.17

1. 概述 

1.1 范围 

本标准为开发满足已知需要的需求集提供指南，本标准中将这个需求集称为系统需求规格（SyRS），开发SyRS包括对需求进行标识、组织、表达和修改等内容，本指南涉及将运作概念、设计限制和设计配置需求合并到需求规格中的条件，本指南还包括单个需求和需求集合所必须具有的特征和质量。 

本指南并非为工业范围内的系统规格定义标准，也不是必须遵循的系统需求规格，写作本指南的原因是认为当前的系统开发技术仍然停留在不能保证或支持正式的标准文档的状态。 

2. 引文 

本标准应该与下述出版品一起使用： 

ASTM E 623-89, Standard Guide for Developing Functional Requirements for Computerized Systems. 

IEEE Std 100-1992, The New IEEE Standard Dictionary of Electrical and Electronics Terms (ANSI). 

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI). 

IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI). 

IEEE Std 828-1990, IEEE Standard for Software Configuration Management Plans (ANSI). 

IEEE Std 830-1993, IEEE Guide for Software Requirements Specifications (ANSI). 

IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes (ANSI). 

IEEE Std 1220-1994, IEEE Trial-Use Standard for Application and Management of the System Engineering Process. 

ISO 9000: 1994, Quality management and quality assurance standards: Guidelines for selection and uses. 

ISO 9126: 1991, Information tech. Software system evaluation, Quality characteristics and guidelines for their use. 

MIL-STD-490/DI-CMAN-80008A/DI-CMAN-80008, Military Standard Specification Practices. 

MIL-STD 498, Military Standard Defense System Software Development. 

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-formed requirements）的环境需求或用户需求。 

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 系统需求的动态性 



需求很少是静态的，永久地固定需求集合是一种奢望。应该在客户和技术团体之间就那些可能改进的需求达成共识，但是需求的核心子集可以早早确定。为某种目的新提交的需求所带来的影响必须经过评估，以确保需求基线的最初意向得到维护，而且对意向的改变一定要得到客户的理解和接受。 


1. SyRS开发过程概述 



本条简要描述SyRS开发过程的步骤。总的来说，系统需求开发过程与三个外部代理--客户、环境和技术团体之间具有接口，每个外部代理在下文描述。图1显示了开发SyRS所需各种代理之间的互动。 

技术反馈

客户表现形式

技术表现形式

限制/影响

客户反馈

原始需求

客户

环境

开发

系统

需求集

技术团体


图1--开发SyRS的上下文 
（略 sorry）

1.1 客户 


客户是SyRS上下文的要素，他们是向SyRS过程提供他们的目标、需要或问题的主体。客户和SyRS的开发人员之间交换的内容在下面讨论。 


5.1.1 原始需求 

在SyRS的过程开始之前，或者是关于过程，或者是关于需要解决的问题，客户已经对系统有了一个想法，此时，关于系统的任何初始概念都可能是不准确并且未结构化的，需求经常与可能采用的设计方法方面的主意和建议混杂成一体，这些原始需求通常在与下述相近的初始文档中得到表达： 

a) 运行概念：此类文档关注待实现系统的目标（译者注：goals）、目的（译者注：objectives）和所期望系统的一般能力，但不表明系统应该如何实现来实际达成目标。 

b) 系统概念：此类文档包括关于运行信息的概念，但是也将包括初步的系统接口设计和其它的外在需求。 

c) 市场规格：此类文档包括新系统或系统的特性列表（often in bullet format），并指明特性的范围和为了建立市场优势实现这些特性的优先级（即必须实现的或很想要的），它也包括用来定义新系统如何与现存系统相互作用的上下文和边界。可能还提供有成本/效益分析和发货时间表。 

d) 招标说明书（译者注：Request for Proposal，不知所译当否）：某些情况下可能备有招标说明书，它可能包括一个或数个上述初始文档，其目的是招引多方投标来构造系统，或者简单地只是为产生系统初始文档而寻求帮助。 

e) 系统外部接口：以逐字逐句或以引用的方式来完成对系统所有外部接口的定义，是在产生SyRS之间应该完成的最重要的（通常也是把握全局的）的事情之一。对系统外部的全域的正确的定义，自然地绑定并限制了系统内部需要做些什么。每个单独定义的接口的所有已知元素应该得到描述，此信息如果不是过分庞大的话可以包括在SyRS中，但多数情况下使用系统外部接口控制文档（ICD）更好。系统外部可能有多种类型的接口，单个系统可能有不同类型的多个接口。下面的列表提供了一些例子： 

--运行的 

--计算机与计算机间的 

--电子的 

--数据链路和协议 

--电信线路 

--设备与系统间、系统与设备间的 

--计算机与系统间、系统与计算机间的 

--环境感知和控制接口 


5.1.2 客户表现形式 

对客户的反馈包括SyRS的表现形式，以及为使需求清晰和/或使需求得到确定而进行的交流和沟通。 

5.1.3 客户反馈 

客户反馈包括对客户的目标、需要或问题进行更新的信息，和关于技术交流方面的需求更改，以及指明新的需求。 

1.2 环境 

除了分析员和客户之外，环境也能够隐式地或显式地影响系统需求或对系统需求加以限制，分析员应该意识到对系统能力的这种影响。在系统对环境敏感的情形下，由客户和分析员来确定环境对系统需求的影响，描述影响系统的环境。环境影响可以被分成重叠的类别，如下述： 

a) 政治的 

b) 市场的 

c) 标准和技术规定的 

d) 文化的 

e) 组织的 

f) 物理的 

这些类别在下面描述。尽管如此，必须意识到这些描述只是应该考虑到的表现因素，列表内容尚不全面。 

1.2.1 政治影响 

国际、联邦、州和当地政府机构有着影响系统需求的法律和法规，一些政府机构可能有强制性的组织来检查是否与法律和法规相一致。这样的政府法律的例子有版权法、专利法和商标法，政府法规的例子有行政区划规定、环境危害规定、废物管理规定、回收规定、系统安全性规定及健康规定。 

政治影响如同政治边界的功能一样改变，在某个环境中影响系统需求的那些东西可能与在另一个环境中完全不同，因此，为确保系统与所有的政府法律法规相一致，以系统制造或使用的政治环境来指引研究，是很重要的。 

1.2.2 市场影响 

有三种类型的市场条件影响到系统规格的开发。首先，通过市场研究或者通过开发与技术研究相匹配的市场，来将客户的需求与系统相匹配。以客户的需求来匹配系统的方式通常预先影响到系统需求，并成为客户需求的一部分。 

第二个市场影响是对要求进行满足的影响，此影响是图1中环境输入的一部分。由于如何满足要求会影响到系统的分布性和可访问性，一定要考虑到此影响。分布性和可访问性是对系统需求的补充。例如，要求系统重量要轻以降低运输成本，或者系统尺寸要小以放入自动售货机。在系统开发过程中和在系统制造或集成之前，为了使得需求能被合并到系统之中，必须先指明分布性和可访问性的需求。如果不能方便地访问系统，系统的成功将会受限，因此，进行市场定位和考虑如何从市场信息导出系统需求都很重要。 

第三个市场影响是竞争，了解竞争对手的系统将有助于定义系统需求。为了保持竞争力，应该考虑下面的因素： 

a) 功能 

b) 价格 

c) 可靠性 

d) 持久性 

e) 性能 

f) 可维护性 

g) 系统保险性（译者注：safety）和安全性（译者注：security） 

对竞争性的市场进行分析是一个持续的过程，且会同时影响到新系统和现存系统的需求。系统能够逐渐进化成一个全新的系统，从而与客户最初的概念只有极小的共同之处。 

1.2.3 标准和技术规定的影响 

系统需求受客户的直接影响，而客户必须遵守政府或工业界颁布的标准和技术规定。技术规定、相关标准和指南有助于确保： 

a) 系统一致性 

b) 系统安全性（译者注：safety） 

c) 系统可靠性和可维护性 

系统一致性标准和指南通过提供关于应该如何实现特定系统的详细资料，规定了特定的需求。 

为了帮助避免安全（译者注：safety）方面的危险和潜在的法律问题，必须遵守工业安全性（译者注：safety）标准，在系统需求文档中必须清楚指明顺从安全性（译者注：safety）的需求（注：玩具制造工业的安全性需求、UL认证、National Electrical Code需求）。 

客户和技术可能要求系统必须遵循技术标准中规定的某些可靠性标准，SyRS中应该指明可靠性和可维护性需求。这些需求可能以多种形式提出来，例如，它们可能是直接面向系统的，并可能要求关于最大损耗时间及最小无故障平均时间、或最小维修平均时间等方面的规格。 

1.2.4 文化影响 

文化是代代相传的整体的人类行为模式，它是一种能通过学习掌握的经验，此经验产生于宗教信仰、国家起源、种族群体、社会经济发展水平、语言、媒体、职业厂所和当前的家庭。为了理解地区文化或所定位市场的文化，必须了解人们的价值观和信仰。由于能影响系统需求，开发系统时应该考虑到文化的影响。 

1.2.5 组织影响 

系统需求受开发需求所在的组织的影响。公司的组织影响能够以市场、内部政治、技术规定和内部标准的形式显现，公司对系统需求的影响与其它外围的影响相似，也就是说，各公司都有自己的文化、目的（译者注：purposes）、价值和目标（译者注：goals），而这些方面能够并将会影响到公司所开发、制造和/或销售的系统。 

1.2.6 物理影响 

物理影响包括自然的和人为的影响如温度、辐射、潮湿、压力和化学。 

1.3 技术团体 

图1中的技术团体，由那些涉及到系统设计、实现、集成、测试、制造、发布、操作和维护的人员组成，技术团体的所有成员应该尽早加入到SyRS的开发过程中来，这样能为SyRS的开发人员提供一种减少在系统生命周期的晚期才发现新需求或改变原始需求的可能性的机制。 

1.3.1 技术表现形式 

为技术团体准备的需求集的表现形式，可以包括技术性的交流和沟通的内容，这些内容能使需求更清晰和确定。 

1.3.2 技术反馈 

在各种活动中技术团体产生反馈，这种反馈能导致对需求集的修改、增加和/或删除，必要的时候通过细化SyRS来支持系统的后续生命周期阶段。 

例如，在需求阶段之后，就要生成测试计划，在测试计划中将需求分配给特定的测试，这个过程将发现不可测试的需求并为了确保可测试性导致对SyRS的修改。 

从技术团体来的其它反馈，可以向客户提供最新系统的特性、即将产生的新技术和对先进的实现方法的洞察。 

2. 良形需求 

本条解释形式良好的需求的特性，提供一个良形需求的例子，并指出需求的陷阱。 

2.1 良形需求的定义 

如前所述，良形需求是一个陈述句，叙述可以得到验收的系统功能（能力），系统必须拥有或满足此功能，以解决客户的问题或达成客户的目标，该功能被可度量的条件所限定，并被限制所绑定。 

这个定义有助于将一般的客户需求分类，需求可以产生于客户的需要，也可以从技术分析推导出来。此定义为区分作为能力的需求和那些需求的属性（条件和限制）提供了手段。限制可以是功能性的也可以是非功能性的，一个非功能性的限制的例子是：在系统的那些不需装饰效果的地方单独涂上一种特定的蓝色阴影。 

本指南建议不要把处理需求的系统实现方法如指定一个特定的设计方法包括在SyRS中，对需求的处理应该包括在其它的系统控制技术文档如质量计划、合同或对工作内容的陈述中。 

2.1.1 能力 

能力是系统的基本需求并表现了客户所需要或期望的系统特征。能力通常应该以一种描述系统应该做什么的方式来叙述，能力也应该以一种独立于解决方法的方式来叙述，这样使得为满足需要或提供功能特征而考虑采用不同的方法成为可能。例如，洛杉矶与纽约之间的高速铁路系统应该包括启动、加速、行驶、减速、停止、上下乘客的能力，该高速铁路系统的能力不包括计算机操作系统这一部分。 

2.1.2 条件 

条件是对能力进行规定的关于质量和数量的属性和特征，它们进一步限定了所需要的能力并提供属性，此属性使得以简明的方式并以可验收和可验证的方式来叙述能力成为可能。例如，在上述的高速铁路系统中，关于行驶能力的一个条件，可以是在0~300km/hr的范围内行驶或者是经济行驶速度为200km/hr。 

仅当将条件（可度量的属性）应用于需要度量的某种事物如能力时，包含条件才有意义。例如，一个系统需求抽象地叙述0~200km/hr是毫无意义的，这个范围可以限定高速铁路线路上的行驶速度，而不是电梯乘载乘客时的的速度。 

条件可能限制设计人员的选择。为了确保在不对解决方法的空间强加不必要的限制的情况清晰地定义需求，指明那些作为能力的属性的条件而不是作为主要能力的条件很重要。 

2.1.3 限制 

限制是环境、压力或不可抗拒的力量强加给设计方法的需求，通过强加不可移动的边界和界限，限制以绝对的方式限定了开放给设计人员的对设计方法的选择。例如，上述高速铁路系统会被将人们活着运抵目的地的需要所限制，而且也能够通过技术得到限制（客户可能要求所有列车控制软件用Ada语言来编写）。 

一个关于限制的清单可以包括与接口已定的现存系统之间的接口（如格式、协议或内容）、物理尺寸限制（如控制器必须放在飞机机翼有限的空间内）、自然的法则、特定国家的法律、可用时间或预算、优先级（必须的或可选的）或者一个已经存在的技术平台。 

限制可以应用于所有的需求，或者通过与特定能力或能力集间的关系来得到定义。 

可以以独立的需求的形式来指明限制，即不与任何特定的能力捆绑，也可以是对单个能力的限制。 

2.1.4 例子 

这个例子的目的是叙述一条良形需求及与之相关的条件和能力需求，如下述： 

以最高速度5300km/hr将乘客从纽约运送到洛杉矶。（译者注：本例中的数字可疑，但原文如此） 

能力：在洛杉矶和纽约之间运送乘客 

条件：行驶速度2500km/hr 

限制：最在速度300km/hr 

2.2 需求的属性 

每个需求应该拥有下列属性： 

a) 抽象性：需求应该独立于实现方法 

b) 无二义性：每个需求应该以只能有一种解释的方式来叙述 

c) 可跟踪性：对于每个需求，可以在所记录的客户对需要的叙述与定义系统的SyRS中的叙述之间找到一种关系，作为需求的来源的证据 

d) 可验收的：每个需求都应该有手段来证明系统满足了此需求 

2.3 分类 

为了便于对需求进行分析，应该根据其标识、优先级、重要性、可行性、风险、来源和类型来将需求分类。每种分类的依据在下面详细描述： 

a) 标识：应该唯一地标识每个需求（注：编号、名字标签、助记法、按钮、超文本），需要的时候能够用标识来反映联接和关系，不同的需求也可以通过标识得到区分。 

b) 优先级：客户应该指明每个需求的优先级，这一点可以通过潜在的客户的多数意见来获得。适当的时候，可以使用比例如1:10或者使用简单的词目如高、中、低和无来指明每个需求的优先级。 

c) 重要性：与客户一起工作的分析员应该定义每个需求的重要性，从用户的观点来看某些需求可能只有较低的优先级，然而却是系统成功所不可或缺的。例如，度量外围温度的需求可以为别的需求如维护柜内温度提供必不可少的支持。应该指明这种关系，以便客户取消主要的需求时可以同时清除那些为之提供支持的需求。 

d) 可行性：客户和分析员应该共同指明将每个特定的需求包括在系统中的可行性，并根据可适用于系统领域的可行性类型将其分类。基于对一些如技术的当前状态（如比较购买商业构件和自主研究），以及对与特定需求相关连的风险或成本等内容的理解，可以获知其可行性。 

e) 风险：可以使用风险分析技术将系统需求分级。根据它们的因果关系或风险的可避免性，多数风险与潜在的财务损失、环境影响、安全和健康问题以及国家标准或法律相关。 

f) 来源：应该进一步通过标明其起源来将每个需求分类。可以被当作某个需求的产生原因的来源可以有多个，指明每个需求的起源很有好处，以便当需求不清楚、相互冲突或需要被删改的时候能够找到需要商议的个人或组织。 

g) 类型：也可以按照下述一或数种类型将需求分类： 

--输入（如接收EDI数据） 

--输出（如输出一种特定的格式） 

--可靠性（如平均无故障时间） 

--可维护性（如哪个构件易于被替换） 

--性能（如响应时间） 

--可访问性（如为初学者和有经验的用户提供的不同的浏览路径） 

--环境条件（如必须忍受的灰尘度） 

--人类工程学的（如使用特殊的颜色来减少眼睛的紧张） 

--安全性（如低于指定的电磁辐射界限） 

--设施需求（如使用家用电源） 

--可运输性（如可携带的重量界限） 

--培训（如包括指南或基于计算机的训练） 

--文档（如在线帮助） 

--外部接口（如对工业标准互通模式/格式的支持） 

--测试（如支持远程诊断） 

--质量规定（如最小刻度间隔） 

--政策和管制（如环境保护机构的政策） 

--转换（如将接受老版本系统产生的数据） 

--扩充能力（如将支持额外数目的用户） 

--安装（如使新系统投入使用的能力） 



2.4 陷阱 



构造良形需求的时候要避免下述陷阱： 



a) 设计和实现：从定义需求的分析员和客户这方面来讲，倾向于把设计和实现方法与对需求的陈述包括在一起。这些关于设计和实现方面的信息可能仍然是重要的，在这种情况下，为了对设计和实现提供帮助，应该在其它形式的文档中记录这些信息。 

b) 超出规格： 

--关于可以购买到而不用自做的系统的需求（这些内容并不表达系统应该做什么） 

--太过深入地叙述系统中关于可以容忍的偏差的需求（在很低的级别叙述错误的需求） 

--关于实现方案的需求（需求应该叙述一种需要） 

c) 过度限制：对需求进行不必要的限制（例如，如果一个系统必须能基于可充电电池来运行，那么就可能派生出一个充电时间小于3小时的需求，但是在12个小时的充电时间也是足可接受的情况下前面的派生需求就显得过于严格，从而消除了一些潜在可行的实现方案） 

d) 不确定性： 

--以相对的方式叙述需求（这种需求无法得到验证且只有重新叙述。如，需求“最小的噪音”可以被重新叙述为“噪音强度不应该超过…” 

--没有结束的需求（频繁地叙述“包括但不限于…”或者用“等等”作为列表的结束） 

--主观或含糊地叙述需求（频繁地使用词目如用户友好、快速响应时间或费用低廉） 

e) 假设： 

--需求基于未经记录的假设（假设也应该象需求一样被写出来） 

--需求基于通过当前的开发将会完成某个特定的标准或系统的假设（此假设及可替代的需求应该被写出来） 

1. SyRS开发 

图1（略 sorry）所示的系统开发是一个循环的过程，其中4个子过程在图2中显示。这些子过程是： 

a) 指明从客户、环境和技术团体的经验产生的需求 

b) 建立良形需求 

c) 将需求组织到SyRS中 

d) 向不同的读者提交不同的SyRS的表现形式 

将系统需求开发过程分解成子过程的目的是为了有助于完整而准确地开发SyRS。下面的子过程以发生顺序的方式表现，但子过程在某种程度经常存在重叠和循环。 

此过程的循环应用导致对SyRS的不断修改。通常地，修改基于SyRS基线进行，并被置于改变控制规程的管理之下。关于改变控制规程可参看IEEE标准1220-1994。 

已组织的

需求集

需求

限制/影响

客户反馈

技术反馈

原始的

客户

环境

客户

技术

团体

识别

需求

建立

良形

需求

表现

需求

组织

需求

良形需求数据

良形需求

客户

客户

技术表现

技术团体


图2--SyRS开发过程（略 sorry） 


1.1 识别需求 

通过和客户一起工作，分析员将图2中的各种输入经过筛选抽取一些需求，建立必要的派生需求和一般的需求，需求可以从初始文档中抽取出来，也可以通过引导用户进行分析性的训练来获得。此循环过程的目标是获得所有的系统需求，确保每个需求只叙述了一次，并确保没有遗漏。 

可以采用多种方法来识别客户需求，在实际操作中，每个组织都有自己的识别需求和开始建立系统解决方案的方法。在某些组织中，客户将独力承担整个过程，这种情形下对需求的识别和定义将由客户来驾驭，在另外一些组织中，客户将定义一个初步的需求集合，并请求组织内部的系统分析员的协助，或者通过与外部的顾问或系统集成商签约来获得协助。 

无论是组织内部和外部的分析员，都应该和客户一起工作来识别需求并将需求结构化，在某些组织中分析员直接和客户一起工作，在另外一些组织中，分析员无法直接与客户打交道，因此将和一或数个代表客户的中间层一起工作。 

由于标识需求过程的动态特性，客户和分析员对这个过程达成共识很重要。分析员应准备指导这个过程计划，定义向不同的读者提交的SyRS的表现形式，并指明将要用到的工具和技术。 

此过程应该向开发SyRS数据库的目标和向客户提供满足其需要的目标迈进，分析员应该确保在标识需求的过程中使用所有合适的技术。 

应该采用需求管理过程来确保： 

a) 这个过程是目标导向的并针对需求集合的产生 

b) 定义了系统的边界 

c) 所有的需求都是调查得来的、经过认真评估的及以文档的方式记录下来的 

d) 需求被定义成能力，并且从该能力明确指明了限定条件和边界限制 

e) 根据需求集合中的需求是否有效来决定某需求被保留或被遗弃 

f) 多人（“作者”）合力开发需求集合时，应该注意一致性 

g) 在适当的详细程度上，此过程的所有参与者都应该明白所开发的需求集合 

1.1.1 识别需求的技术 

需求以主意或概念为开端，它们可能始于认识到安全性（译者注：security）或市场份额受到威胁时做出的反映，始于法制或法规的强制性，始于建立新的或更好的系统或过程的渴望，始于取代现存系统的需要，或者始于别的什么实际需求或认识到的需要。尽管这些主意或概念可能产生于某个个人，但是需求集合通常以从具有共同想法及形成该想法的群体之间的互动中获得为最佳。 

标识需求有一些技术，它们包括： 

a） Structured workshops 

b） 头脑风暴会议或问题-方案会议 

c） 会谈 

d） 调查/问卷 

e） Observation of work pattern（e.g., time and motion studies） 

f） 研究系统的组织和政治环境（e.g., sociogram） 

g） 技术文档评审 

h） 市场分析 

i） 对手系统评定 

j） 逆向工程（译者注：没有查到相关的定义，我觉得正向工程是指从需求导出产品的过程和子过程，逆向工程与之相反：指从后期的工作产品导出作为其基础的前期工作产品的过程。Rational公司在其资料中把从已有的C++代码中导出反映需求的USE CASE模型的过程称为逆向工程，可为一例证） 

k） 仿真 

l） 原型 

m）将过程和系统基准化 

1.1.2 客户与分析员之间的互动 

在分析员受雇与客户一起工作的情形中，有必要为这两个团体建立一个高效的互动过程，为了使这个过程富有成效，每个团体都应明白他们有培训对方的任务，并明白他们应该通过一起工作来共同定义需求。 

1.1.2.1 相互培训 

培训可以是一个双向的过程。首先，分析员需要获知客户的环境、当前的系统（如果有的话）以及需求，双方在这个培训过程上都应花费时间并付出努力。 

其次，客户可能也需要培训。在定义需求的过程中客户可能需要来自分析员的培训，此外，关于需求自身及如何根据经验产生需求，可能需要分析员来培训客户。 

1.1.2.2 共同定义需求 

客户和分析员在定义需求的过程中可以采用多种互动方式，例如，分析员可以简单地引导会谈来获得所需信息，然后组织需求并将它们提交给客户评审。 

分析员的经验非常重要，但是切不可采用任何方式误导或窒息客户的参与，他们与客户一起工作的时候，其主要任务就是从客户处获得需求并组织需求，他们可以以自己的经验或者从以前定义的系统方案中添加需求，但是有前提条件：这些额外的需求被客户遗漏了，而对客户来说这些需求清楚地给所定义的系统带来了好处，而且这些需求被客户所接受。 

作为另一个例子，客户中的个体可能与分析员一起参加工作会议，在这些场合中，可能有大量的头脑风暴和对需求的交互式定义，这些会议通常由分析员来主持和引导，这些场合的成果由分析员记录。 

一个更协作（共同定义）的方法，是使客户更直接地参与定义需求，客户甚至可以以写作SyRS的方式来参加对需求的定义。 

无论采用什么手段，目的是在达成一致意见和共同理解的基础上定义需求，客户和分析员需要走到一个共同点上，在这点上他们对需求有共同的理解并将此理解以SyRS的形式进行表现，以此达成客户的满意。 

1.2 建立良形需求 

分析员通过进行下面的工作来完成这个子阶段： 

a） 确保每个需求是必要的、简短的、是对需要（能力、限制）的陈述 

b）为每个需求定义适当的条件（质量或数量的量度），并避免象resistant或industry wide这样的形容词 

c） 避开需求陷阱（参看6.4） 

d）确保可读性，可读性有如下要求： 

--简单的词/词组/概念 

--为排列和关系的采用同样的形式 

--定义专用的词、符号和图符 

--对语言和象征的使用应该合乎文法 

e） 确保可测试性 

下面是一个如何从客户的最初陈述产生良形需求的例子。客户的陈述“在洛杉矶和纽约之间运送乘客”是一种对原始需求的陈述，也是良形需求的基础，从客户处得来的进一步的信息包括“速度不超过300km/hr且行驶速度应为200km/hr”。这些条件和限制可以应用于下面的原始需求： 

能力：在洛杉矶和纽约之间运送乘客 

条件：行驶速度200km/hr 

限制：最高速度300km/hr 

良形需求：系统应该以经济运行速度200km/hr在洛杉矶和纽约之间运送乘客，最高速度为300km/hr。 

对于一条能力，可以有多个条件和限制，但是对一条能力添加太多的条件和/或限制，可能需要另外定义良形需求。 

1.3 组织需求 

在这个子过程中，分析员根据一些比较定义方法，通过把需求彼此关联来给需求集合加上结构，这个过程中的某些任务可以用自动化的方式来完成。 

本事务具有如下特征： 

a） 寻找将需求分组所要采用的样式 

b）利用经验和判断去分析适当的技术方法 

c） 利用创造性和直觉去产生可选的途径并基于客户的输入区分需求的优先次序 

d）定义需求的properties 

e） 定义需求的attributes 


需求的attributes可以被赋给每个良形需求。如： 

<标识>=2.1.3.6 

<优先级>=高 

<重要性>=低 

<可行性>=高 

<风险性>=中 

<来源>=客户 

<类型>=性能 



将定义组织成有序集合有多种方法，最常用的方法是将需求按能力分层，其中更一般性的需求被分解成从属的需求，另一种方法是用网路（如超文本）来显示所有最低级别需求之间的关系。无论采用何种方法，SySRS应该表明需求之间的关系，具体的关系依赖于捕获、记录和存储需求时所使用的方法、技术和工具。一些可以在SyRS中维护的需求之间的关系包括如下的层次相关性：（译者注：注意下面4项之间的层次关系，列在前面的层次要低，列在后面的层次要高） 



a） 事件 

b）信息/数据 

c） 物理或抽象的对象 

d）功能 



1.4 表现需求 



在本子过程中，分析员和客户一起工作，确定向需要理解、评审、接受或使用SyRS的所有个人沟通需求的最好的方法，采用单一的表现形式并不总是合适的，因为： 



a） 客户和技术团体通常具有不同的文化和语言，因此，同样的需求可能要以不同的方式提交给客户和技术团体 

b）在某些表现形式中难以检索特定的信息 

c） 在某些表现形式中难以实现对互动的表达 

d）在某些表现形式中难以将一个地方的需求与另一个地方的需求相关联 



因此，分析员和客户一起工作来确定沟通需求的最好方法很重要。为了完成此项任务，应该根据SyRS来准备不同的表现形式。不应该独立地维护这些表现形式，相反地，应该从SyRS来导出、产生它们。针对代表客户来接收系统的个人，可能要提供包括正式模型的更详细的文档，针对设计小组，可能要提供正式模型的完整的集合。自动化的工具的使用能有效地提高维护SyRS和生成不同表现形式的效率。 



1.4.1 表现方法 



表现方法可以是下面所列的一种或其组合，以便根据读者的需要表现出需求的不同的方面： 



a） 文本 

--印刷的 

--电子的 

b）模型 

--物理的 

--符号的 

--图形的 

--原型的 



在SyRS得到认可之后很久，一般仍然要继续进行需求写作的工作，在庞大复杂的系统中，首次得到认可的SyRS版本很可能包含有遗漏或曲解的错误，此外，许多系统将随着新特性的增加而改进，这使得为了改正初始需求的错误或增加增强系统的特性的需求而循环或重复这个过程成为必要。 



附录A 

（informative） 

SyRS大纲 

本指南认识到并认可许多种沟通需求的方法和媒介如文本和模型，下面内容的目的是为帮助读者关注SyRS的技术内容。关于开发SyRS的过程需求可参看IEEE标准1220-1994。针对客户和技术团体，可以扩展或缩短此表现形式和内容。可能的SyRS的表现形式可以有许多种，下面的只是一个例子： 

SyRS大纲 


目录

插图清单

表格清单

1. 介绍 

1.1 系统目的

1.2 系统范围

1.3 定义、首字母缩写词和缩写

1.4 引文

1.5 系统综述

2. 系统概述 

2.1 系统环境（译者注：context）

2.2 系统模式和状态

2.3 主要的系统能力

2.4 主要的系统条件

2.5 主要的系统限制

2.6 用户特征

2.7 假设和依据

2.8 运行场合

3. 系统能力、条件和限制 

注--在每个能力、条件和限制下应该论及系统行为、意外处理、可制造性和应用（译者注：deployment）。

3.1 物理的

3.1.1 构造

3.1.2 持久性

3.1.3 适应性

3.1.4 环境条件

3.2 系统性能特征

3.3 系统安全性（译者注：security）

3.4 信息管理

3.5 系统运行

3.5.1 系统人类因素

3.5.2 系统可维护性

3.5.3 系统可靠性

3.6 政策和法规

3.7 系统生命周期支持

4. 系统接口

大纲解释 

对于那些不能自说明的条目，提供如下信息：

1.2 系统范围 

本子条应该

a） 为将产生的系统命名。

b） 以一种简单但正式表达客户的问题的形式，引用并叙述以前确定的分析需要的结果，解释系统为满足那些需要，应该做什么和不应该做什么。

c） 描述所定义系统的应用。作为其中的一个部分，应该尽可能精确地描述所有相应的在最高层次上的收益、objectives和goals。

2.1 系统环境 

本子条中应该包括恰当的图表和叙述，对系统的上下文提供一个综述，定义穿过系统边界的所有重要接口。

2.2 系统模式和状态 

如果系统能存在于多种模式和状态，本子条应该描述这些内容，适当的地方可以使用图表。


2.3 主要的系统能力 

本子条应该提供图表及与之相伴的说明来显示将需求分成组的主要能力。

2.6 用户特征 

本子条应该指明系统的每种类型的用户（通过功能、位置、设备类型），每个组中的数量，和他们（它们）使用系统的本质。

2.8 运行场合 

本子条提供例子描述如何使用系统。

3 系统能力、条件和限制 

3.1 物理的 

3.1.1 构造 

应该包括系统所安装之处的环境特征（机械的、电子的、化学的）。例如，应该在此处定义系统的重量限制、惰性时刻、尺寸大小限制、群体空间、操作员位置布局、入口、出口和维护通路。应叙述本条目要用到的对原材料的需求或本规格涉及的服务，本子条应述及对标示牌及系统记号的需求、对设备可替换性的需求和对工作技能的需求。

3.1.3 适应性 

本子条中包括成长、扩充、能力和收缩。例如，如果系统将来需要更多的网络带宽，应该为硬件机框定义额外的槽位，以便当带宽的需要量增加时能插入新的网卡。

3.1.4 环境条件 

本子条款包括系统将遭遇的环境条件，应该考虑涉及如下主题：自然环境（风、雨、温度）；感应环境（运动、震动、噪音）；电磁信号环境。

3.2 系统性能特征 

本段用于强调重要的性能条件及其相关能力。作为一般性的指导，包括如下考虑：

a） 所发生的动态行为或变化（如速率、速度、运动和噪音强度）。

b） 设备在指规定的环境条件或其它条件下，满足用户需要的持久能力的量化标准，包括对总的生命长度的最小期望。指明需要的持续运行时间和计划使用率。

c） 运作阶段和模式的性能需求

3.3 系统安全性 

在本段中给出与系统所栖设施和系统运行安全性需求两者相关的系统安全性需求。安全性需求的一个可能的例子是指明关于安全性和私有性的需求，包括对系统的访问限制，如提供登录步骤和口令、数据保护和恢复方法，这将保护系统避免由于偶然或恶意的访问、使用、修改、清除或泄密而受到损害。特别是在安全性特别重要（译者注：safety-critical）的嵌入式系统中，这样将合成分布式的日志或历史数据集合、特定的功能在不同的单个系统之间的分配、或者对系统中各领域之间进行的限制。（译者注：合成--incorporate，这句话的意思是说利用安全性机制能从整体上把握这些问题。）

3.5.1 系统人类因素 

本子段应注明可适用的文档的出处，并指明任何特别的或独特的需求，如对分配给个人、通讯和人/机互动的功能的限制。由于操作的敏感性或任务的重要性（注：人的错误将会引起严重后果的区域），应包括那些需要对人类工程特别关注的特定领域、站点、或设备。

3.5.2 系统可维护性 

本子条指明量化的可维护性需求，此需求应用于谋划中的维护，支持环境要求，并以量化的条目来叙述。例子如下：
a） 时间（如平均及最长的停工期、反应时间、恢复时间、平均及最长维修时间、平均维护间隔）

b） 速率（如每个特定维护工作药费的维护部门的小时数、完好率、每运行小时中的维护小时数、预防性维护的频繁程度）

c） 维护复杂度（如人数和技能水平、辅助设备的种类）

d） 维护行为索引（如每运行小时维护费用、每次大修的小时数）

3.5.3 系统可靠性 

下面的子条应该以量化的条目指明系统的可靠性需求，并定义在何种条件下可靠性需求需要得到满足。为了便于在达到所期望的系统可靠性的过程中为各系统功能分配可靠性的数值，系统可靠性可以包括可靠性分配模型。

3.6 政策和法规 

本子条应详列将影响系统运行或操作的任何相关的组织政策，同时详列任何相关的外部的规则化的需求，也要详列正式的业务实践所强加的限制。其例包括多语言支持、劳工法、个人隐私保护和向秩序机构报告。

健康和安全（译者注：safety）标准（包括那些对系统设计来说基本的东西）、关于设备特性、操作方法、和环境影响，这些内容应该在本子条中指明。

3.7 系统生命周期支持 

为了帮助实现质量系统，本子条应粗略叙述质量事务如评审、度量集合和度量分析。

4 系统接口 

本子条包含关于不同的构件及其外部能力之间接口的需求规格，包括其所有的用户--该用户可以是人类也可以是其它的系统，也应包括所开发系统或未来系统的特征，同时也应指明与接口相关的相互依赖性和限制（如通讯协议、特殊设备、标准、固定的格式）。每个接口可以表现一个双向的信息流，为了清晰的缘故，适当的时候应该对接口采用图形化的表现方式。


注--本大纲不包括与所有域相关的所有能力分类。例如，它不涉及到通讯、存储、分布、传感器、仪器。另外，上述各条可以以读者感到合适的任何方式进行组织。

<script language="javascript" src="../../../share/bottom.js" type="text/javascript"></script>