BABOK3.0 中文翻译-第七章 需求分析与设计

7、需求分析与设计

Requirements Analysis and Design Definition

The Requirements Analysis and Design Definition knowledge area describes the tasks that business

analysts perform to structure and organize requirements discovered during elicitation activities,

specify and model requirements and designs, validate and verify information, identify solution

options that meet business needs, and estimate the potential value that could be realized for each

solution option. This knowledge area covers the incremental and iterative activities ranging from

the initial concept and exploration of the need through the transformation of those needs into a

particular recommended solution.

定义和设计知识领域的需求分析描述了业务分析进行结构和组织中发现的启发活动要求的

任务，指定和模型的要求和设计，验证和核实信息，确定解决方案，满足业务需求，并估计

潜在的价值，可以为每个解决方案的实现。这个知识领域涵盖了从最初的概念和探索需求的

增量和迭代活动，通过将这些需求转化为特定的推荐解决方案。

Both requirements and designs are important tools used by business analysts to define and guide

change. The main difference between requirements and designs is in how they are used and by

whom. One person’s designs may be another person’s requirements. Requirements and designs may

be either high-level or very detailed based upon what is appropriate to those consuming the

information.

需求和设计都是业务分析人员用来定义和指导更改的重要工具。需求和设计的主要区别在于

它们是如何使用的以及由谁来设计的。一个人的设计可能是另一个人的要求。需求和设计可

以是高级的或非常详细的，基于对那些消费信息的合适的。

The business analyst's role in modelling needs, requirements, designs, and solutions is instrumental

in conducting thorough analysis and communicating with other stakeholders. The form, level of

detail, and what is being modelled are all dependent on the context, audience, and purpose.

业务分析师在建模需求、需求、设计和解决方案中的作用有助于进行透彻的分析，并与其他

利益相关者进行沟通。形式、细节层次和所建模的内容都依赖于上下文、受众和目的。

Business analysts analyze the potential value of both requirements and designs. In collaboration

with implementation subject matter experts, business analysts define solution options that can be

evaluated in order to recommend the best solution option that meets the need and brings the most

value.

业务分析人员分析需求和设计的潜在价值。业务分析人员与实现主题专家协作，定义可供评

估的解决方案选项，以推荐满足需求并带来最大价值的最佳解决方案选项。

The following image illustrates the spectrum of value as business analysis activities progress from

delivering potential value to actual value.

下图展示了业务分析活动从交付潜在价值到实际价值的过程中的价值谱。

Figure 7.0.1: Business Analysis Value Spectrum

图为7.0.1：业务分析值谱

The Requirements Analysis and Design Definition knowledge area includes the following tasks:

需求分析和设计定义知识领域包括以下任务：

• Specify and Model Requirements: describes a set of requirements or designs in detail using

analytical techniques.

•指定和建模需求：使用分析技术详细描述一组需求或设计。

• Verify Requirements: ensures that a set of requirements or designs has been developed in enough

detail to be usable by a particular stakeholder, is internally consistent, and is of high quality.

•验证需求：确保一组需求或设计在足够详细的范围内被某个特定的利益相关者利用，是内

部一致的，并且是高质量的。

• Validate Requirements: ensures that a set of requirements or designs delivers business value and

supports the organization's goals and objectives.

•验证需求：确保一组需求或设计交付业务价值并支持组织的目标和目标。

• Define Requirements Architecture: structures all requirements and designs so that they support

the overall business purpose for a change and that they work effectively as a cohesive whole.

•定义需求体系结构：构建所有需求和设计，以支持变革的总体业务目标，并使其作为一个

有凝聚力的整体有效地工作。

• Define Solution Options: identifies, explores and describes different possible ways of meeting

the need.

•定义解决方案选项：识别、探索和描述满足需求的不同可能方式。

• Analyze Potential Value and Recommend Solution: assesses the business value associated with a

potential solution and compares different options, including trade-offs, to identify and recommend

the solution option that delivers the greatest overall value.

•分析潜在价值并提出解决方案：评估与潜在解决方案相关联的业务价值，并比较不同的选

项，包括权衡，以确定和推荐解决方案，从而提供最大的总体价值。

The Core Concept Model in Requirements Analysis and Design Definition

需求分析与设计定义中的核心概念模型

The Business Analysis Core Concept Model™ (BACCM™) describes the relationships among the

six core concepts. The following table describes the usage and application of each of the core

concepts within the context of Requirements Analysis and Design Definition.

商业分析的核心概念模型™（baccm™）描述了六个核心概念之间的关系。下表描述了每个核

心概念在需求分析和设计定义中的用法和应用。

Table 7.0.1: The Core Concept Model in Requirements Analysis and Design Definition

表7.0.1：核心概念模型的需求分析和设计的定义

Core Concept

核心概念

During Requirements Analysis and Design

Definition,

在需求分析和设计定义中，业务分析师…

Change: the act of transformation in transform elicitation results into requirements

response to a need.

变化：为了满足需要而进行的变换行

为。

and designs in order to define the change.

将启发结果转化为需求和设计，以定义变更。

Need: a problem or opportunity to be analyze the needs in order to recommend a

addressed. solution that meets the needs.

需要：需要解决的问题或机会。 分析需求以推荐满足需求的解决方案。

define solution options and recommend the one

Solution: a specific way of satisfying

that is most likely to address the need and has the

one or more needs within a context.

most value.

解决方案：在上下文中满足一个或多

定义解决方案选项，并推荐最有可能满足需求

个需求的特定方式。

且最有价值的方案。

Stakeholder: a group or individual with

a relationship to the change, the need, or

the solution.

利益相关者：与变化、需要或解决方

案有关系的群体或个人。

tailor the requirements and designs so that they

are understandable and usable by each

stakeholder group.

对需求和设计进行裁剪，使它们能够被每个利

益相关者群体理解和使用。

Value: the worth, importance, or

usefulness of something to a stakeholder analyze and quantify the potential value of the

within a context. solution options.

价值：某事物在上下文中对利益相关分析并量化解决方案选项的潜在价值。

者的价值、重要性或有用性。

Context: the circumstances that

influence, are influenced by, and provide

understanding of the change.

语境：影响、影响和提供理解变化的

环境。

model and describe the context in formats that are

understandable and usable by all stakeholders.

用所有利益相关者理解和使用的格式建模和

描述上下文。

Figure 7.0.2: Requirements Analysis and Design Definition Input/Output Diagram

图7.0.2：需求分析和设计的定义输入/输出图

7.1

指定和模型需求

Specify and Model Requirements

7.1.1 Purpose

7.1.1目的

The purpose of Specify and Model Requirements is to analyze, synthesize, and refine elicitation

results into requirements and designs.

指定和建模需求的目的是分析、合成和提炼启发结果到需求和设计中。

7.1.2 Description

7.1.2描述

Specify and Model Requirements describes the practices for analyzing elicitation results and

creating representations of those results. When the focus of the specifying and modelling activity is

on understanding the need, the outputs are referred to as requirements. When the focus of the

specifying and modelling activity is on a solution, the outputs are referred to as designs.

指定和模型需求描述了分析启发结果并创建结果表示的实践。当指定和建模活动的重点是理

解需求时，输出被称为需求。当指定和建模活动的焦点在解决方案上时，输出称为设计。

Important ： In many IT environments, the word 'design' is used specifically for technical designs

created by software developers, data architects, and other implementation subject matter experts.

All business deliverables are referred to as 'requirements'.

要点：在许多IT环境中，“设计”一词专门用于由软件开发人员、数据架构师和其他实现主

题专家创建的技术设计。所有业务可交付成果称为“需求”。

In addition to the models used to represent the requirements, this task also includes capturing

information about attributes or metadata about the requirements. The specifying and modelling

activities relate to all requirement types.

除了用于表示需求的模型之外，这个任务还包括获取关于需求的属性或元数据的信息。指定

和建模活动涉及到所有需求类型。

7.1.3 Inputs

7.1.3输入

• Elicitation Results (any state): modelling can begin with any elicitation result and may lead to the

need for more elicitation to clarify or expand upon requirements. Elicitation and modelling may

occur sequentially, iteratively, or concurrently.

•启发式结果（任何状态）：建模可以从任何启发性结果开始，并可能需要更多的启发来澄清

或扩展需求。启发和建模可以依次、迭代或并发地发生。

Figure 7.1.1: Specify and Model Requirements Input/Output Diagram

图1：指定和模型要求输入/输出图

7.1.4 Elements

7.1.4元素

.1 Model Requirements

1

种型号要求

A model is a descriptive and visual way to convey information to a specific audience in order to

support analysis, communication, and understanding. Models may also be used to confirm

knowledge, identify information gaps that the business analyst may have, and identify duplicate

information. Business analysts choose from one or more of the following modelling formats:

模型是一种描述性的和直观的方式，将信息传达给特定的受众，以支持分析、交流和理解。

模型还可以用来确认知识，识别业务分析师可能存在的信息间隙，并识别重复的信息。业务

分析师从以下一种或多种建模格式中选择：

• Matrices: a matrix is used when the business analyst is modelling a requirement or set of

requirements that have a complex but uniform structure, which can be broken down into elements

that apply to every entry in the table. Matrices may be used for data dictionaries, requirements

traceability, or for gap analysis. Matrices are also used for prioritizing requirements and recording

other requirements attributes and metadata.

•矩阵：当业务分析师建模需求或一组复杂而一致的结构的需求或需求集合时，使用一个矩

阵，该矩阵可以分解成适用于表中每个条目的元素。矩阵可用于数据字典、需求可追溯性或

用于间隙分析。矩阵还用于优先需求和记录其他需求属性和元数据。

• Diagrams: a diagram is a visual, often pictorial, representation of a requirement or set of

requirements. A diagram is especially useful to depict complexity in a way that would be difficult

to do with words. Diagrams can also be used to define boundaries for business domains, to

categorize and create hierarchies of items, and to show components of objects such as data and their

relationships.

•图表：图表是一个可视化的，通常是图形化的，表示需求或一组需求。一个图表特别有用，

用一种很难用词表达的方式来描述复杂性。图还可以用来定义业务域的边界，对项目进行分

类和创建层次结构，并显示对象的组件，如数据及其关系。

Using one or more of the model formats, business analysts determine specific categories and specific

models within categories to be used. Model categories can include:

通过使用一种或多种模型格式，业务分析人员确定类别中的特定类别和特定模型将被使用。

模型类别可以包括：

• People and Roles: models represent organizations, groups of people, roles, and their relationships

within an enterprise and to a solution. Techniques used to represent people and their roles include

Organizational Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or Personas.

•人员和角色：模型代表企业内部的组织、群体、角色以及它们之间的关系和解决方案。用

于表示人及其角色的技术包括组织建模、角色和权限矩阵和利益相关者列表、映射或人物角

色。

• Rationale: models represent the ‘why’ of a change. Techniques used to represent the rationale

include Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, and

Business Rules Analysis.

•理由：模型代表变化的“原因”。用于表示基本原理的技术包括决策建模、范围建模、业务

模型画布、根原因分析和业务规则分析。

• Activity Flow: models represent a sequence of actions, events, or a course that may be taken.

Techniques used to represent activity flows include Process Modelling, Use Cases and Scenarios,

and User Stories.

•活动流程：模型表示可能采取的一系列行动、事件或过程。用于表示活动流的技术包括流

程建模、用例和场景以及用户故事。

• Capability: models focus on features or functions of an enterprise or a solution. Techniques used

to represent capabilities include Business Capability Analysis, Functional Decomposition, and

Prototyping.

•能力：模型关注企业的特性或功能或解决方案。用于表示能力的技术包括业务能力分析、

功能分解和原型设计。

• Data and Information: models represent the characteristics and the exchange of information

within an enterprise or a solution. Techniques used to represent data and information include Data

Dictionary, Data Flow Diagrams, Data Modelling, Glossary, State Modelling, and Interface

Analysis.

•数据和信息：模型代表企业或解决方案中的特征和信息交换。用于表示数据和信息的技术

包括数据字典、数据流图、数据建模、术语表、状态建模和接口分析。

Business analysts should use any combination of models best suited to meet stakeholder needs in a

given context. Each modelling technique has strengths and weaknesses and provides unique insights

into the business domain.

业务分析人员应该使用最适合于满足特定环境下涉众需求的模型的任何组合。每种建模技术

都有其优点和缺点，并为业务领域提供独特的见解。

.2 Analyze Requirements

2分析需求

Business analysis information is decomposed into components to further examine

业务分析信息被分解为组件以进一步检查。

for:

对于：

• anything that must change to meet the business need,

•必须改变以满足业务需要的任何东西，

• anything that should stay the same to meet the business need,

•任何与业务需要保持一致的东西，

• missing components,

•缺少的组件，

• unnecessary components, and

•不必要的组件，以及

• any constraints or assumptions that impact the components.

•影响组件的任何约束或假设。

The level of decomposition required, and the level of detail to be specified, varies depending on the

knowledge and understanding of the stakeholders, the potential for misunderstanding or

miscommunication, organizational standards, and contractual or regulatory obligations, among

other factors.

分解所需的水平，和水平的细节规定，取决于知识和利益相关者的理解，潜在的误解或误传，

组织标准、合同或监管义务，除其他因素。

Analysis provides a basis for discussion to reach a conclusion about solution options.

分析提供了讨论的基础，以得出解决方案的结论。

.3 Represent Requirements and Attributes

3表示需求和属性

Business analysts identify information for requirements and their attributes as part of the elicitation

results. Requirements should be explicitly represented and should include enough detail such that

they exhibit the characteristics of requirements and designs quality (see Verify Requirements (p.

141)). Various attributes can be specified for each requirement or set of requirements. These

attributes are selected when planning for information management (see Plan Business Analysis

Information Management (p. 42)).

业务分析人员将需求信息及其属性标识为启发结果的一部分。需求应该被明确地表示，并且

应该包含足够的细节，这样它们就显示了需求和设计质量的特性（见验证要求（第141页））。

可以为每个需求或一组需求指定各种属性。在计划信息管理时选择这些属性（参见计划业务

分析信息管理（第42页））。

As part of specifying requirements, they can also be categorized according to the schema described

in task Requirements Classification Schema (p. 16). Typically elicitation results contain information

of different types, so it is natural to expect that different types of requirements might be specified at

the same time.

作为指定需求的一部分，还可以根据任务需求分类模式中描述的模式进行分类（第16页）。

通常，启发式结果包含不同类型的信息，因此很自然地期望在同一时间指定不同类型的需求。

Categorizing requirements can help ensure the requirements are fully understood, a set of any type

is complete, and that there is appropriate traceability between the types.

对需求的分类可以帮助确保需求被完全理解，任何类型的集合都完成了，并且类型之间有适

当的可跟踪性。

.4 Implement the Appropriate Levels of Abstraction

4实现适当的抽象级别

The level of abstraction of a requirement varies based on the type of requirement and audience for

the requirement. Not all stakeholders require or find value in the complete set of requirements and

models. It may be appropriate to produce different viewpoints of requirements to represent the same

need for different stakeholders. Business analysts take special care to maintain the meaning and

intent of the requirements over all representations.

需求的抽象级别根据需求的类型和需求的不同而不同。并非所有的利益相关者都需要或在完

整的需求和模型中找到价值。为了满足不同的利益相关者相同的需求，可以产生不同的需求

观点。业务分析人员特别注意在所有表示中维护需求的含义和意图。

The business analysis approach may also influence the level of abstraction and choice of models

used when defining requirements.

业务分析方法还可能影响定义需求时使用的模型的抽象级别和选择。

7.1.5 Guidelines and Tools

7.1.5指南和工具

• Modelling Notations/Standards: allow requirements and designs to be precisely specified, as is

appropriate for the audience and the purpose of the models. Standard templates and syntax help to

ensure that the right information is provided about the requirements.

•建模符号/标准：允许精确地指定需求和设计，适合于受众和模型的目的。标准模板和语法

有助于确保提供关于需求的正确信息。

• Modelling Tools: software products that facilitate drawing and storing matrices and diagrams to

represent requirements. This functionality may or may not be part of requirements life cycle

management tools.

•建模工具：便于绘制和存储矩阵和图表以表示需求的软件产品。此功能可能是或可能不是

需求生命周期管理工具的一部分。

• Requirements Architecture: the requirements and interrelationships among them can be used to

ensure models are complete and consistent.

•需求体系结构：它们之间的需求和相互关系可以用来确保模型是完整的和一致的。

• Requirements Life Cycle Management Tools: software products that facilitate recording,

organizing, storing, and sharing requirements and designs.

•需求生命周期管理工具：促进记录、组织、存储和共享需求和设计的软件产品。

• Solution Scope: the boundaries of the solution provide the boundaries for the requirements and

designs models.

解决方案范围：解决方案的边界为需求和设计模型提供了边界。

7.1.6 Techniques

7.1.6技术

• Acceptance and Evaluation Criteria: used to represent the acceptance and evaluation criteria

attributes of requirements.

•接受和评价标准：用于表示接受和评价标准的需求属性。

• Business Capability Analysis: used to represent features or functions of an enterprise.

•业务能力分析：用来表示企业的特征或功能。

• Business Model Canvas: used to describe the rationale for requirements.

业务模型画布：用于描述需求的基本原理。

• Business Rules Analysis: used to analyze business rules so that they can be specified and

modelled alongside requirements.

•业务规则分析：用于分析业务规则，以便根据需求指定和建模。

• Concept Modelling: used to define terms and relationships relevant to the change and the

enterprise.

•概念建模：用于定义与变化和企业相关的术语和关系。

• Data Dictionary: used to record details about the data involved in the change. Details may include

definitions, relationships with other data, origin, format, and usage.

•数据字典：用于记录与更改相关的数据的详细信息。详细信息可能包括定义、与其他数据

的关系、来源、格式和用法。

• Data Flow Diagrams: used to visualize data flow requirements.

•数据流图：用于可视化数据流需求。

• Data Modelling: used to model requirements to show how data will be used to meet stakeholder

information needs.

•数据建模：用于对需求进行建模，以显示数据将如何用于满足涉众信息需求。

• Decision Modelling: used to represent decisions in a model in order to show the elements of

decision making required.

•决策建模：用于表示模型中的决策，以显示所需的决策要素。

• Functional Decomposition: used to model requirements in order to identify constituent parts of

an overall complex business function.

•功能分解：用于对需求进行建模，以确定整体复杂业务功能的组成部分。

• Glossary: used to record the meaning of relevant business terms while analyzing requirements.

•词汇表：在分析需求时记录相关业务术语的含义。

• Interface Analysis: used to model requirements in order to identify and validate inputs and outputs

of the solution they are modelling.

•接口分析：用于建模需求，以识别和验证他们正在建模的解决方案的输入和输出。

• Non-Functional Requirements Analysis: used to define and analyze the quality of service

attributes.

•非功能需求分析：用于定义和分析服务质量属性。

• Organizational Modelling: used to allow business analysts to model the roles, responsibilities,

and communications within an organization.

•组织建模：用于允许业务分析人员对组织中的角色、职责和通信进行建模。

• Process Modelling: used to show the steps or activities that are performed in the organization, or

that must be performed to meet the desired change.

•流程建模：用于显示组织中执行的步骤或活动，或必须执行以满足所需的更改。

• Prototyping: used to assist the stakeholders in visualizing the appearance and capabilities of a

planned solution.

•原型化：用于帮助利益相关者可视化计划的解决方案的外观和能力。

• Roles and Permissions Matrix: used to specify and model requirements concerned with the

separation of duties among users and external interfaces in utilizing a solution.

•角色和权限矩阵：用于指定和建模与使用解决方案中的用户和外部接口之间的职责分离有

关的需求。

• Root Cause Analysis: used to model the root causes of a problem as part of rationale.

•根本原因分析：用于将问题的根本原因建模为理论的一部分。

• Scope Modelling: used to visually show a scope boundary.

•范围模型：用于直观地显示范围边界。

• Sequence Diagrams: used to specify and model requirements to show how processes operate and

interact with one another, and in what order.

•序列图：用于指定和建模需求，以显示流程是如何相互操作和交互的，以及按什么顺序进

行。

• Stakeholder List, Map, or Personas: used to identify the stakeholders and their characteristics.

•利益相关者列表、地图或人物角色：用于识别利益相关者及其特征。

• State Modelling: used to specify the different states of a part of the solution throughout a life

cycle, in terms of the events that occur.

•状态建模：用于在整个生命周期中，根据发生的事件指定解决方案的一部分的不同状态。

• Use Cases and Scenarios: used to model the desired behavior of a solution, by showing user

interactions with the solution, to achieve a specific goal or accomplish a particular task.

•用例和场景：用于对解决方案的期望行为进行建模，通过显示用户与解决方案的交互，以

实现特定的目标或完成特定任务。

• User Stories: used to specify requirements as a brief statement about what people do or need to

do when using the solution.

•用户故事：用于将需求指定为一个简短的语句，说明使用该解决方案时人们需要做什么或

需要做什么。

7.1.7 Stakeholders

7.1.7的利益相关者

• Any stakeholder: business analysts may choose to perform this task themselves and then

separately package and communicate the requirements to stakeholders for their review and approval,

or they might choose to invite some or all stakeholders to participate in this task.

•任何利益相关者：业务分析人员可以选择自己完成这项任务，然后单独将需求打包并传达

给利益相关者以供其审查和批准，或者他们可以选择邀请一些或所有利益相关者参与这项任

务。

7.1.8 Outputs

7.1.8输出

• Requirements (specified and modelled): any combination of requirements and/or designs in the

form of text, matrices, and diagrams.

•要求（指定和模拟）：以文本、矩阵和图表形式要求和/或设计的任何组合。

7.2

校验需求

Verify Requirements

7.2.1 Purpose

7.2.1目的

The purpose of Verify Requirements is to ensure that requirements and designs specifications and

models meet quality standards and are usable for the purpose they serve.

验证需求的目的是确保需求和设计规格和型号符合质量标准，并可用于服务的目的。

7.2.2 Description

7.2.2描述

Verifying requirements ensures that the requirements and designs have been defined correctly.

Requirements verification constitutes a check by the business analyst and key stakeholders to

determine that the requirements and designs are ready for validation, and provides the information

needed for further work to be performed.

验证需求确保了需求和设计的正确定义。需求验证由业务分析人员和关键的利益相关者进行

检查，以确定需求和设计已经准备好进行验证，并提供要执行的进一步工作所需的信息。

A high-quality specification is well written and easily understood by its intended audience. A high-

quality model follows the formal or informal notation standards and effectively represents reality.

高质量的规范写得很好，易于理解。高质量的模型遵循正式或非正式的符号标准，并有效地

代表现实。

The most important characteristic of quality requirements and designs is fitness for use. They must

meet the needs of stakeholders who will use them for a particular purpose. Quality is ultimately

determined by stakeholders.

质量要求和设计的最重要特点是适合使用。他们必须满足利益相关者的需要，他们将为特定

目的使用它们。质量最终由利益相关者决定。

7.2.3 Inputs

7.2.3输入

• Requirements (specified and modelled): any requirement, design, or set of those may be verified

to ensure that text is well structured and that matrices and modelling notation are used correctly.

•要求（指定的和模拟的）：任何要求、设计或设置都可以得到验证，以确保文本结构良好，

并正确使用矩阵和建模符号。

Figure 7.2.1: Verify Requirements Input/Output Diagram

图7.2.1：验证要求的输入/输出图

7.2.4 Elements

7.2.4元素

.1 Characteristics of Requirements and Designs Quality

1

需求和设计质量的特性

While quality is ultimately determined by the needs of the stakeholders who will use the

requirements or the designs, acceptable quality requirements exhibit many of the following

characteristics:

虽然质量最终取决于需要使用需求或设计的利益相关者的需求，可接受的质量要求具有以下

许多特性：

• Atomic: self-contained and capable of being understood independently of other requirements or

designs.

•原子：自包含，能够独立于其他需求或设计而被理解。

• Complete: enough to guide further work and at the appropriate level of detail for work to continue.

The level of completeness required differs based on perspective or methodology, as well as the point

in the life cycle where the requirement is being examined or represented.

•完成：足以指导进一步的工作，并在适当的细节层次上继续工作。所需的完整性程度不同，

基于透视或方法，以及生命周期中需要检查或表示的一点。

• Consistent: aligned with the identified needs of the stakeholders and not conflicting with other

requirements.

•一致：符合利益相关者的确定需要，而不与其他要求冲突。

• Concise: contains no extraneous and unnecessary content.

•简明：不包含无关和不必要的内容。

• Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or

considered feasible enough to investigate further through experiments or prototypes.

•可行的：在商定的风险、进度和预算内合理可行，或认为是可行的，以便通过试验或原型

进一步调查。

• Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a

solution does or does not meet the associated need.

•明确的：必须明确说明这一要求，以便明确某一解决办法是否符合相关需要。

• Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of

verifying fulfillment depend on the level of abstraction of the requirement or design.

•可测试：能够验证需求或设计是否已完成。验证实现的可接受级别取决于需求或设计的抽

象级别。

• Prioritized: ranked, grouped, or negotiated in terms of importance and value against all other

requirements.

•优先考虑：按重要性和价值对所有其他要求进行排序、分组或谈判。

• Understandable: represented using common terminology of the audience.

•可以理解的：以观众的共同术语为代表。

.2 Verification Activities

2

核查活动

Verification activities are typically performed iteratively throughout the requirements analysis

process.

验证活动通常在需求分析过程中反复执行。

Verification activities include:

核查活动包括：

• checking for compliance with organizational performance standards for business analysis, such

as using the right tools and methods,

•检查遵守业务分析的组织性能标准，如使用正确的工具和方法，

• checking for correct use of modelling notation, templates, or forms,

•检查正确使用建模符号、模板或表格，

• checking for completeness within each model,

•检查每个模型中的完整性，

• comparing each model against other relevant models, checking for elements that are mentioned

in one model but are missing in other models, and verifying that the elements are referenced

consistently,

•将每个模型与其他相关模型进行比较，检查在其他模型中缺少的一个模型中提到的元素，

并验证这些元素是否被一致引用，

• ensuring the terminology used in expressing the requirement is understandable to stakeholders

and consistent with the use of those terms within the organization, and

•确保在表达需求时使用的术语对利益相关者是可以理解的，并符合在组织内使用这些术语

的情况，以及

• adding examples where appropriate for clarification.

•在适当情况下加上澄清说明。

.3 Checklists

3

清单。

Checklists are used for quality control when verifying requirements and designs. Checklists may

include a standard set of quality elements that business analysts use to verify the requirements, or

they may be specifically developed to capture issues of concern. The purpose of a checklist is to

ensure that items determined to be important are included in the final requirements deliverables, or

that steps required for the verification process are followed.

在验证需求和设计时，检查表用于质量控制。检查表可以包括业务分析师用来验证需求的标

准质量元素集合，或者可以专门开发来捕获关注的问题。检查表的目的是确保确定重要的项

目包括在最终的可交付成果中，或遵循验证过程所需的步骤。

7.2.5 Guidelines and Tools

7.2.5指南和工具

• Requirements Life Cycle Management Tools: some tools have functionality to check for issues

related to many of the characteristics, such as atomic, unambiguous, and prioritized.

•需求生命周期管理工具：一些工具具有检查与许多特性相关的问题的功能，如原子、明确、

优先级等。

7.2.6 Techniques

7.2.6技术

• Acceptance and Evaluation Criteria: used to ensure that requirements are stated clearly enough

to devise a set of tests that can prove that the requirements have been met.

•验收标准和评价标准：用于确保要求明确说明，设计出一套能够满足要求的测试。

• Item Tracking: used to ensure that any problems or issues identified during verification are

managed and resolved.

•项目跟踪：用于确保在核查过程中发现的任何问题或问题得到管理和解决。

• Metrics and Key Performance Indicators (KPIs): used to identify how to evaluate the quality of

the requirements.

•指标和关键绩效指标（KPI）：用来确定如何评价质量的要求。

• Reviews: used to inspect requirements documentation to identify requirements that are not of

acceptable quality.

•审查：用于检查需求文件，以确定不合格的要求。

7.2.7 Stakeholders

7.2.7利益相关者

• All stakeholders: the business analyst, in conjunction with the domain and implementation subject

matter experts, has the primary responsibility for determining that this task has been completed.

Other stakeholders may discover problematic requirements during requirements communication.

•所有利益相关者：业务分析师与域和实现主题专家一起负责确定此任务已完成。其他利益

相关者可能在需求沟通过程中发现有问题的需求。

Therefore, all stakeholders could be involved in this task.

因此，所有利益相关者都可以参与这项任务。

7.2.8 Outputs

7.2.8输出

• Requirements (verified): a set of requirements or designs that is of sufficient quality to be used

as a basis for further work.

•要求（核实）：一套要求或设计足够的质量，以此作为进一步工作的基础。

7.3 确认需求Validate Requirements

7.3.1 Purpose

7.3.1目的

The purpose of Validate Requirements is to ensure that all requirements and designs align to the

business requirements and support the delivery of needed value.

验证需求的目的是确保所有的需求和设计都符合业务需求，并支持交付所需的价值。

7.3.2 Description

7.3.2描述

Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition

requirements align to the business requirements and that the designs satisfy the requirements.

需求验证是一个正在进行的过程，以确保涉众、解决方案和转换需求符合业务需求，并且设

计满足需求。

Understanding what the desired future state looks like for stakeholders after their needs have been

met is valuable to business analysts when validating requirements. The overall goal of

implementing the requirements is to achieve the stakeholders' desired future state. In many cases,

stakeholders have different, conflicting needs and expectations that may be exposed through the

validation process.

在满足需求之后，对涉众的需求进行了了解，这对业务分析人员来说是很有价值的。实现需

求的总体目标是实现涉众想要的未来状态。在许多情况下，涉众有不同的、冲突的需求和期

望，这些需求和期望可能通过验证过程公开。

7.3.3 Inputs

7.3.3输入

• Requirements (specified and modelled): any types of requirements and designs can be validated.

Validation activities may begin before requirements are completely verified. However, validation

activities cannot be completed before requirements are completely verified.

•需求（指定和建模）：任何类型的需求和设计都可以得到验证。验证活动可以在完全验证需

求之前开始。但是，在完全验证需求之前，验证活动不能完成。

Figure 7.3.1: Validate Requirements Input/Output Diagram

图1：确认需求的输入/输出图

7.3.4 Elements

7.3.4元素

.1 Identify Assumptions

1

确定假设

If an organization is launching an unprecedented product or service, it may be necessary to make

assumptions about customer or stakeholder response, as there are no similar previous experiences

on which to rely. In other cases, it may be difficult or impossible to prove that a particular problem

derives from an identified root cause. Stakeholders may have assumed that certain benefits will

result from the implementation of a requirement. These assumptions are identified and defined so

that associated risks can be managed.

如果一个组织正在推出一种前所未有的产品或服务，就有必要对客户或利益相关者的反应做

出假设，因为以前没有类似的经验可以依赖。在其他情况下，很难或不可能证明一个特定的

问题源于一个确定的根本原因。利益相关者可能认为实施某项要求会带来某些好处。确定和

界定这些假设，以便管理相关风险。

.2 Define Measurable Evaluation Criteria

2

定义可衡量的评价标准

While the expected benefits are defined as part of the future state, the specific measurement criteria

and evaluation process may not have been included. Business analysts define the evaluation criteria

that will be used to evaluate how successful the change has been after the solution is implemented.

Baseline metrics might be established based on the current state. Target metrics can be developed

to reflect the achievement of the business objectives or some other measurement of success.

虽然预期收益被定义为未来状态的一部分，但具体的度量标准和评估过程可能不包括在内。

业务分析人员定义了评估标准，该标准将用于评估在解决方案实施后变更的成功程度。基线

度量可以根据当前状态建立。目标度量可以被开发来反映业务目标的实现或其他成功度量。

.3 Evaluate Alignment with Solution Scope

3

评估与解决方案范围的一致性

A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution. A

requirement that does not deliver benefit to a stakeholder is a strong candidate for elimination. When

requirements do not align, either the future state must be re-evaluated and the solution scope

changed, or the requirement removed from the solution scope.

需求可以对利益相关者有利，但仍然不是解决方案的可取部分。不给利益相关者带来利益的

要求是消除的有力候选者。当需求不对齐时，必须重新评估未来状态，改变解决方案的范围，

或者将需求从解决方案范围中移除。

If a design cannot be validated to support a requirement, there might be a missing or misunderstood

requirement, or the design must change.

如果一个设计不能被验证以支持需求，可能会有一个缺失或误解的需求，或者设计必须改变。

7.3.5 Guidelines and Tools

7.3.5指南和工具

• Business Objectives: ensure the requirements deliver the desired business benefits.

•业务目标：确保需求达到预期的商业效益。

• Future State Description: helps to ensure the requirements that are part of the solution scope do

help achieve the desired future state.

•未来状态描述：有助于确保作为解决方案范围的一部分的需求有助于实现预期的未来状态。

• Potential Value: can be used as a benchmark against which the value delivered by requirements

can be assessed.

•潜在价值：可以作为评估需求交付价值的基准。

• Solution Scope: ensures the requirements that provide benefit are within the scope of the desired

solution.

•解决方案范围：确保提供利益的要求在所期望的解决方案的范围内。

7.3.6 Techniques

7.3.6技术

• Acceptance and Evaluation Criteria: used to define the quality metrics that must be met to achieve

acceptance by a stakeholder.

•接受和评价标准：用于定义必须达到满足利益相关者接受的质量指标。

• Document Analysis: used to identify previously documented business needs in order to validate

requirements.

•文档分析：用于确定先前记录的业务需求，以验证需求。

• Financial Analysis: used to define the financial benefits associated with requirements.

•财务分析：用于定义与需求相关的财务收益。

• Item Tracking: used to ensure that any problems or issues identified during validation are

managed and resolved.

•项目跟踪：用于确保在验证过程中发现的任何问题或问题得到管理和解决。

• Metrics and Key Performance Indicators (KPIs): used to select appropriate performance measures

for a solution, solution component, or requirement.

•指标和关键绩效指标（KPI）：用来选择一个解决方案，适当的绩效测量解决方案组件，或

要求。

• Reviews: used to confirm whether or not the stakeholder agrees that their needs are met.

•审查：用于确认利益相关者是否同意他们的需要得到满足。

• Risk Analysis and Management: used to identify possible scenarios that would alter the benefit

delivered by a requirement.

•风险分析和管理：用于确定可能改变需求交付的利益的情景。

7.3.7 Stakeholders

7.3.7利益相关者

• All stakeholders: the business analyst, in conjunction with the customer, end users, and sponsors,

has the primary responsibility for determining whether or not requirements are validated. Other

stakeholders may discover problematic requirements during requirements communication.

Therefore, virtually all project stakeholders are involved in this task.

•所有利益相关者：业务分析员与客户、最终用户和发起人一起，主要负责确定需求是否得

到验证。其他利益相关者可能在需求沟通过程中发现有问题的需求。因此，几乎所有项目涉

众都参与了这项任务。

7.3.8 Outputs

7.3.8输出

• Requirements (validated): validated requirements and designs are those that can be demonstrated

to deliver benefit to stakeholders and align with the business goals and objectives of the change. If

a requirement or design cannot be validated, it either does not benefit the organization, does not fall

within the solution scope, or both.

•需求（验证）：经过验证的需求和设计是能够证明对利益相关者带来利益并符合业务目标和

变更目标的设计。如果一个需求或设计不能被验证，它既不利于组织，也不属于解决方案范

围，或者两者都在。

7.4

定义需求的架构

Define Requirements Architecture

7.4.1 Purpose

7.4.1目的

The purpose of Define Requirements Architecture is to ensure that the requirements collectively

support one another to fully achieve the objectives.

定义需求体系结构的目的是确保需求共同支持以充分实现目标。

7.4.2 Description

7.4.2描述

Requirements architecture is the structure of all of the requirements of a change. A requirements

architecture fits the individual models and specifications together to ensure that all of the

requirements form a single whole that supports the overall business objectives and produces a useful

outcome for stakeholders.

需求体系结构是所有变更需求的结构。需求体系结构将单个模型和规范结合在一起，以确保

所有需求形成一个整体，支持整体业务目标，并为利益相关者产生有用的结果。

Business analysts use a requirements architecture to:

业务分析人员使用需求体系结构：

• understand which models are appropriate for the domain, solution scope, and audience,

•理解哪些模型适合于域、解决方案范围和受众，

• organize requirements into structures relevant to different stakeholders,

•将需求组织成与不同利益相关者相关的结构，

• illustrate how requirements and models interact with and relate to each other, and show how the

parts fit together into a meaningful whole,

•说明需求和模型是如何相互作用和相互关联的，并显示各部分如何组合成一个有意义的整

体，

• ensure the requirements work together to achieve the overall objectives, and

•确保各项要求共同工作，以实现总体目标，以及

• make trade-off decisions about requirements while considering the overall objectives.

•在考虑总体目标的同时，对需求做出权衡决定。

Requirements architecture is not intended to demonstrate traceability, but rather to show how

elements work in harmony with one another to support the business requirements, and to structure

them in various ways to align the viewpoints of different stakeholders. Traceability is often used as

the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)).

需求体系结构不是为了展示可追溯性，而是为了显示元素是如何和谐地协同工作以支持业务

需求，并以不同的方式组织它们以对齐不同利益相关者的观点。可追溯性经常被用作表示和

管理这些关系的机制（见跟踪需求（第79页））。

Traceability proves that every requirement links back to an objective and shows how an objective

was met. Traceability does not prove the solution is a cohesive whole that will work.

可追溯性证明，每个需求都链接到一个目标，并显示目标是如何实现的。可追溯性并不能证

明解决方案是一个有凝聚力的整体。

7.4.3 Inputs

7.4.3输入

• Information Management Approach: defines how the business analysis information (including

requirements and models) will be stored and accessed.

•信息管理方法：定义业务分析信息（包括需求和模型）如何存储和访问。

• Requirements (any state): every requirement should be stated once, and only once, and

incorporated into the requirements architecture so that the entire set may be evaluated for

completeness.

•需求（任何国家）：每一项要求都应一次说明一次，并且只一次，并纳入需求体系结构，以

便对整个集合进行评估以确保完整性。

• Solution Scope: must be considered to ensure the requirements architecture is aligned with the

boundaries of the desired solution.

•解决方案的范围：必须考虑到确保需求体系结构与所需解决方案的边界相一致。

Figure 7.4.1: Define Requirements Architecture Input/Output Diagram

图

7.4.1

：定义需求结构的输入

/

输出图

7.4.4 Elements

7.4.4元素

.1 Requirements Viewpoints and Views

1

需求观点和观点

A viewpoint is a set of conventions that define how requirements will be represented, how these

representations will be organized, and how they will be related. Viewpoints provide templates for

addressing the concerns of particular stakeholder groups.

视点是定义需求如何被表示、如何组织这些表示以及它们将如何关联的一组约定。视点为解

决特定利益相关者群体的关注提供模板。

Requirements viewpoints frequently include standards and guidelines for the:

需求视图通常包括以下标准和指南：

• model types used for requirements,

•用于需求的模型类型，

• attributes that are included and consistently used in different models,

•包含在不同的模型中并始终如一地使用的属性，

• model notations that are used, and

·使用的模型符号，以及

• analytical approaches used to identify and maintain relevant relationships among models.

•用于确定和维持模型相关关系的分析方法

No single viewpoint alone can form an entire architecture. Each viewpoint is stronger for some

aspects of the requirements, and weaker for others, as different groups of stakeholders have different

concerns. Trying to put too much information into any one viewpoint will make it too complex and

degrade its purpose. Examples of viewpoints include:

没有一个单一的观点可以形成一个完整的体系结构。每个观点对于需求的某些方面来说更为

强大，而对于其他人来说，这些观点更为薄弱，因为不同的利益相关者群体有不同的关注点。

试图把太多的信息放在任何一个角度都会使它过于复杂而降低它的用途。观点的例子包括：

• Business process models,

业务流程模型，

• Data models and information,

•数据模型和信息，

• User interactions, including use cases and/or user experience,

•用户交互，包括用例和/或用户体验，

• Audit and security, and

•审计和安全，以及

• Business models.

•商业模式。

Each of those viewpoints has different model notations and techniques, and each is important to

ensure a cohesive final solution. The solution would likely not be a success if the business analyst

only looked at the business process viewpoint.

每种观点都有不同的模型符号和技术，每一种观点都有助于确保有一致性的最终解决方案。

如果业务分析人员只查看业务流程视图，则该解决方案可能不会成功。

Similarly, trying to put conventions from many viewpoints in one single viewpoint would make it

overwhelming to analyze and contain information irrelevant to particular stakeholder groups.

同样地，试图从一个单一的观点中从许多观点中加入约定会使分析和包含与特定利益相关者

不相关的信息变得势不可挡。

The actual requirements and designs for a particular solution from a chosen viewpoint are referred

to as a view. A collection of views makes up the requirements architecture for a specific solution.

Business analysts align, coordinate, and structure requirements into meaningful views for the

various stakeholders. This set of coordinated, complementary views provides a basis for assessing

the completeness and coherence of the requirements.

从选定的视点对特定解决方案的实际需求和设计称为视图。视图集合构成特定解决方案的需

求体系结构。业务分析人员为各种利益相关者对齐、协调和将需求构造成有意义的视图。这

套协调一致的补充意见为评估需求的完整性和一致性提供了依据。

In short, the viewpoints tell business analysts what information they should provide for each

stakeholder group to address their concerns, while views describe the actual requirements and

designs that are produced.

简而言之，这些观点告诉业务分析人员他们应该为每个利益相关者组提供什么信息来解决他

们的关注，而视图描述实际的需求和设计。

.2 Template Architectures

2

模板体系结构

An architectural framework is a collection of viewpoints that is standard across an industry, sector,

or organization. Business analysts can treat frameworks as predefined templates to start from in

defining their architecture. Similarly, the framework can be populated with domain-specific

information to form a collection of views that is an even more useful template to build architecture

from if it is accurate because the information is already populated in it.

体系结构框架是跨行业、部门或组织标准的观点集合。业务分析人员可以将框架视为预定义

的模板，从定义它们的体系结构开始。类似地，可以使用特定于域的信息填充该框架，以形

成视图集合，这些视图是一个更为有用的模板，用于构建架构，如果它是准确的，因为信息

已经填充在其中。

.3 Completeness

3

完整性。

An architecture helps ensure that a set of requirements is complete. The entire set of requirements

should be able to be understood by the audience in way that it can be determined that the set is

cohesive and tells a full story. No requirements should be missing from the set, inconsistent with

others, or contradictory to one another. The requirements architecture should take into account any

dependencies between requirements that could keep the objectives from being achieved.

体系结构有助于确保一组需求是完整的。整个集合的要求应该能够被听众理解，这样就可以

确定集合是有凝聚力的，并讲述一个完整的故事。从集合中不应缺少任何要求，与他人不一

致，或相互矛盾。需求体系结构应该考虑到能够实现目标的需求之间的依赖关系。

Structuring requirements according to different viewpoints helps ensure this completeness.

Iterations of elicitation, specification, and analysis activities can help identify gaps.

根据不同的观点构造需求有助于确保这种完整性。启发式、规范和分析活动的迭代有助于识

别差距。

.4 Relate and Verify Requirements Relationships

4

联系和验证需求关系

Requirements may be related to each other in several ways when defining the requirements

architecture. Business analysts examine and analyze the requirements to define the relationships

between them. The representation of these relationships is provided by tracing requirements (see

Trace Requirements (p. 79)).

在定义需求体系结构时，需求可能以多种方式相互关联。业务分析人员检查和分析需求以定

义它们之间的关系。这些关系的表示是通过跟踪需求提供的（参见跟踪需求（第79页））。

Business analysts examine each relationship to ensure that the relationships satisfy the following

quality criteria:

业务分析人员检查每个关系，以确保关系满足以下质量标准：

• Defined: there is a relationship and the type of the relationship is described.

•定义：存在一种关系，并描述关系的类型。

• Necessary: the relationship is necessary for understanding the requirements holistically.

•必要的关系是理解整体的必要要求。

• Correct: the elements do have the relationship described.

•正确：元素之间有描述的关系。

• Unambiguous: there are no relationships that link elements in two different and conflicting ways.

•毫不含糊：没有关系以两种不同的、相互冲突的方式把元素联系起来。

• Consistent: relationships are described in the same way, using the same set of standard

descriptions as defined in the viewpoints.

•一致性：使用相同的方式描述关系，使用与视图中定义的相同的标准描述集。

.5 Business Analysis Information Architecture

5

业务分析信息体系结构

The structure of the business analysis information is also an information architecture. This type of

architecture is defined as part of the task Plan Business Analysis Information Management (p. 42).

The information architecture is a component of the requirements architecture because it describes

how all of the business analysis information for a change relates. It defines relationships for types

of information such as requirements, designs, types of models, and elicitation results. Understanding

this type of information structure helps to ensure that the full set of requirements is complete by

verifying the relationships are complete. It is useful to start defining this architecture before setting

up infrastructure such as requirements life cycle management tools, architecture management

software, or document repositories.

业务分析信息的结构也是信息体系结构。这种类型的架构被定义为任务计划的一部分，业务

分析信息管理（第42页）。信息体系结构是需求体系结构的一个组成部分，因为它描述了变

更的所有业务分析信息的关系。它定义了信息类型的关系，如需求、设计、模型类型和启发

结果。理解这种类型的信息结构有助于确保通过验证关系完整完成完整的需求集。在构建基

础结构之前，如需求生命周期管理工具、体系结构管理软件或文档存储库，开始定义此体系

结构是有用的。

7.4.5 Guidelines and Tools

7.4.5指南和工具

• Architecture Management Software: modelling software can help to manage the volume,

complexity, and versions of the relationships within the requirements architecture.

•架构管理软件：建模软件可以帮助管理需求体系结构中的关系的数量、复杂性和版本。

• Legal/Regulatory Information: describes legislative rules or regulations that must be followed.

They may impact the requirements architecture or its outputs. Additionally, contractual or standards-

based constraints may also need to be considered.

•法律/法规信息：描述必须遵循的立法规则或条例。它们可能影响需求体系结构或其输出。

此外，还可能需要考虑基于契约或基于标准的约束。

• Methodologies and Frameworks: a predetermined set of models, and relationships between the

models, to be used to represent different viewpoints.

•方法和框架：预先确定的模型集和模型之间的关系，用于表示不同的观点。

7.4.6 Techniques

7.4.6节技术

• Data Modelling: used to describe the requirements structure as it relates to data.

•数据建模：用于描述与数据相关的需求结构。

• Functional Decomposition: used to break down an organizational unit, product scope, or other

elements into its component parts.

•功能分解：用于将组织单元、产品范围或其他元素分解成其组成部分。

• Interviews: used to define the requirements structure collaboratively.

•访谈：用于协作定义需求结构。

• Organizational Modelling: used to understand the various organizational units, stakeholders, and

their relationships which might help define relevant viewpoints.

•组织建模：用于了解各种组织单位、利益相关者及其关系，这可能有助于定义相关的观点。

• Scope Modelling: used to identify the elements and boundaries of the requirements architecture.

•范围建模：用于确定需求体系结构的元素和边界。

• Workshops: used to define the requirements structure collaboratively.

•讲习班：用于协作定义需求结构。

7.4.7 Stakeholders

7.4.7利益相关者

• Domain Subject Matter Expert, Implementation Subject Matter Expert, Project Manager, Sponsor,

Tester: may assist in defining and confirming the requirements architecture.

•领域主题专家、实施主题专家、项目经理、发起人、测试人员：可以协助定义和确认需求

体系结构。

• Any stakeholder: may also use the requirements architecture to assess the completeness of the

requirements.

•任何利益相关者：也可以使用需求体系结构来评估需求的完整性。

7.4.8 Outputs

7.4.8输出

• Requirements Architecture: the requirements and the interrelationships among them, as well as

any contextual information that is recorded.

•需求体系结构：需求和它们之间的相互关系，以及记录的任何上下文信息。

7.5 确定设计方案Define Design Options

7.5.1 Purpose

7.5.1目的

The purpose of Define Design Options is to define the solution approach, identify opportunities to

improve the business, allocate requirements across solution components, and represent design

options that achieve the desired future state.

定义设计选项的目的是定义解决方案的方法，找出改善业务的机会，在解决方案组件之间分

配需求，并代表实现预期未来状态的设计选项。

7.5.2 Description

7.5.2描述

When designing a solution, there may be one or more design options identified. Each design option

represents a way to satisfy a set of requirements. Design options exist at a lower level than the

change strategy, and are tactical rather than strategic. As a solution is developed, tactical trade-offs

may need to be made among design alternatives. Business analysts must assess the effect these

trade-offs will have on the delivery of value to stakeholders. As initiatives progress and

requirements evolve, design options evolve as well.

在设计解决方案时，可能存在一个或多个设计选项。每个设计选项表示满足一组需求的方法。

设计选项存在于较低级别的变化战略，是战术而不是战略。随着解决方案的发展，可能需要

在设计方案之间进行战术权衡。业务分析人员必须评估这些权衡将对利益相关者交付价值的

影响。随着倡议的进展和需求的发展，设计选项也随之演变。

7.5.3 Inputs

7.5.3输入

• Change Strategy: describes the approach that will be followed to transition to the future state.

This may have some impact on design decisions in terms of what is feasible or possible.

•变革战略：描述过渡到未来国家所遵循的方法。这可能对设计决策的影响是可行的或可能

的。

• Requirements (validated, prioritized): only validated requirements are considered in design

options. Knowing the requirement priorities aids in the suggestion of reasonable design options.

Requirements with the highest priorities might deserve more weight in choosing solution

components to best meet them as compared to lower priority requirements.

•需求（验证，优先）：只有验证的需求在设计选项中被考虑。了解需求优先级有助于提出合

理的设计方案。与优先级较低的需求相比，优先级最高的需求在选择解决方案组件时最合适。

• Requirements Architecture: the full set of requirements and their relationships is important for

defining design options that can address the holistic set of requirements.

•需求体系结构：全套需求及其关系对于定义能够满足整体需求的设计选项非常重要。

Figure 7.5.1: Define Design Options Input/Output Diagram

图

7.5.1

：定义设计选项输入

/

输出图

7.5.4 Elements

7.5.4元素

.1 Define Solution Approaches

1

定义解决方法

The solution approach describes whether solution components will be created or purchased, or some

combination of both. Business analysts assess the merits of the solution approaches for each design

option.

解决方案方法描述是否将创建或购买解决方案组件，或者两者的组合。业务分析人员评估每

个设计选项的解决方案方法的优点。

Solution approaches include:

解决方法包括：

• Create: solution components are assembled, constructed, or developed by experts as a direct

response to a set of requirements. The requirements and the design options have enough detail to

make a decision about which solution to construct. This option includes modifying an existing

solution.

•创建：解决方案组件由专家组装、构建或开发，作为对一组需求的直接响应。需求和设计

选项有足够的细节来决定构建哪种解决方案。此选项包括修改现有解决方案。

• Purchase: solution components are selected from a set of offerings that fulfill the requirements.

The requirements and design options have enough detail to make a recommendation about which

solution to purchase. These offerings are usually products or services owned and maintained by

third parties.

•购买：解决方案组件选自满足需求的一组产品。需求和设计选项有足够的细节来推荐购买

哪种解决方案。这些产品通常是由第三方拥有和维护的产品或服务。

• Combination of both: not all design options will fall strictly into one of the categories above.

Design options may include a combination of both creation and purchase of components.

•两者的结合：并非所有的设计方案都严格属于上述类别之一。设计选项可以包括组件的创

建和购买的组合。

In all of these types of approaches, proposed integration of the components is also considered within

the design option.

在所有这些类型的方法中，在设计选项中也考虑了组件的建议集成。

.2 Identify Improvement Opportunities

2

找出改进机会

When proposing design options, a number of opportunities to improve the operation of the business

may occur and are compared.

在提出设计方案时，可能会出现一些改善业务运作的机会，并进行比较。

Some common examples of opportunities include:

一些常见的机会例子包括：

• Increase Efficiencies: automate or simplify the work people perform by re-engineering or sharing

processes, changing responsibilities, or outsourcing. Automation may also increase consistency of

behaviour, reducing the likelihood of different stakeholders performing the same function in

distinctly different fashions.

•提高效率：通过重新设计或共享流程、改变职责或外包，使人们的工作自动化或简化。自

动化还可以增加行为的一致性，减少不同利益相关者在明显不同的方式中执行相同功能的可

能性。

• Improve Access to Information: provide greater amounts of information to staff who interface

directly or indirectly with customers, thereby reducing the need for specialists.

•改善获取信息的机会：向直接或间接与客户接触的工作人员提供更多的信息，从而减少对

专家的需求。

• Identify Additional Capabilities: highlight capabilities that have the potential to provide future

value and can be supported by the solution. These capabilities may not necessarily be of immediate

value to the organization (for example, a software application with features the organization

anticipates using in the future).

•确定附加功能：突出显示有可能提供未来价值的能力，并可由解决方案支持。这些功能不

一定对组织有直接的价值（例如，一个软件应用程序，该特性是该组织预期将来使用的特性）。

.3 Requirements Allocation

3

需求分配

Requirements allocation is the process of assigning requirements to solution components and

releases to best achieve the objectives. Allocation is supported by assessing the trade-offs between

alternatives in order to maximize benefits and minimize costs. The value of a solution might vary

depending on how requirements are implemented and when the solution becomes available to

stakeholders. The objective of allocation is to maximize that value.

需求分配是将需求分配到解决方案组件和发布以最佳实现目标的过程。分配通过评估替代品

之间的权衡来支持，以最大限度地提高效益和降低成本。解决方案的价值可能因需求如何实

现以及何时解决方案对利益相关者可用而有所不同。分配的目标是使价值最大化。

Requirements may be allocated between organizational units, job functions, solution components,

or releases of a solution. Requirements allocation typically begins when a solution approach has

been determined, and continues until all valid requirements are allocated. Allocation typically

continues through design and implementation of a solution.

需求可以在组织单元、作业功能、解决方案组件或解决方案的发布之间分配。需求分配通常

在解决方案方法确定后开始，并一直持续到所有有效需求被分配为止。分配通常通过设计和

实现解决方案来继续。

.4 Describe Design Options

4

描述设计选项

Design options are investigated and developed while considering the desired future state, and in

order to ensure the design option is valid. Solution performance measures are defined for each

design option.

在考虑预期的未来状态的同时，研究和开发设计选项，以确保设计选项是有效的。为每个设

计选项定义解决方案性能度量。

A design option usually consists of many design components, each described by a design element.

Design elements may describe:

设计选项通常由许多设计组件组成，每个设计组件都由设计元素描述。设计元素可以描述：

• business policies and business rules,

•业务政策和业务规则，

• business processes to be performed and managed,

•执行和管理的业务流程，

• people who operate and maintain the solution, including their job functions and responsibilities,

•操作和维护解决方案的人员，包括其工作职能和职责，

• operational business decisions to be made,

•拟作出的业务决定，

• software applications and application components used in the solution, and

•解决方案中使用的软件应用程序和应用程序组件，以及

• organizational structures, including interactions between the organization, its customers, and its

suppliers.

•组织结构，包括组织、其客户和供应商之间的相互作用。

7.5.5 Guidelines and Tools

7.5.5指南和工具

• Existing Solutions: existing products or services, often third party, that are considered as a

component of a design option.

•现有解决方案：现有产品或服务，通常为第三方，被认为是设计选项的一个组成部分。

• Future State Description: identifies the desired state of the enterprise that the design options will

be part of, and helps to ensure design options are viable.

•未来状态描述：确定设计方案将成为企业的理想状态，并帮助确保设计选项是可行的。

• Requirements (traced): define the design options that best fulfill known requirements.

•需求（跟踪）：定义最佳实现已知需求的设计选项。

• Solution Scope: defines the boundaries when selecting viable design options.

•解决方案范围：在选择可行的设计选项时定义边界。

7.5.6 Techniques

7.5.6技术

• Benchmarking and Market Analysis: used to identify and analyze existing solutions and market

trends.

•基准测试和市场分析：用于识别和分析现有的解决方案和市场趋势。

• Brainstorming: used to help identify improvement opportunities and design options.

•头脑风暴：用于帮助识别改进机会和设计选项。

• Document Analysis: used to provide information needed to describe design options and design

elements.

•文档分析：用于提供描述设计选项和设计元素所需的信息。

• Interviews: used to help identify improvement opportunities and design options.

•面试：用于帮助识别改进机会和设计选项。

• Lessons Learned: used to help identify improvement opportunities.

•吸取的经验教训：用于帮助识别改进机会。

• Mind Mapping: used to identify and explore possible design options.

•思维导图：用于识别和探索可能的设计选项。

• Root Cause Analysis: used to understand the underlying cause of the problems being addressed

in the change to propose solutions to address them.

•根本原因分析：用于了解变化中所涉及的问题的根本原因，提出解决方案。

• Survey or Questionnaire: used to help identify improvement opportunities and design options.

•调查或问卷：用于帮助识别改进机会和设计选项。

• Vendor Assessment: used to couple the assessment of a third party solution with an assessment

of the vendor to ensure that the solution is viable and all parties will be able to develop and maintain

a healthy working relationship.

•供应商评估：用于评估对第三方解决方案的评估和对供应商的评估，以确保该解决方案是

可行的，所有各方都能够发展并保持良好的工作关系。

• Workshops: used to help identify improvement opportunities and design options.

•讲习班：用于帮助识别改进机会和设计选项。

7.5.7 Stakeholders

7.5.7利益相关者

• Domain Subject Matter Expert: provides the expertise within the business to provide input and

feedback when evaluating solution alternatives, particularly for the potential benefits of a solution.

•域主题专家：在评估解决方案替代品时，提供业务内的专业知识，提供输入和反馈，特别

是解决方案的潜在好处。

• Implementation Subject Matter Expert: use their expertise in terms of the design options being

considered to provide needed input about the constraints of a solution and its costs.

•实施主题专家：在设计方案中使用他们的专门知识，以便为解决方案及其成本的限制提供

必要的输入。

• Operational Support: can help evaluate the difficulty and costs of integrating proposed solutions

with existing processes and systems.

•业务支持：可以帮助评估拟议的解决方案与现有过程和系统集成的困难和成本。

• Project Manager: plans and manages the solution definition process, including the solution scope

and any risks associated with the proposed solutions.

•项目经理：计划和管理解决方案定义过程，包括解决方案范围和与提议的解决方案相关的

任何风险。

• Supplier: provides information on the functionality associated with a particular design option.

•供应商：提供与特定设计选项相关联的功能的信息。

7.5.8 Outputs

7.5.8输出

• Design Options: describe various ways to satisfy one or more needs in a context. They may

include solution approach, potential improvement opportunities provided by the option, and the

components that define the option.

•设计选项：描述在上下文中满足一个或多个需求的各种方法。它们可能包括解决方案、选

项提供的潜在改进机会以及定义选项的组件。

7.6

分析潜在价值并推荐解决方案

Analyze Potential Value and Recommend Solution

7.6.1 Purpose

7.6.1目的

The purpose of Analyze Potential Value and Recommend Solution is to estimate the potential value

for each design option and to establish which one is most appropriate to meet the enterprise’s

requirements.

分析潜在价值和推荐解决方案的目的是评估每种设计方案的潜在价值，并确定哪种设计方案

最适合企业的要求。

7.6.2 Description

7.6.2描述

Analyze Potential Value and Recommend Solution describes how to estimate and model the

potential value delivered by a set of requirements, designs, or design options. Potential value is

analyzed many times over the course of a change. This analysis may be a planned event, or it may

be triggered by a modification to the context or scope of the change. The analysis of potential value

includes consideration that there is uncertainty in the estimates. Value can be described in terms of

finance, reputation, or even impact on the marketplace. Any change may include a mix of increases

and decreases in value.

分析潜在价值，推荐解决方案描述如何估算和建模一系列需求、设计或设计选项交付的潜在

价值。在变化过程中，多次分析潜在价值。这种分析可能是计划中的事件，也可能是对变更

的上下文或范围的修改触发的。对潜在价值的分析包括对估计中存在不确定性的考虑。价值

可以用财务、声誉甚至是市场的影响来描述。任何变化都可能包括价值的增加和减少。

Design options are evaluated by comparing the potential value of each option to the other options.

Each option has a mix of advantages and disadvantages to consider. Depending on the reasons for

the change, there may be no best option to recommend, or there may be a clear best choice. In some

cases this means the best option may be to begin work against more than one design option, perhaps

to develop proofs of concept, and then measure the performance of each. In other instances, all

proposed designs may be rejected and more analysis may be needed to define a suitable design. It

is also possible that the best recommendation is to do nothing.

通过比较每个选项与其他选项的潜在价值来评估设计选项。每个选项都有各种优点和缺点来

考虑。根据变化的原因，可能没有最好的选择来推荐，或者可能有一个明确的最佳选择。在

某些情况下，这意味着最好的选择可能是针对多个设计选项开始工作，也许是开发概念证明，

然后测量每个性能。在其他情况下，所有建议的设计可能被拒绝，可能需要更多的分析来定

义合适的设计。最好的建议也可能是什么也不做。

7.6.3 Inputs

7.6.3输入

• Potential Value: can be used as a benchmark against which the value delivered by a design can

be evaluated.

潜在价值：可以作为基准，评估设计交付的价值。

• Design Options: need to be evaluated and compared to one another to recommend one option for

the solution.

•设计选项：需要相互评价和比较，以便为解决方案推荐一种方案。

Figure 7.6.1: Analyze Potential Value and Recommend Solution Input/Output Diagram

图

7.6.1

：分析潜在的价值和建议解决输入

/

输出图

7.6.4 Elements

7.6.4元素

. 1 Expected Benefits

。

1

预期利益

Expected benefits describe the positive value that a solution is intended to deliver to stakeholders.

Value can include benefits, reduced risk, compliance with business policies and regulations, an

improved user experience, or any other positive outcome. Benefits are determined based on the

analysis of the benefit that stakeholders desire and the benefit that is possible to attain. Expected

benefits can be calculated at the level of a requirement or set of requirements by considering how

much of an overall business objective the set of requirements contribute to if fulfilled. The total

expected benefit is the net benefit of all the requirements a particular design option addresses.

Benefits are often realized over a period of time.

预期的收益描述了一个解决方案旨在向利益相关者交付的积极价值。价值可以包括收益、降

低风险、遵守业务策略和规则、改善用户体验或任何其他积极结果。利益是基于利益相关者

的利益和可能获得的利益的分析而确定的。预期的收益可以在需求的层次上进行计算，也可

以通过考虑满足需求的总体业务目标的多少来计算需求的多少。总预期收益是一个特定设计

选项所满足的所有需求的净收益。福利往往会在一段时间内实现。

. 2 Expected Costs

。

2

预期成本

Expected costs include any potential negative value associated with a solution, including the cost to

acquire the solution, any negative effects it may have on stakeholders, and the cost to maintain it

over time.

预期成本包括与解决方案相关的任何潜在的负面价值，包括获得解决方案的成本、对涉众可

能产生的任何负面影响，以及维护它的成本。

Expected costs can include:

预期成本可以包括:

• timeline,

•时间表,

• effort,

•努力,

• operating costs,

•运营成本,

• purchase and/or implementation costs,

购买和/或执行成本，

• maintenance costs,

•维护成本,

• physical resources,

•物理资源,

• information resources, and

•信息资源

• human resources.

•人力资源。

Expected costs for a design option consider the cumulative costs of the design components.

设计选项的预期成本考虑了设计组件的累积成本。

Business analysts also consider opportunity cost when estimating the expected cost of a change.

Opportunity costs are alternative results that might have been achieved if the resources, time, and

funds devoted to one design option had been allocated to another design option. The opportunity

cost of any design option is equal to the value of the best alternative not selected.

业务分析人员在评估变更的预期成本时也考虑机会成本。如果资源、时间和投入到一个设计

选项的资金被分配到另一个设计选项中，那么机会成本是另一个可能的结果。任何设计方案

的机会成本都等于没有选择的最佳选择的价值。

. 3 Determine Value

。

3

确定价值

The potential value of a solution to a stakeholder is based on the benefits delivered by that solution

and the associated costs. Value can be positive (if the benefits exceed the costs) or negative (if the

costs exceed the benefits).

一个涉众的解决方案的潜在价值是基于该解决方案所带来的收益和相关的成本。价值可以是

正的(如果收益超过成本)或者是负的(如果成本超过收益)。

Business analysts consider potential value from the points of view of stakeholders. Value to the

enterprise is almost always more heavily weighted than value for any individual stakeholder groups.

There might be increases in value for one set of stakeholders and decreases in value for another set,

but an overall positive increase in value for the enterprise as a whole justifies proceeding with the

change.

业务分析人员从涉众的角度考虑潜在价值。对企业的价值几乎总是比任何个人利益相关者的

价值都要重。一组利益相关者的价值可能会增加，而另一组的价值也会降低，但总体来说，

企业整体的价值增长是值得的。

Potential value is uncertain value. There are always events or conditions that could increase or

decrease the actual value if they occur. Many changes are proposed in terms of intangible or

uncertain benefits, while costs are described as tangible, absolute, and might grow. When benefits

are described as intangible and costs expressed as tangible, it may be difficult for decision makers

to compare their options. Business analysts define a complete estimate of the purpose-driven and

monetary effects of a proposed change by considering the tangible and intangible costs alongside

the tangible and intangible benefits. The estimate of costs and benefits must take into account the

degree of uncertainty pertaining at the time the estimates are made.

潜在价值是不确定的价值。总有一些事件或条件会增加或减少它们的实际价值。许多变化都

是在无形或不确定的利益方面提出的，而成本则被描述为有形的、绝对的，而且可能还会增

长。当福利被描述为无形的，成本以有形的方式表达时，决策者可能很难比较他们的选择。

商业分析师通过考虑有形和无形的成本，以及有形和无形的利益，来定义一项拟议变革的目

的驱动和货币效应的完整估计。成本和收益的估计必须考虑到估算的时间的不确定程度。

. 4 Assess Design Options and Recommend Solution

。评估设计方案并推荐解决方案

Each design option is assessed based on the potential value it is expected to deliver. At any point

in analyzing the design options, it may become necessary to re-evaluate the initial allocation of

design elements between components. The reasons for re-evaluation include better understanding

of the cost to implement each component and to determine which allocations have the best cost-to

benefit ratio.

每个设计选项都基于预期交付的潜在价值进行评估。在分析设计选项的任何时候，可能有必

要重新评估组件之间设计元素的初始分配。重新评估的原因包括更好地理解实现每个组件的

成本，以及确定哪些配置具有最佳的成本效益比。

As costs and effort are understood for each solution component, business analysts assess each design

option to ensure that it represents the most effective trade-offs. There are several factors to take

into consideration:

由于每个解决方案组件都理解成本和努力，业务分析人员评估每个设计选项，以确保它表示

最有效的权衡。有几个因素需要考虑:

• Available Resources: there may be limitations regarding the amount of requirements that can be

implemented based on the allocated resources. In some instances, a business case can be

developed to justify additional investment.

可用资源:根据分配的资源可以实现的需求数量可能有限制。在某些情况下，可以开发一个

业务案例以证明额外的投资是合理的。

• Constraints on the Solution: regulatory requirements or business decisions may require that

certain requirements be handled manually or automatically, or that certain requirements be

prioritized above all others.

解决方案的约束:管理需求或业务决策可能需要手动或自动地处理某些需求，或者将某些需

求放在优先级之上。

• Dependencies between Requirements: some capabilities may in and of themselves provide

limited value to the organization, but need to be delivered in order to support other high-value

requirements.

需求之间的依赖性:一些功能本身和它们本身对组织的价值是有限的，但是需要交付以支持

其他高价值的需求。

Other considerations may include relationships with proposed vendors, dependencies on other

initiatives, corporate culture, and sufficient cash flow for investment.

其他的考虑可能包括与提议的供应商的关系，对其他计划的依赖，企业文化，以及足够的投

资现金流。

Business analysts recommend the option or options deemed to be the most valuable solution to

address the need. It is possible that none of the design options are worthwhile and the best

recommendation is to do nothing.

业务分析人员推荐使用被认为是最有价值的解决方案的选项或选项。可能没有一个设计选项

是值得的，最好的建议是什么都不做。

7.6.5 Guidelines and Tools

7.6.5指南和工具

• Business Objectives: used to calculate the expected benefit.

业务目标:用于计算预期的收益。

• Current State Description: provides the context within which the work needs to be completed.

It can be used to identify and help quantify the value to be delivered from a potential solution.

当前状态描述:提供工作需要完成的上下文。它可以用来识别并帮助量化从一个潜在的解决

方案中交付的价值。

• Future State Description: describes the desired future state that the solution will be part of in order

to ensure the design options are appropriate.

未来状态描述:描述希望的未来状态，解决方案将是确保设计选项是适当的一部分。

• Risk Analysis Results: the potential value of design options includes an assessment of the level

of risk associated with the design options or initiative.

风险分析结果:设计选项的潜在价值包括评估与设计选项或计划相关的风险等级。

• Solution Scope: defines the scope of the solution that is being delivered so that a relevant

evaluation can be made that is within the scope boundaries.

解决方案范围:定义正在交付的解决方案的范围，以便在范围范围内进行相关的评估。

7.6.6 Techniques

7.6.6技术

• Acceptance and Evaluation Criteria: used to express requirements in the form of acceptance

criteria to make them most useful when assessing proposed solutions and determining whether a

solution meets the defined business needs.

验收和评估标准:用于以验收标准的形式表达需求，以使它们在评估建议的解决方案和确定

一个解决方案是否满足定义的业务需求时最有用。

• Backlog Management: used to sequence the potential value.

Backlog管理:用于对潜在的价值进行排序。

• Brainstorming: used to identify potential benefits of the requirements in a collaborative manner.

头脑风暴:用于以协作的方式确定需求的潜在好处。

• Business Cases: used to assess recommendations against business goals and objectives.

业务案例:用于评估针对业务目标和目标的建议。

• Business Model Canvas: used as a tool to help understand strategy and initiatives.

业务模型画布:用作帮助理解策略和计划的工具。

• Decision Analysis: used to support the assessment and ranking of design options.

决策分析:用于支持设计选项的评估和排名。

• Estimation: used to forecast the costs and efforts of meeting the requirements as a step towards

estimating their value.

估计:用于预测满足需求的成本和努力，作为评估其价值的一个步骤。

• Financial Analysis: used to evaluate the financial return of different options and choose the best

possible return on investment.

财务分析:用于评估不同选项的财务回报，并选择最佳可能的投资回报。

• Focus Groups: used to get stakeholder input on which design options best meet the requirements,

and to evaluate a targeted, small group of stakeholders’ value expectations.

焦点小组:用于获得涉众的输入，在哪些设计选项中最好满足需求，并评估一个有针对性的、

小规模的利益相关者的价值期望。

• Interviews: used to get stakeholder input on which design options best meet the requirements,

and to evaluate individual stakeholders’ value expectations.

访谈:用于让涉众输入哪些设计选项最符合需求，并评估每个涉众的价值期望。

• Metrics and Key Performance Indicators (KPIs): used to create and evaluate the measurements

used in defining value.

度量和关键性能指标(kpi):用于创建和评估用于定义值的度量。

• Risk Analysis and Management: used to identify and manage the risks that could affect the

potential value of the requirements.

风险分析和管理:用于识别和管理可能影响需求潜在价值的风险。

• Survey or Questionnaire: used to get stakeholder input on which design options best meet the

requirements, and to identify stakeholders’ value expectations.

调查或问卷调查:用于让涉众输入最符合需求的设计选项，并确定涉众的价值期望。

• SWOT Analysis: used to identify areas of strength and weakness that will impact the value of the

solutions.

SWOT分析:用于确定影响解决方案价值的力量和弱点的领域。

• Workshops: used to get stakeholder input on which design options best meet the requirements,

and to evaluate stakeholders’ value expectations.

专题讨论会:用于让涉众输入最符合需求的设计选项，并评估涉众的价值期望。

7.6.7 Stakeholders

7.6.7利益相关者

• Customer: represents the market segments affected by the requirements and solutions, and will

be involved in analyzing the benefit of those requirements and costs of the design options.

•客户：代表受需求和解决方案影响的细分市场，并将参与分析这些需求的好处和设计选项

的成本。

• Domain Subject Matter Expert: may be called upon for their domain knowledge to assist in

analyzing potential value and benefits, particularly for those requirements where they are harder to

identify.

•领域主题专家：可以要求其领域知识帮助分析潜在价值和收益，特别是对那些难以识别的

需求。

• End User: provides an insight into the potential value of the change.

•最终用户：提供洞察潜在价值的变化。

• Implementation Subject Matter Expert: may be called upon for their expertise in implementing

the design options in order to identify potential costs and risks.

•执行主题专家：可以要求他们在执行设计方案方面的专长，以便查明潜在的成本和风险。

• Project Manager: manages the selection process so that when effecting the change they are aware

of potential impacts on those supporting the change, including the risks associated with the change.

•项目经理：管理甄选过程，以便在实施变更时，意识到对支持变更的潜在影响，包括与变

更相关的风险。

• Regulator: may be involved in risk evaluation concerning outside regulatory bodies or place

constraints on the potential benefits.

•监管机构：可能参与外部监管机构的风险评估或对潜在利益的限制。

• Sponsor: approves the expenditure of resources to purchase or develop a solution and approve

the final recommendation. The sponsor will want to be kept informed of any changes in potential

value or risk, as well as the resulting opportunity cost, as he/she may prefer another course of action.

•提案国：核准购买或开发解决方案的资源支出，并核准最后建议。发起人将希望随时了解

潜在价值或风险的任何变化，以及由此产生的机会成本，因为他/她可能更愿意采取另一行

动。

7.6.8 Outputs

7.6.8输出

• Solution Recommendation: identifies the suggested, most appropriate solution based on an

evaluation of all defined design options. The recommended solution should maximize the value

provided to the enterprise.

•解决方案建议：根据对所有定义的设计选项的评价，确定建议的、最合适的解决方案。推

荐的解决方案应该最大限度地提供给企业的价值。