KBPA - DUN

Tasks: Strategy Analysis

"*Defining *and *understanding *the business *problem or opportunity* *Assessing* capability* gaps *in the organization by analyzing the current and future states *Assessing risks* relative to the proposed *solution* *Defining* the change *strategy* for the initiative *Determining* the *most feasible* business *solution* approach" Tasks from the Strategy Analysis knowledge area *focus* on *defining the business requirements* and justifying delivery of the *solution scope* for the project. Business analysis performance *metrics for the tasks and deliverables* are *also defined and tracked.* *determine* whether it is a *viable and worthwhile project * for the business.

Tasks: Requirements Life Cycle Management

"*Managing *requirements *traceability* *Maintaining *requirements for accuracy and *reuse* *Addressing *requirements *prioritization* *Determining* how requirements *should change* *Facilitating* requirements *approval*"

Tasks: Elicitation and Collaboration

"*Preparing* for *elicitation* activities Meeting with stakeholders to *conduct the elicitation activity* *Confirming, documenting, and recording* the elicitation *results* *Communicating and confirming* elicitation *results * with key stakeholders"

Tasks: Requirements Analysis and Design Definition

"*Specifying and modeling* requirements and designs *Verifying* requirements and designs *Validating* requirements and designs *Defining* the *architecture and structure* of requirements *Defining* *solution options* *Analyzing value* and *recommending a solution*"

Tech: Business Capability Analysis: Elements

1. Capabilities 2. Using Capabilities 3. Performance Expectations 4. Risk Model (Business risk/Tech risk/Org risk/Market risk) 5. Strategic Planning 6. Capability Maps (Out to in: Business Value, Customer Value, Risk, Explicit Performance Gaps - An Outcome)

Indicators must be...

1. Clear / 2. Relevant / 3. Economical / 4. Adequate / 5. Quantifiable / 6. Trustworthy&Credible) CREATQ

Difference: Enterprise vs Business Architecture

*Enterprise Architecture* - A *description of the business processes, information technology, people, operations, information, and projects* of an enterprise and the relationships between them. *Business architecture*: - The *design, structure, and behaviour of the current and future states* of an enterprise to provide a common understanding of the organization. It is *used to align the enterprise's strategic objectives and tactical demands*.

Stakeholder Map - What to Who

*Influence H / Impact L* Ensure stakeholder remains satisfied *Influence H / Impact H* Work closely with stakeholder to ensure in agreement and support *Influence L / Impact L* Monitor to ensure interest/influence do not change *Influence L / Impact H* Keep informed, stakeholder ver concerned about lack of control

Tech: Non-Functional Requirements Analysis: Categories of Non-Function Req

.1 Categories of Non-Functional Requirements Common categories of non-functional requirements include: 1. *Availability*: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available. 2. *Compatibility*: degree to which the solution operates effectively with other components in its environment, such as one process with another. 3. *Functionality*: degree to which the solution functions meet user needs, including aspects of suitability, accuracy, and interoperability. 4. *Maintainability*: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. 5. *Performance Efficiency*: degree to which a solution or component performs its designated functions with* minimum consumption of resources. Can be defined based on the context or period, such as high-peak, mid- peak or off-peak usage. 6. *Portability*: ease with which a solution or component can be transferred from one environment to another. 7. *Reliability*: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device. 8. *Scalability*: degree with which a solution is able to grow or evolve to handle increased amounts of work. 9. *Security*: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure. 10. *Usability*: ease with which a user can learn to use the solution. 11. *Certification*: constraints on the solution that are necessary to meet certain standards or industry conventions. 12. *Compliance*: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction. 13. *Localization*: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context. 14. *Service Level Agreements*: constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution. 15. *Extensibility*: the ability of a solution to incorporate new functionality.

Tech: Interviews: Elements

.1 Interview Goal .2 Potential Interviewees .3 Interview Questions 4. Interview Logistics 5. Interview Flow 6. Interview Follow up

Tech: Financial Analysis: Elements

1. *Cost of the Change* The cost of a change includes the expected cost of building or acquiring the solution components and the expected costs of transitioning the enterprise from the current state to the future state 2. *Total Cost of Ownership* The total cost of ownership (TCO) is the cost to acquire a solution, the cost of using the solution, and the cost of supporting the solution for the foreseeable future, combined to help understand the potential value of a solution. 3. *Value Realization* Value is typically realized over time. 4. *Cost-Benefit Analysis* Cost-benefit analysis is a prediction of the expected total benefits minus the expected total costs, resulting in an expected net benefit (the planned business value). 5. *Financial Calculations*

Tech: Business Rules: Elements

1. *Definitional Rules* Definitional rules shape concepts, or produce knowledge or information 2. *Behavioural Rules* Behavioural rules are people rules-even if the behaviour is automated. *Levels of Enforcement* 2.1 Allow no violations (strictly enforced). • 2.2 Override by authorized actor. 2.3 Override with explanation. 2.4 No active enforcement.

Tech: Process Analysis: Elements

1. *Identify Gaps & Areas to Improve* (what is in scope) 2. *Identify Root Causes* 3. *Generate and Evaluate Options* 4. *Common Methods* (SIPOC, VSM) Value stream mapping (VSM) is a process analysis method used in Lean methodologies. SIPOC is a process analysis method that originates in the Six Sigma methodology and has been more commonly adopted as a process analysis method outside of Six Sigma.

Tech: Scope Modelling: Elements

1. *Objective* (• span of control, • relevance of elements, and • where effort will be applied.) 2. *Scope of Change and Context* (business processes, functions, new capabilities, events, technologies , stakeholders and organizational roles impacted by the change) 3. *Level of Detail* 4. *Relationships* (Parent-Child / Function-Responsibility / Supplier-Customer / Cuase-Effect / Emergent) 5. Assumptions 6. Scope Modelling Results

Tech: Root Cause Analysis: Elements

1. *The Fishbone Diagram* A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is used to identify and organize the possible causes of a problem. 2. *The Five Whys* The five whys is a question asking process to explore the nature and cause of a problem.

Various levels of enforcement may be specified for a behavioural rule. For example

1. Allow no violations (strictly enforced). 2• Override by authorized actor. 3• Override with explanation. 4• No active enforcement.

Tech: Review: Elements: Participants

1. Author - Answers Q, listens to suggestions (All tech) 2. Peer - Examines and review objectives. (All tech) 3. Facilitator - Neutral, keep everyone focused (Inspection/Formal walkthrough/Single Issue) 4. Scribe - Neutral, document (inspection/formal&informal walkthrough)

Software Req Traceability

1. Business Need 2. Business Requirement 3. Stakeholder Requirement 4. Solution Requirement (Design, Code, Test)

Tech: Decision Analysis: Elements

1. Components of Decision Analysis (a. Decision to be made, b. Decision Maker, c. Alternative, d. Decision Criteria) 2. Decision Matrices (Simple Decision Matrix / Weighted Decision Matrix) 3. Decision Trees (Decision Nodes/Chance Nodes/ Terminator(End Node)) 4. Trade-offs (Elimination of dominated alternatives / Ranking objectives on similar scale)

Tech: Decision Modelling: Types of Models and Notations

1. Decision Tables/ 2. Decision Trees/ 3. Decision Requirements Diagrams 3.1 Decisions (Rectangles) 3.2 Input Data (Ovals) 3.3 Business Knowledge Models - Business rules & other decision models(Rectangles with ends off) 3.4 Knowledge Sources (Document icon/ Square with wave)

Tech: Func Decomposition: Elements

1. Decomposition Objectives 2. Subjects of Decomposition 3. Level of Decomposition 4. Representation of Decomposition Results

Tech: Func Decomposition: Elements (Detailed)

1. Decomposition Objectives (Measuring & Mng / Designing / Analyzing / Estimating & Forecasting / Reusing / Optimization / Substitution / Encapsulation) 2. Subjects of Decomposition (Business Outcomes / Work to be Done (WBS) / Business Process / Function / Business Unit / Solution Component / Activity / Products & Services / Decisions) 3. Level of Decomposition 4. Representation of Decomposition Results (Tree Diagrams / Nested Diagrams / Use Case Diagrams / Flow Diagrams / State Transition diagrams / Cause-Effect Diagrams / Decision Trees / Mind Maps / Component diagram / Decision Model & Notation)

Tech: Decision Analysis: Approach Activities

1. Define Problem Statement 2. Define Alternative 3. Evaluate Alternatives 4. Choose Alternative to Implement 5. Implement Choice

Types of Analytics

1. Descriptive analytics: uses historical data to understand and analyze past business performance. 2. Predictive analytics: applies statistical analysis methods to historical data to identify patterns, and then uses that understanding of relationships and trends to make predictions about future events. 3. Prescriptive analytics: expands on predictive analytics to identify decisions to be made and to initiate appropriate action to improve business performance.

Types of Data Mining

1. Descriptive: such as clustering make it easier to see the patterns in a set of data, such as similarities between customers. 2. Diagnostic: such as decision trees or segmentation can show why a pattern exists, such as the characteristics of an organization's most profitable customers. 3. Predictive: such as regression or neural networks can show how likely something is to be true in the future, such as predicting the probability that a particular claim is fraudulent.

Tech: Focus Group: Elements

1. Focus Group Objectives 2. Focus Group Plan (Activities:) 2.1 Purpose 2.2 Location 2.3 Logistics 2.4 Participants 2.5 Budget 2.6 Timelines 2.7 Outcomes 3. Participants (6-12 & Paid) 4. Discussion Guide 5. Assign a Moderator and Recorder 6. Conduct Focus Group 7. After the Focus Group

Tech: Mind Mapping: Elements

1. Main Topic 2. Topics 3. Sub Topics 4. Branches 5. Keywords 6. Colour 7. Images

Tech: Estimation: Elements

1. Methods (Top-Down/Bottom-up/Parametric/Rough Order of Magnitude (ROM)/Rolling Wave/Delphi/PERT 2. Accuracy of Estimate 3. Sources of Info (Analogous Situation/Org History/Expert Judgement) 4. Precision & Reliability of Estimates 5. Contributors to Estimates

Tech: Business Cases: Elements

1. Need Assessment 2. Desired Outcomes 3. Assess Alternatives 3.1 Scope 3.2 Feasibility 3.3 Assumptions, Risks, Constraints 3.4 Financial Analysis/Value Assessment 4. Rocommended Solution

Tech: Review: Elements

1. Objectives 2. Techniques 3. Participants

Tech: Observation: Elements

1. Observation Objectives (Understand activity(tasks,tools,events) / identify opportunities for improv / establish perf metrics / assess solution / validate assumptions) 2. Prepare for Observation 3. Conduct the Observation Session 4. Confirm and Present Observation Results

Tech: Collaborative Games: Steps

1. Opening Step (Learn rules) 2. Exploration (Engage) 3. Closing Step (Assess ideas)

Tech: Document Analysis: Elements

1. Preparation 2. Doc Review & Analysis 3. Record Findings

Tech: Workshop: Elements

1. Prepare for workshop 2. Roles (Sponsor, Facilitator, Scribe, Timekeeper, Participants) 3. Conduct Workshop 4. Post Workshop wrap-up

Tech: Collaborative Games: Types

1. Product Box (Used to help identify features - construct a box and try to sell) 2. Affinity Map (Used to help identify related features - sticky notes) 3. Fishbowl (Used to identify hidden assumptions/perspectives - 2 groups, 1 speaks, other listens)

Tech: Prototyping: Elements

1. Prototyping Approach a) Throw-away b) Evolutionary/Functional 2. Prototyping Examples a) Proof of Principle/Concept (validate, without appearance) b) Form Study Prototype (explore appearance, without functionality) c) Usability Prototype (test how user interacts without appearance) d) Visual Prototype (visual, without functionality) e) Functional Prototype (test software func) 3. Prototyping Methods a) Storyboarding (visual/text sequence of activities different user interactions) b) Paper Prototyping c) Workflow Modelling d) Simulation (test various)

RACI

1. Responsible 2. Accountable 3. Consulted 4. Informed

Onion Diagram - Levels?

1. Solution Delivery (Project team, direct) 2. Affected Org Unit (End users, help desk, affected by) 3. Org / Enterprise (Sponsor, executive, SME, interact with) 4. Affected External Stakeholder (Customer/Supplier/Regulations, etc)

Tech: Stakeholder List, Map, or Personas: Elements

1. Stakeholder Lists 2. Stakeholder Map (Stakeholder Matrix/Onion Diagram)

Process Traceability

1. Value Chain 2. Business Process 3. Sub-Process 4. Activity 5. Task

Datamining Techniques

1. classification and regression trees (CART), C5 and other decision tree analysis techniques, 2. linear and logistic regression, 3. neural networks, 4. support sector machines, and 5. predictive (additive) scorecards.

Tech: Risk Analysis & Mng: Treatment

1• *Avoid*: either the source of the risk is removed, or plans are adjusted to ensure that the risk does not occur. 2• *Transfer*: the liability for dealing with the risk is moved to, or shared with, a third party. 3• *Mitigate*: reduce the probability of the risk occurring or the possible negative consequences if the risk does occur. 4• *Accept*: decide not to do anything about the risk. If the risk does occur, a workaround will be developed at that time. 5• *Increase*: decide to take on more risk to pursue an opportunity.

Tech: Focus Groups: Activities

2.1 Purpose 2.2 Location 2.3 Logistics 2.4 Participants 2.5 Budget 2.6 Timelines 2.7 Outcomes

9.1 Analytical Thinking and Problem Solving

9.1.1 Creative Thinking 9.1.2 Decision Making 9.1.3 Learning 9.1.4 **Problem Solving** 9.1.5 Systems Thinking 9.1.6 **Conceptual Thinking** 9.1.7 Visual Thinking

9.2 Behavioural Characteristics

9.2.1 Ethics 9.2.2 Personal Accountability 9.2.3 **Trustworthiness** 9.2.4 Organization and Time Management 9.2.5 **Adaptability**

9.3 Business Knowledge

9.3.1 **Business Acumen** 9.3.2 Industry Knowledge 9.3.3 Organization Knowledge 9.3.4 **Solution Knowledge** 9.3.5 **Methodology Knowledge**

9.4 Communication Skills

9.4.1 ****Verbal** Communication** 9.4.2 Non-Verbal Communication 9.4.3 Written Communication 9.4.4 **Listening**

9.5 Interaction Skills

9.5.1 Facilitation 9.5.2 **Leadership** and Influencing 9.5.3 Teamwork 9.5.4 **Negotiation and Conflict Resolution** 9.5.5 **Teaching**

9.6 Tools and Technology

9.6.1 Office Productivity Tools and Technology 9.6.2 Business Analysis Tools and Technology 9.6.3 Communication Tools and Technology

Personas

A persona is defined as a fictional character or archetype that exemplifies the way a typical user interacts with a product. Personas are helpful when there is a desire to understand the needs held by a group or class of user

Roles & Permission Matrix

A roles and permissions matrix is used to ensure coverage of activities by denoting responsibility, to identify roles, to discover missing roles, and to communicate results of a planned change. 1. Identify Role 2. Identify Activities 3. Identify Authorities 4. Refinement (Delegation/Inheritance)

Tech: Survey / Questionnaire

A survey or questionnaire is used to elicit business analysis information—including information about customers, products, work practices, and attitudes—from a group of people in a structured way and in a relatively short period of time. *Closed-Ended* or *Open-ended* ----- Elements: 1. Prepare (Define Objective, target group, type, sample, distribution channel, timeliness, test) 2. Distribute (urgency, security, geographic) 3. Document Results (collect, summarize, evaluate, formulate, breakdown to measurable increments)

Tech: Glossary: Elements

A term is included in the glossary when: • the term is unique to a domain, • there are multiple definitions for the term, • the definition implied is outside of the term's common use, or • there is a reasonable chance of misunderstanding.

Tech: User Stories

A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. Used for: Capture need, estimating, user acceptance test, metric, tracing, additional analysis, reporting -- Elements: 1. Title 2. Statement of value (Who, What, Why) 3. Conversation 4. Acceptance Criteria

Tech: Vendor Assessment

A vendor assessment assesses the ability of a vendor to meet commitments regarding the delivery and the consistent provision of a product or service. Elements: 1. Knowledge and Expertise 2. Licensing / Pricing Models 3. Vendor Market Position 4. Terms and Conditions 5. Vendor Experience, Repution, Stability

Tech: Interviews

An interview is a systematic approach designed to elicit business analysis information from a person or group • Structured Interview: in which the interviewer has a predefined set of questions. • Unstructured Interview: in which the interviewer does not have a predetermined format or order of questions. Questions may vary based on interviewee responses and interactions.

Categories of Non Functional Requirements

C*2*REAMCUP*2*S*3* FL Availability: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available. • Compatibility: degree to which the solution operates effectively with other components in its environment, such as one process with another. • Functionality: degree to which the solution functions meet user needs, including aspects of suitability, accuracy, and interoperability. • Maintainability: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. • Performance Efficiency: degree to which a solution or component performs its designated functions with minimum consumption of resources. Can be defined based on the context or period, such as high-peak, mid- peak or off-peak usage. • Portability: ease with which a solution or component can be transferred from one environment to another. • Reliability: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device. • Scalability: degree with which a solution is able to grow or evolve to handle increased amounts of work. • Security: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure. • Usability: ease with which a user can learn to use the solution. • Certification: constraints on the solution that are necessary to meet certain standards or industry conventions. • Compliance: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction. • Localization: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context. • Service Level Agreements: constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution. • Extensibility: the ability of a solution to incorporate new functionality.

Tasks: Business Analysis Planning and Monitoring

Defining the business analysis approach Planning for stakeholder engagement Setting up business analysis governance Outlining the business analysis information management process Identifying business analysis performance improvements ------ "*Planning* the business analysis *approach* for the project *Determining* how to *engage* stakeholders, including stakeholder identification, analysis, and categorization *Defining* the business analysis *governance* activities for decision making *Addressing* business analysis *information* management *needs* *Planning* the *requirements development* and management process *Managing* and *reporting *on the business analysis *effort*"

What are the three basic modeling elements of BPMN?

Event, Activity, and Gateway

Tech: Interface Analysis: Elements

Interface analysis is used to identify where, what, why, when, how, and for whom information is exchanged between solution components or across solution boundaries. .1 Preparing for Identification .2 Conduct Interface Identification .3 Define Interfaces

Tech: Item Tracking: Elements

Item tracking is used to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution. 1. Item Record (Item identifier / Summary / Category / Type / Date Identified / Identified by / Impact / Priority / Resolution Date / Owner / Resolver / Agreed Strat / Status / Resolution Updates / Escalation Matrix) 2. Item Management 3. Metrics

Tech: Metrics & KPI

Metrics and key performance indicators measure the performance of solutions, solution components, and other matters of interest to stakeholders. 1. Indicators (Results...) (CREATQ) (Clear / Relevant / Economical / Adequate / Quantifiable / Trustworthy&Credible) 2. Metrics (Objective to reach...) 3. Structure (data collection/analysis...) 4. Reporting (Compare baseline, metrics, target...)

What is a model

Model is a descriptive and visual way to convey information

Tech: Financial Analysis: Internal Rate of Return

Net Present Value = (-1 x Original Investment) + Sum of (net benefit for that period / (1 + IRR) for all periods) = 0. The internal rate of return (IRR) is the interest rate at which an investment breaks even, and is usually used to determine if the change, solution or solution approach is worth investing in. T

Tech: Financial Analysis: Net Present Value

Net Present Value = Present Value - Cost of Investment

Tech: Non-Functional Requirements Analysis

Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform .1 Categories of Non-Functional Requirements (AC3-FMP2-RS3ULE) .2 Measurement of Non-Functional Requirements .3 Context of Non-Functional Requirements

Explain Object Diagrams

Object diagrams can be used to illustrate particular instances of entities from a data model. They can include actual sample values for the attributes, making object diagrams more concrete and more easily understood.

Tech: Observation: Approaches

Observation is used to elicit information by viewing and understanding activities and their context ----- There are two basic approaches for observation: 1• *Active/Noticeable*: while observing an activity the observer asks any questions as they arise. Despite this interruption to the work flow, the observer can more quickly understand the rationale and hidden processes underlying the activity, such as decision making. A variation of this method may involve even stronger intervention into actors' activities by stimulating them to perform specific tasks. This kind of facilitated observation allows focus on the observer's objectives in order to shorten observation time or elicit specific information. 2• *Passive/Unnoticeable*: during the activity the observer does not interrupt the work. Any concerns are raised once the observation is over. This allows observation of a natural flow of events without intervention by the observer, as well as measurement of the time and quality of work. A variation of this method is video recording the activity and then reviewing it with the person being observed so they may provide further clarification.

Tech: Org Modelling: Elements

Organizational modelling is used to describe the roles, responsibilities, and reporting structures that exist within an organization and to align those structures with the organization's goals. 1. Types of Org Models 1.1 Functionally-orientated (based on shared skills/expertise) 1.2 Market-oriented 1.3 Matrix Model 2. Roles 3. Interfaces 4. Org Charts 5. Influencers

SDLC (Systems Development Life Cycle)

Phase 1: Requirement collection and analysis Phase 2: Feasibility study Phase 3: Design Phase 4: Coding Phase 5: Testing Phase 6: Installation/Deployment Phase 7: Maintenance

Tech: Financial Analysis: Present Value

Present Value = Sum of (Net Benefits in that period / (1 + Discount Rate for that period)) for all periods in the cost-benefit analysis.

Tech: Prioritization: Elements

Prioritization provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information. For the purpose of this technique, prioritization is classified into one of four approaches: 1• Grouping (high/med/low) 2• Ranking (most/least), 3• Time boxing/Budgeting (allocation based on amount work/budget) 4• Negotiation (consensus).

Tech: Process Analysis

Process analysis assesses a process for its efficiency and effectiveness, as well as its ability to identify opportunities for change. Process analysis is used for various purposes including: 1• recommending a more efficient or effective process, 2• determining the gaps between the current and future state of a process, 3• understanding factors to be included in a contract negotiation, 4• understanding how data and technology are used in a process, and 5• analyzing the impact of a pending change to a process. *When analyzing BA look for how value is created, aligns to strat, importance and how future state will affect*

Tech: Process Modelling

Process modelling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis. Process models describe the sequential flow of work or activities. Process models can be used to: 1• describe the context of the solution or part of the solution, 2• describe what actually happens, or is desired to happen, during a process, 3• provide an understandable description of a sequence of activities to an external observer, 4• provide a visual to accompany a text description, and 5• provide a basis for process analysis.

Tech: Prototyping

Prototyping is used to *elicit and validate* stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.

Not identified in GA

Responsible to Implement What is Identified: - Who will approve change - How to change requests - Who can change requests

Tech: Financial Analysis: Return on Investment

Return on Investment = (Total Benefits - Cost of the Investment) / Cost of the Investment.

Tech: Review: Purpose

Reviews are used to evaluate the content of a work product. ------- Each is tailored to the needs of the organization and business analyst, and uses these *dimensions*: 1• *Objectives*: defining the purpose of the review. 2• *Techniques: identifying either a formal or informal way to perform the review. 3• *Participants*: identifying who should take part in the review activity.

Tech: Risk Analysis & Mng

Risk analysis and management identifies areas of uncertainty that could negatively affect value, analyzes and evaluates those uncertainties, and develops and manages ways of dealing with the risks. 1. Risk Identificaiton 2. Analysis 3. Evauation 4. Treatment (avoid/transfer/mitigate/accept/increase)

Tech: Root Cause Analysis Used for? Activities?

Root cause analysis is used to *identify and evaluate the underlying causes* of a problem. Root cause analysis helps organize the information in a framework, which allows for deeper analysis if needed. Root cause analysis *can be used for*: 1• *Reactive Analysis*: identifying the root cause(s) of an occurring problem for corrective action, or 2• *Proactive Analysis*: identifying potential problem areas for preventive action. --- Root cause analysis *uses four main activities*: 1• *Problem Statement Definition*: describes the issue to be addressed. 2• *Data Collection*: gathers information about the nature, magnitude, location, and timing of the effect. 3• *Cause Identification*: investigates the patterns of effects to discover the specific actions that contribute to the problem. 4• *Action Identification*: defines the corrective action that will prevent or minimize recurrence.

Tech: SWOT

SWOT analysis is a simple yet effective tool used to evaluate an organization's strengths, weaknesses, opportunities, and threats to both internal and external conditions. --- A SWOT analysis can be used to: 1• evaluate an organization's current environment, 2• share information learned with stakeholders, 3• identify the best possible options to meet an organization's needs, 4• identify potential barriers to success and create action plans to overcome barriers, 5• adjust and redefine plans throughout a project as new needs arise, 6• identify areas of strength that will assist an organization in implementing new strategies, 7• develop criteria for evaluating project success based on a given set of requirements, 8• identify areas of weakness that could undermine project goals, and 9• develop strategies to address outstanding threats.

Tech: Scope Modelling

Scope models define the nature of one or more limits or boundaries and place elements inside or outside those boundaries. ---- These *models may show elements that include*: 1• *In-scope*: the model identifies a boundary as seen from inside, as well as the elements contained by that boundary (for example, functional decomposition). 2• *Out-of-scope:* the model identifies a boundary as seen from outside, as well as the elements that are not contained by that boundary (for example, context diagram). 3• *Both: *the model identifies a boundary as seen from both sides, as well as elements on both sides of the boundary (for example, venn diagram or use case model). ------ Scope models *provide the basis for understanding the boundaries* of: 1• *Scope of Control*: what is being analyzed, roles and responsibilities, and what is internal and external to the organization. 2• *Scope of Need*: stakeholder needs, value to be delivered, functional areas, and organizational units to be explored. 3• *Scope of Solution*: requirements met, value delivered, and impact of change. 4• *Scope of Change*: actions to be taken, stakeholders affected or involved, and events to cause or prevent.

Tech: Sequence Diagrams:

Sequence diagrams are used to model the *logic* of *usage scenarios* by showing the information passed between objects in the system through the execution of the scenario. Elements 1. Lifeline (lifespan of object) 2. Activation Box (period of execution) 3. Message (Synchronous Call - send & wait / Asynchronous Call - Send & Continue) ---- Used for chronological order

Tech: Stakeholder List, Map, or Personas

Stakeholder lists, maps, and personas assist the business analyst in analyzing stakeholders and their characteristics. *Common types of stakeholder characteristics* that are worth identifying and analyzing include: 1• level of authority within the domain of change and within the organization, 2• attitudes toward or interest in the change being undertaken, 3• attitudes toward the business analysis work and role, and 4• level of decision-making authority.

Tech: State Modelling: Elements

State modelling is used to describe and analyze the different possible states of an entity within a system, how that entity changes from one state to another, and what can happen to the entity when it is in each state. 1. State 2. State Transition 3. State Diagram 4. State Tables

Tech: Financial Analysis: Discount Rate

The discount rate is the assumed interest rate used in present value calculations.

Tech: Fincial Analysis: Payback Period

The payback period provides a projection on the time period required to generate enough benefits to recover the cost of the change, irrespective of the discount rate.

Tech: Lessons Learned

The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases. Sessions can include a review of: 1• business analysis activities or deliverables, 2• the final solution, service, or product, 3• automation or technology that was introduced or eliminated, 4• impact to organizational processes, 5• performance expectations and results, 6• positive or negative variances, 7• root causes impacting performance results, and 8• recommendations for behavioural approaches.

Tech: Process Modelling: Elements

Types of Process Models and Notations 1. *Flowcharts * Non-Tech, swimlanes 2. *VSM* (Value Stream Mapping) 3. *UML* (Unified Modelling Language) Activity diagrams, elaborate on a single use case, business process modelling, swimlanes (responsibility), synchronization bars (parallell processing), multiple exit decision points 4. *BPMN* (Business Process model and Notation) Industry standard language, distinguish activities of different participants (pools/swimlanes -> responsibility passes) 5. *IDEF* (Integrated DEFinition) 6. *IGOE* (Input, Guide, Output, Enabler Diagrams) 7. *SIPOC* (Supplier, Input, Process, Output, Customer) 8. *VSA* (Value Stream Analysis) 9. *Data Flow Diagrams*

Tech: Use Cases & Scenarios

Use cases and scenarios describe how a person or system interacts with the solution being modelled to achieve a goal. ---- Use Case Diagram 1. Relationship (Extend - Insertion / Include - Make use of) 2. Name 3. Goal (Successful outcome) 4. Actors (Person/system external to solution) 5. Preconditions (must be true before) 6. Trigger (Initiates) 7. Flow of events (set steps) 8. Post-conditions / Guarantees (fact that must be true after)

Methods used in Lean

VSM (Value Stream Mapping)

Tech: Workshops

Workshops bring stakeholders together in order to collaborate on achieving a predefined goal. Workshops generally include: 1• a representative group of stakeholders, 2• a defined goal, 3• interactive and collaborative work, 4• a defined work product, and 5• a facilitator.

Logical data model:

is an abstraction of the conceptual data model that incorporates rules of normalization to formally manage the integrity of the data and relationships. It is associated with the design of a solution.

Conceptual data model:

is independent of any solution or technology and can be used to represent how the business perceives its information. It can be used to help establish a consistent vocabulary describing business information and the relationships within that information.

Physical data model

is used by implementation subject matter experts to describe how a database is physically organized. It addresses concerns like performance, concurrency, and security.

Tech: Review: Elements: Objecties

• to remove defects, • to ensure conformance to specifications or standards, • to ensure the work product is complete and correct, • to establish consensus on an approach or solution, • to answer a question, resolve an issue, or explore alternatives, • to educate reviewers about the work product, and • to measure work product quality.

Tech: Review: Elements: Techniques

• *Inspection*: a formal technique that includes an overview of the work product, individual review, logging the defects, team consolidation of defects, and follow-up to ensure changes were made. The focus is to remove defects and create a high quality work product. While usually performed by peers, it can also be used for stakeholder reviews. • *Formal Walkthrough* (also known as Team Review): a formal technique that uses the individual review and team consolidation activities often seen in inspection. Walkthroughs are used for peer reviews and for stakeholder reviews. • *Single Issue Review* (also known as Technical Review): a formal technique focused on either one issue or a standard in which reviewers perform a careful examination of the work product prior to a joint review session held to resolve the matter in focus. • *Informal Walkthrough*: an informal technique in which the business analyst runs through the work product in its draft state and solicits feedback. Reviewers may do minimal preparation before the joint review session. • *Desk Check*: an informal technique in which a reviewer who has not been involved in the creation of the work product provides verbal or written feedback. • *Pass Around*: an informal technique in which multiple reviewers provide verbal or written feedback. The work product may be reviewed in a common copy of the work product or passed from one person to the next. • *Ad hoc*: an informal technique in which the business analyst seeks informal review or assistance from a peer.

Tech: Business Model Canvas: Elements

• Key Partnerships, • Key Activities (Value-Add/NonValue-Add/Business Non-value-add), • Key Resources (Physical/Fin/Intellectual/Human), • Value Proposition, • Customer Relationships, • Channels, • Customer Segments, --------- • Cost Structure, and • Revenue Streams (Licensing/Subscription/Trasaction/Fees/Sales/Lending/Renting/Leasing).

Tech: Decision Analysis: Tools

• pro versus con considerations, • force field analysis, • decision tables, • decision trees, • comparison analysis, • analytical hierarchy process (AHP), • totally-partially-not (TPN), • multi-criteria decision analysis (MCDA), and • computer-based simulations and algorithms.