六大知识领域：

1. 战略分析：定义问题/设定目标和范围。

2. 需求分析和设计定义：前置步骤1，解决方案的输入。

3. 解决方案评估：前置步骤2，前提条件是已有解决方案。在评估过程中可能会发现问题，需要讨论问题，解决问题。流程回到步骤1战略分析，重复步骤1到3。

4.发掘和协作：持续进行的工作。发掘需求，和干系人沟通收集信息，步骤1到3都涉及到发掘和协作。

5.需求生命周期管理：持续进行的工作。需求批准/需求变更管理，需求优先级划分，需求重用

6.需求规划和监督：持续进行的工作。对实际效果进行监控，用经验教训分析偏差。

Knowledge area tasks

1.任务的定义：一个相对独立的工作，有一个输出

2.按一定顺序/同步的执行任务

3.BABOK没有规定任务执行顺序，BABOK不是方法论，是一个工具箱

4.需求分析可以是对现状做分析(战略分析领域)/衡量解决方案的效果（解决方案评估）

需求分类

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

系统介绍课程

需要记忆每个领域包含的任务名称，及输入输出

领域的相关方/技巧等重在理解

需求分析的旧版定义：一组任务和技术如何应用到工作中的组织架构/流程/运作方式等分析，在分析中发现问题，提供解决方案解决问题，为组织带来价值 。

课程分成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