六大知识领域：
战略分析：定义问题/目标和范围
需求分析和设计定义：解决方案的输入
解决方案的评估：前提条件是已有解决方案
CBAP®商业分析师（高级）认证培训课程
CBAP提升业务思考能力与分析水平，培养商业头脑。
价格
¥ 5000.00
该课程属于 CBAP®国际商业分析师认证备考班
请加入后再学习
需求分类
business requirement : 事情的目标。应用到整个企业或业务领域的业务/商务需求。
stakeholder/user requirement: 哪些人会用到或受到影响，他们具体的要求是什么。敏捷项目利用用户故事呈现，包含actor/action。瀑布性项目需要方案，涉及业务流程，用户体验的设计。
solution requirements: 业务解决方案所有的细节，包含功能/属性。理论上实施团队依靠此实现需求，但实际可能还有需要确认的方面。
需求收集和分析的过程不是一步完成的，需要迭代完成以上三个步骤。建议初步调研时不要调研的特别细节
Transition requirements: 转换/过渡需求，在解决方案部署前的过渡方案（人员培训解决方案/数据迁移）。特点：有一定时效性
解决方案在使用阶段仍产生作用，比如某些需求是持续性的（用户在线率）。在使用解决方案过程中对功能做调整是正常情况。
前三个在解决方案前完成，最后一个在解决方案后完成。
solution requirements:
分成
1. functional requirements 功能性需求
2. non - functional requirements 性能/可用性/安全性，影响需求方案的被接受程度，如果不能满足需求可能导致整体解决方案失去价值
例：
1. 比如12315功能性满足，但性能不满足
2. 登录后的页面数据加载量大，导致用户登录后系统加载慢，用户体验差，导致客户体验差。原因是服务器在外国，国内显示慢。后来在需求方案中加了性能要求即非功能性需求。
Requirements & Design(what & how)
需求是解决方案的团队的输入，解决团队也会做输出（比如测试用例）给BA确认。
六大领域：
Needs: 重点问题或机会
Change：针对某个问题或可开发机会，在组织层面应对，所以需求改变
Contexts: 组织内外部结构/人员影响因素的总和
Solutions: 考虑到内外部因素的解决问题的方案
Stakeholders: 干系人
Value：问题解决产生的价值，解决方案是否能产生足够的价值（需要考虑各个因素和组织架构）
Business Analysis Information
the broad and diverse sets of information that business analysts analyze, transform, and report;
It is information of any kind—at any level of detail—that is used as an input to, or is an output of, business analysis work.
商业分析信息：最重要的概念是requirement 需求收集/需求分析/需求管理。
需求收集过程中访谈过程中产生的访谈记录，干系人表达的需求/限制条件/顾虑/解决方案，分析后产生需求。
Design 实现需求/解决方案的设计（偏业务领域的设计+UI）
how：解决方案
what：需求
实际工作中 design和requirement很难分割开
Requirement
能被团队其他成员使用的反馈需求的展现形式（文档/图表）
Organization组织
管理层设计目标
Enterprise 目标达成的多组织构成的整体
组织和组织以外的环境因素
Plan
需求分析的工作内容/工作量/时间/资源/approach 的规划
Risk
将来有可能发生的事件，带有不确定性，如果发生会有负面/正面影响
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) is the
globally recognized standard for the practice of business analysis.
全球范围内认证的BA知识体系
The BABOK® Guide describes business analysis knowledge areas, tasks, underlying competencies, techniques and perspectives on how to approach business analysis.
A business analyst is any person who performs business analysis tasks described in the BABOK® Guide, no matter their job title or organizational role.
任何完成需求分析工作的人员都是BA（项目经理/咨询顾问/需求架构人员）
需求分析的工作：从各个途径收集信息，对信息做梳理归纳，最后形成完整的，能被其他人所用的输出。
Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders.
Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.
需求分析人应该最了解干系人的需要，评估解决团队的方案。
从事需求分析的人员分成了三大类：
Generalist 多行业的通才
Specialist 特定行业专家
Hybrid 混合类型BA（项目经理角色+BA）
公司中BA角色的z
系统介绍课程
需要记忆每个领域包含的任务名称，及输入输出
领域的相关方/技巧等重在理解
需求分析的旧版定义：一组任务和技术如何应用到工作中的组织架构/流程/运作方式等分析，在分析中发现问题，提供解决方案解决问题，为组织带来价值 。
需求分析的新版定义：Business analysis is the practice of enabling change in an enterprise（包含公司外的上下有） by defining needs and recommending solutions that deliver value to stakeholders.
needs：工作中需要解决的问题，或机会。通常不清晰，需要和干系人调研。调研干系人，干系人可能说的是解决方案，或有误解。需求分析需要定义问题，需要用ppt等方式呈现问题。
requirements：是收集问题后的分析结果
stakeholders：工作中的相关方/人(包含解决方案的施加方)
BA这个工作是做什么的：是客户和解决团队之间沟通的桥梁。为解决方案的设计和实施提供输入，也就是requirements。
Business analysis may be performed within the boundaries of a project or throughout enterprise evolution and continuous improvement.
BABOK领域内定位BA是在项目中或在公司中（业务顾问）
PMI领域内定位BA是在项目中的角色
It can be used to understand the current state, to define the future state, and to determine the activities required to move from the current to the future state.
分析现有流程或未来希望达成的流程
课程分成12个单元，基本参考BABOK书籍
第一单元对应第一章
介绍背景/结构/重要概念
第二单元对应第二章
介绍重要概念：需求/干系人
第三到第八章
需求分析的六大领域，每个领域有任务，任务的输入输出是什么
第九章
基本能力：沟通/协调
第十章
六大领域工作中需要的方式方法：interview
考试实际占了比重
第十一章 视角
在特别行业的应用：IT 敏捷 业务流程管理 商业智能 商业架构
第十二单元
不是BABOK书内容，是考试指导
Agile-iteration-just enough, just in time
Prective-requirement are define at a rather early stage-deliverables at the final stage
Interfaces-departmental
Roles and permission matrix
use case
Crud: create read update delete
Variance-root cause analysis
Data mining
Define, validate
focus group: qualitative measures
current
Acceptance (one solution, pass/fail) and evaluation (multiple solutions, assign different weights, ranking) criteria
The previous chapters about requirements: elicitation, analysis.
In use-existing, in varying stages of development: proto, beta, operational release
Opportunity cost--by opting A you can't enjoy the benefits from choosing B and C
constraints on solutions: time, budget
Dependencies on other initiatives-about consideration
Sponsor: usually important decision maker
prioritisation: Must Could Should What
Identify improvement opportunities
better access to information
identify additional capabilities
Requirement allocation-solution components / release
Determing solution approach-understanding of requirements , solution architecture
Design options: personnel, section, operational structures, policy, rules, relationships, aapplications
Mind mapping
RFI-information, RFQ-quotation, RFT-Tender, RFP-Prposal
Can adopt various formality based on differing needs of the stkhldrs
audit and security-non functional requirements
more than one viewpoints, interrelated with each other-tracing requirements
User stories or use case--functional requirements
Elicitstion results-business analysis
Assumption
Alignment with solution scope
Tracing requirements-new requirements, change requirements
Review
Walkthrough-predictive-group
single issue review
ad hoc-temporary
Atomic
Verify-quality check
