IIBA(International Institute of Business Analysis)

I. IIBA(International Institute of Business Analysis)의 개요

  가. IIBA(International Institute of Business Analysis)의 정의

   -비즈니스분석 (Business Analysis)을 지원하기 위한 목적으로 2003년 10월에 설립된 비영리 전문가 협회

 

II.BABOK (Business Analysis Body of Knowledge)의 개요

  가.BABOK (Business Analysis Body of Knowledge)의 정의 

   -BABOK 가이드는 BA 분야의 지식체계를 집대성한 이론서로서 지속적으로 업그레이드가 되고 있으며 현재는 Version 2 이며,

    271페이지 분량의 PDF 파일로 작성되어 있습니다.

   - BA 지식 체계는 6대 지식 영역(Knowledge Area), 분석 기법들로 구성되어 있습니다. 

III.BABOK의 6대 지식 영역

  가. 6대 지식 영역

  

항목	분석내용
Business Analysis Planning & Monitoring	-비즈니스 분석을 위해서 필요한 활동들을 정의하는 영역 -이해관계자 확인, 비즈니스 분석 기법 선택, 요구사항 관리 프로세스, 진척 상태 평가 등을 포함
Elicitation	-이해관계자들과 함께 그들의 needs와 우려를 이해하고 비즈니스 환경을 이해하는 영역 -이해관계자가 언급하거나 피상적인 희망 보다는 실제 근본 needs를 파악하는 것이 목적.
Requirements Management & Communication	-이해관계자들과 프로젝트 팀이 솔루션 범위에 대한 지속적인 합의를 위한 갈등, 이해 및 변화를 관리하고, 이해관계자들과 요구사항을 커뮤니케이션하며, 비즈니스 분석을 통해서 파악한 지식을 관리하는 방법을 기술하고 있음
Enterprise Analysis	-프로젝트 팀이 조직과 이해관계자들의 needs를 해결하는 솔루션을 구현할 수 있도록 이해관계자 요구사항을 우선 순위화하고 점진적으로 정교화하는 영역 - 필요 솔루션을 정의하기 위해서 이해관계자 needs를 분석하고, 개선방안을 도출하기 위해서 현행 비즈니스 상태를 평가하며, 최종 요구사항에 대한 확인 및 검증을 하는 것을 포함
Requirements Analysis	-프로젝트 팀이 조직과 이해관계자들의 needs를 해결하는 솔루션을 구현할 수 있도록 이해관계자 요구사항을 우선 순위화하고 점진적으로 정교화하는 영역 - 필요 솔루션을 정의하기 위해서 이해관계자 needs를 분석하고, 개선방안을 도출하기 위해서 현행 비즈니스 상태를 평가하며, 최종 요구사항에 대한 확인 및 검증을 하는 것을 포함
Solution Assessment & Validation	-비즈니스 needs에 가장 적합한 제안 솔루션을 평가하고, 솔루션의 갭과 단점을 확인하며, 갭에 따른 솔루션 수정개발이나 다른 해결책을 결정 -솔루션의 성능과 효과를 평가할 수 있도록 배포된 솔루션이 당초의 needs를 제대로 만족시키는지 평가하는 방법을 포함.

 

IV.BABOK의 분석기법

1) RACI Matrix (Conduct Stakeholder Analysis) 개요
- 프로젝트 팀의 R&R을 정의할 때 사용하는 기법으로서 프로젝트 태스크별로 각 멤버/그룹의 역할을

 Responsible, Accountable, Consult With, Inform으로 구분함
- 다음은 RACI Matrix의 간단한 예제를 보여준다.

2) Stakeholder Map (Conduct Stakeholder Analysis) 개요
- 이해당사자와 솔루션의 관계를 묘사하는 다이어그램으로서 Stakeholder Matrix

(이해 당사자에 미치는 영향 Impact, 이해당사자의 영향력 Influence을 X, Y 축으로 해서 4분면으로 표시)와

Stakeholder Onion Diagram (프로젝트에 직접 참여하는 멤버부터 양파의 안쪽에 위치시키고 참여도가

낮은 고객 등을 바깥쪽에 위치시키는 다이어그램)이 있음

3) Variance Analysis (Manage Business Analysis Performance) 개요
- 계획 (Planned)과 실제 결과 (Actual Results)를 비교하는 것임

4) Baselining (Manage Solution Scope & Requirements) 개요
- 승인된 요구사항들을 Baseline으로 해서 향후의 변경 요구사항은 모두 Change Control 절차를 통해서

기록/추적하기 위해서 사용됨

5) Signoff (Manage Solution Scope & Requirements) 개요
- 이해당사자들이 공식적으로 요구사항들을 승인하는 것을 의미함

6) Coverage Matrix = Traceability Matrix (Maintain Requirements for Re-Use) 개요
- 요구사항을 추적하는데 사용되며, 테이블이나 스프레드시트 형태이므로 요구사항 갯수가 상대적으로 적을 때 사용.

7) Requirements Documentation (Requirements Management & Communication) 개요
- 일반적으로 자주 사용하는 요구사항 문서화 방법에는 Business Requirements Document (BRD),

Product Roadmap, Software/System Requirements Specification,

 Suppliementary Requirements Specification, Vision Document 등이 있음

8) Requirements for Vendor Selection (Requirements Management & Communication) 개요
- 우리가 잘 아는 RFP, RFQ, RFP 등을 의미함

9) Feasibility Analysis, Feasibility Study (Determine Solution Approach) 개요
- 규모가 작은 프로젝트에는Feasibility Analysis가 사용되고, 규모가 큰 프로젝트에는 Feasibility Study가 사용

10) Problem or Vision Statement (Define Business Case) 개요
- 비즈니스 needs, 주요 이해당사자, 이해당사자에 대한 비즈니스 영향도, 효익 등을 간략히 기술한 것임

11) MoSCow Analysis (Prioritize Requirements) 개요
- 요구사항의 우선순위를 메길 때, Must Have (무조건 해야), Should Have (우선순위 높음),

Could Have (우선순위 낮음), Would Not Have또는 Won't Have (안하기로) 등으로 분류함

12) Timeboxing/Budgeting (Prioritize Requirements) 개요
- 주어진 시간, 자원, 예산에 맞추어 요구사항들을 Filtering하는 기법으로서 All In (요구사항을 모두 포함시킨 후

예산에 맞출 때까지 하나씩 제외하는 방식), All Out (Zero에서 요구사항을 하나씩 추가하는 방식),

Selective (Hybrid 방식) 등으로 나눌 수 있음

13) Voting (Prioritize Requirements) 개요
- 정해진 자원 (투표, 자금, 토큰 등)을 각 참가자에게 할당해서 요구사항들에게 배분하는 기법임

14) Checklists (Validate Requirements) 개요
- 요구사항 산출물에 대한 Quality Control 기법으로서 품질 요소의 표준 세트를 포함함

15) Force Field Analysis (Assess Organizational Readiness) 개요
- 제안된 솔루션에 대한 긍정적인 포스 (변화를 지원)와 부정적인 포스 (변화에 반대)를 그래픽으로 묘사