1 - Colophon [Seite 5]
2 - Preface [Seite 6]
3 - 1 Introduction [Seite 12]
3.1 - 1.1 Purpose of the Pocket Guide [Seite 12]
3.2 - 1.2 What is Business Analysis? [Seite 13]
3.3 - 1.3 The Need for Business Analysis [Seite 15]
3.4 - 1.4 About IIBA [Seite 17]
3.5 - 1.5 About the BABOK® Guide [Seite 18]
3.6 - 1.6 Key Terms to Understand [Seite 20]
3.7 - 1.7 Knowledge Areas, Techniques and Their Inter-Relationships [Seite 21]
3.8 - 1.8 Stakeholders and Their Influence on Business Analysis [Seite 22]
4 - 2 Business Analysis Planning and Monitoring [Seite 24]
4.1 - 2.1 Plan Business Analysis Approach [Seite 25]
4.2 - 2.2 Conduct Stakeholder Analysis [Seite 27]
4.3 - 2.3 Plan Business Analysis Activities [Seite 28]
4.4 - 2.4 Plan Business Analysis Communication [Seite 30]
4.5 - 2.5 Plan Requirements Management Process [Seite 32]
4.6 - 2.6 Manage Business Analysis Performance [Seite 32]
5 - 3 Elicitation [Seite 34]
5.1 - 3.1 Prepare for Elicitation [Seite 34]
5.2 - 3.2 Conduct Elicitation Activity [Seite 35]
5.3 - 3.3 Document Elicitation Results [Seite 37]
5.4 - 3.4 Confirm Elicitation Results [Seite 38]
6 - 4 Requirements Management and Communication [Seite 40]
6.1 - 4.1 Manage Solution Scope and Requirements [Seite 41]
6.2 - 4.2 Manage Requirements Traceability [Seite 42]
6.3 - 4.3 Maintain Requirements for Re-Use [Seite 44]
6.4 - 4.4 Prepare Requirements Package [Seite 45]
6.5 - 4.5 Communicate Requirements [Seite 46]
7 - 5 Enterprise Analysis [Seite 50]
7.1 - 5.1 Define Business Need [Seite 51]
7.2 - 5.2 Assess Capability Gaps [Seite 52]
7.3 - 5.3 Determine Solution Approach [Seite 53]
7.4 - 5.4 Define Solution Scope [Seite 54]
7.5 - 5.5 Define Business Case [Seite 55]
8 - 6 Requirements Analysis [Seite 58]
8.1 - 6.1 Prioritize Requirements [Seite 59]
8.2 - 6.2 Organize Requirements [Seite 60]
8.3 - 6.3 Specify and Model Requirements [Seite 61]
8.4 - 6.4 Define Assumptions and Constraints [Seite 63]
8.5 - 6.5 Verify Requirements [Seite 65]
8.6 - 6.6 Validate Requirements [Seite 67]
9 - 7 Solution Assessment and Validation [Seite 70]
9.1 - 7.1 Assess Proposed Solution [Seite 71]
9.2 - 7.2 Allocate Requirements [Seite 73]
9.3 - 7.3 Assess Organizational Readiness [Seite 74]
9.4 - 7.4 Define Transition Requirements [Seite 77]
9.5 - 7.5 Validate Solution [Seite 78]
9.6 - 7.6 Evaluate Solution Performance [Seite 79]
10 - 8 Underlying Competencies [Seite 82]
10.1 - 8.1 BABOK® Guide Underlying Competencies [Seite 83]
10.2 - 8.2 Additional Competencies [Seite 85]
10.3 - 8.3 Additional Behavioral Characteristics [Seite 87]
10.4 - 8.4 Complementary Disciplines [Seite 89]
11 - 9 Techniques [Seite 92]
11.1 - 9.1 BABOK® Guide General Techniques [Seite 92]
11.2 - 9.2 Other Techniques [Seite 97]
12 - 10 Applying the BABOK® Guide [Seite 102]
12.1 - 10.1 Developing a Business Analysis Methodology [Seite 103]
12.2 - 10.2 Business Analysis Maturity and Competency Models [Seite 107]
12.3 - 10.3 Improving Business Analysis Practices [Seite 110]
13 - Appendix A Glossary [Seite 114]
14 - Appendix B References [Seite 120]
To effectively perform business analysis you need to plan how the business analysis activities will be executed and understand how to assess the value of the outputs from those activities. The plan should be based on the context of:
■ What you are trying to accomplish and the reasons why it is worthwhile;
■ Your organizational environment;
■ What assets and tools you have available at your disposal.
There are six Business Analysis Planning and Monitoring tasks:
1. Plan business analysis approach: determine how the overall business analysis work will be completed.
2. Conduct stakeholder analysis: identify and classify people and groups who are affected by the project or initiative.
3. Plan business analysis activities: define which specific business activities will be performed, the outputs that will be generated, and the amount of time and effort required to perform the activities.
4. Plan business analysis communication: describe how business analysis activities and outputs will be communicated, to whom, and when.
5. Plan requirements management process: determine how requirements and the scope of the solution will be managed as changes occur over time.
6. Manage business analysis performance: identify how the performance of business analysis activities will be assessed and improved.
The resulting plans and associated documents produced during these tasks are used to guide and monitor all of the other activities that Business Analysts perform in the context of a particular project or initiative.
2.1 Plan Business Analysis Approach
An approach to performing business analysis activities is used to govern the development of specific business analysis plans. Organizations may define a formal, repeatable approach (called a method) to ensure consistency between various projects or initiatives.
Note: The approach describes the characteristics of how activities should be performed, while the plan defines the details of the activities for the particular effort being undertaken.
The business analysis approach should address the following questions:
When are business analysis activities being performed in the context of the other activities of the project or initiative?
What format and structure will business analysis deliverables take?
How will requirements be prioritized?
How will changes to requirements be managed?
How will the detailed business analysis plan be developed?
What types of communication will be used with stakeholders?
What tools will be used to manage and analyze requirements?
There are two general types of approaches taken to perform business analysis activities. Most approaches fall somewhere between these two extremes:
■ Plan-driven approaches often have very structured stages with formal controls placed on proceeding between each stage. Plan-driven approaches focus on identifying as many requirements as possible initially, and serve as the basis for determining subsequent stages of the initiative.
■ Change-driven approaches focus on iteratively producing tangible results that solve a portion of the business need. Requirements outside of the current iteration are often left at a high level and are not subject to strict change control processes.
If there is no prescribed approach for the effort being undertaken, or there are parts of the approach that must be customized for the particular effort, the Business Analyst takes into account the following considerations:
■ The business need being addressed and the nature of the initiative to address the business need;
■ The organizational process assets available, such as methodologies, defined business analysis processes, tools and templates;
■ Internal or external expertise available from Business Analysts or Business Analyst groups.
Example: The approach taken to determine the requirements to implement a new enterprise-wide information system will likely be very different to the approach for assessing a request to modify a screen on an existing software solution, given the difference in complexity and breadth of the impact of each effort.
2.2 Conduct Stakeholder Analysis
Whenever an effort is undertaken, there is at least one individual or group who is affected by the end result. Business Analysts need to know who these people are and how they need to be engaged in order to successfully achieve the effort's objectives.
Stakeholder analysis helps answer the following questions:
Who is directly or indirectly affected by the initiative?
What are the relevant characteristics of each stakeholder that pertain to the initiative?
What are the commonalities amongst stakeholders and how can they be grouped?
Which stakeholders need to be involved in specific business analysis activities and in what capacity?
Tip: Stakeholder analysis is not only needed for business analysis activities. In projects this task is often performed in collaboration with the Project Manager and/or Change Management staff, as they also require detailed information on the groups affected by the project's end product.
Stakeholders may be categorized in several different ways:
■ Organization or organizational unit;
■ Job function;
■ Hierarchical level (e.g. executives, supervisors, front-line staff);
■ Domain knowledge/skillset;
■ Some other common characteristic (e.g. an end user of the information system).
Each stakeholder group should share common characteristics that are relevant to the initiative. Some of the potential characteristics captured for each stakeholder group include:
■ Their overall role in the initiative;
■ Key contacts within the group and their respective roles;
■ Relevant metrics about the group (e.g. number of people or organizations, revenue or cost information);
■ Their attitude, influence, and level of engagement in the effort;
■ Their authority for particular business analysis deliverables (e.g.approval, review, consult, end consumer);
■ Risks and opportunities that could affect the outcome of the initiative.
The resulting stakeholder matrix is used to determine what specific business analysis activities are required.
Tip: This matrix should be updated continuously as the effort undertaken progresses to ensure activities are adapted if there is a change in a stakeholder's role or attitude towards the effort.
2.3 Plan Business Analysis Activities
The business analysis plan is the central component guiding other Business Analyst activities. See figure 2.1. The content and format of the plan can vary due to several factors:
■ Desired outcomes from the initiative;
■ Complexity of the initiative;
■ Approach taken to address the business need;
■ Organizational or environmental norms or standards that must be met.
When developing a business analysis plan, the Business Analyst is applying the approach they have defined in Section 2.1. While the approach describes how to go about getting the work done, the plan specifies exactly what activities will be performed, how much effort they will take and their relationships to each other and non-business analysis activities.
Figure 2.1 The business analysis plan is used by all other knowledge areas
Building the business analysis plan can involve working back from the end result to identify the necessary activities:
1. Assess target outcomes: what needs to have occurred when the business analysis activities are completed?
2. Identify deliverables: in order to meet your outcomes, what work products are needed?
3. Determine activities: what actions need to occur in order to produce the required deliverables?
4. Define activity relationships: which activities have dependencies with one another or external events or actions?
5. Estimate effort and duration: how much time will it take to complete each activity, both in terms of hours spent on a task and total time elapsed from the beginning of the activity until it is finished?
Tip: When identifying the...
