1. 6 - Strategy Analysis
1.1. 6.1 - Analyze Current State
1.1.1. Purpose
1.1.1.1. to understand the reasons why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change
1.1.2. Inputs
1.1.2.1. Elicitation Results
1.1.2.2. Needs
1.1.3. Elements
1.1.3.1. Business Needs
1.1.3.1.1. From the top-down
1.1.3.1.2. From the bottom-up
1.1.3.1.3. From middle management
1.1.3.1.4. From external drivers
1.1.3.2. Organizational Structure & Culture
1.1.3.3. Capabilities & Processes
1.1.3.3.1. capability-centric view
1.1.3.3.2. process-centric view
1.1.3.4. Technology & Infrastructure
1.1.3.5. Plicies
1.1.3.6. Business Architecture
1.1.3.7. Internal Assets
1.1.3.8. External Influencers
1.1.3.8.1. Industry Structure
1.1.3.8.2. Competitors
1.1.3.8.3. Customers
1.1.3.8.4. Suppliers
1.1.3.8.5. Political & Regulatory Environment
1.1.3.8.6. Technology
1.1.3.8.7. Macroeconomic Factors
1.1.3.9. Guidelines & Tools
1.1.3.9.1. BA Approach
1.1.3.9.2. Enterprise Limitation
1.1.3.9.3. Organizational Strategy
1.1.3.9.4. Solution Limitation
1.1.3.9.5. Solution Performance Goals
1.1.3.9.6. Solution Performance Measures
1.1.3.9.7. Stakeholder Analysis Results
1.1.4. Techniques
1.1.4.1. Benchmarking & Market Analysis
1.1.4.2. Business Capability Analysis
1.1.4.3. Business Model Canvas
1.1.4.4. Business Cases
1.1.4.5. Concept Modelling
1.1.4.6. Data Mining
1.1.4.7. Document Analysis
1.1.4.8. Financial Analysis
1.1.4.9. Focus Groups
1.1.4.10. Functional Decomposition
1.1.4.11. Interviews
1.1.4.12. Item Tracking
1.1.4.13. Lessons Learned
1.1.4.14. Metrics & KPIs
1.1.4.15. Mind Mapping
1.1.4.16. Observation
1.1.4.17. Organizational Modelling
1.1.4.18. Process Analysis
1.1.4.19. Process Modelling
1.1.4.20. Risk Analysis and Management
1.1.4.21. Root Cause Analysis
1.1.4.22. Scope Modelling
1.1.4.23. Survey or Questionaire
1.1.4.24. SWOT Analysis
1.1.4.25. Vendor Assessment
1.1.4.26. Workshops
1.1.5. Stakeholders
1.1.5.1. Customer
1.1.5.2. Domain SME
1.1.5.3. End User
1.1.5.4. Implementation SME
1.1.5.5. Operational Support
1.1.5.6. Project Manager
1.1.5.7. Regulator
1.1.5.8. Sponsor
1.1.5.9. Supplier
1.1.5.10. Tester
1.1.6. Outputs
1.1.6.1. Current State Description
1.1.6.2. Business Requirements
1.2. 6.2 - Define Future State
1.2.1. Purpose
1.2.1.1. to determine the set of necessary conditions to meet the business need
1.2.2. Description
1.2.2.1. business processes
1.2.2.2. functions
1.2.2.3. lines of business
1.2.2.4. organization structures
1.2.2.5. staff competencies
1.2.2.6. knowledge and skills
1.2.2.7. training
1.2.2.8. facilities
1.2.2.9. desktop tools
1.2.2.10. organization locations
1.2.2.11. data and information
1.2.2.12. application systems
1.2.2.13. technology infrastructure
1.2.3. Inputs
1.2.3.1. Business Requirements
1.2.4. Elements
1.2.4.1. Business Goals and Objectives
1.2.4.2. Scope of Solution Space
1.2.4.3. Constraints
1.2.4.3.1. budgetary restrictions
1.2.4.3.2. time restrictions
1.2.4.3.3. technology
1.2.4.3.4. infrastructure
1.2.4.3.5. policies
1.2.4.3.6. resources
1.2.4.3.7. skills of the team and stakeholders
1.2.4.3.8. certain stakeholders not be affected by the solution
1.2.4.3.9. compliance with regulations
1.2.4.4. Organizational Structure & Culture
1.2.4.5. Capabilities & Processes
1.2.4.6. Technology and Infrastructure
1.2.4.7. Policies
1.2.4.8. Business Architecture
1.2.4.9. Internal Assets
1.2.4.10. Identify Assumptions
1.2.4.11. Potential Value
1.2.5. Guidelines & Tools
1.2.5.1. Current State Description
1.2.5.2. Metrics & KPIs
1.2.5.3. Organizational Strategy
1.2.6. Techniques
1.2.6.1. Acceptance and Evaluation Criteria
1.2.6.2. Balanced Scorecard
1.2.6.3. Benchmarking and Market Analysis
1.2.6.4. Brainstorming
1.2.6.5. Business Capability Analysis
1.2.6.6. Business Cases
1.2.6.7. Business Model Canvas
1.2.6.8. Decision Analysis
1.2.6.9. Decision Modelling
1.2.6.10. Financial Analysis
1.2.6.11. Functional Decomposition
1.2.6.12. Interviews
1.2.6.13. Lessons Learned
1.2.6.14. Metrics & KPIs
1.2.6.15. Mind Mapping
1.2.6.16. Organizational Modelling
1.2.6.17. Process Modelling
1.2.6.18. Prototyping
1.2.6.19. Scope Modelling
1.2.6.20. Survey or Questionaire
1.2.6.21. SWOT Analysis
1.2.6.22. Vendor Assessment
1.2.6.23. Workshops
1.2.7. Stakeholders
1.2.7.1. Customer
1.2.7.2. Domain SME
1.2.7.3. End User
1.2.7.4. Implementation SME
1.2.7.5. Operational Support
1.2.7.6. Project Manager
1.2.7.7. Regulator
1.2.7.8. Sponsor
1.2.7.9. Supplier
1.2.7.10. Tester
1.2.8. Outputs
1.2.8.1. Business Objectives
1.2.8.2. Future State Description
1.2.8.3. Potential Value
1.3. 6.3 - Assess Risks
1.3.1. Purpose
1.3.1.1. to understand the undesirable consequences of internal and external forces on the enterprise during a transition to, or once in, the future state.
1.3.2. Description
1.3.2.1. possible consequences if the risk occurs
1.3.2.2. impact of those consequences
1.3.2.3. likelihood of the risk
1.3.2.4. potential time frame when the risk might occur
1.3.3. Inputs
1.3.3.1. Business Objectives
1.3.3.2. Elicitation Results (confirmed)
1.3.3.3. Influences
1.3.3.4. Potential Value
1.3.3.5. Requirements (prioritized)
1.3.4. Elements
1.3.4.1. Unknowns
1.3.4.2. Constraints, Assumptions & Dependencies
1.3.4.3. Negative Impact to Value
1.3.4.4. Risk Tolerance
1.3.4.4.1. Risk-aversion
1.3.4.4.2. Neutrality
1.3.4.4.3. Risk-seeking
1.3.4.5. Recommendation
1.3.5. Guidelines & Tools
1.3.5.1. BA Approach
1.3.5.2. Business Policies
1.3.5.3. Change Strategy
1.3.5.4. Current State Description
1.3.5.5. Future State Description
1.3.5.6. Identified Risks
1.3.5.7. Stakeholder Engagement Approach
1.3.6. Techniques
1.3.6.1. Brainstorming
1.3.6.2. Business Cases
1.3.6.3. Decision Analysis
1.3.6.4. Financial Analysis
1.3.6.5. Interviews
1.3.6.6. Lessons Learned
1.3.6.7. Mind Mapping
1.3.6.8. Risk Analysis and Management
1.3.6.9. Root Cause Analysis
1.3.6.10. Survey or Questionaire
1.3.6.11. Workshops
1.3.7. Stakeholders
1.3.7.1. Domain SME
1.3.7.2. Implementation SME
1.3.7.3. Operational Support
1.3.7.4. Project Manager
1.3.7.5. Regulator
1.3.7.6. Sponsor
1.3.7.7. Supplier
1.3.7.8. Tester
1.3.8. Outputs
1.3.8.1. Risk Analysis Results
1.4. 6.4 - Define Change Strategy
1.4.1. Purpose
1.4.1.1. to develop and assess alternative approaches to the change, and then select the recommended approach
1.4.2. Inputs
1.4.2.1. Current State Description
1.4.2.2. Future State Description
1.4.2.3. Risk Analysis Results
1.4.2.4. Stakeholder Engagement Approach
1.4.3. Elements
1.4.3.1. Solution Scope
1.4.3.2. Gap Analysis
1.4.3.2.1. processes
1.4.3.2.2. functions
1.4.3.2.3. lines of business
1.4.3.2.4. organizational structures
1.4.3.2.5. staff competencies
1.4.3.2.6. knowledge and skills
1.4.3.2.7. training
1.4.3.2.8. facilities
1.4.3.2.9. locations
1.4.3.2.10. data and information
1.4.3.2.11. application systems
1.4.3.2.12. technology infrastructure
1.4.3.3. Enterprise Readiness Assessment
1.4.3.4. Change Strategy
1.4.3.5. Transition States & Release Planning
1.4.4. Guidelines & Tools
1.4.4.1. BA Approach
1.4.4.2. Design Options
1.4.4.3. Solution Recommendations
1.4.5. Techniques
1.4.5.1. Balanced Scorecard
1.4.5.2. Benchmarking and Market Analysis
1.4.5.3. Brainstorming
1.4.5.4. Business Capability Analysis
1.4.5.5. Business Cases
1.4.5.6. Business Model Canvas
1.4.5.7. Decision Analysis
1.4.5.8. Estimation
1.4.5.9. Financial Analysis
1.4.5.10. Focus Groups
1.4.5.11. Functional Decomposition
1.4.5.12. Interviews
1.4.5.13. Lessons Learned
1.4.5.14. Mind Mapping
1.4.5.15. Organizational Modelling
1.4.5.16. Process Modelling
1.4.5.17. Scope Modelling
1.4.5.18. SWOT Analysis
1.4.5.19. Vendor Assessment
1.4.5.20. Workshops
1.4.6. Stakeholders
1.4.6.1. Customer
1.4.6.2. Domain SME
1.4.6.3. End User
1.4.6.4. Implementation SME
1.4.6.5. Operational Support
1.4.6.6. Project Manager
1.4.6.7. Regulator
1.4.6.8. Sponsor
1.4.6.9. Supplier
1.4.6.10. Tester
1.4.7. Outputs
1.4.7.1. Change Strategy
1.4.7.2. Solution Scope
2. 7 - Requirements Analysis and Design Definition
2.1. 7.1 - Specify and Model Requirements
2.1.1. Purpose
2.1.1.1. to analyze, synthesize, and refine elicitation results into requirements and designs.
2.1.1.2. Focus on NEED >> Requirements Focus on SOLUTION >> Design
2.1.1.3. IT Env., Technical design = Design All business deliverables = Requirements
2.1.2. Inputs
2.1.2.1. Elicitation Results (any state) Confirmed & Unconfirmed
2.1.2.2. Elicitation and modelling may occur sequentially, iteratively, or concurrently.
2.1.3. Elements
2.1.3.1. Model Requirements
2.1.3.1.1. Matrices
2.1.3.1.2. Diagrams
2.1.3.1.3. Categories Pr R Af C Di
2.1.3.2. Analyze Requirements
2.1.3.2.1. Business analysis information is **decomposed into** components to further examine for: • anything that must change to meet the business need, • anything that should stay the same to meet the business need, • missing components, • unnecessary components, and • any constraints or assumptions that impact the components.
2.1.3.2.2. The level of decomposition required, and the level of detail to be specified, varies depending on the knowledge and understanding of the stakeholders
2.1.3.3. Represent Requirements & Attributes
2.1.3.4. Implement the Appropriate Levels of Abstraction
2.1.3.4.1. The level of abstraction of a requirement varies based on the type of requirement and audience for the requirement.
2.1.3.4.2. Not all stakeholders require or find value in the complete set of requirements and models.
2.1.4. Guideline & Tools
2.1.4.1. Modelling Notations/Standards
2.1.4.2. Modelling Tools
2.1.4.3. Requirements Architecture
2.1.4.4. Requirements Life Cycle Management Tools
2.1.4.5. Solution Scope
2.1.5. Techniques
2.1.5.1. Acceptance and Evaluation Criteria
2.1.5.2. Business Capability Analysis
2.1.5.3. Business Model Canvas
2.1.5.4. Business Rules Analysis
2.1.5.5. Concept Modelling
2.1.5.6. Data Dictionary
2.1.5.7. Data Flow Diagrams
2.1.5.8. Data Modelling
2.1.5.9. Decision Modelling
2.1.5.10. Functional Decomposition
2.1.5.11. Glossary
2.1.5.12. Interface Analysis
2.1.5.13. Non-Functional Requirements Analysis
2.1.5.14. Organizational Modelling
2.1.5.15. Process Modelling
2.1.5.16. Prototyping
2.1.5.17. Roles and Permissions Matrix
2.1.5.18. Root Cause Analysis
2.1.5.19. Scope Modelling
2.1.5.20. Sequence Diagrams
2.1.5.21. Stakeholder List, Map, or Personas
2.1.5.22. State Modelling
2.1.5.23. Use Cases and Scenarios
2.1.5.24. User Stories
2.1.6. Outputs
2.1.6.1. Requirements (specified & modeled)
2.2. 7.2 - Verify Requirements
2.2.1. Purpose
2.2.1.1. to ensure that requirements and designs specifications and models **meet quality standards** and are usable for the purpose they serve
2.2.2. Description
2.2.2.1. Verifying requirements ensures that the requirements and designs have been **defined correctly.**
2.2.2.2. A high-quality specification is well written and easily understood by its intended audience. A high-quality model follows the formal or informal notation standards and effectively represents reality.
2.2.3. Inputs
2.2.3.1. Requirements (specified and modelled)
2.2.4. Elements
2.2.4.1. Characteristics of Requirements & Designs Quality **FPT AUU CCC**
2.2.4.1.1. Atomic
2.2.4.1.2. Complete
2.2.4.1.3. Consistent
2.2.4.1.4. Concise
2.2.4.1.5. Feasible
2.2.4.1.6. Unambiguous
2.2.4.1.7. Testable
2.2.4.1.8. Prioritized
2.2.4.1.9. Understandable
2.2.4.2. Verification Activities
2.2.4.2.1. checking for compliance with organizational performance standards
2.2.4.2.2. correct use of modelling notation, templates, or forms
2.2.4.2.3. completeness within each model
2.2.4.3. Checklists
2.2.4.3.1. Checklists are used for quality control when verifying requirements and designs.
2.2.4.3.2. hecklist is to ensure that items determined to be important are included in the final requirements deliverables
2.2.5. Guidelines & Tools
2.2.5.1. Requirements Life Cycle Management Tools
2.2.6. Techniques
2.2.6.1. Acceptance and Evaluation Criteria
2.2.6.2. Item Tracking
2.2.6.3. Metrics and Key Performance Indicators (KPIs)
2.2.6.4. Reviews
2.2.7. Outputs
2.2.7.1. Requirements (verified)
2.3. 7.3 - Validate Requirements
2.3.1. Purpose
2.3.1.1. to ensure that all requirements and designs align to the business requirements and support the **delivery of needed value.**
2.3.1.2. Validation activities may begin before requirements are completely verified. However, validation activities cannot be completed before requirements are completely verified.
2.3.2. Inputs
2.3.2.1. Requirements (specified and modelled)
2.3.3. Elements
2.3.3.1. Identify Assumptions
2.3.3.1.1. If an organization is launching an unprecedented product or service, it may be necessary to make assumptions about customer or stakeholder response, as there are no similar previous experiences on which to rely.
2.3.3.1.2. These assumptions are identified and defined so that associated risks can be managed.
2.3.3.2. Define Measurable Evaluation Criteria
2.3.3.2.1. Baseline metrics might be established based on the current state
2.3.3.2.2. Target metrics can be developed to reflect the achievement of the business objectives or some other measurement of success.
2.3.3.3. Evaluate Alignment with Solution Scope
2.3.3.3.1. A requirement can be of benefit to a stakeholder and still not be a desirable part of a solution.
2.3.3.3.2. A requirement that does not deliver benefit to a stakeholder is a strong candidate for elimination.
2.3.3.3.3. When requirements do not align, either the future state must be re-evaluated and the solution scope changed, or the requirement removed from the solution scope.
2.3.3.3.4. If a design cannot be validated to support a requirement, there might be a missing or misunderstood requirement, or the design must change.
2.3.4. Guidelines & Tools
2.3.4.1. Business Objectives
2.3.4.2. Future State Description
2.3.4.3. Potential Value
2.3.4.4. Solution Scope
2.3.5. Techniques
2.3.5.1. Acceptance and Evaluation Criteria
2.3.5.2. Document Analysis
2.3.5.3. Financial Analysis
2.3.5.4. Item Tracking
2.3.5.5. Metrics and Key Performance Indicators (KPIs)
2.3.5.6. Reviews
2.3.5.7. Risk Analysis and Management
2.3.6. Output
2.3.6.1. Requirements (validated)
2.4. 7.4 - Define Requirements Architecture
2.4.1. Purpose
2.4.1.1. to ensure that the requirements collectively support one another to fully achieve the objectives
2.4.2. Inputs
2.4.2.1. Information Management Approach
2.4.2.2. Requirements (any state)
2.4.2.3. Solution Scope
2.4.3. Elements
2.4.3.1. Viewpoints
2.4.3.1.1. Viewpoints provide templates for addressing the concerns of particular stakeholder groups.
2.4.3.1.2. A viewpoint is a set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related
2.4.3.2. NOTES
2.4.3.2.1. Views > to actual solution = Viewpoints
2.4.3.2.2. Architectural framework = collections of viewpoints
2.4.3.2.3. Requirements Architecture = collections of views
2.4.3.3. Examples of Viewpoints
2.4.3.3.1. Business Models
2.4.3.3.2. Business Process Models
2.4.3.3.3. Data models and information
2.4.3.3.4. User interactions, including Use Cases and/or User Experience
2.4.3.3.5. Audit and security
2.4.3.4. Template Architectures
2.4.3.4.1. An architectural framework is a collection of viewpoints that is standard across an industry, sector, or organization.
2.4.3.5. Completeness
2.4.3.5.1. The entire set of requirements should be able to be understood by the audience in way that it can be determined that the set is cohesive and tells a full story
2.4.3.6. Relate and Verify Requirements Relationships **NC DUC**
2.4.3.6.1. Defined
2.4.3.6.2. Necessary
2.4.3.6.3. Correct
2.4.3.6.4. Unanbiguous
2.4.3.6.5. Consistent
2.4.3.7. Business Analysis Information Architecture
2.4.3.7.1. The structure of the business analysis information is also an information architecture.
2.4.3.7.2. The information architecture is a component of the requirements architecture because it describes how all of the business analysis information for a change relates
2.4.4. Guidelines & Tools
2.4.4.1. Architecture Management Software
2.4.4.2. Legal/Regulatory Information
2.4.4.3. Methodologies & Frameworks
2.4.5. Techniques
2.4.5.1. Data Modelling
2.4.5.2. Functional Decomposition
2.4.5.3. Interviews
2.4.5.4. Organizational Modelling
2.4.5.5. Scope Modelling
2.4.5.6. Workshops
2.4.6. Output
2.4.6.1. Requirements Architecture
2.5. 7.5 - Define Design Options
2.5.1. Purpose
2.5.1.1. to define the solution approach, identify opportunities to improve the business, allocate requirements across solution components, and represent design options that achieve the desired future state
2.5.2. Inputs
2.5.2.1. Change Strategy
2.5.2.2. Requirements (validated, prioritized)
2.5.2.2.1. Requirements with the highest priorities might deserve more weight in choosing solution components to best meet them as compared to lower priority requirements.
2.5.2.3. Requirements Architecture
2.5.3. Elements
2.5.3.1. Define Solution Approaches
2.5.3.1.1. Create
2.5.3.1.2. Purchase
2.5.3.1.3. Combination of both
2.5.3.2. Identify Improvement Opportunities
2.5.3.2.1. Increase Efficiencies
2.5.3.2.2. Improve Access to Information
2.5.3.2.3. Identify Additional Capabilities
2.5.3.3. Requirements Allocation
2.5.3.3.1. Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives.
2.5.3.3.2. Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits and minimize costs.
2.5.3.4. Describe Design Options
2.5.3.4.1. A design option usually consists of many design components, each described by a design element.
2.5.4. Guidelines & Tools
2.5.4.1. Existing Solutions
2.5.4.2. Future State Description
2.5.4.3. Requirements (traced)
2.5.4.4. Solution Scope
2.5.5. Techniques
2.5.5.1. Benchmarking and Market Analysis
2.5.5.2. Brainstorming
2.5.5.3. Document Analysis
2.5.5.4. Interviews
2.5.5.5. Lessons Learned
2.5.5.6. Mind Mapping
2.5.5.7. Root Cause Analysis
2.5.5.8. Survey or Questionnaire
2.5.5.9. Vendor Assessment
2.5.5.10. Workshops
2.5.6. Output
2.5.6.1. Design Options
2.6. 7.6 - Analyze Potential Value & Recommend Solution
2.6.1. Purpose
2.6.1.1. to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise’s requirements
2.6.1.2. There may be no best option to recommend, or there may be a clear best choice. . Do nothing.
2.6.2. Inputs
2.6.2.1. Potential Value
2.6.2.2. Design Options
2.6.3. Elements
2.6.3.1. Expected Benefits
2.6.3.1.1. Expected benefits describe the positive value that a solution is intended to deliver to stakeholders.
2.6.3.1.2. The total expected benefit is the net benefit of all the requirements a particular design option addresses. Benefits are often realized over a period of time
2.6.3.2. Expected Costs
2.6.3.2.1. timeline
2.6.3.2.2. effort
2.6.3.2.3. operating costs
2.6.3.2.4. purchase and/or implementation costs
2.6.3.2.5. maintenance costs
2.6.3.2.6. physical resources
2.6.3.2.7. information resources
2.6.3.2.8. human resources
2.6.3.3. NOTE
2.6.3.3.1. opportunity cost = equal to the value of the best alternative not selected
2.6.3.4. Determine Value
2.6.3.4.1. Value to the enterprise is almost always more heavily weighted than value for any individual stakeholder groups
2.6.3.4.2. There might be increases in value for one set of stakeholders and decreases in value for another set, but an overall positive increase in value for the enterprise as a whole justifies proceeding with the change.
2.6.3.5. Assess Design Options and Recommend Solution
2.6.3.5.1. Available Resources
2.6.3.5.2. Constraints on the Solution
2.6.3.5.3. Dependencies between requirements
2.6.4. Guidelines & Tools
2.6.4.1. Business Objectives
2.6.4.2. Current State Description
2.6.4.3. Future State Description
2.6.4.4. Risk Analysis Results
2.6.4.5. Solution Scope
2.6.5. Techniques
2.6.5.1. Acceptance and Evaluation Criteria
2.6.5.2. Backlog Management
2.6.5.3. Brainstorming
2.6.5.4. Business Cases
2.6.5.5. Business Model Canvas
2.6.5.6. Decision Analysis
2.6.5.7. Estimation
2.6.5.8. Financial Analysis
2.6.5.9. Focus Groups
2.6.5.10. Interviews
2.6.5.11. Metrics and Key Performance Indicators (KPIs)
2.6.5.12. Risk Analysis and Management
2.6.5.13. Survey or Questionnaire
2.6.5.14. SWOT Analysis
2.6.5.15. Workshops
2.6.6. Output
2.6.6.1. Solution Recommendation
3. 8 - Solution Evaluation
3.1. 8.1 - Measure Solution Performance
3.1.1. Purpose
3.1.1.1. to define performance measures and use the data collected to evaluate the effectiveness of a solution in relation to the value it brings.
3.1.2. Inputs
3.1.2.1. Business Objectives
3.1.2.2. Implemented Solution (external)
3.1.3. Elements
3.1.3.1. Define Solution Performance Measures
3.1.3.1.1. Quantitative Measures
3.1.3.1.2. Qualitative Measures
3.1.3.2. Validate Performance Measures
3.1.3.3. Collect Performance Measures
3.1.3.3.1. Volume or Sample Size
3.1.3.3.2. Frequency and Timing
3.1.3.3.3. Currency
3.1.4. Guidelines & Tools
3.1.4.1. Change Strategy
3.1.4.2. Future State Description
3.1.4.3. Requirements (validated)
3.1.4.4. Solution Scope
3.1.5. Techniques
3.1.5.1. Acceptance and Evaluation Criteria
3.1.5.2. Benchmarking and Market Analysis
3.1.5.3. Business Cases
3.1.5.4. Data Mining
3.1.5.5. Decision Analysis
3.1.5.6. Focus Groups
3.1.5.7. Metrics and Key Performance Indicators (KPIs)
3.1.5.8. Non-Functional Requirements Analysis
3.1.5.9. Observation
3.1.5.10. Prototyping
3.1.5.11. Survey or Questionnaire
3.1.5.12. Use Cases and Scenarios
3.1.5.13. Vendor Assessment
3.1.6. Output
3.1.6.1. Solution Performance Measures
3.2. 8.2 - Analyze Performance Measures
3.2.1. Purpose
3.2.1.1. to provide insights into the performance of a solution in relation to the value it brings
3.2.2. Inputs
3.2.2.1. Potential Value
3.2.2.2. Solution Performance Measures
3.2.3. Elements
3.2.3.1. Solution Performance versus Desired Value
3.2.3.2. Risks
3.2.3.3. Trends
3.2.3.4. Accuracy
3.2.3.5. Performance Variances
3.2.4. Guidelines & Tools
3.2.4.1. Change Strategy
3.2.4.2. Future State Description
3.2.4.3. Risk Analysis Results
3.2.4.4. Solution Scope
3.2.5. Techniques
3.2.5.1. Acceptance and Evaluation Criteria
3.2.5.2. Benchmarking and Market Analysis
3.2.5.3. Data Mining
3.2.5.4. Interviews
3.2.5.5. Metrics and Key Performance Indicators (KPIs)
3.2.5.6. Observation
3.2.5.7. Risk Analysis and Management
3.2.5.8. Root Cause Analysis
3.2.5.9. Survey or Questionnaire
3.2.6. Output
3.2.6.1. Solution Performance Analysis
3.3. 8.3 - Assess Solution Limitations
3.3.1. Purpose
3.3.1.1. to determine the factors internal to the solution that restrict the full realization of value
3.3.2. Inputs
3.3.2.1. Implemented Solution (external)
3.3.2.2. Solution Performance Analysis
3.3.3. Elements
3.3.3.1. Identify Internal Solution Component Dependencies
3.3.3.2. Investigate Solution Problems
3.3.3.3. Impact Assessment
3.3.3.3.1. severity
3.3.3.3.2. probability
3.3.3.3.3. impact
3.3.3.3.4. capacity to absorb the impact
3.3.4. Guidelines & Tools
3.3.4.1. Change Strategy
3.3.4.2. Risks Analysis Results
3.3.4.3. Solution Scope
3.3.5. Techniques
3.3.5.1. Acceptance and Evaluation Criteria
3.3.5.2. Benchmarking and Market Analysis
3.3.5.3. Business Rules Analysis
3.3.5.4. Data Mining
3.3.5.5. Decision Analysis
3.3.5.6. Interviews
3.3.5.7. Item Tracking
3.3.5.8. Lessons Learned
3.3.5.9. Risk Analysis and Management
3.3.5.10. Root Cause Analysis
3.3.5.11. Survey or Questionnaire
3.3.6. Output
3.3.6.1. Solution Limitation
3.4. 8.4 - Assess Enterprise Limitations
3.4.1. Purpose
3.4.1.1. to determine how factors external to the solution are restricting value realization
3.4.2. Inputs
3.4.2.1. Current State Description
3.4.2.2. Implemented (or Constructed) Solution (external)
3.4.2.3. Solution Performance Analysis
3.4.3. Elements
3.4.3.1. Enterprise Culture Assessment
3.4.3.2. Stakeholder Impact Analysis
3.4.3.2.1. Functions
3.4.3.2.2. Locations
3.4.3.2.3. Concerns
3.4.3.3. Organizational Structure Changes
3.4.3.4. Operational Assessment
3.4.3.4.1. policies and procedures
3.4.3.4.2. capabilities and processes that enable other capabilities
3.4.3.4.3. skill and training needs
3.4.3.4.4. human resources practices
3.4.3.4.5. risk tolerance and management approaches
3.4.3.4.6. tools and technology that support a solution
3.4.4. Guidelines & Tools
3.4.4.1. Business Objectives
3.4.4.2. Change Strategy
3.4.4.3. Future State Descriptions
3.4.4.4. Risk Analysis Results
3.4.4.5. Solution Scope
3.4.5. Techniques
3.4.5.1. Benchmarking and Market Analysis
3.4.5.2. Brainstorming
3.4.5.3. Data Mining
3.4.5.4. Decision Analysis
3.4.5.5. Document Analysis
3.4.5.6. Interviews
3.4.5.7. Item Tracking
3.4.5.8. Lessons Learned
3.4.5.9. Observation
3.4.5.10. Organizational Modelling
3.4.5.11. Process Analysis
3.4.5.12. Process Modelling
3.4.5.13. Risk Analysis and Management
3.4.5.14. Roles and Permissions Matrix
3.4.5.15. Root Cause Analysis
3.4.5.16. Survey or Questionnaire
3.4.5.17. SWOT Analysis
3.4.5.18. Workshops
3.4.6. Stakeholders
3.4.6.1. Customer
3.4.6.2. Domain Subject Matter Expert
3.4.6.3. End User
3.4.6.4. Regulator
3.4.6.5. Sponsor
3.4.7. Output
3.4.7.1. Enterprise Limitation
3.5. 8.5 - Recommend Actions to Increase Solution Value
3.5.1. Purpose
3.5.1.1. to understand the factors that create differences between potential value and actual value, and to recommend a course of action to align them
3.5.2. Inputs
3.5.2.1. Solution Limitation
3.5.2.2. Enterprise Limitation
3.5.3. Elements
3.5.3.1. Adjust Solution Performance Measures
3.5.3.2. Recommendations
3.5.3.2.1. Do Nothing
3.5.3.2.2. Organizational Change
3.5.3.2.3. Reduce Complexity of Interfaces
3.5.3.2.4. Eliminate Redundancy
3.5.3.2.5. Avoid Waste
3.5.3.2.6. Identify Additional Capabilities
3.5.3.2.7. Retire the Solution
3.5.3.2.8. additional factors
3.5.4. Guidelines & Tools
3.5.4.1. Business Objectives
3.5.4.2. Current State Description
3.5.4.3. Solution Scope
3.5.5. Techniques
3.5.5.1. Data Mining
3.5.5.2. Decision Analysis
3.5.5.3. Financial Analysis
3.5.5.4. Focus Groups
3.5.5.5. Organizational Modelling
3.5.5.6. Prioritization
3.5.5.7. Process Analysis
3.5.5.8. Risk Analysis and Management
3.5.5.9. Survey or Questionnaire
3.5.6. Stakeholders
3.5.6.1. Customer
3.5.6.2. Domain Subject Matter Expert
3.5.6.3. End User
3.5.6.4. Regulator
3.5.6.5. Sponsor
3.5.7. Output
3.5.7.1. Recommended Actions
4. 11 - Perspectives
4.1. 11.1 - The Agile Perspective
4.1.1. Change Scope
4.1.1.1. Breadth of Change
4.1.1.2. Depth of Change
4.1.1.3. Value and Solutions Delivered
4.1.1.4. Delivery Approach
4.1.1.5. Major Assumptions
4.1.2. Business Analysis Scope
4.1.2.1. Change Sponsor
4.1.2.2. Change Targets and Agents
4.1.2.2.1. Agile team leader
4.1.2.2.2. Customer representative or product owner
4.1.2.2.3. Team members
4.1.2.2.4. External stakeholders
4.1.2.3. Business Analyst Position
4.1.2.4. Business Analysis Outcomes
4.1.3. Approaches and Techniques
4.1.3.1. Approaches
4.1.3.1.1. Crystal Clear
4.1.3.1.2. Disciplined Agile Delivery (DAD)
4.1.3.1.3. Dynamic Systems Development Method (DSDM)
4.1.3.1.4. Evolutionary Project Management (Evo)
4.1.3.1.5. Extreme Programming (XP)
4.1.3.1.6. Feature Driven Development (FDD)
4.1.3.1.7. Kanban
4.1.3.1.8. Scaled Agile Framework®(SAFe™)
4.1.3.1.9. Scrum
4.1.3.2. Techniques
4.1.3.2.1. Behaviour Driven Development (BDD)
4.1.3.2.2. Kano Analysis
4.1.3.2.3. Lightweight Documentation
4.1.3.2.4. MoSCoW Prioritization
4.1.3.2.5. Personas
4.1.3.2.6. Planning Workshop
4.1.3.2.7. Purpose Alignment Model
4.1.3.2.8. Real Options
4.1.3.2.9. Relative Estimation
4.1.3.2.10. Retrospectives
4.1.3.2.11. Story Decomposition
4.1.3.2.12. Story Mapping
4.1.3.2.13. Storyboarding
4.1.3.2.14. Value Stream Mapping
4.1.4. Underlying Competencies
4.1.4.1. Communication and collaboration
4.1.4.2. Patience and tolerance
4.1.4.3. Flexibility and adaptability
4.1.4.4. Ability to handle change
4.1.4.5. Ability to recognize business value
4.1.4.6. Continuous improvement
4.1.5. Impact on Knowledge Areas
4.1.5.1. Business Analysis Planning and Monitoring
4.1.5.2. Elicitation and Collaboration
4.1.5.3. Requirements Life Cycle Management
4.1.5.4. Strategy Analysis
4.1.5.5. Requirements Analysis and Design Definition
4.1.5.6. Solution Evaluation
4.2. 11.2 - The Business Intelligence Perspective
4.2.1. Change Scope
4.2.1.1. Breadth of Change
4.2.1.2. Depth of Change
4.2.1.2.1. executive level
4.2.1.2.2. management level
4.2.1.2.3. process level
4.2.1.2.4. the overall impact of the change on the organization
4.2.1.3. Value and Solutions Delivered
4.2.1.3.1. strategic processes such as market analysis, customer engagement, and product development
4.2.1.3.2. tactical processes such as stock control and financial planning
4.2.1.3.3. operational processes such as credit assessment, fault detection, and accounts payable monitoring
4.2.1.4. Delivery Approach
4.2.1.4.1. at different levels in the organization
4.2.1.4.2. in target functional areas in the organization
4.2.1.5. Major Assumptions
4.2.2. Business Analysis Scope
4.2.2.1. Change Sponsor
4.2.2.2. Change Targets
4.2.2.3. Business Analyst Position
4.2.2.3.1. primary liaison between business intelligence stakeholders and solution providers
4.2.2.3.2. enterprise data modelling
4.2.2.3.3. decision modelling
4.2.2.3.4. dashboards
4.2.2.3.5. ad hoc query design
4.2.2.3.6. Business Analysis Outcomes
4.2.2.4. Methodologies and Approaches
4.2.2.4.1. Methodologies
4.2.2.4.2. Approaches
4.2.2.4.3. Underlying Competencies
4.2.2.4.4. Impact on Knowledge Areas
5. 10 - Techniques
5.1. 10.1 - Acceptance and Evaluation Criteria
5.1.1. Value Attributes
5.1.2. Assessment
5.1.2.1. Testability
5.1.2.2. Measures
5.2. 10.2 - Backlog Management
5.2.1. Items in the Backlog
5.2.2. Prioritization
5.2.3. Estimation
5.2.4. Managing Changes to the Backlog
5.3. 10.3 - Balanced Scorecard
5.3.1. Learning and Growth Dimension
5.3.2. Business Process Dimension
5.3.3. Customer Dimension
5.3.4. Financial Dimension
5.3.5. Measures or Indicators
5.4. 10.4 - Benchmarking and Market Analysis
5.4.1. Benchmarking
5.4.2. Market Analysis
5.5. 10.5 - Brainstorming
5.5.1. Preparation
5.5.2. Session
5.5.3. Wrap-up
5.6. 10.6 - Business Capability Analysis
5.6.1. Capabilities
5.6.2. Using Capabilities
5.6.3. Performance Expectations
5.6.4. Risk Model
5.6.5. Strategic Planning
5.6.6. Capability Maps
5.7. 10.7 - Business Cases
5.7.1. Need Assessment
5.7.2. Desired Outcomes
5.7.3. Assess Alternatives
5.7.3.1. Scope
5.7.3.2. Feasibility
5.7.3.3. Assumptions, Risks, and Constraints
5.7.3.4. Financial Analysis and Value Assessment
5.7.4. Recommended Solution
5.8. 10.8 - Business Model Canvas
5.8.1. Key Partnerships
5.8.2. Key Activities
5.8.2.1. Value-add
5.8.2.2. Non-value-add
5.8.2.3. Business non-value-add
5.8.3. Key Resources
5.8.3.1. Physical
5.8.3.2. Financial
5.8.3.3. Intellectual
5.8.3.4. Human
5.8.4. Value Proposition
5.8.4.1. products
5.8.4.2. services
5.8.5. Customer Relationships
5.8.5.1. customer acquisition
5.8.5.2. customer retention
5.8.6. Channels
5.8.6.1. communication-oriented
5.8.6.2. delivery-oriented
5.8.7. Customer Segments
5.8.7.1. group customers
5.8.8. Cost Structure
5.8.9. Revenue Streams
5.8.9.1. revenue resulting (a one-time purchase)
5.8.9.2. recurring revenue (periodic payments)
5.8.9.3. Licensing or Subscription fees
5.8.9.4. Transaction or Usage fees
5.8.9.5. Sales
5.8.9.6. Lending, Renting, or Leasing
5.8.10. 10.9 - Business Rules Analysis
5.8.10.1. Definitional Rules
5.8.10.2. Behavioural Rules
5.9. 10.9 - Business Rules Analysis
5.9.1. Business Policy
5.9.2. Regulations
5.9.3. Contracts
5.9.4. Undocumented business policies
5.9.5. norms of the corporate culture
5.9.6. Generally accepted business practies
5.9.7. Definitional Rules
5.9.7.1. A customer must be considered a Preferred Customer if they place more than 10 orders per month.
5.9.8. Behavioural Rules
5.9.8.1. An order must not be placed when the billing address provided by the customer does not match the address on file with the credit card provider.
5.9.8.2. levels of enforcement
5.9.8.2.1. Allow no violations (strictly enforced)
5.9.8.2.2. Override by authorized actor
5.9.8.2.3. Override with explanation
5.9.8.2.4. No active enforcement
5.10. 10.10 - Collaborative Games
5.10.1. Game Purpose
5.10.2. Process
5.10.2.1. an opening step
5.10.2.2. the exploration step
5.10.2.3. a closing step
5.10.3. Outcome
5.10.4. Examples
5.10.4.1. Product Box
5.10.4.2. Affinity Map
5.10.4.3. Fishbowl
5.11. 10.11 - Concept Modelling
6. 3 - BA Planning & Monitoring
6.1. 3.1 - Plan Business Analysis Approach
6.1.1. Purpose
6.1.1.1. Is to define an appropriate method to conduct business analysis activities.
6.1.2. Description
6.1.3. Input
6.1.3.1. Needs
6.1.4. Elements
6.1.4.1. Planning Approach **PA & AA**
6.1.4.1.1. Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order to maximize control and minimize risk.
6.1.4.1.2. Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution.
6.1.4.2. Formality & Level of Details of BA deliverables
6.1.4.2.1. PA: Formal document & standardized templates
6.1.4.2.2. AA: Interaction and gethering feedback. Formal documentation is oftern produced after the solution is implemented to facilitate knowledge transfer
6.1.4.3. BA Activities
6.1.4.4. Timing of BA work
6.1.4.5. Complexity & Risks
6.1.4.6. Acceptance
6.1.5. Guidelines & Tools
6.1.5.1. BA Performance Assessment
6.1.5.2. Business Policies
6.1.5.3. Expert Judgment
6.1.5.4. Methodologies & Frameworks
6.1.5.5. Stakeholder Engagement Approach
6.1.6. Techniques
6.1.6.1. Brainstorming
6.1.6.2. Business Case
6.1.6.3. Document Analysis
6.1.6.4. Estimation
6.1.6.5. Financial Analysis
6.1.6.6. Functional Decomposition
6.1.6.7. Interview
6.1.6.8. Item Tracking
6.1.6.9. Lessons Learned
6.1.6.10. Process Modeling
6.1.6.11. Reviews
6.1.6.12. Risk Analysis & Management
6.1.6.13. Scope Modeling
6.1.6.14. Survey & Questionnaire
6.1.6.15. Workshops
6.1.7. Stakeholders
6.1.7.1. Domain Subject Matter Expert
6.1.7.2. Project Manager
6.1.7.3. Regulator
6.1.7.4. Sponsor
6.1.8. Output
6.1.8.1. BA Approach
6.2. 3.2 - Plan Stakeholder Engagement
6.2.1. Purpose
6.2.1.1. is to plan an approach for **establishing** and **maintaining** **effective working relationships** with the stakeholders.
6.2.2. Description
6.2.3. Input
6.2.3.1. Needs
6.2.3.2. BA approach
6.2.4. Elements
6.2.4.1. Perform stakeholder analysis
6.2.4.1.1. Roles
6.2.4.1.2. Attitudes
6.2.4.1.3. Decision Making Authority
6.2.4.1.4. Level of power or influence
6.2.4.2. Define stakeholder collaboration
6.2.4.3. Stakeholder communication needs
6.2.5. Guidelines & Tools
6.2.5.1. BA Performance Assessment
6.2.5.2. Change Strategy
6.2.5.3. Current State Description
6.2.6. Techniques
6.2.6.1. Brainstorming
6.2.6.2. Business Rules Analysis
6.2.6.3. Document Analysis
6.2.6.4. Interviews
6.2.6.5. Lessons Learned
6.2.6.6. Mind Mapping
6.2.6.7. Organizational Modelling
6.2.6.8. Process Modeling
6.2.6.9. Risk Analysis and Management
6.2.6.10. Scope Modelling
6.2.6.11. Stakeholder List, Map or Personas
6.2.6.12. Survey or Questionaire
6.2.6.13. Workshops
6.2.7. Stakeholders
6.2.7.1. Customers
6.2.7.2. Domain SME
6.2.7.3. End User
6.2.7.4. Project Manager
6.2.7.5. Regulator
6.2.7.6. Sponsor
6.2.7.7. Supplier
6.2.8. Output
6.2.8.1. Stakeholder Engagement Approach
6.3. 3.3 - Plan Business Analysis Governance
6.3.1. Purpose
6.3.1.1. to define how decisions are made about requirements and designs, including reviews, change controle, approvals and prioritization
6.3.2. Inputs
6.3.2.1. BA Approach
6.3.2.2. Stakeholder Engagement Approach
6.3.3. Elements
6.3.3.1. Decision Making
6.3.3.2. Change Controll Process
6.3.3.2.1. Determine the process for requesting changes
6.3.3.2.2. Determine the elements of the change request
6.3.3.2.3. Determine how changes will be prioritizes
6.3.3.2.4. Determine how changes will be documented
6.3.3.2.5. Determine how changes will be communicated
6.3.3.2.6. Determine who will perform the impact analysis
6.3.3.2.7. Determine who will authorize changes
6.3.3.3. Plan Prioritization Approach
6.3.4. Guidelines & Tools
6.3.4.1. BA Performance Assessment
6.3.4.2. Business Policies
6.3.4.3. Current State Description
6.3.4.4. Legal/Regulatory Information
6.3.5. Techniques
6.3.5.1. Brainstorming
6.3.5.2. Document Analysis
6.3.5.3. Interviews
6.3.5.4. Item Tracking
6.3.5.5. Lessons Learned
6.3.5.6. Organizational Modelling
6.3.5.7. Process Modelling
6.3.5.8. Reviews
6.3.5.9. Survey or Questionaire
6.3.5.10. Workshops
6.3.6. Stakehgolders
6.3.6.1. Domain SME
6.3.6.2. Project Manager
6.3.6.3. Regulator
6.3.6.4. Sponsor
6.3.7. Ouputs
6.3.7.1. Governance Approach
6.4. 3.4 - Plan Business Analysis Information Management
6.4.1. Purpose
6.4.1.1. to develop an approach for how BA information will be stored and accessed
6.4.2. Inputs
6.4.2.1. BA Approach
6.4.2.2. Governance Approach
6.4.2.3. Stakeholder Engagement Approach
6.4.3. Elements
6.4.3.1. Organization of BA Information
6.4.3.2. Level of Abstraction
6.4.3.3. Plan Traceability Approach
6.4.3.4. Plan for Requirements Reuse
6.4.3.5. Storage and Access
6.4.3.6. Requirements Attributes **CARA'S SOUPS**
6.4.4. Guidelines & Tools
6.4.4.1. BA Performance Assessment
6.4.4.2. Business Policies
6.4.4.3. Information Management Tools
6.4.4.4. Legal/Regulatory Information
6.4.5. Techniques
6.4.5.1. Brainstorming
6.4.5.2. Interviews
6.4.5.3. Item Tracking
6.4.5.4. Lessons Learned
6.4.5.5. Mind Mapping
6.4.5.6. Process Modelling
6.4.5.7. Survey or Questionaire
6.4.5.8. Workshops
6.4.6. Stakeholders
6.4.6.1. Domain SME
6.4.6.2. Regulator
6.4.6.3. Sponsor
6.4.7. Outputs
6.4.7.1. Information Management Approach
6.5. 3.5 - Identify Business Analysis Performance Improvements
6.5.1. Purpose
6.5.1.1. to assess BA work and to plan to improve processes where required
6.5.2. Inputs
6.5.2.1. BA Approach
6.5.2.2. Performance Objectives (external)
6.5.3. Elements
6.5.3.1. Performance Analysis
6.5.3.2. Assessment Measures **AcK EOs SST**
6.5.3.2.1. Accuracy and Completeness
6.5.3.2.2. Knowledge
6.5.3.2.3. Effectiveness
6.5.3.2.4. Organizational Support
6.5.3.2.5. Significance
6.5.3.2.6. Strategic
6.5.3.2.7. Timeliness
6.5.3.3. Analyze Results
6.5.3.4. Recommend Actions for Improvement
6.5.3.4.1. Preventive
6.5.3.4.2. Corrective
6.5.3.4.3. Improvement
6.5.4. Guidelines & Tools
6.5.4.1. Organizational Performance Standards
6.5.5. Techniques
6.5.5.1. Brainstorming
6.5.5.2. Interviews
6.5.5.3. Item Tracking
6.5.5.4. Lessons Learned
6.5.5.5. Metrics and KPIs
6.5.5.6. Observation
6.5.5.7. Process Analysis
6.5.5.8. Process Modelling
6.5.5.9. Reviews
6.5.5.10. Risk Analysis & Management
6.5.5.11. Root Cause Analysis
6.5.5.12. Survey or Questionaire
6.5.5.13. Workshops
6.5.6. Stakeholders
6.5.6.1. Domain SME
6.5.6.2. Project Manager
6.5.6.3. Sponsor
6.5.7. Outputs
6.5.7.1. BA Performance Assessment
7. 4 - Elicitation and Collaboration
7.1. 4.1 - Prepare for Elicitation
7.1.1. Purpose
7.1.1.1. to understand the scope or the elicitation activity. Select appropriate techniques and plan for appropriate supporting materials and resources
7.1.2. Inputs
7.1.2.1. Needs
7.1.2.2. Stakeholder Engagement Approach
7.1.3. Elements
7.1.3.1. Understand the Scope of Elicitation
7.1.3.2. Select Elicitation Techniques
7.1.3.3. Set up Logistics
7.1.3.4. Secure Supporting Material
7.1.3.5. Prepare Stakeholders
7.1.4. Guidelines & Tools
7.1.4.1. BA Approach
7.1.4.2. Business Objectives
7.1.4.3. Existing BA Information
7.1.4.4. Potential Value
7.1.5. Techniques
7.1.5.1. Brainstorming
7.1.5.2. Data Mining
7.1.5.3. Document Analysis
7.1.5.4. Estimation
7.1.5.5. Interviews
7.1.5.6. Mind Mapping
7.1.5.7. Risk Analysis & Management
7.1.5.8. Stakeholder List, Map or Personas
7.1.6. Stakeholders
7.1.6.1. Domain SME
7.1.6.2. Project Manager
7.1.6.3. Sponsor
7.1.7. Outputs
7.1.7.1. Elicitaion Activity Plan
7.2. 4.2 - Conduct Elicitation
7.2.1. Purpose
7.2.1.1. to draw out, explore, and identify information relevant to the change
7.2.2. Description
7.2.2.1. Collaborative
7.2.2.2. Research
7.2.2.3. Experiments
7.2.3. Inputs
7.2.3.1. Elicitation Activity Plan
7.2.4. Elements
7.2.4.1. Guide Elicitation Activity
7.2.4.2. Capture Elicitation Outcomes
7.2.5. Guidelines & Tools
7.2.5.1. BA Approach
7.2.5.2. Existing BA Information
7.2.5.3. Stakeholder Engagement Approach
7.2.5.4. Supporting Materials
7.2.6. Techniques
7.2.6.1. Benchmarking and Market Analysis
7.2.6.2. Brainstorming
7.2.6.3. Business Rules Analysis
7.2.6.4. Collaborative Games
7.2.6.5. Concept Modelling
7.2.6.6. Data Mining
7.2.6.7. Data Modelling
7.2.6.8. Document Analysis
7.2.6.9. Focus Groups
7.2.6.10. Interface Analysis
7.2.6.11. Interviews
7.2.6.12. Mind Mapping
7.2.6.13. Observation
7.2.6.14. Process Analysis
7.2.6.15. Process Modeling
7.2.6.16. Prototyping
7.2.6.17. Survey or Questionaire
7.2.6.18. Workshops
7.2.7. Stakeholders
7.2.7.1. Customer
7.2.7.2. Domain SME
7.2.7.3. End User
7.2.7.4. Implementation SME
7.2.7.5. Sponsor
7.2.7.6. Any Stakeholders
7.2.8. Outputs
7.2.8.1. Elicitation Results (unconfirmed)
7.3. 4.3 - Confirm Elicitation Results
7.3.1. Purpose
7.3.1.1. to check the information gathered during an elicitation session for accuracy and consistency with other information
7.3.2. Inputs
7.3.2.1. Elicitation Results (unconfirmed)
7.3.3. Elements
7.3.3.1. Compare Elicitation Results Against Source Information
7.3.3.2. Compare Elicitation Results Against Other Elicitation Results
7.3.4. Guidelines & Tools
7.3.4.1. Elicitation Activity Plan
7.3.4.2. Existing BA Information
7.3.5. Techniques
7.3.5.1. Document Analysis
7.3.5.2. Interviews
7.3.5.3. Reviews
7.3.5.4. Workshops
7.3.6. Stakeholders
7.3.6.1. Domain SME
7.3.6.2. Any Stakeholder
7.3.7. Outputs
7.3.7.1. Elicitation Results (confirmed)
7.4. 4.4 - Communicate BA Information
7.4.1. Purpose
7.4.1.1. to ensure stakeholders have a shared understanding of BA information
7.4.2. Inputs
7.4.2.1. BA Information
7.4.2.2. Stakeholder Engagement Approach
7.4.3. Elements
7.4.3.1. Determine Objectives and Format of Communication
7.4.3.1.1. Formal Documentation
7.4.3.1.2. Informal Documentation
7.4.3.1.3. Preseentations
7.4.3.2. Communicate BA Package
7.4.3.2.1. Group collaboration
7.4.3.2.2. Individual collaboration
7.4.3.2.3. E-mail or other non-verbal methods
7.4.4. Guideline & Tools
7.4.4.1. BA Approach
7.4.4.2. Information Management Approach
7.4.5. Techniques
7.4.5.1. Intervies
7.4.5.2. Reviews
7.4.5.3. Workshops
7.4.6. Stakeholders
7.4.6.1. End User
7.4.6.2. Customer
7.4.6.3. Domain SME
7.4.6.4. Implementation SME
7.4.6.5. Tester
7.4.6.6. Any Stakeholder
7.4.7. Outputs
7.4.7.1. BA Information (communicated)
7.5. 4.5 - Manage Stakeholder Collaboration
7.5.1. Purpose
7.5.1.1. to encourage stakeholders to work towards a common goal
7.5.2. Inputs
7.5.2.1. Stakeholder Engagement Approach
7.5.2.2. BA Performance Assessment
7.5.3. Elements
7.5.3.1. Gain Agreement on Commitments
7.5.3.2. Monitor Stakeholder Engagement
7.5.3.3. Collaboration
7.5.4. Guidelines & Tools
7.5.4.1. BA Approach
7.5.4.2. Business Objectives
7.5.4.3. Future State Description
7.5.4.4. Recommended Actions
7.5.4.5. Risk Analysis Results
7.5.5. Techniques
7.5.5.1. Collaborative Games
7.5.5.2. Lessons Learned
7.5.5.3. Risk Analysis and Management
7.5.5.4. Stakeholder List, Map or Personas
7.5.6. Stakeholders
7.5.6.1. All stakeholders
7.5.7. Outputs
7.5.7.1. Stakeholder Engagement
8. 5 - Requirements Life Cycle Management
8.1. 5.1 - Trace Requirements
8.1.1. Purpose
8.1.1.1. to ensure that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements
8.1.1.2. Requirements traceability identifies and documents the lineage of each requirement, including its backward traceability, its forward traceability, and its relationship to other requirements.
8.1.1.3. It is also used to detect missing functionality or to identify if there is implemented functionality that is not supported by any requirement.
8.1.2. Description
8.1.2.1. Process Traceability
8.1.2.1.1. Value Chain <--> Business Process <--> Sub-process <--> Activity <--> Task
8.1.2.2. Requirement Traceability
8.1.2.2.1. Business Needs <--> Business Req <--> Stakeholder Req <--> Solution Req (Design, Code & Test)
8.1.2.3. **Traceability enables:** • faster and simpler impact analysis, • more reliable discovery of inconsistencies and gaps in requirements, • deeper insights into the scope and complexity of a change, and • reliable assessment of which requirements have been addressed and which have not.
8.1.3. Inputs
8.1.3.1. **Requirements**
8.1.3.2. **Designs**
8.1.4. Elements
8.1.4.1. Level of Formality
8.1.4.1.1. The effort to trace requirements grows significantly when the number of requirements or level of formality increases.
8.1.4.2. Relationships (Types) **D DEN SV**
8.1.4.2.1. **Derive**
8.1.4.2.2. **Depends**
8.1.4.2.3. **Satisfy**
8.1.4.2.4. **Validate**
8.1.4.3. Traceability Repository
8.1.4.3.1. Requirements traceability is documented and maintained in accordance with the methods identified by the business analysis approach. . Requirements management tools can provide significant benefits when there is a need to trace a large number of requirements that may be deemed unmanageable with manual approaches.
8.1.5. Guidelines & Tools
8.1.5.1. Domain Knowledge
8.1.5.2. Information Management Approach
8.1.5.3. Legal/Regulatory Information
8.1.5.4. Requirements Management Tools/Repository
8.1.6. Techniques
8.1.6.1. Business Rules Analysis
8.1.6.2. Functional Decomposition
8.1.6.3. Process Modelling
8.1.6.4. Scope Modelling
8.1.7. Stakeholders
8.1.7.1. Customers
8.1.7.2. Domain SME
8.1.7.3. End User
8.1.7.4. Implementation SME
8.1.7.5. Operational Support
8.1.7.6. Project Manager
8.1.7.7. Sponsor
8.1.7.8. Suppliers
8.1.7.9. Tester
8.1.8. Outputs
8.1.8.1. Requirements (traced)
8.1.8.2. Designs (traced)
8.2. 5.2 - Maintain Requirements
8.2.1. Purpose
8.2.1.1. to retain requirement accuracy and consistency throughout and beyound the change during the entire requirements life cycle, and to support reuse of requirements in other solutions
8.2.1.2. A requirement that represents an ongoing need must be maintained to ensure that it remains valid over time.
8.2.1.3. In order to maximize the benefits of maintaining and reusing requirements, the requirements should be: • consistently represented, • reviewed and approved for maintenance using a standardized process that defines proper access rights and ensures quality, and • easily accessible and understandable.
8.2.2. Inputs
8.2.2.1. **Requirements**
8.2.2.2. Designs
8.2.3. Elements
8.2.3.1. Maintain Requirements
8.2.3.1.1. For requirements to be properly maintained they must be clearly named and defined, and easily available to stakeholders.
8.2.3.2. Maintain Attributes
8.2.3.2.1. Some attributes change as the business analyst uncovers more information and conducts further analysis. An attribute may change even though the requirement does not.
8.2.3.3. Reusing Requirements
8.2.3.3.1. Requirements that are candidates for long-term use by the organization are identified, clearly named, defined, and stored in a manner that makes them easily retrievable by other stakeholders
8.2.3.3.2. within the **current initiative**
8.2.3.3.3. within **similar initiatives**
8.2.3.3.4. within **similar departments,** and
8.2.3.3.5. **throughout the entire organization.**
8.2.3.3.6. Requirements that are represented in a general manner, without direct ties to a particular tool or organizational structure, tend to be more reusable.
8.2.3.3.7. Specific references to applications or departments limit the reuse of requirements and designs across an organization.
8.2.4. Guidelines & Tools
8.2.4.1. Information Management Approach
8.2.5. Techniques
8.2.5.1. Business Rules Analysis
8.2.5.2. Data Flow Diagrams
8.2.5.3. Data Modelling
8.2.5.4. Document Analysis
8.2.5.5. Functional Decomposition
8.2.5.6. Process Modelling
8.2.5.7. Use Cases and Scenarios
8.2.5.8. User Stories
8.2.6. Stakeholders
8.2.6.1. Domain SME
8.2.6.2. Implementation SME
8.2.6.3. Operational Support
8.2.6.4. Regulator
8.2.6.5. Tester
8.2.7. Outputs
8.2.7.1. Requirements (maintained)
8.2.7.2. Designs (maintained)
8.3. 5.3 - Prioritize Requirements
8.3.1. Purpose
8.3.1.1. to rank requirements in the order of relative importance
8.3.2. Inputs
8.3.2.1. Requirements
8.3.2.2. Designs
8.3.3. Elements
8.3.3.1. Basis for Prioritization (factors) **(PRD Prc BSC Ts)**
8.3.3.1.1. **Benefit**
8.3.3.1.2. **Penalty**
8.3.3.1.3. **Cost**
8.3.3.1.4. **Risk**
8.3.3.1.5. Dependencies
8.3.3.1.6. Time Sensitivity
8.3.3.1.7. Stability
8.3.3.1.8. Regulatory or Poilicy Compliance
8.3.3.2. Challenges of Prioritization
8.3.3.2.1. Stakeholders may also have difficulty characterizing any requirement as a lower priority, and this may impact the ability to make necessary trade-offs.
8.3.3.2.2. There may be a need for stakeholders to make trade-offs in prioritization.
8.3.3.3. Continual Prioritization
8.3.3.3.1. Initially, prioritization is done at a higher level of abstraction. As the requirements are further refined, prioritization is done at a more granular level and will incorporate additional bases for prioritization as they become appropriate.
8.3.3.3.2. Once the implementation team has provided the cost of each requirement, the stakeholders may re-prioritize yet again.
8.3.4. Guidelines & Tools
8.3.4.1. Business Constraints
8.3.4.2. Change Strategy
8.3.4.3. Domain Knowledge
8.3.4.4. Governance Approach
8.3.4.5. Requirements Architecture
8.3.4.6. Requirements Management Tools/Repository
8.3.4.7. Solution Scope
8.3.5. Techniques
8.3.5.1. Backlog Management
8.3.5.2. Business Cases
8.3.5.3. Decision Analysis
8.3.5.4. Estimation
8.3.5.5. Financial Analysis
8.3.5.6. Interviews
8.3.5.7. Item Tracking
8.3.5.8. Priotization
8.3.5.9. Risk Analysis and Management
8.3.5.10. Workshops
8.3.6. Stakeholders
8.3.6.1. Customer
8.3.6.2. End User
8.3.6.3. Implementation SME
8.3.6.4. Project Manager
8.3.6.5. Regulator
8.3.6.6. Sponsor
8.3.7. Outputs
8.3.7.1. Requirements (prioritized)
8.3.7.2. Design (prioritized)
8.4. 5.4 - Assess Requirements Changes
8.4.1. Purpose
8.4.1.1. to evaluate the implications of proposed changes to requirements and designs
8.4.2. Description
8.4.2.1. Assessment must be performed to determine whether a proposed change will increase the value of the solution, and if so, what action should be taken.
8.4.2.2. Business analysts also ensure each proposed change can be traced back to a need.
8.4.2.3. When assessing changes, business analysts consider if each proposed change: • aligns with the overall strategy, • affects value delivered to the business or stakeholder groups, • impacts the time to deliver or the resources required to deliver the value, and • alters any risks, opportunities, or constraints associated with the overall initiative.
8.4.3. Inputs
8.4.3.1. Proposed Change
8.4.3.2. Requirements
8.4.3.3. Designs
8.4.4. Elements
8.4.4.1. Assessment Formality
8.4.4.1.1. Business analysts will determine the formality of the assessment process based on the information available, the apparent importance of the change, and the governance process.
8.4.4.1.2. **A predictive approach may indicate a more formal assessment of proposed changes.** . In predictive approaches, the impact of each change can be disruptive; the change can potentially generate a substantial reworking of tasks and activities completed in previous activities.
8.4.4.1.3. **An adaptive approach may require less formality in the assessment of proposed changes. ** . While there may be reworking needed as a result of each change, adaptive approaches try to minimize the impact of changes by utilizing iterative and incremental implementation techniques.
8.4.4.2. Impact Analysis **BIC SU**
8.4.4.2.1. **Benefit**
8.4.4.2.2. **Cost**
8.4.4.2.3. **Impact**
8.4.4.2.4. **Schedule**
8.4.4.2.5. **Urgency**
8.4.4.3. Impact Resolution
8.4.4.3.1. All impacts and resolutions resulting from the change analysis are to be documented and communicated to all stakeholders.
8.4.5. Guidelines & Tools
8.4.5.1. Change Strategy
8.4.5.2. Domain Knowledge
8.4.5.3. Governance Approach
8.4.5.4. Legal/Regulatory Information
8.4.5.5. Requirements Architecture
8.4.5.6. Solution Scope
8.4.6. Techniques
8.4.6.1. Business Cases
8.4.6.2. Business Rules Analysis
8.4.6.3. Decision Analysis
8.4.6.4. Document Analysis
8.4.6.5. Estimation
8.4.6.6. Financial Analysis
8.4.6.7. Interface Analysis
8.4.6.8. Interviews
8.4.6.9. Item Tracking
8.4.6.10. Risk Analysis and Management
8.4.6.11. Workshops
8.4.7. Stakeholders
8.4.7.1. Customer
8.4.7.2. Domain SME
8.4.7.3. End User
8.4.7.4. Operational Support
8.4.7.5. Project Manager
8.4.7.6. Regulator
8.4.7.7. Sponsor
8.4.7.8. Tester
8.4.8. Outputs
8.4.8.1. Requirements Change Assessment
8.4.8.2. Designs Change Assessment
8.5. 5.5 - Approve Requirements
8.5.1. Purpose
8.5.1.1. to obtain agreement on and approval of requirements and designs for BA work to continue and/or solution construction to proceed
8.5.2. Description
8.5.2.1. Business analysts are responsible for ensuring clear communication of requirements, designs, and other business analysis information to the key stakeholders responsible for approving that information.
8.5.2.2. Approval of requirements and designs may be formal or informal. Predictive approaches typically perform approvals at the end of the phase or during planned change control meetings.
8.5.2.3. Adaptive approaches typically approve requirements only when construction and implementation of a solution meeting the requirement can begin.
8.5.2.4. Business analysts work with key stakeholders to gain consensus on new and changed requirements, communicate the outcome of discussions, and track and manage the approval.
8.5.3. Inputs
8.5.3.1. Requirements (verified)
8.5.3.2. Designs
8.5.4. Elements
8.5.4.1. Understand Stakeholder Roles
8.5.4.1.1. Business analysts are responsible for obtaining stakeholder approvals and are required to understand who holds decision-making responsibility and who possesses authority for sign-off across the initiative. Business analysts also consider any influential stakeholders who should be consulted or informed about the requirements. Few stakeholders may have the authority to approve or deny changes, but many stakeholders may be able to influence these decisions.
8.5.4.2. Conflict and Issue Management
8.5.4.2.1. To maintain stakeholder support for the solution, consensus among stakeholders is usually sought prior to requesting approval of requirements.
8.5.4.2.2. A conflict may arise among stakeholders as a result of different interpretations of requirements or designs and conflicting values placed on them. The business analyst facilitates communication between stakeholders in areas of conflict so that each group has an improved appreciation for the needs of the others. Conflict resolution and issue management may occur quite often, as the business analyst is reviewing requirements and designs, and aiming to secure sign-off.
8.5.4.3. Gain Consensus
8.5.4.3.1. Business analysts are responsible for ensuring that the stakeholders with approval authority understand and accept the requirements.
8.5.4.3.2. Complete agreement may not be necessary for a successful change, but if there is a lack of agreement, the associated risks are to be identified and managed accordingly
8.5.4.4. Track and Communicate Approval
8.5.4.4.1. The business analyst records approval decisions, possibly in requirements maintenance and tracking tools.
8.5.5. Guidelines & Tools
8.5.5.1. Change Strategy
8.5.5.2. Governance Approach
8.5.5.3. Legal/Regulatory Information
8.5.5.4. Requirement Management Tools/Repository
8.5.5.5. Solution Scope
8.5.6. Techniques
8.5.6.1. Acceptance and Evaluation Criteria
8.5.6.2. Decision Analysis
8.5.6.3. Item Tracking
8.5.6.4. Reviews
8.5.6.5. Workshops
8.5.7. Stakeholders
8.5.7.1. Customer
8.5.7.2. Domain SME
8.5.7.3. End User
8.5.7.4. Operational Support
8.5.7.5. Project Manager
8.5.7.6. Regulator
8.5.7.7. Sponsor
8.5.7.8. Tester
8.5.8. Outputs
8.5.8.1. Requirements (approved)
8.5.8.2. Designs (approved)
9. 9 - Underlying Competencies
9.1. 9.1 - Analytical Thinking and Problem Solving
9.1.1. 9.1.1 - Creative Thinking
9.1.2. 9.1.2 - Decision Making
9.1.3. 9.1.3 - Learning
9.1.4. 9.1.4 - Problem Solving
9.1.5. 9.1.5 - Systems Thinking
9.1.6. 9.1.6 Conceptual Thinking
9.1.7. 9.1.7 - Visual Thinking
9.2. 9.2 - Behavioural Characteristics
9.2.1. 9.2.1 - Ethics
9.2.2. 9.2.2 - Personal Accountability
9.2.3. 9.2.3 - Trustworthiness
9.2.4. 9.2.4 - Organization and Time Management
9.2.5. 9.2.5 - Adaptability
9.3. 9.3 - Business Knowledge
9.3.1. 9.3.1 - Business Acumen
9.3.2. 9.3.2 - Industry Knowledge
9.3.3. 9.3.3 - Organization Knowledge
9.3.4. 9.3.4 - Solution Knowledge
9.3.5. 9.3.5 - Methodology Knowledge
9.4. 9.4 - Communication Skills
9.4.1. 9.4.1 - Verbal Communication
9.4.2. 9.4.2 - Non-Verbal Communication
9.4.3. 9.4.3 - Written Communication
9.4.4. 9.4.4 - Listening
9.5. 9.5 - Interaction Skills
9.5.1. 9.5.1 - Facilitation
9.5.2. 9.5.2 - Leadership and Influencing
9.5.3. 9.5.3 - Teamwork
9.5.4. 9.5.4 - Negotiation and Conflict Resolution
9.5.5. 9.5.5 - Teaching
9.6. 9.6 - Tools and Technology
9.6.1. 9.6.1 - Office Productivity Tools and Technology
9.6.2. 9.6.2 - Business Analysis Tools and Technology
9.6.3. 9.6.3 - Communication Tools and Technology