Business Analysis - Essentials
-
Upload
barbara-bermes -
Category
Technology
-
view
1.433 -
download
0
Transcript of Business Analysis - Essentials
Barbara Bermes
Fundamentals of BUSINESS ANALYSISGlobal Knowledge, March 2011
Thursday, February 16, 2012
Overview
✤ Role of a BA - Solving “the problem”
✤ Business Analysis as part of a Project
✤ Eclication (Techniques)
✤ Stakeholders and Stakeholders Profiles
✤ Vision and Scope Document
✤ Business Needs & Business Requirements
✤ BRD - Business Requirements Document
✤ Business Plan
✤ How to apply all of this to CBC
Thursday, February 16, 2012
Before we start...
✤ Have you ever worked on a project that was understood like this....
Thursday, February 16, 2012
A project: from concept to delivery
Thursday, February 16, 2012
CHAOS Report
✤ Common Reasons for Project Failure
✤ Incomplete requirements
✤ Changing requirements
✤ A requirement is something that a particular solution (product or service) must have to ensure success
Thursday, February 16, 2012
So why do we need BAs?
✤ To help identify the problem
✤ To suggest a solution of the problem
✤ To meet the business needs related to the problem
✤ Bridge between the business and the stakeholders
✤ Need to understand all aspects of the solution
✤ How things are (as-is) and how they should be (to-be)
✤ Represent users to development team
✤ Filter wishes from actual requirements
Thursday, February 16, 2012
The Definition of Business Analysis
✤ “Business analysis is the set of tasks and techniques used to
work as a liaison among stakeholders in order to understand
the structure, policies, and operations of an organization,
and to recommend solutions that enable the organization to
achieve its goals”
(The BABOK Guide, Business Analysis Body of
Knowlegde)
Thursday, February 16, 2012
BA, PM, SA
Role Primary Focus Example
Project Manager Project Budget, schedule
Business Analyst Business needs Value business results, product/service provided
System Analyst Technical solution Specifications
Thursday, February 16, 2012
Knowledge Areas of a BA
Thursday, February 16, 2012
BA Tasks
✤ Vision and Scope Document
✤ Planning requirement activities
✤ Requirements Elicitation
✤ Analyzing requirements
✤ Documenting requirements
✤ Verifying and Validation requirements
✤ Final testing of the solution
✤ Find solution to meet organizational goals
Thursday, February 16, 2012
Definition of Requirement
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents
3. A documented presentation of a condition or capability as in (1) or (2)
- The BABOK Guide
Thursday, February 16, 2012
Requirements Planning: Vision and Scope Document
✤ Current state and desired state from the business perspective
✤ In-scope and out-of-scope solution features
✤ Puts the solution in the business context
Thursday, February 16, 2012
Requirements Planning: Vision and Scope Document
✤ Background: Need for solution
✤ Users and Stakeholders
✤ Vision Statement: How stakeholders envision the solution, purpose and intent
✤ In/Out Scope Features
✤ Assumptions, add some degree of risks
✤ Constraints
✤ Risks, Business, Financial, Technical, including Risk Mitigation, contingency
Thursday, February 16, 2012
Stakeholders
✤ Sponsor
✤ Business Analyst
✤ Project Manager
✤ Customer
✤ End User
✤ Domain SME
✤ Implementation SME
✤ Tester
✤ Regulator
✤ Supplier
Thursday, February 16, 2012
Stakeholder Profiles
✤ Demographics
✤ Role and responsibilities
✤ Solutions attitude
✤ Number
✤ Location
✤ Special needs
✤ Name and Title
✤ Solution influence
✤ Authority
Thursday, February 16, 2012
Requirements Elicitation
✤ Elicitation is not requirements gathering (implies that requirements already exist)
✤ Merriam-Webster Online Dictionary, elicitation means:
✤ To draw forth or bring out (something latent or potential)
✤ To call forth or draw out (as information or a response)
Thursday, February 16, 2012
Elicitation Techniques
Preplanning Preparation
Closing Execution
Thursday, February 16, 2012
Peoples Techniques
✤ People techniques are used when your resource for requirements is a person
✤ Each person poses different challenges
Thursday, February 16, 2012
Techniques
Technique When/AdvantageInterview need general information about requirements, want
stakeholders to explain their needs, conflicting req.
Focus Group want to gauge users’ attitude and preferences towards solution or current situation
Requirements Workshop Need requirment consensus on noncontroversial issues, want to generate ideas, review requirments
Brainstorming creative, innovative solutions (large number of solutions)
Observation Need to learn about user’s environment, need to understand workflow, need information that user can’t provide fully
Survey Only short time, have a lot of remote users to contact, need statistical and survey writing abilities
Prototyping Identify usability issues, concrete representation of the proposed solution to elicit feedback
Product Trials see how competitors solve the problem, see if COTS (commercial off-the-shelf) product might be the solution
Thursday, February 16, 2012
Select Techniques
✤ Always consider these three factors
✤ Stakeholders
✤ Requirement type
✤ Product geography
Thursday, February 16, 2012
Using Models for Analysis
✤ Model: A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication and understanding (The BABOK Guide)
Thursday, February 16, 2012
Models/Diagrams
✤ Organizational Model: to show stakeholders connections, roles, help to understand the scope of the organization
✤ Location Model: show geographical locations and facilities
✤ Process Model: show business process,
✤ Visual presentation of the order, flow, and logic that controls a set of activities or actions,
✤ Excellent to show as-is and to-be state
Thursday, February 16, 2012
Models
✤ Use Case Model: describes a system’s behavior as it responds to the request that originates from outside of that system
✤ Can easily be understood
✤ Identify possible mistakes
✤ CRUD (Create-Read-Update-Delete) Matrix: describes users permissions to manipulate the data
Thursday, February 16, 2012
Models
✤ Data Model/ERD Diagram: describe the information needs of the business area, data is clustered around the concept of a real-world object or event
✤ State Diagram: show how and why a data item, or a system, changes state, sued to identify missing requirements related to business rules, events, data attributes, use cases, and procedural steps
Thursday, February 16, 2012
Types of Requirements
✤ Business RequirementsDescribe the reasons a project is started, its objectives, and its success measures in terms of the organization as a whole
✤ Stakeholder Requirements Capture and describe requirements of a particular stakeholder or stakeholder group
✤ Solution RequirementsDescribe the behavior or capabilities of the component of the solution
✤ Transition RequirementsDescribe the capabilities that the solution must process in order to assist the change from current state to the desired future state of the enterprise
Thursday, February 16, 2012
Prioritization of Requirements
✤ Consents/Agreements with stakeholders what requirements are high-priority / low-priority in order to proceed/succeed with the solution
✤ Make sure requirements are accurate with stakeholders
Thursday, February 16, 2012
Requirements Documentation
✤ Business Requirements Document
✤ Verification
✤ Validation
✤ Sign-Off
Thursday, February 16, 2012
Why Documentation
✤ Stakeholders need to see a clear set of requirements which they can affirm their needs to, evaluate the end solution
✤ Development Team needs clear set of requirements,
✤ Alleviate Risks
✤ Stakeholders can give feedback and to reduce risks
Thursday, February 16, 2012
How to document
✓ CohesiveRequirements about a particular feature should be grouped together
✓ ConsistentRequirements should not be duplicated, nor should they contradict each other. The level of detail should also be consistent. The terminology should be consistent with the language used in the organization
✓ ModularRequirements should be presented in such a way that changes can be made easily without affecting other unrelated requirements
✓ Unambiguous Requirements should mean the thing to anyone who reads them
Thursday, February 16, 2012
Common BRD Defects
BRD Defects Effects
Information hard to find or unclear Reviewers miss other defects; developer does not follow requirements
Requirements not clearly differentiated from other information
Features are added into product that should not be there
Importance of each requirement is not documented
Tester concentrates on the wrong requirements
Requirements not numbered Review of requirements is wrong
Thursday, February 16, 2012
Tips for writing BRD
✓ Use simple language
✓ Visual methods
✓ Use “shall”
✓ Importance ratings
✓ Unique identifiers
✓ Rational
Thursday, February 16, 2012
Time Boxing
✤ Time Management Technique that divides the schedule into a number of separate time periods/boxes where each box has its own deliverables, deadline and budget
Thursday, February 16, 2012
Verification
✤ Verification of requirements, must be
✤ Consistent
✤ Complete
✤ Correct
✤ Feasible
✤ Validable
Thursday, February 16, 2012
Validation
✤ Ensure that the requirement supports the business goals and objectives meet the business needs
✤ Rule: If requirement cannot be validated as business need, it should be eliminated
Thursday, February 16, 2012
Verification and Validation Techniques
✤ DESK CHECKING, individually go to desks and talk to stakeholders, time intensive
✤ WALKTHROUGH, efficient method of finding defects, normally with a group of people
✤ PEER REVIEW, walkthrough of group of people with same level to find defects
Thursday, February 16, 2012
Requirements Sign-Off
✤ Sometimes called Requirements Gate
✤ Releases the funds for the project
✤ Make sure stakeholder / sponsor actually read the document
Thursday, February 16, 2012
Requirements Management and Communication
✤ Happens throughout the whole life cycle
✤ Everyone should always have the same understanding of the solution scope
✤ BAs manage conflicts, issues and changes
Thursday, February 16, 2012
Change Control Process / Request
✤ Receive solution change request
✤ Determine impact of not implementing change
✤ Determine impact of implementing change
✤ Make decision
✤ Communicate actions to be taken
✤ Check if actions have been taken
✤ Changed need to be aligned with projects vision and scope
✤ Change needs approval
Thursday, February 16, 2012
Change Requests - Steps
✤ Change request (CR) needs to be defined, its impact , should be numbered and tracked
✤ CR will be received by anyone who might be affected
✤ Change Authority (CA) meets with everyone who is affected by the change
✤ CA makes the decision. The CA can be a PM, sponsor or Change Control Board (CCB)
Thursday, February 16, 2012
Requirement Attributes
✤ Gives additional information about requirement
✤ Unique identifier
✤ Source
✤ Priority
✤ Rationale
Thursday, February 16, 2012
Requirements Communication
✤ Goal is
✤ to find the best way of communication with each stakeholder
✤ to make all stakeholders understand the requirements
✤ to make all stakeholders understand the BRD
Thursday, February 16, 2012
Ways of Communication
✤ Emails
✤ Workshops
✤ Formal presentations, using slides and handouts
✤ Reports
✤ Memos
✤ Meetings, formal / informal
✤ Walkthroughs
Thursday, February 16, 2012
Requirements Documentation
✤ Requirements activity status: Status reports include wether or not deadlines are being met or if the schedule has changed
✤ Requests for requirement feedback and approval: Ask for feedback or approval during requirements elicitation and when a requirement change is requested
✤ Notifications of requirement changes: Even if a stakeholder does not have to approve the change, he or she should always be notified of any changes to the original requirements baseline
Thursday, February 16, 2012
Solution Validation and Acceptance
✤ Assessments performed during solution validation include both
✤ Testing: solutions is run using defined inputs in a defined enviornment with defined expected outputs
✤ Non-testing methods: Calculating, Simulating, Prototyping, Analyzing, Reading documents, obtaining user feedback
Thursday, February 16, 2012
Purpose of Validation
Uncovering solution defects
Proving compliance to the
requirements+ = Validation
GOAL is to identify as many defects in the solution as possible
Thursday, February 16, 2012
The Art of Testing
Performing the smallest number of tests
Finding the greatest number of defects
Thursday, February 16, 2012
Levels of Testing
✤ Unit Testing: conducted by software developers
✤ Integration Testing: conducted by developers, QA
✤ System Testing: conducted
✤ Business-level testing/acceptance testing: solution tested against the BRD requirements, followed by sign-off, managed by BA
✤ Stakeholder assessment: conducted after system has been deployed
Thursday, February 16, 2012
Role of BA during Testing
✤ The BA is responsible for providing assurance to the PM and the customer that all of the solution testing is adequate
Thursday, February 16, 2012
Solution Acceptance and Closeout
✤ Sponsor is completely in charge of selecting the evidence he or she feels provides the requisite comfort needed to accept and use the solution within the scope of the requirements
✤ Once the solution is accepted, the ownership passes from project team to sponsor and the project is considered completed
Thursday, February 16, 2012
Enterprise Analysis
✤ Normally executed/done by Senior BAs or Business Architects
✤ Define the business need
Thursday, February 16, 2012
Enterprise Analysis - Business need
✤ Basis of the business analysis activities related to determining a solution
✤ Clearly defining the problem to find the solution
✤ Ask questions: Who? What? When? Where? Why? and How?
✤ Includes Root cause Analysis as the identification and evaluation of the reason for the problem
Thursday, February 16, 2012