Please enable JavaScript.
Coggle requires JavaScript to display documents.
Business Analysis for Practitioner (Requirements Elicitation and Analysis,…
Business Analysis for Practitioner
Business Analysis Planning
Conduct/Refine the stakeholder analysis
Create the business analysis plan
Plan the business analysis work
Review the business plan with key stakeholders
Obtain approval of the business analysis plan
Need Assessment
Identify Problems/Opportunity
Assess current state of organisation
Recommend action to address business need
Assemble the business case
Requirements Elicitation and Analysis
What it means to eliciting information
Elicitation is more than requirements collection or gathering
Importance of eliciting information
Support executive decision making
Apply influence successfully
Assist in negotiation or mediation
Resolve conflicts
Define problems
Plan for elicitation
Develop the elicitation plan
What information to elicit?
Where to find that information?
How to obtain that information?
Sequencing the elicitation activities
Finding information
Techniques for eliciting information
Prepare the elicitation
Determine the objectives
Determine the participants
Determine the questions for the session
Conduct elicitation activities
Introduction
Body
Types of questions
How to ask the "right" questions
Listening
Close
Follow-up
Elicitation techniques
Brainstorming
Document analysis
Facilitated workshops
Overview
Workshop preparation
Invite participants by roles
Tips for running a workshop
Closing tips
Follow-up tips
Focus groups
Interviews
Structured interviews
Unstructured interviews
Synchronous interviews
Asynchronous interviews
Observation
Passive observation
Active observation
Participatory observation
Simulation
Prototyping
Low-fidelity prototyping
High-fidelity prototyping
Questionnaires and surveys
Document outputs from elicitation activities
Complete elicitation
Elicitation issues and challenges
The business analyst cannot gain access to the right stakeholders
Stakeholders do not know what they want
Stakeholders are having difficulty defining their requirements
Stakeholders are not providing sufficient detail to develop the solution
Analyze requirements
Plan for analysis
Analysis defined
Thinking ahead about analysis
What to analyze
Model and refine requirements
Description of models
Purpose of models
Categories of models P90
Selection of models
Methodology
Characteristics of the project
Timing within the project life cycle
Categories of models
Level of abstraction
User models to refine requirements
Modeling languages
Scope models
Goal model and business objective model
Ecosystem map
Context diagram
Feature model
Use case diagram
Process models
Process flow
Use case
User story
Rule models
Business rules catalog
Decision tree and decision table
Data models
Entity relationship diagram
Data flow diagrams
Data dictionary
State table and state diagram
Interface models
Report table P113
System interface table
User interface flow
Wireframes and display-action-response
Document the solution requirements
Why documentation is important
Business requirements document
The solution documentation
Requirements
Categorization
Scope filter
Functional filter
Prioritization filter
Testability filter
Requirements specification
Documenting assumptions
Documenting constraints
Guidelines for writing requirements
Functional requirements
Unambiguous
Precise
Consistent
Correct
Complete
Measurable
Feasible
Traceable
Testable
Prioritizing requirements
Prioritization schemes
MoSCoW
Multivoting
Time-boxing
Weighted ranking
Technical requirements specification
Documenting with use cases
Documenting with user stories
Backlog items
Validate requirements
The concept of continual confirmation
Requirements walkthroughs
Verify requirements
Peer reviews
Inspections
Approval sessions
Resolve requirements-related conflicts
Delphi
Multivoting
Weighted ranking
Traceability and Monitoring
Traceability
What is traceability
Benefit of tracing requirement
Helps to ensure that each requirement adds business value
Helps to meet customer expectation
Helps to manage scope
The traceability matrix
Requirements attributes
Traceability matrix hierarchy
Relationships and dependencies
Subsets
Implementation dependency
Benefit or value dependency
Approving requirements
Work authorization system
Approval levels
Approval vs. signoff
Reviewer vs. approver
Approval authority vs. accountability
Rejection of requirements
Change control board(CCB) and approval of changes
Expert judgement and the approval process
Baselining approved requirements
What is a requirement baseline
Relationship of requirements baseline, product scope and project scope
Maintaining the product backlog
Monitoring requirements using a traceability matrix
Benefits of using traceability to monitor requirements
The requirements life cycle
Manage changes to requirements
Change management as it relates to business analysis
Change control tools and techniques
Configuration management system(CMS)
Version control system(VCS)
Impact analysis
Impact on the requirements baseline
Impact on whether a proposed change conflicts with other requirements
Impact on business analysis
Impact on project management
Recommending a course of action
Controlling changes related to defects
Solution evaluation
Purpose of solution evaluation
Recommended mindset for evaluation
Evaluate early and often
Treat requirements analysis, traceability, testing, and evaluation as complementary activities
Evaluate with the context of usage and value in mind
Confirm expected values for software solutions
Plan for evaluation of the solution
Determine what to evaluate
Consider the business goals and objectives
Consider key performance indicators
Consider additional evaluation metrics and evaluation acceptance criteria
Project metrics as input to the evaluation of the solution
Customer metrics
Sales and marketing metrics
Operational metrics and assessments
Functionality
Confirm that the organisation can continue with evaluation
When and How to validate solution results
Surveys and focus groups
Results from exploratory testing and user acceptance testing
Result from Day in the life(DITL) testing
Results from integration testing
Expected vs. actual results for functionality
Expected vs. actual results for non-functional requirements
Outcome measurement and financial calculation of benefits
Evaluate acceptance criteria and address defects
Comparison of expected vs. actual results
Examine tolerance ranges and exact numbers
Log and address defects
Facilitate the go/no-go decision
Obtain sign-off of the solution
Evaluate the long-term performance of the solution
Determine metrics
Obtain metrics/measure performance
Analyze results
Assess limitations of the solution and organiztion
Recommend approach to improve solution performance
Solution replacement/Phase out