4.1 业务或使命分析过程

4.1.1 目的

如ISO/IEC/IEEE 15288所述：

业务或使命分析过程的目的是定义业务或任务的问题或机会、描述问题的解空间，并确定潜在的、可以解决问题或利用机会的解决方案类别。

业务或使命分析过程并不聚焦于特定的待开发系统，而是在一个更大的背景中识别潜在的需求，这种需求可能会成为开发某个系统或服务的理由。

4.1.2 概述

业务或使命分析过程主要从业务管理层面通过趋势分析、标杆研究等途径，分析并定义业务所存在的问题与差距，然后定义可以解决问题、弥补差距的可能的解决方案类别。

《INCOSE系统工程手册》在业务或使命分析过程中引用了特别值得关注的两份文件——ANSI/AIAA G043A：2012与BABOK（IIBA,2009国际商业分析协会）。ANSI/AIAA G043A：2012主要介绍了如何开发概念文档，为系统需求开发做准备；而BABOK则从任务、技能与知识点等维度非常系统地介绍了如何分析企业与业务需要。

就像我们写立项报告论述必要性一样，业务需求是企业目的、目标或需要的高层级描述。业务需求描述了为什么要启动一个项目，项目将实现什么，以及哪些指标将被用来衡量项目的成功与否。

业务需求反映组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明；业务需求给出系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统。

为了满足客户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature），特性说明了系统为用户提供的各项功能，限定了系统的范围（Scope）；参与各方必须要对高层次的解决方案达成一致，以建立共同愿景（Vision）。

由业务需求到相关方需求、再到系统需求的需求工程过程，本质上遵循从问题域到方案域的问题求解逻辑的系统工程过程。

4.1.3 活动描述

按照《INCOSE系统工程手册（第4版）》中4.1章节所述，业务或使命分析过程包括一系列的输入输出和活动项，图4-2是根据《INCOSE系统工程手册》IPO图改编的业务或使命分析过程。

按照ISO/IEC/IEEE 15288：2015标准，业务或使命分析过程包括以下活动。

1.准备业务或使命分析

本活动包含以下任务：

1）审查组织战略中关于组织所预期的目的或目标中被识别出的问题和机会。

2）定义业务或使命分析策略。

3）识别并计划必要的使能系统或所需的服务，以支持业务或使命分析。

4）获得或购买使能系统或服务的访问权。

2.定义问题或机会空间

本活动包含以下任务：

1）在相关的权衡空间因素背景下分析问题与机会。

2）定义使命、业务或运行的问题或机会。

3.描述解决方案空间特性

本活动包含以下任务：

1）定义初步的运行概念以及生存周期其他概念。

2）在整个潜在解空间识别候选的备选解决方案类别。

4.评估可选解决方案类别

本活动包含以下任务：

1）评估每一个可选解决方案类别。

2）选择首选解决方案类别。

5.管理业务和使命分析

本活动包含以下任务：

1）维护业务或使命分析的可追溯性。

2）为建立基线提供关键信息项。

4.1.4 关键要素解析

在业务或使命分析过程中有两个关键的概念——Concept of Operations(ConOps)与Operational Concept(OpsCon)——需要辨析清楚，同时，有三项输出成果需要关注——业务需求、业务或使命分析策略与可选解决方案类别。

1.ConOps与OpsCon的区别

业务或使命分析过程的输入有一项是ConOps，而输出项有初步生存周期概念文档，其中包含有一项重要的内容就是OpsCon。这两个概念比较容易混淆，下面就这两个概念进行解析。

ANSI/AIAA G043A：2012描述的“Concept of Operations”和“Operational Concept”通常可以互换使用，但是也存在重要的区别，每一个都有各自的目的，用来满足不同的结局。

按照ISO/IEC/IEEE 29148：2011需求工程标准，ConOps是在组织层面，处理领导层运作组织的预期方式。它可能涉及使用一个或多个系统，单个系统仅仅是为达到组织目的的一个黑盒。ConOps文件描述了关于整体运行或一系列业务运营使用将要被开发的系统、现有系统以及未来可能的系统的假设或意图。ConOps通常在长远的战略规划和年度经营计划中出现。

ConOps文件作为组织的基础，用来指导未来的业务和系统整体特性，了解项目的背景，并指导用户获取相关方的需求（ISO/IEC/IEEE 29148）。

按照ISO/IEC/IEEE 29148：2011需求工程标准，OpsCon是一个系统的运行概念。文档描述系统将做什么（不是怎么做）和为什么这么做（论据）。一个OpsCon是面向用户的文档，从用户的视角描述了将要移交的系统的特点。OpsCon文件是用来在采办方、使用者、供应商和其他组织要素之间沟通系统整体的定性或定量特性的。

在INCOSE《系统工程手册——系统生存周期过程和活动指南》（张新国译）中，将ConOps翻译为“运行意图”，在《NASA系统工程手册》（朱一凡等译）中将ConOps翻译成“运行使用构想”，它与组织的发展战略相关，而不限于组织计划拟开发的特定系统或服务。在本书中将ConOps翻译为“使用构想或作战想定”，其中，作战想定主要面向军事领域；OpsCon翻译为“运行概念”。

图4-3明确地表达了ConOps与OpsCon之间的关系。ConOps是在组织层面描述组织的预期运作方式、目的与目标。ConOps的目的是提供组织（事业）运行的全局画面，描述了组织业务使用一系列系统的假设与企图。

而OpsCon是在系统层面，针对某一个特定的系统，描述系统为了完成使命任务将要做什么以及为什么这么做。采用场景和“What-if”思维在复杂和不确定的环境中规划和决策。让人们以一种创造性的方式思考、观察各种涌现的情况以减少对重要因素的忽视。

在工程领域，通常ConOps所描述的对象是多个系统组合形成的体系，因此定义者一定是站在某一个具体系统对象之上来看这个组合的。OpsCon所描述的是一个确定的系统对象，在描述OpsCon的过程中，以某个特定系统对象为核心，将这个特定的对象纳入体系环境中去考虑，需要描述体系中的其他系统与目标系统之间的交互，是以某个特定系统对象为核心的一对多的关系表达；而描述ConOps时，需要考虑构成体系的所有系统之间的交互，是多对多的关系描述。

2.业务需求规格说明（BRS）

业务需求描述了为什么要启动一个项目，项目将要实现什么，以及哪些指标将被用来衡量项目的成功。

业务需求规格说明（Business Requirements Specification，BRS）描述了组织如何寻求新的业务或改变现有业务以适应新的业务环境，以及如何利用系统促进业务。

业务需求规格说明在组织层面描述组织的环境、目的与目标、业务模型、信息环境，以及在业务运营层面描述业务运行模型、业务运行模式、业务运行质量水平、提案系统的概念和组织模式，是在业务管理层面一份非常重要的文件。

业务需求规格说明（BRS）的内容根据组织业务确定，业务管理对业务需求规格的内容负责。BRS可以作为相关方参与需求过程的活动基础，比如，业务分析可以审查BRS并讨论业务模型和运行，业务管理可以审查BRS，系统分析也可以审查BRS并讨论潜在的技术解决方案。典型的BRS包括组织需求和业务需求。

虽然在本章开篇就强调了业务或使命分析过程侧重于业务管理层面，相关方需要与需求定义过程侧重于业务运行层面，但业务管理与业务运行紧密关联，因此在很多领域，业务需求规格说明（BRS）通常与相关方需求规格说明（StRS）一起确定，在较早期的ISO/IEC 15288：2002标准中，这两个过程并没有拆分，同时在ISO/IEC/IEEE 29148：2011版本中，也是将业务需求与相关方需求置于同一份需求规格文档。

《业务分析知识体系》（Business Analysis Body Of Knowledge，BABOK）将业务需求和相关方需求拆分开来，ISO/IEC/IEEE 15288：2015标准中也将业务或使命分析过程与相关方需要与需求定义过程分开。在ISO/IEC/IEEE 29148：2018需求工程过程标准中，业务需求规格说明与相关方需求规格说明被拆分为两份文档。业务需求规格说明的范例轮廓见表4-1。在这两份需求规格说明中，有很多内容具有相似性。

关于业务需求规格说明（BRS）各信息项的具体内容，请参考附录D.1。

3.业务或使命分析策略

“业务或使命分析策略”是业务或使命分析过程中的第一项活动——准备业务或使命分析的输出物，很多人不太清楚“业务或使命分析策略”应该如何写，在《INCOSE系统工程手册（第4版）》的附录E中，对于“业务或使命分析策略”仅给出了比较简单的描述：

开展业务或使命分析、确保业务需要被阐述并正式化为业务需求所需要的方法、进度、资源以及相关注意事项。

BABOK V2对业务分析进行了比较详细的描述，业务分析策略包括：

（1）规划业务分析方法 需要选择一个方法来执行业务或使命分析，确定哪些相关方会参与决策、将要咨询哪些人、适应该方法的理由等内容。同时，分析师需要理解组织过程需要与目标，这些需要与目标包含与其他组织程序的兼容性、上市时间的约束、相关的法律法规以及监管框架等。

在业务或使命分析方法中，需要制定团队的角色、可移交的成果、使用到的分析技术、与相关方的互动时间与频率，并确定业务或使命分析过程的活动。

（2）规划业务分析活动与进度 确定业务分析必须执行的活动，必须产生的可移交成果，估算完成工作所需要的工作量，并确定相关的工具来度量这些活动的进展与成果。

针对一个给定项目，业务分析师需要确定有哪些活动、如何实现、工作量以及完成这些活动需要多长时间等。具体内容包括工作范围、可移交的工作分解结构（WBS）、活动清单以及对每一个活动与任务的评估。

（3）规划业务分析沟通计划 业务分析沟通计划是针对拟议的跟业务分析活动相关的沟通工作的安排，记录并组织业务分析工作、会议、走查或其他交流活动。

（4）规划需求管理过程 主要是确定需求变更过程，需要哪些相关方批准变更，发生变更时需要咨询哪些人、需要通知哪些人，以及评估需求的必要性等。

业务或使命分析策略会作为项目管理的输入融入项目管理中，从这个意义上讲，《INCOSE系统工程手册（第4版）》中在每一个过程中所包含的准备活动，其成果——“关于×××业务或使命分析策略”——成为联系系统工程技术过程与技术管理过程（项目管理）的纽带。

4.1.5 案例——空中运输系统业务或使命分析

在空中运输系统的案例中，最初的业务使命就是解决从城市A到城市B的运输问题。按照业务或使命分析过程的相关活动，要完成从城市A到城市B的业务或使命分析工作，需要开展以下几项活动。

1.完成业务或使命分析策划

1）按照SMART原则（Specific、Measurable、Achievable、Relevant、Time-Bounded）分析组织的使命、愿景与目标。

2）确定项目类型。通常的项目类型包括可行性研究、过程改进、组织变更、新系统开发（内部）、新系统开发（外包）、系统维护与增强、软件包选择。

3）确定业务分析可交付成果。例如，工作分解结构（WBS）、工作说明（SoW）、立项论证报告等。

4）确定业务分析活动。定义工作范围的一个很重要的工具就是WBS（工作分解结构），通过不同方式产生活动清单。

2.描述业务问题与机会

为了定义业务需要，问题一定要调查清楚，以确保有解决问题的机会。在问题与机会分析中，要注意以下几点：

1）分析问题的负面影响，尽量量化，如可能的利润丧失、无效、客户不满意、员工（股民）士气低落。

2）期望的利益（如利润增加、减少成本、增加市场份额）。

3）如何能够尽快地解决问题或者形成机会；不作为的代价与后果。

3.确定期望的结果

可能包括：

1）形成新的能力。

2）增加利润，通过增加销售减少成本。

3）增加用户满意度。

4）增加员工（股民）满意度。

5）符合新规则。

6）增加安全性。

7）减少移交时间。

4.找出并确定最优解决方案类别

在本案例中，地面运输、空中运输、水上运输是根据A、B两个城市之间的实际运输环境而确定三种解决方案类别，如图4-4所示。不同的解决方案类别决定了未来的业务技术路线与方向。根据性能、效率、维修性、后勤保障以及经济性标准进行权衡分析，评价出最可行的解决方案类别。评价过程中，需要考虑到技术的类型和成熟度、它的稳定性和增长潜力、技术的预期生命以及资源的数量等。可行性分析的结果对系统的使用特性有着深远的影响，包括可生产性、保障性、可弃置性以及其他一些类似的特性。因此，在进行可行性分析时，一定要考虑到全生存周期。

在本案例中，经过可行性分析后，确定了空中运输解决方案类别。

5.定义初步运行概念

当确定了解决方案类别后，需要根据解决方案类别定义初步的运行概念。在空中运输系统中，顶层的初步运行概念在图4-4下部分的图形中通过任务剖面表达出来。空中运输系统将从城市A开始任务，起飞爬升—空中巡航—下降—进近—降落到达城市B结束任务。

在业务或使命分析过程中，还包括其他活动，本案例暂不对其他活动进行详细阐述。