Business Analysis Body of Knowledge (BABOK v1.6)	Cat: ICT Pub: 2006 #:0903b
	International Institute of Business Analysis	09224u/18121r

Title	Business Analysis Body of Knowledge	ビジネスアナリシス知識体系
Index	Preface and Introduction: Enterprise Analysis: Requirements Planning and Management: Requirements Elicitation: Requirements Analysis and Documentation: Requirements Communication: Solution Assessment and Validation: Underlyning Fundamentals: Glossary:	序文: 企業分析: 要求計画と管理: 要求の引き出し: 要求分析と文書化: 要求コミュニケーション: ソリューション評価と検証: 基本能力: 用語集:
Why?	IT Coordinator's Process Guideline (PGL) of Japan and The Business Analysis Body of Knowledge (BABOK) of Canada overlaps in most parts each other. Here is essence of the concept which overlaps between the two guideline. The biggest difference is language; PGL is originally written in Japanese, while BABOK is in English. It is interesting and meaningful to refer and compare the difference of expression between different languages. Also, the work of translation of PGL into English is still under process. So the study of BABOK would be useful in making smart translation of PGL. IIBA-Japan was established on Dec 23, 2008, where not a few IT Coordinators attended. Japanese IT Coordinators virtully function also as BA's in Japan, utilizing their own unique process guideline (PGL).	日本のITコーディネータのプロセスガイドライン (PGL) とカナダのビジネスアナリシス知識体系 (BABOK)には相互に重複する部分が多い。 これら２つのガイドライン間の重複する概念のエッセンスをまとめる。最大の違いは言語である。原本は、PGLは日本語で書かれ、BABOKは英語で書かれた。 異なる言語間での表現の違いを参照比較するのは興味深く、また意義ある。 また、PGLの英語への翻訳作業も進行している。BABOKの研究はPGLのうまい翻訳作成に役立つと思われる。 IIBA-Japanが2008年12月23日に設立され、かなりのITコーディネータが参加した。日本のITコーディネータは実質的に、PGLを活用して日本でBAとしても機能している。

Resume	要約
>Top-1: Seven Knowledge Area of BABOK: (originally by Masakazu Kobayashi, ITC) The number corresponds to the relevant chapter in BABOK Ver.1.6:     3. Business Analysis Planning and Management   2. Enterprise Analysis 4. Requirements Elicitation 5. Requirements Analysis & Documentation 7. Solution Assessment & Validation 6. Requirements Communication 8. Underlying Fundamentals
>Top0. Comparison with PMBOK:   Business Analysis Project Management   Architectonics Business Analysis Body Of Knowledge (BABOK) Ver1.6 -> 2.0 Project Management Body Of Knowledge (PMBOK) Ver4.0 知識体系 Promotion body International Institute of Business Analysis (IIBA) Project Management Institute (PMI) 推進機関 Foundation 2003, Toronto, Canada 1969, Pennsylvania, USA 設立時期 # of members 5,000 265,000 会員数 Japanese org. IIBA-Japan, Dec, 2008 PMI-Japan, 1998 日本支部 Qualification Certified Business Analysis Professional (CBAP) Project Management Professional (PMP) 資格 # of qualified people 450 270,000 資格者数
>Top 1. Preface and Introduction: 1.1: What is the BABOK? : the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. reflects currently accepted practice Additions will be made bi-annually. 1.2: Purpose of the guide to IIBA BOK: central overview of each knowledge area and the list of activities and tasks developing examination questions for the exam certified by IIBA IIBA is following ISO/IEC 17024; General Requirements for Bodies Operation Certification of Persons 1.3: Defining BA Profession: BA is the set of tasks, knowledge, and techniques required to identify business needs and determining solutions to business problems BA is district from financial analysis, project management, quality assurance, organizational development, testing, training and documentation development. But BA may perform some or all of these related functions. 1.4: Core concepts of BA: 1.4.1: Definition of BA role: 1.4.2: Definition of requirement: a condition or capability needed by a stakeholder to solve a problem a condition that must be met or possessed by a system to satisfy a contract, specification a documented representation of a condition 1.4.3: Definition of requirements types: Business requirements User requirements Functional Requirements of the system environmental conditions under which the solution must remain effective assumptions and constraints that will limit or impact the solution implementation requirements that facilitate transition from the current state to the desired future state 1.4.4: Effective requirements practices: clear understanding to the needs of users collaboration relationship between the user, stakeholders and the technical team strong commitment of the requirements development team members repeatable requirements process that is continuously improved system architecture that supports the user and stakeholders	1. 序文: 1.1: BABOKとは? ビジネス分析の専門知識の体系 現行の実践を反映 半年ごとに追加 1.2: 目的とは: 各知識分野、活動リストの概括 IIBA試験の開発 ISO/IEC 17024準拠 1.3: BA職業の定義: ビジネス上のニーズや課題解決を特定するために必要な知識技術体系 BAは、FA, PM, QA,組織開発などと異なるがこれらと関連した機能を行う 1.4: BAの中心概念: 1.4.1: BAの役割定義: 1.4.2: 要求の定義: シェアホルダの問題解決に必要な条件・能力 契約、標準、仕様を満足するためにシステムが解決すべき条件・能力 条件を表示する文書 1.4.3: 要求のタイプ: ビジネス要求 : ユーザ要求: システム機能要求: 環境条件: 前提と制約条件: 構築要求: 1.4.4: 効果的な要求実践: ユーザ・ニーズの明確な理解 ユーザ、ステークホルダ、技術チームとの協働 要求開発チーム内の責任 要求プロセスの継続改善 ユーザとステイクホルダを支援するシステムアーキテクチャ
>Top 1.5: The body of knowledge in summary: 1.5.1: Enterprise Analysis: creating Business Architecture identifying new business opportunities scoping and defining the new business opportunity preparing the business case conducting the initial Risk Assessment preparing the Decision Package 1.5.2: Requirements Planning & Management: the sets of requirements activities undertaken are the most appropriate the requirements is coordinated with other work being done the whole requirements team has a common understanding BA is able to monitor and react to requirements challenge the tools, resources are available as needed changes are capture correctly 1.5.3: Requirements Elicitation: a key task in BA the requirements be complete, clear, correct, & consistent 1.5.4: Requirements Analysis & Documentation: ensure a consensus between all the stakeholders refine the models based upon stakeholder feedback 1.5.5: Requirements Communication: include presenting, communicating, verifying & gaining approval of the requirements must be able to clearly present the requirements in a format & structure 1.5.6: Solution Assessment & Validation: ensure that the solution meets the stakeholder objectives, is thoroughly tested, and is implemented smoothly assist the technology team with detailed design work including splitting a large project into phases, reviewing technical design deliverables 1.6: The body of knowledge in context : BABOK is not a methodology. Theoretically, one gathers requirements then analyzes and documents them, then uses them as input into the designs that lead to the final implementation of the gathered and documented requirements and the testing that validates the solution against the requirements.	1.5: 知識体系概括: 1.5.1: 企業分析: ビジネス・アーキテクチャ作成 新規ビジネス機会特定 新規ビジネス機会の範囲と定義 ビジネスケースの準備 初期リスク評価の実施 意志決定準備 1.5.2: 要求計画とマネジメント 要求計画とマネジメント 最適な要求活動 他作業との連携要求 要求チーム内の共通理解 BAがモニター可能 ツール、資源が入手可能 変更対応 1.5.3: 要求引き出し BAのキーの役割 要求は完全、明確、かつ一貫性 1.5.4: 要求分析と文書化 全ステークホルダ間での合意 ステークホルダのフィードバックによるモデル改善 1.5.5: 要求コミュニケーション 要求のプレゼン、コミュニケーション、検証、承認 要求は明確な形式と構造で提示 1.5.6: 解決評価と検証 解決がステークホルダの目的を満たすか完全な検証を実施 技術チームによる詳細設計作業の支援、フェーズ分割、技術設計書のレビュー 1.6: BABOK関係図 (左図) BABOKは方法論にあらず 要求を集め、分析・文書化し、設計・構築をインプットとする。次に要求に対する検証を実施

>Top 2. Enterprise Analysis:　 2.1: Introduction: 2.1.1: Definition: 1) identify business opportunities 2) build their business architecture framework 3) determine the optimum project investment path for the enterprise 2.1.2: Overview: Projects play an essential role in the growth and survival of organizations 2.1.3: Strategic Planning: (Cf: below chart) various business circumstances & needs are considered identifying ongoing business issues assessing the current technology competitive, profitable & efficient 2.1.4: Strategic Goal Setting: The balanced scorecard: 1) reduce costs through online customer ordering 2) increase the number of high-value customers through acquisitions 3) increase revenue per customers by increase the services 2.1.5: The BA Strategic Role: often conduct competitive analysis and benchmark studies 2.1.6: The BA Enterprise Analysis Role: the focus is at the enterprise level where considerations about a proposed initiative are made across the organization understand inter-project dependencies and system interfaces determine the risks and exposures to the business 2.1.7: Enterprise Analysis Activities: creating & maintaining the business architecture: output is Business Architecture Framework Business Architecture Artifacts Alignment of Problem/Opportunity to the Business Gap Analysis Results conducting feasibility study: (output) Business Feasibility Study Strategic Alignment Technical Alignment Alternative Solution Ranking & Recommendation determining project scope: (output) Strategic Fit Business Objectives & High Level Requirements Root Cause Analysis Rationale for Option Selected Product Description & Scope Assumptions & Constraints Initial Project Approach & Resourcing Major Project Milestones & Funding Requirements preparing the decision package: (output) Collated Package of Enterprise Activity Product Enhanced Business Case Report Recommendations Executive/Sponsor Briefing Material project sizing grid Large: significant, high-risk project: 12-24 months Medium: low-moderate risk project: 6-12 months Small: small, low risk project: <6 months 2.1.8: Relationship to Other Knowledge Areas: Requirements Planning & Management Knowledge Area Requirements Gathering Knowledge Area Requirements Communication Knowledge Area	2. 企業分析: 2.1: 序 2.1.1:定義: 1) ビジネス機会特定 2) ビジネス・アーキテクチャ・フレーム構築 3) 最適プロジェクト投資方向の確定 2.1.2:概論: (下図) プロジェクトは組織の成長と存続にとって必須 2.1.3: 戦略計画: ビジネス環境・需要検討 継続ビジネスの課題 現行技術の評価 競争力、収益性、効率 2.1.4: 戦略目標策定: BSC: 1) オンライン顧客によりコスト削減 2) 高価値顧客数の増加 3) サービス増加による顧客単価増大 2.1.5: BA戦略的役割: 競争力分析、ベンチマーク研究 2.1.6: BA企業分析役割: 全社レベルでの指導 プロジェクト間の独立性やシステムインターフェースの理解 ビジネスに係るリスク 2.1.7: 企業分析活動: ビジネス・アーキテクチャの作成・維持：成果物 ビジネス・アーキテクチャ・フレームワーク ビジネス・アーキテクチャ成果 ビジネス課題・機会リスト ギャップ分析結果 フィージビリティ・スタディ実施：成果物 ビジネスFS 戦略課題リスト 技術課題リスト 優先度順代替策 プロジェクト範囲の決定：成果物 戦略適合度 ビジネス目的・高レベル要求 原因分析 オプション選択理由 製品記述・範囲 前提・制約条件 当初プロジェクト投入資源 主要プロジェクト予定・予算 意志決定の準備：成果物 企業活動成果の照合 詳細事例報告 提言 幹部・スポンサーへの報告書 プロジェクト規模分類: 大プロジェクト： 期間 12-24ヶ月 中プロジェクト 期間6-12ヶ月 小プロジェクト 期間６ヶ月未満 2.1.8:他知識分野との関係: 要求計画＆マネジメント知識領域 要求収集地域領域 要求コミュニケーション地域領域
>Top 2.2: Creating & Maintaining Business Architecture: 2.2.1: Purpose: As we change the business, we ensure that business operations and their supporting IT systems are aligned: The Enterprise Architecture consists of five architectures: 1) Business Architecture 2) Information Architecture 3) Application Architecture 4) Technology Architecture 5) Security Architecture 2.2.3: knowledge: General business practices Industry domains IT-enabled business solutions Current & emerging business concepts, strategies and practices How various lines of business within the organization interact Standard architectural principles and semantics Standard business concepts and guidance as to how to use them 2.2.4: Skills Business strategy Business process engineering Business analysis Business modeling Business concepts, rules 2.2.6: Process & Elements: Determine the scope of the effort Plan the activities Create or update the documents and drawings Conduct a quality review of the Business Architeture components 2.2.7: Stakeholders Executive & middle management Individual contributors Project & operational teams Shareholders Customers & end users Government & regulatory bodies 2.2.8: Deliverables: Strategi plans, goals Organization structures Business unit goals & objectives Business fucntions Business product lines Business services proided to customers Business process, including peformance measures Busienss rules Gap analysis results 2.2.9: Techniques: POLDAT framework:: This is often used in business process re-engineering projects. Process: the business processes that flow value from the organization to the customer. Organization: the organizational entities that operate the business processes Location: the location of the business units; eg, call centers, distribution centers, etc. Data: the data & information that is the currency of the organization, flowing through the processes to accomplish the business functions. Application: IT applications that enable the business processes to operate efficiently. Technology: the enabling technology that supports the operation of the processes & application. Business architecture modeling: CoBz CLUB-K Component business model: identifies a basic building block, and includes people, processes and technology. Business process model: describes the process associated with business activities and information exchanged between activities. Class models: describes static information and relationships between information; various levels of granularity. Use case models: Business scenarios: Knowledge management:	2.2: ビジネス・アーキテクチャ作成・維持 2.2.1: 目的 ビジネス・アーキテクチャは以下５アーキテクチャから成る 1) ビジネス・アーキテクチャ 2) 情報アーキテクチャ 3) アプリケーション・アーキテクチャ 4) 技術アーキテクチャ 5) セキュリティ・アーキテクチャ 2.2.3: 知識: 一般的ビジネス実施 産業ドメイン IT活用ビジネス・ソリューション 現状＆新興ビジネス・コンセプト・戦略・実践 組織内各ビジネス分野の製品 標準アーキテクチャ原則と意味 標準ビジネス概念・ガイダンス 2.2.4: スキル: ビジネス戦略 ビジネス・プロセス・エンジニアリング ビジネス分析 ビジネスモデリング ビジネス・コンセプト・ルール 2.2.6: プロセス＆要素: 努力範囲の決定 活動計画 文書・図面作成と更新 ビジネス・アーキテクチャ要素の品質審査実施 2.2.7: ステークホルダ: トップ・中間管理職 個別貢献者 プロジェクト・運用チーム 株主 顧客＆エンドユーザ 政府＆規制当局 2.2.8: 成果物: (左図：S-OBBB-BBBG) 戦略目標 組織構造 事業部目標 事業機能 事業生産ライン 顧客へのビジネスサービス ビジネスプロセス ビジネスルール ギャップ分析 2.2.9: 技術: POLDATフレームワーク: BPRで利用 プロセス 組織 場所 データ アプリケーション (IT) 関連技術 ビジネスアーキテクチャ・モデリング 構成ビジネスモデル ビジネスプロセスモデル クラスモデル ユースケースモデル ビジネスシナリオ ナレッジマネジメント
>Top 2.3: Conducting Feasibility Studies: 2.3.3: Knowledge: Financial analysis Industry and organizational strategic goals A broad understanding of IT 2.3.4: Skills Research & information analysis skills Ability to plan and document results Technical writing skills Leadership & organizational skills Change management skills Communication skills Ability to work independently or in a team environment 2.3.8: Deliverables: FS Report Executive summary Business problem and/or opportunity statement Feasibility study requirements, including business drivers of the initiative. For each option that was assessed: solution option assessment process & methods overall results; document expected vs. actual results identified risks associated with the alternative identified issues which adversely impact the success of the solution Assumptions to close gap Alternative solution ranking 2.3.9: Techniques: Techniques to conduct current state-assessment: Organization chart Geographical maps Data flow diagram Technology architecture diagram Process flow diagram Domain modeling Six sigma Root cause analysis Techniques to plan FS: Project management Brainstorming Work Breakdown Structure (WBS)	2.3: フィージビリティスタディ実施 2.3.3: 知識: 財務分析 業界・組織戦略目標 ITへの広い理解 2.3.4: スキル: 研究・情報分析スキル 計画立案、文書化スキル 技術的記述スキル 組織リーダーシップスキル コミュニケーションスキル 単独またはチームでの作業能力 2.3.8: 成果物: FSレポート 要約 業務課題、機会記述 FS要求 各オプションへの評価 2.3.9: 技術: 現状評価の技術: 組織図 地理図 データフローダイアグラム 技術アーキテク プロセスフローダイアグラム ドメインモデリング シックスシグマ 根本原因分析 FS計画の技術: プロジェクト管理 ブレインストーミング WBS
>Top 2.4: Determining Project Scope: 2.4.1: Purpose: a project manager has not yet been assigned. BA enlists the assistance of an experienced project manager 2.4.3: Knowledge: a basic understanding of PMBOK Project life cycles Project management process groups Project scope management Projects, subprojects, programs and portfolios Impacted application area standards and regulations Functional department Supporting disciplines: legal, production, inventory management, marketing , logistics, human resources. Knowledge about the technology elements Government contracting, new product development 2.4.4: Skills: Planning, estimating & scheduling Scope definition Interpersonal skills Documentation & diagramming approaches Communication skills	2.4: プロジェクトスコープの決定: 2.4.1: 目的: PMはまだ未決定 BAは経験のあるPMを支援 2.4.3: 知識：PMBOKの基本理解 プロジェクトライフサイクル プロジェクト・マネジメント・プロセス・グループ プロジェクト・スコープ・マネジメント プロジェクト、サブプロジェクト等 関連法規規制 関連部署 支援原則：法務、生産、在庫、マーケティング、物流、人事 技術要素に関する知識 行政対応、新規商品開発 2.4.4: スキル: 計画、見積、スケジュール 範囲定義 対人スキル 文書化、図示化 コミュニケーション・スキル
>Top 2.5: Preparing the Business Case: 2.5.2: Description: describe the justification in terms of the value to be added vs. the cost to develop the new solution 2.5.3: Knowledge: An understanding of accounting practices translate the proposed change into financial terms 2.5.6: Process & Elements: identify and quantify the benefits identify and quantify the cost prepare the business case determine the measurement process for the costs and benefits 2.6: Conducting the Initial Risk Assessment: 2.6.3: Knowledge: Risk management principles and concepts Financial analysis and profit projection models Business enterprise structure, operations , skill sets Organizational readiness for the change initiative Technical feasibility of the proposed solution 2.6.6: Process & Elements: identifying project risks assessing risk probability and impact planning risk responses assessing organizational readiness and calculating an overall risk rating 2.7: Preparing the Decision Package: 2.7.3: Knowledge: Portfolio management Project section and prioritization 2.7.4: Skills: written communication skills executive briefing preparation skills 2.8: Selecting and Prioritizing Projects 2.9: Launching New Projects 2.10: Managing Projects for Value 2.11: Tracking Projects Benefits	2.5: ビジネス・ケースの準備 2.5.2: 解説: プロジェクトの費用対効果を検証 2.5.3: 知識: 会計処理の理解 変更に伴う予算知識 2.5.6: プロセス＆要素: 便益の数値化 コストの数値化 ビジネス・ケースの準備 費用対効果の測定 2.6: 初期リスク評価 2.6.3: 知識: リスク管理原則 財務分析 ビジネス構造、スキルセット 変化への組織対応 技術的可能性 2.6.6: プロセス＆要素: プロジェクトリスク特定 リスク蓋然性＆インパクト評価 リスク対応計画 組織対応氷塊および全般的なリスク段階計算 2.7: 意志決定パッケージ: 2.7.3: 知識 ポートフォリオ管理 プロジェクト部門、優先度 2.7.4: スキル 文書コミュニケーションスキル 幹部用簡潔プレゼンスキル 2.8: プロジェクト選定と優先度 2.9: 新規プロジェクト立ち上げ 2.10: プロジェクト管理 2.11: プロジェクト利便性追跡
>Top 2.1.2: Enterprise analysis activities linked to business planning events. Activity Owner Deliverables オーナー Strategic plan development Executive Team Strategic plan document 担当役員 Strategic goal development Executive Team Strategic goals, themes & measures 担当役員 Business architecture development Business Analyst Business architecture ビジネス･アナリスト Feasibility studies Business Analyst Feasibility study report ビジネス･アナリスト Business case development Business Analyst Business case document ビジネス･アナリスト New project proposal Business Sponsor Executive presentation decision package ビジネス・スポンサー Selecting & prioritizing new business Enterprise Governance Group Project selection, Project priority, Project charter 全社ガバナンスグループ Launching new projects Project Manager Project plans プロジェクト・マネジャ Managing projects for value Busienss Analyst Updated business case at key control gates ビジネス･アナリスト Tracking project benefits Business Sponsor BSC reports ビジネス・スポンサー

>Top 3. Requirements Planning and Management: 3.2: Understand Team Roles for the Project: 3.2.1: TASK: Identify & Document Team Roles for the Project: <Typical team roles>: Executive sponsor: has overall responsibility for the project at the management level including funding, go/no go decision making and providing resource support; project champion Business analyst: elicits, analyses, documents and reviews the requirements Project manger: manages the day-to-day activities of the project ensuring related tasks delivered on time, within budget, and within scope. Developer: includes many technical roles within a project team. Quality assurance analyst: is responsible for ensuring that quality standards are adhered to. Trainer: is responsible for developing user training curriculum and delivering training to end-users. Application architect: is responsible for determining the technical direction of the project and the overall structure of the solution. Data modeler: Database analyst (DBA): is responsible for all technical aspects related to designing, creating and maintaining project databases. Infrastructure analyst: designs the overall hardware and software infrastructure and environment. Information architect: identifies reusable data assets and resolve enterprise data modeling issues. Solution owner: is responsible for defining and approving the project scope and ensuring that it aligns with the business strategy. End user: actually interacts directly with he software application. Subject Matter expert (SME): is closely tied to defining, approving and using the functional requirements for the project. Stakeholders: are often a prime source of information when planning and managing requirements. 3.2.2: TASK: Identify & Document Team Role Responsibilities: RACI Matrix: RACI matrix is a powerful tool useful to illustrate usual responsibilities of the roles involved in planning and managing requirements. Responsible does the work Accountable is the decision maker (only one) Consulted must be consulted prior to the work and gives input Informed is on a need to know basis after the work is done	3. 要求計画と管理: 3.2: プロジェクトチームの役割理解: 3.2.1: タスク：プロジェクトチームの役割の特定と文書化: <典型的なチームの役割>: エクゼクティブ・スポンサー ビジネス・アナリスト プロジェクト・マネジャ デベロッパー QAアナリスト トレーナー アプリケーション・アーキテクト データ・モデラー データベース・アナリスト インフラ・アナリスト インフォメーション・アーキテクト ソリューション・オーナー エンドユーザ サブジェクト・マター・エキスパート ステークホルダ 3.2.2: タスク：チームの役割と責任の特定と文書化 RACIマトリックス：<左表> R: 実施責任 A: 意志決定者としての説明責任 C: 事前相談 I: 事後報告 これは要求計画・要求管理での役割と責任を明確にする上で役立つ Role RACI 責任 Executive sponsor C 事前相談 Business analyst R 実施責任 Project manager A 意志決定者として説明責任 Developer C 事前相談 Quality assurance analyst I 事後報告 Trainer I 事後報告 Application architect C 事前相談 Data modeler C 事前相談 Database analyst (DBA( C 事前相談 Infrastructure analyst C 事前相談 Business architect R 実施責任 Information architect C 事前相談 Solution owner C 事前相談 End user I 事後報告 Subject matter expert (SME) C 事前相談 Other stakeholders R, C, I
>Top 3.3: Define Business Analyst Work Division Strategy: 3.3.4: Technique: Knowledge transfer: Knowledge transfer is a systematic approach to capture, collect and share tacit knowledge in order for it to become explicit knowledge Tacit knowledge is the know-how and explicit knowledge is the knowledge that has been articulated and captured in the form of text, diagrams, product specifications, etc. Information exchange Verbal or Non verbal (electronic, document, fax) Structured walk-through/peer reviews Status meeting Debriefing meeting: to report, verbal or non verbal, after the activity is completed. Central repository Mentorship: pair senior and junior business analyst for back-up 3.4: Define Requirements Risk Approach: 3.4.3: Risk Planning: To provide a well-thought out and methodically planned risk response strategy to be used in monitoring and controlling of all identified risks. Processes: the following is determined for each risk. Likelihood: use a scale such as 1 is low, 5 is high. Impact: as forecast - the impact to the requirements process if the risk materializes and become an issue; cost impact, schedule impact, scope impact, quality impact, and benefits impact. Intervention difficulty: determine how difficult it will be to intervene to prevent the risk from occurring. Precision of assessment: will be based on past experience with the type of risk. Mitigation strategy: as initially defined - determine the best approach to detail with the risk. Avoid Mitigate Assume Action plan Contingency plan	3.3: BAの作業分割戦略定義: 3.3.4: 技術：知的移転: これは暗黙知を形式知として収集し共有するためのシステム的なアプローチである。 暗黙知はノウハウであるが、形式知は文章、図表、仕様書などに記述された知識である。 情報交換の方法としては 口頭か文書か 構造化され査読されたか 状況報告 系統的報告 中央管理 助言指導 3.4: 要求リスクへの取組定義 3.4.3: リスク計画 熟慮されたリスク対策 プロセス: 可能性 (1-5段階) インパクト 介入の困難度 評価の正確性 軽減策 行動計画 緊急対策 タスクの記述 Purpose 目的 Description 説明 Predecessors 前任者 Process & Element プロセスと要素 Stakeholders ステイク ホルダ Deliverables 成果物
>Top 3.5: Determine Planning Considerations: 3.5.2: Task: Consider the SDLC Methodology: System Development Life Cycle (SDLC) is defined as the overall process od designing and developing information systems; multi phase approached through the steps of analysis, design, construction, implementation and eventual maintenance. Waterfall: The traditional waterfall method advocates gathering all requirements in the beginning of the project. Iterative and Agile: Iterative/Agile approaches requirements many be defined throughout the lifecycle. 3.5.3: Task: Consider the Project Life Cycle Methodology: A Project Life-Cycle (PLC) is defined as all of the project phase/events needed to complete the project. A typical PLC may include followings: Definition: The project concept is defined, various alternatives evaluated, and the optimum alternative selected. Planning: The project is approved and the detailed project plan is created. Initiation: The project is kicked off with clear definition and defined agreed to objectives. Execution: The project is executed with the tasks and activities underway. Project deliverables listed in the project plan are crated. Close-Out: The final product is completed. Any close out activities are carried out and the project terminated. 3.5.7: Task: Consider the Project Type: Types of projects include the followings: New software development (in-house) Outsourced development Software maintenance Software package selection Process improvement Organizational change The difference in the requirements planning and management activities in these different types of projects will be very great. 3.6: Select Requirements Activities: 3.7: Estimate Requirements Activities: 3.8: Manage Requirements Scope: 3.9: Measure and Report on Requirements Activity: 3.9.1: Task: Reporting Project Metrics: Project status reports are most often used to report on the status of project metrics. Five primary criteria that are common: Time (Schedule) Cost (Budget) Resources (Who and how much) Features (Any feature creep occurring) Quality (Defects vs. plan) "Trend analysis"is often a key capability in metrics reporting and design the repoting capability accordingly. 3.10: Manage Requirements Change: 3.11: Refrences:	3.5: 計画決定に当たって考慮すべき事項: 3.5.2: タスク：SDLC方法論 システム開発ライフサイクル(SDLC) ウォーターフォール型 反復型 アジャイル型 3.5.3: タスク：PLC方法論 プロジェクトライフサイクル(PLC) 以下プロセスを含む 定義 計画 開始 実施 完成 3.5.7: タスク：プロジェクト型 ；以下がある。 新規ソフト開発 アウトソース開発 ソフト維持 ソフトパッケージ選択 プロセス改善 組織改革 上記の型によって要求計画・開発が大きく異なる 3.6: 要求活動選択 3.7: 要求活動予測 3.8: 要求範囲の管理 3.9: 要求活動の測定報告 3.9.1: プロジェクト報告書: ５つの基本項目 時間 (予定) コスト (予算) リソース (誰がどの位) 特記事項 品質 "動向分析"は報告ではしばしば重要 3.10: 要求変更管理 3.11: 参考文献
>Top 4. Requirements Elicitation: 4.2: Task: Elicit Requirements: 4.2.4: Skills: Eliciting and assessing information Interviewing Facilitating collaborative sessions Observation Resolving conflicts; eliminating root cause of conflicts; reaching consensus Thinking abstractly; finding and leveraging patterns Writing, business documentation Listening and oral communication 4.2.6: Process: Prepare for elicitation Eliciation technique: Commonly used requirements elicitation techniques. Brainstorming Document analysis = Review existing documentation Focus group Interface analysis = External interface analysis Interview Observation = Job shadowing Prototyping = Storyboarding, Navigation flow Requirements workshop = Elicitation workshop, facilitation workshop, Joint application design (JAD) Reverse engineering Survey = Questionnaire Conduct elicitation: Tracing requirements: BA must guard against "scope-creep." Tracing requirements back to the business goals helps to validate whether a requirement should be included. Capturing requirement attributes: BA will document the attributes which can be initially identified during requirements elicitation. Use of glossary: Creation and use of a business glossary is an essential asset for all requirements elicitation techniques. 4.2.7: Stakeholders: Business owner Business user Domain expert Project manager Project team	4. 要求の引き出し: 4.2: 要求を引き出す 4.2.4: スキル: 引き出しと情報の評価 インタビュー 共同会議をファシリテイト 観察 紛争解決；紛争原因の除去、合意形成 抽象化思考；解決パターンの発見・活用 ビジネス文書の作成 聞き取りと口頭でのコミュニケーション 4.2.6:プロセス： 要求引き出しの準備 要求引き出し技術: ブレーンストーミング 文書解析 フォーカス・グループ インターフェイス分析 インタビュー 観察 プロトタイピング 要求ワークショップ リバース・エンジニアリング 調査 要求引き出しの実施: 要求をトレースする: BAは、仕様変」を防ぐ。要求を経営目的と照合することは要求が含まれるべきかどうかの検証となる。 要求の特性を把握する: 当初の要求引き出しの特性を文書化すること。 用語を活用する: ビジネス用語の創造と使用はすべての要求引き出し技術にとって本質的に重要 4.2.7: ステイクホルダ: ビジネス・オーナー ユーザ部署 当該分野のエキスパート プロジェクト・マネジャ プロジェクトチーム
>Top 4.3: Technique: Brainstorming: 4.3.1: Purpose: Brainstorming is an excellent way of eliciting many creative ideas for an area of interest. 4.3.2: Description: Brainstorming means using the brain to storm a creative problem and to do so in commando fashion, each stormer audaciously attacking the same objective. 4.3.4: Intended Audience: Ideas generated in a brainstorming session are consumed by project team and shareholders 4.3.4: Process: Develop a clear and concise definition of the area of interest. Determine a time limit to generate ideas. Decide who will be included in the session and their role. Establish criteria for evaluation and rating the ideas. Conduct brainstorming session: Share new ideas without any discussion, criticism or evaluation. Visibly record all ideas. Encourage participants to be creative, share exaggerated ideas, and build on the id ears of others. Don't limit the number of ideas. Wrap up the brainstorming: Using pre-determined criteria, discuss and evaluate the ideas. Create a condensed list of ideas Rate the ideas Distribute the final list of ideas. Strength: Able to elicit many ideas in a short period. non-judgmental environment enables outside-the-box thinking Weakness: Dependent on participants' creativity	4.3: 技術：ブレインストーミング: 4.3.1: 目的: ブレインストームは創造的なアイデアを引き出すための優れた方法。 4.3.2: 解説: 大脳を活性化させて突撃部隊のように目的に対して大胆に急襲 4.3.4: 対象: ブレインスームの結果はプロジェクトチームやステイクホルダに報告 4.3.4: プロセス: 対象範囲の明確な定義 タイムリミット 任務の遂行者 評価基準 ブレインストーム会議実施: 議論・批判・評価なしに新アイデアを共有する。 すべてのアイデアの図示 創造的/極論アイデア、他人のアイデアの追加OK アイデア数制限なし ブレインストームの集約: 予め決めた基準に基づき、アイデアを議論・評価する アイデアの集約リスト作成 アイデアの順位付け 最終のアイデア表配布 強み: 短期間に多くのアイデア引き出す 断定的でない環境で独創的なアイデア可能 弱み: 参加者の創造性に依存
>Top 4.4: Technique: Document Analysis: 4.4.1: Purpose: 4.4.2: Description: 4.4.3: Intended Audience: 4.4.4: Process: 4.4.5: Usage Considerations: 4.5: Technique: Focus Group: 4.5.1: Purpose: 4.5.2: Description: 4.5.3: Intended Audience: 4.5.4: Process: 4.5.5: Usage Considerations: 4.6: Technique: Interface Analysis: 4.6.1: Purpose: 4.6.2: Description: 4.6.3: Intended Audience: 4.6.4: Process: 4.6.5: Usage Considerations: 4.7: Technique: Interview: 4.8: Technique: Observation 4.9: Technique: Prototyping 4.10 Technique: Requirements workshop: 4.11: Technique: Reverse Engineering: 4.12: Technique: Survey/Questionnaire 4.13: Bibliography: 4.14 Contributer:	4.4: 技術:文書分析: 4.4.1: 目的: 4.4.2: 解説: 4.4.3: 対象: 4.4.4: プロセス 4.4.5: 利用考察: 4.5: 技術: フォーカスグループ 4.4.1: 目的: 4.4.2: 解説: 4.4.3: 対象: 4.4.4: プロセス 4.4.5: 利用考察: 4.6: 技術: インターフェイス分析 4.4.1: 目的: 4.4.2: 解説: 4.4.3: 対象: 4.4.4: プロセス 4.4.5: 利用考察: 4.7: 技術: インタビュー 4.8: 技術: 観察 4.9: 技術: プロトタイピング 4.10: 技術: 要求ワークショップ 4.11: 技術: 収益エンジニアリング 4.12: 技術: 調査／質問 4.13: 参考文献 4.14: 貢献者
>Top 5. Requirements Analysis and Documentation: 5.1: Introduction 5.2: Task: Structure Requirements Packages 5.3: Task: Create Business Domain Model: 5.4: Task: Analyze User Requirements: 5.5: Task: Analyze Functional Requirements: 5.6: Task: Analyze Quality of Service Requirements: 5.7: Task: Determine Assumptions and Constraints 5.8: Task: Determine Requirements Attributes: 5.9: Task: Document Requirements 5.10: Task: Validate Requirements 5.11: Task: Verify Requirements: 5.12: Technique: Data and Behavior Models 5.13: Technique: Process/Flow Models: 5.14: Technique: Usage Models: 5.15: Issue and Task List 5.16: References:	5. 要求分析と文書化: 5.1: 序: 5.2: タスク：要求パッケージ構造化: 5.3: タスク：ビジネスドメインモデル作成: 5.4: タスク：ユーザ要求分析: 5.5: タスク：機能要求分析: 5.6: タスク：QoS要求分析: 5.7: タスク：前提と制約条件の決定: 5.8: タスク：要求属性の決定: 5.9: タスク：文書要求: 5.10: タスク：要求の検証: 5.11: タスク：要求の実証: 5.12: 技術：データ・振る舞いモデル: 5.13: 技術：プロセス／フロー・モデル: 5.14: 技術：ユーセッジ・モデル: 5.15: 課題とタスクリスト: 5.16: 参考文献:
>Top 6. Requirements Communication: 6.1: Introduction: 6.2: Task: Create a Requirements Communication Plan: 6.3: Task: Manage Requirements Conflicts: 6.4: Task: Determine Appropriate Requirements Format: 6.5: Task: Requirements Package: 6.6: Task: Conduct a Requirements Presentation: 6.7: Task: Conduct a Formal Requirements Review: 6.8: Task: Obtain Requirements Signoff: 6.9: References:	6. 要求コミュニケーション: 6.1: 序 6.2: タスク：要求コミュニケーション計画作成 6.3: タスク：要求不一致管理 6.4: タスク：最適要求フォーマット決定 6.5: タスク：要求パッケージ 6.6: タスク：要求プレゼンの実施 6.7: タスク：要求レビューの実施 6.8: タスク：要求承認取得 6.9: 参考文献 :
>Top 7. Solution Assessment and Validation: 7.1: Introduction: 7.2: Develop Alternate Solutions: 7.3: Evaluate Technology Options: 7.4: Facilitate The Selection of a Solution: 7.5: Ensure The Usability of The Solution: 7.6: Support The Quality Assurance Process: 7.7: Support The Implementation of The Solution: 7.8: Communicate The Solution Impacts: 7.9: Post Implementation Review and Assessment: 7.10: References:	7. ソリューション評価と検証: 7.1: 序 7.2: 代替ソリューション開発 7.3: 技術オプション評価 7.4: ソリューション選定の促進 7.5: ソリューションの有用性の裏付け 7.6: 品質保証プロセス支援 7.7: ソリューション実行支援 7.8: ソリューション・インパクトの連絡 7.9: 実行後のレビューと評価 7.10: 参考文献
>Top 8. Underlying Fundamentals: 8.1: Introduction: 8.2: Communication Skills: 8.3: Leadership Skills: 8.4: Problem Solving Skills: 8.5: Business Knowledge: 8.6: IT Knowledge: 8.7: References:	8. 基本能力: 8.1: 序 8.2: コミュニケーション・スキル 8.3: リーダーシップ・スキル 8.4: 問題解決スキル 8.5: 業務知識 8.6: IT知識 8.7: 参考文献
>Top 9. Glossary: 9.2: Terms: Activity diagram: Business analyst: Business requirements document: Class model: Constraint: A constraint describes any limitations imposed on the solution. Business constraints are things like budget limitations, restrictions on the people who can do the work, the skill sets available, etc. Technical constraints include any architecture decisions that are made. Deliverable: On the highest level of a deliverable is the solution due to the customer at the end of project. But, during a project there are a number of project artifacts and solution components due by project team members to other project team members. Diagram: Discovery session: Enterprise analysis: Feature: Functional design: Observable behaviours of the solution; as opposed to technical design. Functional requirements: Modeling: Representation of a business or solution that often include a graphic component along with supporting text and relations to other components. Needs: A type of high level requirement that is a statement of a business objective, or an impact the solution should have on it's environment. Non-functional requirements: Object-Oriented Modeling: Product: A solution or component of a solution that is the result of a project. Project: A temporary endeavor undertaken to create a unique product, service or result. Requirements: A requirements is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. Requirements analysis & documentation: Requirements attribute: Requirements communication: Requirements discovery session: A forum where stakeholders, Subject Matter Experts (SME) get together to provide information about the target system. This forum needs to be led by a Business Analyst who is a skilled Facilitator, and assisted by a Scribe whose role is to document the business requirements discovered. Synonym; Requirements Elicitation, Requirements Discovery Session (RDS), Joint Requirements Planning Session (JRPS) Requirement document: Requirement elicitation: This is a Knowledge Area within the BABOK. This Knowledge Area describes the collection of activities and approaches for capturing the requirements of a target system, from the stakeholders. Solution assessment and validation: Reverse engineering requirements: Requirements planning and management: Requirements workshop: Sequence diagram: Traceability: An association that exits between requirements when more detailed requirements are associated with the higher level requirements (needs and features) those detailed requirements support. Traceability associations can also exist between detailed requirements and both design models and test cases. Traceability between requirements and other project artifacts allows a BA to manage scope creep and ensure all requirements have been met. User case diagram: A type of a diagram defined by UML that captures all actors and use cases involved with a system or product.	9. 用語集: 9.2: 用語 制約 (Constraint) ソリューションに科せられる何らかの制限をいう。ビジネス的制約とは、予算制約、仕事に従事する人員の制約、スキルセット等。技術的制約は採用されるアーキテクチャの制約を含む。 成果物 (Deliverable) : 最高の成果物はプロジェクトの最後に顧客に提示されるソリューションである。但し、プロジェクトの途中では、数多くのプロジェクト成果やソリューション要素がプロジェクトチーム員によって他のプロジェクトチーム員に提示される。 機能設計 (Functional Desgin): 技術設計と異なり、観察可能なソリューションのふるまい モデリング (Modeling) : ビジネスあるいはソリューションの表示で、テキストや他要素との関連に加えて、しばしば図の要素を含む。 ニーズ (Needs): 業務目的が記載された上位レベルの要求タイプ、またはソリューションがその環境に対して与えるインパクト プロダクト (Product) : プロジェクトの結果としてのソリューションまたはソリューションの要素 プロジェクト (Project): ユニークな製品、サービスあるいは結果を作るために行われる一時的な活動 要求 (Requirements): ステークホルダが問題を解決し、あるいは目的を達成するために必要な条件または機能 要求発見会議 (Requirements discovery session) : ステークホルダおよび対象エキスパートが集まり目標システムについて情報を提供する会議。この会議は熟練のファシリテータであるBAによってリードされ、また発見されビジネス要求を文書化する役割の書記を伴う必要がある。 同義語としては、要求引き出し、要求発見会議、合同要求会議 要求引き出し (Requiement elicitation): これはBABOKの知識領域の一つである。この知識領域では、目標システムの要求を収集、および獲得方法について記述してある。 トレーサビリティ (Traceability): より詳細な要求がサポートする上位の要求 (ニーズや特徴) との間で関連がある場合をいう。またトレーサビリティの関連性は、詳細要求とデザインモデルやテストケースとの間にも存在する。要求と他のプロジェクト成果との間のトレーサビリティはBAにとって要件変更を管理し、全ての要求を確実に行うために必要となる、 ユースケース図 (User case diagram): UMLで定義される図であり、システムや製品に関わるすべての主体とユースケースを捉える。

Comment

The above summary is based on BABOK Ver.1.6, but Ver. 2.0 will be published soon. I hope that the coming Ver. 2.0 would not become more vague due to the consideration of copyright of preceding standards or other reasons.

上記要約はBABOK Ver.1.6に基づいている。Ver.2.0はまもなく出版予定である。 Ver. 2.0が先行する他標準などへの配慮によって内容が曖昧にならないことを期待する。