信息技术视角

信息技术视角侧重于从信息技术系统变化对商业分析的影响的角度来研究商业分析的特点。

这个视角关注的是非敏捷方法来处理IT项目。

在信息技术领域工作时，商业分析师需要处理各种复杂性和活动范围。 举措可能很小，例如修复小错误和增强功能，也可能很大，例如为大型企业重新设计整个信息技术基础设施。 商业分析师被要求具备这种多样化的知识和技能。为涉众提供有价值的解决方案，以满足他们的IT需求。

关于在信息技术项目中使用敏捷方法，参见《敏捷视角 ^[1]》。

能够有效地将业务愿景和技术需求传达给技术人员, 这在信息技术领域，对商业分析师的成功至关重要。 商业分析师积极与业务涉众和开发团队合作，确保需求得到理解并符合组织战略。 商业分析师经常扮演翻译者的角色 ^[2]，帮助业务和技术涉众了解彼此的需求、约束和背景。 在技术环境中，解决方案设计的概念对于IT商业分析师来说是合适的。 然而，在IT环境中讨论“设计”时，通常假定其意味着“技术设计”，即利用技术来解决业务问题。 在IT环境中，商业分析师定义和详细说明解决方案要求或与业务涉众参与解决方案设计，同时与技术设计保持分离。

在信息技术环境中，术语“设计”传统上是指由开发人员、IT 架构师或解决方案架构师执行的解决方案或技术设计。 商业分析师所做的所有工作都属于“需求”的范畴，包括定义和设计业务流程、用户界面、报告或其他与实施团队以外的相关方有关的解决方案元素的概念。 在这种情况下工作的商业分析师可能会更喜欢使用术语“解决方案要求”，而不是“设计”，以便明确责任分工。

在信息技术环境中工作的商业分析师会根据 三个关键因素 来考虑他们的任务：

• 解决方案影响：解决方案对业务的价值和风险。
• 组织成熟度：组织变革过程的形式化与灵活性。
• 变更范围：变更所涵盖的广度、深度、复杂性和上下文。

1 范围变更

IT系统变更通常由多种原因引发。以下各项触发因素都可能导致IT系统变更：

• 创建新的组织能力：可以执行以改变组织。这种类型的 IT 举措可能会推动创建更大的计划来解决非 IT 变化，但重点在于一项技术，它可以改变业务环境。
• 通过增强现有能力来实现组织目标：这是满足明确需求的变革的一部分。这可能包括为满足监管要求或实现业务特定目标而进行的变更。这种类型的倡议通常会修改现有系统，但也可能需要实施和集成新系统。
• 促进运营改进：旨在提高组织效率或降低组织风险。变更范围、组织成熟度和解决方案影响决定了这些变更是否作为项目进行管理，还是作为持续改进工作的一部分，或者是作为增强功能。
• 维护现有的信息技术系统：进行维护是为了确保现有IT系统的平稳运行。根据变更范围，维护可以作为项目或定期安排的活动来管理。这可能包括技术驱动的更改，例如供应商 ^[3]终止对技术的支持、计划发布或升级购买的软件包，或为支持架构策略所需的技术修改。
• 修复一个故障的信息技术系统：当一个没有按预期运行的信息系统被修改以纠正故障时，就会进行这项工作。维修的紧急程度通常根据造成的中断级别来确定。在某些情况下，维修范围非常大，因此将其作为项目管理。

.1 变革广度

信息技术倡议可能专注于一个系统或多个相互交互的系统。一些系统由内部开发和维护，而其他系统则是由实施系统的外部组织开发的商用现货 (COTS) 系统。也有可能是由外部组织完成定制开发，例如当开发任务外包或承包出去时。

IT 项目的范围通常只关注软件、硬件以及一组最小化的系统、应用程序或涉众。更大的项目可能会影响多个用户组或系统，而且往往需要与企业外部合作。COTS 信息技术系统的实施在启动时可能会有较小的或有限的范围，但分析完成后其范围比最初预期的要大得多。选择和实现 COTS 的商业分析方法与内部开发不同。这些 IT 系统几乎总是需要定制、集成、管理和培训。有时，这些举措仅限于初始安装和部署，或者对现有应用进行增强。IT 举措还可以专注于非常具体的技术解决方案，例如需要哪些数据、如何收集数据，如何存储和访问以支持业务交易方法，或者信息是如何向企业集团报告和可用的。

在 IT 领域工作的商业分析师会仔细考虑任何信息技术变革的上下文。他们考虑变革是以项目、持续改进还是维护活动的形式进行管理。商业分析师还考虑组织变革管理和所有影响，包括培训、沟通和采用变革。

在IT环境中，商业分析活动的性质取决于多种解决方案影响因素：

如果这个系统关闭了，公司会发生什么？

• 如果系统性能下降了怎么办？
• 业务能力与流程依赖于哪些 IT 系统？
• 谁为这些能力和流程做出了贡献？
• 谁使用这些功能和流程？

在考虑这些解决方案的影响因素时，商业分析师不仅要匹配分析活动的形式与组织定义的商业分析过程，还要考虑IT系统的重要性。被分析系统的相关性可能表明需要更多的分析来支持并定义变更的要求。

.2 变化的深度

IT 环境中的变化经常要求商业分析师明确细节，包括诸如个别数据元素的定义之类的详细技术细节，这些数据元素正在被更改或受到影响。集成工作可能需要在识别和定义 IT 系统之间的接口时进行详细的分析和定义。由于此类倡议所需的详细程度，商业分析师会收集并分析组织的整体运作方式以及 IT 系统如何支持这些操作。这为商业分析师提供了必要的背景信息，以了解发现和记录的详细信息是否与实现价值相关。当出于技术驱动的原因启动 IT 系统变更但缺乏足够的清晰度或与业务目标的一致性时，这一点可能会变得特别具有挑战性。

.3 交付的价值与方案

信息技术系统被实现是为了增加组织价值，包括任何使用该系统的支持能力和过程。商业分析师寻求对齐IT功能与这些流程和能力，并衡量系统对其的影响。

IT 系统的变化可以通过多种方式增加价值，包括：

• 减少运营成本，
• 减少浪费的努力，
• 增加战略协同，
• 提高可靠性和稳定性，
• 自动化容易出错或需要人工处理的过程，
• 修复问题，
• 使业务能力得到扩展、增强或更易于获得，以及
• 实施新的功能和能力。

.4 交付方法

在IT组织中开展商业分析活动的方式各不相同。这些举措可能包括小规模的改进，通过一个短时间框架内的单次发布来完成，也可能是多阶段、多次发布的实施。

短期时间框架倡议可能涉及一个商业分析师在短期内。更大的努力通常会涉及几个商业分析员，他们可能会以多种方式协调分析活动。商业分析人员可以根据参与的业务组或特定活动来划分工作。

.5 重要假设

IT 领域的主要假设如下：

• 业务能力和流程 使用IT系统，为组织提供价值，
• 从其他角度工作的商业分析师可以与 IT 商业分析师的工作相结合，
• 通常，IT 系统变更由业务需求驱动，尽管有些倡议可能源自技术发展。

2 商业分析范围

.1 变更发起人

信息技术变革可能由业务发起人、IT 部门或两者的合作提出或赞助。这些变化应与组织战略和商业目标保持一致。 IT部门可以启动变革以使其与技术策略对齐，或实现技术目标，但总体上与组织战略的一致性仍然是成功变革的关键。

以下是可能的变更发起人：

• 技术团队，
• 技术主管，
• 应用程序所有者，
• 过程所有者，
• 企业主，
• 内部产品经理，以及
  监管机构（如公司法务部）。

企业可以使用多种方法来启动与信息技术相关的变更。通常，大型企业会在 IT 部门内设立一个项目或计划管理办公室，该办公室会接收请求并代表部门优先处理工作。

.2 变更目标

商业分析师识别所有可能受到提议变更影响的部门、流程、应用和功能。 商业分析师不仅关注倡议的细节，还着眼于大局以及变革（无论是商业还是技术）的潜在影响。 这涉及到对流程和技术接口以及流程交接进行特定重点的流程和功能分析。

. 3 商业分析师职位

在 信息技术 发展计划中，商业分析活动可能会由组织内的不同背景或职位的人员担任。这项任务可能取决于变化类型、经验水平、所需知识，或者仅仅是为该任务提供人力所必需的人员。由于以下描述的经验，人员可以被分配到商业分析任务，并且可能完成给定变更的所有或部分商业分析职责。

有可能所有与IT项目相关的商业分析任务都由具备下列背景之一的人来完成：

• 专门与 IT 系统中的业务用户打交道的商业分析师，
• 作为IT商业分析师，负责技术团队与使用应用程序的业务团队之间的联络；
• 一位对当前软件实施有经验的主题专家（SME），
• 一个熟悉软件日常使用并能够关注可用性的 软件用户，
• 有业务领域经验，但没有特定应用程序经验的 系统分析师
• 业务流程所有者对业务功能或流程有深入的了解，但可能没有任何技术或 IT 经验，
• 有丰富的技术经验的技术人员，或
• 一个代表商业现货的产品，可以定制一个包装解决方案，并利用供应商的包和以往的经验。

.4 商业分析结果

在IT倡议中，商业分析师可能会考虑受变更影响的业务流程以及系统收集的数据和商业智能 ^[4]信息。 该倡议中的商业分析师彻底规划了商业分析工作及其支持变更工作的成果。

所采用的方法直接关系到商业分析成果或结果。许多组织都有明确的系统或解决方案开发方法，这在一定程度上规定了每个项目里程碑所需的交付成果。即使在这种结构内，商业分析师也可以尝试完成超出变更方法或组织特定流程所需之外的其他交付成果，并使用支持对变更工作进行全面了解的技术。

在信息技术领域工作的商业分析师负责提供以下任何一项：

• 定义、完整、可测试、有优先级 ^[5]且经过验证的需求，
• 选择分析，
• 商业规则，
• 跨度分析，
• 功能分解 ^[6]，
• 用例和场景，以及/或适当的故事叙述，
• 接口分析 ^[7]，
• 原型，
• 过程分析 ^[8]，
• 过程模型，
• 状态模型，
• 决策模型，
• 上下文模型或范围模型，以及
• 数据模型。

除上述列表中所包含的内容外，与商业分析技术产生的任何输出相关的其他交付成果也可能被视为商业分析师的交付成果。

3 方法

信息技术组织遵循的方法各不相同。

一般来说，解决方案开发方法分为两种通用方法：

• 预测性：强调计划和正式记录用于完成更改的过程的结构化过程。在进入下一阶段之前，必须完成过程或序列中的每个阶段。
• 自适应：允许在整体结构化过程循环中的一个或多个中重新处理的过程。大多数自适应模型都是迭代和增量式的，专注于在广度和深度上扩展产品。

也可以使用混合方法。 混合方法可能包括整个倡议的总体愿景（如预测），以及个别周期或迭代内的详细信息定义（如适应）。

下表列出了商业分析师在信息技术环境中可能遇到的一些成熟的 方法 或方法。
表 11.3.1：信息技术方法

方法论	简介
自主开发或组织特定	由信息技术组织创建的一种方法论，它源于其他已建立方法论或方法的组成部分，用于管理基于信息技术的举措。
需求工程（RE）	建立了一种结构化的需求开发 [9]和管理方法，适用于预测型、适应型以及敏捷环境。
结构化系统分析与设计方法（SSADM）	一种预测型开发方法论，侧重于成熟逻辑建模，并将需求与解决方案分离作为系统分析和规格说明的核心。
统一过程（UP）	一种适应型开发方法。其中初始阶段和细化阶段对于商业分析师尤其重要。尽管UP不是敏捷方法论，但它是一种适应型方法。

4 基础技能(基本功)

在IT领域工作的商业分析师可能具备与IT开发相关的技能，例如编程、创建数据库或创建系统或解决方案架构、软件测试经验或其他技术技能。然而，在 IT 环境中，商业分析师并不一定需要具备与开发相关的技能或技术技能才能取得成功。商业分析师对需求包中的详细要求有深入理解，以支持技术解决方案至关重要，同时还要了解在组织的技术架构约束下在技术上可行的内容。这些技能将使商业分析师能够与所有涉众合作设计业务解决方案框架，这也将允许技术团队设计灵活的技术解决方案。

商业分析师在与涉众打交道时使用影响和促进技术。 当需要达成协议或做出决策时，经常使用谈判技术，例如解决方案的成本（无论是预算、时间还是架构影响）与期望的商业结果相冲突。

系统思维对于在 IT 环境中工作的商业分析师来说是一项关键技能。系统思维支持商业分析师能够从整体上看到任何其他可能受到影响的应用程序或技术方面，具体需求的细节以及可能的技术解决方案。系统思维也支持识别对人员、流程和软件产生的影响，这些影响不一定直接作为 IT 发展工作的一部分进行更改，并分析这些影响的风险和可能的结果。

5 影响知识领域

本节解释了信息技术中特定的商业分析实践如何映射到babok指南中定义的商业分析任务和实践。它还描述了每个知识领域在IT学科中的应用或修改。

每个知识领域都列出了与信息技术视角相关的技术。 在信息技术学科中使用的技术不会偏离 BABOK 指南中的技术。 BABOK指南技术可以在 BABOK指南的“技术”章节中找到。 这并不是要提供技术的详尽列表，而是要突出商业分析师在知识领域内执行任务时所使用的技术类型。

.1 商业分析规划与监控

商业分析方法是一种基本的沟通工具，可用于识别商业分析工作所需的资源，并确保为分析工作提供足够的时间。 定义良好的商业分析计划已融入整体项目计划，并为商业分析师提供了定义和安排项目中商业分析活动的机会。

许多组织已经建立了某些标准和流程，这些标准和流程可能会确定特定的分析任务和可交付成果。如果没有这些标准和流程，则商业分析师会根据具体倡议的需求来识别这些任务和可交付成果。

重要的是要理解分析工作所处的上下文。这包括了解软件系统、业务流程以及从一个系统传递到下一个系统的数据之间的相互作用。任何一个系统或过程的变化都可能产生涟漪效应，使其他系统、流程或涉众群体成为该倡议的范围。

IT 商业分析师可能会被嵌入到软件团队中。这种方法允许商业分析师对特定的软件或由软件支持的过程非常了解。每个具体的更改都会改变或转移涉众的态度和需求。每个变更都计划了角色、协作和沟通计划。

商用解决方案可能需要大量的系统集成工作、定制以及许多意想不到的任务，因为引入了外部软件。当规划未知的影响和未定义的自定义需求时，商业分析师会同时与了解变更需求的内部涉众和具有正在实施的商用解决方案专业知识的外部涉众合作。

BABOK 指南 技术

• 条目管理
• 组织建模 ^[10]
• 文档分析 ^[11]
• 角色和权限矩阵
• 估算 ^[12]
• 功能分解
• 范围建模 ^[13]
• 积压管理 ^[14]
• 涉众列表 ^[15]
• 度量和关键指标（KPI ^[16]）

.2 需求挖掘和协作

信息技术变更常常会影响到众多与解决方案或变更有着不同关联的利益相关者。当变更涉及到IT应用或系统时，技术人员可能具备的专业知识、视角或经验能够识别出在定义需求和解决方案过程中对系统或流程的额外影响。因此，在同一时间和地点将IT技术人员（如开发人员或技术设计人员）与业务领域专家一同安排至少一次的需求挖掘会议是非常有益的。此类需求获取方式提供了技术和业务团队之间的协作平台，其中IT业务分析师扮演着促进者和联络人的角色。

在IT环境中实践的业务分析师可能会利用《Elicitation and Collaboration知识领域》中所识别的各种技术。此外，以下方法在信息技术领域也能带来极大益处：

• 调查：利用组织过程资产、市场研究、竞争分析、功能规格说明以及观察 ^[17]等方式；
• 模拟：利用统计建模和模型演示；
• 实验：利用概念验证、原型、α版和β版发布，以及A/B测试。

若业务利益相关者认为某项信息技术变更并非任务关键，或者他们从变更中体验到负值，那么他们可能会视此变更为空耗精力或成本。这可能导致在需求挖掘方面的参与变得困难。跨越组织边界的挖掘工作可能会受阻，进而导致协作破裂和返工。IT业务分析师可以通过促使信息技术和业务资源参与协作活动，从而降低返工的风险。

BABOK®指南中的相关技术：

• 头脑风暴 ^[18]
• 协作游戏 ^[19]
• 文档分析
• 焦点小组 ^[20]
• 接口分析
• 访谈 ^[21]
• 观察
• 流程建模
• 原型设计 ^[22]
• 范围建模
• 顺序图
• 利益相关者列表、地图或人物角色
• 状态建模 ^[23]
• 调查或问卷调查
• 用例和场景分析
• 研讨会 ^[24]

.3 需求生命周期管理

IT 举措在实现变革的过程中经常会有重大发现。商业分析师通过探索发现了解决方案提供的新功能的影响。这种在 IT 环境中的发现感，导致了短期周期时间（敏捷和持续改进）、严格变更控制（能力成熟度模型集成 (CMMI) 和预测性）以及外部化信息技术（软件即服务 (SaaS) 和云服务）的发展。

在IT领域工作的商业分析师特别关注对齐、批准、变更控制、跟踪和需求生命周期管理工具。 商业分析师的作用是与涉众合作，制定一致的方法来审查不断变化的需求，以确保符合该倡议的商业目标。

在许多情况下，对批准的要求进行更改是由更高层次的要求（如业务目标）的变化驱动的。 商业分析师与涉众合作，确保这些要求在继续到解决方案或技术需求之前保持稳定。 当出现要求更改时，商业分析师会分析影响并计划如何管理建议的更改。

随着信息技术环境的复杂性不断增加，对每个需求或需求和其他信息之间的每一个更改进行跟踪变得越来越重要。
可追溯性，包括对要求之间的依赖关系和相互关系进行说明，有助于涉众了解 IT 系统的变化情况，并预测额外变化可能产生的影响。

随着技术系统的演进，当每个版本的需求以某种方式被存储并得到跟踪时，会有帮助。 可追溯性使我们能够找到每个请求的功能和服务的来源、所有者以及它们是如何随着时间推移而变化的。 这个历史很重要，因为它确保了需求是完整的，并且对需求的认可是明智的决定。 当变更工作和IT系统受到审计时，监管机构和其他涉众可以了解发生了什么、何时发生、为何发生。 对于审计目的来说，这一点可能特别重要，因为应用程序在处理数据或流程时不需要人为干预，无论是事务还是过程实例。 此外，这种追踪还有助于组织了解为什么某些功能没有在IT系统中交付或实现，以及为什么这些功能会从所实施的范围中删除。

BABOK 指南 技术

• 接受和评估标准
• 指标和关键绩效指标 （KPIs）
• 决策分析 ^[25]
• 优先排序
• 跟踪物品

.4 策略分析

在IT组织中，战略分析侧重于受提议变更影响的技术和系统、业务单位、业务流程和业务策略。变更的影响可能会通过组织内的其他系统产生连锁反应。为了分析需求和建议的更改，商业分析师寻求了解可能受到变更影响的所有不同方面。

在IT倡议中，对当前状态的分析包括对 人工流程 的分析、了解系统或技术目前所做的事情、完成任务所需的数据以及与其他系统交互的过程。商业分析师首先计划对当前状态有一个全面的理解，并且需要理解范围会在未来状态被确定时缩小。

一旦当前状态被理解，理想未来状态就会被描述。 这可能与流程或能力有关，并且通常包括如何要求当前系统功能发生变化以支持未来的愿景并满足个人涉众和企业的目标。 通过了解当前和未来状态，可以确定两者之间的差距，这就是变更努力的方向所在。 在分析阶段，解决方案选项会得到探索。

一旦了解了变化范围和期望的未来状态，商业分析师评估不确定性。不确定性的澄清如下：

• 识别并定义风险，
• 确定并定义潜在的利益，
• 确定已知过程和操作的变异性参数，以及
• 探索未知。

商业分析师还探讨了其他潜在风险，包括：

• 供应商风险，如他们的业务和产品稳定性，
• 对系统技术环境的影响，
• 解决方案应能随交易量或用户数量的增加而扩大，
• 根据发起的变化，需要额外的过程或系统更改。

BABOK 指南 技术

• 过程分析
• 业务能力分析
• 过程建模 ^[26]
• 焦点小组
• 范围建模
• 功能分解
• 调查问卷 ^[27]
• 访谈
• SWOT ^[28]分析
• 条目跟踪
• 供应商评估
• 观察
• 研讨会

.5 需求分析与设计定义

对在 IT 领域工作的商业分析师来说，了解并澄清“设计”这个词是非常重要的。许多 IT 组织认为，设计只适用于软件或技术变更的设计或蓝图。在需求分析与定义设计领域内，“设计”从更广泛的角度来看待，并且是从商业分析师的角度来看待的。设计是以方案为重点、关注如何通过构建来实现价值的可用表示形式。例如，无论是影响还是利用 IT 系统的潜在流程改进（例如），以及用户界面布局或报告定义，都可以视为设计。

商业分析师概述业务和技术需求，分解并定义涉众的需求，并确定一旦实施技术解决方案或更改后，将实现的利益。他们收集、定义和分析业务需求和涉众要求，以及定义、分析和设计解决方案的设计。他们以足够详细的程度来定义要求，以便将其用作解决方案设计的一部分，并用于技术设计。这包括功能需求和非功能需求。对于某些变更项目，非功能性需求的定义可能足以确定变更工作的所有业务目标。业务分析师通常依赖其他变革代理人来制定软件解决方案的技术设计。系统架构师、程序员、数据库管理员或其他技术专家通常需要确定如何运用技术来满足一系列需求。IT业务分析师负责定义流程步骤、业务规则、界面流程和报表布局。将系统、业务及系统流程的详细功能纳入需求定义，是解决方案设计的关键环节，并没有将分析与设计割裂开来。

作为需求分析的一部分，IT业务分析师可能与另一位关注点不同的业务分析师合作，比如企业级业务分析师或业务架构师，以确保IT需求与业务或组织战略相吻合。

需求分析和设计定义过程中，经常需要使用文字和图片等形式记录需求。在某些情况下，需求也可能通过其他方式呈现，例如概念验证、工作软件原型或模拟。不论何种情况，业务分析师都会致力于生成具有充分且适当细节的文档，以便：

• 业务方能够验证和确认需求；
• 开发人员能够据此进行设计；
• 测试人员能够在解决方案投入生产环境之前，根据这些文档对解决方案进行衡量和测试。

BABOK®指南技巧列表：

• 商业规则分析 ^[29]
• 数据字典 ^[30]
• 数据流 ^[31]图分析
• 数据建模 ^[32]
• 决策分析
• 决策建模 ^[33]
• 文档分析
• 估算
• 功能分解
• 术语表
• 接口分析
• 非功能性需求分析
• 组织建模
• 过程建模
• 原型制作
• 审查
• 角色与权限矩阵
• 范围建模
• 序列图 ^[34]
• 状态建模
• 用例和场景分析
• 用户故事 ^[35]

6. 解决方案评估

解决方案评估侧重于解决方案组件及其提供的价值。在IT语境中，这包括对多个系统在变化中以及周围环境中交互的关注。IT 领域的企业分析师了解解决方案的上下文以及单个系统或流程中的更改如何影响环境中的其他系统非常重要。这些影响可以为其他系统增加或减少价值，从而影响变更的整体价值实现。

在信息技术环境中，解决方案评估的一个方面是软件测试或解决方案测试。测试或质量保证确保解决方案按预期或设计运行，并满足发起变更努力的企业或涉众的需求。商业分析师与质量保证（测试人员）合作，以确保技术解决方案符合需求和其他商业分析交付成果所定义的业务需求。测试人员使用测试方法计划、开发和执行测试。这种解决方案测试通常侧重于全面的过程测试，包括跨系统测试，以确保端到端解决方案的质量和准确性。商业分析师与涉众合作，规划、开发和执行用户验收测试，以确保解决方案满足他们的需求。

商业分析师了解为什么要实施IT解决方案，以及这种方案如何为价值创造。 通常情况下，该方法与更好地支持业务流程和程序有关。

业务和技术目标与利益相关，这些利益通过用于评估成功的定义指标进行衡量。需求应追溯到目标，这种可追溯性为解决方案的评估提供了基础。对解决方案性能的分析侧重于技术系统及其如何为涉众提供潜在价值和实际价值。

当一个大型组织变革包含IT元素时，IT解决方案评估可以促进与整个变革计划相关的更广泛的收益实现活动。

作为解决方案评估活动的一部分，商业分析师可能会与团队合作完成任务，例如评估解决方案的局限性并评估这些局限性的影响。 商业分析师可以支持和评估为所有或部分开发的解决方案进行的技术测试工作。
BABOK 指南 技术

• 接受与评价标准 ^[36]
• 风险分析与管理 ^[37]
• 决策分析
• 过程建模
• 估计
• SWOT分析
• 供应商评估
• 跟踪物品
• 指标和关键绩效指标（KPI）
• 组织建模

本文同步发表在 软件需求探索的http://www.srs.pub/babok/xinxijishu-shijiao.html

---

1. 商业分析中的敏捷视角.http://www.srs.pub/babok/minjie-shijiao.html ↩

2. 商业分析中的五十种分析方法和技巧之39-角色与权限矩阵.http://www.srs.pub/babok/juese-yu-quanxian-juzhen.html ↩

3. 商业分析中的五十种分析方法和技巧之49-供应商评估.http://www.srs.pub/babok/gongyingshang-pinggu.html ↩

4. 商业分析中的商业智能视角.http://www.srs.pub/babok/shangyezhineng-shijiao.html ↩

5. 商业分析中的五十种分析方法和技巧之33-优先级.http://www.srs.pub/babok/youxianji.html ↩

6. 商业分析中的五十种分析方法和技巧之22-功能分解.http://www.srs.pub/babok/gongneng-fenjie.html ↩

7. 商业分析中的五十种分析方法和技巧之24-接口分析.http://www.srs.pub/babok/jiekoufenxi.html ↩

8. 商业分析中的五十种分析方法和技巧之34-过程分析.http://www.srs.pub/babok/guocheng-fenxi.html ↩

9. 需求开发向设计规划的转化.http://www.srs.pub/theory/xu-qiu-kai-fa-xiang-she-ji-gui-hua-de-zhuan-hua.html ↩

10. 商业分析中的五十种分析方法和技巧之32-组织建模.http://www.srs.pub/babok/zuzhi-jianmo.html ↩

11. 商业分析中的五十种分析方法和技巧之18-文档分析.http://www.srs.pub/babok/wendang-fenxi.html ↩

12. 商业分析中的五十种分析方法和技巧之19-估算.http://www.srs.pub/babok/gusuan.html ↩

13. 商业分析中的五十种分析方法和技巧之41-序列图.http://www.srs.pub/babok/fanwei-jianmo.html ↩

14. 商业分析中的五十种分析方法和技巧之2-积压追踪管理.http://www.srs.pub/babok/jiya-zhuizong-guanli.html ↩

15. 商业分析中的五十种分析方法和技巧之43-涉众列表或人物角色.http://www.srs.pub/babok/shezhong-liebiao-huo-renwu-juese.html ↩

16. 商业分析中的五十种分析方法和技巧之28-度量和关键绩效指标（KPI）.http://www.srs.pub/babok/duliang-he-guanjian-jixiao-zhibiao-kpi.html ↩

17. 商业分析中的五十种分析方法和技巧之31-观察.http://www.srs.pub/babok/guancha.html ↩

18. 商业分析中的五十种分析方法和技巧之5-头脑风暴.http://www.srs.pub/babok/tounao-fengbao.html ↩

19. 商业分析中的五十种分析方法和技巧之10-协作游戏.http://www.srs.pub/babok/xiezuo-youxi.html ↩

20. 商业分析中的五十种分析方法和技巧之21-焦点小组.http://www.srs.pub/babok/jiaodian-xiaozu.html ↩

21. 商业分析中的五十种分析方法和技巧之25-访谈.http://www.srs.pub/babok/fangtan.html ↩

22. 商业分析中的五十种分析方法和技巧之36-原型设计.http://www.srs.pub/babok/yuanxing-sheji.html ↩

23. 商业分析中的五十种分析方法和技巧之44-状态建模.http://www.srs.pub/babok/zhuangtai-jianmo.html ↩

24. 商业分析中的五十种分析方法和技巧之50-研讨会.http://www.srs.pub/babok/yantaohui.html ↩

25. 商业分析中的五十种分析方法和技巧之16-决策分析.http://www.srs.pub/babok/juecefenxi.html ↩

26. 商业分析中的五十种分析方法和技巧之35-过程建模.http://www.srs.pub/babok/guocheng-jianmo.html ↩

27. 商业分析中的五十种分析方法和技巧之45-调查或问卷.http://www.srs.pub/babok/diaocha-huo-wenjuan.html ↩

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

29. 商业分析中的五十种分析方法和技巧之9-商业规则分析.http://www.srs.pub/babok/shangye-guize-fenxi.html ↩

30. 商业分析中的五十种分析方法和技巧之12-数据字典.http://www.srs.pub/babok/shuju-zidian.html ↩

31. 商业分析中的五十种分析方法和技巧之13-数据流图.http://www.srs.pub/babok/shujuliu-tu.html ↩

32. 商业分析中的五十种分析方法和技巧之15-数据建模.http://www.srs.pub/babok/shuju-jianmo.html ↩

33. 商业分析中的五十种分析方法和技巧之17-决策建模.http://www.srs.pub/babok/juece-jianmo.html ↩

34. 商业分析中的五十种分析方法和技巧之42-序列图.http://www.srs.pub/babok/xulietu.html ↩

35. 商业分析中的五十种分析方法和技巧之48-用户故事.http://www.srs.pub/babok/yonghu-gushi.html ↩

36. 商业分析中的五十种分析方法和技巧之1-接受与评价标准.http://www.srs.pub/babok/jieshou-yu-pingjia-biaozhun.html ↩

37. 商业分析中的五十种分析方法和技巧之38-风险分析与管理.http://www.srs.pub/babok/fengxian-fenxi-yu-guanli.html ↩