interactive tables - projerra · interactive tables for the babok® 2nd edition 4 requirements...

VisuAL BA™ Interactive Tables for the BABOK® 2nd Edition. Copyright Projerra Inc. 2012 of 24

Interactive Tables For the BABOK® 2nd Edition

4 Requirements Management & Communication

6 Requirements Analysis 7 Solution Assessment

& Validation 5 Enterprise Analysis 3 Elicitation

2 Business Analysis Planning & Monitoring

for the BABOK® 2nd Edition

Interactive Tables







THANK YOU Thank you for purchasing a copy of the VisuAL BA™ Interactive Tables by Projerra Inc. We hope that the presentation of the knowledge areas, tasks, and techniques in a visual and interactive manner will assist you in your

preparation for the CBAP®/CCBA® exam.

VisuAL BA™ Interactive Tables are part of a suite of visual and interactive products developed by Projerra Inc. Please visit www.projerra.ca to learn about the other study aids that are available. We appreciate thoughts and feedback from the professionals that use our products. Please contact us at [email protected]. PUBLISHED BY Projerra Inc. 439 John Aselford Drive Ottawa, Ontario, Canada, K2W 1A8 www.projerra.ca COPYRIGHT Copyright 2012 by Projerra Inc. All rights reserved. No part of this study aid may be reproduced, stored, or transmitted, in any form or by any means, without the prior written permission of the publisher. First Edition 2012

REFERENCES International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) – Version 2.0, 2009. Copyright and all rights reserved. REGISTERED MARKS IIBA® and BABOK® are registered trademarks owned by International Insti-tute of Business Analysis. CBAP® and CCBA® are registered certification marks owned by International Institute of Business Analysis. These trade-marks are used with the express permission of International Institute of Busi-ness Analysis® (IIBA®) VisuAL BA™ is a registered mark of Projerra Inc.

for the BABOK® 2nd Edition Interactive Tables

http://www.projerra.ca

mailto:[email protected]

http://www.projerra.ca/







WHAT IS VISUAL BA™? VisuAL BA™ is Visually Assisted Learning for Business Analysis. It is a suite of products that can help you visualize the relationships and dependencies that exist between the tasks and documents that are defined in the BABOK® Sec-ond Edition. The graphical and color oriented presentation allows you to see the associations between the tasks and the various input and output docu-ments. HOW TO USE THIS PRODUCT Color has been used to visually represent the relationship between the 32 processes, 6 knowledge areas, and the many inputs, outputs, and techniques that are defined in the BABOK® Second Edition. The front section of the document presents the processes associated with each knowledge area. The header of the sheet identifies the knowledge area represented on that sheet and the chapter where that knowledge area is defined in the BABOK®. The body of the sheet contains a table that identifies the inputs, outputs, elements and techniques of the process. The later section of the document presents the various techniques that are defined in the BABOK®, the advantages and disadvantages associated with each technique. Also identified are the set of processes that use the tech-nique. Throughout the document hyperlinks have been used to help you jump for-ward and backward through the document to see how the tasks, techniques, and input/output documents are related. Use the PDF on your computer or tablet to explore through the network of tasks and techniques. Print out the tables and take them with you for a quick reference guide.

for the BABOK® 2nd Edition Interactive Tables

LEGEND Different colors have been used to help you identify the knowledge area under study. Knowledge Areas VisuAL BA™ products have helped hundreds of students pass the CABP™/CAPM™ Certification Exam. We hope that you will find it as useful as they did.


6 Requirements Analysis

7 Solution Assessment & Validation

5 Enterprise Analysis

3 Elicitation








Business Analysis Tasks by Knowledge Area

4.2 Manage Requirements Traceability

6.1 Prioritize Requirements

7.6 Evaluate Solution Performance

5.1 Define Business Need

3.4 Confirm Elicitation Results

2.1 Plan Business Analysis Approach

2.2 Conduct Stakeholder Analysis

2.3 Plan Business Analysis Activities

2.4 Plan Business Analysis Communication

2.5 Plan Requirements Management Process

2.6 Manage Business Analysis Performance

3.1 Prepare for Elicitation

3.3 Document Elicitation Results

3.2 Conduct Elicitation Activity

4.3 Maintain Requirements for Reuse

4.4 Prepare Requirements Package

4.5 Communicate Requirements

4.1 Manage Solution Scope Requirements

5.2 Assess Capability Gaps

5.3 Determine Solution Approach

5.5 Define Solution Approach

5.5 Define Business Case

6.2 Organize Requirements

6.3 Specify and Model Requirements

6.4 Define Assumptions & Constraints

6.5 Verify Requirements

6.6 Validate Requirements

7.5 Validate Solution

7.4 Define Transition Requirements

7.3 Assess Organizational Readiness

7.2 Allocate Requirements

7.1 Assess Proposed Solu-tion

2 Business Analysis Planning

& Monitoring


6 Requirements Analysis

7 Solution Assessment &

Validation

5 Enterprise Analysis

Underlying Competencies

3 Elicitation

Business Analysis Start







BA Planning & Monitoring | Chapter 2

Task Name Inputs Elements Techniques Stakeholders Outputs

2.1 Plan BA Approach describes how to select an approach for business analy-sis, which stakeholders need to be involved in defining the approach, and who will be consulted/informed about the approach, including the rationale for using it.

Business need (5.1) Expert judgment Organizational process assets Implicit Input: BA plan(s) (2.3)

Plan vs Change driven appraoch 1. Timing 2. Formality and detail 3. Requirements prioritization 4. Change management 5. Planning process 6. Communication with stakeholders 7. Req analysis & mgmt tools 8. Project complexity

General: Decision analysis (9.8) Process modeling (9.21) Structured walkthrough (9.30)

Customer, Domain SME End User, Supplier Implementation SME Project Manager Tester Regulator Sponsor

Business analysis approach Implicit Output: BA perf metrics

2.2 Conduct Stakeholder Analysis identifies the stakeholders who may be affected by the initiative. Determines stake-holder influence and/or authority regarding approval of deliverables.

Business need (5.1) Enterprise architecture Organizational process assets Implicit Input: BA plan(s) (2.3)

1. Identification 2. Complexity of stakeholder group 3. Attitude and influence 4. Authority levels for BA work

General: Acceptance & evaluation criteria (9.1) Brainstorming (9.3) Interviews (9.14) Organizational modeling (9.19) Process modeling (9.21) Requirements workshops (9.23) Risk analysis (9.24)

Domain SME Implementation SME Project Manager Tester Regulator Sponsor

Stakeholder list, roles & responsibili-ties Implicit Output: BA perf metrics

Scenarios & use cases (9.26) Scope modeling (9.27) Survey / questionnaire (9.31) User Stories (9.33) Other: RACI matrix Stakeholder map

2.3 Plan BA Activities Identifies the activities and deliverables, the effort to perform the work and the management tools to meas-ure progress.

BA approach (2.1) BA performance assessment (2.6) Organizational process assets Stakeholder list, roles, & resp (2.2) Implicit Input: BA plan(s) (2.3)

1. Geographic distribution 2. Type of project/initiative 3. BA deliverables 4. Determine BA activities

General: Estimation (9.10) Functional decomposition (9.12) Risk analysis (9.24)

Customer, Domain SME End User, Supplier Implementation SME Operational Support Project Manager Tester Sponsor

BA Plan(s) Implicit Output: BA perf metrics

2.4 Plan BA Communica-tion Describes the structure and schedule for BA communica-tions. Organize activities to set expectations for BA work, meetings, walkthroughs and other communications.

BA approach (2.1) BA plan(s) (2.3) Organizational process assets Stakeholder list, roles, & resp (2.2) Implicit Input: BA plan(s) (2.3)

1. Geography 2. Culture 3. Project type 4. Communication frequency 5. Communication formality

General: Prepare requirement package(4.4) Communicate requirements (4.5) Communication skills (8.4) Structured walkthrough (9.30)

Customer, Domain SME End User, Supplier Implementation SME Operational Support Project Manager Tester Regulator Sponsor

BA communication plan Implicit Output: BA perf metrics

2.5 Plan Req. Mgmt. Proc-ess Define the process to ap-proved requirements and manage change to the solu-tion or requirement scope.

BA approach (2.1) BA plan(s) (2.3) Organizational process assets Implicit Input: BA plan(s) (2.3)

1. Repository 2. Traceability 3. Select requirement attributes 4. Requirements prioritization 5. Change management 6. Tailoring requirements mgmt process

General: Decision analysis (9.8) Problem tracking (9.20) Risk analysis (9.24)

Domain SME, End User Implementation SME Operational Support Project Manager Tester Sponsor

Requirements mgmt plan Implicit Output: BA perf metrics

2.6 Manage BA Perform-ance Manage the performance of BA activities and ensure that they are executed effectively.

BA performance metrics (all tasks) BA plan(s) (2.3) Organizational performance standards Requirements mgmt plan (2.5) Implicit Input: BA plan(s) (2.3)

1. Performance measures 2. Performance reporting 3. Preventative & corrective action

General: Interviews (9.14) Lessons learned process (9.15) Metrics & KPI (9.16) Problem tracking (9.20) Process modeling (9.21) Survey/questionnaire (9.31)

Domain SME, End User Implementation SME Project Manager Sponsor

BA performance assessment BA process assets Implicit Output: BA perf metrics

Root cause analysis (9.25) Survey / questionnaire (9.31) Other: Variance Analysis







Elicitation | Chapter 3


3.1 Prepare for Elicitation Ensure all required resources are sched-uled and organized for elicitation activi-ties.

Business need (5.1) Solution scope (5.4) Business case (5.5) Stakeholder list, roles & responsibilities (2.2) Implicit Input: BA plan(s) (2.3)

1. Clarify scope 2. Schedule resources 3. Mechanism for signoff 4. Form and frequency for feedback 5. Ground rules

General: Brainstorming (9.3) Document analysis (9.9) Focus groups (9.11) Interface analysis (9.13) Interviews (9.14) Observation (9.18) Prototyping (9.22) Requirements workshops (9.23) Survey/questionnaire (9.31)

All stakeholders Project Manager

Scheduled resources Supporting materials Implicit Output: BA perf metrics

3.2 Conduct Elicitation Activity Meet with stakeholders and gather information regarding their business needs.

Business need (5.1) Organizational process assets Requirements management plan (2.5) Scheduled resources (3.1) Solution scope (5.4) Business case (5.5) Supporting materials (3.1) Implicit Input: BA plan(s) (2.3)

1. Tracing requirements 2. Capturing requirement attributes 3. Metrics

General: Brainstorming (9.3) Data dictionary and glossary (9.5) Document analysis (9.9) Focus groups (9.11) Interface analysis (9.13) Interviews (9.14) Observation (9.18) Prototyping (9.22) Requirements workshops (9.23) Survey/questionnaire (9.31)

Customer, Domain SME End User, Supplier, Sponsor Implementation SME Operational Support Project Manager Supplier Tester Regulator

Elicitation results Implicit Output: BA perf metrics

3.3 Document Elicitation Results Take note of the information provided by stakeholders.

Elicitation results (3.2) Implicit Input: BA plan(s) (2.3)

1. Documentation variety of forms (written documents, visual or audio, whiteboards, virtual notes)

General: Brainstorming (9.3) Document analysis (9.9) Focus groups (9.11) Interface analysis (9.13) Interviews (9.14) Observation (9.18) Problem tracking (9.20) Prototyping (9.22) Requirements workshops (9.23) Survey/questionnaire (9.31)

Business Analyst Requirements (stated) Stakeholder concerns Implicit Output: BA perf metrics

3.4 Confirm Elicitation Results Validate that the documented require-ments meet the stakeholder’s under-standing of business problem and their needs.

Requirements (stated, unconfirmed) (3.3) Stakeholder concerns (unconfirmed) (3.3) Implicit Input: BA plan(s) (2.3)

General: Interviews (9.14) Observation (9.18)

Any participant Requirements (stated, con-firmed) Stakeholder concerns (confirmed) Implicit Output: BA perf metrics







Task Name Inputs Elements Techniques Stakeholders Outputs 4.1 Manage Solution Scope & Re-quirements Reach consensus among stakeholders regarding overall scope and require-ments to be implemented.

Requirements management plan (2.5) Solution scope (5.4) Stakeholder list, roles & responsibilities (2.2) Stakeholder requirements Solution requirements Transition requirements (7.4) Implicit Input: BA plan(s) (2.3)

1. Solution scope management 2. Conflict and issue management 3. Presenting requirements for review 4. Approval

General: Problem tracking (9.20) Other: Baselining Signoff

Domain SME Implementation SME Project Manager Sponsor

Requirements (Approved) Implicit Output: BA perf metrics

4.2 Manage Requirements Trace-ability Create and maintain relationships be-tween business objectives, require-ments, solution components and deliv-erables.

Requirements Requirements management plan (2.5) Implicit Input: BA plan(s) (2.3)

1. Relationships: Necessity; Effort; Subset; Cover; Value

2. Impact analysis 3. Configuration management systems

Other: Coverage matrix

Implementation SME Project Manager Tester

Requirements (Traced) Implicit Output: BA perf metrics

4.3 Maintain Requirements for Re-use Manage knowledge of requirements following implementation.

Organizational process assets Requirements Implicit Input: BA plan(s) (2.3)

1. Ongoing requirements 2. Satisfied requirements

None Business analyst Domain SME Implementation SME

Requirements (Maintained & Reusable) Implicit Output: BA perf metrics

4.4 Prepare Requirements Package Prepare documentation of requirements to ensure that they are effectively com-municated and understood and usable by stakeholders.

BA communication plan (2.4) Organizational process assets Requirements Requirements structure (6.2) Implicit Input: BA plan(s) (2.3)

1. Work products & deliverables 2. Format

Other: Requirements documentation Requirements for vendor selection

Domain SME & End users Implementation SME Project Managers Regulators Sponsors Testers

Requirements package Implicit Output: BA perf metrics

4.5 Communicate Requirements Share and discuss. Bring stakeholders to a common understanding of require-ments.

BA communication plan (2.4) Requirements Requirements package (4.4) Implicit Input: BA plan(s) (2.3)

1. General communication: Enterprise analysis tasks; Elicita-tion tasks; Requirements analysis tasks; Solution assessment & validation tasks

2. Presentations: Formal or informal

General: Requirements workshops (9.23) Structured walkthrough (9.30)

All Communicated requirements Implicit Output: BA perf metrics

Requirements Management & Communication | Chapter 4







Enterprise Analysis | Chapter 5


5.1 Define Business Need Discover and define why changes to organizational systems and capabilities are required.

Business goals and objectives Requirements (stated) (3.3) Implicit Input: BA plan(s) (2.3)

1. Business goals and objectives (SMART) 2. Business problem or opportunity 3. Desired outcome

General: Benchmarking (9.2) Brainstorming(9.3) Business rules analysis (9.4) Focus groups (9.11) Functional decomposition (9.12) Root cause analysis (9.25)

Customer or Supplier Domain SME & End User Implementation SME Regulator Sponsor

Business need Implicit Output: BA perf metrics

5.2 Assess Capability Gaps Analyze and identify capability gaps.

Business need (5.1) Enterprise architecture Solution performance assessment (7.6) Implicit Input: BA plan(s) (2.3)

1. Current capability analysis 2. Assessment of new capability requirements 3. Assumptions

General: Document analysis (9.9) SWOT (9.32)

Customer or Supplier Domain SME & End User Implementation SME Sponsor

Required capabilities Implicit Output: BA perf metrics

5.3 Determine Solution Approach Identify the most viable approach to meet the business need, described with enough detail to allow definition of scope and preparation of business case.

Business need (5.1) Organizational process assets Required capabilities (5.2) Implicit Input: BA plan(s) (2.3)

1. Alternative generation 2. Assumptions & constraints 3. Ranking & selection of approaches

General: Benchmarking (9.2) Brainstorming (9.3) Decision Analysis (9.8) Estimation (9.10) SWOT (9.32) Other: Feasibility analysis

Customer or Supplier Domain SME & End User Implementation SME Sponsor

Solution approach Implicit Output: BA perf metrics

5.4 Define Solution Scope Define the new capabilities that will be delivered in each iteration.

Assumptions & constraints (6.4) Business need (5.1) Required capabilities Solution approach (5.3) Implicit Input: BA plan(s) (2.3)

1. Solution scope definition 2. Implementation approach 3. Dependencies

General: Functional decomposition (9.12) Interface analysis (9.13) Scope modeling (9.27) User stories (9.33) Other: Problem or vision statement


Solution scope Implicit Output: BA perf metrics

5.5 Define Business Case Determine if the organization can justify the investment required to carry out the solution proposed.

Assumptions & constraints (6.4) Business need (5.1) Solution scope (5.4) Stakeholder concerns (3.3) Implicit Input: BA plan(s) (2.3)

1. Benefits 2. Costs 3. Risk assessment 4. Results measurement

General: Decision analysis (9.8) Estimation (9.10) Metrics & KPI (9.16) Risk analysis (9.24) SWOT analysis (9.32) Vendor assessment (9.34)

Sponsor Domain SME Implementation SME Project Manager

Business case Implicit Output: BA perf metrics







Requirements Analysis | Chapter 6


6.1 Prioritize Requirements A decision process to determine the relative importance of re-quirements. Ensures that effort is focussed on most critical items.

Business case (5.5) Business need (5.1) Requirements Req mgmt plan (2.5) Stakeholder list, roles, re-sponsibilities (2.2) Implicit Input: BA plan(s) (2.3)

1. Basis for prioritization: Business value; Business or techni-cal risk; Implementation difficulty; Likelihood of success; Regulation or policy compliance; Relationship to other Requirements; Stakeholder agreement; Urgency

2. Challenges: Non-negotiable demands, Unrealis-tic tradeoffs

General: Decision analysis (9.8) Risk analysis (9.24) Other: MoSCoW analysis Timeboxing/budgeting Voting


Requirements (Prioritized) Implicit Output: BA perf metrics

6.2 Organize Requirements Create a set of views of require-ments.

Org process assets Requirements (stated) (3.3) Solution scope (5.4) Implicit Input: BA plan(s) (2.3)

1. Levels of abstraction 2. Model selection:

User classes, profiles, roles; Con-cepts and Relationships; Events; Processes; Rules

General: Business rule analysis (9.4) Data modeling (9.7) Organizational modeling (9.19) Scenarios & use cases (9.26) User stories (9.33)

Domain SME End User Implementation SME Project Manager Sponsor

Requirements Struc-ture Implicit Output: BA perf metrics

Data flow diagrams (9.6) Functional decomposition (9.12) Process modeling (9.21) Scope modeling (9.27)

6.3 Specify and Model Re-quirements Express current or future state of an organization (or system) using a combination of text, matrices, diagrams, and models.

Requirements (stated) (3.3) Requirements structure (6.2) Implicit Input: BA plan(s) (2.3)

1. Text 2. Matrix documentation 3. Models 4. Capture requirement attributes 5. Improvement Opportunities

General: Acceptance and evaluation criteria (9.1) Data dictionary & glossary (9.5) Data modeling (9.7) Interface analysis (9.13) Non-functional req. analysis (9.17) Process modeling (9.21) Scenarios & use cases (9.26) State diagrams (9.29)

Any Requirements (analyzed) Implicit Output: BA perf metrics

Business rule analysis (9.4) Data flow diagrams (9.6) Functional decomposition (9.12) Metrics and KPI (9.16) Organizational modeling (9.19) Prototyping (9.22) Sequence diagrams (9.28) User stories (9.33)

6.4 Define Assumptions & Constraints Identify assumptions, limitations, or restrictions that may influence the set of viable solutions.

Stakeholder concerns (3.3) Implicit Input: BA plan(s) (2.3)

1. Assumptions 2. Business constraints 3. Technical constraints

General: Problem tracking (9.20) Risk analysis (9.24)

Implementation SME Project Manager All stakeholders

Assumptions & Constraints Implicit Output: BA perf metrics

6.5 Verify Requirements Ensure that the requirements specifications and models meet the standard of quality.

Requirements (any except stated) Implicit Input: BA plan(s) (2.3)

1. Characteristics of quality: Cohesive; Complete; Consistent; Correct; Feasible; Modifiable; Un-ambiguous; Testable

2. Verification activities

General: Acceptance and evaluation criteria (9.1) Problem tracking (9.20) Structured walkthrough (9.30)

All stakeholders Requirements (verified) Implicit Output: BA perf metrics

Other: Checklists

6.6 Validate Requirements Ensure that all requirements support the delivery of value to the business and meet stake-holder need.

Business case (5.5) Stakeholder, solution, or Transition requirements (verified) Implicit Input: BA plan(s) (2.3)

1. Identify assumptions 2. Define measurable evaluation crite-ria 3. Determine business value 4. Determine dependencies for benefits realization 5. Evaluation alignment with business case and opportunity cost

General: Acceptance and evaluation criteria (9.1) Metrics & KPI (9.16) Prototyping (9.22) Risk analysis (9.24) Structured walkthrough (9.30)

All stakeholders Requirements (validated) Implicit Output: BA perf metrics







Solution Assessment & Validation | Chapter 7


7.1 Assess Proposed Solution Evaluate proposed solutions to deter-mine how closely they satisfy stake-holder and solution requirements.

Assumptions and constraints (6.4) Requirements (prioritized and ap-proved) Solution option(s) Implicit Input: BA plan(s) (2.3)

1. Ranking of solution options 2. Identification of additional po-tential capabilities

General: Acceptance and evaluation criteria definition (9.1) Decision analysis (9.8) Vendor assessment (9.34)

Domain SME Implementation SME Operational Support Project Manager Supplier, Sponsor

Assessment of proposed solution Implicit Output: BA perf metrics

7.2 Allocate Requirements Allocate requirements to solution com-ponents and releases to maximize business value.

Requirements (prioritized & approved) Solution (designed) Solution scope (5.4) Implicit Input: BA plan(s) (2.3)

1. Solution components 2. Release planning

General: Acceptance and evaluation criteria definition (9.1) Business Rules Analysis (9.4) Decision analysis (9.8) Functional Decomposition (9.12) Process Modeling (9.21) Scenarios and Use Cases (9.26)

Customers & Suppliers Domain SME End User Implementation SME Operational Support Project Manager Tester Sponsor

Requirements (allocated) Implicit Output: BA perf metrics

7.3 Assess Organizational Readi-ness Assess if the organization is ready to use of the new solution effectively.

Enterprise architecture Solution scope (5.4) Solution (designed) Stakeholder concerns (3.3) Implicit Input: BA plan(s) (2.3)

1. Cultural assessment 2. Operational or technical assess-ment 3. Stakeholder impact analysis (functions, location, tasks, con-cerns)

General: Acceptance and evaluation criteria definition (9.1) Data flow diagrams (9.6) Focus groups (9.11) Interviews (9.14) Organizational modeling (9.19) Problem tracking (9.20) Process models (9.21) Risk analysis (9.24) Survey/questionnaire (9.31) SWOT analysis (9.32) Other: Force field analysis

Domain SME Implementation SME Operational Support Project Manager Sponsor

Organizational readiness assessment Implicit Output: BA perf metrics

7.4 Define Transition Requirements Define requirements for capabilities to transition from existing to new solution.

Org readiness assessment (7.3) Requirements (stated) Solution (deployed) Solution (designed) Implicit Input: BA plan(s) (2.3)

1. Data 2. Ongoing work 3. Organizational change

General: Business rule analysis (9.4) Data flow diagrams (9.6) Data modeling (9.7) Organizational modeling (9.19) Process modeling (9.21)

Customer Domain SME, End User Implementation SME Operational Support Project Manager Regulator Tester, Sponsor

Transition requirements Implicit Output: BA perf metrics

7.5 Validate Solution Confirm that a solution meets the business need. Determine the most effective response to identified defects.

Solution (constructed) Requirements (prioritize & validated) Implicit Input: BA plan(s) (2.3)

1. Investigate defective solution outputs 2. Assess defects & issues

General: Acceptance and evaluation criteria definition (9.1) Problem tracking (9.20) Root cause analysis (9.25)

Domain SME End User Implementation SME Operational Support Project Manager Regulator, Tester, Sponsor

Identified defects Mitigating actions Solution validation assess-ment Implicit Output:

7.6 Evaluate Solution Performance Evaluate operating solutions to under-stand the value delivered and identify opportunities for improvement.

Business requirements Identified defects (7.5) Solution performance metrics Solution (deployed) Implicit Input: BA plan(s) (2.3)

1. Understand value delivered by solution 2. Validate solution metrics 3. Solution replacement or elimina-tion

General: Decision analysis (9.8) Focus groups (9.11) Observation (9.18) Survey/questionnaire (9.31)

Customer Domain SME Supplier End User Operational Support Regulator Sponsor

Solution performance assess-ment Implicit Output: BA perf metrics







BA Documentation Sources

2.1 Plan Business Analysis Approach Business Analysis Approach

2.2 Conduct Stakeholder Analysis Stakeholder List, Roles & Responsibilities

2.3 Plan Business Analysis Activities Business Analysis Plan(s)

2.4 Plan BA Communication Business Analysis Communication Plan

2.5 Plan Requirements Management Process Requirements Management Plan

2.6 Manage BA Performance Business Analysis Performance Assessment Business Analysis Processes Assets

5.1 Defined Business Need Business Need

5.2 Assess Capability Gaps Required Capabilities

5.3 Determine Solution Approach Solution Approach

5.4 Define Solution Scope Solution Scope

5.5 Define Business Case Business Case

4.1 Manage Solution Scope & Requirements Requirements (Approved)

4.2 Manage Requirements Traceability Requirements (Traced)

4.3 Maintain Requirements for Re-use Requirements (Maintained & Reusable)

4.4 Prepare Requirements Package Requirements Package

4.5 Communicate Requirements Communicated Requirements

3.1 Prepare for Elicitation Scheduled Resources Supporting Materials

3.2 Conduct Elicitation Activity Elicitation Results

3.3 Document Elicitation Results Requirements (stated) Stakeholder concerns

3.4 Confirm Elicitation Results Requirements (stated, confirmed) Stakeholder concerns (confirmed)

7.1 Assess Proposed Solution Assessment of Proposed Solution

7.2 Allocate Requirements Requirements (Allocated)

7.3 Assess Organizational Readiness Organizational Readiness Assessment

7.4 Define Transition Requirements Transition Requirements

7.5 Validate Solution Identified Defects Mitigating Actions Solution Validation Assessment

7.6 Evaluate Solution Performance Solution Performance Assessment

6.1 Prioritize Requirements Requirements (Prioritized)

6.2 Organize Requirements Requirements (Structure)

6.3 Specify and Model Requirements Requirements (Analyzed)

6.4 Define Assumptions and Constraints Assumptions & Constraints

6.5 Verify Requirements Requirements (Verified)

6.6 Validate Requirements Requirements (Validated)

BA Documents & Outputs

BAPM

RMC

RA

SAVEA

Underlying Competencies

E

Business Analysis Start







Generally Accepted Techniques

Technique Description Elements Advantages Disadvantages Usage Purpose

9.1 Acceptance & Evaluation Criteria Definition To define the requirements that must be met in order for a solution to be considered acceptable to key stakeholders. Acceptance criteria describe the minimal set of requirements that must be met in order for a particular solution to be worth implementing. Evaluation criteria are the set of require-ments that will be used to choose between multiple solutions.

Testability Ranking: determining the relative importance of all requirements Scoring: determining how well a solutions meets the requirements

Agile methodologies may require that all requirements be ex-pressed in the form of testable acceptance criteria Acceptance criteria are necessary when the requirements express contractual obligations.

May express contractual obligations and may be difficult to change for legal or political reasons.


To identify the stakeholders that must be engaged in the acceptance and evaluation of the solution.


To identify the requirements to evaluate the solution

6.5 Verify Requirements To ensure the requirements are constructed accu-rately so they may be used to evaluate the solution

6.6 Validate Requirements To test the solution according to the defined evaluation criteria

7.1 Assess Proposed Solu-tion

To evaluate the proposed solution—does it meet the requirements?

7.2 Allocate Requirements To evaluate the bundles of solution that are avail-able in each release to ensure that they maximize business value.

7.3 Assess Organizational Readiness

To determine if the organization is ready to make effective use of the solution

7.5 Validate Solution To evaluate the developed/deployed solution — does it meet the requirements?

9.2 Benchmarking To compare organizational practices against the best-in-class practices that exist within competitor enterprises in government or industry. To determine how companies achieve their superior performance levels and use that information to design projects to improve operations of the enterprise. Focused on strategies, operations and processes.

Identify the area to be studied Identify leaders in the sector Conduct survey to understand their practices Arrange visit to best-in-class organizations Develop a project proposal to implement the best practices

Provides organizations with information about new and different methods, ideas, and tools to improve organ-izational performance

Is time consuming Organizations may not have the expertise to conduct the analysis and acquire or interpret useful competitive information. Does not produce innovative solutions or solutions that will produce a sustainable competitive advantage

5.1 Define Business Need To understand what competing organizations are doing - identify opportunities to increase efficiency


To identify solution approaches that have proven effective in other organizations

9.3 Brainstorming A way to foster creative thinking. Aim is to produce numerous new ideas, and to derive themes for further analysis. Best applied in a group as it draws on the experience and creativity of all members. Free association is encouraged

Prepare: define area of interest, determine time limit, identify facilitator and participants, set expectations, establish evalua-tion criteria Session: share ideas without discussion, visibly record ideas Wrap up: evaluate ideas using pre-determined criteria, create condensed list, rank ideas

Ability to elicit many ideas in short time Non-judgmental envi-ronment enables crea-tive thinking Useful during a work-shop to reduce tension


To identify the stakeholders that should be con-sulted during the initiative.

Dependent on participants’ creativity and willingness to participate. Organizational and interper-sonal politics may limit par-ticipation. Group participants must agree to avoid debating ideas.

3.1 Prepare for Elicitation To identify the participants, materials, techniques & resources required


To generate many requirements quickly… through use of creative thinking techniques

3.3 Document Elicitation To document requirements

5.1 Define Business Need To generate insights and options


To generate solution alternative









9.4 Business Rule Analysis To define the rules that govern deci-sions in an organization and that define, constrain, or enable organ-izational operations. Business policy: a non-actionable directive that supports a business goal. Business rule: a specific, actionable, testable directive that is under the control of an organization and that supports a business policy.

Operative Rules: enforced as a matter of policy. They guide people’s actions. It must be possible to violate Structural Rules: categorizations that may change over time. Something that is true or false. They can not be violated

Clearly defined rules enable: changes policy without alter-ing processes Assess impact to change in business rule is easier when documented separately from the business process

Lengthy lists of rules that can contradict each other

Need to question existing rules for relevance

5.1 Define Business Need To identify changes in the organizational policies to achieve goals

6.2 Organize Require-ments

To group requirements according to different busi-ness rules


To identify the rules that will form the requirements

7.2 Allocate Requirements To identify which business rules will be performed manually or by a system—and at which release


To identify new business rules that may be required to assist with the migration of the data—or manage work that is migrated

9.5 Data Dictionary & Glossary Defines key terms and data relevant to a business domain.

Glossary: terms unique to a domain Data Dictionary: standard definitions of data elements and meanings: Primitive Elements (Name,

Alias, Value/Meaning, De-scription)

Composite Elements (Sequences, repetition, optional)

Useful for ensuring that all stakeholders are in agree-ment on the format and content of relevant informa-tion. Ensures that these terms will be used consistently

3.2 Conduct Elicitation Activities

To provide common terms and facilitate under-standing during elicitation activities.


To identify the terms and the definitions that will form the basis of the solution.

9.6 Data Flow Diagrams A visual representation of how infor-mation is moved through a system. External entities, processes that transform data, data sores and data flows

External Entities Data Store Data Process Data Flow

May be used as a discovery technique or as a technical verification Easy to understand Useful analysis deliverable to developers in a structured environment

Can not show who is responsi-ble for performing the work Can not show alternate paths


To show how information flows through the system. 6.3 Specify and Model Requirements

7.3 Assess Org Readiness To identify those activities that will change with the implementation of a new solution


To analyze and determine difference between cur-rent and end-state models.

9.7 Data Modeling A diagram supported by textual descriptions that describes the con-cepts relevant to a domain, the relationships between those con-cepts, and information associated with them (ERD & class diagram)

Concept: entities Attributes (Name, Value/Meanings) Relationship: business associa-tions between concepts Metadata: data about data

Different levels of description Consistent approach through planning, analysis, design, and implementation Supported by rigorous rules for correctness & complete-ness

Can be complex May be difficult for people without IT background


To describe concepts and relationships relevant to the solution and domain



To determine the difference between current and end-state models.









9.8 Decision Analysis An approach to decision-making that examines and models the possi-ble consequences of different deci-sions Effective decision analysis requires that the analyst understand: 1) The values, goals and objectives

that are relevant to the decision problem

2) The nature of the decision that must be made

3) The areas of uncertainty that affect the decision

4) And the consequences of each possible decision

1) Outcomes Financial Analysis:

DCF: Discounted Cash Flow

NPV: Net Present Value

IRR: Internal Rate of Return

ARR: Average Rate of Return

PB: Payback Period

CBA: Cost Benefit Analysis Non Financial Outcomes

2) Uncertainty 3) Tradeoffs

Elimination of dominated alternatives Ranking objectives on similar scale

An effective technique to determine the expected value Provides decision makers with quantitative measures upon which to make project investment decisions. Forces stakeholders to assess the importance of alternatives.

Required specialized knowl-edge and skill Results of analysis may be treated as more certain than they are (need to understand limitations) May be reluctant to revisit decisions

2.1 Plan BA Approach To evaluate different techniques according to organizational needs & objectives

2.5 Plan Req Mgmt Proc-ess

To evaluate value proposed by change—to iden-tify areas of uncertainty


To rank and select possible solution approaches

5.5 Define Business Case To evaluate the costs, benefits, risks and prob-abilities of the solution

6.1 Prioritize Require-ments

To support the ranking of requirements

7.1 Assess Proposed Solution

To support the assessment and ranking of solu-tions

7.2 Allocate Requirements To estimate the value associated with different allocation decisions

7.6 Evaluation Solution Performance

To determine the impact of the solution.

9.9 Document Analysis Elicit requirements by studying avail-able documentation on existing and comparable solutions and identifying relevant information

Preparation Document review (read material, document details, pose questions) Wrap up (review and confirm with SME, organize into requirement format, obtains answers to ques-tions

Leveraging existing material A means to cross-check requirements from other techniques

Limited to as-is Existing docs may not be up to date Can be time-consuming and tedious

3.1 Prepare for Elicitation To prepare for requirements elicitation. Identify stakeholders. Understand issues.


To gain insights into business processes and re-quirements


To extract & document requirements

5.2 Assess Capability Gaps

To understand the current state of the enterprise

9.10 Estimation Forecast the possible range of cost and effort involved in pursuing a course of action.

Analogous estimation Parametric estimation Bottom-up estimation Rolling wave estimation Three-point estimation Historic analysis Expert judgment Delphi estimation

Can help stakeholders make better decisions based upon improved un-derstanding of the likely outcome from an initiative

Stakeholders treat estimates as commitments Estimates may be altered to match the desires of influential stakeholders

2.3 Plan BA Activities To estimate the amount of time/resources required to complete the BA Activities.


To develop initial cost comparison of possible solutions

5.5 Define Business Case To forecast the size of the investment required to deploy and operate the solution.









9.11 Focus Groups A means to elicit ideas and attitudes about a specific product, services or opportunity in an interactive group environment. A group of pre-qualified individuals meeting Qualitative research Can be used during any stage of life-cycle

1) Preparation Recruit participants (homogenous, heteroge-neous) Assign the moderator and recorder Create discussion guide Reserve site and services

2) Run the focus group ses-

sion 3) Produce the report

Saves time and cost over conducting individual inter-views Effective for learning peo-ple attitudes, experiences and desired Active discussion and ques-tions allow others to con-sider different perspectives

Some may not be willing to discuss sensitive topics What people say may not be consistent with how people behave If group is too homogene-ous may not represent all requirements Need a skilled moderator Difficult to schedule Not effective to evaluate usability

3.1 Prepare for Elicitation To identify a list of the stakeholders to participate and a list of topics to discuss during elicitation


To provide opportunity to identify requirements in an casual setting


Results of the meeting are documented/summarized, and shared.

5.1 Define Business Need To identify and discuss problems

7.3 Assess Org Readiness To identify affected stakeholders and their interests


To gain qualitative feedback on the value of the solution for stakeholders

9.12 Functional Decomposition Decompose processes, functional ar-eas, or deliverables into their compo-nent parts and allow each part to be analyzed independently Ensure that the problem is separated into sub-problems that are as inde-pendent as possible, so that work can be assigned to different groups

Decomposition A conceptual model of work that need to be com-pleted Provides a consistent view of scope of effort Assists estimating. Estimates can be made for smaller, more comprehensible sets

No way to be certain that all components have been captured Decomposing a problem without understanding the relationships can create an inappropriate structure

2.3 Plan BA Activities To decompose tasks or products to facilitate understand-ing of the work at a sufficient level to enable estimation of tasks

5.1 Define Business Need To convert business goals into achievable objectives and measures

5.4 Define Solution Scope To break the solution scope into smaller work products or deliverable

6.2 Organize Require-ments To break down an organizational unit, product scope or

similar into it’s component parts 6.3 Specify and Model Requirements

7.2 Allocate Requirements To break down solution scope into smaller components for allocation

9.13 Interface Analysis Identify interfaces between solutions and/or solution components. Define requirements that describe how they will interact. Interfaces include: 1) User interfaces 2) Interface to/from external applica-

tions 3) Interfaces to/from external hardware

1) Prepare for interface iden-tification

2) Conduct interface identifi-

cation: Describe purpose of interface Identify type of interface appropriate Elicit high level details about interface

3) Define interfaces

Early identification of inter-faces provides early, high level view of interoperability Impacts delivery date Collaboration with other systems or projects Specification of the inter-face should prevent difficul-ties in integration

Does not provide insight into other aspects of the solution since analysis does not assess internal compo-nents.

3.1 Prepare for Elicitation To identify a list of stakeholders to participate.


To identify opportunities for change


To report of the findings

5.4 Define Solution Scope To identify the scope of work required to integrate new solution into the environment


To break the interface scope into constituent parts/interfaces









9.14 Interviews A systematic approach designed to elicit information from a person or group of people in an informal or formal setting by talking to an inter-viewee, asking relevant questions and documenting the responses. Structured or unstructured Successful interviews depend upon: understanding the domain, experi-ence of interviewer, skill in docu-menting discussion, readiness of interviewee to provide info, degree of understanding of business re-quirements, rapport

1) Prepare for the interview Identify potential interviewees Design the interview Contact potential interviewees

2) Conduct the interview

Opening the interview During the interview Closing the interview

3) Post interview follow-up and

confirmation

Encourages participation Establishes rapport Allows full discussion and explanation Observation of non-verbal behaviour Interviewer can ask follow-up and probing questions Allows interviewees to express opinions in private that they may be reluctant to express in public

Difficult to reach consensus across a group of stakeholders Considerable involvement Training is required to conduct effective interviews Depth of follow-on questions de-pendent on interviewers knowledge of business domain Transcription and analysis of inter-view data can be complex & expen-sive Interview results subject to interview-ers interpretation Risk of unintentionally leading the interviewee


To identify the stakeholders for the initia-tive— those that may be interviewed for requirements


To identify stakeholders to be interviewed to collect input into BA performance

3.1 Prepare for Elicitation To gather insight into stakeholders to participate and topic for discussion.


To collect requirements through speaking directly with an individual


To document interview results and related requirements


To review, discuss, and confirm the re-quirements that have been documented


9.15 Lessons Learned Process To compile and document suc-cesses, opportunities for improve-ment, failures, and recommenda-tions for improving the performance of future projects or project phases.

Review of business analysis activi-ties, process, deliverables, the final product, technology used (not-used), managerial concerns/issues, organizational assets, performance against plan, variances, corrective and/or preventative actions recom-mended, approved, rejected, or taken

Can identify opportunities for process improvement Can help build team morale

Must be prepared to avoid the urge to assign blame May be reluctant to document and discuss problems May become a gripe session.


To identify the changes that will be made in the next iteration of the process.

9.16 Metrics & KPI To measure the performance of solutions, solution components, and other matters of interest to stake-holders. A metric is a quantifiable level of an indicator that an organization uses to measure progress at a specific point in time (Sales in Jan). An indicator identifies a specific numerical measurement (Sales) that represents the degree of progress toward achieving a goal (Industry Leader).

1) Indicators: Characteristics in-clude clear, relevant, economi-cal, adequate, quantifiable, stakeholder interests, proxies, source, method of collection, collector, cost, frequency, diffi-culty, secondary sources

2) Metrics 3) Structure: 3 factors to assessing

quality of indicators : reliability, validity, timeliness

4) Reporting: compare baseline to

current, rends, visual presenta-tion

Allows stakeholders to under-stand the extent to which a solution meets an objective Facilitate organizational align-ment, linking goals to objec-tives, supporting solutions, underlying tasks & resources

Can result in unnecessary expense Can distract project members for other responsibilities May collect too much data, without generating useful reports


To define the metrics by which perform-ance will be measured.

5.5 Define Business Case

To define the metrics by which the project will be measured and evaluated


6.6 Validate Requirements To select appropriate metrics to measure the solution, component, or requirement









9.17 Non-functional Requirements Analysis To describe the required qualities of a system, such as its usability and per-formance characteristics. Important to user and development community

1) Category: reliability, per-formance efficiency, oper-ability, security, compatibil-ity, maintainability, transfer-ability

2) Measurement 3) Documentation

Success in meeting non-functional requirements will have a strong influence on whether or not a system is accepted by its users.

Often more difficult to define than functional requirements. Expectations regarding quality attrib-utes may not be described. Users of an application may find them difficult to articulate


To identify requirements f or the solution

9.18 Observation A means of eliciting requirements by conducting an assessment of the stake-holder’s work environment. Two techniques: 1) Passive/Invisible 2) Active/Visible Variations

1) Prepare for the Observation Determine sampling Prepare questions

2) Observe Introduction Conduct observation

3) Post Observation Wrap up Provide summary notes

Provides realistic and practi-cal insight into the business Elicits details of informal communication

Only possible for existing processes. Can be time-consuming. May be disruptive to the person being shadowed. Unusual exceptions and critical situa-tions that happen infrequently may not occur during the observation. May not well work if the current process involves a high level of intel-lectual activity or other work that is not easily observable.

3.1 Prepare for Elicitation To identify stakeholders in the project


To collect requirements that may be easier to obtain by watching


To document results of the observation.


To validate requirements by observing employees perform the task.


To identify issues that have not been reported

9.19 Organization Modeling To describe the roles, responsibilities and reporting structures that exist within an organization and to align those structures with the organization’s goals.

1) Organizational purpose & structure: functions, markets, Matrix

2) Roles 3) Interfaces 4) Org Charts:

Units, Lines of Reporting, Roles & People

Every organization should have one

Organizational redesign is high contentious and requires significant executive support Informal lines of authority and com-munication are not reflected in the org chart


To identify the stakeholders for the initiative— those that may be impacted by the change


To document requirements in a manner that meets the needs of the various stakeholder groups.


To recognize that organizational structure may influence the design of the model

7.3 Assess Org Readiness To identify stakeholders are affected by the change implementation of a new solution


To determine difference between current and end-state models.









9.20 Problem Tracking An organized approach to tracking, management, and resolution of de-fects, issues, problems, and risks throughout business analysis activities Problems may include issues, ques-tions, risks, defects, conflicts, or other concerns that need to be tracked to resolution

Problem Record (description, raised by, date identified, impact, priority, date needed by, owner, status, action needed to resolve, responsible for action, complete date of action, outcome) Problem Management Metrics (number of problems by status and priority, age of each problem)

An organized method for tracking and resolving risks, issues and defects. A mechanism to com-municate problems across the team and helps to maintain focus on open problems until they are resolved.

If prioritization and manage-ment is not done on a regu-lar basis, the list becomes outdated and irrelevant. If key team members are not available to discuss the lists and to take action, progress to resolve them may become very slow. If there is a strict deadline to deliver the solution, then problem management may become a lower priority.

2.5 Plan Req Mgmt Process To chart possible changes in requirements and ensure that changes are met


To track issues identify during the review and ensure they are resolved.

3.3 Document Elicitation Results To track issues identified during elicitation and ensure that they are resolved.

4.1 Manage Soln Scope & Req To manage issues identified with requirements and ensure they are resolved

6.4 Define Assumptions & Con-straints

To identify assumptions and constraints—and monitor/manage these through problem/issue/risk management.

6.5 Verify Requirements To ensure that problems identified are resolved.

7.3 Assess Org Readiness To ensure that issues identified with organizational readi-ness are resolved

7.5 Validate Solution To ensure that defects identified are resolved

9.21 Process Modeling To understand how work that involves multiple roles and departments is performed within an organization Flowchart Swim lane Activity Diagram

1) Notational Elements: Activities, decisions, events, flow, roles, swim lanes & pools, terminal points

2) Process Improvement:

Six Sigma Lean, BPM, value streaming, Statistical analysis benchmarking

3) Common Changes:

remove non-value-add activities Reduce time required by task Improve interface Reduce bottlenecks

Most stakeholders are comfortable with basic concepts in model Effective at showing a large number of scenar-ios/branches Likely to have value in their own right as they can be used by stake-holders for training and coordination

Can become extremely com-plex Problems in process can not always be identified by look-ing at the model

2.1 Plan BA Approach To define and document the BA Approach

2.2 Conduct Stakeholder Analysis To identify stakeholders for defining new business model


To define existing processes and identify potential im-provements.

6.2 Organize Requirements To group requirements around relevant processes

6.3 Specify and Model Require-ments

To assists in modelling the requirements

7.2 Allocate Requirements To influence allocation of requirements to different re-leases or outsourced to different suppliers

7.3 Assess Org Readiness To identify those activities that will change with the imple-mentation of a new solution

7.4 Define Transition Requirements To determine difference between current and end-state models.









9.22 Prototyping Prototyping details user interface requirements and integrates them with other requirements such as use cases, scenarios, data and business rules Two categorizations: 1) Functional Scope: Horizontal

vs Vertical 2) Usage: Throw-away vs evolu-

tionary or Functional

1) Prepare for prototyping: determine approach, identify function

2) Build the prototype: an

iterative process, story-boards, screen proto-types/ layout/ mockup

3) Evaluate the prototype

Supports users who are more comfortable “seeing” the future systems interface. Encourages early user interaction and feed-back. A prototype is an inex-pensive means to quickly uncover/confirm requirements

Eliciting requirements may be time consuming if process defines how’s rather than what’s. Assumptions about underlying technology need to be made May lead users to unre-alistic expectations. May focus on design specifications rather than requirements

3.1 Prepare for Elicitation To understand issue and identify topics for elicitation


To provide inspiration of what they need/want and project require-ments.


To capture results of elicitation directly via a prototype, rather than via documentation

6.3 Specify and Model To identify and model requirements in a manner that is easy to

6.6 Validate Requirements To gain agreement to the proposed solution prior to full implemen-tation

9.23 Requirements Workshops A structured way to capture re-quirements. A workshop may be used to scope, discover, define, prioritize and reach closure on requirements for the target system. One of the most effective ways to deliver high quality requirements quickly. They promote trust & understanding. May be used to generate ideas, review requirements or reach consensus

1) Prepare for workshop: identify stakeholders, define agenda, schedule, logistics, send materials, pre-workshop interviews

2) Conduct the workshop:

elicit, analyze, document requirements, obtain con-sensus

3) Post requirement workshop

wrap up: follow up on action items, distribute documentation

Means to elicit detailed requirements in a short period of time. Means for stakeholder to collaborate, make decisions, develop mu-tual understanding Cost lower than several individual interviews Feedback is immediate

Stakeholder availability may be difficult Success is highly de-pendent upon expertise of the facilitator and knowledge of the par-ticipants. Too few or too many participants can affect results.


To identify additional stakeholders.

3.1 Prepare for Elicitation To identify issues/stakeholders/topics for subsequent workshops


To elicit requirements from a large number of people in a short period of time.


To create artefacts for further analysis.

4.5 Communicate Re-quirements

To familiarize stakeholders with the requirements

9.24 Risk Analysis To identify and manage areas of uncertainty that can impact an initiative, solution, or organization. May be positive or negative

1) Risk Tolerance: Risk Aversion neutrality risk seeking

2) Assessment 3) Response (for negative

risk): Acceptance Transfer Avoidance Mitigation (For positive risk): Acceptance Share Enhance Exploit

Enables an organization to prepare for some-things that will not go as planned

Number of possible risks can become unman-ageably large May be difficult to esti-mate impact of risk


To identify risks may result from stakeholder attitudes, or inability to participate.

2.3 Plan BA Activities To asses the risks associated with different approaches.

2.5 Plan Req Mgmt Proc-ess

To identify risks associated with the req mgmt process and risks associated with making or choosing not to make the change.

5.5 Define Business Case To assess the risks, costs, and benefits associated with the solution

6.1 Prioritize Require-ments

To understand that the risk associated with a requirement can influ-ence the order in which they are developed.

6.4 Define Assumptions & Constraints

To assess the risk should an assumption prove to be false or a con-straint is removed.

6.6 Validate Require-ments

To identify scenarios that would alter the expected value delivered by a requirement

7.3 Assess Org Readiness To assess risks and determine mitigation strategies









9.25 Root Cause Analysis A structured examination to deter-mine the underlying source of a problem. Current business thinking and proc-esses are challenged

Fishbone (Ishikawa, Cause & Ef-fect) Five Whys

A structured method to identify the root causes, ensuring complete understand-ing

Works best when facili-tated by someone with formal training. Facilitator must remain objective

2.6 Manage Business Analysis Performance To identify the underlying source of delivery problem.

5.1 Define Business Need To determine the underlying source of problem.

7.5 Validate Solution To ensure that the underlying cause of the defect is resolved and the outstanding issue is resolved

9.26 Scenarios & Use Cases To describe how an actor interacts with a solution to accomplish one or more goals. Or to respond to an event Scenario: one way to accomplish a goal A Use Case: all possible outcomes of an attempt to accomplish a goal Primary and alternate flows

Name Actors: a person, system or event external to the system. Temporal events Preconditions Flow of Events Post-conditions Relationships: Extend, include

Good at clarifying scope and providing high level understand-ing

Temptation to describe all requirements using use cases, even when not appropriate Does not facilitate discov-ery of common elements. Additional design is often required


To assist in identification of stakeholders

6.2 Organize Requirements To group the requirements according to the actors and use cases

6.3 Specify and Model Re-quirements

To group requirements and document requirements according to use cases and scenarios

7.2 Allocate Requirements To facilitate allocation, alternative flows can be sepa-rated from the base use case and assigned to later releases

9.27 Scope Modeling To describe the scope of analysis or the scope of a solution

Context diagram Events Features Use Case Diagram Business Process

Will make it easier to determine what is in/out of scope

Leaves much of the de-tailed scope needing to be investigated


To identify key stakeholders

5.4 Define Solution Scope To identify boundaries for the solution scope

6.2 Organize Requirements To group requirements according to the solution com-ponent that they are associated with

9.28 Sequence Diagrams Used to model the logic of usage scenarios, by showing the informa-tion passed between classes & ob-jects in the system through the exe-cution of the scenario.

Two Types: 1) Procedural 2) Asynchronous (signal)

May be used in object-oriented analysis to validate class dia-grams, against use cases, or to show the timing of interactions between entities within the system scope

A diagram must be de-fined for each possible scenario.


To understand the flow of communication between processes helps to define system requirement

9.29 State Diagrams Specifies a sequence of states that an object goes through during its lifetime, and defines which events cause a transition between those states.

States Transitions

Domain SMEs have deep knowledge of states & lifecycle

Easy to unintentionally expand scope


To provide insights into the flow of a system—defining and modelling requirements for transition.









9.30 Structure Walkthrough Is a working session where invited participants review, verify, and validate require-ments

1) Prerequisites: A complete requirements pkg List of reviewers (who are knowledgeable) A meeting vehicle

2) Process

Review Scope Organize and Schedule Conduct the Review Compile Notes & Results Re-review if necessary

3) Rules to be followed during

Promotes discussion Effective at identifying ambiguity and misunderstanding

2.1 Plan BA Approach To review the BA approach with others—collect and incorporate their feedback

Can lead to repeated revisions if changes are not carefully managed Can be a lengthy approval process 2.4 Plan BA Communica-

tion To review the strategy for communications

4.5 Communicate Re-quirementsT To review the requirements

6.5 Verify Requirements To inspect requirements, to identify ambiguous and requirements

6.6 Validate Requirements To confirm that stakeholders agree that their needs are met

9.31 Survey Questionnaire A means of eliciting informa-tion from many people, some-times anonymously, in a rela-tively short period of time Closed or Open-ended

Prepare Distribute the survey Document survey results

Closed-ended questions can be effective for obtaining quantita-tive data for use in statistical analysis. Open-ended questions may yield insights and opinions not easily obtainable through other tech-niques. Does not require significant time from responders Effective and efficient when stakeholders are not located in one location. May result in large number of responses. Quick and relatively inexpensive to administer.

Open-ended questions require more analysis To achieve unbiased results, require specialize skill in statistical sampling Some questions may be unan-swered due to ambiguity May require follow up questions Not suited for obtaining info an actual behaviour Response rate is often too low for statistical significance.


To identify stakeholders


To collect performance feedback from a large number of stakeholders

3.1 Prepare for Elicitation To identify stakeholders, issues, and related back-ground information for elicitation


To elicit requirements from individuals where other methods are not feasible


To collate and summarized



To collect qualitative and quantitative feedback from a large number of stakeholders regarding the performance of the solution

9.32 SWOT Analysis A framework for strategic plan-ning, opportunity analysis, competitive analysis, business and product development Tool to quickly analyze various aspects of the current state of the business process undergo-ing change

Draw grid SWOT is an acronym for Strengths, Weaknesses, Op-portunities, and Threats

Helps quickly analyze various aspects of the current state of the organization and its environment prior to identifying potential solution options.

Very high-level view; more detailed analysis is almost always needed 5.2 Assess Capability

Gaps To identify how current capabilities and limitations compare against the influencing factors


To compare possible approaches

5.5 Define Business Case To demonstrate how the solution will maximize strengths and minimize threats

7.3 Assess Org Readiness To assess strategies for developing with issues









9.33 User Stories A brief description of functionality that users need from a solution to meet a business objective

Actor Description Benefit

Create an environment of cus-tomer ownership of features and prioritizations in an incremental, iterative development environ-ment

May not be the best technique for some environments with regulatory restrictions or when an organization mandates docu-mentation May not be effective when par-ticipants are not co-located Does not explicitly address how to document non-functional requirements


To identify stakeholders

5.4 Define Solution Scope

To describe stakeholders and the goals the system supports


To group requirements according to the stories that they relate to


To identify the data and flow of a business system to be modelled

9.34 Vendor Assessment Assess the ability of a potential ven-dor to meet commitments regarding a product or service

Knowledge & Expertise Licensing & Pricing Models Product Reputation & Market Posi-tion Terms & Conditions Vendor Experience & Reputation Vendor Stability

Effective vendor assessment reduces the risk of the organiza-tion developing a relationship with an unsuitable vendor and is likely to improve long-term satis-faction with the decision.

Can be time-consuming Some information may not be readily available Vendors with new and innovative products may score poorly be-cause they do not have a signifi-cant history in the market

5.5 Define Business Case When a solution involves outsourcing, take time to assess the vendor. It is impor-tant that the parties have a healthy working relationship 7.1 Assess Proposed

Solution







Supplemental Techniques


Baselining 4.1 Manage Soln Scope & Req

To be able to track changes in the requirements.

Checklists 6.5 Verify Requirements To identify the set of criteria that a requirement must meet.

Coverage Matrix 4.2 Manage Req Trace-ability

To trace requirements upwards and downwards

Feasibility Analysis 5.3 Determine Solution Approach

To evaluate the expected benefit of the solution

MoSCoW Analysis

6.1 Prioritize Requirements To categorize requirements into four types to assist with prioritiza-tion (Must, Should, Could Won’t)

Problem or Vision Statement 5.4 Define Solution Scope

To state the business need, identify the stakeholders, and de-scribe the expected benefits

RACI Matrix 2.2 Conduct Stakeholder Analysis

To identify various stakeholders, their interests, as well as their responsibility, accountability, and participation in the solution.

Requirements Documentation 4.4 Prepare Requirements Package

To capture requirements in a formal document—structure de-pendent upon approach

Requirements for Vendor Selection RFI: Request for Information RFQ: Request for Quote

4.4 Prepare Requirements Package

To capture requirements to be met by a 3rd party vendor

Sign Off 4.1 Manage Soln Scope & Req

To formalize agreement by stakeholders that the content and presentation is accurate and complete.

Stakeholder Map 2.2 Conduct Stakeholder Analysis

To illustrate relationships between various stakeholders.

Time boxing / Budgeting All In — All Out — Selective 6.1 Prioritize Requirements

To prioritize requirements based up allocation of fixed re-sources—how much work the team can deliver in a fixed period of time/money

Variance Analysis 2.6 Manage Business Analysis Performance

To analyze the difference between planned and actual results. Determine if preventative or correction action are required

Voting

6.1 Prioritize Requirements To prioritize requirements based upon distribution of token. Whichever requirements receive the most votes proceed to imple-mentation







Business Analysis Techniques by Knowledge Area

9.01 Acceptance & Evaluation Criteria Definition

9.09 Document Analysis 9.20 Problem Tracking 9.08 Decision Analysis 9.08 Decision Analysis 9.08 Decision Analysis

9.03 Brainstorming 9.11 Focus Groups 9.23 Requirements Workshops 9.09 Document Analysis 9.12 Functional Decomposition 9.11 Focus Groups

9.08 Decision Analysis 9.13 Interface Analysis 9.30 Structure Walkthrough 9.10 Estimation 9.16 Metrics & KPI 9.12 Functional Decomposi-

tion

9.10 Estimation 9.14 Interviews 9.11 Focus Groups 9.17 Non-functional Require-

ments Analysis 9.14 Interviews

9.12 Functional Decomposition 9.18 Observation 9.12 Functional Decomposition 9.19 Organization Modeling 9.18 Observation

9.14 Interviews 9.20 Problem Tracking 9.13 Interface Analysis 9.20 Problem Tracking 9.19 Organization Modeling

9.15 Lessons Learned Process 9.22 Prototyping 9.16 Metrics & KPI 9.21 Process Modeling 9.20 Problem Tracking

9.16 Metrics & KPI 9.23 Requirements Work-

shops 9.24 Risk Analysis 9.22 Prototyping 9.21 Process Modeling

9.19 Organization Modeling 9.31 Survey Questionnaire 9.25 Root Cause Analysis 9.24 Risk Analysis 9.24 Risk Analysis

9.20 Problem Tracking 9.27 Scope Modeling 9.26 Scenarios & Use Cases 9.25 Root Cause Analysis

9.21 Process Modeling 9.32 SWOT Analysis 9.27 Scope Modeling 9.26 Scenarios & Use Cases

9.23 Requirements Workshops 9.33 User Stories 9.28 Sequence Diagrams 9.31 Survey Questionnaire

9.24 Risk Analysis 9.34 Vendor Assessment 9.29 State Diagrams 9.32 SWOT Analysis

9.25 Root Cause Analysis 9.30 Structure Walkthrough 9.34 Vendor Assessment

9.26 Scenarios & Use Cases 9.33 User Stories

9.27 Scope Modeling

9.30 Structure Walkthrough

9.31 Survey Questionnaire

9.33 User Stories

RACI Matrix Baselining Feasibility Analysis

Stakeholder Map Coverage Matrix Problem or Vision Statement

Variance Analysis Requirements Documentation

Requirements for Vendor Selection

Sign Off