Download Business Analysis for Practitioners: A Practice Guide PDF

TitleBusiness Analysis for Practitioners: A Practice Guide
Author
LanguageEnglish
File Size4.7 MB
Total Pages289
Table of Contents
                            Title Page
Copyright Page
Notice
Table of Contents
List of Tables and Figures
Preface
1. Introduction
	1.1. Purpose of this Practice Guide
	1.2. Need for this Practice Guide
	1.3. PMI's Increased Focus on Business Analysis
	1.4. Intended Audience for the Guide
	1.5. What is Business Analysis?
	1.6. Who Performs Business Analysis?
		1.6.1. Skillset and Expertise Needed for the Business Analysis Role
		1.6.2. How Organizations Implement Business Analysis
		1.6.3. The Relationship between the Project Manager, Business Analyst, and other Roles
		1.6.4. The Need to Build the Relationships
	1.7. Definition of Requirement
		1.7.1. Who has the Responsibility for the Requirements?
		1.7.2. Requirement Types
	1.8. The Structure of the Practice Guide
		1.8.1. Section 2 on Needs Assessment
		1.8.2. Section 3 on Business Analysis Planning
		1.8.3. Section 4 on Requirements Elicitation and Analysis
		1.8.4. Section 5 on Traceability and Monitoring
		1.8.5. Section 6 on Solution Evaluation
2. Needs Assessment
	2.1. Overview of this Section
	2.2. Why Perform Needs Assessments
	2.3. Identify Problem or Opportunity
		2.3.1. Identify Stakeholders
		2.3.2. Investigate the Problem or Opportunity
		2.3.3. Gather Relevant Data to Evaluate the Situation
		2.3.4. Draft the Situation Statement
		2.3.5. Obtain Stakeholder Approval for the Situation Statement
	2.4. Assess Current State of the Organization
		2.4.1. Assess Organizational Goals and Objectives
			2.4.1.1. Goals and Objectives
			2.4.1.2. SMART Goals and Objectives
		2.4.2. SWOT Analysis
		2.4.3. Relevant Criteria
		2.4.4. Perform Root Cause Analysis on the Situation
			2.4.4.1. Five Whys
			2.4.4.2. Cause-And-Effect Diagrams
		2.4.5. Determine Required Capabilities Needed to Address the Situation
			2.4.5.1. Capability Table
			2.4.5.2. Affinity Diagram
			2.4.5.3. Benchmarking
		2.4.6. Assess Current Capabilities of the Organization
		2.4.7. Identify Gaps in Organizational Capabilities
	2.5. Recommend Action to Address Business Needs
		2.5.1. Include a High-Level Approach for Adding Capabilities
		2.5.2. Provide Alternative Options for Satisfying the Business Need
		2.5.3. Identify Constraints, Assumptions, and Risks for Each Option
			2.5.3.1. Constraints
			2.5.3.2. Assumptions
			2.5.3.3. Risks
		2.5.4. Assess Feasibility and Organizational Impacts of Each Option
			2.5.4.1. Operational Feasibility
			2.5.4.2. Technology/System Feasibility
			2.5.4.3. Cost-Effectiveness Feasibility
			2.5.4.4. Time Feasibility
			2.5.4.5. Assess Factors
		2.5.5. Recommend the Most Viable Option
			2.5.5.1. Weighted Ranking
		2.5.6. Conduct Cost-Benefit Analysis for Recommended Option
			2.5.6.1. Payback Period (PBP)
			2.5.6.2. Return on Investment (ROI)
			2.5.6.3. Internal Rate of Return (IRR)
			2.5.6.4. Net Present Value (NPV)
	2.6. Assemble the Business Case
		2.6.1. Value of the Business Case
3. Business Analysis Planning
	3.1. Overview of this Section
	3.2. The Importance of Business Analysis Planning
		3.2.1. Rationale
		3.2.2. Business Analysis Planning and Project Management Planning
	3.3. Conduct or Refine the Stakeholder Analysis
		3.3.1. Techniques for Identifying Stakeholders
			3.3.1.1. Brainstorming
			3.3.1.2. Organizational Charts
		3.3.2. Determine Stakeholder Characteristics
			3.3.2.1. Attitude
			3.3.2.2. Complexity
			3.3.2.3. Culture
			3.3.2.4. Experience
			3.3.2.5. Level of Influence
			3.3.2.6. Location and Availability
		3.3.3. Techniques for Grouping or Analyzing Stakeholders
			3.3.3.1. Job Analysis
			3.3.3.2. Persona Analysis
		3.3.4. Assemble the Stakeholder Analysis Results
	3.4. Create the Business Analysis Plan
		3.4.1. Business Analysis Plan vs. Requirements Management Plan
		3.4.2. What to Include in the Business Analysis Plan
			3.4.2.1. Determining the Proper Level of Detail
		3.4.3. Understand the Project Context
		3.4.4. Understand how the Project Life Cycle Influences Planning Decisions
		3.4.5. Ensure the Team is Trained on the Project Life Cycle
		3.4.6. Leverage Past Experiences when Planning
			3.4.6.1. Lessons Learned
			3.4.6.2. Retrospectives
		3.4.7. Plan for Elicitation
			3.4.7.1. Strategies for Sequencing Elicitation Activities
		3.4.8. Plan for Analysis
		3.4.9. Define the Requirements Prioritization Process
		3.4.10. Define the Traceability Approach
		3.4.11. Define the Communication Approach
		3.4.12. Define the Decision-Making Process
		3.4.13. Define the Requirements Verification and Validation Processes
		3.4.14. Define the Requirements Change Process
		3.4.15. Define the Solution Evaluation Process
	3.5. Plan the Business Analysis Work
		3.5.1. Determine who Plans the Business Analysis Effort
		3.5.2. Build the Business Analysis Work Plan
			3.5.2.1. Identify the Deliverables
			3.5.2.2. Determine the Tasks and Activities
			3.5.2.3. Determine the Timing and Sequencing of Tasks
			3.5.2.4. Determine the Roles and Responsibilities
			3.5.2.5. Identifying the Resources
			3.5.2.6. Estimate the Work
		3.5.3. Assemble the Business Analysis Work Plan
		3.5.4. Document the Rationale for the Business Analysis Approach
		3.5.5. Review the Business Analysis Plan with Key Stakeholders
		3.5.6. Obtain Approval of the Business Analysis Plan
4. Requirements Elicitation and Analysis
	4.1. Purpose of this Section
	4.2. What it Means to Elicit Information
		4.2.1. Elicitation is More than Requirements Collection or Gathering
		4.2.2. Importance of Eliciting Information
	4.3. Plan for Elicitation
		4.3.1. Develop the Elicitation Plan
			4.3.1.1. Finding Information
			4.3.1.2. Techniques for Eliciting Information
			4.3.1.3. Sequencing the Elicitation Activities
	4.4. Prepare for Elicitation
		4.4.1. Determine the Objectives
		4.4.2. Determine the Participants
		4.4.3. Determine the Questions for the Session
	4.5. Conduct Elicitation Activities
		4.5.1. Introduction
		4.5.2. Body
			4.5.2.1. Types of Questions
			4.5.2.2. How to Ask the “Right” Questions
			4.5.2.3. Listening
		4.5.3. Close
		4.5.4. Follow-Up
		4.5.5. Elicitation Techniques
			4.5.5.1. Brainstorming
			4.5.5.2. Document Analysis
			4.5.5.3. Facilitated Workshops
			4.5.5.4. Focus Groups
			4.5.5.5. Interviews
			4.5.5.6. Observation
			4.5.5.7. Prototyping
			4.5.5.8. Questionnaires and Surveys
	4.6. Document Outputs from Elicitation Activities
	4.7. Complete Elicitation
	4.8. Elicitation Issues and Challenges
	4.9. Analyze Requirements
		4.9.1. Plan for Analysis
			4.9.1.1. Analysis Defined
			4.9.1.2. Thinking Ahead about Analysis
			4.9.1.3. What to Analyze
	4.10. Model and Refine Requirements
		4.10.1. Description of Models
		4.10.2. Purpose of Models
		4.10.3. Categories of Models
		4.10.4. Selection of Models
		4.10.5. Use Models to Refine Requirements
		4.10.6. Modeling Languages
		4.10.7. Scope Models
			4.10.7.1. Goal Model and Business Objective Model
			4.10.7.2. Ecosystem Map
			4.10.7.3. Context Diagram
			4.10.7.4. Feature Model
			4.10.7.5. Use Case Diagram
		4.10.8. Process Models
			4.10.8.1. Process Flow
			4.10.8.2. Use Case
			4.10.8.3. User Story
		4.10.9. Rule Models
			4.10.9.1. Business Rules Catalog
			4.10.9.2. Decision Tree and Decision Table
		4.10.10. Data Models
			4.10.10.1. Entity Relationship Diagram
			4.10.10.2. Data Flow Diagrams
			4.10.10.3. Data Dictionary
			4.10.10.4. State Table and State Diagram
		4.10.11. Interface Models
			4.10.11.1. Report Table
			4.10.11.2. System Interface Table
			4.10.11.3. User Interface Flow
			4.10.11.4. Wireframes and Display-Action-Response
	4.11. Document the Solution Requirements
		4.11.1. Why Documentation is Important
		4.11.2. Business Requirements Document
		4.11.3. The Solution Documentation
			4.11.3.1. Requirements
			4.11.3.2. Categorization
		4.11.4. Requirements Specification
			4.11.4.1. Documenting Assumptions
			4.11.4.2. Documenting Constraints
		4.11.5. Guidelines for Writing Requirements
			4.11.5.1. Functional Requirements
		4.11.6. Prioritizing Requirements
			4.11.6.1. Prioritization Schemes
		4.11.7. Technical Requirements Specification
		4.11.8. Documenting with use Cases
		4.11.9. Documenting with user Stories
		4.11.10. Backlog Items
	4.12. Validate Requirements
		4.12.1. The Concept of Continual Confirmation
		4.12.2. Requirements Walkthrough
	4.13. Verify Requirements
		4.13.1. Peer Review
		4.13.2. Inspection
	4.14. Approval Sessions
	4.15. Resolve Requirements-Related Conflicts
		4.15.1. Delphi
		4.15.2. Multivoting
		4.15.3. Weighted Ranking
5. Traceability and Monitoring
	5.1. Overview of this Section
	5.2. Traceability
		5.2.1. What is Traceability?
		5.2.2. Benefits of Tracing Requirements
		5.2.3. The Traceability Matrix
			5.2.3.1. Requirements Attributes
			5.2.3.2. Traceability Matrix Hierarchy
	5.3. Relationships and Dependencies
		5.3.1. Subsets
		5.3.2. Implementation Dependency
		5.3.3. Benefit or Value Dependency
	5.4. Approving Requirements
		5.4.1. Work Authorization System
		5.4.2. Approval Levels
	5.5. Baselining Approved Requirements
		5.5.1. What is a Requirements Baseline?
		5.5.2. Relationship of Requirements Baseline, Product Scope, and Project Scope
		5.5.3. Maintaining the Product Backlog
	5.6. Monitoring Requirements using a Traceability Matrix
		5.6.1. Benefits of using Traceability to Monitor Requirements
	5.7. The Requirements Life Cycle
	5.8. Managing Changes to Requirements
		5.8.1. Change Management as it Relates to Business Analysis
		5.8.2. Change Control Tools and Techniques
			5.8.2.1. Configuration Management System (CMS)
			5.8.2.2. Version Control System (VCS)
		5.8.3. Impact Analysis
			5.8.3.1. Impact on the Requirements Baseline
			5.8.3.2. Impact on whether a Proposed Change Conflicts with other Requirements
			5.8.3.3. Impact on Business Analysis
			5.8.3.4. Impact on Project Management
			5.8.3.5. Recommending a Course of Action
		5.8.4. Controlling Changes Related to Defects
6. Solution Evaluation
	6.1. Overview of this Section
	6.2. Purpose of Solution Evaluation
	6.3. Recommended Mindset for Evaluation
		6.3.1. Evaluate Early and Often
		6.3.2. Treat Requirements Analysis, Traceability, Testing, and Evaluation as Complementary Activities
		6.3.3. Evaluate with the Context of usage and Value in Mind
		6.3.4. Confirm Expected Values for Software Solutions
	6.4. Plan for Evaluation of the Solution
	6.5. Determine what to Evaluate
		6.5.1. Consider the Business Goals and Objectives
		6.5.2. Consider Key Performance Indicators
		6.5.3. Consider Additional Evaluation Metrics and Evaluation Acceptance Criteria
			6.5.3.1. Project Metrics as Input to the Evaluation of the Solution
			6.5.3.2. Customer Metrics
			6.5.3.3. Sales and Marketing Metrics
			6.5.3.4. Operational Metrics and Assessments
			6.5.3.5. Functionality
		6.5.4. Confirm that the Organization can Continue with Evaluation
	6.6. When and how to Validate Solution Results
		6.6.1. Surveys and Focus Groups
		6.6.2. Results from Exploratory Testing and user Acceptance Testing
		6.6.3. Results from Day-In-The-Life (DITL) Testing
		6.6.4. Results from Integration Testing
		6.6.5. Expected vs. Actual Results for Functionality
		6.6.6. Expected vs. Actual Results for Nonfunctional Requirements
		6.6.7. Outcome Measurements and Financial Calculation of Benefits
	6.7. Evaluate Acceptance Criteria and Address Defects
		6.7.1. Comparison of Expected vs. Actual Results
		6.7.2. Examine Tolerance Ranges and Exact Numbers
		6.7.3. Log and Address Defects
	6.8. Facilitate the Go/No-Go Decision
	6.9. Obtain Signoff of the Solution
	6.10. Evaluate the Long-Term Performance of the Solution
		6.10.1. Determine Metrics
		6.10.2. Obtain Metrics/Measure Performance
		6.10.3. Analyze Results
		6.10.4. Assess Limitations of the Solution and Organization
		6.10.5. Recommend Approach to Improve Solution Performance
	6.11. Solution Replacement/Phase Out
Appendix X1
Appendix X2
Glossary
                        
Document Text Contents
Page 144

would be most beneficial given what is known about the project. There are a
number of analysis techniques to choose from, and each technique has strengths
and circumstances to which it is best used. A business analyst will likely not be
proficient in every technique; however, it is valuable to learn as many techniques
as possible and develop the skills and experience to know when a particular
technique is best leveraged. Consider which analysis tools could be applied, such
as modeling tools, and which templates could be used. Decide in advance which
modeling language to use, if any. Determine what existing models in the
organization could be used as a starting point for the current project. Plan for
analysis based on known information but also be able and ready to adjust plans
to the unexpected discoveries that occur throughout the business analysis
process.

Business analysts work with different types of information. Choose the correct
information to analyze and separate out those things that interfere with a proper
analysis. Use visual models to help establish a boundary on exactly what needs
to be analyzed and to help facilitate discussions with stakeholders and subject
matter experts when determining the key pieces of information. Most often,
business analysts conduct analysis on the outputs of elicitation activities. In
addition, analysis frequently provokes relevant and important questions about
the situation, requiring more elicitation. Regardless of the business analysis
approach used, elicitation and analysis are usually iterative.

In this practice guide, the model refers to a visual representation of
information, both abstract and specific, that operates under a set of guidelines in
order to efficiently arrange and convey a lot of information in a concise manner.
In its simplest form, a business analysis model is a structured representation of
information. Models are diagrams, tables, or structured text. Models are created
with a variety of tools, ranging from formal modeling tools to whiteboards to
artistic software. There are many business analysis models and each serves one
or more purposes. Examples of information related to business analysis that can
be modeled include business objectives, requirements, business rules, and

Page 145

design.

Business analysis models are helpful to find gaps in information and to
identify extraneous information. Models provide context to better understand
and more clearly convey information. Requirements are modeled and refined to
achieve further clarity, correctness, and to elicit additional information to define
the details necessary for the product to be built.

When the correct models are applied, analysis becomes simple relative to
analyzing the information in pure text form, because the models help visualize
and summarize complex information. When the correct models are applied,
analysis becomes much easier.

Analysis models are organized into specific categories, defined mostly by the
primary subject matter represented. One categorization of models is shown in
Table 4-2, along with examples of each model.

Scope models Models that structure and organize the
features, functions, and boundaries of
the business domain being analyzed

• Goal and business objectives model
• Ecosystem map
• Context diagram
• Feature model
• Organizational chart (described in
Business Analysis Planning)

• Use case diagram
• Decomposition model (described in
Business Analysis Planning)

• Fishbone diagram (described in Needs
Assessment)

• Interrelationship diagram (described in
Needs Assessment)

• SWOT diagram (described in Needs
Assessment)

Process models Models that describe business processes
and ways in which stakeholders interact
with those processes

• Process flow
• Use case
• User story

Page 288

constraints in order to identify user interface and usability requirements for
software applications and other products.

User Interface Flow. A business analysis model that shows the specific pages
or screens of an application and how a user can navigate between them.

User Story. A one or two sentence description, written from the viewpoint of
the actor, describing what function is needed. A user story usually takes the form
of “as an <actor>, I want to <function>, so that I can <benefit>.”

Validation. The assurance that a product, service, or system meets the needs of
the customer and other identified stakeholders. It often involves acceptance and
suitability with external customers. Contrast with

Verification. The evaluation of whether or not a product, service, or system
complies with a regulation, requirement, specification, or imposed condition. It
is often an internal process. Contrast with

Velocity. A measure of a team's productivity rate at which the deliverables are
produced, validated, and accepted within a predefined interval. Velocity is a
capacity planning approach frequently used to forecast future project work.

Version Control. The process of maintaining a history of changes on software
or documentation.

Version Control System (VCS). A system that is used to track the history of
revisions, often but not always related to software.

Weighted Criteria. A technique used to help support objective decision making.
It uses a weighted ranking matrix to compare alternatives and their weighted
scores in order to evaluate decision options. See also

Weighted Ranking Matrix. A table used in decision making that combines pair
matching of all alternatives with weighted criteria to add objectivity when
formulating a decision or recommendation. Each alternative is compared with
every other alternative on the basis of weighted criteria, and the resulting scores
are added together to determine the preferred choice.

Work Breakdown Structure (WBS). A hierarchical decomposition of the total
scope of work to be carried out by the project team to accomplish the project
objectives and create the required deliverables.

Page 289

Work Product.

Similer Documents