CMMI1.3《需求开发》翻译

CMMI1.3《需求开发》翻译

REQUIREMENTS DEVELOPMENT需求开发

目次

Purpose目的 (1)

Introductory Notes简介 (1)

Related Process Areas相关过程域 (5)

Specific Goal and Practice Summary特定目标和实践摘要 (6)

Specific Practices by Goal各特定目标的特定实践 (6)

SG1Develop Customer Requirements开发客户需求 (6)

SP1.1Elicit Needs引出需要 (7)

SP1.2Transform Stakeholder Needs into Customer

Requirements将相关干系人的

需要转化为客户需求 (9)

SG2Develop Product Requirements开发产品需求 (10)

SP2.1Establish

件需求 (11)

SP2.2Allocate Product Component Requirements分配产品组件需求 (13)

SP2.3Identify Interface Requirements识别接口需求 (15)

SG3Analyze and Validate Requirements分析并确认需求 (16)

SP3.1Establish Operational Concepts and Scenarios建立操作概念和场景 (17)

SP3.2Establish a Definition of Required Functionality and

Quality Attributes

建立必要的功能和质量特性定义 (19)

SP3.3Analyze Requirements分析需求 (20)

SP3.4Analyze Requirements to Achieve Balance分析需求以取得平衡 (22)

Product and Product Component

Requirements建立产品或产品组

SP3.5Validate Requirements确认需求 (23)

i

REQUIREMENTS DEVELOPMENT需求开发

An Engineering Process Area at Maturity Level3

成熟度3级的工程类过程域

Purpose目的

The purpose of Requirements Development(RD)is to

elicit,analyze,and establish customer, product,and product

component requirements.

需求开发（RD）的目的是引出、分析并建立顾客、产品及产品组件的需求。

Introductory Notes简介

This

product

process area describes three types of

requirements:customer requirements,product requirements,and

component together,these

requirements address

the needs of relevant stakeholders,including needs pertinent

to various product lifecycle , acceptance testing

criteria)and

,responsiveness,safety,reliability,

maintainability).Requirements also address constraints caused by

the selection of design solutions (e.g.,integration of commercial

off-the-shelf products,use of a particular architecture pattern).

本过程域描述了三类需求：客户需求、产品需求和产品组件需求。综合来看，这些需求标识了相关干系人的需要，包括与各产品生命周期阶段有关的需要（如验收测试标准）以及与产品属性有关的需要（如响应能力、安全性、可靠性、可维护性）。这些需求同时也标识了由于所选设计方案带来的约束（如集成商业产品、使用特殊的架构模式）。

All development projects have ements

product

are the basis for development of requirements

includes the following activities:

所有的开发项目都有需求。需求是设计的基础。需求开发包括以下活动：

Elicitation,analysis,validation,and

customer

prioritized

needs,expectations,and

customer requirements

communication

constraints

that

to

constitute

of

an

obtain

understanding of what will satisfy stakeholders

引导、分析、确认以及沟通客户需要、期望和约束，以获得具有优先级的客户需求，这些需求构成什么将满足相关干系人的需要的共同理解。

Collection and coordination of stakeholder needs

收集并协调相关干系人的需要

Development of the lifecycle requirements of the product

开发产品生命周期需求

Establishment of the customer functional and quality

attribute requirements

建立客户功能和质量特性的需求

Establishment of initial product and product component

requirements consistent with customer

1

requirements

建立与客户需求一致的初始产品和产品组件需求

This process area addresses all customer requirements rather

than only product level requirements because the customer can

also provide specific design requirements.

由于客户也可能提出特殊的设计要求，因此这个过程域标识的所有客户需求不仅仅是产品层面的需求。Customer requirements are

further refined into product and product component

addition to customer requirements,product and

product component requirements are derived from the selected

design hout the process areas,where the

terms“product”and“product

their components.

将客户需求进一步提炼成产品和产品组件需求。除客户需求之外，产品和产品组件需求也来源于所选的设计方案。在整个过程域中，使用的术语“产品”和“产品组件”其隐意也包括服务、服务体系及其组件。

Requirements are identified and refined throughout the

phases of the product decisions,subsequent

corrective actions,and feedback during each phase of the

product’s lifecycle are analyzed for impact on derived and

allocated requirements.

在整个产品生命周期的各个阶段需要对需求进行识别和精练。对设计决策、随后的纠正措施和产品的生命周期各个阶段所产生的反馈进行分析，以了解它们对已分配和导出的需求的影响。

The Requirements Development process area includes three

specific Develop Customer Requirements specific goal

addresses defining a set of customer requirements to use in the

development of product Develop Product

Requirements specific goal addresses defining a set of product

or product component requirements to use in the design of

products and product Analyze and Validate

Requirements specific goal addresses the analysis of

customer,product,and product component requirements to

define,derive,and understand the specific

practices of the third specific goal are intended to assist the

specific practices in the first two specific processes

associated with the

component”are used,their

intended meanings also encompass services,service systems,and

Requirements Development process area and processes

associated with the Technical Solution process area can interact

recursively with one another.

需求开发过程域包含三个特定目标。“开发客户需求”特定目标说明如何定义一组用于开发产品需求的客户需求。“开发产品需求”特定目标说明如何定义一组用于产品和产品组件设计的产品和产品组件需求。“分析和确认需求”特定目标说明对客户、产品及产品组件的需求进行分析，以定义、导出并理解需求。第三个特定目标的特定实践意在辅助前两个特定目标的特定实践。需求开发过程域和技术解决方案的过程可递归地相互影响。

Analyses are used to understand,define,and select the

requirements at all levels from competing

analyses include the following:

2

对竞争的备选方案进行分析，以理解、定义和选择所有各层级的需求。包括如下分析活动：

Analysis of needs and requirements for each product

lifecycle phase,including needs of relevant stakeholders,the

operational environment,and factors that reflect overall

customer and end-user expectations and satisfaction,such as

safety,security,and affordability

产品生命周期各阶段的需要和需求分析，包括相关干系人的需要、操作环境以及反映所有客户及最终用户期望和满意度的因素，如安全性，保密性和负担能力。

Development of an operational concept

开发操作概念

Definition of the required functionality and quality attributes

定义需要的功能和质量特性

This definition of required functionality and quality attributes

describes what the product is to do.(See the definition

of“definition of required functionality and quality attributes”in

the glossary.)This definition

a

can

partitioning

include

of the descriptions,decompositions,and

functions(or in object oriented analysis what has been referred to

as“services”or“methods”)of the product.

这里定义需要的功能和质量特性，描述该产品是做什么的（见词汇表中“需要的功能和质量特性需求”的定义）。这里的定义可以包括产品的描述、分解和函数划分（或者面向对象分析中被称作为“服务”或“方法”）。

In addition,the definition specifies design considerations or

constraints on how the required functionality will be realized in

the y attributes address such things as product

availability;maintainability;modifiability;timeliness,throughput,and responsiveness;reliability; security;and quality

attributes will emerge as architecturally significant and thus drive

the development of the product architecture.

此外，定义还详述在如何实现产品需要的功能方面的设计依据或约束。质量特性标识了诸如此类需求：产品的可用性、可维护性、可修改性；实时性、处理能力和响应能力；可靠性；安全性和可测性。一些质量特性将显露架构的重要，因而驱动产品架构的开发。

Such analyses occur recursively at successively more detailed

layers of a product’s architecture until sufficient detail is

available to enable detailed design,acquisition,and testing of the

product to a result of the analysis of requirements

and the operational concept(including

disposal),the functionality,support,maintenance,and

manufacturing or production concept produces more derived

requirements,including consideration of the following:

不断地递归地分析产品架构的更细层次，直到可以进行产品详细设计、采购和测试。作为分析需求和操作概念（包括功能、支持、维

护和引退）的结果，制造或生产概念会产生更多的导出需求。包括如下考虑：

Constraints of various types

各种类型的约束

3

Technological limitations

技术限制

Cost and cost drivers

成本和成本动因

Time constraints and schedule drivers

时间约束和进度动因

Risks

风险

Consideration of issues implied but not explicitly stated by

the customer or end user

对客户或最终用户隐含而未明确阐述问题的考虑

Factors introduced by the developer’s unique business

considerations,regulations,and laws

由开发商独特的商业考虑、规程和法规引入的因素

A hierarchy of logical ,functions and

subfunctions,object classes and subclasses; processes;other

architectural entities)is established through iteration with the

evolving operational ements

to these

are

logical refined,derived,and allocated

ements and logical entities are allocated to

products,product components,people,or associated

the case of iterative or incremental development,the

requirements are also allocated to iterations or increments.

随着操作概念的展开，逻辑实体的层次（如功能和子功能，对象类和子类，过程及其他构件实体）在不断迭代中建立。需求被精练、

获得并分配到逻辑实体。需求和逻辑实体再分配给产品、产品组件、人或者相关的过程。对于迭代或增量开发来说，需求也被分配到迭代或增量中。

Involvement of relevant stakeholders in both requirements

development and analysis gives them visibility into the evolution

of activity continually assures them that the

requirements are being properly defined.

相关干系人参与需求开发和需求分析，给他们展示需求演变的可视性。这些活动可以持续使他们相信需求被正确地定义了。

For product lines,engineering processes(including

requirements development)may be applied to at least two levels

in the an organizational or product line

level,a“commonality and variation analysis”is performed to

help elicit,analyze,and establish core assets for use by projects

within the product the project level,these core assets are

then used as per the product line production plan as part of the

project’s engineering activities.

对于产品线来说，工程过程（包括需求开发）在组织中可能至少应用于两个层面。在组织或产品线层面，“共性和差异性分析”用于帮助引出、分析和建立在产品线中项目使用的核心资产。在项目层面，这些核心资产如同在项目工程活动中一样，成为产品线的生产计划的一部分。

In Agile environments,customer needs and ideas are

iteratively elicited,elaborated,analyzed,and validated.

4

Requirements are documented in forms such as user

stories,scenarios,use cases,product backlogs,and the results of

Refer to the Product Integration process area for more

information about ensuring interface compatibility.

关于确保接口兼容性的更多信息，请参考产品集成过程域。

Refer to the Technical Solution process area for more

information about selecting product component solutions and

developing the design.

关于选择产品组件解决方案和开发设计的更多信息，请参考技术解决过程域。

Refer to the Validation process area for more information

about validating product or product components.

关于确认产品或产品组件的更多信息，请参考确认过程域。

Refer to the Verification process area for more information

about verifying selected work products.

关于验证所选工作产品的更多信息，请参考验证过程域。

Refer to the Configuration Management process area for

more information about tracking and controlling changes.

关于跟踪和控制变更的更多信息，请参考配置管理过程域。

Refer to the Requirements Management process area for

more information about managing requirements.

关于管理需求的更多信息，请参考需求管理过程域。

Refer to the Risk Management process area for more

information about identifying and analyzing risks.

5

关于识别和分析风险的更多信息，请参考风险管理过程域。

Specific Goal and Practice Summary特定目标和实践摘要

SG1Develop Customer Requirements开发客户需求

SP1.1Elicit Needs引导需要

SP1.2Transform Stakeholder Needs into Customer

Requirements开发客户需求

SG2Develop Product Requirements开发产品需求

SP2.1Establish Product and Product Component

Requirements建立产品与产品组件需求

SP2.2Allocate Product Component Requirements分配产品组

件需求

SP2.3Identify Interface Requirements识别接口需求

SG3Analyze and Validate Requirements分析并确认需求

SP3.1Establish Operational Concepts and Scenarios建立操作概念及场景

SP3.2Establish a Definition of Required Functionality and

Quality Attributes建立必要功能的定义

SP3.3Analyze Requirements分析需求

SP3.4Analyze Requirements to Achieve Balance分析需求以取得平衡

SP3.5Validate Requirements确认需求

Specific Practices by Goal各特定目标的特定实践

SG1Develop Customer Requirements开发客户需求

Stakeholder needs,expectations,constraints,and interfaces

are collected and translated into customer requirements.

收集相关干系人的需要、期望、约束及接口并转换成客户需求。

The needs of ,customers,end

users,suppliers,builders,testers,manufacturers, logistics support

staff)are the basis for determining customer

stakeholder

expectations,constraints,interfaces,operational

product concepts are analyzed,

needs,

concepts,and

harmonized,refined,and

elaborated for translation into a set of customer requirements.

相关干系人（例如：客户、最终用户、供用商、实施人员、测试人员、制造厂商和后勤支持人员等）的需要是确定客户需求的基础。分析、协调、精炼并细化干系人的需要、期望、约束、接口、操作概念以及产品概念，以便转化为一套客户需求。

Frequently,stakeholder needs,expectations,constraints,and

interfaces are poorly identified or stakeholder

needs,expectations,constraints,and limitations should be clearly

identified and understood,an iterative process is used

throughout the life of the project to accomplish this

facilitate the required interaction,a surrogate for the end user or

customer is frequently involved to represent their needs and help

resolve customer relations or

6

marketing part of the organization as well as members of the

development team from disciplines such as human engineering

or support can be used as nmental,legal,and

other constraints should be considered when creating and

resolving the set of customer requirements.

干系人的需求、期望、约束及接口常被粗略地识别或相互矛盾。由于干系人的需要、期望、约束和限制需要清晰地识别和理解，因此，为实现这个目标，在整个项目的生命周期中须要迭代进行识别。为减少需要的迭代，最终用户或客户代表常常代表他们的需要、帮助解决冲突而参与进来。组织的客户关系或市场部门，以及来自各学科的开发团队成员，例如：人体工程学或支持部门，都可视为此类的代表。在创建或分解这套客户需求时，环境、法律法规以及其他约束应一并考虑。

SP 1.1Elicit Needs引出需要

Elicit stakeholder needs,expectations,constraints,and

interfaces for all phases of the product lifecycle.

引出相关干系人对产品生命周期各阶段的需要、期望、约束及接口。

Eliciting goes beyond collecting requirements by proactively

identifying additional requirements not explicitly provided by

onal requirements should address the various

product lifecycle activities and their impact on the product.

引出需要活动远不止是收集需要，还需主动地识别客户尚未明确提出的附加需要。附加需求应标识对各种各样的产品生命周期活动及

它们对产品的影响。

Examples of techniques to elicit needs include the following:

7

Brainstorming

8

商业环境需要（如实验室、测试和其他设施，以及信息技术基础设施）

Transform stakeholder needs,expectations,constraints,and

interfaces into prioritized customer requirements.

将相关干系人的需要、期望、约束和接口等转化为具有优先级的客户需求。

The various inputs from the relevant stakeholders should be

consolidated,missing information should be obtained,and

conflicts should be resolved as customer requirements are

developed and customer requirements can

include needs,expectations,and constraints with regard to

verification and validation.

在开发客户需求时，应对来自相关干系人的各种输入进行整理，获取遗漏的信息，并解决相关冲突。客户需求包括与验证和确认有关的需要、期望及约束。

In some situations,the customer provides a set of

requirements to the project,or the requirements exist as an

output of a previous project's these situations,the

customer requirements could conflict with the relevant

stakeholders'needs,expectations,constraints,and interfaces and

will need to be transformed into the recognized set of customer

requirements after appropriate resolution of conflicts.

在某些情况下，客户提供了一组项目需求，或作为早先的项目活

动的输出，需求已经存在。在这些情况下，客户需求可能与相关干系人的需要、期望、约束和接口发生冲突。妥善地解决冲突后，需要将之转换成一组被公认的客户需求。

Relevant stakeholders representing all phases of the

product's lifecycle should include business as well as technical

this way,concepts for all product related lifecycle

processes are

9

considered concurrently with the concepts for the

er requirements result from informed decisions

on the business as well as technical effects of their requirements.

作为产品生命周期的所有阶段代表的相关干系人，应兼具业务和技术职能。只有这样，与生命周期过程相关的所有产品的概念才能与产品概念同步考虑。客户需求源于在业务以及需求的技术特点方面明智的判断。

Example Work Products工作产品样例

tized customer requirements

对客户需求优先顺序进行排序

er constraints on the conduct of verification

客户在进行验证方面的约束

er constraints on the conduct of validation

客户在进行确认方面的约束

Subpractices子实践

ate stakeholder needs,expectations,constraints,and

interfaces into documented customer requirements.

将干系人的需要、期望、约束及接口转换成客户需求文档。

ish and maintain a prioritization of customer

functional and quality attribute requirements.

建立并维护客户对功能和质量特性需求的优先级。

Having prioritized customer requirements helps to

determine project,iteration,or increment prioritization

ensures that functional and quality attribute requirements critical

to the customer and other stakeholders are addressed quickly.

对客户需求进行优先级划分可以帮助确定计划、或迭代、增量的范围。优先级划分确保了对客户和其他干系人至关重要的功能和质量特性需求被快速识别。

constraints for verification and validation.

明确对验证和确认的约束。

SG2Develop Product Requirements开发产品需求

Customer requirements are refined and elaborated to

develop product and product component requirements.

精练并详细阐述客户需求，以开发产品及产品组件需求。

Customer requirements are analyzed in conjunction with the

development of the operational concept to derive more detailed

and precise sets of requirements called“product and product

component requirements.”Product and product component

requirements address the needs associated with each product

lifecycle d requirements arise from

constraints;consideration of issues implied but not explicitly

stated in the customer requirements baseline;factors introduced

by the selected architecture,product lifecycle,and design;and the

developer’s unique business

10

requirements are reexamined with each

successive,lower level set of requirements and architecture,and

the preferred product concept is refined.

结合操作概念的开发，分析客户需求，导出更详细和准确的称作为“产品和产品组件需求”的需求集。产品或产品组件需求集描述每个产品生命周期阶段的需要。导出需求源于约束；对在客户需求基线中隐含但没有明确陈述的问题的考虑；由所选架构、产品生命周期、

设计和开发者独特的业务考虑而引入的各种因素。随着进展，即较低层次的需求集和体系结构的开发，需求被再次检查，并且先前的产品概念被细化。

The requirements are allocated to product functions and

product components including objects, people,and

the case of iterative or incremental development,the

requirements are also allocated to iterations or increments based

on customer priorities,technology

traceability of

issues,and project

to requirements

functions,objects,tests,issues,or other entities is

allocated requirements and functions(or other logical entities)are

the basis for the synthesis of the technical solution;however,as

the architecture is defined or emerges,it serves as the ultimate

basis for directing the allocation of requirements to the

internal components are developed,additional

interfaces are defined and interface requirements are established.

需求被分配到产品功能和产品组件中，包括对象、人员和过程。在迭代或增量开发情况下，需求也同样被分配到基于客户的优先级别、技术问题及项目目标的迭代或增量中。对功能、对象、测试、问题或其他实体的需求可追溯性需要形成文档。已分配的需求和功能（或其他逻辑实体）是一揽子技术解决方案的基础。然而，随着架构的定义或形成，它作为最终的基础用来指导将已分配需求落实到解决方案中。随着内部组件的开发，附加的接口被定义，并建立起相应的接口需求。

Refer to the Requirements Management process area for

more information about maintaining bidirectional traceability of

requirements.

关于维护需求双向追溯性的更多信息，请参考需求管理过程域。

SP2.1Establish Product and Product Component

Requirements建立产品或产品组件需求

Establish and maintain product and product component

requirements,which are based on the customer requirements.

根据客户需求建立和维护产品或产品组件需求。

The customer functional and quality attribute requirements

can be expressed in the customer’s terms and can be

nontechnical product requirements are the

expression of these requirements in technical terms that can be

used for design example of this translation is found

in the first House of Quality Function Deployment,which maps

customer desires into technical instance,“solid

sounding door”may be mapped to size,weight,fit,

dampening,and resonant frequencies.

客户对功能和质量特性的需求可以用客户术语描述，可以是非技术性的描述。产品需求则要以可以用于

11

设计的技术术语表达。这种转换可以在第一个质量屋中找到，它们将客户要求映射为技术参数。比如，“solid sounding door”或许被映射为尺寸，重量，配合，减震及共振频率。

Product and product component requirements address the

satisfaction of customer,business,and project objectives and

associated attributes,such as effectiveness and affordability.

产品和产品组件需求标识了客户、业务及项目目标和相关属性，如有效性和可购性。

Derived requirements also address the needs of other

lifecycle ,production,operations, disposal)to the

extent compatible with business objectives.

导出需求也标识了其他生存周期阶段（如生产、操作及处置阶段）的需要，以便与业务目标相一致。The modification of

requirements due to approved requirement changes is covered

by the“maintain”aspect of this specific practice;whereas,the

administration of requirement changes is covered by the

Requirements Management process area.

由于已批准的需求的改变引起需求的修改包含在这个特定实践的“维护”部分中。然而，对需求变更的管理则包含在需求管理过程域中。

Refer to the Requirements Management process area for

more information about managing requirements.

关于管理需求的更多信息，请参考需求管理过程域。

Example Work Products工作产品样例

d requirements

导出需求

t requirements

产品需求

t component requirements

产品组件需求

ectural requirements,which specify or constrain the

relationships among product components

架构需求，用来说明或约束产品组件之间的相互关系

Subpractices子实践

p requirements in technical terms necessary for

product and product component design.

用技术术语开发需求，用于产品和产品组件设计。

requirements that result from design decisions.

由设计决策导出需求。

Refer to the Technical Solution process area for more

information about selecting product component solutions and

developing the design.

关于选择产品组件解决方案和开发设计的更多信息，请参考技术解决方案过程域。

Selection of a technology brings with it additional

instance,use of electronics requires additional

12

technology specific requirements such as electromagnetic

interference limits.

技术的选用会带来附加的需求，比如，电子设备的使用带来附加的技术细节要求，如电子干扰限制。Architectural decisions,such as

selection of architecture patterns,introduce additional derived

requirements for product example,the Layers

Pattern will constrain dependencies between certain product

components.

架构决策（如架构模式的选择）产生附加的产品组件导出需求。例如，层模式将约束某些产品组件之间的依赖关系。

p architectural requirements capturing critical

quality attributes and quality attribute measures necessary for

establishing the product architecture and design.

开发架构需求来捕获关键的质量特性和对其的测量，对于建立产品架构和产品设计是必要的。Examples of quality attribute

measures include the following:

Allocate the requirements for each product component.

为每个产品组件分配需求。

Refer to the Technical Solution process area for more

information about selecting product component solutions.

关于选择产品组件解决方案的更多信息，请参考技术解决过程域。

The product architecture provides the basis for allocating

product requirements to product requirements

for product components of the defined solution include

allocation of product performance;design constraints;and

fit,form,and function to meet requirements and facilitate

cases where a higher level requirement specifies a

quality attribute that will be

13

the responsibility of more than one product component,the

quality attribute can sometimes be partitioned for unique

allocation to each product component as a derived

requirement,however,other times the shared requirement should

instead be allocated directly to the example,

allocation of shared requirements to the architecture would

describe how a performance requirement (e.g.,on

responsiveness)is budgeted among components so as to

account in an end-to-end manner for realization of the

concept of shared requirements can extend to

other architecturally significant quality

,security,reliability).

产品架构为分配产品需求到产品组件提供基础。确定的解决方案中的产品组件的需求包括产品性能分配、设计约束，以及符合要求、形式和功能满足需求并利于生产。假设一个较高层次的需求确定了一个质量特性，这个质量特性涉及两个或以上的产品组件时，该质量特性有时会作为唯一分配被划分到每个产品组件作为其分配需求。然而，在其他时候，共用需求却被直接被分配到架构中。比如，把共用需求分配到架构中时应描述性能需求（如响应能力）是怎样被安排到各个组件中，以便以端到端方式说明需求的实现。这个处理公共需求的概念可以扩展到其他与构架有关的重要质量特征中（如安全性，可靠性等）。

Example Work Products工作产品样例

ement allocation sheets

需求分配表

ional requirement allocations

临时的需求分配

constraints

设计约束

d requirements

导出需求

onships among derived requirements

导出需求之间的关联关系

Subpractices子实践

te requirements to functions.

将需求分配到功能。

te requirements to product components and the

architecture.

将需求分配到产品组件和架构。

te design constraints to product components and

the architecture.

将设计约束分配到产品组件和架构。

te requirements to delivery increments.

将需求分配至交付增量。

nt relationships among allocated requirements.

14

将分配需求之间的关联关系文档化。

Relationships include dependencies in which a change in one

requirement can affect other requirements.

关联关系包括依赖性，即某个需求的变化会影响其他的需求。

SP 2.3Identify Interface Requirements识别接口需求

Identify interface requirements.

识别接口需求。

Interfaces between functions(or between objects or other

logical entities)are aces can drive the

development of alternative solutions described in the Technical

Solution process area.标识功能之间（或对象、逻辑实体之间）的接口。功能接口能够驱动在技术解决过程域中描述的备选解决方案的开发。

Refer to the Product Integration process area for more

information about ensuring interface compatibility.

关于确保接口兼容性的更多信息，请参考产品集成过程域。

Interface requirements between products or product

components identified in the product architecture are

are controlled as part of product and product

component integration and are an integral part of the

architecture definition.

定义在产品架构中识别的产品或产品组件之间的接口需求。这些接口需求当作产品和产品组件集成的一部分受到控制，它们是构成架构定义中不可缺少的部分。

Example Work Products工作产品样例

ace requirements

接口需求

Subpractices子实践

fy interfaces both external to the product and internal

to the ,between functional partitions or objects).

识别产品的内、外部接口（如，功能划分或对象之间的接口）。

As the design progresses,the product architecture will be

altered by technical solution processes,creating new interfaces

between product components and components external to the

product.

随着设计进展，产品架构将受技术解决过程影响而发生改变，在产品组件和产品外部组件之间产生新的接口。

Interfaces with product related lifecycle processes should

also be identified.

与生命周期过程有关的产品的接口也应被识别。

Examples of these interfaces include interfaces with test

equipment,transportation systems,support systems,and

15

开发已识别的接口需求。

Refer to the Technical Solution process area for more

information about designing interfaces using criteria.

关于使用准则设计接口的更多信息，请参考技术解决方案过程域。

Requirements for interfaces are defined in terms such as

origination,destination,stimulus,data characteristics for software,

and electrical and mechanical characteristics for hardware.

用术语定义软件接口需求，例如，软件方面：信源、信宿、激活源及数据特征；硬件方面：电子和机械特性。

SG3Analyze and Validate Requirements分析并确认需求

The requirements are analyzed and validated.

对需求进行分析并确认。

The specific practices of the Analyze and Validate

Requirements specific goal support the development of the

requirements in both the Develop Customer Requirements

specific goal and the Develop Product Requirements specific

specific practices associated with this specific goal cover

analyzing and validating the requirements with respect to the

end user’s intended environment.分析和确认需求特定目标的特定实践，支持在开发客户需求和开发产品需求中的两个特定目标的需求开发过程。本特定目标的特定实践包含分析和确认与最终用户预期环境有关的需求。

Analyses are performed to determine what impact the

intended operational environment will have on the ability to

satisfy the stakeholders’needs,expectations,constraints,and

interfaces. Considerations,such as feasibility,mission needs,cost

constraints,potential market size,and acquisition strategy,should

all be taken into account,depending on the product context.

Architecturally significant quality attributes are identified based

on mission and business drivers.A definition of required

functionality and quality attributes is also

specified usage modes for the product are considered.

执行分析，以确定预期的操作环境对满足相关干系人的需要、期望、约束及接口要求的能力有什么影响。根据产品背景，应将对诸如可行性、目标需要、成本约束、潜在市场规模及采购策略等的考虑纳入到估计中。总的来说，基于任务和业务驱动来识别重要的质量特性。同样也要建立必要的功能或性能定义。所有规定的产品使用模式都要考虑到。

The objectives of the analyses are to determine candidate

requirements for product concepts that will satisfy stakeholder

needs,expectations,and constraints and then to translate these

concepts into parallel with this activity,the

parameters that will be used to evaluate the effectiveness of the

product are determined based on customer input and the

preliminary product concept.

分析的目的在于确定对于能满足相关干系人的需要、期望、约束的产品概念的备选需求，进而，将这些概念转化为需求。开展这些活动的同时，这些作为评价产品有效性的参数将基于顾客的输入和初步产品16

概念而被确定。

Requirements are validated to increase the probability that

the resulting product will perform as intended in the use

environment.

确认需求，以增加最终产品在用户环境中将按照预期运行的概率。

SP 3.1Establish Operational Concepts and Scenarios建立操作概念和场景Establish and maintain operational concepts and

associated scenarios.

建立和维护操作概念和相关的场景。

A scenario is typically a sequence of events that may occur

in the development,use,or sustainment of the product,which is

used to make explicit some of the functional or quality attribute

needs of the contrast,an operational concept for

a product usually depends on both the design solution and the

example,the operational concept for a satellite

based communications product is quite different from one based

on the alternative solutions have not usually been

defined when preparing the initial operational

concepts,conceptual solutions are developed for use when

analyzing the operational concepts are refined

as solution decisions are made and lower level detailed

requirements are developed.

场景一般而言是指在产品开发、使用或支持时可能发生的事件序列，明确来使相关干系人对功能或质量特性的需要。相比之下，对于产品来说，操作概念通常即取决于设计方案也取决于场景。例如，基于卫星的通讯产品与基于地面线路的通讯产品，他们的操作概念完全是两回事。由于在准备最初的操作概念时，备选方案通常尚未被定义，因此，在分析需求时，开发概念性解决方案以供分析使用。随着解决方案的确定、较低层详细需求的开发，操作概念被细化。

Just as a design decision for a product can become a

requirement for a product component,the operational concept

can become the scenarios(requirements)for product

ional concepts and scenarios are evolved to

facilitate the selection of product component solutions that,

when implemented,will satisfy the intended use of the product

or facilitate its development and ional

concepts and scenarios document the interaction of the product

components with the environment,end users,and other product

components,regardless of engineering should be

documented for all modes and states within operations, product

development,deployment,delivery,support(including

maintenance and sustainment), training,and disposal.

正如产品的设计决策可以变成产品组件需求，操作概念也可以变成产品组件的场景（需求）。逐步开发操作概念和场景，方便了对产品组件解决方案的选择。当实现时，产品组件解决方案就能满足产品预期的使用或便于对它开发和维护。无论什么工程学科，操作概念和场景都以文档描述产品组件与环境、最终用户及其他产品组件之间的相互关系。对于运行方式和状态、产品开发、部署、交付，支持（包括维护及维修）、培训及处置等都应以文档描述。

Scenarios can be developed to

operational,sustainment,development,or other event

17

address