标准翻译：系统软件工程

Systems and software engineering – Life cycle processes – Requirements engineering

系统软件工程 - 生命周期过程 - 需求工程

 

Foreword前言

ISO (the International Organization for Standardization) and IEC(the International Electrotechnical Commission) form the specialized system for worldwide standardization.National bodies that are members of ISO or IEC participate in the development of lnternational Standards through technical committees establishedby the respective organization to deal with particular fields of technical activity.ISO and IEC technicalcommittees collaborate in fields of mutual interest.Other international organizations,governmental and non-governmental,in lialson with ISO and IEC,also take part in the work.In the field of information technology,ISO and IEC have established a joint technical committee,ISO/IEC JTC1.

ISO(国际标准化组织)和IEC(国际电工委员会)构成了全球标准化的专门体系。作为ISO或IEC成员的国家机构通过各自组织设立的技术委员会参与制定国际标准，以处理特定的技术活动领域。ISO和IEC技术委员会在共同感兴趣的领域进行合作，其他国际组织，包括政府和非政府组织，与ISO和IEC联系，也参与这项工作。在信息技术领域，ISO和IEC成立了一个联合技术委员会--ISO/IEC JTC1。

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board.The IEEE develops its standardsthrough a consensus development process,approved by the American National Standards Institute,whichbrings together volunteers representing varied viewpoints and interests to achieve the final product.Volunteersare not necessarily members of the Institute and serve without compensation.While the IEEE administers theprocess and establishes rules to promote fairness in the consensus development process,the IEEE does notindependently evaluate,test,or verify the accuracy of any of the information contained in its standards.

IEEE标准文件是在IEEE协会和IEEE标准协会(IEEE-SA)标准委员会的标准协调委员会内制定的。IEEE通过美国国家标准协会(American National Standard Institute)批准的一个协商一致的开发过程来制定其标准，该过程由代表不同观点和利益的志愿者组成，以实现最终的产品。志愿人员不一定是协会的成员并无偿服务。虽然IEEE管理过程并制定规则以促进共识制定过程中的公平，但IEEE并不独立地评估、测试或验证其标准中所包含的任何信息的准确性。

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives,Part 2.

国际标准是根据ISO/IEC指令第2部分规定的规则起草的。

The main task of ISO/IEC JTC 1 is to prepare International Standards.Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.Publication as an InternationalStandard requires approval by at least 75 % of the national bodies casting a vote.

ISO/IEC JTC 1的主要任务是制定国际标准。联合技术委员会通过的国际标准草案将分发给国家机构表决。作为国际标准的出版物需要至少75%的国家机构投票批准。

Attention is called to the possibility that implementation of this standard may require the use of subject matter covered by patent rights.By publication of this standard,no position is taken with respect to the existence or validity of any patent rights in connection therewith.ISO/IEEE is not responsible for identifying essential patents or patent claims for which a license may be required,for conducting inquiries into the legal validity or scope of patents or patent claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance or a Patent Statement and Licensing Declaration Form,if any,or in any licensing agreements are reasonable or non-discriminatory.Users of this standard are expressly advised that determination of the validity of any patent rights,and the risk of infringement of such rights,is entirely their own responsibility.Further information may be obtained from ISO or the IEEE Standards Association.

请注意，使用本标准需要的主题材料有可能受专利权影响。本标准的公布，并不意味着相关的任何专利权的存在或有效性或相反。ISO IEEE不负责识别可能需要许可证的必要专利或专利索赔，不负责对专利或专利索赔的法律效力或范围进行调查，或确定与提交保证书或专利声明和许可声明表格有关的任何许可条款或条件，如果有的话，或在任何许可协议中是否合理或非歧视性。本标准的使用者被告知，确定任何专利权的有效性和侵犯这些权利的风险完全是他们自己的责任。进一步的信息可从ISO或IEEE标准协会获得。

ISO/IEC/IEEE 29148 was prepared by Joint Technical Committee ISO/IEC JTC 1，Information technology,Subcommittee SC 7,Software and systems engineering，in cooperation with the Software&Systems Engineering Standards Committee of the IEEE Computer Society,under the Partner Standards Development Organization cooperation agreement between ISO and IEEE.

ISO/IEC/IEEE 29148由信息技术联合技术委员会ISO/IEC JTC 1，软件和系统工程分委员会SC 7，与IEEE计算机学会软件和系统工程标准委员会合作编写，根据ISO和IEEE之间的合作伙伴标准开发组织合作协议。

Introduction引言

This International Standard provides a unified treatment of the processes and products involved in engineering requirements throughout the life cycle of systems and software.This International Standard is the result of harmonization of the following sources:

本标准在系统和软件的整个生命周期内统一处理涉及工程需求的过程和产品。本标准是综合以下来源的结果：

ISO/IEC 12207:2008 (IEEE Std 12207-2008),Systems and software engineering- Software life cycle processes

Iso/iec 12207：2008(ieee std 12207-2008)，系统和软件工程-软件生命周期过程

ISO/IEC 15288:2008 (IEEE Std 15288-2008)，Systems and software engineering -System life cycle processes

Iso/iec 15288：2008(ieee std 15288-2008)，系统和软件工程.系统生命周期过程

ISO/IEC/IEEE 15289:2011，Systems and software engineering -Content of life-cycle information products (documentation)

Iso/iec/ieee 15289：2011，系统和软件工程.生命周期信息产品的内容(文档)

ISO/IEC TR19759，Software Engineering- Guide to the Software Engineering Body of Knowledge(SWEBOK)

ISO/IEC TR19759，软件工程.软件工程知识体系指南(SWEBOK)

IEEE Std 830,IEEE Recommended Practice for Software Requirements Specifications

IEEE STD 830，IEEE软件需求规范推荐规程

IEEE Std 1233,IEEE Guide for Developing System Requirements Specifications

IEEE STD 1233，IEEE系统需求规范开发指南

IEEE Std 1362，IEEE Guide for Information Technology    System Definition-Concept of Operations(ConOps) Document

IEEE STD 1362，IEEE信息技术指南.系统定义-操作概念(ConOPS)文件

ISO/IEC TR24748-1，Systems and software engineering-Life cycle management-Part 1:Guide for life cycle management

系统和软件工程.生命周期管理.第1部分：生命周期管理指南

ISO/IEC/IEEE 24765,Systems and software engineering-Vocabulary

系统和软件工程-词汇

1 Scope范围

This International Standard

本标准

-    specifies the required processes that are to be implemented for the engineering of requirements for systems and software products (including services) throughout the life cycle,
指定在生命周期内为实施系统和软件产品（包括服务）的需求工程所需的过程

-    gives guidelines for applying the requirements and requirerments-related processes described in ISO/IEC 12207:2008(IEEE Std 12207-2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008),

给出了应用ISO/IEC 12207:2008（IEEE标准12207-2008）和ISO/IEC 15288:2008（IEEE标准15288-2008）中描述的要求和要求相关过程的指南

-    specifies the required information items that are to be produced through the implementation of the requirements processes,

指定通过实施需求过程产生的必要信息项

-    specifies the required contents of the required information items,and

指定了各信息项的必要内容。

-    gives guidelines for the format of the required and related information items.

提供信息项的格式指南

This lnternational Standard is applicable to

本标准适用于：

-    those who use or plan to use ISO/IEC 15288 and ISO/IEC 12207 on projects dealing with man-made systems,software-intensive systems，software and hardware products,and services related to those systems and products,regardless of project scope,product(s),methodology,size or complexity,

-在涉及人造系统、软件密集型系统、软件和硬件产品以及与这些系统和产品相关的服务的项目中使用ISO/IEC 15288和ISO/IEC 12207的人员，而无论项目范围、产品、方法、规模或复杂性如何，

-

-    anyone performing requirements engineering activities to aid in ensuring that their application of therequirements engineering processes conforms to ISO/IEC 15288:2008 (IEEE Std 15288-2008) and/or ISO/IEC 12207:2008 (IEEE Std 12207-2008),

-执行需求工程活动以帮助确保其采用的需求工程过程符合ISO/IEC 15288:2008（IEEE标准15288-2008）和/或ISO/IEC 12207:2008（IEEE标准12207-2008）的任何人,

-

-    those who use or plan to use ISO/IEC/IEEE 15289:2011 on projects dealing with man-made systems,software-intensive systems,software and hardware products,and services related to those systems and products,regardless of project scope,product(s),methodology,size or complexity,and

-在处理人工系统、软件密集型系统、软件和硬件产品以及与这些系统和产品相关的服务的项目上使用ISO/IEC/IEEE 15289：2011的人，而不论项目范围、产品、方法、规模或复杂性，以及

-

-    anyone performing requirements engineering activities to aid in ensuring that the information items developed during the application of”requirements engineering processes conform to ISO/IEC/IEEE 15289:2011.

-执行需求工程活动以帮助确保在采用“需求工程过程”期间开发的信息项符合ISO/IEC/IEEE 15289:2011的任何人。

-

2 Conformance一致性

2.1 Intended Usage用途

This International Standard provides guidance for the execution of the ISO/IEC 15288 and ISO/IEC 12207 processes that deal with requirements engineering.This International Standard ISO also provides normative definition of the content and recommendations for the format of the information items,or documentation,that result from the implementation of these processes.Users of this International Standard can claim conformance to the process provisions or to the information item provisions,or both.

本标准为涉及需求工程的ISO/IEC 15288和ISO/IEC 12207过程的执行提供了指南。本标准ISO还对实施这些过程产生的信息项或文件的格式提供了建议，对产生的内容提供了规范性定义。本标准的用户可声称符合工艺规定或信息项规定，或两者兼而有之

2.2 Conformance to processes与过程的一致性

This Intermational Standard provides requirements for a number of requirements engineering processes suitable for usage during the life cycle of a system,a product,or a service.

本标准提供了许多需求工程流程的需求，适合于在系统、产品或服务的生命周期中使用。

The requirements for processes in this International Standard are contained in 5.2.4,5.2.5,5.2.6,5.2.7,and 6.1.

本标准对流程的要求载于5.2.4、5.2.5、5.2.6、5.2.7和6.1。

NOTE 1 lf a user of this International Standard claims full conformance to ISO/EC 15288:2008(IEEE Std 15288-2008) and/or ISO/IEC 12207:2008 (IEEE Std 12207-2008),then by implication the user may claim conformance to the processes in this lnternafional Standard.

注意：如果本标准的用户声称完全符合ISO/EC 15288：2008(IEEESTD 15288-2008)和ISO IEC 12207：2008(IEEE STD 12207-2008)，则用户可以声称符合本标准中的流程。

NOTE 2 A claim to tailored conformance to ISO/IEC 15288:2008 (IEEE Std 15288-2008) and/or ISO/IEC 12207:2008(IEEE Std 12207-2008),does not necessarily imply conformance to the processes in this International Standard.

注2声称符合ISO/iec 15288：2008(IEEESTD 15288-2008)和ISO/IEC 12207：2008(IEEESTD 12207-2008)，并不一定完全符合本标准中的流程。

2.3 Conformance to information item content符合信息项目内容

This International Standard provides requirements for a number of requirements engineering information items to be produced during the life cycle of a system,a product or a service.A claim of conformance to the information item provisions of this International Standard means that

本标准对系统、产品或服务的生命周期内产生的许多需求工程信息项提出了要求。符合本标准信息项规定的声明的意思是：

-    the user produces the required information items stated in this International Standard,and

-用户生成本标准中规定的所需信息项，以及

-

-    the user demonstrates that the information items produced during the requirements engineering activities conform to the content requirements defined in this International Standard.

-用户证明需求工程活动期间产生的信息项符合本标准中定义的内容要求。。

-

The requirements for information items in this International Standard are contained in Clause 7.The requirements for the content of information items in this International Standard are contained in Clause 9 and Annex A.

本标准对信息项目的要求载于第7条。本标准中关于信息项目内容的规定载于第9条和附录A。

NOTE 1 lf a user of this International Standard claims full conformance to ISO/IEC/IEEE 15289 it does not imply that the user may claim conformance to the information items and information item content in this International Standard.The reason is that this International Standard adds additional information items.

注1：如果本标准的用户声称完全符合ISO/IEC/IEEE 15289，并不意味着用户可以声称符合本标准中的信息项和信息项内容。这是因为本标准定义了额外的信息项。

NOTE 2 In this International Standard,for simplicity of reference,each information item is described as if it were published as a separate document. However, information items will be considered as conforming if they are unpublished but available in a repository for reference,divided into separate documents or volumes,or combined with other information items into one document.

注2：在本标准中，为便于参考，对每个信息项目的描述就好像它是作为一个单独的文件发布的一样。但是，如果信息项目未发表，但可在存储库中查阅，分为单独的文件或卷，或与其他信息项目合并成一个文件，则将被视为符合标准。

2.4 Full conformance完全符合

Aclaim of full conformance to this International Standard is equivalent to claiming conformance

完全符合本标准等同于声称符合

-    to the provisions contained in subclauses 5.2.4,5.2.5,5.2.6,and 5.2.7,

-符合第5.2.4、5.2.5、5.2.6和5.2.7款所载的规定，

-

-    to the requirements-engineering-related processes of ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008(IEEE Std 12207-2008) cited in subclause 6.1,

-符合ISO/IEC 15288：2008(IEEE STD 15288-2008)和ISO/IEC 12207：2008(IEEE STD 12207-2008)有关的要求

-

-    to the information items cited in Clause 7,and

-符合第7条所引述的资料项目，及

-    to the content requirements of the information items in Clause 9 and Annex A.

-符合第9条和附件A.2.5所列信息项目的内容要求

2.5 Tailored conformance定制一致性

2.5.1 Processes过程

This International Standard does not make provision for tailoring processes. ISO/IEC 15288:2008(IEEE Std 15288-2008)，Annex A provides normative direction regarding the tailoring of system life cycleprocesses,ISO/EC 12207:2008(IEEE Std 12207-2008),Annex A provides normative direction regarding the tailoring of software life cycle processes.

本标准没有对裁剪过程作出规定。ISO IEC 15288：2008(IEEESTD 15288-2008年)，附件A提供关于系统生命周期过程裁剪的标准指示，ISO/EC 12207：2008(IEEE STD 12207-2008年)，附件A提供关于软件生命周期过程裁剪的规范指导。

2.5.2 Information items信息项

When this International Standard is used as a basis for establishing a set of information items that do not qualify for full conformance,the clauses of this International Standard are selected or modified in accordance with the tailoring process prescribed in Annex D.The tailored text,for which tailored conformance is claimed,is declared.Tailored conformance is achieved by demonstrating that requirerments for the information items,as tailored,have been satisfied using the outcomes of the tailoring process as evidence.

当本标准用作建立一组不符合完全一致性要求的信息项的基础时，根据附录D中规定的裁剪过程选择或修改本标准的条款。声明裁剪一致性要求的裁剪文本。定制一致性是通过使用定制过程的结果作为证据，证明已满足定制信息项的要求来实现的。

3 Normative references规范参考文献

The following referenced documents are indispensable for the application of this document.For dated references,only the edition cited applies.For undated references,the latest edition of the referenced document,(including any amendments) applies.

下列参考文件对于本文件的应用是必不可少的。对于日期引用，仅引用的版本适用。凡是不注日期的引用文件，其最新版本（包括任何修改件）适用。

ISO/IEC 12207:2008 (IEEE Std 12207-2008)，Systems and software engineering-Sofware life cycle processes

Iso/iec 12207：2008(ieee std 12207-2008)，系统和软件工程.软件生命周期过程

ISO/IEC 15288:2008 (IEEE Std 15288-2008)，Systems and software engineering-System lmfe cycle processes

ISO/IEC 15288:2008 (IEEE Std 15288-2008)，Systems and software engineering-System lmfe cycle processes

ISO/IEC/IEEE 15289:2011，Systems and software engineering - Content of life-cycle information products(documentation)

Iso iec/ieee 15289：2011，系统和软件工程.生命周期信息产品的内容(文档)

4 Terms,definitions and abbreviated terms术语、定义和缩略语

4.1 Terms and definitions

For the purposes of this document,the terms and definitions given in ISO/IEC 15288,ISO/IEC 12207 and the following apply.

出于本文件行文之目的，本文使用ISO/IEC 15288、ISO/IEC 12207中定义、及以下给出的术语和定义。

4.1.1 acquirer需方

stakeholder that acquires or procures a product or service from a supplier

从供应商那里获得或获取产品或服务的干系人

[ISO/IEC 15288;2008(IEEE Std 15288-2008) and ISO/IEC 12207:2008(IEEE Std 12207-2008)J

NOTE Other terms commonly used for an acquirer are buyer,customer,owner,and purchaser.

注：需方有时也称为买方、客户、所有者和购买者。

4.1.2 attribute属性

inherent property or characteristic of an entity that can be distinguished quantitatively or qulitatively by human or automated means

实体的固有属性或特征，可通过人工或自动化手段进行定量或定量区分.

[ISO/IEC 25000:2005]

NOTE ISO 9000 distinguishes two types of attributes: a permanent characteristic existing inherently in something;and an assigned characteristic of a product,process,or system (e.g.the price of a product,the owner of a product).

注：ISO 9000区分了两种类型的属性：一种是固有于某物的永久特性；另一种是产品、过程或系统的指定特性(例如，产品的价格、产品的所有者)。

4.1.3 baseline基线

specification or product that has been formally reviewed and agreed upon,that thereafter serves as the basis for further development,and that can be changed only through formal change control procedures

规范或产品已经过正式审查和同意，随后作为进一步开发的基础，并且只能通过正式的变更控制程序进行变更

[ISO/IEC15288;2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008(IEEE Std 12207-2008)]

4.1.4 concept of operations运行方案

verbal and graphic statement,in broad outline,of an organization's assumptions or intent in regard to an operation or series of operations

概括地说，组织对一项或一系列业务的假设或意图的口头和图形性陈述

[ANSI/AIAA G-043-1992]

NOTE1 The concept of operations frequently is embodied in long-range strategic plans and annual operational plans.ln the latter case,the concept of operations in the plan covers a series of connected operations to be carried out simultaneously or in succession.The concept is designed to give an overall picture of the organization operations.See also operational concept.

注1运行方案经常体现在长期战略计划和年度作战计划中。在后一种情况下，计划中的运行方案包括一系列同时或接连进行的相互关联的行动。这一概念旨在全面描述组织的运作情况。参见操作概念。

NOTE 2 It provides the basis for bounding the operating space，system capabilities， interfaces and operating environment.

注2它为界定操作空间、系统功能、接口和操作环境提供了基础。

4.1.5 condition条件

measurable qualitative or quantitative attribute that is stipulated for a requirement

为需求规定的可测量的定性或定量属性

4.1.6 constraint 约束

externally imposed limitation on system requirements,design,or implementation or on the process used to develop or modify a system

外部对系统需求、设计或实现或对系统开发、修改过程施加的限制

NOTE A constraint is a factor that is imposed on the solution by force or compulsion and may limit or modify the design changes.

注：约束是通过强制或强制施加在解决方案上的因素，可能会限制或修改设计变更。

4.1.7 customer客户

organization or person that receives a product or service

接受产品或服务的组织或人个人

[ISO/EC15288;2008 (IEEE Std 15288-2008) and IISO/IEC 12207:2008 (IEEE Sld 12207-2008)]

NOTE Customers are a subset of stakeholders.

注：客户是干系人的子集。

4.1.8 derived requirement衍生需求

requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution

从收集和组织需求到特定的系统配置和解决方案中推导或推断的需求

4.1.9 developer开发人员

organization that performs development tasks (including requirements analysis，design，testing through acceptance) during a life cycle process

在生命周期过程中执行开发任务(包括需求分析、设计、验收测试)的组织。

[ISO/IEC 12207;2008(IEEE Std 12207-2008)]

NOTE Developers are a subset of stakeholders.

注 开发人员是涉众的子集。

4.1.10 document文件

uniquely identified unit of information for human use,such as a report,specification,manual or book in printedor electronic form

有唯一标识的供人使用的信息载体，如打印或电子形式的报告、规范、手册或书籍

4.1.11 human systems integration人机集成

interdisciplinary technical and management process for integrating human considerations with and across all system elements,an essential enabler to systems engineering practice

跨学科的技术和管理过程，将人考虑的因素与所有系统要素结合起来，这是促进系统工程实践的一个重要因素。

NOTE Adapted from lNCOSE SEHbk 3.2:2010.

NOTE更改自lNCOSE SEHbk 3.2:2010。

4.1.12 level of abstraction抽象层次

view of an object at a specific level of detail

对象在特定细节级别上的视图

4.1.13 mode模式

set of related features or functional capabilities of a product

产品的相关功能或能力

[IEEE STD 1362-1998]

4.1.14 operational concept经营理念

verbal and graphic statement of an organization's assumptions or intent in regard to an operation or series of operations of a system or a related set of systems

组织对系统或相关系统的操作或系列操作的假定或意图的文字和图形说明

[ANSI/AIAA G-043-1992]

NOTE The operational concept is designed to give an overall picture of the operations using one or more specific systems,or set of related systems,in the organization's operational environment from the users’ and operators'perspective.See also concept of operations.

注：操作概念旨在从用户和操作员的角度给出在组织的操作环境中使用一个或多个特定系统或一组相关系统的操作的总体情况。参见操作概念（operations concept）。

4.1.15 operational scenario业务场景

description of an imagined sequence of events that includes the interaction of the product or service with its environment and users,as well as interaction among its product or service components

描述想象中的事件序列，包括产品或服务与其环境和用户之间的交互，以及其产品或服务组件之间的交互。

NOTE Operational scenarios are used to evaluate the requirements and design of the system and to verify and validate the system.

注：业务场景用于评估系统的需求和设计，并确认和验证系统。

4.1.16 operator操作者

entity that performs the operations of a system

操作系统的实体。

[ISO/IEC 15288:2008(IEEE Std 15288-2008) and ISO/IEC 12207:2008(IEEE Std 12207-2008)]

NOTE The role of operator and the rule of user may be vested,simultaneously or sequentially,in the same individual or organization.

注：操作人员的角色和用户规则可以同时或顺序地归属于同一个个人或组织。

4.1.17 requirement要求/需求

statement which translates or expresses a need and its associated constraints and conditions

表达需求的描述，及其相关的约束和条件。

NOTE Requirements exist at different tiers and express the need in high-level form (e.g.software component requirement).

注：需求存在于不同的层次中，并以高层次的形式表达需求(例如，软件组件需求)。

4.1.18 requirements elicitation需求启发

process through which the acquirer and the suppliers of a system discover,review,articulate,understand,and document the requirements on the system and the life cycle processes

系统的需方和供应商发现、审查、阐明、理解和记录对系统和生命周期过程的需求的过程。

NOTE Adapted from ISO/IEC/IEEE 24765:2010.

注：改编自ISO/IEC/IEEE 24765：2010。

4.1.19 requirements engineering需求工程

interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system,software or service of interest

跨学科功能，它在需方和供货商的领域之间进行调解，以建立和维护系统、软件或相关服务所要满足的要求。

NOTE Requirements engineering is concerned with discovering,eliciting，developing,analyzing，determining verification methods, validating, communicating, documenting,and managing requirements.

注 需求工程是指发现、启发、开发、分析、确定验证方法、验证、沟通、记录和管理需求。

4.1.20 requirements management需求管理

activities that ensure requirements are identified，documented，maintained,communicated and traced throughout the life cycle of a system, product, or service

确保在系统、产品或服务的整个生命周期中需求能得到确定、记录、维护、沟通和跟踪的活动

4.1.21 requirements traceability matrix 需求追溯矩阵

table that links requirements to their origin and traces them throughout the project life cycle

表，该表将需求与其来源联系起来，并在整个项目生命周期中跟踪它们。

4.1.22 requirements validation需求确认

confirmation by examination that requirements (individually and as a set) define the right system as intended by the stakeholders

审查确认需求(单独的或者需求集合)，确保定义的系统满足干系人的要求。

NOTE Adapted from EIA 632:1999.

注：改编自EIA 632：1999。

4.1.23 requirements verification需求验证

confirmation by examination that requirements (individually and as a set) are well formed

通过检查确认需求（单独或作为一个集合）格式良好。

NOTE1 Adapted from EIA 632:1999.

注1：改变自EIA 632:1999。

NOTE2 This means that a requirement or a set of requirements has been reviewed to ensure the characteristics of good requirements are achieved.

注2：这意味着已经对需求或一组需求进行了审查，以确保实现了良好需求的特征。

4.1.24 software requirements specification软件需求规范

structured collection of the requirements (functions,performance,design constraints,and attributes) of the software and its external interfaces

软件及其外部接口的需求(功能、性能、设计约束和属性)的结构化集合

NOTE Adapted from IEEE Std 1012:2004.

NOTE 来自IEEE STD 1012：2004。

4.1.25 stakeholder干系人

individual or organization having a right，share，claim，or interest in a system or in its possession of characteristics that meet their needs and expectations

在某一系统中有权利、份额、权利要求或利益的个人或组织，或拥有符合其需要和期望的特性的个人或组织

NOTE Stakeholders include,but are not limited to,end users,end user organizations, supporters,developers,producers， trainers,maintainers,disposers acquirers,customers，operators, supplier organizations，accreditors，and regulatory bodies.

注：干系人包括但不限于最终用户、最终用户组织、支持者、开发人员、生产者、培训人员、维护人员、处置者、需方、客户、经营者、供应商组织、债权人和监管机构。

[ISO/IEC 15288:2008(IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)]4.1.26

4.1.26 state状态

condition that characterizes the behaviour of a function/subfunction or element at a point in time[ISO/IEC 26702]

描述函数/子函数或系统元素在某一时刻的行为的条件[iso/iec 26702]

4.1.27 supplier 供应商

organization or individual that enters into an agreement with the acquirer for the supply of a product or service[ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207-2008)

与采购方签订提供产品或服务协议的组织或个人[iso/iec 15288：2008(ieee std 15288-2008)和ISO/iec 12207：2008(ieee std 12207-2008)

NOTE Suppliers are a subset of stakeholders.

注：供应商是干系人的子集。

4.1.28 system-of-interest相关系统

system whose life cycle is under consideration in the context of this International Standard

在本标准范围内正在考虑其生命周期的系统

[ISO/IEC 15288-2008(IEEE Std 15288-2008)]

4.1.29 system requirements specification系统要求规范

structured collection of the requirements (functions,performance,design constraints,and attibutes) of thesystem and its operational environments and external interfaces

系统及其操作环境和外部接口的需求(功能、性能、设计约束和装配)的结构化集合

NOTE Adapted from IEEE Std 1233:1998 and IEEE Std 1012;2004.

注：修订自IEEE Std 1233：1998和IEEE Sthu  1012；2004。

4.1.30 trade-off 折中

decision-making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders

基于净利润考虑，从各种需求和备选解决方案中选择给干系人的决策行动

4.1.31 user用户

individual or group that benefits from a system during its utilization

在系统使用过程中受益的个人或组

[ISO/IEC 15288:2008 (IEEE Std 15288-2008)]

NOTE1 The role of user and operator may be vested,simultaneously or sequentially，in the same individual ororganization.

注1：用户和操作员的角色可以同时或顺序地归属于同一个人或组织。

NOTE2 Users are a subset of stakeholders.

NOTE 2：用户是涉众的子集。

4.1.32 validation确认

confirmation,through the provision of objective evidence,that the requirements for a specific intended use orapplication have been fulfilled

通过提供客观证据，确认某一特定用途或用途的要求已得到满足

[ISO 9000:2005]

NOTE Validation in a system life cycle context is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use,goals,and objectives.The right system has been built.

注：系统生命周期上下文中的验证是一组活动，确保并获得对系统能够实现其预期用途、目标和目标的信心。正确的系统已经建立。

4.1.33 verification验证

confirmation,through the provision of objective evidence,that specified requirements have been fulfilled

通过提供客观证据，确认以满足特定要求

[ISO 9000:2005]

NOTE Verification in a system life cycle context is a set of activities that compares a product of the system life cycle against the required characteristics for that product.This may include,but is not limited to,specified requirements,design description and the system itself.The system has been built right.

注：系统生命周期上下文中的验证是一组活动，它将系统生命周期的产品与该产品所需的特征进行比较。这可能包括但不限于指定的要求、设计说明和系统本身。系统已被正确构建。

4.2 Abbreviated terms缩略语

BRS

Business Requirements Specification

业务需求规范

ConOps

Concept of Operations

操作概念

FSM

Functional Size Measurement

功能大小度量

HSI

Human Systems lntegration

MOP Measures Of Performance

OpsCon

Operational Concept

RTM

Requirements Traceability Matrix

需求可追溯矩阵

SRS

Software Requirements SpecificationstRSStakeholder Requirements Specification

SyRS

System Requirements SpecificationTBDTo Be Determined

软件需求规范

TBR

To Be Resolved,To Be Revised

待解决，待修订

TBS

To Be Supplied,To Be Specified.

须予提供，并须予指明。

TPM

Technical Performance Measure

技术绩效计量

5 Concepts概念

5.1 Introduction导言

This clause presents concepts that apply to requirements themselves,and to the information items generated during the process of documenting requirements.The concepts apply to the properties of requirements at all levels of the system-of-interest.The concepts alse apply to the processes used in the elicitation, analysis,allocation,documentation,and management of requirements.

本条款提出了适用于需求本身以及在记录需求过程中产生的信息项的一些概念，这些概念适用于系统各层级的需求的属性。这些概念也适用于在需求启发、分析、分配、记录和管理中等需求过程。

5.2 Requirements fundamentals需求基础

5.2.1 General

Requirements engineering is an interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system,software or service of interest.Requirements engineering is concerned with discovering, eliciting, developing, analyzing, determining verification methods,validating,communicating,documenting,and managing requirements.The result of requirements engineering is a hierarchy of requirements that:

需求工程是一种跨学科的功能，它在需方和供方两个领域之间进行，以建立和维护需求，这些需求通过所创建的系统、软件或服务来满足。需求工程涉及到对需求的发现、启发、开发、分析、确定验证方法、验证、交流、记录和管理等诸多过程。需求工程的结果是需求的层次结构，需求应该：

-    enables an agreed understanding between stakeholders (e.g，acquirers, users,customers,operators,suppliers)

-使干系人(例如，需方、用户、客户、经营者、供应商)能够达成一致的理解

-

-    is validated against real-world needs,can be implemented provides a basis of verifying designs and accepting solutions.

-根据实际需要进行验证，可行性是验证设计和方案被接受的基础.

-

-    The hierarchy of requirements may be represented in one or more requirements specifications (see Clauses 8 and 9 for specification templates and content).

-需求的层次结构可以在一个或多个需求规范中表示(关于规范模板和内容，请参见第8和第9条)。

5.2.2 Stakeholders 干系人

Stakeholders vary across projects when considered in the context of requirements engineering.A minimumset of stakeholders consists of users and acquirers (who may not be the same).Complex projects can impact many users and many acquirers,each with different concerns.Project requirements can necessitate including two other groups as part of the minimum set of stakeholders.First,the organization developing,maintaining.or operating the system or software has a legitimate interest in benefiting from the system.Second,regulatory authorities can have statutory,industry,or other external requirements demanding careful analysis.

在整个需求工程中，项目中的干系人各不相同。干系人的最小集合包括用户和需方（二者有可能不是同一方）。复杂的项目可能会影响更多的用户和需方，各方的关注点各不相同。项目需求可能需要将另外两个组作为最小干系人集合的一部分。首先，组织的发展、维护。或操作系统或软件具有从系统中受益的合法利益。其次，监管机构可能有法律、行业或其他外部要求，也需要考虑。（待定）

5.2.3 Transformation of needs into requirements将要求转化为需求

Defining requirements begins with stakeholder intentions (referred to as needs,goals,or objectives),that evolve into a more formal statement before arriving as valid stakeholder requirements.Initial stakeholder intentions do not serve as stakeholder requirements,since they often lack definition,analysis and possibly consistency and feasibility.Using the Concept of Operations to aid the understanding of the stakeholder intentions at the organizational level and the System Operational Concept from the system perspective,requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements.These statements are well-formed and meet the characterstics of subclauses 5.2.4,5.2.5,and 5.2.6.

定义需求始于干系人的意图（称为需求、目标或目的），在形成正式的需求之前，这些意图首先会表现为更正式的陈述。干系人的初始意图并不是真正的需求，因为它们通常缺乏严谨的定义、分析，也缺乏一致性和可行性。使用经营理念帮助理解组织层面的干系人意图，并从系统角度理解系统运营概念，需求工程引导干系人将最初的、原始的意图逐步转换为结构化和更正式的需求。正式需求要求格式良好，符合第5.2.4款、第5.2.5款和第5.2.6款的要求。

The stakeholder requirements are then transformed into system requirements for the system-of-interest,in accordance with subclauses 5.2.4,5.2.5,and 5.2.6. Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy.The recursive application of the processes in Clause 6 will generate lower-level system element requirements.

然后，根据第5.2.4、5.2.5和5.2.6款，将干系人需求转化为正式的系统需求。实践表明，该过程会在整个系统设计层次结构上，与其他生命周期过程，一起进行迭代和递归。循环应用第6条中的过程，来生成较低级别的系统需求。

Clause 6 details the processes to perform stakeholder requirements definition and requirements analysis.Clauses 7,8,and 9 contain further guidance on information items associated with documenting the requirements.Annex A provides requirements for the content of a System Operational Concept and Annex B provides guidelines for the content of a Concept of Operations.

第6条对干系人需求定义和需求分析的过程进行了详细说明。第7、8和9条包含如何编写需求相关的内容的进一步指南。附件A规定了系统运行概念的内容要求，附件B则规定了运行方案的内容指南。

NOTE See ISO/IEC 26551:-,Software and systems engineering-Tools and methods of requirements engineeringand management for product lines for addtional guidance on requirements development techniques，includingrequirements reuse.

注：请参阅ISO/IEC 26551：-，软件和系统工程-产品线的需求工程和管理工具和方法，用于需求开发技术的附加指南，包括需求重用。

5.2.4 Requirements construct需求创建

Well-formed stakeholder requirements,system requirements,and system element requirements shall be developed.This will contribute to requirements validation with the stakeholders，and ensure that the requirements accurately capture stakeholder needs.

应创建格式良好的干系人需求、系统需求和系统元素需求。这将有助于与干系人进行需求确认，并确保准确地获取了干系人的真正需求。

A well-formed requirement is a statement that

格式良好的需求描述要具备以下特点：

-    can be verified,

-可被验证，

-    has to be met or possessed by a system to solve a stakeholder problem or to achieve a stakeholder objective,

-系统必须满足或具备（某些需求和功能），以解决干系人问题、实现其目标，

-    is qualifed by measurable conditions and bounded by constraints,and

-能以可测量的条件和约束进行量化，以确定系统范围，

-    defines the performance of the system when used by a specifc stakeholder or the corresponding capability of the system,but not a capability of the user,operator,or other stakeholder.

定义系统应具备的性能或能力，但不是指用户、操作员或其他干系人的能力。

This description provides a means for distinguishing between requirements and the attributes of those requirements (conditions,assumptions,design decisions and constraints).

本说明提供了区分需求和需求属性（条件、假设、设计决策和约束）的方法。

The following provides guidance on writing well-formed requirements.A requirement is a statement which translates or expresses a need and its associated constraints and conditions.This statement is written in a language which can take the form of a natural language.If expressed in the form of a natural language,the statement should comprise a subject,a verb and a complement.A requirement shall state the subject of the requirement (e.g.,the system,the software,etc.) and what shall be done (e.g.,operate at a power level,provide a field for).Figure 1 shows example syntax for requirements.Condition-action tables and use cases are other means of capturing requirements.

以下是编写格式良好的需求的指导。需求是要求及其相关约束和条件的表达，采用自然语言写成，包括主语、动词和补语。需求应说明主体（例如，系统、软件等）以及应做的事情（例如，在功率水平下运行，为其提供一个字段）。图1显示了需求的示例语法。条件操作表和用例是获取需求的另一个方法。

It is important to agree in advance on the specific keywords and terms that signal the presence of a requirement.A common approach is to stipulate the fllowing:

对如何表达需求的必要性进行约定非常重要。一般按以下要求：

-     Requirements are mandatory binding provisions and use 'shall’.

需求是强制性的有约束力的规定，使用“应该”

-     Statements of fact,futuriy,or a declaration of purpose are non-mandatory,non-binding provisions and use ‘Will’.’Will' can also be used to establish context or limitations of use.However,"will can be construed as legally binding,so it is best to avoid using it for requirements.

-事实陈述、未来陈述或目的声明均为非强制性、非约束性条款和使用意愿,使用“最好，希望Will”。“最好”也可用于确定使用的上下文或限制。然而，“最好”可被解释为具有法律约束力，因此最好避免将其用于需求。

-     Preferences or goals are desired,non-mandatory,non-binding provisions and use 'should'.

偏好或目标是理想的，非强制性的，不具约束力的条款和使用‘应该’。

-     Suggestions or allowances are non-mandatory,non-binding provisions and use 'may'.

-建议或条款是非强制性的，不具约束力的规定，使用“可以”。

-     Non-requirements,such as descriptive text,use verbs such as ‘are',‘is',and 'was'.It is best to avoid using the term ‘must',due to potential misinterpretation as a requirement.

使用“必须”一词，因为潜在的误解是一种要求。

-     Use positive statements and avoid negative requirements such as 'shall not'.

-使用积极的陈述，避免消极的要求，如“不应该”。

-     Use active voice: avoid using passive voice,such as 'shall be able to Select'.

-使用主动语态：避免使用被动语态，如“应能选择”。

All terms specific to requirements engineeing should be formally defined and applied consistently throughout all requirements of the system.

需求工程的所有术语都应经过定义，并在使用过程中保持统一。

[Condition] [Subject] [Action] [Object] [Constraint]

[条件][主体][行动][客体][约束]

EXAMPLE: When signal x is received [Condition],the system [Subject] shall set [Action] the signal x received bit [Object] within 2 seconds [Constraint]

例如：当接收到信号x[条件]时，系统[主体]应设置[动作]信号x接收位[对象]在2秒内[约束]

or或者

[Condition] [Action or Constraint] [Value]

[条件][行动或约束][价值]

EXAMPLE: At sea state 1 [Condition].the Radar System shall detect targets at ranges out to [Action or Constraint] 100 nautical miles [Value].

例：在海上状态1[条件]。雷达系统应在100海里范围内[值]探测目标[行动]。

Or或

[Subject] [Action] [Value]

[主体][行动][价值]

EXAMPLE: The Invoice System [Subject],shall display pending customer invoices [Action] in ascending order [Value] in which invoices are to be paid.

例如：发票系统[主体]，将显示客户代付款发票[动作] 以升序方式 [价值]。

Figure 1- Examples of Requirement Syntax

图1-需求语法示例

Conditions are measurable qualitative or quantitative attributes that are stipulated for a requirement.They further qualify a requirement that is needed,and provide attributes that permit a requirement to be formulated and stated in a manner that can be validated and verfied.Conditions may limit the options open to a designer.It is important to transform the stakeholder needs into stakeholder requirements without imposing unnecessary bounds on the solution space.

条件是定义需求时要明确的属性，条件必须是可测量的、定量的或者定性的。它们进一步限定了所需的需求，并定义了一些需求属性，用这些属性对需求使用一种可验证的方式进行表达。条件可能会限制设计人员的可选项。条件对将干系人要求（needs）转化为干系人需求（requrements）非常重要，可以避免在方案中引入不必要内容。

Constraints restrict the design solution or implementation of the systems engineering process.Constraints may apply across all requirements,may be specified in a relationship to a specific requirement or set of requirements,or may be identifed as stand-alone requirements (i.e.,not bounding any specific requirement).（tdb）[GRG1] 

约束限制了系统开发过程中的设计方案或实现方法。约束可用于所有需求，定义在特定需求或需求组中，但有时也可以识别为独立需求（即，不限于某一特定需求）。

Examples of constraints include:

以下是一些约束的例子：

-    interfaces to already existing systems (e.g..format,protocol,or content) where the interface cannot be changed.

-与现有系统的接口(例如。(格式、协议或内容)，现有系统的接口不能被修改。

-    physical size limitations (e.g..a controller shall fit within a limited space in an airplane wing),

-物理尺寸限制(例如.控制器应在飞机机翼有限的空间内飞行)，

-    laws of a particular country,

国家的法律，

-    available duration or budget,

-项目周期或预算，

-    pre-existing technology platform,

-现有技术平台，

-    user or operator capabilties and limitations.

-用户或操作员的能力和局限。

-

Requirements may be ranked or weighted to indicate priority,timing,or relative importance.Requirements in scenario form depict the system's action from a user's perspective.

可以对需求进行分级或加权，以表明其优先级、时间要求或相对重要性。场景形式的需求从用户的角度描述系统的行为。

NOTE Subclauses 6.2.3 and 6.3.3 detail the process to define stakeholder and system requirements.

注 第6.2.3和6.3.3分节详细说明了界定涉众和系统要求的过程。

5.2.5 Characteristics of individual requirements单一需求的特点

Each stakeholder,system,and system element requirement shall possess the following characteristics:

每个干系人、系统和系统组成部分的需求应具有以下特点：

-    Necessary.The requirement defines an essential capability, characteristic, constraint,and/or quality factor,If it is removed or deleted,a deficiency will exist,which cannot be fuflled by other capabilities of the product or process.The requirement is currently applicable and has not been made obsolete by the passage of time.Requirements with planned expiration dates or applicability dates are clearly identified.

-必要性。需求定义了系统的基本能力、特性、约束和/或质量因素，如果缺失，系统将存在无法弥补的缺陷。该需求不仅仅当前需要，而且不会随着时间的推移而过时。需求明确确定了其有效期日期。

-

-    Implementation Free.The requirement,while addressing what is necessary and sufficient in the system,avoids placing unnecessary constraints on the architectural design.The objective is to be implementation-independent.The requirement states what is required,not how the requirement should be met.

需求不是实现。需求除了对系统是必须的、充分的之外，无需对系统的体系结构设计进行限制。目标是独立于实现的。需求说明了需要什么，而不是如何满足（实现）需求。

NOTE While such information may still be important,the information should be documented and communicated in some other form of documentation,such as the requirements attributes in subclause 5.2.8 (e.g..rationale) in order to aid in design and implementation.Additionally,including design solutions in the requirements may risk.the possibility that potential design solutions may be overlooked or eliminated.Examples include stating requirements that express an exact commercial system set or a system that can be bought rather than made,stating tolerances for items deep within the conceplual system,or establishing constraints that are not necessarily reflective of the parent requirement.[GRG2] (tbd)

注：尽管此类信息可能仍然很重要，但应以其他形式的文件记录和传达此类信息，如第5.2.8款（如基本原理）中的要求，以帮助设计和实施。通常，在需求中包含设计解决方案可能会带来风险。潜在设计解决方案可能被忽略或消除的可能性。例如，说明表示精确的商业系统集或可购买而非制造的系统的要求，说明相关系统中项目的公差，或建立不一定是父需求选择的约束。

-    Unambiguous.The requirement is stated in such a way so that it can be interpreted in only one way.The requirement is stated simply and is easy to understand.
明确的：需求陈述要明确，确保只能以一种方式解释。需求还应当表述简洁，并易于理解。

-    Consistent.The requirement is free of conflicts with other requirements.

-一致。该需求与其他需求没有冲突。

-    Complete.The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholder's need .

-完整性：所述需求无需进一步补充，因为它是可测量的，并且充分描述了满足干系人应具备的能力和特征。

-    Singular.The requirement statement includes only one requirement with no use of conjunctins.

-单一性：描述只包含一个需求。

-    Feasible.The requirement is technically achievable,does not require major technology advances,and fits within system constraints (e.g., cost, schedule, technical,legal,regulatory) with acceptable risk.

-可行性：该要求在技术上是可以实现的，不需要重大的技术进步，并且符合系统约束条件（例如，成本、进度、技术、法律、监管），具有可接受的风险。

-    Traceable.The requirement is upwards traceable to specific documented stakeholder statement(s) of need,higher tier requirement,or other source (e.g.,a trade or design study).The requirement is also downwards traceable to the specic requirements in the lower tier requirements specification or other system definition artefacts.That is,all parent child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.

-可追溯的：需求向上可追溯到特定的干系人需求说明、更高层次的需求或其他来源的需求（例如，交易或设计研究）。还可以向下追溯到下层需求规范或其他的特定需求。也就是说，需求的所有层级关系都进行标识，以便可跟踪到其来源和实现。

-

-    Verifiable.The requirement has the means to prove that the system satisfies the specified requirement.Evidence may be collected that proves that the system can satisfy the specifed requirement.Verifability is enhanced when the requirement is measurable.
可验证的。该需求要有证明系统满足规定要求的方法。可以收集用来证明系统满足规定要求的证据。如果需求是可测量的，可大大增强需求的可验证性。

5.2.6 Characteristics of a set of requirements需求集的特点

There are certain characteristics that need to be considered for the set of stakeholder,system,and system element requirements rather than for any individual requirement.This will ensure that the set of requirements collectively provide for a feasible solution that meets the stakeholder intentions and constraints. Each set of requirements shall possess the following characteristics:

相对于单个需求，对于干系人、系统和系统组件需求集，也有需要考虑的特有特性。这些特征将确保这组需求共同提供满足干系人意图和约束的可行方案。每组需求应具有以下特性：

-     Complete.The set of requirements needs no further amplfication because it contains everything pertinent to the definition of the system or system element being specifed.In addition,the set contains no To Be Defined (TBD),To Be Specified (TBS),or To Be Resolved (TBR) clauses.Resolution of the TBx designations may be iterative and there is an acceptable timeframe for TBx items,determined by risks and dependencies.

-完整性：需求集不应需要进一步的详细说明，因为它包含用来定义系统或系统元素的所有相关的信息。此外，该集合不包含待定义（TBD）、待指定（TBS）或待解决（TBR）的内容。通过迭代消除TBx项，依据其相关的风险和依赖性，TBx项目通常指定时间期限。

NOTE Some practices are recommended to improve completeness; include all requirements types; account for requirements in all stages of the life cycle; and involve all stakeholders in the requirements elicitation activity.

建议采用一些措施来提高需求完整性；包含所有需求类型；考虑生命周期所有阶段的需求；并让所有干系人参与到需求获取活动中。

-     Consistent.The set of requirements does not have individual requirements which are contradictory.Requirements are not duplicated.The same term is used for the same item in all requirements.

一致性。需求集内没有相互矛盾的需求，也没有重复的需求。所有需求使用统一的术语。

-     Affordable.The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g., cost, schedule,technical,legal,regulatory).

可行的。在整个生命周期的限制（如成本、进度、技术、法律、监管）下，所有需求满足要求。

-     Bounded.The set of requirements maintains the identifed scope for the intended solution without increasing beyond what is needed to satisfy user needs.

范围明确。需求集符合预期解决方案的确定范围，而不会超出满足用户需求所需的范围。

Careful checking of the requirements set and the traceable architectural design for these characteristics is critical to avoiding requirements changes and growth ('requirements creep') during the life cycle that will impact the cost,schedule or quality of the system.

仔细检查需求集和对这些特性进行跟踪对于避免生命周期内的需求变化和增加（“需求蔓延”）至关重要，因为这将影响系统的成本、进度或质量。

5.2.7 Requirement language criteria 需求语言标准

When writing textual requirements,the following considerations will help ensure that good requirements characteristics are employed.

在编写需求文本时，以下注意事项将有助于确保需求具备良好的特征。

Requirements should state 'what’ is needed,not 'how’.Requirements should state what is needed for the system-of-interest and not include design decisions for it.However,as requirements are allocated and decomposed through the levels of the system,there will be recognition of design decisions / solution architectures defined at a higher level.This is part of the iterative and recursive application of the requirements analysis and architectural design processes.

需求应该说明需要“什么”，而不是“如何”。需求应该说明系统需要什么，而不是设计决策。然而，随着需求在系统的层级上进行分解和分配，在更高层次上定义的设计决策/解决方案体系结构将得到认可。这是需求分析和架构设计过程的迭代和递归应用程序的一部分。

Vague and general terms shall be avoided.They result in requirements that are offten difficult or even impossible to verify or may allow for multiple interpretations.The following are types of unbounded or ambiguous terms:

应避免使用含糊和笼统的术语。它们导致要求难以验证，甚至不可能验证，或者可能允许多种解释。以下是无界或模糊术语的类型：

-     Superlatives (such as 'best','most')
最高级（如“最佳”、“最高级”）

-     Subjective language (such as 'user friendly,'easy to use','cost effective’)

-主观语言(如“用户友好”、“易用”、“节省成本”)

-     Vague pronouns (such as ‘it’,‘this','that’)
模糊代词(如它，这，那)

-     Ambiguous adverbs and adjectives (such as 'almost always', 'significant', 'minimal')

-有歧义的副词或形容词(如“几乎总是”、“意义重大”、“最小”)

-     Open-ended,non-verifiable terms (such as 'provide support','but not limited to','as a minimum')

-开放的、不可验证的术语(如“提供支持”、“但不限于”、“作为最低限度”)

-     Comparative phrases (such as better than',"higher qualiy')

-比较短语(如“好于”、“高质量”)

-     Loopholes (such as "if possible','as appropriate','as applicable')

-漏洞(如“如有可能”、“酌情”、“视情况而定”)

-     Incomplete references (not specifying the reference with its date and version number; not specifying just the applicable parts of the reference to restrict verification work)

不完整的参考文件（未指定参考文件的日期和版本号；未仅指定参考文件的适用部分以限制验证工作）

-     Negative statements (such as statements of system capability not to be provided)

-负面陈述(如不提供的系统能力陈述)

-

All assumptions made regarding a requirement shall be documented and validated in one of the requirement's attributes in subclause 5.2.8 (e.g.,rationale) associated with a requirement or in an accompanying document.Include definitions as declarative statements,not requirements.

对需求每个假设都应该被被记录，并使用第5.2.8款或其他文档中的相关特性进行验证。将定义包含为声明性语句，而不是需求。

5.2.8 Requirements attributes需求属性

To support requirements analysis,well-formed requirements should have descriptive attributes defined to help in understanding and managing the requirements.The attribute information should be associated with the requirements in the selected requirements repository.

为了支持需求分析，格式良好的需求应该定义描述性的属性，以帮助理解和管理需求。属性信息应与需求相关联。

5.2.8.1 Examples of requirements attributes需求属性示例

Important examples of requirements attributes include:

需求属性的例子包括：

-    Identification.Each requirement should be uniquely identified (i.e., number,name tag,mnemonic).Identification can reflect linkages and relationships,if needed,or they can be separate from identification.Unique identifiers aid in requirements tracing.Once assigned,the identification has to be unique - it is never changed (even if the identified requirement changes) nor is it reused (even if the identified requirement is deleted).

唯一标识。每个需求都应被唯一标识（即编号、名称标签、助记符）。如果需要，唯一标识可以用来反映需求之间的关联，也可以通过标识将需求区分开来。唯一标识符有助于需求跟踪。一旦分配了唯一标识，标识必须是唯一的 - 它永远不会更改（即使已标识的需求发生更改），也不会重用（即使已标识的需求被删除）。

-    Stakeholder Priority.The priority of each requirement should be identified.This may be established through a consensus process among potential stakeholders.As appropriate,a scale such as 1-5 or a simple scheme such as High,Medium,or Low,could be used for identifying the priority of each requirement.The priority is not intended to imply that some requirements are not necessary,but it may indicate what requirements are candidates for the trade space when decisions regarding alternatives are necessary. Prioritization needs to consider the stakeholders who need the requirements.This will facilitate trading off requirements and balancing the impact of changes among stakeholders.

干系人优先级。应确定每个需求的优先级。需求优先级由各干系人协商来确定。使用1-5或简单方案（如高，中或低）来定义需求的优先级。优先级并不意味着某些需求不是必需的，当需要权衡方案时，根据优先级可以知道哪些需求可被放弃。优先级需要考虑相关的干系人。这将有助于权衡需求，并平衡干系人变化对需求的影响。

-    Dependency.The dependency between requirements should be defined,when a dependency exists.Some requirements could have a low priority from one of the stakeholders' perspective,but nevertheless be essential for the success of the system.For example,a requirement to measure external ambient temperature could be essential to provide support to other requirements such as the maintenance of internal cabin temperature.This relationship should be identified so that if the primary requirement is removed,the suporting requirement can also be eliminated.

依赖关系。应进行明确定义需求之间存在依赖关系。从干系人的角度来看，某些需求的优先级可能较低，但对于系统的成功至关重要。例如，测量外部环境温度的需求对于支持其他需求（例如维持机舱内部温度）可能至关重要。有了依赖关系，在删除主要需求时，可以同时删除相关的支持需求。

-    Risk.Risk analysis techniques can be used to determine a grading for system requirements in terms of their consequences or degree of risk avoidance.Major risks are related to potential financial loss,potential missed business opportunity,loss of confldence by stakeholders,environmental impact,safety and health issues,and national standards or laws.

风险。风险分析技术可用于对需求进行风险评级，风险评级主要考虑风险发生时导致的后果或规避风险的难度。主要风险包括潜在的财务损失，潜在的商业机会错失，干系人的冲突损失，环境影响，安全和健康问题以及国家标准或法律的合规等等。

NOTE Additinal guidance on risk analysis can be found in ISO/IEC 16085.

注：关于风险分析的附加指南可在ISO/IEC 16085中找到。

-    Source.Each requirement should include an atribute that indicates the originator.Multiple sources may be considered creators of each requirement.Identifying the sources for each requirement support identifying which organizations(s) to consult for requirement clarification, deconfliction,modification,or deletion.The concept of ownership is related to source.Ownership applies to the origin of a requirement.The requirement source indicates where the requirement came from.For stakeholder requirements,the stakeholder who issues the requirement gains ownership.As requirements are further devolved through allocation and derivation,the responsibility to meet the requirement is passed to the appropriate product team.

需求来源。每个需求都应标明需求提出方。多个需求提出方，都可以被当做是需求的创建者。确定了需求来源，在进行需求澄清、消除冲突、修改或删除时就可以知道要去问谁。需求所有权与需求来源有关。需求来源等同有需求的所有权。需求来源表示需求来自哪里。提出要求的干系人具有需求的所有权。随着需求通过分配和派生进一步下沉，满足需求的责任被传递给相应的产品团队。

-    Rationale.The rationale for establishing each requirement should be captured.The rationale provides the reason that the requirement is needed and points to any supporting analysis,trade study,modelling,simulation,or other substantive objective evidence.

理由。应明确每个需求的存在的理由。理由提供了需要该要求的内在原因，并指出了（该需求存在的）任何支持性分析、权衡分析、建模、模拟或其他实质性客观据。

-    Difficulty.The assumed dificulty for each requirement should be noted (e.g.Easy/Nominal/difficult).This provides additional context in terms of requirements breadth and affordability.It also helps with cost modelling.

难度。应估计并标注每项需求的难度（例如，容易/一般/困难）。这在需求的广度和可承受性之外的方面提供了额外的信息。需求难度也有助于成本建模。

-    Type.Requirements vary in intent and in the kinds of properties they represent.This aids collecting requirements into groups for analysis and allocation.

需求类型。需求的目的及其属性种类有所不同。这有助于将需求来分组进行分析和分配。

5.2.8.2 Examples of the requirements type attribute需求类型属性示例

Important examples of the requirements type attribute include:

需求类型属性的重要例子有：

-    Functional.Functional requirements describe the system or system element functions or tasks to be performed.

功能性的。功能需求描述了要实现的系统或系统要素功能或任务。

-    Performance.A requirement that defines the extent or how well,and under what conditions,a function or task is to be performed.These are quantitative requirements of system performance and are verifiable individully.Note that there may be more than one performance requirement associated with a single function,functional requirement,or task.

性能。定义要执行的功能或任务的程度、好坏，以及执行条件。这些是系统性能的定量要求，可单独进行验证。请注意，与单个功能、功能需求或任务相关联的性能需求可能不止一个。

n  Usability/Quality-in-Use Requirements(for user performance and satisfaction) - Provide the basis for the design and evaluation of systems to meet the user needs.Usability/Quality-in-Use requirements are developed in conjunction with,and form part of,the overall requirements specification of a system.

可用性/使用质量要求（针对用户性能和满意度）-评估系统设计如何及在何种程度上满足用户要求。可用性/使用质量要求是与系统的总体需求规范一起开发的，并构成系统总体需求规范的一部分。

-    Interface.Interface requirements are the definition of how the system is required to interact with external systems (external interface),or how system elements within the system,including human elements,interact with each other (internal interface).

接口需求。接口需求定义了系统如何与外部系统交互（外部接口），或系统内的各组成部分（包括人）之间如何相互交互（内部接口）。

-    Design Constraints.A requirement that limits the options open to a designer of a solution by imposing immovable boundaries and limits (e.g.,the system shall incorporate a legacy or provided system element,or certain data shall be maintained in an on-line repository).

设计约束。通过指定系统边界和限制来约束设计人员在设计时的可选项（例如，系统应包含遗留或（外部）提供的系统元素，或者在联机数据库中维护数据）。

-    Process requirements.These are stakeholder,usually acquirer or user,requirements imposed through the contract or statement of work.Process requirements include: compliance with national,state or local laws，including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives.Process requirements may also be imposed on a program by corporate policy or practice.System or system element implementation process requirements,such as mandating a particular design method,are usually captured in project agreement documentation such as contracts,statements of work,and quality plans.

流程要求。这些是干系人，通常是需方或用户，通过合同或工作说明书所施加的要求。流程要求包括：遵守国家、州或地方法律；行政要求；需方/供应商关系要求；以及具体的工作指示。流程要求也可能由公司政策或具体实践要求强加给项目。系统或系统要素实现过程需求，如指定特定设计方法，通常在项目协议文件（如合同、工作说明书和质量计划）中约定。

-    Non-Functional.These specify requirements under which the system is required to operate or exist or system properties.They define how a system is supposed to be.Quality requirements and human factors requirements are examples of this type.

非功能性需求。规定了系统运行或存在的额外要求或属性。它们定义了一个系统应该是怎样的。比如质量要求和人为因素要求就是例子。

n  Quality Requirements - Include a number of the ‘ilities' in requirements to include,for example, transportability, survivability, flexibility, portability,reusability,relability,maintainability,and security.The list of non-functional,quality requirements (e.g..Ilities") should be developed prior to initiating the requirements document.This should be tailored to the system(s) being developed.As appropriate,measures for the quality requirements should be included as well.

质量要求—在要求中包括许多“能力”，例如，可移植性、生存性、灵活性、可移植性、可重用性、相关性、可维护性和安全性。在启动需求文件之前，应制定非功能性质量需求（如能力）清单。应将其考虑到正在开发的系统中。必要时，还应包括质量需求的度量方法。

NOTE 1 Additional guidance on software quality requirements can be found in the ISO/IEC SQuaRE standards,especially ISO/IEC 25030 and in ISO/IEC 25010.

注1：关于软件质量要求的其他指南可在ISO/IEC SQuaRE标准中找到，特别是ISO/IEC 25030和ISO/IEC 25010。

-    Human Factors Requirements - State required characteristics for the outcomes of interaction with human users (and other stakeholders affected by use) in terms of safety, performance, effectiveness, efficiency, reliability, maintainability,health,well-being and satisfaction.These include characteristics efficiency,reliability,maintainability,health,well-being and satisfaction.These include characteristics such as measures of usbility,including effectiveness,eficiency and satisfaction; human reliability;freedom from adverse health effects.

-人为因素需求-就安全性、性能、有效性、效率、可靠性、可维护性、健康、幸福感和满意度而言，说明与人类用户（以及受使用影响的其他干系人）交互结果所需具备的特征。这些特征包括效率、可靠性、可维护性、健康、幸福感和满意度。这些特征包括可用性度量，包括有效性、效率和满意度；人的可靠性；免受有害健康因素的影响。

NOTE2 Aditional guidance on human factors requirements can be found in subclause 6.2.3.2.

注2：关于人为因素要求的传统指南见第6.2.3.2款。

NOTE3 There may be other ways to organize requirements types.

注3：可能还有其他方法来组织需求类型。

5.3 Practical considerations实际考虑

5.3.1 Iteration and recursion of processes过程的迭代和递归

Two forms of process application - iterative and recursive - are essential and useful for applying the processes defined in this International Standard.

两种形式的过程应用-迭代和递归-对于应用本标准中定义的过程是必要和有用的。

5.3.1.1 Iterative application of processes过程的迭代应用

When the application of the same process or set of processes is repeated on the same level of the system,the application is referred to as iterative.Iteration is not only appropriate but also expected.New information is created by the application of a process or set of processes.Typically this information takes the form of questions with respect to requirements, analysed risks or opportunities. Such questions should be resolved before completing the activities of a process or set of processes.When re-application of activities or processes can resolve the questions，then it is useful to do so.Iteration can be required to ensure that information with admissible quality is used prior to applying the next process or set of activities to a system-of-interest.In this case iteration adds value to the system to which the processes are being used.The iterative application of processes is illustrated in Figure 2.【tbd】

当在系统的同一级别上重复执行同一过程或一组过程时，这个过程称为迭代。迭代不仅是有效的，而且是经常使用。通过应用一个或一组过程会生成一些信息。通常情况下，这些信息表现为需求、风险或机遇相关的问题。这些问题应在完成后续的活动之前解决。当重新应用活动或流程可以解决问题时，这样做很有用。在将下一个过程或一组活动应用于新系统之前，可能需要迭代以保证信息的质量。在这种情况下，迭代为正在使用流程的系统增加了价值。流程的迭代应用如图2所示。

NOTE There can also be internal iteration within a process.This is not shown in Figure 2 for simplicity of the figure.

注：流程中也可以有内部迭代。简洁起见，图2中没有显示这一点。

5.3.1.2 Recursive application of processes过程的递归应用

When the same set of processes or the same set of process activities are applied to successive levels of system elements within the system structure,the application form is referred to as recursive.The outcomes from one application are used as inputs to the next lower (or higher) system in the system structure to arrive at a more detailed or mature set of outcomes.Such an approach adds value to successive systems in the system structure.Figure 3 illustrates the recursive application of processes to systems from the top down.The stakeholder requirements definition process may only be applied at the system-of-interest level.However,the requirements analysis and architectural design processes will be applied at each successive level of recursion.

我们将在系统内的连续层级上执行同一组过程或活动，称之为递归。在一个层级的过程或活动的输出，用作系统结构中下一较低（或较高）层级的输入，以得到更详细或更完整的输出结果。这种步骤为系统结构中的后继系统提供的价值。图3说明了从上到下将过程递归应用于系统的过程。干系人需求定义过程只能应用于特定的系统级别。然而，需求分析和架构设计过程将递归应用于每个连续的级别。

NOTE The recursion can also be bi-directional,with requirements from the system requiring further analysis at the system-of-interest level.This is not shown in Figure 3 for simplicity of the figure.

注：递归也可以是双向的，系统需求需要在目标系统级别进行进一步分析。简便起见，图3中省略了这一点。

5.3.2 Iteration and recursion in requirements engineering需求工程中的迭代和递归

Since different groups of stakeholders often view the system from differing levels of abstraction,it is necessary to define and document requirements statements at lower,more detailed levels of abstraction than just the overall system-of-interest.This is accomplished by allocating or distributing the system requirements to the system elements.The activity of allocating requirements to system elements is part of the architectural design process and proceeds in parallel with the definition of the system architecture.There may be multiple iterations between the requirements analysis and architectural design processes to resolve trade-offs between the requirements and architecture (see Figure 2).

由于不同的干系人群体通常从不同的抽象层次来看待系统，因此有必要在较低、更详细的抽象层次上定义和记录需求陈述，而不仅仅是在系统的总体上。这是通过将系统需求分配给系统元素来实现的。将需求分配给系统元素的活动是体系结构设计过程的一部分，与系统体系结构的定义并行进行。需求分析和体系结构设计过程之间可能会有多次迭代，以解决需求和体系结构之间的权衡问题（见图2）。

One of the main objectives of architectural design is to determine how to partition the system; that is,how to identify which requirements should be allocated to which system elements.As system elements are defined,additional requirements statements (called derived requirements) should be created to define relationships between the architectural elements of the system,to provide necessary clarity in the context of the lower levels of abstraction of the system elements,or to specify design constraints or performance levels on system elements.This is accomplished through recursive application of the requirements analysis process (see Figure 3).

架构设计的主要目标之一是确定如何分解系统；也就是说，如何确定哪些需求应该分配给哪些系统元素。在定义系统元素时，应创建额外的需求（称为衍生需求），以定义系统架构元素之间的关系，使得系统元素在较低抽象级别上更加清晰，或指定系统元素的设计约束或性能级别。这是通过递归应用需求分析过程实现的（见图3）。

In addition,some requirements cannot be derived until some portion of the architecture or design evolves.Some requirements depend on how several system elements inter-operate.For example，the information throughput of a system is dependent on the interaction of the system hardware,software,personnel actions,and environment.Recursive and iterative application of the requirements analysis and architectural design processes are used to capture these requirements.

此外，在架构或设计的某些部分确定之前，无法衍生出某些需求。一些要求取决于几个系统元素如何相互操作。例如，系统的信息吞吐量取决于系统硬件、软件、人员动作和环境的交互。需求分析和体系结构设计过程的递归和迭代应用程序用于获得这些需求。

Even where requirements engineering is well resourced,the level of analysis will seldom be uniformly applied.For example,early in the requirements analysis process experienced engineers are often able to identify where existing or off-the-shelf solutions can be adapted to the implementation of system elements.The requirements allocated to these may need less analysis,while others,for which a solution is less obvious,may need to be subjected to further,more detailed analysis.Critical requirements,i.e.requirements having high risk or impacting public safety,environment,or health,should always be analyzed rigorously.

即使在需求工程资源充足的地方，分析的层次也很少是统一的。例如，在需求分析过程的早期，经验丰富的工程师通常能够确定现有的解决方案如何调整去以实现系统元素。有些需求需要的分析工作可能较少，而解决方案尚不明确的其他需求可能需要进行更进一步的详细分析。关键需求，即具有高风险或影响公共安全、环境或健康的需求，应始终着重分析。

NOTE Subclause 6.2.3.2 details the process to define requirements,including how to apply iteration and recursion to develop requirements flly,particularly with regards to requirements negotiation during the analysis,allocation and trading off between requirements.

第6.2.3.2款详细说明了定义需求的过程，包括如何应用迭代和递归来快速开发需求，特别是在需求分析、分配和权衡期间的需求协商。

5.4 Requirement information items需求信息项

This subclause describes the relationship between the requirements processes and requirement information items by ilustrating a typical application style in a project.

本节通过举例说明项目中的典型应用样式，以描述需求过程和需求信息项之间的关系。

  Figure 4-Example of requirements scope in a business context

图4-业务上下文中需求范围的示例

Requirements processes and their resultant specifications depend on the scope of the system for which the requirements are to be defined.Requirements for a system or system element to be developed or changed are subject to organization level requirements for the business or organizational operation.The requirements for the system or system element are allocated to lower level systems progressively.A typical view for thescope of a system and the corresponding requirements is illustrated in Figure 4.

需求过程及其规范取决于定义需求的系统范围。系统或系统元素的需求受商业机构或组织的组织级需求的约束。系统或系统元素需求逐步分配给较低级别的部分。系统范围和相应需求的典型视图如图4所示。

NOTE The term business is used even though it could apply to not-for-proft organizations such as in the publicsector.Users of this standard may replace each occurrence of the term business with the term organization or organizational depending on the users' environment.

注：即使商业机构一词可以适用于非营利组织，如公共部门，也可以使用该术语。根据用户环境的不同，读者可以用“组织”或“组织的”代替“商业机构”这个术语。

The stakeholder requirements specification(StRS),the system requirements specification (SyRS) and thesoftware requirements specification (SRS) are intended to represent different sets of requirement information items.The specifications correspond to the requirements in Figure 4 as follows: StRS – Stakeholder Requirement (business management level and business operational level); SyRs - System Requirements;and SRs - Software Requirements.These information items can be applied to multiple specifications(instances) iteratively or recursively.An example of a sequence of requirements processes and specifications is illustrated in Figure 5.

干系人需求规范（StRS）、系统需求规范（SyRS）和软件需求规范（SRS）旨在表示不同的需求信息项集。规范对应于图4中的要求，如下所示：StRS–干系人要求（业务管理层和业务运营层）；SyRs——系统要求；和SRs-软件需求。这些信息项可以迭代或递归地应用于多个规范（实例）。图5举例说明了一系列需求过程和规范。

EXAMPLE 1 The SyRS can be used for a system or a system element.The SyRS can also be used to specify software requirements.

EXAMPLE 2 The SRS can be used for lower level sofware requirements for software specific elements of a system or system element.

 Figure 5-Example of the sequence of requirements processes and specifications

图5需求、过程和规范序列示例

The Concept of Operation (ConOps) and the System Operational Concept (OpsCon) are useful in eliciting requirements from various stakeholders in an organization and as a practical means to communicate and share the organization's intentions.The ConOps,at the organization level,addresses the leadership's  intended way of operating the organization.It may refer to the use of one or more systems as 'black boxes'.The OpsCon addresses the specific system-of-interest from the user's view point.

运行方案（ConOps）和系统操作方案（OpsCon）有助于从组织中的各类干系人那里获取需求，并作为沟通和分享组织意图的实用手段。在组织层面上，ConOps解决了领导层对组织运作方式的要求，它将一个或多个系统视为“黑箱”。而OpsCon则从用户的角度看待系统。

Information items represented in the StRS,SyRS,SRS,ConOps,and OpsCon documents are interdependent.The development of these items requires interaction and cooperation,particularly in relation to the business processes,organizational practice,and options for technical solutions.

STR、SyRS、SRS、ConOps和OpsCon文档中的信息项是相互依赖的，这些信息项的开发需要相互作用和合作，特别是在业务流程、组织实践和技术解决方案选择方面。

Different types of systems may have parallel documentation for the various requirements they contain.However,in general,they will start with an StRS and an SyRS,and include the software specifications as wellas those for hardware and interfaces.

不同类型的系统可能会针对其包含的各种需求同时提供多种文档。然而，一般来说，它们将从StRS和SyRS开始，包括软件规范以及硬件和接口规范。

6 Processes 过程

6.1 Requirement processes需求过程

The project shall implement the following requirements engineering processes as defined inISO/IEC 15288:2008 (IEEE Std 15288-2008)，System life cycle processes,and ISO/IEC 12207:2008(IEEE Std 12207-2008)，Software life cycle processes,depending on the adherence to one or both ofiSO/IEC 15288 and ISO/IEC 12207:

项目将执行在以下标准中定义的需求工程的过程：SO/IEC 15288:2008 (IEEE Std 15288-2008)，System life cycle processes,and ISO/IEC 12207:2008 Iso/iec 15288：2008(ieee std 15288-2008)，系统生命周期过程，以及iso/iec 12207：2008 (IEEE Std 12207-2008)， Software life cycle processes,depending on the adherence to one or both of ISO/IEC 15288 and ISO/IEC 12207：

-    Stakeholder requirements definition process (ISO/IEC 15288:2008(IEEEstd 15288-2008).subclause 6.4.1 or ISO/IEC 12207:2008 (IEEE Std 12207-2008),subclause 6.4.1)

关系人需求定义过程

-    Requirements analysis process (ISO/IEC 15288:2008 (IEEE Std 15288-2008) subclause 6.4.2，or ISO/IEC 12207:2008 (IEEE Std 12207-2008),subclause 6.4.2)

需求分析过程

-    Software requirements analysis process (ISO/IEC 12207:2008 (IEEE Std 12207-2008),subclause 7.1.2) for the acquision or supply of software products.

软件需求分析过程

6.1.1 Guidelines for Processes过程指南

In this International Standard,the requirements related processes are elaborated upon,in order to provide the user with additional planning and implementation guidance.

在本标准中，详细阐述了与需求相关的过程，以便为用户提供更多的规划和实施指导。

Beginning with subclause 6.2,original ISO/IEC 15288:2008 (IEEE Std 15288-2008) tasks relevant to this International Standard,are highlighted in a box,to show the reader the original text being elaborated.Tasks that are not relevant were omitted,but the original numbering from ISO/EC 15288 was retained.The original source reference is included in the lower right hand corner.The original ISO/IEC (IEEE Std 15288-2008) purposes and outcomes relevant to this Intermational Standard are used in their entirety,without any change,for the subset of processes that are relevant to requirements engineering.

从第6.2款开始，方框中突出显示了与本标准相关的原始ISO/IEC 15288:2008（IEEE标准15288-2008）任务，以向读者展示正在阐述的原始文本。省略了不相关的任务，但保留了ISO/EC 15288的原始编号。原始源参考包含在右下角。与本标准相关的原始ISO/IEC（IEEE Std 15288-2008）目的和结果全部用于与需求工程相关的过程子集，不作任何更改。

The principal processes are 1) Stakeholder Requirements Definition Process,and 2) Requirements Analysis Process (ISO/IEC 15288),or System Requirements Analysis Process (ISO/IEC 12207).These two processes result in a baseline set of requirements which flow into the architectural design process where the requirements are allocated,decomposed and traced to system elements.The architectural design process also includes allocation of requirements that initiates the recursive and iterative application of the requirements processes.This is applied based on the project's system life cycle model definition as described in ISO/IEC TR 24748-1,Systems and software engineering-Life cycle management-Part 1:Guide for life cycle management.The architectural design process includes allocation and decomposition of requirements that triggers the recursive application of the requirements processes,for the definition of system element requirements and the iterative application of the requirements analysis process for derived requirements.There are also other technical and project processes that have requirements-related activities or tasks.

主要过程是：1）干系人需求定义过程，2）需求分析过程（ISO/IEC 15288）或系统需求分析过程（ISO/IEC 12207）。这两个过程产生了一组基线需求，这些需求流入体系结构设计过程，在该过程中，需求被分配、分解并跟踪到系统各部分。架构设计过程还包括需求分配，需求分配启动了需求过程的递归和迭代应用。这是基于ISO/IEC TR 24748-1《系统和软件工程生命周期管理第1部分：生命周期管理指南》中描述的项目系统生命周期模型定义应用的。体系结构设计过程包括需求的分配和分解，这些过程会触发需求过程的反复应用，用于定义系统元素需求和迭代应用派生需求的需求分析过程。还有其他与需求相关的活动或任务的技术和项目过程。

There are minor differences between the system and software activities.For the purposes of this International Standard,the clauses are generally titled after the systems engineering processes in ISO/IEC 15288.

系统和软件活动之间存在细微差异。就本标准而言，这些条款通常以ISO/IEC 15288中的系统工程过程命名。

The relationships between the processes in the two standards are shown in Annex C along with the mapping to the relevant clause in this International Standard.Tables C-1 and C-2 identify the two principal technical processes and their applicable activities in requirements engineering.Table C-3 identifies other technical activities related to requirements engineering.

附录C中显示了两个标准中流程之间的关系以及与本标准相关条款的对应关系。表C-1和C-2确定了需求工程中的两个主要技术过程及其适用活动。表C-3确定了与需求工程相关的其他技术活动。

6.2 Stakeholder requirements definition process干系人需求定义过程

6.2.1 Purpose目的

The purpose of the Stakeholder Requirements Definition Process is to define the requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.

干系人需求定义过程的目的是定义系统的需求，该系统可以在预定的环境中提供用户和其他干系人所需的服务。

It identifies stakeholders,or stakeholder classes,involved with the system throughout its life cycle,and their needs,expectations,and desires.It analyzes and transforms these into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational service is validated.

它识别系统整个生命周期中涉及的干系人或干系人类别，以及他们的需求、期望和愿望。它分析这些需求并将其转换为一组共同的干系人需求，这些需求表达了系统与其操作环境的预期交互，并据此验证每个实现的操作服务是否正确。

6.2.2 Outcomes 成果

As a result of the successful implementation of the Stakeholder Requirements Definition Process:

干系人需求定义过程的输出：

a) The required system characteristics and context of use of the product functions and services,and operational concepts are specifed.

规定了所需的系统特征、产品功能和服务的使用环境以及操作过程。

b) The constraints on a system solution are defined.

定义了系统方案的约束条件。

c) Traceability of stakeholder requirements to stakeholders and their needs is achieved.

实现了需求到干系人及其诉求的可追溯性。

d) The stakeholder requirements are defined.

定义了干系人需求。

e) Stakeholder requirements for validation are identifed.

确定了干系人对验证的需求。

6.2.3 Activities and tasks活动和任务

The project shall implement the following activities and tasks in accordance with applicable organization policies and procedures with respect to the Stakeholder Requirements Definition Process.

项目应根据与干系人需求定义过程相关的适用组织政策和程序，实施以下活动和任务。

6.2.3.1 Elicit stakeholder requirements干系人需求引导

This activity consists of the following tasks:

此活动由以下任务组成：

1)   Identily the individual stakeholders or stakeholder classes who have a legitimate interest in the system throughout its life cycle.

识别在系统的整个生命周期中对系统具有利益诉求的个人干系人或干系人阶层。

NOTE This includes,but is not limited to, users, operators, supporters, developers,producers,trainers,maintainers,disposers,acquirer and supplier organizations,parties responsible for extemal interfacing entties or enabling systems,regulatory bodies and members of sociely.Where direct communication is not practicable(e.g.for consumer products and services),representatives or designated proxy stakeholders are selected.

注：这包括但不限于用户、运营商、支持者、开发者、生产商、培训师、维护人员、处置者、收购方和供应商组织、负责外部接口或授权系统的各方、监管机构和社会成员。如果无法进行直接沟通（例如，对于消费品和服务），则选择代表或指定的代理干系人。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3a) 1]]

lt is best to identify all stages of the system life cycle,and then identify the individual stakeholders or stakeholder classes who have a legitimate interest in the system throughout its life cycle.Requirements elicited from a stakeholder will be dependent on the role,responsibility,and position of the stakeholder in the organization.Identify all of the stakeholder classes that have a role or interest in the desired product or service.Then identify those stakeholders who have strong influence on goals,strategies,operations,and the target system.The list of stakeholder classes is often modified with time as more is learned about the desired product or service.Representatives from each stakeholder class should be identified and include multi-level perspectives.Information gathered from only one stakeholder class,or only one level,is likely to be biasedfrom a single perspective.A representative cross-section of stakeholders is necessary to provide the true picture of the 'problem to be solved'.

先确定系统生命周期的所有阶段，然后识别在整个系统生命周期中对系统具有利益诉求的个人干系人或干系人阶层。由干系人引出的需求将取决于干系人在组织中的角色、责任和地位。先识别在所需产品或服务中承担角色或利益诉求的所有干系人阶层。再识别对目标、战略、运营和目标体系有重大影响的干系人。随着对所需产品或服务的了解越来越多，干系人阶层的列表通常会随着时间的推移而修改。应确定每个干系人阶层的代表，并包括多方位视角。仅从一个干系人阶层或一个级别收集的信息可能存在偏差。有代表性的干系人是必要的，以提供“待解决问题”的真实情况

2)   Elicit stakeholder requirements from the identified stakeholders.

2)从识别出的干系人那里引出干系人需求。

NOTE Stakeholder requirements describe the needs,wants,desires,expectations and perceived constraints of identified stakeholders.They are expressed in terms of a model that may be textual or formal,that concentrates on system purpose and behaviour，and that is described in the context of the operational environment and conditions.A product quality model and quality requirements,such as found in ISO/IEC 9126-1 and ISO/IEC 25030,may be useful for aiding this activity. Stakeholder requirements include the needs and requirements imposed by society,the constraints imposed by an acquiring organization and the capabilities and operational characteristics of users and operator staff.It is useful to cite sources,including solicitation documents or agreements,and,where possible,their justification and rationale,and the assumptions of stakeholders and the value they place on the satisfaction of their requirements.For key stakeholder needs，the measures of effectiveness are defined so that operational performance can be measured and assessed.lf significant risks are likely to arise from issues (i.e.needs， wants,constraints,limits,concerns,barriers,factors or considerations) relating to people (users and other stakeholders) and their involvement in or interaction with a system at any time in the life cycle of that system,recommendations for identifying and treating human-system issues can be found in ISO PAS 18152,A specification for the process assessment of human-system issues.

注：干系人需求描述了已识别的干系人的需求、愿望、期望和约束。它们以模型的形式表示，模型可以是文本的，也可以是形式化的，它着重于系统目的和行为，并基于操作环境和条件的上下文定义。ISO/IEC 9126-1和ISO/IEC 25030中的产品质量模型和质量要求可用于本活动。干系人需求包括社会施加的需求和要求、需方施加的约束以及用户和运营商员工的能力和运营特征。需求中引用来源（包括招标文件或协议）、理由和原因，以及干系人的假设及给他们带来的收益很有用处。对于关键的干系人需求，定义有效性的衡量标准，可以衡量和评估收益。如果在系统生命周期的任何时候，与人员（用户和其他干系人）及其参与系统或与系统交互有关的问题（即需求、需求、约束、限制、担忧、障碍、因素或考虑因素）可能产生重大风险，可以参考ISO PAS 18152中识别和处理人类系统问题的建议，这是人机系统问题过程评估规范。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 a) 2)]

NOTE1 Subclause 5.2.3 describes the use of the Concept of Operations and the System Operational Concept as toolsto elicit,document and capture the information needed to build requirements.Annex A contains the essential elements forthe System Operational Concept and Annex B contains this information for the Concept of Operations.

注1：第5.2.3款描述了使用ConOps和系统OpsCon作为工具来引出、记录和捕获构建需求所需的信息。附件A载有系统OpsCon的基本要素，附件B载有ConOps的信息。

NOTE2 There are very few systems for which there are no significant risks related to use，users，operators,maintainers,or some source of human-system issues.

注2：很少有系统不存在与使用、用户、操作员、维护人员或某些人为系统问题来源相关的重大风险。

ln most systems,there will be many sources of requirements and it is essential that all potential sources are identified and evaluated for their impact on the system.Some of the common sources of requirements and issues that need to be dealt with are:

在大多数系统中，将有许多需求来源，识别和评估所有潜在来源对系统的影响至关重要。需求和问题的一些常见来源是：

-    Goals - The term 'Goal'(sometimes called ‘business concern' or ‘critical success factor') refers to the overall，high-level objectives of the system.Goals provide the motivation for a system but are often vaguely formulated.lt is important to assess the value (relative to priority) and cost of goals.

-目标 - 术语“目标”（有时称为“业务关注点”或“关键成功因素”）指的是系统的总体、高层次目标。目标为一个系统提供了动力，但往往是模糊不清的。评估目标的价值（相对于优先级）和成本很重要。

-    Mission profile - How will the system perform its mission? How will the system contribute to business or organizational operations?

任务简介 - 系统将如何执行其任务？系统将如何促进业务或组织运营？

-    Operational scenarios - Are there any special scenarios that need to be accounted for? Scenarios can beused to define operational concepts and to bound the range of anticipated uses of system products,the intended operational environment and interfacing systems,platforms or products.Scenarios help identify requirements that might otherwise be overlooked.

操作场景-是否存在需要考虑的特殊场景？场景可用于定义操作概念，并限制系统产品使用范围、预期操作环境和接口系统、平台或产品的预期使用范围。场景有助于确定可能被忽略的需求。

-    Operational environment and context of use-Requirements will be derived from the environment in which the system or software product will operate.Will it operate in hot or cold conditions,externally,or other equally restrictive conditions? What are the characteristics,timing,and quantity (workload) of interactions with the system environment? Are there any timing constraints in a real-time system or interoperability constraints in a business environment such as constraints in operational hours? Other aspects of the environment (threats and interoperating systems) can also lead to requirements upon the system.These can greatly affect system feasibility and cost,and restrict design choices.

操作环境和使用环境 - 需求来自系统或软件产品运行的环境中。它会在高温或低温、外部或其他同等限制条件下运行吗？与系统环境交互的特征、时间和数量（工作负载）是什么？实时系统中是否存在时间限制或业务环境中是否存在互操作性限制，如操作时间限制？环境的其他方面（威胁和互操作系统）也可能导致对系统的需求。这些会极大地影响系统的可行性和成本，并限制设计选择。

-    Operational deployment - When will the system be used? will it be deployed during the initial,middle,orwrap up phases of a need?

-操作部署-什么时候使用系统？它会在需求的初始阶段、中期阶段或结束阶段部署吗？

-    Performance - What are the critical system parameters to accomplish the mission?

-性能-完成任务的关键系统参数是什么？

-    Effectiveness - How effective/efficient should the system be in performing its mission? What are the applicable measures of effectiveness? Does the system have to be available to perform its missions a minimum amount of time,such as 90-percent of the time?

有效性-系统如何有效或高效地执行任务？如何评价有效性？系统是否必须大多数时候（例如90%的时间）可用？

-    Operational life cycle - How long will the system's life time be? 20 years? 30 years? How many hours per year should the system operate?

-运行生命周期-系统的生命周期有多长？20年？30年？系统每年应运行多少小时？

-    Organizational environment - Many systems are required to support an organization's process and this may be conditioned by the structure,culture,and internal politics of the organization.In general,new systems should not force unplanned change to the business process.

组织环境-需要许多系统来支持组织的流程，这可能受到组织结构、文化和内部政治的制约。通常，新系统不应强制对业务流程进行不必要的变更。

-    User and operator characteristics - Who will be using or operating the system? How will they vary in role,skill level and expected workload? What are the expectations or constraints on their capability an availability? Should allowance be made for acssibiliy?

用户和操作员特征-谁将使用或操作系统？他们在角色、技能水平和预期工作量方面的差异如何？对其能力和可用性的期望或限制是什么？是否应考虑可访问性？

NOTE3 See ISO/IEC TR 29138-1:2009，Information technology- Acessibility considerations for people with disabilties - Part 1: User needs summary,for additional information on accessbilty.

注3：关于可访问性的更多信息，参见ISO/IEC TR 29138-1:2009，信息技术-残疾人的可访问性考虑-第1部分：用户需求摘要。

As part of this task,it is important to identify and assess opportunities to reuse previously existing requirements.This includes identification of existing systems that provide similar functions or capabilites,specified functions or capabilties applicable to the new system-of-interest,and information on the extent of reusability.

作为这项任务的一部分，识别和评估重用已有需求的机会非常重要。这包括识别提供类似功能或能力的现有系统、适用于新系统的功能或能力，以及关于可重用程度的信息。

NOTE 4 See ISO/IEC 26551,Information technology Tools and methods of requrements englneering and management for product lines for additional guidance on requirements reuse.

注4：参见ISO/IEC 26551，产品线需求工程和管理的信息技术工具和方法，了解需求重用的更多指南。

Requirements elicitation is an iterative activity.Consider several different techniques for identifying requirements during the elcitation task to better accommodate the diverse set of requirements sources,including:

需求获取是一项迭代活动。可以采取不同的技术来识别需求，以更好地适应多样化的需求来源，包括：

-    Structured workshops with brainstorming

-有组织的集思广益讲习班

-    Interviews,questionnaires

-访谈、问卷

-    Observation of environment or work patterns (e.g.time and motion studies)

-观察环境或工作模板(例如时间和动作研究)

-    Technical documentation review

-技术文件评审

-    Market analysis or competitive system assessment
市场分析或竞品评估

-    Simulations,prototyping,modelling

-模拟、原型制作、建模

-    Benchmarking processes and systems

基准流程和系统

-    Organizational analysis techniques (e.g.Strength - Weakness - Opportunity - Threat analysis,product portfolio)

组织分析技术（例如优势-劣势-机会-威胁分析、产品组合）

System stakeholders will be authoritative sources for requirements of the system that represent their interests or area(s) of expertise.However,they usually are not familiar with how to transform their expertise into well formed requirements statements.In addition to these human sources of requirements,important system requirements often are imposed by other systems in the environment that require some services of the system,or act to constrain the system,or even from fundamental characteristics of the application domain.There may also be safety or other regulatory constraints that drive system requirements.

系统干系人是代表其利益或专业领域的系统需求的权威来源。然而，他们通常不熟悉如何将他们的专业知识转化为格式良好的需求陈述。除了这些来自人的需求外，重要的系统需求通常来自其他系统，这些系统要么需要新系统的某些服务，要么对新系统有约束，甚至来自应用领域的基本要求。还可能存在安全或其他监管约束。

A description of the user community (typically found in the organization concept of operations) may provide common understanding across the effort and validate the appropriateness of scenarios.A user description may cover the demographic group(s) to which a product will be marketed or the specific personnel categories that will be assigned to employ the system or otherwise benefit from its operation.

对用户社区的描述（通常在组织ConOps中找到）可以提供对整个工作的共同理解，并验证场景的适当性。用户描述可能涵盖产品将要销售到的特定人群，或指定使用该系统或从其运行中获益的特定人员类别。

Involving the stakeholders in the verification of the stakeholder requirements (e.g.,well-formed requirements) during stakeholder requirements elicitation can also aid early validation by those stakeholders that the statements accurately capture their needs.Apply the characteristics and guidelines for building well-formed requirements statements provided in subclause 5.2.

在干系人需求获取过程中，让干系人参与需求（例如，格式良好的需求）的验证，也有助于干系人尽早确认需求陈述的准确性。请使用第5.2款：构建格式良好的需求的特征和指南。

6.2.3.2 Define stakeholder requirements.定义干系人需求。

This activity consists of the following tasks:

此活动由以下任务组成：

1) Define the constraints on a system solution that are unavoidable consequences of existing agreements,management decisions and technical decisions.

定义对系统方案的约束，这些约束是现有协议、管理决策和技术决策所导致的。

NOTE These may result from 1) instances or areas of stakeholder-defined solution 2) implementation decisions made at higher levels of system hierarchical structure 3) required use of defined enabling systems,resources and staff.

注：这些可能来自1）干系人定义的解决方案的实例或领域2）在更高层次的系统层次结构上做出的实施决策3）需要授权、使用资源和人员。

 (ISO/EC 15288：2008(EESTD 15288-2008年)，6.4.1.3b)1]

Constraints are one type of requirement.They may be imposed by:

约束也是一种需求。它们可以通过下列方式施加影响：

-    External or organization stakeholders (e.g.,engineering plans,technical performance measures,technical maturity,regulations,life cycle costs,or user and operator staffing constraints).

外部的或内部的干系人（例如，工程计划、技术性能度量、技术成熟度、法规、生命周期成本，或用户和操作员人员配备限制）

-    External,interacting,or enabling systems.

外部、交互或授权系统

-    Activities from other life cycle phases and technical activities such as Transition,Operation,and Maintenance.

其他生命周期阶段的活动和技术活动，如转换、运行和维护。

-    Measures of effectiveness and suitability that reflect overall acquirer/user satisfaction (e.g.,performance, safety, reliability, availability, maintainability,and workload requirements).

有效性和适用性度量（例如，性能、安全性、可靠性、可用性、可维护性和工作量要求），这将反映需方/用户的总体满意度。

Examples of constraints include: 1) the budget limit required by top management is a constraint for succeeding requirement processes,and 2) the maintenance strategy developed for the system may impose conditions or constraints on requirements (repair times and/or spares levels may drive reliability values),or may define capability requirements directly (e.g.built-in-test functionality to support maintenance fault isolation).

约束的示例包括：1）最高管理层要求的预算限制是后续需求过程的约束，2）为系统制定的维护策略可能会对需求施加条件或约束（维修时间和/或备件水平可能会影响系统可靠性），或者可以直接定义能力要求（例如，支持维护故障隔离的内置测试功能）。

2) Define a representative set of activity sequences to identify all required services that correspond to anticipated operational and support scenarios and environments.

定义一组典型的活动序列，以确定与预期的操作和支持场景及环境相对应的所有必需服务。

NOTE Scenarios are used to analyze the operation of the system in its intended environment in order to identify requirements that may not have been formally specified by any of the stakeholders,e.g.，legal regulatory and social obligations.The context of use of the system is identified and analyzed.Include in the context analysis the activities that users perform to achieve system objectives,the relevant characteristics of the end-users of the system (e.g.,expected training,degree of fatigue),the physical environment (e.g.,available light,temperature) and any equipment to be used (e.g.protective or communication equipment).The social and organizational influences on users that could affect system use or constrain its design are analyzed when applicable.

注：场景用于分析系统在其预期环境中的运行，以确定干系人可能未正式提出的需求，例如法律法规和社会义务。识别和分析系统的使用环境。在上下文分析中包括用户为实现系统目标而执行的活动、系统最终用户的相关特征（例如，预期培训、疲劳程度）、物理环境（例如，光照、温度）和要使用的设备（例如，防护或通信设备）。如果适用，分析可能影响系统使用或限制其设计的对用户的社会和组织影响。

ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 b) 2)]

Scenarios can be used to define the concept documents and bound the range of anticipated uses of system products,the intended operational environment and   interfacing systems,platforms or products.Scenarios help identify requirements that might otherwise be overlooked.Scenarios may help to establish critical and desired system performance thresholds and objectives for system performance parameters that are critical for system success.They may also establish those that are desired but may be subject to compromise in order to meet the critical parameters.Use case approaches can also be used to define concept documents.Under this approach,a set of actors (systems and classes of people that interact with the system) is identified,along with their goals，purposes，and needs for the system.The use cases are analyzed to identify stakeholder requirements.

场景可用于定义概念文件，并限定系统产品、预期操作环境和接口系统、平台或产品的预期使用范围。场景有助于识别可能被忽略的需求，有助于确定系统参数的阈值和目标，这些参数对系统的成功至关重要。他们还可以确定那些需要的，但可能会妥协，以满足关键参数。用例方法也可用于定义概念文档。在这种方法下，确定了一组参与者（与系统交互的系统和人员类别），以及他们对系统的目标、目的和需求。通过分析用例以确定干系人需求。

Different levels of abstraction or presentation mechanisms will often be necessary to address the full range of stakeholders,including the acquirer,user,and supplier.

通常需要不同级别的抽象或表示机制来处理所有干系人，包括收购方、用户和供应商。

3) Identify the interaction between users and the system.

识别用户与系统之间的交互。

NOTE Usability requirements are determined,establishing， as a minimum，the most effective,efficient,and reliable human performance and human-system interaction.The interaction should take into account human capabilities and skills limitations.Where possible,applicable standards,e.g.,ISO 9241,and accepted professional practices are used in order to define:

注：确定可用性要求，要求至少建立最有效、最高效、最可靠的人因绩效和人-系统交互。互动应考虑到人的能力和技能限制。在可能的情况下，使用适用标准（如ISO 9241）和公认的专业实践来定义以下方面：

i) Physical,mental,and learned capabilties;

身体、心理和学习能力；

ii) Work place,environment and facilities,including other equipment in the context of use;

工作场所、环境和设施，包括使用中的其他设备。

iii) Normal,unusual,and emergency conditins;

正常、异常和紧急情况；

iv) Operator and user recruitment,training and culture;

经营者和用户的招聘、培训和文化；

If usability is important,usability requirements should be planned, specified,and implemented through the life cycle processes,and the following standards or technical reports may be aplicable:

如果可用性很重要，则应在整个生命周期过程中规划、制定和实施可用性要求，可以参考以下标准或技术报告:

- ISO 9241-11:1998,Ergonomic requirements for office work with visual display terminals (VDTs)

- Part 11: Guidance on usability;

-ISO 13407:1999,Ergonomics Ergonomics of human-system interaction - Human-centred design process for interactive systems.

(ISO/IEC 15288：2008(IEEESTD 15288-2008年)，6.4.1.3b)3)]

Consideration of human systems integration(HSI) is an important concept within systems engineering.HSI focuses on the human over the system life cycle.It promotes a total system approach which includes humans,technology (hardware and software),the operational context,and the necessary interfaces among the system elements to make them work in harmony.HSI brings human-centred disciplines (such as manpower,personnel,training,human factors, environment, health, safety, habitability,and survivability) into the systems engineering process to improve the overall system design and performance.Incorporation of HSI considerations into requirements is contingent upon a clear understanding of the missions，functions,operational scenarios and tasks,user population,and quality characteristic considerations.Requirements in the areas of user tasks and performance,manpower,and training can only be defined through decomposition of the goals or missions of the system down to the level of task analyses to define characteristics of the user interface or front end analyses to determine training impacts.

考虑人-系统集成（HSI）是系统工程中的一个重要概念。HSI关注系统生命周期中的人。它促进了一种全面的系统方法，其中包括人、技术（硬件和软件）、操作环境，以及系统元素之间的必要接口，以使它们协调工作。HSI将以人为中心的学科（如人力、人员、培训、人为因素、环境、健康、安全、宜居性和生存能力）纳入系统工程过程，以改进整体系统设计和性能。将HSI考虑纳入需求取决于对任务、功能、作战场景和任务、用户群和质量特征考虑的清晰理解。用户任务和性能、人力和培训方面的需求只能通过将系统的目标或任务分解到任务分析级别来定义，以定义用户界面的特征，或通过前端分析来确定培训影响。

NOTE ISO 13407:1999 has been replaced by ISO 9241-210,Ergonomics of human-system interaction - part 210:Human-centred design for interactive systems.

4) Specifty health,safety,security,environment and other stakeholder requirements and functions that relate to critical qualities.

规定与关键质量相关的健康、安全、安保、环境和其他干系人要求和功能。

NOTE Identify safety risk and,if warranted,specify requirements and functions to provide safety.This includes risks associated with methods of operations and support,health and safety ,threats to property and environmental influences.Use applicable standards,e.g.,IEC 61508,and accepted professional practices.Identify security risk and,if warranted, specify all applicable areas of system security,including physical, procedural,communications,computers，programs,data and emissions.Identify functions that could impact the security of the system,including access and damage to protected personnel，properties and information，compromise of sensitive information,and denial of approved access to property and information.Specify the required security functions.including mitigation and containment,referencing applicable standards and accepted professiona practices where mandatory or relevant.

注：识别安全风险，并在保证的情况下，指定提供安全的要求和功能。这包括与操作和支持方法、健康和安全、财产威胁和环境影响相关的风险。使用适用标准，如IEC 61508和公认的专业实践。识别安全风险，如果有保证，指定系统安全的所有适用领域，包括物理、程序、通信、计算机、程序、数据和排放。识别可能影响系统安全的功能，包括对受保护人员、财产和信息的访问和损坏、敏感信息的泄露，以及拒绝对财产和信息的批准访问。指定所需的安全功能。包括缓解和遏制措施，在强制性或相关的情况下，参考适用标准和公认的专业实践。

(ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 b) 4)]

Critical qualities are aspects of the system that are essential to ensure the integrity of the system and its operating environment.

关键质量是系统确保系统及其操作环境完整性所必需的，并且很重要的方面。

6.2.3.3 Analyze and maintain stakeholder requirements.分析和维护干系人需求。

This activity consists of the following tasks:

此活动由以下任务组成：

1) Analyze the complete set of elicited requirements.

分析获取的完整的需求集。

NOTE Analysis includes identifing and prirtizing the conlicting, missing, incomplete,ambiguous,inconsistent,incongruous or unverifable requirements.

注：分析包括识别和区分冲突、缺失、不完整、不明确、不一致、不合适或无法验证的需求。

[ISO/EC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 c) 1]

Requirements should be analyzed for the characteristics defined in subclauses 5.2.5 and 5.2.6.Requirements should be prioritized and may be classified as described in subclause 5.2.8.The use of checklists or standard templates helps in the review process.

针对第5.2.5款和第5.2.6款中定义的特性的进行需求分析。需求应按优先顺序排列，并可按第5.2.8款所述进行分类。使用检查表或标准模板有助于审查过程。

If stakeholder requirements from existing or legacy systems have been identifed as candidates for reuse,then they should be analyzed for use,based on factors such as applicability,feasibility,availability,quality,cost effectiveness, value,and currency.While reusing requirements,a careful consistency check of reused requirements with the system-of-interest's specifc requirements should be performed in order to assure consistency.

如果现有系统中的干系人需求被确定为可重用的候选需求，则应根据适用性、可行性、可用性、质量、成本效益、价值和货币等因素对其进行分析以供使用。在重用需求时，应仔细检查重用需求与当前系统需求是否一致。

2) Resolve requirements problems.

解决需求问题。

NOTE This includes requirements that cannot be realized or are impracical to achieve.

注：这包括无法实现或无法实现的要求。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 c) 2)]

It is important to continue to perform requirements negotiation during the analysis and allocation of requirements,because conflicts will occur.Negotiation might be needed among stakeholders requiring mutually incompatible features,or due to conflicts between desired performance requirements,constraints,available budget,and delivery schedule.In most cases,it is necessary to consult with the stakeholder(s) to reach a consensus on an appropriate trade-off.It is often important for contractual reasons that such decisions are traceable to the stakeholder.Various analysis methods and conflict resolution techniques may be applicable to facilitate the resolution and are dependent on the specific situation.

在需求分析和分配过程中，继续进行需求协商是很重要的，因为会发生需求冲突。可能需要在存在冲突功能的干系人之间进行协商，或者由于期望的性能要求、约束、可用预算和交付时间之间的冲突。在大多数情况下，有必要与干系人协商，做出适当的权衡和达成共识。出于合同原因，此类决策可追溯至干系人通常很重要。各种分析方法和冲突解决技术可能适用于促进基于具体情况解决这种冲突。

Some organizations consider requirements negotiation to be part of requirements validation.The specific process subcategory is not important as long as the conflict resolution occurs as early as possible in the requirements analysis task.

一些组织认为需求协商是需求验证的一部分。只要在需求分析任务中尽早解决冲突，特定流程子类别就不重要。

3) Feed back the analyzed requirements to applicable stakeholders to ensure that the needs and expectations have been adequately captured and expressed.

将分析过的需求反馈给干系人，以确保其要求能被充分获取和表达。

NOTE Explain and obtain agreement to the proposals to resolve conflicting,impractical and unrealisable stakeholder requirements.

注：解释并解决冲突的、不切实际和无法实现的干系人的需求。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 c) 3)]

4) Establish with stakeholders that their requirements are expressed correctly.

与干系人确认他们的需求得到正确的表达。

NOTE This includes confirming that stakeholder requiremnents are comprehensible to originators and that the resolution of conflict in the requirements has not corrupted or compromised stakeholder intentions.

注：这包括确认发起人可以理解干系人的要求，并且冲突的解决没有破坏或损害干系人的意图。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3c) 4]

It is normal for there to be one or more formally scheduled points in the requirements engineering processwhere the requirements are validated.The objective is to identify any problems before resources are committed to implementing a system solution for the requirements.Requirements validation is concerned with the process of examining the requirements set to ensure that it defines the right system,i.e.the system thatthe stakeholder expects.The most common activities in requirements validation are conducting requirements reviews,simulation,and prototyping.

在需求工程过程中，通常会计划一次或多次正式的需求验证。目标是在投入资源实施需求的解决方案之前，尽可能识别出存在的问题。需求确认涉及检查需求集的过程，以确保它定义了正确的系统，即干系人期望的系统。需求验证中最常见的活动是进行需求评审、模拟和原型设计。

Conducting requirements reviews is perhaps the most common means of both verification and validation of the requirements document(s).A group of reviewers is constituted with a brief to look for errors，mistaken assumptions,lack of clarity,verifiability issues and deviation from standard practice.The composition of the group that conducts the review is important (at least one representative of the acquirer should be included for an acquirer-driven project,for example) and it may help to provide guidance on what to look for in the form of checklists.

进行需求评审是验证和确认需求文档最常用的方法。成立审查小组，阅读需求报告，以查找错误、错误的假设、定义不明确、可验证性问题以及与标准实践的偏差。审查小组的组成很重要（例如，对于由需方主导的项目，至少应包括一名需方代表），这有助于通过检查清单，提供对审查内容的指导。

Reviews may be conducted at any level of abstraction in the set of requirements.Various types of reviewsmay be applicable throughout the development and maintenance of the requirements,including technical reviews,inspections,and walk-throughs.Effective early requirements review and validation can be achieved using low fidelity prototypes to obtain feedback from potential users of the system.

评审可以在需求集合的任何抽象层次上进行。有各种类型的评审方法可能适用于需求的整个开发和维护过程，包括技术评审、检查和走查。早期需求评审和确认可以通过使用低保真原型来获得系统潜在用户的反馈来实现。

NOTE1 Additional guidance on reviews can be found in IEEE Std 1028-2008,Standard for Software Reviews and Audits.

注1：更多的评审指南参见：IEEE Std 1028-2008,Standard for Software Reviews and Audits

NOTE2 Discussion on prototyping and simulation is contained in subclause 6.3.3.2.

注：原型法和模拟法参见本标准的6.3.3.2小节。

5).Record the stakeholder requirements in a form suitable for requirements management through the life cycle and beyond.

在整个生命周期中，记录干系人需求，记录得形式要符合需求管理的要求。

NOTE These records establish the stakeholder requirements baseline,and retain changes of need and their origin throughout the system life cycle.They are the basis for traceability to the system requirements and form a source of knowledge for requirements for subsequent system entities.

注：这些记录建立了干系人需求基线，并记录了整个系统生命周期中的需求变更及其来源。它们是系统需求追溯的基础，并形成后续系统需求的知识来源。

(ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.1.3 c) 5)]

Consideration should be given to using a requirements management tool,especially for more complex projects.This tool should have the capability to trace linkages between requirements to show relationships.A requirements management tool is intended to facilitate and support the systematic managing of requirements throughout the project life cycle.This includes,but is not limited to,requirements elcitation,requirements analysis,requirements change management, requirements reuse and requirements quality assessment.

可以考虑使用需求管理工具，尤其是对于复杂的项目。需求管理工具可以跟踪需求之间的联系。需求管理工具旨在促进和支持整个项目生命周期内需求的系统化管理，包括需求引用、需求分析、需求变更管理、需求重用和需求质量评估。

NOTE Additional information and guidelines on requirements management tools can be found in ISO/IEC TR 24766:2009 - Guide for requirement engineering tool capabities.

注：更多需求管理工具的指南参见：ISO/IEC TR 24766:2009 – 需求工程工具指南。

The requirements repository should first be populated with the source documentation of the stakeholder needs,project constraints (such as from business policies/rules or regulatory requirements),and any other conditions that provide the basis for the total set of system requirements that will govern its design.Both the source and that provide the basis for the total set of system requirements that will govern its design.Both the source and rationale for each requirement needs to be captured.

需求库中首先要有干系人需求的源文档、项目约束（例如来自业务策略/规则或法规要求）以及为整个系统需求集提供基础的任何其他条件，这些需求集影响后续的设计。需求来源和约束条件，都为管理其设计的系统需求提供了基础。需要获取每个需求的来源和理由。

Requirements documents that may be output as part of the Stakeholder Requirements Definition process include:

可作为干系人需求定义过程一部分输出的需求文件包括：

-     Stakeholder Requirements Specification

-干系人需求规范

-     Concept of Operations

-     System Operational Concept

-系统运作概念

Additional information on these requirements-related documents can be found in Clauses 7 through 9 and Annex A and B.

有关这些要求相关文件的更多信息，请参见第7条至第9条以及附件A和B。

The requirements repository should also include any requirements attributes, including the priority and criticality of the requirements.Additional information on requirements attributes can be found in subclause 5.2.8.

需求库还应包括所有需求属性，包括需求的优先级和关键程度。有关需求属性的更多信息，请参见第5.2.8款。

6) Maintain stakeholder requirements traceability to the sources of stakeholder need.

保持干系人需求对需求来源的可追溯性。

NOTE The stakeholder requirements are reviewed at key decision times in the life cycle to ensure that account is taken of any changes of need.

注：在生命周期的关键决策时刻对干系人需求进行审查，以确保考虑需求的任何变化。

(ISO/EC 15288:2008 (IEEE Std 15288-2008),6.4.1.3c) 6)]

Initial requirements traceability should be established and maintained to document how the formal requirements are intended to meet the stakeholder objectives and achieve stakeholder agreement.Stakeholder requirements need to be captured,traced,and maintained throughout the system life cycle and beyond,and placed under configuration control.Use of a requirements management tool can facilitate this process.More discussion on the aplication of traceability can be found in subclause 6.3.3.2 of this intemational Standard under task 3.

应建立并保持初始需求的可追溯性，以记录正式需求旨在如何满足干系人目标并达成干系人协议。干系人需求需要在整个系统生命周期及其后获取、跟踪和维护，并置于配置控制之下。使用需求管理工具可以促进这一过程。关于可追溯性应用的更多讨论见本标准第6.3.3.2款任务3。

NOTE 1 Additional guidance on placing information under configuration control can be found in ISO/IEC 15288,subclause 6.3.5.and in subclause 6.5.2.1 of this Intemalional Standard.

注1：ISO/IEC 15288第6.3.5款以及本标准第6.5.2.1款中提供了将信息置于配置控制下的附加指南。

NOTE 2 Subclause 5.2.5 descibes requirements traceabilityt as it pertains to requirements engineering.

注2本标准第5.2.5款描述了与需求工程相关的需求可追溯性。

6.3 Requirements analysis process需求分析过程

6.3.1 Purpose目的

The purpose of the Requirements Analysis Process is to transform the stakeholder, requirement-driven view of desired services into a technical view of a required product that could deliver those services.

需求分析过程的目的是将干系人对所需服务的需求驱动视图转换为能够提供这些服务的所需产品的技术视图。

This process builds a representation of a future system that will meet stakeholder requirements and that,as far as constraints permit,does not imply any specific implementation.It results in measurable system requirements that specify,from the suplier's perspective,what characteristics it is to possess and with what magnitude in order to satisfy stakeholder requirements.

需求分析过程构建了一个未来系统的表示，该系统将满足干系人的需求，并且只要约束允许，并不包含任何具体的实现。需求分析过程生成可测量的系统需求，从供应商的角度，具体说明了为了满足干系人的需求，系统需要具备哪些特征，以及达到何种程度。

6.3.2 Outcomes成果

As a result of the successful implementation of the Requirements Analysis Process:

完成需求分析后的产出物包括：

a)   The required characterstics,attributes,and functional and performance requirements for a product solution are specifed.

产品解决方案应具备的特性、属性以及功能和性能要求。

b)   Constraints that will affect the architectural design of a system and the means to realize it are specified.

b)具体规定了影响系统架构设计和实现方法的制约因素。

c)   The integrity and traceability of system requirements to stakeholder requirements is achieved.

c)实现了系统需求到干系人需求的完整性和可跟踪性。

d)   A basis for verifying that the system requirements are satisfied is defined.

d)确定了验证系统要求是否得到满足的基础。

6.3.3 Activities and tasks活动和任务

The project shall implement the following activitles and tasks in accordance with applicable organization policies and procedures with respect to the Requirements Analysis Process.

项目应遵循需求分析过程相关的组织政策和程序，执行以下活动和任务。

6.3.3.1 Define system requirements.定义系统需求。

This activity consists of the following tasks:

此活动由以下任务组成：

1)Define the functional boundary of the system in terms of the behavior and properties to be provided.

根据要提供的行为和提交物定义系统的功能边界。

NOTE This includes the system's stimuli and its responses to user and environment behavior,and an analysis and description of the required interactions between the system and its operational envionment in terms of interface constraints,such as mechanical, electrical, mass, thermal, data,and procedural flows.This establishes the expected system behavior,expressed in quantitative terms,at its boundary.

注：这包括系统的刺激及其对用户和环境行为的响应，以及根据接口约束（如机械、电气、质量、热、数据和程序流）分析和描述系统与其操作环境之间所需的交互。这将在其边界处建立期望的系统行为，对这些行为要进行量化描述。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.2.3a) 1)]

Scope problems can be minimized by establishing boundary conditions for the system (or service) with the stakeholders before defining the system requirements.Three factors which affect the boundary conditions are:

在定义系统需求之前，可以通过与干系人一起建立系统（或服务）的边界条件来最小化问题范围。影响边界条件的三个因素是：

-     Organization - stakeholders should have an understanding of the organization in which the targeted system will be used and of the real mission or objective of that organization.

组织-干系人应了解使用目标系统的组织以及该组织的真正使命或目标。

-     Environment - stakeholders should be aware of the maturity of the domain of the system-of-interest,the certainty of interfaces between the system-of-interest and other systems in the operational environment,and the role of the system-of-interest relative to other systems in the operational environment

环境-干系人应了解相关系统涉及领域的成熟度关系统与操作环境中其他系统之间接口的确定性，以及系统在操作环境中相对于其他系统的位置。

-     Constraints - stakeholders should consider the constraints that affect the life cycle of the system-of-interest,such as cost,schedule,political,and operational.

-约束-干系人应该考虑影响系统生命周期的约束，例如成本、进度、政治和操作。

2) Define each function that the system is required to perform.

定义系统需要实现的每个功能。

NOTE 1 This includes how well the system,incuding its operators,is required to perform that function,the conditions under which the system is to be capable of performing the function,the conditions under which the system is to commence performing that function and the conditions under which the system is to cease performing that function.

注1：这包括要求系统多好用、操作人员需要具备的技能，系统能够执行该功能的条件、系统开始执行该功能的条件以及系统停止执行该功能的条件。

NOTE 2 Conditions for the performance of functions may incorporate reference to required states and modes of operation of the system.System requirements depend heavily on abstract representations of proposed system characteristics and may employ multiple modeling techniques and perspectives to give a sufficiently complete description of the desired system requirements.

注2：功能执行的条件可包括要求的系统状态和运行模式。系统需求在很大程度上依赖于拟开发系统特征的抽象表示，并可能采用多种建模技术和视角，以充分完整地描述所需的系统需求。

(ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.2.3a) 2)]

As a better understanding is gained of the interactions and interfaces among the various functions and elements of the system,requirements are generated through combinations of performance and effectiveness analyses,trade studies,design development,interface defnitions,and costbenefit assessments.

随着对系统各种功能和要素之间的相互作用和接口的深入理解，通过性能和有效性分析、权衡研究、设计开发、接口定义和成本效益评估等一系列的过程，最终获得完整的系统需求。

Again,for the system,it is important to identiy and assess opportunities to reuse previously existing requirements.This includes identification of existing systems that provide similar functions or capabilities,specified functions or capabilities aplicable to the new system-of-interest,and information on the extent of reusability.

同样，对于系统来说，识别和评估重用之前的需求的机会是很重要的。这包括识别可以提供类似功能或能力的现有系统、现有系统适用于新系统的功能或能力，以及关于可重用程度的信息。

NOTE See ISO/IEC 26551,Software and systems engineering- Tools and methods of requirerments engineering and management for product lines for additional guidance on requirements reuse.

注：参见ISO/IEC 26551，软件和系统工程-产品线需求工程和管理的工具和方法，用于需求重用的附加指南。

3) Define necessary implementation constraints that are introduced by stakeholder requirements or are unavoidable solution limitations.

定义干系人需求引入的或解决方案限制的必要实施约束。

NOTE This includes the implementation decisions that are allocated from design at higher levels in the structure of the system.

注：这包括从系统结构中更高层次的设计中分配的实施决策。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.2.3a) 3)]

It is important to validate constraints with stakeholders and ensure they are fully understood and correct before evolving a set of system requirements and the architectural design.In addition to operational scenarios and requirements,implementation constraints may also come from extemal drivers,such as interfacing systems in the operating environment,enabling systems or regulatory requirements.

在开发一组系统需求和体系结构设计之前，与干系人确认约束并确保它们被充分理解并无误非常重要。与操作场景和需求不同，约束也可能来自外部驱动因素，如操作环境中的接口系统、授权系统或监管要求。

4)Define technical and quality in use measures that enable the assessment of technical achievement.

定义技术和质量方面的度量措施，以便能够评估技术效果。

NOTE This includes defining critical performance parameters assoclated with each effectiveness measure identified in the stakeholder requirements.The critical performance measures are analyzed and reviewed to ensure stakeholder requirements are met and to ensure identification of project cost,schedule or performance risk associated with any non-compliance.ISO/IEC 15939 provides a process to identify,define and use appropriate measures.The ISO/IEC 9126 series of standards provides relevant quality measures.

注：这包括定义与干系人要求中确定的每个有效性度量相关的关键性能参数。对关键绩效指标进行分析和审查，以确保满足干系人的要求，并确保识别可能导致不合规的项目成本、进度或绩效风险。ISO/IEC 15939提供了识别、定义和使用适当措施的过程。ISO/IEC 9126系列标准提供了相关的质量措施。

[ISO/EC 15288:2008 (IEEE Std 15288-2008).6.4.2.3a) 4)]

Technical measures are used to provide insight into the progress of the system or system elements in achieving the technical parameters specified in the requirements.These include Measures of Performance(MOP) and Technical Performance Measures (TPM).An MOP is a measure that characterizes physical or functional attributes relating to the system operation.MOPs are measured under operational environment conditions.A TPM is a measure used to assess design progress,compliance to performance requirements,and technical risks for critical performance parameters.See ISO/IEC 26702 and ISO/IEC TR 24748-2 for more information on these.The quality in use measures are used to determine whether a product meets the needs of specified users to achieve specified goals with effectiveness,productity,safety and satisfaction in a specified context of use in a realistic system environment.

技术措施用于深入了解系统或系统要素要求中规定的技术参数方面的达标情况。这些措施包括绩效措施（MOP）和技术绩效措施（TPM）。MOP是表征与系统运行相关的物理或功能属性的一种量度。MOP是在操作环境条件下测量的。TPM是用于评估设计进度、性能要求合规性和关键性能参数的技术风险的度量。有关这些方面的更多信息，请参阅ISO/IEC 26702和ISO/IEC TR 24748-2。使用中的质量度量用于确定产品是否满足特定用户的需求，以在现实系统环境中的特定使用环境中实现有效性、生产性、安全性和满意度的特定目标。

5)Specify system requirements and functions,as justified by risk identification or criticality of the system,that relate to critical qualities,such as health,safety,security,reliabilty,availability and supportabilty.

根据风险识别或系统的关键性，指定与关键质量相关的系统要求和功能，如健康、安全、安保、可靠性、可用性和保障性。

NOTE This includes analysis and definition of safety considerations, including those relating to methods of operation and maintenance, environmental influences and personnel injury.It also includes each safety related function and its associated safety integrity.expressed in terms of the necessary risk reduction,is specified and allocated to designated safety-related systems.Applicable standards are used concerning functional safety,e.g.,IEC 61508,and environmental protection, e.g.,ISO 14001.Analyze security considerations including those related to compromise and protection of sensitive information,data and material.The security-related risks are defined,including,but not limited to, administrative, personnel, physical, computer, communication, network,emission and environment factors using,as appropriate,applicable security standards.

注：这包括安全因素的分析和定义，包括与操作和维护方法、环境影响和人员伤害有关的安全因素。它还包括每个安全相关功能及其相关的安全完整性。以必要的风险降低表示，并指定和分配给指定的安全相关系统。使用的适用标准涉及功能安全，如IEC 61508和环境保护，如ISO 14001。分析安全考虑因素，包括与敏感信息、数据和材料的泄露和保护相关的考虑因素。定义了安全相关风险，包括但不限于行政、人员、物理、计算机、通信、网络、排放和环境因素，并酌情使用适用的安全标准。

 (ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.2.3a) 5)]

Again,both the source and rationale for each requirement need to be captured.The traceability should be updated and maintained to document how the formal system requirements,including derived requirements,are intended to meet the stakeholder requirements and objectives and achieve stakeholder agreement.

同样，需要捕获每个需求的来源和根本原因。应更新和维护可追溯性，以记录正式系统需求（包括衍生需求）旨在如何满足干系人需求和目标并达成干系人协议。

Specifications are collections of requirements.They describe essential technical requirements for products,materials,and the criteria for determining whether those requirements are met Requirements specifications that are important as part of the Requirements Analysis Process may include:

规范是需求的集合。它们描述了产品、材料的基本技术要求，以及确定这些要求是否满足的标准。作为需求分析过程的一部分，需求规范包括：

-    System Requirements Specification

系统需求规范

-    Software Requirements Specification

软件需求规范

Subclauses 9.4 and 9.5 contain detailed specification content for the system and software requirements specifications.

子条款9.4和9.5包含系统和软件需求规范的详细规范内容。

The benefits of documenting both the system requirements and the software requirements include:

记录系统需求和软件需求的益处有一下几点：

-    It establishes the basis for agreement between the acquirers or suppliers on what the product is to do (in market driven projects,the user input may be provided by marketing)

它为需方或供应商之间就产品的用途达成协议奠定了基础（在市场驱动的项目中，用户输入可能由市场部提供）

-    It forces a rigorous assessment of requirements before design can begin and reduces later redesign.

它强制在设计开始之前对需求进行严格的评估，并减少以后的返工。

-    It provides a realistic basis for estimating product costs,risks and schedules.

它为估计产品成本、风险和进度提供了现实的基础。

-    Organizations can use the specifications to develop validation and verification plans.

组织可以使用规范来制定验证和验证计划。

-    It provides an informed basis for deploying a product to new users or new operational environments.

它为将产品部署到新用户或新的操作环境提供了信息。

-    It provides a basis for product enhancement.

它为产品增强提供了基础

6.3.3.2 Analyze and maintain system requirements.分析和维护系统需求。

This activity consists of the following tasks:

此活动由以下任务组成：

1) Analyze the integrity of the system requirements to ensure that each requirement,pairs of requirements or sets of requirements possess overall integrity.

分析系统需求的完整性，以确保每个需求、成对需求或需求集具有整体完整性。

NOTE Each system requirement statement is checked to establish that it is unique,complete,unambiguous,consistent with all other requirements, implementable and verifiable.Deficiencies,conlicts and weaknesses are identified and resolved within the complete set of system requirements.The resulting system requirements are analyzed to confrm that they are complete,consistent,achievable (given current technologies or knowledge of technological advances) and expressed at an appropriate level of detail.Refer to ISO/IEC 26702:2007,IEEE Standard for Aplication and Management of the Systems Engineering Process for additional detailed guidance regarding the atrbutes and qualtbes of good requirements.

注：检查每个系统需求陈述，以确定其唯一性、完整性、明确性，一致性，可实现可验证。发现并解决所有需求的缺失、冲突和不充分问题。对产生的系统需求进行分析，以确认它们是完整的、一致的、可实现的（基于当前技术或技术发展），并得以充分描述。参考ISO/IEC 26702:2007，IEEE系统工程过程应用和管理标准，了解有关良好要求的适用性和质量的更多详细指南。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.2.3 b) 11

Again,for system requirements,it is important to verify that requirements are well formulated.Review all requirements for the characteristics of a good requirement and good set of requirements as described in subclauses 5.2.5 and 5.2.6.

同样，对于系统需求，重要的是验证需求是否得到了很好的定义。参考第5.2.5款和第5.2.6款中的要求，审查需求定义是否具备好的需求的特点。

If system requirements from existing or legacy systems have been identified as candidates for reuse,then they should be analyzed for use,based on factors such as applicabiliy,feasiblily,ailbility,quality,cost effectiveness,value,and currency. While reusing requirements,a careful consistency check of reused requirements with the system-of-interest's specific requirements should be performed in order to assure consistency.

如果确定采用来自现有或遗留系统的系统需求，则应根据适用性、可行性、可用性、质量、成本效益、价值和货币等因素对其进行分析以供使用。在重用需求时，应仔细检查重用需求与当前系统的特定需求的一致性。

NOTE See ISO/IEC 26551,Software and systems engineering- Tools and methods of requirements engineering and management for product lines for additional guidance on requirements reuse.

注：有关需求重用的更多指南，请参见ISO/IEC 26551，软件和系统工程-产品线需求工程和管理的工具和方法。

The classifications in subclause 5.2.8 may help with this task.The 'plan verification' process of ISO/IEC 15288,should be used for the definition,planning,and execution of requirements verification(ISO/IEC 15288:2008 (IEEE Std 15288-2008),subclause 6.4.6.3 a).

第5.2.8款中的分类可能有助于完成此任务。ISO/IEC 15288的“计划验证”过程应用于需求验证的定义、规划和执行（ISO/IEC 15288:2008（IEEE标准15288-2008），第6.4.6.3 a款）。

In addition to verification of the requirements,the following activity addresses validation of the requirements,individually and as a set,as properly representing the stakeholder needs.

除了验证需求外，以下活动还单独或作为一个集合验证需求，以准确地代表干系人的需求。

3)   Feed back the analyzed requirements to applicable stakeholders to ensure that the specified system requirements adequately reflect the stakeholder requirements to address the needs and expectations.

将已分析的需求反馈给干系人，确保系统需求充分地反映了干系人需求，以满足其要求和期望。

NOTE Confirmation is made that they are a necessary and suficient response to stakeholder requirements and a necessary and suficient input to other processes,in particular architectural design.

注：确认它们是对干系人要求的必要且充分的响应，并可作为其他过程（尤其是架构设计）的必要且充分的输入。

[ISO/EC 15288:2008 (IEEE Std 15288-2008),6.4.2.3 b) 2)]

Requirements validation ensures that stakeholder requirements have been correctly transformed into system requirements.Various techniques may be used,including stakeholder reviews,prototyping,modelling and simulation,conceptual modelling, and formal modelling.The appropriate technique may vary based on the characteristics of the stakeholders,so multiple techniques may need to be employed to ensure accounting for characteristics of the stakeholders,so multiple techniques may need to be employed to ensure accounting for all stakeholders.Reviews are discussed in subclause 6.2.3.3 of this International Standard under task 4.

需求验证确保干系人需求已正确转化为系统需求。可以使用各种技术，包括干系人评审、原型设计、建模与仿真、概念建模和正式建模。根据干系人的特点，可以从采用不同的技术，因此可能需要使用多种技术来确保适应所有干系人以及干系人的所有特点。本标准第6.2.3.3款任务4中讨论了评审。

Stakeholder reviews are a common technique to validate requirements that can be implemented easily.The stakeholder reviews involve conducting a analysis of the requirements with a group that includes the key stakeholders to determine that the system requirements are complete,correct,and consistent reflect the intent of the stakeholder requirements.Checklists are often developed to aid the reviews to ensure that all applicable categories of requirements have been considered and documented.

干系人评审是一种常见的技术，用于验证需求是否可以实现。干系人评审包括与包括关键干系人在内的小组一起对需求进行分析，以确定系统需求是否完整、正确且一致，是否反映干系人的意图。检查表通常用于帮助评审，以确保所有适用的需求类别都已得到考虑和记录，没有被遗漏。

Prototyping is commonly employed for eliciting requirements,validating the interpretation of the system requirements,clarifying or examining requirement attributes,and identifying any omitted requirements.The advantage of prototypes is that they provide a richer context for stakeholder evaluation and input,they can make it easier to interpret the assumptions,and they can provide useful feedback on why they are wrong.For example,the dynamic behaviour of a user interface can be better understood through an animated or static prototype than through textual description or graphical models.There are also some disadvantages,however.These include the cost of developing prototypes， potential erroneous assumptions and unwarranted expectations,and quality problems with low fidelity prototypes.Effective early requirements review and validation can be achieved using the appropriate level of fldelity for prototypes when the purpose of the prototype is well understood.The level of fidelity and build quality should be based on the purpose of the prototype.

原型设计通常用于引出需求、验证系统需求的解释、澄清或检查需求属性，以及找出任何遗漏的需求。原型的优势在于，它们为干系人的评估和输入提供了更丰富的背景，可以更容易地解释假设，并且可以提供关于其错误原因的有用反馈。例如，通过动画或静态原型可以更好地理解用户界面的动态行为，而不仅仅通过文本描述或图形模型。然而，原型设计也有一些缺点。包括开发原型的成本、潜在的错误假设和无根据的期望，以及低保真度原型的质量问题。当原型的目的得到充分理解时，可以使用适当级别的原型进行有效的早期需求评审和确认。保真度水平和构建质量应基于原型设计的目的。

Modelling and simulation can be used to assist the stakeholder vlidation of the requirements.The advantage of modelling and simulations is that they can demonstrate interactions and allow for sensitivity analysis when the results are not what the stakeholder expected.

建模和仿真可用于帮助干系人确定需求。建模和仿真的优势在于，当结果与干系人的预期不符时，它们可以演示交互作用并允许进行敏感性分析。

Conceptual modelling is another technique that can be used.The purpose is to aid understanding of the problem rather than to initiate design of the solution.Hence,conceptual models comprise models of entities from the problem domain configured to reflect their real-world relationships and dependencies.There are several kinds of models that can be developed.These include data and control flows,state models,event traces,user interactions, object models,system context models,and many others.The factors that influence the choice of model include:

概念建模是另一种可用技术。目的是帮助理解问题，而不是开始设计方案。因此，概念模型包括来自问题域的实体模型，模型用于反映实体在真实世界的关系和依赖关系。有几种模型可用。其中包括数据和控制流、状态模型、事件跟踪、用户交互、对象模型、系统上下文模型以及许多其他模型。影响模型选择的因素包括：

-    The nature of the problem: -Some types of application demand that certain aspects be analyzed particularly rigorously.For example,control flow and state models are likely to be more important for real-time systems than for an information system.
问题的性质：-某些类型的应用要求对某些方面进行特别严格的分析。例如，控制流和状态模型对于实时系统可能比对于信息系统更重要。

-    Expertise: - It is often more productive to adopt a modelling notation or method with which the supplier has experience.However,it may be appropriate or necessary to adopt a notation that is better supported by tools,imposed as a process requirement,or simply 'better'.
专业知识：-采用供应商有经验的建模符号或方法通常更有效。然而，采用工具更好支持的符号、作为过程要求强加的符号或简单的“更好”符号可能是适当的或必要的。

-    The process requirements of the acquirer: - Acquirers may impose a particular notation or method.This can conflict with the previous factor.
的流程要求：-需方可采用特定的符号或方法。这可能与前面的因素相冲突。

-    The availability of methods and tools: - Notations or methods that are poorly supported by training and tools may not reach widespread acceptance even if they are better suited to particular types of problem.
方法和工具的可用性：-没有得到培训和工具支持的符号或方法可能无法得到广泛接受，即使它们更适合特定类型的问题。

Formal modelling that uses notations based upon discrete mathematics and that is traceable to logical reasoning has made an impact in some specialized domains.Formal modelling may be imposed by acquirers or standards or may offer compelling advantages to the analysis of certain critical functions or elements.

使用基于离散数学的符号并可追溯到逻辑推理的形式化建模在一些专业领域产生了影响。正式建模可能由收购方或标准实施，也可能为某些关键功能或要素的分析提供令人信服的优势。

3) Demonstrate traceability between the system requirements and the stakeholder requirements.

演示系统需求和涉众需求之间的可跟踪性。

NOTE Maintain mutual traceability between the system requirements and the stakeholder requirements,i.e.all achievable stakeholder requirements are met by one or more system requirements,and all system requirements meet or contribute to meeting at least one stakeholder requirement The system requirements are held in an appropriate data repository that permits traceability to stakeholder needs and architectural design.

注：保持系统需求和干系人需求之间的相互可追溯性，即一个或多个系统需求满足所有可实现的干系人需求，所有系统需求满足或有助于满足至少一个干系人需求。系统需求保存在适当的数据存储库中，允许追溯干系人需求和架构设计。

 (ISO/EC 15288:2008 (IEEE Std 15288-2008),6.4.2.3 b) 3)]

Requirements tracing is concerned with recovering the source of requirements and predicting the effects of requirements.The traceability should include interface requirements.Tracing is fundamental to performing coverage analysis (to ensure that all stakeholder requirements are met in the design and that each low-level requirement is justifed); compliance analysis (to document that stakeholder requirements have been satisfied); and impact analysis when requirements change.A requirement should be traceable:

需求跟踪涉及到复原需求的来源和预测需求的影响。可追溯性应包括接口需求。需求跟踪是执行覆盖率分析的基础（以确保设计满足所有干系人的要求，并确保每个低级别的需求都是合理的）；合规性分析（记录干系人的要求已得到满足）；以及需求变化的影响分析。需求应该是可追踪的：

-    to lower-level requirements (e.g.stakeholder to system to element and ultimately to hardware and software requirements)
追溯到低层次需求（例如，干系人到系统到模块，最终到硬件和软件需求）

-    to architectural design (e.g..logical or physical)
追溯到架构设计（如：逻辑的或物理的）

-    to system elements (e 9.,.software and hardware elements that implement the requirement) to verification/test entities that satisfy it,along with any supporting models and analysis.
追溯到系统各组成部分（例如，实现需求的软件和硬件部件）与满足需求的验证/测试实体以及任何支持模型和分析联系起来

A requirement should also be traceable upwards to the requirements and stakeholders that motivated it (from a software requirement back to the system requirement(s) that it helps satisfy,for example).In the case of requirements derived from trade or design studies,those derived requirements should be traceable back to the study from which they derive,and the study should be traceable back to the high-level requirements by which it was informed.Bi-directional traceability is a technique that can be used to:

需求还应该向上追溯到驱动它的需求和干系人（例如，从软件需求追溯到系统需求）。对于源自交易或设计研究的需求，这些衍生需求应可追溯至其导致其产生的调研活动，且该调研活动也可追溯至促使执行调研活动的高级需求。双向可追溯性是一种技术，可用于：

-    improve the integrity and accuracy of all requirements,from the system level all the way down to the lowest level system element;
提高所有需求的完整性和准确性，从系统级别一直到最低级别的系统组成部分；

-    allow tracking of the requirements development and allocation with related measures such as requirements coverage,compliance,and complexity;
允许跟踪需求的开发和分配，以及相关的度量，如需求覆盖率、合规性和复杂性；

-    provide a means of documenting and reviewing the relationships between layers of requirements that capture certain aspects of the design; and
提供一种记录和审查捕获设计某些方面的需求层之间关系的方法；和

-    support easier maintenance and change implementation of the system in the future.
使得对系统的维护和变更更容易。

4) Maintain throughout the system life cycle the set of system requirements together with the assoclated rationale,decisions and assumptions.

在整个系统生命周期内维护系统需求集以及相关的根本原因、决策和假设。

(ISO/EC 15288:2008 (IEEE Std 15288- 2008),6.4.2.3 b) 4)]

The requirements shall be configuration controlled.The ancillary information recorded along with the requirements may include a summary rationale for each requirement,decisions,assumptions,and a change history,along with the requirements categorization information described in subclause 5.2.8.Once again,use of a requirements management tool facilitates a cumbersome and complex project of maintaining requirements traceability and configuration control.

需求应进行配置控制。随需求一起记录的详细信息包括每个需求、决策、假设的起因，以及需求变更记录，以及子条款5.2.8中描述的需求分类信息。再次强调，使用需求管理工具有助于维护需求可追溯性和管理复杂繁琐的配置控制。

6.4 Requirements engineering activities in other technical processes其他技术过程中的需求工程活动

6.4.1 Requirements in architectural design架构设计要求

The purpose of the Architectural Design Process is to synthesize a solution that satisfies system requirements.

架构设计过程的目的是形成满足系统需求的解决方案。

6.4.1.1 Define the architecture定义架构

This activity consists of the following tasks:

此活动由以下任务组成：

NOTE Task 1) under this activity is not included,as there is no specific guidance related to requirements engineering.

任务1)这项活动不包括在内，因为没有关于需求工程的具体指导。

2) Partition the system functions identified in requirements analysis and allocate them to elements of system architecture.Generate derived requirements as needed for the allocations.

对需求分析中明确的功能进行划分，并将其分配给系统架构的各部分。根据分配的需要生成派生需求。

 (ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.3.3 a) 2)]

An architectural design solution is defined in terms of the requirements for the set of system elements from which the system is configured.It is important to establish and maintain the traceability between requirements and the architectural design,including the system elements and interfaces.Verification and validation criteria for the system elements should be identified and recorded as derived requirements are generated.

体系结构设计方案是根据配置系统的一组系统元素的需求来定义的。建立和维护需求和体系结构设计（包括系统元素和接口）之间的可追溯性非常重要。在生成衍生需求时，应确定并记录系统要素的验证和确认标准。

3) Define and document the interfaces between system elements and at the system boundary with extemal systems.
定义系统各组成部分之间以及与外部系统的接口。

(ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.3.3a) 3)]

Interface requirements should be identifed through appropriate interface specifications such as an Interface Control Document.The interface requirements are incorporated into the architectural design solution.These documents are shared by the programs involved with the interactions between systems.

应通过适当的接口规范（如接口控制文件）确定接口需求。接口需求属于架构设计解决方案的一部分。这些文档由涉及系统间交互的程序共享。

6.4.1.2 Analyze and evaluate the architecture分析和评估体系结构

This activity consists of the following tasks:

此活动由以下任务组成：

NOTE Tasks 1),3),and 4) under this activity are not included,as there is no specific guidance related to requirements engnering.

2) Determine which system requirements are allocated to operators.

确定分配给操作员的系统需求。

NOTE 1 This determination takes account of the context of use factors and considers,as a minimum,the following factors for the most effective,efficient and reliable human-machine interaction:

注1：该决定考虑了使用因素的背景，并至少考虑了最有效、高效和可靠人机交互的以下因素：

i) Limitations of human capabilities;

人员能力的局限性；

ii) Human actions critical to safety and how the consequences of error are addressed
人员严重影响安全的行为，以及如何定位错误及造成的后果；

iii) Integration of human performance into systems and their operation.
将人因绩效整合到系统及其运行中。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.3.3 b) 2)]

NOTE Additional guidance on architectural design can be found in ISO/IEC 15288:2008 (IEEE Std 15288-2008),subclause 6.4.3.Architectural design process.

注：ISO/IEC 15288:2008（IEEE标准15288-2008）第6.4.3款架构设计过程中提供了关于架构设计的其他指南。。

6.4.2 Requirements in verification验证要求

The purpose of the Verification Process is to confirm that the specified design requirements are fullfilled by the system.

验证过程的目的是确认系统已满足规定的设计要求。

NOTE Additional guidance on verification can be found in ISO/IEC 15288:2008 (IEEE Std 15288-2008),subclause 6.4.6,Verification process.

注：ISO/IEC 15288:2008（IEEE标准15288-2008）第6.4.6款“验证过程”中提供了验证的其他指南。

6.4.2.1 Plan verification 验证计划

This activity consists of the following tasks:

此活动由以下任务组成：

NOTE Tasks 1) and 3) under this activity are not included,as there is no specific guldance related to requirements engineering.

2) Define a verification plan based on system requirements.
根据系统需求定义验证方案。

NOTE The plans account for the sequence of configurations defined in the integration strategy and,where appropriate,take account of disassembly strategies for fault diagnosis.The schedule typically defines risk-managed verification steps that progressively build confidence in complance of the fully configured product.

注：计划考虑了集成策略中定义的配置顺序，并在适当情况下考虑了故障诊断的分解策略。该计划通常定义风险管理的验证步骤，逐步建立对完全配置产品满足性的信心。

ISO/EC 15288:2008 (IEEE Std 15288-2008),6.4.6.3 a) 2)]

This activity is facilitated by initially associating a verification method as requirements are created.Verification methods should be documented.Documentation may include requirements verification and traceability matrix or verification statements in a verification plan.A verification method defines how (including success criteria and closure approach),where and when each requirement's compliance will be proven for acquirer acceptance.A verification method is associated with each requirement to define activities that yield objective information to prove satisfaction of the requirement.A good verification method definition addresses some or all of the following content considerations:

在创建需求时将需求与验证方法关联，可以更有效开展这项活动。验证方法要记录在文档中。文档包括需求验证和追溯矩阵或验证计划中的验证声明。验证方法定义了如何（包括成功标准和结束条件）、何时何地证明每项要求的合规性以得到需方的认可。验证方法与每个需求相关，以定义产生客观信息以证明满足需求的活动。好的验证方法定义解决了以下部分或全部内容注意事项：

-    How - Identify which verification method will be applied (see list below)

-方法 - 确定将采用哪种核查方法(见下文清单)

-    Who - Identify the organization/person with the lead responsibility for performing the verfication,such as a contractor,subcontractor,vendor,product team,or supplier
执行人 -确定负责执行验证的组织/人员，如承包商、分包商、供应商、产品团队或供应商。

-    When - Designate a time in the program plan when the verification is to be done.This should be an event-based,and not a calendar date,accomplishment
时间 - 在采办项目计划中指定一个验证时间。这应该是一项基于事件的相对时间，而不是日历日期。

-    Where - Specify any unique venue and environment needed for the verification activity
地点 - 指定验证活动所需的任何独特地点和环境

There are four standard verifcation methods to use to obtain the objective evidence that the requirements have been fulfilled: inspection,analysis or simulation,demonstration,and test.

有四种标准验证方法可用于获得满足需求的客观证据：检查、分析或模拟、演示和测试。

Inspection - an examination of the item against applicable documentation to confirm compliance with requirements.Inspection is used to verify properties best determined by examination and observation (e.g.,-paint colour, weight, etc.).Inspection is generally non-destructive and typically includes the use of sight,hearing,smell,touch,and taste; simple physical manipulation; mechanical and eIECtrical gauging; and measurement.

检查 - 根据文件对检查项进行检查，以确认符合需求。检查用于通过检查和观察确定被检查对象是否是好的（例如，油漆颜色、重量等）。检查通常是非破坏性的，通常包括使用视觉、听觉、嗅觉、触觉和味觉；简单的物理操作；机械和电气测量；和测量。

Good practice: Include identification of the document(s)/drawing(s) to use to make the comparison between what is required versus what is being inspected.

良好实践：使用包括文件/图纸的标识，比较所期望的内容和正在检查的内容是否一致。

Analysis (including modelling and simulation) - use of analytical data or simulations under defined conditions to show theoretical compliance.Used where testing to realistic condtions cannot be achieved or is not cost-effective.Analysis (including simulation) may be used when such means establish that the appropriate requirement,specification,or derived requirement is met by the proposed solution.Analysis may also be based on 'similarity' by reviewing a similar item's prior verification and confirming that its verification status can legitimately be transferred to the present system element.Similarity can only be used if the items are similar in design,manufacture,and use; equivalent or more stringent verifcation specifications were used for the similar system element; and the intended operational environment is identical to or less rigorous then the similar system element.

分析（包括建模和模拟）-在规定条件下使用分析数据或模拟，证明其理论符合性。适用于无法在实际条件下进行测试或者测试成本太高的情形。当此类方法确定拟定解决方案满足适当的需求、规范或衍生需求时，可使用分析（包括模拟）。分析也可以基于“相似性”，通过审查类似物项的先前验证，并确认其验证状态可以合法地转移到当前系统元素。只有当项目在设计、制造和使用方面相似时，才能使用相似性；类似系统元件采用了同等或更严格的验证规范；预期的操作环境与类似的系统元素相同或不那么严格。

Good practice: Identify the generic name of the analysis (like Failure Modes Effects Analysis),analytical/computer tools,and/or numeric methods; the source of input data; and how raw data will be analyzed.Ensure agreement with the acquirer that the analysis methods and tools,including simulations, are acceptable for the provision of objective proof or requirements compliance.

良好实践：良好实践：确定分析（如故障模式影响分析）、分析/计算机工具和/或数值方法的通用名称；输入数据的来源；以及如何分析原始数据。确保与收单机构达成一致，即分析方法和工具（包括模拟）可用于提供客观证据或符合要求。

Demonstration - a qualitative exhibition of functional performance,usually accomplished with no or minimal instrumentation or test equipment.Demonstration uses a set of test activities with system stimuli selected by the supplier to show that system or system element response to stimuli is suitable or to show that operators can perform their allocated functions when using the system. Observations are made and compared with predetermined responses. Demonstration may be appropriate when requirements or specifications are given in statistical terms (e.g.,mean time to repair,average power consumption,etc.).

演示 - 功能性能的定性展示，通常在没有或很少使用仪器或测试设备的情况下完成。演示使用一组由供应商选择的包含测试数据的测试活动，来测试系统或系统组成部分是否对测试活动做出正确响应，或测试操作员在使用系统时可以完成预期的功能。观察系统实际响应并与预定响应进行比较。当以统计术语给出要求或规范时（例如，平均维修时间、平均功耗等），演示这种方法是很适合的。

Good practice: State who the witnesses will be for the purpose of Collecting the evidence of success,what general steps will be followed,and what special resources are needed,such as instrumentation,special test equipment or facilities,simulators,specific data gathering,or rigorous analysis of demonstration results.

良好实践：说明为了收集成功证据，证人将是谁，将遵循哪些一般步骤，以及需要哪些特殊资源，如仪器、特殊测试设备或设施、模拟器、收集特定数据，或对演示结果进行严格分析。

Test - an action by which the operability,supportability,or performance capability of an item is quantitatively verified when subjected to controlled conditions that are real or simulated.These verifications often use special test equipment or instrumentation to obtain very accurate quantitative data for analysis.

测试-在真实或模拟的受控条件下，对项目的可操作性、可保障性或性能进行定量验证的活动。这些验证通常使用特殊的测试设备或仪器来获得非常准确的定量数据进行分析。

Good practice: State who the witnesses will be for the purpose of Collecting the evidence of success.Identify the test faciity,test equipment,any unique resource needs and environmental conditions,required qulficatins and test personnel,general steps that will be fllowed,specific data to be colected,criteria for repeatability of Collected data,and methods for analyzing the results.

良好做法：说明证人将是谁，以便收集成功的证据。确定试验设施、试验设备、任何独特的资源需求和环境条件、所需的质量指标和试验人员、将要采取的一般步骤、收集的具体数据、收集数据的重复性标准以及分析结果的方法。

NOTE Certification is often included as a fifth method of verification. Certification is a written assurance that the system or system element has been developed in accordance with the required standard,and meets the requirements. This assures that the system or system element can perform its asigned functions to a negotiated standard.The development reviews and system venfication and validation results form the basis for cerification.Certifcation is generally performed by a third party against an accepted standard.

注：认证通常包括在第五种验证方法中。认证是系统或系统部件已按照所需标准开发并满足要求的书面保证。这确保了系统或系统组成部分可以按照预定的标准执行其功能。开发评审、系统验证和确认结果构成认证的基础。认证通常由第三方根据公认标准进行。

This information is included and documented in an updated Requirements Traceability Matrix (RTM).

该信息包含并记录在更新的需求追溯矩阵（RTM）中。

6.4.2.2 Perform verification执行验证

This activity consists of the following tasks:

活动包括以下任务：

NOTE Tasks 1),3),and 4) under this activity are not included,as there is no specific guidance related to requirements engineering.

注：本活动下的任务1）、3）和4）不包括在内，因为没有与需求工程相关的具体指导

2) Conduct veification to demonstrate compliance to the specifed design requirements.

进行验证以证明符合规定的设计要求。

NOTE Non-compliance identifies the existence of random faults and/or design errors,and corrective actions are initiated as appropriate.Verification is undertaken in a manner,consistent with organizational constraints.such that uncertainty in the replication of verification actions,conditions and outcomes is minimized.Approved records of verification actions and outcomes are made.

注：不合规性表明存在随机故障或设计错误，并采取适当纠正措施。核查是以符合组织要求的方式进行的。这样，在复制核查行动、条件和结果时的不确定性被最小化。对验证行动和结果进行批准记录。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.6.3 b) 2)]

Requirements Traceabilty is frequently used as a single point of accountability for tracing a requirement back to the source of the requirement and forward through the life cycle to assess that the requirement has been met.In requirements tracebility,verfication methods and information are associated with the requirements to indicate how the system or system element will be verified to show it meets the requirements.As the system moves through the life cycle phases,traceabilty of the requirements to the work products should be added.It is important to include unique identifiers for each requirement.

需求可追溯性经常被单独进行考量，用于将需求追溯到需求的来源，以评估需求是否得到满足。在需求可追溯性中，验证方法和信息与需求相关联，以表明如何验证系统或系统组件，以证明其满足需求。系统在整个生命周期中，应保证对工作产品需求的可追溯性。为每个需求指定唯一标识符非常重要。

6.4.3 Requirements in validation审定方面的要求

The purpose of the Validation Process is to provide objective evidence that the services provided by a system when in use comply with stakeholders' requirements,achieving its intended use in its intended operational environment.

验证过程的目的是提供客观证据，证明系统提供的服务符合干系人的要求，从而在其预期运行环境中实现其预期用途。

6.4.3.1 Plan validation验证计划

This activity consists of the following task:

这项活动包括以下任务：

NOTE Task 1) under this activity is not included,as there is no specific guidance related to requirements engineering.

注 任务1)这项活动不包括在内，因为没有关于需求工程的具体指导。

2) Prepare a validation plan.

制定验证计划。

NOTE Validation is based on the stakeholder requirements.Where appropriate, define validation steps,e.g.,various operational states,scenarios and missions that progressively build confidence in the conformance of the installed system and assist diagnosis of any discrepancies.Methods and techniques needed to implement the validation strategy are specified,as are the purpose,conditions,and conformance criteria for each validation.Where stakeholder requirements cannot be specified comprehensively or change frequently,repeated validation of (often rapidly developed) increments in system evolution may be employed to refine stakeholder requirements and mitigate risks in the correct identification of need,e.g.,ISO 13407 describes an iterative life cycle that involves users.

注：验证基于干系人需求。在适当的情况下，定义验证步骤，例如各种运行状态、场景和任务，逐步验证系统符合预定的设计要求，并有助于发现任何问题。规定了实施验证策略所需的方法和技术，以及每次验证的目的、条件和一致性标准。当干系人需求难以准确定义或频繁变更时，系统演化过程中（通常很快）增量的重复验证可用于细化干系人需求，并在正确识别需求时降低风险，例如，ISO 13407描述了涉及用户的迭代生命周期。

ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.8.3a) 2)]

The system operational concept and baselined stakeholder requirements are inputs to the validation plan activity.

系统运行概念和基线干系人需求是验证计划活动的输入。

6.4.3.2 Perform validation执行验证

This activity consists of the following task:

这项活动包括以下任务：

NOTE Tasks 1),3),4),and 5) under this activity are not included,as there is no specific guidance related to Tasks 1),3),4),and 5) under this activity are not included,as there is no specific guidance related to requirements engineering.

注：本活动下的任务1）、3）、4）和5）不包括在内，因为没有与本活动下的任务1）、3）、4）和5）相关的具体指导，因为没有与需求工程相关的具体指导。

2) Conduct validation to demonstrate conformance of services to stakeholder requirements.

进行验证，以证明服务符合干系人需求。

NOTE Validation is undertaken in a manner,consistent with organizational constraints,such that uncertainty in the replication of validation actions,conditions and outcomes is minimized.Objectively record and approve validation actions and results.Validation may also be conducted to confrm that the system not only satisfies all operational,functional and usability requirements,but also satisfies the often less formally expressed,but sometimes overriding,attitudes,experience and subjective tests that comprise customer satisfaction.

注：验证是以符合组织约束的方式进行的，以使验证行动、条件和结果的重复的不确定性最小化。客观地记录和批准验证活动和结果。还可以通过验证，以确认系统不仅满足所有操作、功能和可用性要求，还满足一些虽然没有正式定义、但是要求比较迫切的系统行为、体验等主管要求，这些属性的测试结果，构成了客户满意度。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.4.8.3 b) 2)]

Requirements validation is subject to approval by the project authority and key stakeholders.This process is invoked during the Stakeholders Requirements Definition Process to confirm that the requirements properly reflect the stakeholder needs and to establish validation criteria,i.e.that we have the right requirements.System validation confirms that the system,as built,satisfies stakeholder stated needs and requirements,that it is the right system. Requirements traceability should be maintained,and may be documented in a Requirements Traceability Matrix (RTM).

需求验证须经项目管理部门和关键干系人批准。在干系人需求定义过程中执行此过程，以确认需求正确反映了干系人需求，同时建立验证标准，这意味着我们获得了正确的需求。系统验证确认要实现的系统满足干系人规定的需求和要求，是正确的系统。应保持需求可追溯性，并将需求记录在需求追溯矩阵（RTM）中。

NOTE 1 Additional guidance on validation can be found in ISO/IEC 15288:2008 (IEEE Std 15288 -2008),subclause 6.4.8,Validation process.

注1：ISO/IEC 15288:2008（IEEE标准15288-2008）第6.4.8款“验证过程”中提供了关于验证的其他指南。

NOTE 2 Additional guidance on validating usability requirements can be found in ISO/IEC 25060 and ISO/IEC 25062.

注2：ISO/IEC 25060和ISO/IEC 25062中提供了验证可用性要求的附加指南。

6.5 Requirements management 需求管理

6.5.1 Management Overview需求管理概述

Requirements management encompasses those tasks that record and maintain the evolving requirements and associated context and historical information from the requirements engineering activities.Requirements management also establishes procedures for defining,controlling,and  publishing the baseline requirements for all levels of the system-of-interest.Effective requirements management occurs within the context of an for all levels of the system-of-interest.Effective requirements management occurs within the context of an organization's project and technical processes as defined in ISO/IEC 15288 and ISO/IEC 12207.

需求管理包括记录和维护持续变化的需求、记录需求工程活动的相关信息。需求管理还建立了定义、控制和发布目标系统所有级别的基线需求的过程。需求管理贯穿在系统生命周期的各个层级和阶段。需求管理参见在ISO/IEC 15288和ISO/IEC 12207中定义的项目和技术过程。

Requirements are rarely static.Although from the development management perspective,it is desirable to freeze a set of requirements permanently,it is rarely possible.Requirements that are likely to evolve should be identifed and communicated to both acquirers and the technical community.A core subset of requirements may be frozen early.The impact of proposed new requirements be evaluated to ensure that the initial intent of the requirements baseline is maintained or that changes to the intent are understood and accepted by the the requirements baseline is maintained or that changes to the intent are understood and accepted by the acquirer.

需求很少是静态的。尽管从开发管理的角度来看，希望能永久冻结需求，但这几乎是不可能的。应确定可能会发生变化的需求，并将其传达给需方和技术团队。核心需求可能会尽早冻结。有新需求时，应对其影响进行评估，以确保不影响需求基线或影响在可接受范围之内，对需求基线的影响，需得到需方的理解和认可。

In almost all cases,requirements understanding continues to evolve as life cycle activities proceed.This often leads to the revision of requirements late in the life cycle.Perhaps the most crucial point of understanding leads to the revision of requirements late in the life cycle.Perhaps the most crucial point of understanding about requirements engineering is that a significant proportion of the requirements will change.This is sometimes due to errors in the analysis,but it is frequently an inevitable consequence of change in the environment,such as changes in the acquirer's operating or business environment,or in the market into which the system is sold.

大多情况下，对需求的理解都会随着生命周期活动的进行而不断加深。这通常会导致在生命周期后期修改需求。需要特别关注生命周期后期的需求变更。需求工程最关键的一点是，大部分将发生变化。需求变更有时是由于分析中的错误造成的，但更多的是环境变化的必然结果，如需方的运营和业务环境、销售市场的变化。

However,care should be exercised in making requirements changes during the life cycle.While some may be unavoidable,excessive uncontrolled changes can result in 'requirements creep' that can result in cost overruns,schedule delays,design errors,buyer dissatisfaction,or even cancellation of the project.

但是，在生命周期中进行需求变更时应谨慎。尽管某些变更可能不可避免，但过度的不受控变更可能导致“需求蔓延”，从而导致成本超支、进度延误、设计错误、买方不满，甚至取消项目。

6.5.2 Change management变更管理

Whatever the cause of requirements changes,it is important to recognize the inevitability of change and adopt measures to mitigate the effects of change.Change has to be managed by ensuring that proposed changes go through a defined impact assessment,review,and approval process,and by applying careful requirements tracing and version management.Hence,the requirements engineering process is not merely a front end task,but spans the life cycle.In a typical project the activities of the requirements management evolve over time from elicitation to change management.

无论需求变更的原因是什么，都必须认识到变更的必然性，并采取措施降低变更的影响。通过执行对变更进行影响评估、审查和批准流程，并使用需求跟踪和版本管理来管理变更。因此，需求工程过程不仅限于项目前期，而是贯穿整个生命周期。在一个典型的项目中，需求管理的活动会随着时间的推移而演变，从启发引导需求直到变更管理。

Commonly used baselines are the functional,allocated,developmental,and product baselines.The baselines to be used for a given project,along with their associated levels of authority needed for change approval,are typically identified in the project's configuration management plan.These baselines are described as follows:

常用的基线包括功能基线、分配基线、开发基线和产品基线。通常在项目配置管理计划中定义项目使用的基线以及变更批准所需的相关权限。这些基线定义如下：

-     Functional baseline corresponds to the reviewed system requirements, including the external interface descriptions.
功能基线对应于已评审的系统需求，包括外部接口定义。

-     Allocated baseline corresponds to the reviewed system element requirements specifications including the interface requirements specification.
分配的基线对应于经评审的系统要素需求规范，包括接口需求规范。（译者：将系统需求分配到系统元素）

-     Developmental baseline represents the evolving system and system element configurations at selected times during the life cycle.Change authority for this baseline typically rests primarily with the supplier organization.
开发基线表示生命周期中特定时间内不断演变的系统和系统要素配置。此基线的变更权限通常主要由供应商组织负责（译者：开发时间计划？）。

-     Product baseline corresponds to the completed system.
产品基线对应于已完成的系统

6.5.2.1 Configuration management 配置管理

The purpose of the Configuration Management Process is to establish and maintain the integrity of all identified outputs of a project or process and make them available to concerned parties.

配置管理过程的目的是建立和维护项目或过程所有已识别输出的完整性，并将其提供给相关方。

6.5.2.1.1 Plan configuration management 计划配置管理

This activity consists of the following task:

该活动由以下任务组成：

NOTE Task 1) under this activity is not included,as there is no specific guidance related to requirements engineering.

任务1)这项活动不包括在内，因为没有关于需求工程的具体指导。

2) Identify items that are subject to configuration control.

识别受配置控制的物品。

NOTE Items are distinguished by unique,durable identifers or markings,where appropriate.The identifiers are in accordance with relevant standards and product sector conventions,such that the items under configuration control are unambiguously traceable to their specifcations or equivalent,documented descriptions.

注：项目通过唯一不变的标识或标记进行区分。标识符符合相关标准和行业惯例，因此，配置控制下的项目可明确追溯至其规范或同等文档化的描述。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.3.5.3a) 2)]

The system operational concept and stakeholder,system,and system element requirements are identified as information items for configuration control in the configuration management planning.

系统运行概念和干系人、系统和系统要素需求被确定为配置管理规划中配置控制的信息项。

6.5.2.1.2 Perform configuration management执行配置管理

This activity consists of the following task:

这项活动包括以下任务：

1) Maintain information on configurations with an appropriate level of integrity and security.

以适当的完整性和安全性水平维护有关配置的信息。

NOTE This includes taking into account the nature of the items under configuration control.Configuration descriptions conform,where possible,to product or technology standards.Ensure that configuration information permits forward and backward traceability to other baselined configuration states.Consolidate the evolving configuration states of configuration items to form documented baselines at designated times or under defined circumstances.Record the rationale for the baseline and associated authorizations in configuration baseline data.Maintain configuration records through the system life cycle and archive them according to agreements,relevant legislation or best industry practice.

注：这包括考虑配置控制项的性质。配置说明尽可能符合产品或技术标准。确保配置信息允许向前和向后跟踪到其他基线配置状态。在指定的时间或定义的条件下，整合配置项的不断变化的配置状态，以形成文档化的基线。在配置基线数据中记录基线和相关授权的根本原因。在整个系统生命周期内维护配置记录，并根据协议、相关法规或最佳行业实践对其进行归档。

2) Ensure that changes to configuration baselines are properly identified, recorded,evaluated,approved,incorporated,and verified.

确保正确识别、记录、评估、批准、合并和验证配置基线的变更。

NOTE Consolidate the evolving configuration states of configuration items to form documented baselines at designated times or under defined circumstances.Record the steps of configuration,the rationale for the baseline and associated authorizations in configuration baseline data.Maintain configuration records through the system life cycle and archive them according to agreements,relevant legislation or best industry practice.Manage the recording,retrieval and consolidation of the current configuration status and the status of all preceding configurations to confirm information correctness,timeliness,integrity and security.Perform audits to verify conformance of a baseline to drawings,interface control documents and other agreement requirements.

注：在指定的时间或规定的情况下，整合配置项的不断变化的配置状态，以形成文档化的基线。在配置基线数据中记录配置步骤、基线基本原理和相关授权。在整个系统生命周期内维护配置记录，并根据协议、相关法规或最佳行业实践对其进行归档。管理当前配置状态和历史配置状态的记录、检索和合并，以确认信息的正确性、及时性、完整性和安全性。进行审核，以验证基线是否符合图纸、接口控制文件和其他协议要求。

[ISO/EC 15288:2008 (IEEE Std 15288-2008),6.3.5.3 b)]

As changes are made to the operational concepts and stakeholder,system and system element requirements,the changes need to be formally captured and in documented baselines of the requirements along with the configuration information that identifies the specific changes and associated rationale. Requirements traceability should be maintained,and may be documented in a Requirements Traceability Matrix (RTM).

当对运行概念和干系人、系统和系统要素需求进行变更时，需要正式获得变更，并将其记录在需求基线中，以及识别特定变更和变更原因的配置信息中。应保持需求可追溯性，并可记录在需求追溯矩阵（RTM）中。

Requirements shall be configuration managed,in accordance with project and organization configuration management processes.

需求应按照项目和组织配置管理流程进行配置管理。

NOTE Subclause 6.3.5 of both ISO/IEC 15288 and ISO/IEC 12207 has additional information on configuration management.

注：ISO/IEC 15288和ISO/IEC 12207的第6.3.5款都有关于配置管理的附加信息。

6.5.2.2 Information management 信息管理

The purpose of the Information Management Process is to provide relevant, timely, complete,valid and,if required,confidential information to designated parties during and,as appropriate,after the system life cycle.

信息管理过程的目的是在系统生命周期期间和之后（视情况而定），向指定方提供相关的、及时的、完整的、有效的和保密（如果需要）的信息。

6.5.2.2.1 Plan information management计划信息管理

This activity consists of the following task:

该活动由以下任务组成：

NOTE Tasks 2) through 5) under this activity are not included,as there is no specifc guidance related to requirements engineering.

注：本活动下的任务2）至5）不包括在内，因为没有与需求工程相关的具体指南。

1) Define the items of information that will be managed during the system life cycle and,according to organizational policy,agreements,or legislation, maintained for a defined period beyond.

定义系统生命周期内需要管理的信息项，并根据组织政策、协议或法规，在系统生命周期后的规定期限内进行维护。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.3.6.3 a) 1)]

The system operational concept document and stakeholder requirements specification,system requirements specification,software requirements specification,and other system element requirements specifications are identified as information items to be managed during the system life cycle.

系统运行概念文件和干系人需求规范、系统需求规范、软件需求规范和其他系统要素需求规范被确定为系统生命周期中需要管理的信息项。

6.5.2.2.2 Perform information management执行信息管理

This activity consists of the following task:

该活动由以下任务组成：

NOTE Tasks 2) through 6) under this activity are not included,as there is no specifc guidance related to requirements engineering.

注：本活动下的任务2）至6）不包括在内，因为没有与需求工程相关的具体指南。

1) Obtain the identifed items of information.

获取识别的信息项。

NOTE This may include generating the information or clIECting it from appropriate sources.

注：这可能包括生成信息或从适当来源剪切信息。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.3.6.3 b) 1)]

As the operational concept document and various requirements specifications are created reflecting the configuration baselines,the information items are provided to the designated authorities and responsibilities for information management.As the requirements are changed and new baselines are created,the revised information items are provided for information management.

在创建反映配置基线的运行概念文件和各种需求规范时，将信息项提供给指定的机构和责任人。随着需求的更改和新基线的创建，修订后的信息项将提供给责任人。

The requirements information shall be managed in accordance with the organization's information management process.

需求信息应按照组织的信息管理流程进行管理。

NOTE Subclause 6.3.6 of both ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008(IEEE Std 12207-2008) has additional detail on information management.

注：ISO/IEC 15288:2008（IEEE标准15288-2008）和ISO/IEC 12207:2008（IEEE标准12207-2008）的第6.3.6款都有关于信息管理的附加细节。

6.5.3 Measurement for requirements需求计量

The purpose of the Measurement Process is to collect,analyze,and report data relating to the products developed and processes implemented within the organization,to support effective management of the processes,and to objectively demonstrate the quality of the products.

测量过程的目的是收集、分析和报告与组织内开发的产品和实施的过程相关的数据，以支持过程的有效管理，并客观地证明产品的质量。

6.5.3.1 Plan measurement测量计划

This activity consists of the following task:

这项活动包括以下任务：

NOTE Tasks 5) through 7) under this activity are not included,as there is no specific guidance related to requirements engineering.

注：本活动下的任务5）至7）不包括在内，因为没有与需求工程相关的具体指导。

1)   Describe the characteristics of the organization that are relevant to measurement.
描述与测量相关的组织特征。

2)   Identify and prioritize the information needs.

确定信息需求并确定其优先级

3)   Select and document measures that satisfy the information needs.

3)选择和记录满足信息需求的措施。

4)   Define data collection,analysis,and reporting procedures.

4)定义数据收集、分析和报告程序。

ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.3.7.3 a) 1) through 4]

Requirements engineering as a discipline benefits from measuring requirements in both the process and product contexts.More than one measure may be needed to provide the insight into the information needs for the requirements.Practice has consistently proven various useful measures,including:

需求工程作为一门学科，得益于对过程和产品环境中的需求进行度量。可能需要一个以上的度量来洞察需求的信息需求。实践证明有多种有效的措施，包括：

-     Requirements volatility - In the process context,requirements volatility can indicate an organization's requirements engineering process will not converge a collection of requirements into a well-formed set.In the product context,a high volatility value can indicate risk early by stakeholders failing to reach consensus on system requirements,putting significant risk on subsequent activities in the life cycle.

需求波动性—在过程上下文中，需求波动性表示组织的需求工程过程不会将一组需求聚合到一个结构良好的集合中。在产品环境中，高波动性值可能表明干系人未能就系统需求达成一致意见而导致早期风险，从而给生命周期中的后续活动带来重大风险。

Other useful requirements measures include:

其他有用的需求措施包括：

-     Requirements trends

-需求趋势

-     Requirements change rate and backlog

-需求变动率和积压

-     Requirements verification

-需求验证

-     Requirements validation and

-要求确认和

-     TBD and TBR closure progress per plan.

-每个计划的TBD和TBR关闭进度。

Software requirements are used in software Functional Size Measurement (FSM) methods to assist with many aspects of managing software projects.FSM methods are organized into two parts: uses for project management and uses for forecasting and performance management.If FSM methods are to provide high-fidelity results,it is very important to achieve an accurate and complete allocation and derivation of a system's software requirements from the system requirements.

软件需求用于软件功能大小度量（FSM）方法，对管理软件项目的许多方面都有用处。FSM方法分为两部分：用于项目管理和用于预测和绩效管理。如果FSM方法要提供准确的结果，那么从系统需求中准确、完整地分配和推导系统的软件需求是非常重要的。

NOTE 1 ISO/IEC 14143-1 provides details of FSM concepts and their uses.

注1：ISO/IEC 14143-1提供了FSM概念及其用途的详细信息.

NOTE2 Subclause 6.3.7 of both ISO/IEC 15288:2008 (IEEE Std 15288-2008) and ISO/IEC 12207:2008 (IEEE Std 12207- 2008) provides additional information on measurement process,as does ISO/IEC 15939.

注2 ISO/IEC 15288:2008（IEEE标准15288-2008）和ISO/IEC 12207:2008（IEEE标准12207-2008）的第6.3.7款提供了有关测量过程的附加信息，ISO/IEC 15939也提供了相关信息。

6.5.3.2 Perform measurement执行测量

This activity consists of the following task:

这项活动包括以下任务：

1) Integrate procedures for data generation,collection,analysis and reporting into the relevant processes.

将数据生成、收集、分析和报告程过程合到相关流程中。

2) Collect,store,and verify data.

收集、存储和验证数据。

3) Analyze data and develop information products.

分析数据，开发信息产品。

4) Document and communicate results to the measurement users.

记录测量结果，并将结果传达给测量用户。

[ISO/IEC 15288:2008 (IEEE Std 15288-2008),6.3.7.3 b)]

It is good practice to choose measures for which data are readily available through the life cycle.The data collection can then be integrated into the requirements related processes to obtain the data and insight on a regular basis as the requirements engineering proceeds.It is also good practice to review the analyzed requirements related measures collectively,looking for predictive trends and projections that can aid risk management.

选择在整个生命周期内数据随时可用的度量标准是一种良好的做法。然后，可以将数据收集集成到与需求相关的过程中，以便在需求工程进行时定期获得数据和洞察力。集体审查与所分析的需求相关的度量也是一种良好的做法，以发现有助于风险管理的预测趋势和推断。

The requirements measurement shall be managed in accordance with the organization's measurement process.

需求测量应按照组织的测量过程进行管理。

7 Information items信息项

The project shall produce the following information items as part of the requirements engineering processes:

作为需求工程过程的一部分，项目应产生以下信息项：

- Stakeholder requirements specification document (StRS)

干系人需求规格文件(StRS)

- System requirements specification document (SyRS)

系统需求规范文档(SyRS)

- Software requirements specification document (SRS),if adhering to ISO/IEC 12207.

软件需求规范文件(SRS)，如果遵守ISO/IEC 12207。

The information items shall contain the content as defined in Clause 9 of this International Standard.

信息项目应包含本标准第9条规定的内容。

NOTE 1 Multiple specification documents for each of the three document types may be produced in the project as discussed in subclause 5.4.For example the SyRS may be produced for systems and system elements.

注1：如第5.4款所述，项目中可针对三种文件类型中的每种类型编制多份规范文件。例如，可以为系统和系统元素生成SyRS。

NOTE 2 The three specification documents,StRS,SyRS and SRS may contain similar information items that could be considered as different views for the same product.For ease of use,this standard presents typical contents of the three forms of the specification separately.

注2：三份规范文件（STR、SYR和SRS）可能包含类似的信息项，这些信息项可视为同一产品的不同视图。为便于使用，本标准分别介绍了规范三种形式的典型内容。

NOTE 3 ISO/IEC/IEEE 15289 provides guidance on identifying and planning the specifc information items to be produced during systems and software life cycles.

注3 ISO/IEC/IEEE 15289提供了识别和规划系统和软件生命周期期间产生的特定信息项的指南。

The management of information items shall be performed by applying the Information Management process of ISO/IEC 12207:2008 (IEEE Std 12207 -2008) and ISO/IEC 15288:2008 (IEEE Std 15288-2008),and the Documentation Management process of ISO/IEC 12207:2008 (IEEE Std 12207- 2008)，including the knowledge management activities of ISO/IEC 15288:2008 (IEEE Std 15288-2008),subclause 6.2.4.

信息项的管理应采用ISO/IEC 12207:2008（IEEE标准12207-2008）和ISO/IEC 15288:2008（IEEE标准15288-2008）规定的信息管理流程，以及ISO/IEC 12207:2008（IEEE标准12207-2008）的文件管理流程，包括ISO/IEC 15288:2008（IEEE标准15288-2008）第6.2.4款的知识管理活动。

The information items do not require physical documentation,so long as required content is easily available and logically organized.

信息项不需要物理文档，只要所需的内容易于获得且组织合理即可。

EXAMPLE   Model-Driven Development (MDD) approaches maintain almost all system information in a modelling tool.In this case,the information is contextually stored in the modelling tool's repository.The required information can be viewed in the model or extracted in report or table formats.

示例:模型驱动开发（MDD）方法在建模工具中维护几乎所有的系统信息。在这种情况下，信息按上下文存储在建模工具的存储库中。所需信息可以在模型中查看，也可以以报告或表格格式提取。

8 Guidelines for information items项信息项目准则

8.1 Requirements information item outlines需求信息项目概述

This clause also provides recommended formats in the form of an outline for the resulting documents.

该条款还以结果文档大纲的形式提供推荐格式。

8.2 Stakeholder requirements specification document干系人需求规格文件

8.2.1 Introduction导言

The Stakeholder Requirements Specifcation (StRS) describes the organization's motivation for why the system is being developed or changed,defines processes and policies/rules under which the system is used and documents the top level requirements from the stakeholder perspective including needs of users/operators/maintainers as derived from the context of use.In a business environment,the StRS describes how the organization is pursuing new business or changing the current business in order to fit a new business environment,and how to utilize the system as a means to contribute to the business.The description includes,at the organization level; the organizational environment,goals and objectives,the business model,and the information environment,and,at the business operation level; the business operation model,business operation modes,business operational quality,organizational formation,and concept of the proposed system.

干系人需求规范（StRS）描述了组织开发或修改系统的动机，定义使用系统所依据的流程和政策/规则，并从干系人的角度记录顶层需求，包括用户/操作员/维护人员的需求，这些需求源自使用环境。在业务环境中，StRS描述了组织如何寻求新业务或改变当前业务以适应新的业务环境，以及如何利用系统为业务做出贡献。描述包括，在组织层面；组织环境、目标和目的、业务模式和信息环境，以及在业务运营层面；拟议系统的业务运营模式、业务运营模式、业务运营质量、组织形式和理念。

The information items of the StRS should be specifed by the stakeholders.The stakeholders should be responsible for the content of the specification.The StRS serves as the basis of the stakeholders' active participation in the requirement processes.Typical types of stakeholder requirements included in the StRS are organizational requirements,business requirements,and user requirements.

StRS的信息项应由干系人指定。干系人应对规范的内容负责。StRS是干系人积极参与需求过程的基础。StRS中包含的干系人需求的典型类型是组织需求、业务需求和用户需求。

NOTE 1 ISO/IEC/IEEE 15289 provides guidance to include business,organizational,and user (stakeholder) requirements in the system requirements specfication.This Intemational Standard includes these requirements in the StRS since the contents should be specified from the stakeholders' perspective.They may be succeeded in the SyRS by addressing technical concerns.

注1 ISO/IEC/IEEE 15289提供了将业务、组织和用户（干系人）需求纳入系统需求规范的指南。本标准将这些要求包括StRS 中，因为内容应从干系人的角度进行规定。通过解决技术问题，他们可能会在SyRS中取得成功。

NOTE 2 The StRS is often identified with the business requirement specifcation (BRS) in many industries.Users of this International Standard may replace StRS with BRS according to the users' environment.

注2在许多行业中，StRS通常与业务需求规范（BRS）一起标识。根据用户环境，本标准的用户可使用BRS替换StRS。

NOTE 3 The stakeholder requirements and business requirements are distinguished in The Guide to the Business Analysis Body of Knowledge (BABOK) as fllows: Business Requirements are high-level statements of the goal,objectives,or needs of the enterprise.They describe why a project is initated,what the project will achieve,and which metrics will be used to measure the project's success.Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders.They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution.Stakeholder Requirements serves as a bridge between Business Requirements and the various classes of solution requirements.

注3《业务分析知识体系指南》（BABOK）将干系人需求和业务需求分为以下内容：业务需求是企业目标、目的或需求的高级陈述。它们描述了项目启动的原因、项目将实现什么以及将使用哪些指标来衡量项目的成功。干系人需求是对特定干系人或干系人阶层需求的陈述。它们描述了干系人的要求以及干系人将如何与解决方案交互。干系人需求是业务需求和各种解决方案需求之间的桥梁。

8.2.2 StRS example outline StRS报告示例大纲

The specific requirements clause of the StRS should be organized such that a consensus of the stakeholders agrees that the organization method aids understanding of the requirements.There is no one optimal organization for all projects.An example outline of a StRS created in an organizational/business context is shown in Figure 6.

应按层级结构组织StRS的具体信息项，以使干系人一致同意这种组织方式有助于理解要求。对于所有项目，没有一个最优的组织方式。图6显示了在组织/业务上下文中创建的StRS的示例概要。

8.3 System requirements specification document系统需求规格文件

8.3.1 Introduction导言

The System Requirements Specification (SyRS) identifes the technical specifications for the selected system-of-interest and usability for the envisaged human-system interaction.It defines the high-level system requirements from the domain perspective,along with background information about the overall objectives for the system,its target environment and a statement of the constraints,assumptions and non-functional the system,its target environment and a statement of the constraints,assumptions and non-functional requirements.It may include conceptual models designed to ilustrate the system context,usage scenarios,the principal domain entities,data,information and workflows.

系统需求规范（SyRS）确定了系统的技术规范，以及期望的人-系统交互的可用性。它从领域角度定义了高级系统需求，以及有关系统总体目标、目标环境的背景信息，以及系统的约束、假设和非功能性声明、目标环境和约束声明，假设和非功能性需求。它可能包括用于说明系统上下文、使用场景、主要领域实体、数据、信息和工作流的概念模型。

The purpose of the SyRS is to provide a description of what the system should do,in terms of the system's interactions or interfaces with its external environment.The SyRS should completely describe all inputs,outputs,and required relationships between inputs and outputs.A SyRS has traditionally been viewed as a document that communicates the requirements of the acquirer to the technical community who will specify and build the system.The collection of requirements that constitutes the specification and its representation acts as the bridge between the two groups and needs to be understandable by both the acquirer and the technical community.One of the most difficult tasks in the creation of a system is that of communicating to all of the subgroups within both groups,especially in one document.This type of communication generally requires different formalisms and languages.

SyRS的目的是根据系统与其外部环境的交互或接口，描述系统应该做什么。SyRS应完整描述所有输入、输出以及输入和输出之间的关系。传统上，SyRS被视为将需方的要求传达给将指定和构建系统的技术团队的文件。本规范内的需求集合起到了两个群体之间的桥梁作用，需要被需方和技术团队理解。创建系统中最困难的任务之一是与两个组中的所有子组进行通信，尤其是在一个文档中。这种类型的交流通常需要不同的形式和语言。

This International Standard suggests a distinction between this structured collection of information and the way in which it is presented to its various audiences.The presentation of the SyRS should take a form that is appropriate for its intended use.This can be a paper document,models,prototypes,other non-paper document representations,or any combination.All of these representations can be derived from this one SyRS to meet the needs of a specific audience.However,care should be taken to ensure that each of these presentations is traceable to a common source of system requirements information.The audience should be made aware that this structured collection of information remains the one definitive source for resolving ambiguities in the particular presentation chosen.

本标准建议区分这种结构化信息集和向不同受众呈现信息的方式。SyRS的呈现形式应适合其预期用途。这可以是纸面文档、模型、原型、其他非纸面文档表示或任何组合。所有这些表述形式都可以从这个SyRS中派生出来，以满足特定受众的需求。但是，应注意确保这些演示文稿中的每一个都可追溯到系统需求信息的共同来源。观众应该意识到，这种结构化的信息集仍然是解决所选特定演示文稿中歧义的一个确定来源。

This International Standard also makes a clear distinction between the system requirements (what the system shall do) contained in the SyRS and process requirements (how to construct the system) that should be contained in contract documents such as a Statement of Work.

本标准还明确区分了SyRS中包含的系统要求（系统应做什么）和合同文件（如工作说明书）中应包含的过程要求（如何构建系统）。

The SyRS presents the results of the definition of need,the system operational concept,and the system requirements analysis tasks.As such,it is a description of what the system's acquirers expect it to do for them,the system's expected environment,the system's usage profile,performance parameters,expected quality and effectiveness,and verification activities.

SyRS提供了需求定义、系统操作概念和系统需求分析任务的结果。因此，它描述了系统的需方希望它为他们做什么，系统的预期环境，系统的使用概况，性能参数，预期质量和有效性，以及验证活动。

8.3.2 SyRS example outline SyRS示例大纲

The specific requirements section of a SyRS should be organized such that a consensus of the stakeholders agrees that the organization method aids understanding of the requirements.There is no one optimal organization for all projects.An example outline of a SyRS is shown in Figure 7.

应合理组织SyRS的特定需求部分的结构，以便干系人一致同意按这种结构组织内容更有助于理解需求。对于所有项目，没有一个最优的组织结构。图7显示了SyRS的示例结构。

NOTE This SyRS outline can be used,with tailoring,for subordinate specifications for system elements,even those that include software.

注：本SyRS大纲可用于系统元素的次级规范，甚至包括软件。

8.4 Software requirements specification document软件需求规范文档

8.4.1 Introduction导言

The software requirements specification (SRS) is a specification for a particular software product,program,or set of programs that performs certain functions in a specific environment.The SRS may be witten by one or more representatives of the supplier,one or more representatives of the acquirer,or by both.

软件需求规范（SRS）是在特定环境中执行特定功能的特定软件产品、程序或程序集的规范。SRS可由供应商代表和需方代表共同发出。

lt is important to consider the part that the SRS plays in the total project plan. The software may contain essentially all the functionality of the project or it may be part of a larger system. In the latter case typically there will be a requirement specification that will state the interfaces between the system and its software portion，and will place external performance and functionality requirements upon the software portion. Of course the SRS should then agree with and expand upon these system requirements. The SRS indicates the precedence and criticality of requirements. The SRS defines all of the required capabilities of the specified software product to which it applies, as well as documenting the conditions and constraints under which the software has to perform, and the intended verification approaches for the requirements.

重要的是要考虑SRS在整个项目计划中所起的作用。软件可能基本上包含项目的所有功能，也可能是更大系统的一部分。在后一种情况下，通常会有一个需求规范，说明系统及其软件部分之间的接口，并将外部性能和功能需求放在软件部分上。当然，SRS应该允许扩展这些系统要求。SRS表示需求的优先级和关键性。SRS定义了其适用的软件产品的所有所需功能，并记录了软件必须执行的条件和约束，以及需求的预期验证方法。

8.4.2 SRS example outline SRS示例大纲

The specific requirements clause of the SRS should be organized such that a consensus of the system stakeholders agrees that the organization method aids understanding of the requirements.There is no one optimal organization for all systems.An example outline for an SRS is in Figure 8.

SRS的具体要求条款的组织形式应确保系统干系人一致同意组织方式有助于理解要求。对于所有系统，没有一个最优的组织形式。SRS的结构示例如图8所示。

NOTE 1 Verification,Section 4 in Figure 8,is not included in the original IEEE Std.830.

注1：原始IEEE标准830中未包括图8第4节中的验证。

Examples of organizational approaches to requirements in an SRS include:

SRS中的需求组织方法示例包括：

System mode - Some systems behave quite differently depending on the mode of operation.For example,a control system may have different sets of functions depending on its mode: training,normal,or emergency.

系统模式-根据操作模式，某些系统的行为非常不同。例如，根据其模式，控制系统可能具有不同的功能集：培训、正常或紧急。

User class - Some systems provide different sets of functions to different classes of users.For example,an elevator control system presents different capabilities to passengers,maintenance workers,and firefighters.

用户分类-一些系统为不同类型的用户提供不同的功能。例如，电梯控制系统为乘客、维护人员和消防员分别提供了不同的功能

Objects - Objects are real-world entties that have a counterpart within the system.For example,in a patient monitoring system,objects include patients,sensors,nurses,rooms,physicians,medicines,etc.Associated with each object is a set of atributes (of that object) and functions (performed by that object).These functions are also called services,methods,or processes.

对象-对象是在系统中具有对应项的真实世界的实体。例如，在患者监控系统中，对象包括患者、传感器、护士、房间、医生、药品等。与每个对象相关联的是一组（该对象的）心房和功能（由该对象执行）。这些功能也称为服务、方法或流程。

Feature - A feature is an externally desired service by the system that may require a sequence of inputs to effect the desired result.For example,in a telephone system,features include local call,call forwarding,and conference call.Each feature is generally described in a sequence of stimulus-response pairs.

功能-功能是系统外部所需的服务，可能需要一系列输入来实现所需结果。例如，在电话系统中，功能包括本地呼叫、呼叫转移和会议呼叫。每个特征通常在一系列刺激-反应对中描述。

Stimulus - Some systems can be best organized by describing their functions in terms of stimuli.For example,the functions of an automatic aircraft landing system may be organized into sections for loss of power,wind shear,sudden change in roll,vertical velocity excessive,etc.

刺激-一些系统可以通过描述它们在刺激方面的功能来进行最佳组织。例如，自动飞机着陆系统的功能可分为功率损失、风切变、横摇突变、垂直速度过大等部分。

Response - Some systems can be best organized by describing all the functions in support of the generation of a response.For example,the functions of a personnel system may be organized into sections corresponding to all functions associated with generating paychecks,all functions associated with generating a current list of employees,etc.

响应-通过描述用于或支持生成系统响应的所有功能，可以很好地组织一些系统。例如，人事系统的功能可以被组织成与生成工资支票相关联的所有功能、与生成当前员工列表相关联的所有功能等相对应的部分。

Functional hierarchy - When none of the above organizational schemes prove helpful,the overall functionality can be organized into a hierarchy of functions organized by common inputs,common outputs,or common internal data access.Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data.

功能层次结构-当上述组织方案均无效时，可将整体功能组织成由公共输入、公共输出或公共内部数据访问组织的功能层次结构。数据流图和数据字典可用于显示函数和数据之间的关系。

NOTE 2 There are many notations,methods,and automated support tools available to aid in the documentation of SRS requirements.For the most part,their usefulness is a function of organization.For example,when organizing by mode,finite state machines or state charts may prove helpful; when organizing by object,object-oriented analysis may prove helpful; when organizing by feature,stimulus-response sequences may prove helpful; and when organizing by functional hierarchy,data flow diagrams and data dictionaries may prove helpful.

注2：有多种符号、方法和自动支持工具可用于帮助编写SRS需求。它们可以在很大程度帮助更有效地组织文档。例如，当按模式组织时，有限状态机或状态图可能会有帮助；当按对象组织时，面向对象的分析可能会有帮助；当按功能组织时，刺激-反应序列可能有帮助；当按功能层次结构进行组织时，数据流图和数据字典可能会很有用。

9 Information item content 信息项内容

9.1 Introduction导言

This clause states the normative content of the required information items.The content for the software requirements specification document,as stated in subclause 9.5,is only applicable if adhering to System Requirements Analysis Process of ISO/IEC 12207.

本条款规定了信息项的规范性内容。如第9.5款所述，软件需求规范文件的内容仅在遵守ISO/IEC 12207的系统需求分析过程时适用。

NOTE Information content in subclause 9.2 is generally applicable to items of information maintained in document form.

注：第9.2款中的信息内容通常适用于以文件形式保存的信息项。

9.2 General content一般内容

9.2.1 Identification标识

Include the following identification matter:

包括以下标识事项

a) Title 标题

b) Revision notice 修订说明

The title and a revision notice uniquely identify the document.Revision information may include the project name,version number of the document,date of release,approved signature,a list of subclauses that have been changed in the current version of the document,and a list of version numbers and dates of release of all previous versions of the document.

标题和修订说明唯一标识文档。修订信息可能包括项目名称、文件版本号、发布日期、批准签名、文件当前版本中已更改的子条款列表，以及文件各版本号及发布日期列表。

9.2.2 Front matter正文前事项

Include the following front matter:

a) A table of contents 目录

b) A list of figures 图清单

c) A list of tables 表清单

9.2.3 Definitions定义

Provide definitions for any words or phrases that have special meaning beyond normal dictionary definitions.

提供任何单词或短语的定义，这些单词或短语具有普通词典定义以外的特殊含义。

9.2.4 References 参考资料

Include the following information regarding references:

包括有关参考资料的浮华信息：

a)   Provide a complete list of all documents referenced elsewhere;

a)提供引用的所有文件的完整清单；

b)   Identify each document by title,report number (if applicable),date and publishing organization;

按标题、报告编号（如适用）、日期和发布组织识别每份文件；

c)   Specify the sources from which the references can be obtained.

c)指明可从中获取参考资料的来源。

c)

This information may be provided by reference to an appendix or to another document.The references information should be subdivided into a 'Compliance' section,containing references to those cited documents containing requirements which are included by that citation and a 'Guidance' section,containing reference to those cited documents containing information,but no requirements.

该信息可通过附录或其他文件提供。参考资料信息应细分为“合规性”部分，其中包括对包含该引用要求的引用文件的参考，以及“指南”部分，其中包括对包含信息但不包含要求的引用文件的参考。

9.2.5 Acronyms and abbreviations缩略语和缩写

Spell out or define all acronyms and abbreviations used in the documents.

拼写或定义文档中使用的所有缩略语和缩写。

NOTE This information may be provided by reference to one or more appendixes in the documents or by reference to other documents.

注：本信息可通过参考文件中的一个或多个附录或参考其他文件提供。

9.3 Stakeholder requirements specification (StRS) document干系人需求规范(StRS)文件

This clause defines the normative content of the stakeholder requirements specification (StRS) document.The project shall produce the following information items in accordance with the project's policies with respect to the stakeholder requirements specification document.Organization of the information items in the document such as the order and section structure may be selected in accordance with the project's documentation policies.

本条款定义了干系人需求规范（StRS）文件的规范性内容。应根据项目政策中与干系人要求规范文件相关的内容，编制以下信息项。可根据项目文件政策选择文件中信息项的组织方式，如顺序和章节结构。

9.3.1 Business purpose业务目的

Describe at the organization level the reason and background for which the organization is pursuing new business or changing the current business in order to fit a new management environment.In this context it should describe how the proposed system will contribute to meeting business objectives.

在组织层面上描述组织寻求新业务或改变当前业务以适应新的管理环境的原因和背景。在这种情况下，应说明系统将如何有助于实现业务目标。

9.3.2 Business scope业务范围

Define the business domain under consideration by

定义所考虑的业务领域：

a)  Identifying the business domain by name.

a)按名称识别业务域。

b)  Defining the range of business activities included in the business domain concerned.The scope can be defined in terms of divisions in the organization and external entities that relate directly to the business activities,or functions to be performed by the business activities.It is helpful to show environmental entities which are outside of the scope.

定义相关业务领域中包含的业务活动范围。范围可以根据组织中与业务活动直接相关的部门和外部实体，或业务活动将执行的职能来定义。有助于显示超出范围的环境实体。

c)  Describing the scope of the system being developed or changed.The description includes assumptions on which business activities are supported by the system.

描述正在开发或更改的系统的范围。描述包括系统支持哪些业务活动的假设

9.3.3 Business overview业务概览

Describe major internal divisions and external entities of the business domain concerned and how they are interrelated.A diagrammatic description is recommended.

描述相关业务领域的主要内部部门和外部实体，以及它们之间的相互关系。建议使用图解说明。

9.3.4 Stakeholders干系人

List the stakeholders or the classes of stakeholders and describe how they will influence the organization and business,or will be related to the development and operation of the system.

列出干系人或干系人类别，并描述他们将如何影响组织和业务，或如何与系统的开发和运行相关。

9.3.5 Business environment商业环境

Define external and internal environmental factors that should be taken into consideration in understanding the new or existing business and eliciting the stakeholder requirements for the system to be developed or changed.The environmental factors should include possible influences to the business and consequently the system from external conditions like market trends,laws and regulations,social responsibilities,and technology base.

定义外部和内部环境因素，这些因素在理解新业务或现有业务、获取干系人对要开发或更改的系统的需求时要予以考虑。环境因素应包括市场趋势、法律法规、社会责任和技术基础等外部条件对业务以及系统可能产生的影响。

9.3.6 Goal and Objective目标和目标

Describe the business results to be obtained through or by the proposed system.

描述通过系统获得的业务结果。

9.3.7 Business model商业模式

Describe methods by which the business goal is expected to be achieved.The description should be concentrated on the methods supported by the system to be developed or changed with the items such as product and services,geographies and locales,distribution channels,business alliance and partnership,and finance and revenue model.

描述预期实现预期业务目标的方法。描述应集中于要开发或修改的系统所支持的方法，包括产品和服务、地理位置和地点、分销渠道、商业联盟和合作伙伴关系以及财务和收入模型。

NOTE Detailed discussions and definitions of the business model elements can be found in Business Motivation Model (BMM) Specification by OMG.

注：有关业务模型元素的详细讨论和定义，请参见OMG的业务动机模型（BMM）规范。

9.3.8 Information environment信息环境

Describe the overall strategy for the organization level decisions on common bases for multiple informationsystems.It should include the following items:

描述基于多个信息系统公共基础的组织级决策的总体策略。它应包括以下项目：

a)   project portfolio - when multiple system projects are running or planned to pursue the same business goal,the priority,relative positioning,and possible constraints come from the portfolio management strategy.

项目组合-当多个系统项目正在运行或计划致力于相同业务目标时，优先级、相对定位和可能的约束来自组合管理策略。

b)   long term system plan - when common system infrastructure or architecture has been decided or planned,it should be described as constraints on possible design decisions.

长期系统规划-当公共系统基础设施或架构已经确定或规划时，应将其描述为对可能的设计决策的约束。

c)   database configuration - an organization level database configuration plan and possible constraints on availability and accessbility of organization global data should be specified.

数据库配置-应指定组织级数据库配置计划以及组织全局数据可用性和可访问性的可能约束。

9.3.9 Business processes业务流程

Provide description of the procedures of business activities and possible system interfaces within the processes.The purpose of this information item is to represent how and in which context the system supports the business activities.In general,business processes make a hierarchical structure with decomposition and classification.Each business process should be uniquely named and numbered in the hierarchy.The description of the individual business process should be represented as a diagram representing a sequence of activities.

提供业务活动程序的描述，以及流程内可能的系统接口。此信息项的目的是表示系统如何以及在何种上下文中支持业务活动。一般来说，业务流程通过分解和分类形成层次结构。每个业务流程在层次结构中都应该有唯一的名称和编号。单个业务流程使用一个表示一系列活动的图表来描述。

9.3.10 Business operational policies and rules业务运作政策和规则

Describe logical propositions applied in conducting the business processes.The propositions will be conditions to start,branch and terminate the sequence of the business activities in the business processes;criteria for judgment in the business processes; or formula to evaluate a quantity,which will likely be addressed in functional requirements in the SyRS and SRS.The policies and rules shall be uniquely named and numbered,and shall be referenced in the description of the business processes.

描述用于执行业务流程的逻辑命题。这些提议将成为启动、分支和终止业务流程中业务活动序列的条件；业务流程中的判断标准；或计算数量的公式，可能在SyRS和SRS的功能要求中解决。政策和规则应具有唯一的名称和编号，并在业务流程描述中引用。

9.3.11 Business operational constraints业务运作制约因素

Describe conditions to be imposed in conducting the business process.The conditions may be on a performance constraint (e.g.,the process shall be finished within a day after the triggering event occurs),or may be from a management requisite such as 'every occurrence of the process shall be monitored and recorded'.

描述在执行业务流程时要施加的条件。这些条件可能与性能约束有关（例如，流程应在触发事件发生后一天内完成），也可能来自管理要求，如“应监控和记录流程的每一次发生”。

9.3.12 Business operation modes业务运作模式

Describe methods to conduct the business operation in an unsteady state,for example,a state when business operations might be extremely busy due to some intensive occurrence of events.An unsteady state of business operation includes a manual operation mode when the proposed system is not available due to some unexpected situation like an accident or natural disaster.

描述在不稳定状态下执行业务操作的方法，例如，由于某些密集事件的发生，业务操作可能非常繁忙的状态。业务运行的不稳定状态包括由于意外情况（如事故或自然灾害）而导致系统不可用时的手动操作模式。

9.3.13 Business operational quality业务运作质量

Define the level of quality required for the business operation.For example,a business process may address required urgency with higher priority than the relability of the business process.

定义业务运行要求的质量级别。例如，业务流程可能以比业务流程的相关性更高的优先级处理所需的紧急性。

9.3.14 Business structure业务结构

Identify and describe the structures in the business relevant to the system,such as organizational structure(divisions and departments),role and responsibility structures,geographic structures,and resource sharing structures.There may be a need to alight the system functions to these structures,and to support future structural changes.

识别和描述与系统相关的业务结构，如组织结构（部门和部门）、角色和责任结构、地理结构和资源共享结构。可能需要将系统功能放在这些结构上，并支持未来的结构变化。

9.3.15 User requirements用户需求

User requirements (within the context of the StRS) include required inputs/selections/information observations which users/operators/maintainers need to perform through the use of the system; any outputs they require from the system in order to perform these tasks; and any applicable conditions or constraints governing their interaction with (i.e.,usability of) the system.These requirements are then used to describe the operational scenarios which specify how to meet these requirements when interacting with the system.

用户需求（在StRS范围内）包括用户/操作员/维护人员需要通过使用系统执行的所需输入/选择/可见信息；执行这些任务所需的系统输出；以及控制其与系统交互（即可用性）的任何条件或约束。然后，这些需求被用来描述操作场景，这些场景定义了在与系统交互时如何满足这些需求。

The context of use specifed for a design (i.e.,the context in which the system will be used) should be specified as part of the user requirements specification to clearly identify the conditions under which the specified as part of the user requirements specification to clearly identify the conditions under which the requirements apply.Usability requirements and objectives for the system include measurable effectiveness,requirements apply.Usability requirements and objectives for the system include measurable effectiveness,efficiency,and satisfaction criteria in specific contexts of use.

应将为设计指定的使用环境（即系统将被使用的环境）视为用户需求书的一部分，作为用户需求书中的环境约束条件，以明确需求适用的条件。系统的可用性要求和目标包括可测量的有效性、适用的需求。系统的可用性要求和目标包括特定使用环境中可测量的有效性、效率和满意度标准。

NOTE 1 See ISO 9241-11 for more information about the context of use and a sample report.See ISO 20282-1:2006 for more information about context of use for everyday products.

注1：有关使用环境和示例报告的更多信息，请参见ISO 9241-11。有关日常产品使用环境的更多信息，请参见ISO 20282-1:2006。

NOTE2 Additional material on user needs,context of use,user requirements can be found in ISO/IEC TR 25060 and ISO 9241-210.

注2关于用户需求、使用环境和用户要求的补充材料可在ISO/IEC TR 25060和ISO 9241-210中找到。

9.3.16 Operational concept业务概念

Describe the proposed system in a high-level manner,indicating the operational features that are to be provided without specifying design details.The following information should be included:

以高层次的方式描述提议的系统，指出在不指定设计细节的情况下提供的操作特性。应包括以下信息：

a)   Operational policies and constraints业务政策和制约因素

b)   Description of the proposed system目标系统的说明

c)   Modes of system operation系统运作模式

d)   User classes and other involved personnel

d)用户班和其他有关人员

e)   Support environment支持环境

NOTE Detailed discussion of the information item content for the System Operational Concept Document is in Annex A,particularly A.2.5.

注：附件A中详细讨论了系统运行概念文件的信息项内容，特别是A.2.5。

9.3.17 Operational scenarios业务场景

Describe examples of how users/operators/maintainers will interact with the system (context of use).The scenarios are described for an activity or a series of activities of business processes supported by the system.The scenario should be uniquely named and numbered,and should be referenced in the description of the business processes in subclause 9.3.9.

描述用户/操作员/维护人员如何与系统交互的示例（使用上下文）。描述了业务流程的一个或一系列活动的场景。该场景应具有唯一的名称和编号，并应在子条款9.3.9中的业务流程描述中引用。

NOTE More information for the context of use and the usability requirements can be found in ISO/EC TR 25060 and ISO 9241-210

注：有关使用环境和可用性要求的更多信息，请参见ISO/EC TR 25060和ISO 9241-210

9.3.18 Project constraints项目限制

Describe constraints to performing the project within cost and schedule.

描述在成本和时间内完成项目的限制。

9.4 System requirements specification (SyRS) document系统需求规范(SyRS)文档

This clause defines the normative content of a system requirements specification (SyRS).The project shall produce the following information item content in accordance with the project's policies with respect to the system requirements specification document.Organization of the content in the document such as the order and section structure may be Selected in accordance with the project's documentation policies.

本条款定义了系统需求规范（SyRS）的规范性内容。项目应根据项目有关系统需求规范文件的政策，生成以下信息项内容。可根据项目文件政策选择文件内容的组织形式，如顺序和章节结构。

9.4.1 System purpose系统目标

Define the reason(s) for which the system is being developed or modified.

定义开发或修改系统的原因。

9.4.2 System scope系统范围

Define the scope of the system under consideration by

定义正在考虑的系统的范围

a)  Identifying the system to be produced by name.

a)系统名称。

b)  Referring to and stating the results of the earlier finalized needs analysis,in the form of a brief but clear expression of the user's problem(s).It explains what the system will and will not do to satisfy those needs.
参考并说明早期最终需求分析的结果，以简短但清晰的方式表达用户的问题。它解释了系统将做什么和不做什么来满足这些需求。

c)  Describing the application of the system being specified.As a portion of this,it should describe all relevant top level benefits,objectives,and goals as precisely as possible.

描述系统的使用。作为其中的一部分，它应该尽可能精确地描述所有相关的顶级利益、目标和目标

9.4.3 System overview系统概览

9.4.3.1 System context系统上下文

Describe at a general level the major elements of the system,to include human elements,and how they interact.The system overview includes appropriate diagrams and narrative to provide the context of the system,defining all significant interfaces crossing the system's boundaries.

从总体上描述系统的主要要素，包括人的要素，以及它们如何相互作用。系统概述包括适当的图表和叙述，以提供系统的上下文，定义跨越系统边界的所有重要接口。

9.4.3.2 System functions系统功能

Describe major system capabilties,conditions and constraints.

描述主要的系统能力，条件和约束。

9.4.3.3 User characteristics用户特性

Identify each type of user/operator/maintainer of the system (by function, location,type of device),the number in each group,and the nature of their use of the system.

确定系统的每种类型的用户/操作员/维护人员（按功能、位置、设备类型）、每组人数以及他们使用系统的方式。

NOTE Where appropriate,the user characteristics of the SyRS and SRS should be consistent.

注：在适当的情况下，SyRS和SRS的用户特征应该是一致的。

9.4.4 Functional requirements功能需求

Define functional requirements applicable to system operation.

定义适用于系统操作的功能需求。

9.4.5 Usability requirements可用性需求

Define usability (quality in use) requirements.Usability requirements and objectives for the system include measurable effectiveness,efficiency,and satisfaction criteria in specific contexts of use.

定义可用性（使用质量）要求。系统的可用性要求和目标包括特定使用环境中可测量的有效性、效率和满意度标准。

9.4.6 Performance requirements性能需求

Define the critical performance conditions and their associated capabilties by including such considerations

定义关键性能条件及其相关能力，包括以下考虑事项

a)  Dynamic actions or changes that occur (e.g.,rates,velocities,movements,and noise levels).

a)发生的动态动作或变化(例如速率、速度、运动和噪音水平)。

b)  Quantitative criteria covering endurance capabilities of the equipment required to meet the user needs under stipulated environmental and other conditions,including minimum total life expectancy.Indicate required operational session duration and planned tilzation rate.
定量标准，包括在规定的环境和其他条件下满足用户需求所需的设备耐久能力，包括最低总预期寿命。指出所需的操作会话持续时间和计划的平铺率。

c)  Performance requirements for the operational phases and modes.

c)运行阶段和运行模式的性能要求。

c)

9.4.7 System interfaces系统接口

Specify requirements for interfaces among system elements and with extermal entities.Interfaces among system elements should include interfaces with the human element.Interfaces with external entities should include other systems.

指定系统元素之间以及与外部实体的接口要求。系统元素之间的接口应包括与人的接口。与外部实体的接口应包括其他系统。

Define any interdependencies or constraints associated with the interfaces (e.g..communication protocols,special devices,standards,fixed formats).Each interface may represent a bidirectional flow of information.A graphic representation of the interfaces can be used when appropriate for the sake of clarity.

定义与接口相关的任何相互依赖性或约束（例如通信协议、特殊设备、标准、固定格式）。每个接口可以表示双向信息流。为了清晰起见，可适当使用界面的图形表示。

9.4.8 System Operations系统运作

9.4.8.1 Human system integration requirements人类系统集成需求

Reference applicable documents and specify any special or unique requirements, e.g.,constraints on allocation of functions to personnel and communications and persone/equipment interactions.

参考适用文件，并规定任何特殊或独特的要求，例如对人员和通信以及人员/设备交互功能分配的限制。

Define any specific areas,stations,or equipment that would require concentrated human engineering attention due to the sensitivity of the operation or criticality of the task (i.e,those areas where the effects of human error would be particularly serious).

定义由于操作的敏感性或任务的关键性而需要集中人力注意的任何特定区域、站点或设备（即人为错误影响特别严重的区域）。

NOTE ISO 18529,Ergonomics - - Ergonomics of human-system interaction 一Human-centred lifecycle process descriptions,contains a formalized model that can be used in the specification,assessment and improvement of the human-centered processes in system development and operation.

注：ISO 18529，人类工效学——人体系统交互的人类工效学一以人为中心的生命周期过程描述，包含一个形式化模型，可用于系统开发和运行中以人为中心的过程的规范、评估和改进。

9.4.8.2 Maintainability可维护性

Specify the quantitative maintainability requirements that apply to maintenance in the planned maintenance and support environment.Examples are as follows:

指定适用于计划内的维护和支持环境中的维护的定量可维护性需求。举例如下：

a)  Time (e.g.,mean and maximum downtime,reaction time,turnaround time,mean and maximum times to repair,mean time between maintenance actions)
时间（例如，平均和最大停机时间、反应时间、周转时间、平均和最大维修时间、维修行动之间的平均时间）

b)  Rate (e.g.maintenance staff hours per specific maintenance action,operational ready rate,maintenance time per operating hour,frequency of preventative maintenance)
比率（例如，每项维护活动的工时、运行就绪率、每运行小时的维护时间、预防性维护频率）

c)  Maintenance complexity (e.g..number of people and skill levels,variety of support equipment,removing/replacing/repairing components)
维护复杂性（例如，人员数量和技能水平、支持设备的种类、拆卸/更换/维修部件）

d)  Maintenance action indices (e.g..maintenance costs per operating hour,staff hours per overhaul)

d)维修行动指数(例如.每工作小时的维持费，每次大修的工作人员时数)

e)  Accessbility to components within systems and to parts within components

e)系统中的组件和组件中的部件的可访问性

e)

9.4.8.3 Reliability可靠性

Specifty the system reliability requirements in quantitative terms,including the conditions under which the reliability requirements are to be met.This may also include the reliability apportionment model to support allocation of reliability values assigned to system functions for their share in achieving desired system relability.

以定量方式说明系统可靠性要求，包括满足可靠性要求的条件。这还可能包括可靠性分配模型，以支持分配给系统功能的可靠性值，以实现所需的系统可靠性。

9.4.9 System modes and states系统模式和状态

If the system can exist in various modes or states define these and,as appropriate,use diagrams.

如果系统可以以不同的模式或状态存在，请定义这些模式或状态，并酌情使用图表。

NOTE The mode of a system refers to a collection of states.

系统的模式是指状态的集合。

9.4.10 Physical characteristics物理特性

9.4.10.1 Physical requirements物理需要

Include constraints on weight,volume and dimension.Include the construction characteristics of where the system will be installed,requirements for materials to be used in the item or service covered by this specification,and requirements covering nameplates and system markings,interchangeability of equipment,and workmanship.

包括对重量、体积和尺寸的约束。包括系统安装位置的结构特征、本规范涵盖的项目或服务中使用的材料要求、铭牌和系统标记、设备互换性和工艺要求。

9.4.10.2 Adaptability requirements适应性要求

Define requirements for growth,expansion,capability,and contraction.For example, if the system will require future network bandwidth,the applicable hardware should be specified with extra card slots to accommodate new network cards as demand increases.

定义增长、扩张、能力和收缩的需求。例如，如果系统未来需要更大的网络带宽，则应为硬件指定额外的卡槽，以便在需求增加时容纳新的网卡。

9.4.11 Environmental conditions环境条件

Include environmental conditions to be encountered by the system.The following areas should be addressed:

包括系统要遇到的环境条件。应处理下列领域：

natural environment (e.g., wind, rain, temperature, flora, fauna, fungus, mold, sand,salt spray,dust,radiation,chemical,and immersion); induced environment (e.g.,motion,shock,noise,electromagnetic,thermal); electromagnetic signal environment; self-induced environment(e.g., motion, shock, noise, electromagnetic,thermal); threat; and cooperative environment.Consideration should also be given to legal/regulatory,political,economic,social,and business environment.

自然环境（例如，风、雨、温度、植物、动物、真菌、霉菌、沙子、盐雾、灰尘、辐射、化学品和浸没）；感应环境（如运动、冲击、噪声、电磁、热）；电磁信号环境；自感环境（如运动、冲击、噪声、电磁、热）；威胁以及合作环境。还应考虑法律/监管、政治、经济、社会和商业环境。

9.4.12 System security系统安全

Define the system security requirements related to both the facility that houses the system and operational security requirements of the system itself.One example of security requirements might be to specify the security and privacy requirements,including access limitations to the system,such as existence of log-on procedures and passwords,and of data protection and recovery methods.This could include the factors that would protect the system from accidental or malicious access,use,modification,destruction,or disclosure.

定义与容纳系统的设施和系统本身的操作安全要求相关的系统安全要求。安全要求的一个例子是指定安全和隐私要求，包括对系统的访问限制，例如存在登录过程和密码，以及数据保护和恢复方法。这可能包括保护系统免受意外或恶意访问、使用、修改、破坏或泄露的因素。

Especially in safety-critical embedded systems this might incorporate a distributed log or history of data sets,the assignment of certain functions to different single systems,or the restriction of communications between some areas of the system.

特别是在安全关键型嵌入式系统中，这可能包括数据集的分布式日志或历史记录、将某些功能分配给不同的单个系统，或限制系统某些区域之间的通信。

9.4.13 Information management信息管理

Define the requirements for the system's management of information that it receives,generates,or exports.

定义系统对其接收、生成或导出的信息的管理要求。

Examples include types and amounts of information the system is required to receive and store,any proprietary or other protections levied on the information the system deals with,and what backup and archiving requirements exist for the information.

示例包括系统需要接收和存储的信息的类型和数量、对系统处理的信息实施的任何专有或其他保护，以及对信息的备份和归档要求。

9.4.14 Policies and regulations政策和条例

Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements,or constraints imposed by normal business practices.

详细说明将影响系统运行或性能的任何相关组织政策，以及任何相关的外部监管要求，或正常业务实践施加的约束。

Examples of requirements include multilingual support,labour policies,protection of personnel information,and reports to a regulatory agency.

要求的例子包括多语言支持、劳工政策、人员信息保护和监管机构要求的报告等。

Specify health and safety criteria,including those basic to the design of the system,with respect to equipment characteristics，methods of operation,and environmental influences such as toxic systems and electromagnetic radiation.

就设备特性、操作方法和环境影响（如有毒系统和电磁辐射）规定健康和安全标准，包括系统设计的基本标准。

9.4.15 System life cycle sustainment系统生命周期支持

Outline quality activities,such as review,and measurement collection and analysis,to help realize a quality system.Life cycle sustainment also includes provision of facilties needed to provide operational- and depot-level support,spares,sourcing and supply,provisioning,technical documentation and data,support-personnel training,initial cadre training and initial contractor-logistics support.

概述质量保障活动，如评审、测量数据收集和分析，以帮助实现优质的系统。生命周期维持还包括提供操作和系统级支持所需的设施、备件、采购和供应、供应、技术文件和数据、支持人员培训、初期干部培训和初期后勤支持。

9.4.16 Packaging,handling,shipping and transportation包装、装卸、运输和运输

Define requirements imposed on the system to ensure that it can be packaged,handled,shipped and transported within its intended operational context.

定义对系统施加的要求，以确保系统能够在其预期操作环境中进行包装、处理、装运和运输。

9.4.17 Verification验证

Provide the verification approaches and methods planned to qualify the system or system element.The information items for verifcation are recommended to be given in a parallel manner with the information items in subclause 9.4.4 to 9.4.16.

提供计划用于鉴定系统或系统要素的验证步骤和方法。建议以与第9.4.4款至第9.4.16款中的信息项平行的方式提供验证信息项。

9.4.18 Assumptions and dependencies假设和依赖关系

List any assumptions and dependencies applicable to the system requirements that should be taken into account in the allocation and derivation of lower-level system requirements.

列出适用于系统需求的任何假设和依赖性，这些假设和依赖性应在分配和推导较低级别的系统需求时予以考虑。

9.5 Software requirements specification (SRS) document软件需求规范(SRS)文档

This subclause defines the normative content of the software requirements specification (SRS).The project shall produce the following information item content in accordance with the project's policies with respect to the software requirements specification document.Organization of the information items in the document such as the order and section structure may be Selected in accordance with the project's documentation policies.

本款定义了软件需求规范（SRS）的规范性内容。项目应根据项目有关软件需求规范文件的政策，生成以下信息项内容。可根据项目文件政策选择文件中信息项的组织方式，如顺序和章节结构。

9.5.1 Purpose目的

Delineate the purpose of the software to be specified.

描述软件的用途。

9.5.2 Scope范围

Describe the scope of the sofware under consideration by

描述软件的范围

a)  Identifying the software product(s) to be produced by name (e.g.Host DBMS,Report Generator,etc.);

确认按名称生产的软件产品(例如主机数据库管理系统、报告生成器等)；

b)  Explaining what the software product(s) will do;

b)解释软件产品将做什么；

c)  Describing the application of the software being specifed,including relevant benefits,objectives,and goals;

c)说明软件的应用，包括相关效益、目地和目标；

d)  Being consistent with similar statements in higher-level specifications (e.g.,the system requirements specification),if they exist.
与更高级别规范（如系统需求规范）中的类似陈述保持一致（如果存在）。

9.5.3 Product perspective产品视角

Define the system's relationship to other related products.

定义系统与其他相关产品的关系。

If the product is an element of a larger system,then relate the requirements of that larger system to the functionality of the product covered by the SRS.

如果产品是较大系统的一部分，则将该较大系统的要求与SRS涵盖的产品功能相关联。

If the product is an element of a larger system,then identify the interfaces between the product covered by the SRS and the larger system of which the product is an element.

如果产品是更大系统的一部分，要定义产品与其所属系统之间的接口。

A block diagram showing the major elements of the larger system, interconnections,and external interfaces can be helpful.

显示较大系统的主要组成部分、互连和外部接口的框图可能会有所帮助。

Describe how the software operates within the following constraints:

描述软件是如何在以下约束条件下工作的：

a) System interfaces;系统接口；

b) User interfaces;用户界面；

c) Hardware interfaces;硬件接口；

d) Software interfaces;软件接口；

e) Communications interfaces;通信接口；

f) Memory内存；

g) Operations;操作；

h) Site adaptation requirements.场地要求。

9.5.3.1 System interfaces系统接口

List each system interface and identify the functionality of the sofware to accomplish the system requirement and the interface description to match the system.

列出每个系统接口，并确定软件的功能，以满足系统需求和接口描述，以匹配系统。

9.5.3.2 User interfaces用户界面

Specify the following:

具体说明如下：

a)  The logical characteristics of each interface between the sofware product and its users.This includes those configuration characteristics (e.g.,required screen formats,page or window layouts,content of any reports or menus,or availability of programmable function keys) necessary to accomplish the software requirements.
软件产品及其用户之间每个接口的逻辑特征。这包括完成软件需求所需的配置特征（例如，所需的屏幕格式、页面或窗口布局、任何报告或菜单的内容或可编程功能键的可用性）。

b)  All the aspects of optimizing the interface with the person who uses,maintains,or provides other support to the system.This may simply comprise a list of do's and don'ts on how the system will appear to the user.One example may be a requirement for the option of long or short error messages.This may also be specifed in the Software System Attributes under a section titled Ease of Use.
与使用、维护或支持人员一起优化接口的各个方面。这可能仅仅包括一个列表，其中列出了系统在用户面前的表现。一个例子可能是要求选择长错误消息或短错误消息。这也可以在“易用性”一节的“软件系统属性”中指定。

NOTE A style guide for the user interface can provide consistent rules for organization, coding,and interaction of the user with the system.

注：用户界面的样式指南可以为用户与系统的组织、编码和交互提供一致的规则。

9.5.3.3 Hardware interfaces硬件接口

Specify the logical characteristics of each interface between the software product and the hardware elements of the system.This includes configuration characteristics (number of ports,instruction sets,etc.)- It also covers such matters as what devices are to be supported,how they are to be supported,and protocols.For example,terminal support may specify full-screen support as opposed to line-by-line support.

指定软件产品和系统硬件之间接口的逻辑特征。这包括配置特征（端口数、指令集等）——还包括支持哪些设备、支持方式和协议等事项。例如，终端支持可以指定全屏支持，而不是逐行支持。

9.5.3.4 Software interfaces软件接口

Specify the use of other required software products (e.g.,a data management system,an operating system,or a mathematical package),and interfaces with other application systems (e.g.,the linkage between an accounts receivable system and a general ledger system).

指定其他所需软件产品（例如，数据管理系统、操作系统或数学软件包）的使用，以及与其他应用系统的接口（例如，应收账款系统和总账系统之间的链接）。

For each required software product,specify:

对于每个软件产品，请指定：

a)   Name;名称；

b)   Mnemonic;简称；

c)   Specification number;规格编号；

d)   Version number;版本号；

e)   Source.来源。

For each interface specify:

对于每个接口，请指定：

a)   Discussion of the purpose of the interfacing software as related to this software product.
讨论与本软件产品有关的接口软件的用途。

b)   Definition of the interface in terms of message content and format.It is not necessary to detail any well-documented interface,but a reference to the document defining the interface is required.
根据消息内容和格式定义接口。无需详细说明任何记录良好的接口，但需要参考定义接口的文件。

b)

9.5.3.5 Communications interfaces通信接口

Specify the various interfaces to communications such as local network protocols.

指定通信的各种接口，如本地网络协议。

9.5.3.6 Memory constraints内存约束

Specify any applicable characteristics and limits on primary and secondary memory.

指定主内存和辅助内存的任何适用特性和限制。

9.5.3.7 Operations操作

Specify the normal and special operations required by the user such as

指定用户所需的正常操作和特殊操作，如

a)   The various modes of operations in the user organization (e.g.,user-initiated operations);
用户组织中的各种业务模式(例如，用户发起的业务)；

b)   Periods of interactive operations and periods of unattended operations;
互动作业和无人值守作业的时期；

c)   Data processing support functions;
数据处理支助职能；

d)   Backup and recovery operations.
备份和恢复操作。

d)

NOTE This is sometimes specified as part of the User Interfaces section.

注意：这有时被指定为用户界面部分的一部分。

9.5.3.8 Site adaptation requirements场地要求

The site adaptation requirements include

场地要求包括

a)  Definition of the requirements for any data or initialization sequences that are specific to a given site,mission,or operational mode (e.g.grid values,safety limits,etc.);
定义特定于某个场地、任务或操作模式的任何数据或初始化顺序的要求（例如网格值、安全限制等）；

b)  Specification of the site or mission-related features that should be modified to adapt the software to a particular installation.
应修改以使软件适应特定安装的场地或任务相关功能的规范。

9.5.4 Product functions产品功能

Provide a summary of the major functions that the software will perform.For example,an SRS for an accounting program may use this part to address customer account maintenance,customer statement,and invoice preparation without mentioning the vast amount of detail that each of those functions requires.

Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product.

提供软件主要功能的摘要。例如，会计程序的SRS可以使用此部分来处理客户帐户维护、客户对账单和发票准备，而不提及这些功能所需的大量细节。

有时，本部分所需的功能摘要可以直接从更高级别规范（如果存在）中获取，该规范将特定功能分配给软件产品。

Note that for the sake of clarity

请注意，为了清晰起见

a)  The product functions should be organized in a way that makes the list of functions understandable to the acquirer or to anyone else reading the document for the first time.
产品功能的组织方式应使需方或首次阅读本文件的任何其他人都能理解功能列表。

b)  Textual or graphical methods can be used to show the different functions and their relationships.Such a diagram is not intended to show a design of a product,but simply shows the logical relationships among variables.
可以使用文本或图形方式来显示不同的函数及其关系。这样的图表不是为了显示产品的设计，而是简单地显示变量之间的逻辑关系。

9.5.5 User characteristics用户特征

Describe those general characteristics of the intended groups of users of the product including characteristics that may influence usability,such as educational level,experience,disabilities,and technical expertise.This description should not state specific requirements,but rather should state the reasons why certain specific requirements are later specified in specifc requirements in subclause 9.5.9.

描述产品预期用户群体的一般特征，包括可能影响可用性的特征，如教育水平、经验、残疾和技术专长。该说明不应说明具体要求，而应说明某些具体要求后来在第9.5.9款的具体要求中规定的原因。

NOTE Where appropriate,the user characteristics of the SyRS and SRS should be consistent.

在适当的情况下，SyRS和SRS的用户特征应该是一致的。

9.5.6 Limitations限制

Provide a general description of any other items that will limit the supplier's options,including

提供限制供应商选择的任何其他项目的一般说明，包括：

a) Regulatory policies;管制政策；

b) Hardware limitations (e.g.,signal timing requirements);

c) Interfaces to other applications;其他应用程序的接口；

d) Parallel operation;并行操作；

e) Audit functions;审计职能；

f) Control functions;控制职能；

g) Higher-order language requirements;高级语文要求；

h) Signal handshake protocols (e.g..XON-XOFF,ACK-NACK);

i) Quality requirements (e.g.,reliability)质量要求(例如可靠性)

j) Criticality of the application;申请的关键程度；

k) Safety and security considerations.安全和安保考虑。

1) Physical/mental considerations身心方面的考虑

9.5.7 Assumptions and dependencies假设和依赖关系

List each of the factors that affect the requirements stated in the SRS.These factors are not design constraints on the software but any changes to these factors can affect the requirements in the SRS.For example,an assumption may be that a specific operating system will be available on the hardware designated for the sofware product.If,in fact,the operating system is not available,the SRS would then have to change accordingly.

列出影响SRS中需求的每个因素。这些因素不是软件的设计约束，但这些因素的任何变化都可能影响SRS中的需求。例如，假设某种操作系统将在软件产品运行的硬件上可用，如果实际上操作系统不可用，则SRS必须相应地进行更改。

9.5.8 Apportioning of requirements需求分解

Apportion the software requirements to software elements.For requirements that will require implementation over multiple software elements,or when allocation to a software element is initially undefined,this should be so stated.A cross reference table by function and software element should be used to summarize the apportionments.

将软件需求分配给软件元素。对于需要在多个软件元素上实现的需求，或者当一个软件元素的分配最初未定义时，应如此说明。使用功能和软件元素交叉表来列出需求分解。

Identify requirements that may be delayed until future versions of the system (e.g.,blocks and/or increments).

确定可能推迟到系统未来版本的需求(例如,块和/或增量)。

9.5.9 Specific requirements具体要求

Specify all of the software requirements to a level of detail sufficient to enable designers to design a software system to satisfy those requirements.

对所有软件需求进行足够详细的说明，使设计人员能够设计满足这些需求的软件系统。

Specify all of the software requirements to a level of detail sufficient to enable testers to test that the software system satisfies those requirements.

详细说明所有软件需求，使测试人员能够测试软件系统是否满足这些需求。

At a minimum,describe every input (stimulus) into the sofware system,every output (response) from the software system,and all functions performed by the software system in response to an input or in support of an output.

至少描述软件系统的每个输入（刺激）、软件系统的每个输出（响应）以及软件系统响应输入或支持输出所执行的所有功能。

The specific requirements should:

具体要求应：

a)   Be stated in conformance with all the characteristics described in subclause 5.2 of this International Standard.

应符合本国际标准第5.2款所述的所有特性。

b)   Be cross-referenced to earlier documents that relate.

与以前有关的文件相互参照。

c)   Be uniquely identifable.

唯一可识别的。

9.5.10 External interfaces外部接口

Define all inputs into and outputs from the software system.The description should complement the interface descriptions in 9.5.3.3.1 through 9.5.3.3.5,and should not repeat information there.

定义软件系统的所有输入和输出。该说明是对9.5.3.3.1至9.5.3.3.5中的接口说明的补充，而不是重复。

Each interface defined should include the following content:

定义的每个接口应包括以下内容：

a) Name of item;项目名称；

b) Description of purpose;目的说明；

c) Source of input or destination of output;输入来源或输出目的；

d) Valid range,accuracy,and/or tolerance;有效范围、准确性和/或公差；

e) Units of measure;计量单位；

f) Timing;时间安排；

g) Relationships to other inputs/outputs;与其他输入/输出的关系；

h) Screen formats/organization;屏幕格式/组织；

i) Window formats/organization;窗口格式/组织；

j) Data formats;数据格式；

k) Command formats;指令格式；

l) Endmessages.结束信息。

9.5.11 Functions功能

Define the fundamental actions that have to take place in the software in accepting and processing the inputs and in processing and generating the outputs,including

定义软件在接受和处理输入以及生成输出时必须采取的基本行动，包括：

a) Validity checks on the inputs输入的有效性检查

b) Exact sequence of operations确切的操作顺序

c) Responses to abnormal situations,including

对不正常情况的反应，包括：

1)Overflow溢出

2)Communication facilities通讯设施（的错误）

3)Error handling and recovery错误处理和恢复

d) Effect of parameters参数的影响

e) Relationship of outputs to inputs,including输入与输出之间的关系，包括

1)Input/output sequences输入/输出顺序

2)Formulas for input to output conversion输入输出转换公式

It may be appropriate to partition the functional requirements into subfunctions or subprocesses.This does not imply that the software design will also be partitioned that way.

可以将功能需求适当划分为子功能或子流程。但这并不意味着软件设计时也以同样的方式进行划分。

9.5.12 Usability requirements可用性需求

Define usability (quality in use) requirements.Usability requirements and objectives for the software system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.

定义可用性（使用方面的标准）要求。软件系统的可用性需求和目标包括特定使用环境中有效性、效率和满意度标准，这些标准要求是可测量的。

9.5.13 Performance requirements性能需求

Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole.

详述对软件或对整个软件的人机交互的静态和动态量化要求。

Static numerical requirements may include the following:

静态量化要求可包括以下内容：

a) The number of terminals to be supported;支持的终端数目；

b) The number of simultaneous users to be supported;同时支持的用户数目；

c) Amount and type of information to be handled.要处理的信息的数量和类型。

Static numerical requirements are sometimes identified under a separate section entitled Capacity.

静态量化要求有时在题为“能力”的单独一节下加以确认。

Dynamic numerical requirements may include,for example,the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.

例如，动态量化需求可能包括正常和峰值工作负载条件下特定时间段内要处理的事务和任务的数量以及数据量。

The performance requirements should be stated in measurable terms.

性能需求应以可衡量的方式表述。

For example,

例如,

95 % of the transactions shall be processed in less than 1 second.

95%的交易应在1秒内处理。

rather than,而不是,

An operator shall not have to wait for the transaction to complete.

经营者不必等待交易完成。

NOTE Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function.

注：特定功能的量化限制通常在该功能处理描述中进行定义。

9.5.14 Logical database requirements逻辑数据库要求

Specify the logical requirements for any information that is to be placed into a database,including:

详述要存放在数据库中的任何信息的逻辑要求，包括：

a) Types of information used by various functions;各种职能所使用的信息类型；

b) Frequency of use;使用频率；

c) Accessing capabilties;获得能力；

d) Data entities and their relationships;数据实体及其关系；

e) Integrity constraints;一致性约束；

f) Data retention requirements.数据保留要求。

9.5.15 Design constraints设计约束

Specify constraints on the system design imposed by external standards,regulatory requirements,or project limitations.

详述外部标准、监管要求或项目局限对系统设计的限制。

9.5.16 Standards compliance合规情况

Specify the requirements derived from existing standards or regulations, including;

详述软件和产品符合现有标准或法规的要求，包括；

a) Report format;报告格式；

b) Data naming;数据命名；

c) Accounting procedures;会计程序；

d) Audit tracing.审计跟踪。

For example,this could specify the requirement for software to trace processing activity.Such traces are needed for some applications to meet minimum regulatory or financial standards.An audit trace requirement may,for example,state that all changes to a payroll database shall be recorded in a trace file with before and after values.

例如，这可以指定软件跟踪处理活动的要求。为了满足最低监管或财务标准，某些应用程序需要这样的跟踪。例如，审计跟踪要求可能会规定，工资数据库的所有更改都应记录在跟踪文件中，记录前后值。

9.5.17 Software system attributes软件系统属性

Specify the required attributes of the software product.The following is a partial list of examples:

指定软件产品的所需属性。以下是部分示例清单：

a)  Reliability - Specify the factors required to establish the required reliability of the sofware system at time of delivery.
可靠性-指定在交付时软件系统要具备的可靠性所需的因素。

b)  Availability - Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint,recovery,and restart.
可用性—指定为保证整个系统的可用性级别（如检查点、恢复和重新启动）所需的因素。

c)  Security - Specify the requirements to protect the software from accidental or malicious access,use modification,destruction,or disclosure.Specific requirements in this area could include the need to:
安全性-指定保护软件免受意外或恶意访问、修改、破坏或泄露的要求。这方面的具体要求可包括：

1)Utilize certain cryptographic techniques;
采用某种加密技术

2)Keep specific log or history data sets;
保留日志或历史数据集

3)Assign certain functions to different modules;
将某些功能分配给不同的模块

4)Restrict communications between some areas of the program;
限制程序某些区域之间的通信

5)Check data integrity for critical variables;
检查关键变量的数据完整性

6)Assure data privacy.
确保数据隐私。

d)  Maintainability - Specify attributes of software that relate to the ease of maintenance of the sofware itself.These may include requirements for certain modularity,interfaces,or complexity limitation.Requirements should not be placed here just because they are thought to be good design practices.
可维护性-指定与软件易于维护相关的属性。这些可能包括对模块化、接口或复杂性限制的要求。需求不应该仅仅因为被认为是良好的设计实践而存在。

e)  Portability - Specify attributes of software that relate to the ease of porting the sofware to other host machines and/or operating systems,including:
可移植性-指定反应将软件移植到其他主机或操作系统的容易程度的属性，包括：

1)Percentage of elements with host-dependent code;
具有主机依赖代码的元素百分比；

2)Percentage of code that is host dependent;
依赖主机的代码百分比；

3)Use of a proven portable language;
使用可移植的编程语言；

4)Use of a particular compiler or language subset;
使用特定的编译器或语言子集；

5)Use of a particular operating system.
使用特定操作系统。

9.5.18 Verification验证

Provide the verification approaches and methods planned to qualify the sofware.The information items for verification are recommended to be given in a parallel manner with the information items in subclause 9.5.10 to 9.5.17.

提供用于鉴定软件的验证步骤和方法。建议以与第9.5.10款至第9.5.17款中的信息项平行的方式提供用于验证的内容。

9.5.19 Supporting information支撑材料

The SRS should contain additional supporting information including

SRS应包含其他支持信息，包括：

a)  Sample input/output formats,descriptions of cost analysis studies,or results of user surveys;
样本输入/输出格式、成本分析研究说明或用户调查结果；

b)  Supporting or background information that can help the readers of the SRS;

b)有助于SRS读者的支持或背景资料；

c)  A description of the problems to be solved by the software;

c)说明软件要解决的问题；

d)  Special packaging instructions for the code and the media to meet security,export,initial loading,or other requirements.

d)针对代码和媒体的特殊包打包说明，以满足安全性、出口、初始装载或其他需求的要求。

d)

The SRS should explicitly state whether or not these information items are to be considered part of the requirements.

SRS应明确说明是否将这些信息项视为要求的一部分。

Annex A(normative) System operational concept附录A(规范)系统操作概念

A.1 Overview概述

A System Operational Concept (OpsCon) document describes what the system will do (not how it will do it)and why (rationale).An OpsCon is a user-oriented document that describes system characteristics of the to-be-delivered system from the user's viewpoint.The OpsCon document is used to communicate overallquantitative and qualitative system characteristics to the acquirer，user，supplier and other organizational elements.

系统运行概念（OpsCon）文件描述了系统将做什么（而不是如何做）以及为什么（根本原因）。OpsCon是面向用户的文档，从用户的角度描述待交付系统的系统特性。OpsCon文件用于向需方、用户、供应商和其他组织传达总体的定量和定性的系统特征。

Users of this International Standard should consider producing separate System OpsCon and SyRSdocuments.The OpsCon document can then focus on all necessary requirements engineering tasksspecifically from the users point of view,and can use vocabulary and ilustration tools that are familiar to theuser's experience and knowledge base.The benefits include: definition of the issues，constraints and opportunities related to human involvement with the system,production of an estimate of what has not beenspecified,clarification of the constraints,opportunities and degree of flexibility required of the system,andsetting of priorities for the requirements.

这个国际标准的用户应该考虑生产单独的系统OpsCon和注射器文件。OpsCon文档可以从用户的角度专门关注所有必要的需求工程任务，并且可以使用用户经验和知识库熟悉的词汇和说明工具。这些好处包括：定义与人类参与系统相关的问题、约束和机会，对尚未明确的内容进行评估，澄清系统所需的约束、机会和灵活性，以及为需求设定优先级。

The project shall product the following information items in accordance with the project's policies with respect to the System Operational Concept document.The information items in subclause A.2.5 shall be produced inthe course of producing the Stakeholder Requirements Specification document as referred to in subclause 9.3.16 and 9.3.17.

项目应根据项目关于系统运行概念文件的政策，生成以下信息项。子条款A.2.5中的信息项应在生成子条款9.3.16和9.3.17中提及的干系人需求规范文件的过程中生成。

NOTE 1 A separate OpsCon document enables the engineering team during development of the SyRS to focus more on the technical community and the vocabulary and knowledge base of the system suppliers and users.

注1：单独的OpsCon文件使工程团队在SyRS开发过程中能够更加关注技术社区以及系统供应商和用户的词汇和知识库。

NOTE 2 Similarities exist between the Concept of Operations and the System Operational Concept.The Concept of Operations describes the view from the organization regarding the intent and assumptions for operation(s).It captures a broad picture of the organizational levell purpose.See Annex B.

注2：作战概念与系统作战概念之间存在相似之处。运营概念描述了组织对运营意图和假设的看法。它概括了组织层面的目标。见附件B。

A.2 Operational concept document (OpsCon)业务概念文件(OpsCon)

Describe each of the essential elements of an OpsCon document.Each version of an OpsCon document based on this guide should contain a title and a revision notice that uniquely identifies the document.Revision information may include the project name,version number of the document,date of release,approval signatures,a list of clauses that have been changed in the current version of the document,and a list of signatures,version numbers and dates of release of all previous versions of the document.The approved OpsCon document should be placed under configuration control.

描述OpsCon文件的每个基本要素。基于本指南的OpsCon文件的每个版本都应包含一个标题和一个唯一标识该文件的修订通知。修订信息可能包括项目名称、文件版本号、发布日期、批准签名、文件当前版本中已更改的条款列表，以及所有以前版本文件的签名、版本号和发布日期列表。批准的OpsCon文件应置于配置控制之下。

NOTE Extracted from IEEE 1362-1998:IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document,Clause 4.In this International Standard,concept of operation (ConOps) is replaced by operational concept (OpsCon).

注释摘自IEEE 1362-1998：IEEE信息技术系统定义操作概念指南（ConOps）文件，第4条。在本标准中，操作概念（ConOps）被操作概念（OpsCon）取代。

The preface of an OpsCon document provides information that the writer wants the reader to know prior to reading the document.The preface should include the purpose of the document,the scope of activities that resulted in its development,who wrote the document and why,the intended audience for the document,and resulted in its development,who wrote the document and why,the intended audience for the document,and the expected evolution of the document.

OpsCon文档的前言提供了作者希望读者在阅读文档之前了解的信息。前言应包括文件的目的、导致其发展的活动范围、编写文件的人和原因、文件的预期受众和导致其发展的人、编写文件的人和原因、文件的预期受众，以及文件的预期演变。

A table of contents,a list of figures,and a list of tables should be included in every OpsCon document.

每个OpsCon文件中都应包括目录、图表列表和表格列表。

A.2.1 Scope范围

Provide an overview of the OpsCon document and the system to which it applies.

提供OpsCon文档及其应用系统的概述。

A.2.1.1 Identification

Include the identifying number,title,and abbreviation (if applicable) of the system or subsystem to which this OpsCon applies.If related OpsCon documents for an overall system have been developed in a hierarchical or network manner,the position of this document relative to other OpsCon documents should be described.

包括本OpsCon适用的系统或子系统的识别号、标题和缩写（如适用）。如果整个系统的相关OpsCon文件是以分层或网络方式编制的，则应说明该文件相对于其他OpsCon文件的位置。

A.2.1.2 Document overview文件概述

Summarize and expand on the purposes of motivations for the OpsCon document.The intended audience for the document should also be mentioned.Describe any security or privacy considerations associated with use of the OpsCon.Outline the remaining parts of this guide.The purposes of an OpsCon document will,in most cases,be:

总结并扩展OpsCon文件的动机目的。还应提及该文件的预期受众。描述与使用OpsCon相关的任何安全或隐私注意事项。概述本指南的其余部分。在大多数情况下，OpsCon文件的目的是：

To communicate the user's needs for and expectations of the proposed system to the acquirer and/or supplier;or

向需方和/或供应商传达用户对拟议系统的需求和期望；或

To communicate the acquirer's or supplier's understanding of the users' need and how the system shall operate to fulfil those needs.

传达需方或供应商对用户需求的理解，以及系统应如何运行以满足这些需求。

However,an OpsCon document might also serve other purposes,such as building consensus among several user groups,among several acquirer organizations,and/or among several suppliers.

然而，OpsCon文件也可能用于其他目的，例如在多个用户群体、多个需方和/或多个供应商之间建立共识。

The audience of an OpsCon document can be a variety of people:

OpsCon文档的读者可以是各种各样的人：

-     Users might read it to determine whether their needs and desires have been correctly specified by their representative or to verify the suppliers understanding of their needs.
用户可能会阅读它，以确定其代表是否正确指定了他们的需求和愿望，或验证供应商对其需求的理解。

-     Acquirers might read it to acquire knowledge of the user's needs and/or supplier's understanding of those needs.
需方可能会阅读它，以了解用户的需求和/或供应商对这些需求的理解。

-     Suppliers will typically use the OpsCon document as a basis for system life cycle activities,and to familiarize new team members with the problem domain and the system to which the OpsCon applies.
供应商通常将OpsCon文件用作系统生命周期活动的基础，并使新团队成员熟悉问题域和OpsCon适用的系统。

A.2.1.3 System overview系统概述

Briefly state the purpose of the proposed system or subsystem to which the OpsCon applies.Describe the general nature of the system,and identify the project sponsors,user agencies,supplier organizations,support agencies,certifiers or certifying bodies,and the operating centres or sites that will run the system.ALSO identify other documents relevant to the present or proposed system.A graphical overview of the system is strongly recommended.This can be in the form of a context diagram,a top-level object diagram,or some other type of diagram that depicts the system and its environment.Documents that might be cited include,but are not limited to: the project authorization,relevant technical documentation,significant correspondence,documents concerning related projects,risk analysis reports,and feasibility studies.

简要说明OpsCon适用的拟议系统或子系统的用途。描述系统的一般性质，并确定项目发起人、用户机构、供应商组织、支持机构、认证机构或认证机构，以及将运行系统的运营中心或站点。还应确定与当前或拟议系统相关的其他文件。强烈建议以图形方式概述系统。这可以是上下文图、顶层对象图或描述系统及其环境的其他类型的图的形式。可能引用的文件包括但不限于：项目授权、相关技术文件、重要信函、相关项目文件、风险分析报告和可行性研究。

A.2.2 Referenced documents参考文件

List the document number,title,revision,and date of all documents referenced in the OpsCon document.ALSO,identify the source for all documents not available through normal channels.

列出OpsCon文件中引用的所有文件的文件编号、标题、版本和日期。此外，还应确定无法通过正常渠道获得的所有文件的来源。

A.2.3 Current system or situation目前的制度或情况

Describe the system or situation (either automated or manual) as it currently exists.If there is no current system on which to base changes,describe the situation that motivates the proposed system.In this case,the following sections will be tailored as appropriate to describe the motivating situation.Introduce the problem domain.This enables readers to better understand the reasons for the desired changes and improvements.

描述当前存在的系统或情况（自动或手动）。如果没有当前的制度作为变更的基础，请描述激励拟议制度的情况。在这种情况下，以下部分将根据情况进行调整，以描述激励情况。介绍问题域。这使读者能够更好地理解所需更改和改进的原因。

A.2.3.1 Background,objectives,and scope背景、目标和范围

Provide an overview of the current system or situation,including as applicable,background,mission,objectives,and scope.In addition to providing the background for the current system,this section should provide a brief summary of the motivation for the current system.Examples of motivations for a system might include automation of certain tasks or countering of certain threat situations.The goals for the current system should also be defined,together with the strategies,solutions,tactics,methods,and techniques used to accomplish them.The modes of operation,classes of users,and interfaces to the operational environment define the scope of the proposed system,which are summarized in this section and defined in greater detail in subsequent sections.

提供当前系统或情况的概述，包括背景、任务、目标和范围（如适用）。除了提供当前系统的背景信息外，本节还应简要概述当前系统的动机。系统动机的示例可能包括某些任务的自动化或应对某些威胁情况。还应确定当前系统的目标，以及用于实现这些目标的战略、解决方案、战术、方法和技术。操作模式、用户类别和操作环境接口定义了拟议系统的范围，本节对此进行了总结，并在后续章节中进行了更详细的定义。

A.2.3.2 Operational policies and constraints业务政策和制约因素

Describe any operational policies and constraints that apply to the current system or situation.Operational policies are predetermined management decisions regarding the operations of the current system,normally in the form of general statements or understandings that guide decision making activities.Policies limit decision-making freedom but do allow for some discretion.Operational constraints are limitations placed on the operations of the current system.Examples of operational constraints include the following:

描述适用于当前系统或情况的任何操作策略和约束。运营政策是关于当前系统运营的预先确定的管理决策，通常以指导决策活动的一般性声明或谅解的形式。政策限制了决策自由，但也允许一些自由裁量权。操作约束是对当前系统操作的限制。操作限制的例子包括：

a)   A constraint on the hours of operation of the system,perhaps limited by access to secure terminals

b)   A constraint on the number of personnel available to operate the system
对可供操作该系统的人员人数的限制

c)   A constraint on the computer hardware (for example,shall operate on computer X)
对计算机硬件的限制(例如，应在计算机X上运行)

d)   A constraint on the operational facilities,such as office space
对办公空间等业务设施的限制

A.2.3.3 Description of the current system or situation对现行制度或情况的说明

Provide a description of the current system or situation,including the fllowing,as appropriate:

酌情说明目前的制度或情况，包括流动情况：

a)   The operational environment and its characteristics
作业环境及其特点

b)   Major system elements and the interconnection among those elements
主要系统要素和这些要素之间的相互联系

c)   Interfaces to external systems or procedures
与外部系统或程序的接口

d)   Capabilities,functions/services,and features of the current system
当前系统的能力、功能/服务和特性

e)   Charts and accompanying descriptions depicting inputs,outputs,data flows,control flows,and manual and automated processes sufficient to understand the current system or situation from the user's point of and automated processes sufficient to understand the current system or situation from the user's point of view

f)   Cost of system operations
系统运作费用

g)   Operational risk factors
操作风险因素

h)   Performance characteristics,such as speed, throughput, volume, frequency, workload
性能特性，如速度、吞吐量、体积、频率、工作量

i)   i) Quality attributes,such as: availability, correctness, efficiency, expandability, flexibility, interoperability, maintain-ability, portability, relability, reusability,supportability,survivability,and usability
质量属性，例如：可用性、正确性、效率、可扩展性、灵活性、互操作性、可维护性、可移植性、可重用性、可重用性、可支持性、生存性和可用性。

j)   Provisions for safety,security,privacy,integrity,and continuity of operations in emergencies
紧急情况下行动的安全、安保、隐私、完整性和连续性的规定

k)   Logistics requirements to support system
后勤支持系统所需经费

k)

Since the purpose of this section is to describe the current system and how it operates,it is appropriate to useany tools and/or techniques that serve this purpose.lt is important that the description of the system be simpleenough and clear enough that all intended readers of the document can fully understand it.lt is also importantto keep in mind that the OpsCon document is written using the users' terminology.

由于本节的目的是描述当前系统及其运行方式，因此宜使用用于此目的的任何工具和/或技术。重要的是，系统的描述要足够简单和清晰，以便所有文档的预期读者都能完全理解它。同样重要的是要记住，OpsCon文档是用用户的术语编写的。

Graphical tools should be used wherever possible，especially since OpsCon documents should be understandable by several different types of readers.Useful graphical tools include,but are not limited to,work breakdown structures (WBS)，N2 charts，sequence or activity charts,functional flow block diagrams,structure charts,allocation charts,data flow diagrams (DFD),object diagrams,context diagrams,storyboards,and entity-relationship diagrams.

应尽可能使用图形工具，因为OpsCon文档有不同的读者。可选的图形工具包括工作分解结构（WBS）、N2图、序列或活动图、功能流程框图、结构图、分配图、数据流程图（DFD）、对象图、上下文图、故事板和实体关系图等。

The description of the operational environment should identify， as applicable，the facilities，equipment,computing hardware,software,personnel,and operational procedures used to operate the existing system.This description should be as detailed as necessary to give the readers an understanding of the numbers,versions,capacity,etc.,of the operational equipment being used.For example,if the current system containsa database,the capacity of the storage unit(s) should be specified，provided the information exerts aninfluence on the users' operational capabilities.Likewise,if the system uses communication links，thecapacities of those links should be specified if they exert influence on factors such as user capabilities,response time,or throughput.

操作环境的描述应确定（如适用）用于操作现有系统的设施、设备、计算硬件、软件、人员和操作程序。该说明应尽可能详细，以使读者了解所用操作设备的数量、版本、容量等。例如，如果当前系统使用的数据库，对用户的操作能力有影响，则应指定数据库的容量。同样，如果系统使用的通讯链路对用户能力、响应时间或吞吐量等因素产生影响，则应指定这些链路的容量。

Those aspects of safety,security,and privacy that exert influence on the operation or operational environmentof the current system should be described.

应说明对现行系统的运作或运作环境产生影响的安全、安保和隐私方面的情况。

The information in this section should be organized as appropriate to the system or situation,as long as a clear description of the existing system is achieved.if parts of the descriptions are voluminous,they can be included in an appendix or incorporated by reference.An example of material that might be included in an appendix would be a data dictionary.An example of material to be included by reference might be a detailed manual of operational policies and procedures for the current system.

本节中的信息应根据系统或外部环境的实际情况进行组织，易变能明确的描述现有系统。如果有的部分描述篇幅很大，则可以将其单独成文，通过附录或引用的形式形成一个整体。比如数据字典就可以放在附录中，当前系统的操作手册则可以作为参考材料。

A.2.3.4 Modes of operation for the current system or situation现行制度或情况的运作方式

Describe the various modes of operation for the current system or situation (e.g.， operational，degraded,maintenance,training,emergency,alternate-site,peacetime,wartime,ground-based， flight,active,and idlemodes).All of the modes that apply to all classes of users should be included.Important modes to include are degraded,backup,and emergency modes,if such exist.This is especially true if these modes involve different geographical sites and equipment that have significant impacts on the operational aspects of the system.

描述当前系统或外部环境的各种运行模式（例如，运行模式、降级模式、维护模式、训练模式、应急模式、备用站点模式、和平时期模式、战时模式、陆基模式、飞行模式、现役模式和空闲模式）。应包括适用于所有类别用户的模式。重要模式包括降级、备份和紧急模式（如果存在）。如果这些模式涉及对系统运行方面有重大影响的不同地理位置和设备，则尤其如此。

This section can be further divided into lower-level sections,one for each mode described.System processes,procedures,and capabilities or functions should be related to each mode,as appropriate， perhaps using across reference matrix.

本节可进一步分为较低层次的部分，每一种模式描述一节，系统进程、过程和功能或功能应酌情与每种模式相关联，也许可以跨引用矩阵使用。

A.2.3.5 User classes and other involved personnel用户班和其他有关人员

A user class is distinguished by the ways in which users interact with the system.Factors that distinguisuser class include common responsibilities,skill levels，work activities，and modes of interaction with the system.Different user classes may have distinct operational scenarios for their interactions with the system.

用户分类通过用户与系统交互的方式来区分。区分用户类别的因素包括共同责任、技能水平、工作活动以及与系统的交互模式。不同的用户分类与系统的交互可能有不同的操作场景。

In this context,a user is anyone who interacts with the existing system,including operational users,data entrypersonnel,system operators,operational support personnel,software maintainers,and trainers.

在此上下文中，用户是与现有系统交互的任何人，包括操作用户、数据入口人员、系统操作员、操作支持人员、软件维护人员和培训师。

This section can be organized further,as follows,if it is helpful in communicating the content.

如果本节有助于内容的交流，可以进一步组织，如下所示。

A.2.3.5.1 Organizational structure组织结构

Describe the existing organizational structures of the various user groups and user classes that are involved with the current system.Organizational charts are useful graphic tools for this purpose.

描述与当前系统相关的各种用户组和用户分类的现有组织结构。组织结构图是用于此目的的有用图形工具。

A.2.3.5.2 Profiles of user classes用户分类的概况

Provide a profile of each user class for the current system.If some users play several roles,each role shouldbe identified as a separate user class.

为当前系统提供每个用户分类的配置文件。如果一些用户扮演多个角色，那么每个角色都应该被标识为一个单独的用户分类。

Each user class for the current system,including operators and maintainers， should be described in a separate section.Each of these should provide a description of the user class，including responsibilities, education, background, skill level,activities,and modes of interaction with the current system.

当前系统的每个用户类，包括操作员和维护人员，都应该在单独的一节中描述。其中每一项都应提供用户类别的描述，包括职责、教育、背景、技能水平、活动以及与当前系统的交互模式。

A.2.3.5.3 Interactions among user classes用户分类之间的交互

Describe interactions among the various user classes involved with the current system，in particular,interactions among user groups,operators,and maintainers. Interactions that occur among the users of thesystem,and between users and non-users,both within the organization and across organizational boundaries,if they are relevant to the operation of the existing system,should be described.Informal as well as formal interactions should be included.

描述各种用户分类之间的交互，特别是用户组、操作员和维护人员之间的交互。如果与现有系统的运行相关，则应描述系统用户之间、用户与非用户之间、组织内部和跨组织边界发生的交互。应包括非正式和正式的互动。

A.2.3.5.4 Other involved personnel其他有关人员

Describe other personnel who will not directly interact with the system,but who have an influence on,and are influenced by,the present system.Examples include executive managers,policy makers,and the user's clients.Although these individuals do not have hands-on interaction with the system,they may significantly influence,and be influenced by,the new or modified system.

描述不会直接与系统互动，但与系统互有影响的其他人员。比如执行经理、决策者和用户的客户。尽管这些人没有与系统进行实际互动，但他们可能会对系统产生重大影响，并受其影响。

A.2.3.6 Support environment支助环境

Describe the support concepts and support environment for the current system,including the support agency or agencies,facilities,equipment,support software,repair or replacement criteria,maintenance levels and cycles,and storage,distribution,and supply methods.

描述当前系统的支持概念和支持环境，包括支持机构、设施、设备、支持软件、维修或更换标准、维护级别和周期，以及存储、分发和供应方法。

A.2.4 Justification for and nature of changes变革的理由和性质

Describe the shortcomings of the current system or situation that motivate development of a new system or modification of an existing system.Provide a transition from the discussion of the current system or situation,to the description of the proposed system.If there is no current system on which to base changes,this section should so indicate and provide justification for the features of the new system.

描述当前系统的缺点或促使开发新系统或修改现有系统的原因。提供从讨论当前系统、现状到描述拟开发系统的过程。如果没有当前系统作为变更的基础，本节应说明开发新系统的理由。

A.2.4.1 Justification for changes改变的理由

This section should:

本节应：

a)   Briefly summarize new or modified aspects of the user needs, missions, objectives,environments,interfaces,personnel,or other factors that require a new or modified system,
简要总结用户需求、任务、目标、环境、接口、人员或其他需要新系统或修改系统的因素的新的或修改的方面，

b)   Summarize the deficiencies or limitations of the current system or situation that make it unable to respond to new or changed factors,and
总结当前系统或情况的缺陷或限制，使其无法应对新的或变化的因素，以及

c)   Provide justification for a new or modified system.
为新的或修改过的系统提供理由

1)   If the proposed system is to meet a new opportunity,describe the reasons why a new system should be developed to meet this opportunity.
如果拟开发的系统是为了满足新的机会，请描述为什么应开发新系统以满足此机会。

2)   If the proposed system improves a current operation,describe the rationale behind the decision to modify the existing system (e.g.,to reduce life cycle costs or improve personnel eficiency).
如果拟开发的系统改进了当前的操作，描述修改现有系统的决定背后的理由（例如，降低生命周期成本或提高人员效率）。

3)   If the proposed system implements a new functional capability,explain why this function is necessary.
如果系统实现了一种新的功能功能，说明为什么需要这种功能。

3)

A.2.4.2 Description of desired changes所需更改的说明

Summarize new or modifed capabilities,functions,processes,interfaces,and other changes needed to respond to the factors identified in A.2.4.1.Changes should be based on the current system.If there is no existing system on which to base changes,summarize the capabilities to be provided by a new system.This description should include the following,as appropriate:

总结为响应A.2.4.1中确定的因素所需的新的或修改的能力、功能、流程、接口和其他变更。更改应基于当前系统。如果没有现有的系统作为变更的基础，总结新系统提供的功能。该说明应包括以下内容（视情况而定）：

-     Capability changes.Description of the functions and features to be added,deleted,and modified in order for the new or modified system to meet its objectives and requirements.
能力变化。为使新系统或修改后的系统满足其目标和要求而添加、删除和修改的功能和特性的说明。

-     System processing changes.Description of the changes in the process or processes of transforming data that will result in new output with the same data,the same output with new data,or both.
系统处理更改。描述转换数据过程中的更改，这些更改将导致使用相同数据的新输出、使用新数据的相同输出或两者兼而有之。

-     Interface changes.Description of changes in the system that will cause changes in the interfaces and changes in the interfaces that will cause changes in the system.
接口更改。系统中会导致接口更改的更改以及会导致系统更改的接口更改的说明。

-     Personnel changes.Description of changes in personnel caused by new requirements,changes in user classes,or both.
人事变动。说明因新需求、用户类别变更或两者兼而有之而导致的人员变更。

-     Environment changes.Description of changes in the operational environment that will cause changes in the system functions,processes,interfaces,or personnel and/or changes that should be made in the environment because of changes in the system functions,processes,interfaces,or personnel.
环境变化。描述操作环境中的变化，这些变化将导致系统功能、过程、接口或人员的变化和/或由于系统功能、过程、接口或人员的变化而应在环境中进行的变化。

-     Operational changes.Description of changes to the user's operational policies,procedures,methods,or daily work routines caused by the above changes.
业务变化。说明由上述变更引起的用户操作政策、程序、方法或日常工作程序的变更。

-     Support changes.Description of changes in the support requirements caused by changes in the system functions,processes,interfaces,or personnel and/or changes in the system functions,processes,interfaces,or personnel caused by changes in the support environment.
-支持更改。描述由系统功能、过程、接口或人员变更引起的支持需求变更和/或由支持环境变更引起的系统功能、过程、接口或人员变更。

-     Other changes.Description of other changes that will impact the users,but that do not fit under any of the above categories.
其他变化。说明对用户有影响除上述任何类别之外的其他更改。

-

A.2.4.3 Priorities among changes变化中的优先事项

Identify priorities among the desired changes and new features.Each change should be classified as essential,desirable,or optional.Desirable and optional changes should be prioritized within their classes.If there is no existing system on which to base changes,this section should classify and prioritize the features of the proposed system.

确定所需更改和新功能之间的优先级。每项变更应分为基本变更、可取变更或可选变更。理想的和可选的变化应该在他们的课程中优先考虑。如果没有现有的系统作为变更的基础，本节应对拟议系统的功能进行分类和优先排序。

Essential features.Features that shall be provided by the new or modified system.The impacts that would result if the features were not implemented should be explained for each essential feature.

基本特征。新系统或修改系统应提供这类功能。逐项说明和解释如果不实施这些功能，将产生的影响。

Desirable features.Features that should be provided by the new or modified system.Desirable features should be prioritized.Reasons why the features are desirable should be explained for each desirable feature.

令人满意的特征。新系统或修改后的系统应提供的功能。理想的特性应该优先考虑。对于每一个需要的特征，应该解释为什么这些特征是需要的。

Optional features.Features that might be provided by the new or modified system.Optional features should be prioritized.Reasons why the features are optional should be explained for each optional feature.

可选功能。新系统或修改后的系统可能提供的功能。应优先考虑可选功能。对于每个可选功能，应解释为什么这些功能是可选的。

Classifying the desired changes and new features into essential,desirable,and optional categories is important to guide the decision making process during the life cycle of the proposed system.This information is also helpful in cases of budget or schedule cuts or overruns,since it permits determination of which features have to be finished,and which ones can be delayed or omitted.

将功能或变更分为基本、期望和可选三类，对于在生命周期中指导决策过程非常重要。该信息在预算削减或超支、进度超期的情况下也很有用，因为据此可以确定哪些功能必须完成，哪些功能可以延迟或不做。

A.2.4.4 Changes considered but not included已考虑但未包括的变动

Identify changes and new features considered but not included in A.2.4.2,and the rationale for not including them.By describing changes and features considered but not included in the proposed system,the authors document the results of their analysis activities.This information can be useful to other personnel involved with the system,whether it be users,acquirers,or suppliers should they want to know if a certain change or feature was considered,and if so,why it was not included.In software especially,there are few,if any,outward signs of what has been changed,improved or is still unsafe or unsecure (e.g..in certain scenarios or workarounds).

确定A.2.4.2中仅考虑但未真正包括在内的变更和新功能，以及不包括这些变更和新功能的理由。通过描述所考虑但未包含的变更和特征，作者记录了其分析活动的结果。该信息对系统各方都有用，无论是用户、需方还是供应商，据此各方可以了解是否考虑了某项变更或功能，为什么不包括在内。特别是在软件方面，很难从外部看到什么已经改变、什么不安全或（例如，在某些场景或解决方法中）。

A.2.4.5 Assumptions and constraints假设和制约因素

Describe any assumptions or constraints applicable to the changes and new features identfied.This should include all assumptions and constraints that will affect users during the life cycle of the new or modified system.An assumption is a condition that is taken to be true.An example of an assumption is that the system workload will double over the next two years,thus a new system with higher performance is required.A constraint is an extermally imposed limitation placed on the new or modified system or the processes used.Examples of constraints include external interface requirements,and limits on schedule and budget.

描述适用于已识别变更和新功能的任何假设或约束。这应包括在新系统或修改系统的生命周期内影响用户的所有假设和约束。假设是被认为是真实的条件。假设的一个例子是，系统工作量将在未来两年翻一番，因此需要一个性能更高的新系统。约束是对新的或修改过的系统或使用的过程施加的外部限制。约束的例子包括外部接口要求、进度和预算限制。

A.2.5 Concepts for the proposed system目标系统的概念

Describe the proposed system that results from the desired changes specified in subclause A.2.4.Describe the proposed system in a high-level manner,indicating the operational features that are to be provided without specifying design details.Methods of description to be used and the level of detail in the description will depend on the situation.The level of detail should be sufficient to fully explain how the proposed system is envisioned to operate in fulling users' needs and buyer's requirements.In some cases,it may be necessary to provide some level of design detail in the OpsCon.The OpsCon should not contain design specifications,but it may contain some examples of typical design strategies,for the purpose of clarifying operational details of the proposed system.In the event that actual design constraints need to be included in the description of the proposed system,they shall be explicitly identified as required to avoid possible misunderstandings.

描述因为子条款A.2.4中规定的预期变更而产生的拟开发或变更的系统。以高层次的方式描述目标的系统，指出系统需要提供的操作特性，而不设计设计细节。如何描述、描述的详细程度视具体情况而定，以足以充分解释目标系统如何在满足用户需求和买方要求的情况下运行为标准。有时，也可能需要在OpsCon中提供设计细节。OpsCon不应包含设计规范，但可以包含一些典型设计策略的示例，以澄清目标系统的操作细节。如果需要在目标系统的描述中包含实际设计约束，则应根据需要明确确定这些约束，以避免产生误解。

NOTE If some of the features of the proposed system are the same as the features of the original system,then the comment 'No change' should appear after the section number and name.

注：如果目标系统的某些功能与原系统功能相同，则应标注“无变化”。

A.2.5.1 Background,objectives,and scope背景、目标和范围

Provide an overview of the new or modifed system,including,as applicable,background,mission,objectives,and scope.In addition to providing the background for the proposed system,this section should provide a brief summary of the motivation for the system.Examples of motivations for a system might include automation of certain tasks or taking advantage of new opportunities.The goals for the new or modified system should also be defined,together with the strategies,solutions,tactics,methods,and techniques proposed to achieve those goals.The modes of operation,classes of users,and interfaces to the operational environment define the scope of the proposed system,which are summarized in this section and defined in greater detail in subsequent sections.

提供系统的概述，包括背景、任务、目标和范围。除了系统背景外，本节还应简要概述系统动机，比如可以实现某些任务的自动化或利用新机会。还应确定系统的目标，以及为实现目标而提出的战略、解决方案、战术、方法和技术。操作模式、用户类别和操作环境接口则定义了系统的范围，本节对此进行了总结，并在后续章节中进行了更详细的定义。

A.2.5.2 Operational policies and constraints业务政策和制约因素

Describe operational policies and constraints that apply to the proposed system.Operational policies are predetermined management decisions regarding the operation of the new or modified system,normally in the form of general statements or understandings that guide decision-making activities.Policies limit decision-making freedom,but do allow for some discretion.Operational constraints are limitations placed on the operations of the proposed system.Examples of operational constraints include the following:

描述适用于目标系统的运营政策和约束。运营政策是关于系统运行的管理决策，通常以指导决策活动的一般性声明或理解的形式。政策限制了决策自由，但也允许一些自由裁量权。操作限制是指对系统的操作施加的限制。操作限制的例子包括：

-     A constraint on the hours of operations of the system,perhaps limited by access to secure terminals,
对系统运行时间的限制，可能受限于对安全终端的访问，

-     A limiting constraint on the number of personnel available to operate the system,
对可操作系统的人员数量的限制,

-     A limiting constraint on the computer hardware (e.g,shall operate on computer X),and
对计算机硬件的限制约束(例如，应在计算机X上运行)，以及

-     A limiting constraint on the operational facilitis,such as office space.
对办公空间等运营设施的限制。

A.2.5.3 Description of the proposed system

This section will contain the major portion of the description of the proposed system.It provides a description of the proposed system,including the following,as appropriate:

本节将包含目标系统描述的主要部分。它提供了系统的说明，包括以下内容：

a)   The operational environment and its characteristics,
作业环境及其特点，

b)   Major system elements and the interconnections among these elements,
主要的系统要素和这些要素之间的相互联系，

c)   Interfaces to external systems or procedures,
与外部系统或程序的接口，

d)   Capabilties or functions of the proposed system,
拟议系统的能力或职能，

e)   Charts and accompanying descriptions depicting inputs,outputs,data flow,and manual and automated processes sufficient to understand the proposed system or situation from the user's point of view,
描述输入、输出、数据流以及足以从用户角度理解拟议系统或情况的手动和自动流程的图表和附带说明，

f)   Cost of systems operations,
系统运营成本，

g)   Operational risk factors,
操作风险因素

h)   Performance characteristics,such as speed,throughput,volume,frequency,

h)性能特性，如速度、吞吐量、体积、频率、

i)   Quality attributes,such as: relability, availability, correctness, efficiency, expandability, flexibilit, interoperability, maintainability, portability,reusability,supportability,survivability,and usability,and

i)质量属性，例如：可重用性、可用性、正确性、效率、可扩展性、灵活性、互操作性、可维护性、可移植性、可重用性、可支持性、生存性和可用性，以及

j)   Provisions for safety,security,privacy,integrity,and continuity of operations in emergencies,
紧急情况下行动的安全、安保、隐私、完整性和连续性的规定，

k)   Logistics requirements to support system.
后勤保障系统的要求。

Since the purpose of this section is to describe the proposed system and how it should operate,it is appropriate to use any tools and/or techniques that serve that purpose.See A.2.3.3.for further discussion.

由于本节的目的是描述拟议的系统及其运行方式，因此使用任何工具和/或技术都是合适的。见A.2.3.3。供进一步讨论。

A.2.5.4 Modes of operation操作方式

Describe the various modes of operation for the proposed system (for example， regular,degraded,maintenance,training,emergency,alternate-site, peacetime, wartime,ground-based,flight,active,and idle modes).Include all of the modes that apply to all user classes.Important modes to include are degraded,modes).Include all of the modes that apply to all user classes.Important modes to include are degraded,backup,and emergency modes,if such exist.This is especially true if these modes involve different geographical sites and equipment that have significant impacts on the system.

描述目标系统的各种运行模式（例如，常规模式、降级模式、维护模式、训练模式、应急模式、备用模式、平时模式、战时模式、陆基模式、飞行模式、主动模式和空闲模式）。包括适用于所有用户类的所有模式。要包括的重要模式是降级模式（模式）。包括适用于所有用户类的所有模式。重要的模式包括降级、备份和紧急模式（如果存在）。如果这些模式涉及对系统有重大影响的不同地理位置和设备，则尤其如此。

This section can be further divided into lower-level sections,one for each mode described.System processes,procedures,and capaibllties or functions should be related to each mode.

该部分可进一步分为较低级别的部分，每种模式一个。系统流程、过程和能力或功能应与每种模式相关。

A.2.5.5 User classes and other involved personnel用户分类和其他相关人员

A user class is distinguished by the ways in which the users interact with the system.Factors that distinguish a user class include responsibilities,skill level,work activities,and mode of interaction with the system.Different user classes may have distinct operational scenarios for their interactions with the system.In this context,a user classes may have distinct operational scenarios for their interactions with the system.In this context,a user is anyone who will interact with the proposed system,including operational users,data entry personnel,system operators,operational support personnel,maintainers,and trainers.This section can be further divided into lowerlevel sections if it is helpful in communicating the content.

用户类通过用户与系统交互的方式来区分。区分用户类别的因素包括职责、技能水平、工作活动以及与系统的交互模式。不同的用户类与系统的交互可能有不同的操作场景。在这种情况下，用户类与系统的交互可能有不同的操作场景。在这种情况下，用户是将与提议的系统进行交互的任何人，包括操作用户、数据输入人员、系统操作员、操作支持人员、维护人员和培训人员。如果有助于传达内容，本节可进一步分为较低级别的部分。

A.2.5.5.1 Organizational structure 组织结构

Describe the organizational structures of the various user groups and user classes that will be involved with the proposed system.Organizational charts are useful graphic tools for this purpose.

描述系统涉及的各种用户组和用户类别的组织结构。组织结构图是用于此目的的有用图形工具。

A.2.5.5.2 Profiles of user classes用户分类的概况

Provide a profile of each user class for the proposed system.If some users play several roles,each role should be identified as a separate user class.

为系统提供每个用户类别的概要文件。如果一些用户扮演多个角色，那么每个角色都应该被标识为一个单独的用户类。

Each user class for the proposed system,including operators,maintainers and trainers,should be described in a separate section.Each section should provide a description of the user class,including responsibilties, education, background, skill level,activities,and envisioned modes of interaction with the proposed system.

系统的每个用户类别，包括操作员、维护人员和培训人员，应在单独的章节中进行描述。描述包括用户类别的描述，包括职责、教育、背景、技能水平、活动以及与拟议系统交互的设想模式。

A.2.5.5.3 Interactions among user classes用户类之间的交互

Describe interactions among the various user classes that may be involved with the proposed system.In particular,interaction among user groups,operators,and maintainers should be described.Interactions that will occur among the users of the proposed system,and between users and non-users,both within the organization and across interfacing organizations,if they are relevant to the operation of the proposed system,should be described.Informal as well as formal interactions should be included.

描述可能涉及目标系统的各种用户类别之间的交互。特别是，应该描述用户组、操作员和维护人员之间的交互。如果系统的用户之间、用户与非用户之间、组织内部和接口组织之间发生的交互与拟议系统的运行相关，则应予以说明。应包括非正式和正式的互动。

A.2.5.5.4 Other involved personnel其他有关人员

Describe other personnel who will not directly interact with the system,but who have an infuence on,and are influenced by,the present system.Examples include executive managers,policy makers,and the user's clients.Although these individuals do not have hands-on interaction with the system,they may significantly influence and be influenced by,the new or modifed system.

对其他人员进行说明，这些人员不会直接与系统互动，但对当前系统之间存在相互影响。比如：执行经理、决策者和用户的客户等。尽管这些人没有与系统进行实际互动，但他们可能会对新系统或修改后的系统产生重大影响并受到其影响。

A.2.5.6 Support environment支持环境

Describe the support concepts and support environment for the proposed system,including the support agency or agencies,facilities,equipment,support sofware,repair or replacement criteria,maintenance levels and cycles,and storage,distribution,and supply methods.

描述目标系统的支持概念和支持环境，包括支持机构、设施、设备、支持软件、维修或更换标准、维护级别和周期，以及存储、分配和供应方法。

A.2.6 Operational scenarios业务场景

A scenario is a step-by-step description of how the proposed system should operate and interact with its users and its external interfaces under a given set of circumstances.Scenarios should be described in a manner that will allow readers to walk through them and gain an understanding of how all the various parts of the proposed system function and interact.The scenarios tie together all parts of the system,the users,and other entities by describing how they interact.Scenarios may also be used to describe what the system should not do.

场景是一种分步骤的描述，说明在给定的一组环境下，系统应如何运行以及如何与其用户及外部接口进行交互。场景的描述方式应能让读者了解场景，了解系统的各个部分是如何运作和交互的。这些场景通过描述系统、用户和其他实体的交互方式，将它们联系在一起。场景也可以用来描述系统不应该做什么。

Scenarios should be organized into sections and subsections,each describing an operational sequence that ilustrates the roles of the system,its interactions with users,and interactions with other systems.Operational scenarios should be described for all operational modes and all classes of users identified for the proposed system.Each scenario should include events,actions,stimuli,information,and interactions as appropriate to provide a comprehensive understanding of the operational aspects of the proposed system.Prototypes,storyboards,and other media,such as video or hypermedia presentations,may be used to provide part of this storyboards,and other media,such as video or hypermedia presentations,may be used to provide part of this information.

场景应分为多个部分和子部分，每个部分都描述了一个操作序列，说明了系统的角色、与用户及其他系统的交互。应包含系统的所有运行模式和所有类别用户的操作场景。每种情况都应包括事件、行动、刺激、信息和互动，以提供对系统运行方面的全面理解。原型、故事板和其他媒体形式（如视频或超媒体演示文稿）可用于提供部分故事板，其他媒体形式（如视频或超媒体演示文稿）可用于提供部分信息。

In most cases,it will be necessary to develop several variations of each scenario,including one for normal operation,one for stress load handling,one for exception handling,one for degraded mode operation,etc.

在大多数情况下，有必要为每个场景开发几个变体，比如一个用于正常操作、一个用于压力负载处理、一个用于异常处理、一个用于降级模式操作等。

Scenarios play several important roles.The first is to bind together all of the individual parts of a system into a comprehensible whole.Scenarios help understand how all the pieces interact to provide operational capabilities.The second role of scenarios is to provide operational details for the proposed system.This enables better understanding of the users' roles,how the system should operate,and the various operational features to be provided.

场景扮演着几个重要角色。首先是将一个系统的各个部分结合在一起，形成一个容易理解的整体。场景有助于理解所有部件如何相互作用以提供操作能力。其次是提供系统的操作细节。这有助于更好地了解用户的角色、系统应该如何操作以及要提供的各种操作功能。

Scenarios can also support the development of simulation models that help in the definition and allocation of derived requirements,identification,and preparation of prototypes to address key issues.In addition,scenarios can serve as the basis for the first draft of the users' manual,and as the basis for developing acceptance test plans.Scenarios are also useful for the acquirer and the supplier to verify that the system design will satisfy the stakeholders' needs and expectations.

场景还可以支持仿真模型的开发，这些模型有助于定义和分配衍生需求、识别和准备原型，以解决关键问题。此外，场景可以作为用户手册初稿的基础，也可以作为制定验收测试计划的基础。场景也有助于需方和供应商验证系统设计是否满足各方的需求和期望。

Scenarios can be presented in several different ways.One approach is to specify scenarios for each major processing function of the proposed system.Using this approach,this section would contain one section for each process.Each section would then contain several more lower-level sections,one for each scenario supported by that process.An alternative approach is to develop thread-based scenarios,where each scenario follows one type of transaction type through the proposed system.In this case,each section would contain one scenario for each interaction type,plus scenarios for degraded,stress loaded,and back-up modes of operation.Other alternatives include following the information flow through the system for each user capability,following the control flows,or focusing on the objects and events in the system.

场景呈现方式。一种方式是为拟议系统的每个主要处理功能指定场景。使用这种方法，本节将为每个流程包含一个部分。然后，每个部分将包含多个较低级别的部分，一个用于该流程支持的每个场景。另一种方法是开发基于线程的场景，其中每个场景对应一种事务类型。在这种情况下，每个部分将包含每个交互类型的一个场景，以及降级、压力加载和备份操作模式的场景。其他替代方案包括针对每个用户能力跟踪系统中的信息流、跟踪控制流或关注系统中的对象和事件。

Scenarios are an important element of an OpsCon,and should therefore receive substantial emphasis.The number of scenarios and level of detail specified will be proportional to the perceived risk and the criticality of the project.

场景是OpsCon的一个重要元素，因此应该得到充分重视。指定的场景数量和详细程度将与感知的风险和项目的关键性成比例。

A.2.7 Summary of impacts影响摘要

Describe the operational impacts of the proposed system on the users,the suppliers,and the operations and maintenance organizations.Also describe the temporary impacts on users,acquirers,suppliers,and the operations and maintenance organizations during the period of time when the new system is being developed,installed,or trained.

描述系统对用户、供应商以及运营和维护组织的运营影响。还应说明在新系统开发、安装或培训期间对用户、需方、供应商以及运营和维护组织的正常业务的影响。

This information is provided in order to allow all affected organizations to prepare for the changes that will be brought about by the new system and to allow for planning of the impacts on the acquirer,user groups,and the operations and maintenance organizations during the development of,and transition to the new system.

提供该信息的目的是让所有受影响的组织为新系统带来的变化做好准备，并在开发和过渡到新系统期间规划对需方、用户群体以及运营和维护组织的影响。

A.2.7.1 Operational impacts业务影响

Further divide this section into lower-level sections to describe the anticipated operational impacts on the user,support,and operations or maintenance organizations during operation of the proposed system.These impacts may include the following:

我们进一步将将内容细化，以描述在系统运行期间对用户、支持、运营或维护组织的预期运营影响。这些影响可能包括以下方面：

-     Interfaces with primary or altemate computer operating centres,
与主要计算机操作中心或Altemate计算机操作中心的接口，

-     Changes in procedure,
程序上的改变，

-     Use of new data sources,
使用新的数据来源，

-     Changes in quantity,type,and timing of data to be input into the system,
要输入系统的数据的数量、类型和时间发生变化，

-     Changes in data retention requirements,
数据保留要求的变化，

-     New modes of operation based on emergency,disaster,or acident conditions,
基于紧急情况、灾难或恶劣条件的新的操作模式，

-     New methods for providing input data if the required data are not readily available,
如果不容易获得所需数据，则提供输入数据的新方法，

-     Changes in operational budget,and
业务预算的变动，以及

-     Changes in operational risks.
业务风险的变化。

-

A.2.7.2 Organizational impacts组织影响

Further divide this section to describe the anticipated operational impacts on the user,development,and support or maintenance organization during operation of the proposed system.These impacts may include the following:

进一步描述在拟议系统运行期间对用户、开发、支持或维护组织的预期运行影响。这些影响可能包括以下方面：

-     Modification of resposibilties,

-改变责任，

-     Addition or elimination of job positions,

-增加或取消职位，

-     Training or retraining users,
持续培训用户，

-     Changes in numbers,skill levels,position identifiers,or locations of personnel,and
人员人数、技能级别、职位标识或地点的变化，以及

-     Numbers and skill levels of personnel needed for contingency operation at one or more altermate sites following an emergency,disaster,or accident.
紧急情况、灾难或事故发生后，在一个或多个交替现场进行应急操作所需的人员数量和技能水平。

-

A.2.7.3 Impacts during development开发过程中的影响

Further divide this section to describe the anticipated impacts on the user,development,and support or maintenance agency or agencies during the development project for the proposed system.These impacts may include the following:

进一步描述系统开发期间对用户、开发和支持或维护机构的可能影响。这些影响包括以下方面：

-     Involvement in studies,meetings,and discussions prior to award of the contract,

-在授予合同之前参与研究、会议和讨论，

-     User and support involvement in reviews and demonstrations,evaluation of initial operating capabilities and evolving versions of the system,development or modification of databases,and required training,

-用户和支持人员参与审查和演示，评估系统的初始运行能力和不断变化的版本，开发或修改数据库，以及所需的培训，

-     Parallel operation of the new and existing systems,and

-新系统和现有系统的并行运行，以及

-     Operational impacts during system testing of the proposed system.

-系统测试期间的操作影响。

-

A.2.8 Analysis of the proposed system系统分析

Provide an analysis of the benefits,limitations,disadvantages,and alternatives considered for the proposed system.

分析提议系统的优点、局限性、缺点和考虑的替代方案。

A.2.8.1 Benefits福利

Provide a qualitative (and to the extent possible,quantitative) summary of the benefits to be provided by the proposed system.This summary should include the below items,as applicable.In each case,the benefts should be related to deficiencies identified.

对系统带来的益处进行定性（并尽可能定量）总结。该总结应包括以下各项（如适用）。在每种情况下，收益都应与所识别的缺陷相关。

-     New capabilties.Additional new features or functionality.

-新能力。额外的新特性或功能。

-     Enhanced capabilities.Upgrades to existing capabilties.

-增强能力。升级到现有能力。

-     Deleted capabilities.Unused,obsolete,confusing,or dangerous capabilities removed.

-删除功能。未使用、过时、令人困惑或危险的功能。

-     Improved performance.Better response time,reduced storage requirements,improved quality,decreased system/user workload,etc.

-提高了性能。更好的响应时间、更少的存储需求、更高的质量、更少的系统/用户工作量等。

A.2.8.2 Disadvantages and limitations缺点和限制

Provide a qualitative (and to the extent possible,quantitative) summary of the disadvantages and/or limitations of the proposed system.Disadvantages might include the need to retrain personnel,rearrange work spaces,or change to a new style of user interface,limitations might include features desired by users but not included,degradation of existing capabilities to gain new capabilities,or greater-than-desired response time for certain complex operations.

对系统的缺点、局限性进行定性或定量总结。缺点可能包括需要对人员进行再培训，调整工作空间，或更改为新的用户界面风格，限制可能包括缺少用户希望的功能，新功能导致现有功能的退化，或某些复杂操作的响应时间超过预期。

A.2.8.3 Alternatives considered考虑的替代办法

Describe major alternatives considered,the trade-off analysis results,and the rationale for the decisions reached.In the context of an OpsCon document,alternatives are operational alternatives and not design alternatives,except to the extent that design alternatives may be limited by the operational capabilities desired in the new system.This information can be useful to determine,now and at later times,whether a given approach was analyzed and evaluated,or why a particular approach or solution was rejected.This information would probably be lost if not recorded.

描述考虑的主要备选方案、权衡结果以及做出决定的理由。在OpsCon文件中，备选方案是操作备选方案，而不是设计备选方案，除非设计备选方案可能受到新系统所需操作能力的限制。这些信息有助于现在和以后确定是否对给定的方法进行了分析和评估，或者为什么拒绝某个特定的方法或解决方案。如果不记录，这些信息可能会丢失。

A.2.9 Appendices附录

To facilitate ease of use and maintenance of the OpsCon document,some information may be placed in appendices to the document.Charts and classifed data are typical examples.Each appendix should be referenced in the main body of the document where that information would normally have been provided.Appendices may be bound as separate documents for easier handling.

为了便于OpsCon文件的使用和维护，一些信息可以放在文件的附录中。比如图表和分类数据。在文件的正文中可以引用附录。为便于处理，附录可作为单独文件装订。

A.2.10 Glossary词汇

A glossary should be maintained and updated during the processes of concept analysis and development of the OpsCon document.Include an alphabetical listing of all acronyms and abbreviations,along with their meanings as used in this document,and a list of any terms and definitions needed to understand the document.To avoid unnecessary work due to misinterpretations,all definitions should be reviewed and agreed upon by all involved parties.

在概念分析和OpsCon文件编制过程中，应维护术语表。包括按字母顺序列出的所有首字母缩略词和缩写词，以及它们在本文件中的含义，以及理解本文件所需的任何术语和定义的列表。为了避免误解，所有定义都应经过所有相关方的审查和同意。

Annex B(informative)附件B (资料丰富)

Concept of operations行动概念

B.1 Overview概览

This Annex provides guidance for the Concept of Operations (ConOps) document in terms of information items.This document is not a requirements specification document required in this International Standard,but is intended to help users of this standard in the requirements elicitation task as practical documentation to understand the background of the project and communicate the overall business and system characteristics.

本附件为操作概念（ConOps）文件的信息项提供了指导。本文件不是本标准要求的需求规范文件，但旨在帮助标准使用者在需求获取任务中作为实战文档理解项目背景，并传达总体业务和系统特征。

The ConOps,at the organization level,addresses the leadership's intended way of operating the organization.It may refer to the use of one or more systems,as black boxes,to forward the organization's goals and objectives.The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations of the business with using the system to be developed,existing systems,and possible future systems.This document is frequently embodied in long-range strategic plans and annual operational plans.The ConOps document serves as a basis for the organization to direct the overall characteristics of the future business and systems,for the project to understand its background,and for the users of this International Standard to implement the stakeholder requirements elicitation.The ConOps document should include the following information items.

在组织层面，ConOps解决了领导层对组织的运行方式。运营方式是指使用一个或多个系统作为黑匣子来推进组织的目标。ConOps文件描述了组织对使用待开发系统、现有系统和未来系统的整体运营或一系列业务运营的期望或意图。该文件经常体现在长期战略计划和年度运营计划中。ConOps文件是组织指导未来业务和系统总体特征、项目了解其背景以及本国际标准用户实施干系人需求获取的基础。ConOps文件应包括以下内容。

B.2 Concept of operation document作业文件的概念

B.2.1 Purpose目的

Describe the purpose of this document by describing the current status of the organization,the goal of the long-range strategic plan,and gaps between them.

通过描述组织的当前状态、长期战略计划的目标以及它们之间的差距来描述本文件的目的。

B.2.2 Scope范围

Describe the scope of this document by specifying the organization's business domains to which it applies.

通过指定本文件适用的组织业务领域来描述本文件的范围。

B.2.3 Strategic plan战略计划

Describe the long-range strategic plan for the organization's business and resultant systems.This includes description when the current business of the organization should be changed and what systems should be implemented and operated.The plan may contain options with priority.

描述公司业务及相关系统的长期战略计划。这包括何时调整组织的业务，以及应实施和操作哪些系统。该计划可能包含具有优先权的选项。

B.2.4 Effectiveness有效性

Estimate the effectiveness expected by implementing the plan.

评估实施计划的预期效果。

B.2.5 Overall operation全面业务

B.2.5.1 Context背景

Describe an overall view for the organization's business,which business function or organizational unit is covered by which existing systems,and which is to be covered by planned systems.For more detailed description,major data resources and flows may be mapped onto the view.

描述组织业务的总体视图，哪些业务职能或组织单元由哪些现有系统覆盖，哪些将由新的系统覆盖。可以通过将主要数据资源和流映射到视图上进行更详细的描述。

B.2.5.2 Systems系统

List and outline the existing systems and systems to be developed in the future.

列出并概述现有系统和未来要开发的系统。

B.2.5.3 Organizational unit组织单位

List and relate with each other the organizational units that play roles in business operation,systems operation,and their management.

列出在业务运营、系统运营及其管理中发挥作用的组织单位，并相互联系。

B.2.6 Governance治理

B.2.6.1 Governance policies治理政策

Describe policies or principles which will govern any critical business and technological decisions in implementing the plan.

描述在实施该计划时，将管理任何关键业务和技术决策的政策或原则。

B.2.6.2 Organization组织

Describe the organization unit that is responsible for the governance,and describe policies on organizational structure and human resource in system development.

描述负责治理的组织单元，描述系统开发中的组织结构和人力资源政策。

B.2.6.3 Investment plan投资计划

Describe plans on possible investment for the development of systems and depict how the policies should be managed.

描述系统开发可能的投资计划，并说明应如何管理政策。

B.2.6.4 Information asset management信息资产管理

Describe policies of how information assets are managed and define which organizational unit is responsible for the management.

描述如何管理信息资产的策略，并定义负责管理的组织单位。

B.2.6.5 Security安全

Describe policies on security.

描述有关安全的政策。

B.2.6.6 Business continuity plan业务连续性计划

Describe policies on business continuity plan.

描述有关业务连续性计划的政策。

B.2.6.7 Compliance遵守情况

Describe policies on regal and regulatory compliance.

描述有关帝王和法规遵守的政策。

Annex C(informative)附件C(资料丰富)

Process Mapping from ISO/IEC 15288 and ISO/IEC 12207

来自ISO/IEC 15288和ISO/IEC 12207的过程映射

C.1 Stakeholder requirements definition process干系人需求定义过程

Table C.1 identfies the activities involved in the stakeholder requirements definition process and the applicable subclause in Clause 6 with additional application guidance.The detailed processes between ISO/IEC 15288 and ISO/IEC 12207 have some different headings and language,but have been aligned to match the equivalent processes.

表C.1确定了干系人需求定义过程中涉及的活动，以及第6条中的适用子条款和附加应用指南。ISO/IEC 15288和ISO/IEC 12207之间的详细过程有一些不同的标题和语言，但已调整以匹配等效过程。

Table C.1-Mapping of 15288,12207,and 29148 clauses on Stakeholder Requirements Definition Process

C.2 Requrements analysis Process需求分析过程

Table C.2 identifies the activities involved in the requirements analysis process and the applicable subclausein Clause 6 with additional application guidance.

表C.2列出了需求分析过程中所涉及的活动和适用的第6条，并提供了更多的应用指南。

C.3 Other technical requirements-related processes其他技术需求相关的过程

Annex D (normative) 附件D (规范)

 Tailoring policies裁剪要求

D.1 Introduction导言

This Annex provides requirements for the tailoring of the information item contents in this International Standard.Tailoring is not a requirement for conformance to the standard.In fact,tailoring is not permitted if a claim of 'full conformance' is to be made.If a claim of 'tailored conformance' is made,then the following process shall be applied to perform the tailoring.

本附录规定了本标准中信息项内容的裁剪要求。剪裁不是符合标准的要求。事实上，如果要声称“完全符合”，就不允许裁剪。如果提出“定制合规性”要求，则应采用以下程序进行定制。

D.2 Information item tailoring process信息项目裁剪过程

D.2.1 Purpose目的

The purpose of the Tailoring Process is to adapt the information item contents of this International Standard to satisfy particular circumstances or factors that:

裁剪过程的目的是调整本国际标准的信息项内容，以满足以下特定情况或因素：

a) Surround an organization that is employing this International Standard in an agreement;

围绕在协议中采用该国际标准的组织；

b) Influence a project that is required to meet an agreement in which this International Standard is referenced;

影响需要满足引用本国际标准的协议的项目；

c) Reflect the needs of an organization in order to supply products or services.

反映一个组织的需要，以便提供产品或服务。

D.2.2 Outcomes成果

As a result of successful implementation of the Tailoring Process,modified or new information item contents are defined to achieve the purpose of the requirements specification documents provided in this International Standard.

由于裁剪过程的成功实施，定义了修改或新的信息项内容，以实现本国际标准中提供的需求规范文件的目的。

D.2.3 Activities and tasks活动和任务

If this International Standard is tailored,then the organization or project shall implement the following activities:

如果定制了本标准，则组织或项目应实施以下活动：

a) Identify and document the circumstances that infuence tailoring.These infuences include,but are not limited to:

确定并记录影响裁剪的情况。这些影响包括但不限于：

1)stability of,and variety in,operational environments;

作战环境的稳定性和多样性；

2)novelty,size,and complexity;

新颖性、尺寸和复杂性；

3)starting date and duration of utilization;

开始使用日期和持续时间；

4)emerging technology opportunities;

新出现的技术机会；

5)profile if budget and organizational resources available;

6)availability of the services of enabling systems;

提供授权系统的服务；

7)the need to conform to other standards.

必须符合其他标准。

b) Obtain input from all parties affected by the tailoring decisions.This includes,but may not limited:

征求受裁剪决定影响的所有各方的意见。这包括但不限于：

1)the stakeholders;

利益攸关方；

2)the interested parties to an agreement mode by the organization;

组织协议模式的干系人；

3)the contributing organizational functions.

c) Select the information item contents that require tailoring and delete them.

选择需要裁剪的信息项内容并将其删除。

NOTE 1 Irrespective of tailoring,organizations and projects are always permitted to create additional information item contents beyond those required for conformance to this standard.

注1：无论如何裁剪，组织和项目始终允许创建超出本标准要求的附加信息项内容。

NOTE 2 An organization or project may encounter a situation where there is the desire to modifty the information item contents.Modification is performed by deleting the information item contents (making the appropriate claim of tailored conformance) and,with careful consideration of consequences,creating information item contents that describe additional information beyond those of the tailored standard.

注2：组织或项目可能会遇到希望修改信息项内容的情况。修改是通过删除信息项内容（做出适当的定制一致性声明），并在仔细考虑后果的情况下，创建描述定制标准之外其他信息的信息项内容来执行的。