阐述业务或任务分析流程,定义业务或任务问题或机会,描述解决方案空间,确定可以解决问题或利用机会的潜在解决方案类别。

1 目的

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

注:业务和使命分析与组织有关,涵盖关注软件生命周期活动的利益相关者。此过程与组织的战略 1相互作用,而组织战略通常不在 ISO/IEC/IEEE12207 的范围内。组织战略分析的结果包括组织运营概念、战略目标和计划、新市场或使命要素以及已确定的问题和机会。组织战略确定了执行业务或使命分析的背景。组织运营概念与领导层运营组织的预期方式有关。它描述了组织的假设以及它打算如何使用、获取或提供将要开发的系统、现有系统和可能的未来系统来支持业务的整体运营或一系列运营。如果该组织是系统利益,组织的策略是系统定义的一部分。

注:此过程适用于软件系统解决方案的整个生命周期,并且可以根据环境、需求或其他驱动因素的变化进行修改。

注:在某些领域,业务或任务分析涉及识别和分析组织所需或期望的能力的概念。此过程侧重于必要的能力并与投资组合互动识别可解决该能力的交易空间的管理流程。识别的问题或机会通常会转化为目标能力。当适用于给定领域时,问题或机会空间包括目标能力。

2 结果

成功实施业务或任务分析流程的结果是:

    1. 定义问题或机会空间。
    1. 对解空间进行特征化。
    1. 定义初步的操作概念和生命周期阶段 2中的其他概念。
    1. 识别并分析候选替代解决方案类别。
    1. 选择优先候选替代解决方案类别。
    1. 任何业务或任务分析所需的支持系统或服务均可用。
    1. 建立业务或任务问题和机会的可追溯性 3以及首选的替代解决方案类别。

3 活动和任务

项目应根据与业务或任务分析过程相关的适用组织政策和程序实施以下活动和任务。

a)准备业务或任务分析。此活动包括以下任务:

    1. 根据期望的组织目标或目的审查组织战略中已发现的问题和机会。

注意这包括与组织业务或使命、愿景、运营理念和其他组织战略目标和目的有关的问题或机遇。这包括已发现的缺陷或现有能力、系统、产品或服务的差距。

2)定义业务或任务分析策略。

注意这包括用于识别和定义问题空间 4、描述解决方案空间和选择解决方案类的方法。

3)识别并规划支持业务或任务所需的必要支持系统或服务分析。

注:这包括识别启用系统的要求和接口。用于业务或任务分析的启用系统包括组织或其他可访问实体的业务系统和存储库。

    1. 获取或获得将要使用的支持系统或服务的访问权。

注:验证过程 5用于客观确认支持系统是否实现了其支持的预期用途。

b)定义问题或机会空间。此活动包括以下任务:

1)结合相关的贸易空间因素,分析顾客投诉、问题和机会。

注:本分析侧重于了解问题或机遇的范围、基础或驱动因素,而不是贸易研究所需的系统分析和决策管理的重点 综合。这里的重点包括任务要求的变化、商业机会、能力、绩效改进或缺乏现有系统、安全性改进、成本和有效性等因素、法规变化、用户不满意度以及 PESTEL 因素(政治、经济、社会、技术、环境和法律)。相关因素可以通过外部、内部或 SWOT 6(优势、劣势、机会和威胁)分析来确定。

注:分析的输出被视为投资组合管理决策的一部分。

2)定义使命、业务、运营问题或机会。

注意:此定义包括上下文和任何关键参数,与具体解决方案无关,因为解决方案可以是操作变更、现有产品或服务的变更或新系统的变更。

c)描述解决方案空间。此活动包括以下任务:

1)定义初步的操作概念和生命周期阶段的其他概念。

注:这涉及识别主要的利益相关者群体,例如客户、用户、主管部门、监管机构和系统所有者,这些群体在利益相关者需求和要求定义过程 7中定义。

注:初步生命周期概念包括初步获取概念、初步部署概念、初步操作概念、初步支持概念和初步退役概念。操作概念包括高级操作模式或状态、操作场景、 潜在用例或在拟议业务战略中的使用。这些概念能够进行可行性分析和替代方案评估。这些概念在利益相关者 8需求和要求定义过程中得到进一步细化。

注:操作环境可能存在与特定安全威胁和安全隐患相关的已知漏洞。需要结合正在开发的产品来了解这些漏洞。系统和人机界面是系统保证环境的一个要素,相关的漏洞在任务关键型威胁的环境中进行检查。

2)确定涵盖潜在解决方案空间的候选替代解决方案类别。

注:这些类别可以从简单的操作更改到各种软件系统开发或修改。该解决方案空间可以包括对现有资产、 系统和适合重用的软件产品的识别,以及可以满足操作或功能修改需求的服务变更。这包括推断可能需要哪些潜在的预期服务。 解决方案空间特性通常调用架构定义过程 9来获取用户架构视点,从而产生架构视图(例如,能力视图、程序视图和操作视图),如 ISO/IEC/IEEE 42010 所提议的那样。

d)评估备选解决方案类别。此活动包括以下任务:

1)评估每个替代解决方案类别。

注:每个备选解决方案类别均根据基于组织战略而建立的既定标准进行评估。解决方案类别的可行性是一项关键的决策标准。投资组合管理流程提供了一些需要考虑的标准。

注:系统分析过程 10用于评估每个替代解决方案类别的每个标准的值。建议进行结构化的可负担性权衡。将成本作为标准将有助于做出可负担性决策。替代方案的评估可以包括建模、模拟、分析技术或专家判断,以了解替代候选解决方案类别的风险、可行性和价值。

2)选择首选的替代解决方案类别。

注:决策管理过程用于评估替代方案并指导选择。选定的替代方案在组织战略的背景下进行验证。提供有关风险、可行性、市场因素和替代方案的反馈,以供更新组织战略使用。

e)管理业务或任务分析。此活动包括以下任务:

1)保持业务或任务分析的可追溯性。

注意在整个生命周期中,业务和任务问题与机会以及首选替代解决方案类别与组织战略、利益相关者的需求和要求以及支持决策的系统分析结果之间保持双向可追溯性。

    1. 提供已选定的基线关键工件和信息项。

注意配置管理流程用于建立和维护配置项和基线。此流程确定基线的候选者,而信息管理流程控制信息项。


  1. 战略分析. https://srs.pub/babok/strategy.html↩︎

  2. 通用生命周期阶段之生命周期阶段. https://srs.pub/specification/incose-lifecycle-stages.html↩︎

  3. 需求生命周期管理中的追踪需求. http://www.srs.pub/babok/trace-requirements.html↩︎

  4. 需求分析. https://srs.pub/theory/ai-problem-space.html↩︎

  5. 技术过程之验证过程. https://srs.pub/specification/incose-verification-process.html↩︎

  6. 商业分析中的五十种分析方法和技巧之46-SWOT. https://srs.pub/babok/swot.html↩︎

  7. 技术过程之利益相关者需求和要求定义过程. https://srs.pub/specification/incose-stakeholder-needs-and-requirements-definition-process.html↩︎

  8. 管理层变更与软件项目稳定性-利益相关者分析与沟通艺术. http://www.srs.pub/theory/stakeholder-driven-changes.html↩︎

  9. 技术过程之架构定义过程. https://srs.pub/specification/incose-architecture-definition-process.html↩︎

  10. 技术过程之系统分析过程. https://srs.pub/specification/incose-system-analysis-process.html↩︎