IIBA Endorsed Business Analysis with Credit hours for IIBA Certification

Course Content
This course is designed to give students a solid knowledge in the role and responsibility of a Business Analyst. Topics are reinforced with intense hands-on practices including in class exercises, 7 Real-time based with reviews/feedback.

8 Projects are done thru out the BA course - Writing BRDs/FRDs/Use Cases/EPICs/Stories):

1. Project-1 – Creating a mock-up screen for a Healthcare application.
2. In class exercise for Project-2.
3. Project-2 – Airline Application – Writing an FRD/BRD.
4. In class exercise for Project-3.
5. Project-3 – Healthcare Application – Writing an FRD/BRD.
6. Project-4 – Mobile Application – Writing an FRD/BRD.
7. Project-5 – Banking Application – Writing a Usecase/UML diagram.
8. Project-6 – Healthcare Application – Writing a Usecase/UML diagram.
9. Project-7 – Healthcare Application – Agile-based – Writing EPICs/Stories.
10. Project-8 – Banking Application – Agile-based – Writing EPICs/Stories. Completing various types of diagrams using Visio

SQL, JIRA and Manual Testing Exercises
1. Writing Manual Test cases.
2. Writing various SQL statements using Oracle.
3. Creating requirements in JIRA.
4. UML and Swim-Lane diagrams using Visio or a similar tool.
5. Flowcharting using Visio or a similar tool

IIBA Endorsed Business Analysis Course Details:

1. Introduction:
1.1. Introduction IIBA, BABOK
1.2. Introduction to BA roles/responsibilities
1.2.1. What is Business Analysis
1.2.2. Role of a Business Analyst

2. System Development Methodologies [Part of 3.2]
2.1. Waterfall method
2.1.1. Various SDLC phases will be covered in detail
2.1.2. Requirement Phase/BA’s role – covered in detail
2.2. Rapid Application Development (RAD)
2.3. Spiral
2.4. Agile: Explain Agile
2.4.1. Scrum
2.4.1.1. Scrum Basics
2.4.1.2. Sprint
2.4.1.3. Product Backlog
2.4.1.4. Sprint Backlog
2.4.1.5. Burn down chart
2.4.1.6. Sprint Planning Meeting
2.4.1.7. Stand-up meeting.
2.5. Agile and JIRA
2.5.1. JIRA – Introduction
2.5.2. JIRA tool registration (Trail Version)
2.5.3. JIRA – Dashboard
2.5.4. Managing Product backlog
2.5.5. Sprint Creation
2.5.6. Managing Sprint Backlog
2.5.7. Creating sub tasks
2.5.8. Sprint Progress and logging work
2.5.9. Reporting defects
2.5.10. Sprint Closer
2.6. Introduction to Various Requirement types [Note – some of these topics will be taught along with methodologies like waterfall or Agile or will be taught later in the course. Just explicitly documenting that these topics will be covered)
2.6.1. User/Business Requirements
2.6.2. Functional Requirements
2.6.3. Non-Functional Requirements
2.6.4. Transition Requirements
2.6.5. UI (User Interface) requirements
2.6.6. System Requirements

3. Business Analysis Process:
3.1. Enterprise Analysis:
3.1.1. Define Business Need:
3.1.1.1. Identify Business goal/Objectives
3.1.1.2. Identify the Business problem
3.1.1.3. Desired Outcome
3.1.1.4. Define/Document Business nee
3.1.2. Assess Capability Gaps
3.1.2.1. Analyze current capability
3.1.2.2. Identify Gaps – problems/limitations
3.1.2.3. New capabilities required to meet the business need
3.1.3. Determine Solution
3.1.3.1. Identify Solutions
3.1.3.2. Identify methodology/Life-Cycle
3.1.3.3. Assess organization capability
3.1.3.4. Define Solution Approach
3.1.4. Define Solution/Scope (Project or Iteration)
3.1.5. Define Business Case:
3.1.5.1. Feasibility Study
3.1.5.1.1. Costs, time, manpower, value/Benefits etc.
3.1.5.2. Other things to consider for an external product
3.1.5.2.1. Analyzing competition
3.1.5.2.2. Understanding the market

3.2. Business Analysis Planning and Monitoring:
3.2.1. Select business analysis approach
3.2.1.1. Understand Existing process/objectives/factors.
3.2.1.1.1. Plan Driven vs. Change Driven
3.2.1.1.1.1. Discuss various methodologies [as in System Development Methodologies]
3.2.1.1.1.2. Requirements for the current project
3.2.1.1.1.3. Analyze Deliverables
3.2.1.1.1.4. Prioritization
3.2.1.1.1.5. Change Management
3.2.1.1.1.6. Stakeholders and Approvals.
3.2.1.1.1.7. Tools
3.2.1.1.1.8. Complexity of the project.
3.2.1.2. Conduct Stakeholder analysis
3.2.1.2.1. Who should participate
3.2.1.2.2. How many? The number of users.
3.2.1.2.3. Identify the business unit
3.2.1.2.4. Understand their approval level
3.2.1.2.5. RACI Matrix
3.2.1.3. Plan Business Analysis Activities
3.2.1.3.1. Identify business analysis deliverables
3.2.1.3.2. Determine Scope of work
3.2.1.3.3. When/What work will be done.
3.2.1.3.4. Develop Estimates
3.2.1.4. Plan Business Analysis Communication
3.2.1.4.1. Type of requirement documents
3.2.1.4.2. Elicitation techniques
3.2.1.4.3. Communicate – Who/what/when/how
3.2.1.4.4. Business Analysis Communication Plan
3.2.1.5. Plan Requirements Management Process
3.2.1.5.1. Plan how changes are handled – Change Management
3.2.1.5.2. Plan how changes are prioritized/approved
3.2.1.5.3. Plan Traceability
3.2.1.6. Manage Business Analysis Performance
3.2.1.6.1. Track, Report and corrective actions.

3.3. Elicitation:
3.3.1. Prepare for Requirement Gathering
3.3.1.1. Review/Understand Business needs/requirements
3.3.1.2. Plan what/when needs to be gathered
3.3.1.3. Identify who needs to be involved in this process
3.3.2. Conduct Requirement Gathering
3.3.2.1. Gather Requirements from the users/clients
3.3.2.1.1. Discuss various techniques used for gathering
3.3.2.1.1.1. Interview, Brainstorming, Focus Gps, JAD etc.
3.3.2.1.2. Other information to consider:
3.3.2.1.2.1. Tracing requirements
3.3.2.1.2.2. Capture Attributes like Priority
3.3.2.1.2.3. Attributes of a good requirement
3.3.2.1.2.4. Where to collect the requirements
3.3.3. Document Elicitation Results:
3.3.3.1. Meeting minutes/other written documents/recordings
3.3.3.2. Document Requirements
3.3.3.3. Document open issues/concerns/questions
3.3.4. Confirm Elicitation
3.3.4.1. Review Requirements with the stakeholder
3.3.4.2. Get approval from Stakeholders
3.3.5. Other:
3.3.6. Prototyping (wireframe):
3.3.6.1. Explain Prototyping
3.3.6.2. Homework using Axure tool
3.3.6.2.1. Create a mock up screen using a prototyping tool
3.3.7. Joint Application Development [JAD]
3.3.7.1. JAD discussion
3.3.7.2. Role of a BA
3.3.7.3. Key Participants
3.3.7.4. Steps for a successful JAD session
3.3.7.5. Mock JAD Session

3.4. Requirements Analysis:
3.4.1. Prioritize Requirements
3.4.1.1. Basis for Prioritization
3.4.1.2. Challenges.
3.4.1.3. Discuss MOSCOW
3.4.1.4. Timeboxing/Budgeting
3.4.2. Organize Requirements
3.4.2.1. Guidelines for organizing requirements
3.4.2.2. Level of Abstraction
3.4.2.3. Model selection
3.4.2.3.1. Why Models
3.4.2.3.2. Modeling Concepts
3.4.2.4. Techniques
3.4.2.4.1. Data Modeling
3.4.2.4.2. Process Flow Diagrams/Business Process Modeling
3.4.2.4.3. Use cases
3.4.2.4.4. User Story boarding
3.4.3. Specify and Model Requirements
3.4.3.1. Writing requirements (Stakeholder/Solution)
3.4.3.1.1. Guidelines
3.4.3.2. Matrix Documentation
3.4.3.3. Process modeling, prototyping, use cases, UML Diagrams
3.4.3.4. Define attributes.
3.4.4. Define Assumptions and Constraints
3.4.4.1. Document Assumptions
3.4.4.2. Document Constraints
3.4.4.2.1. Business
3.4.4.2.2. Technical
3.4.5. Verify Requirements
3.4.5.1. Check for Quality
3.4.5.2. Various verification activities
3.4.5.3. Reviews:
3.4.5.3.1. Internal Review
3.4.5.3.2. Customer/SME/Stakeholder Review
3.4.5.3.3. Team Review: BA, Customer/SME, Technology Teams
3.4.6. Validate Requirements
3.4.6.1. Business Value:
3.4.6.1.1. Techniques for validating requirements
3.4.6.1.2. Deliver value to customers?
3.4.6.1.3. Aligned with business goals and objectives?

3.5. Requirements Management and Communication
3.5.1. Manage Solution Scope & Requirements
3.5.1.1. Formal walk-through with the stakeholders
3.5.1.2. Getting the approval from the stakeholders
3.5.1.3. Changes
3.5.1.4. Base lining requirements
3.5.1.5. Change Management vs. Change Driven
3.5.2. Manage Requirements Traceability
3.5.2.1. Identify and document
3.5.2.1.1. Backward traceability
3.5.2.1.2. Forward traceability
3.5.2.1.3. Benefits:
3.5.2.1.3.1. Impact Analysis
3.5.2.1.3.2. Requirements Coverage
3.5.2.1.3.3. Requirements Allocation
3.5.3. Maintain Requirements for Re-use
3.5.4. Prepare Requirements Package
3.5.4.1. (Possible) List of documents in a package
3.5.4.2. Documents for Vendor Selection
3.5.5. Communicate Requirements
3.5.5.1. General Communication
3.5.5.1.1. Enterprise Analysis Tasks
3.5.5.1.2. Elicitation Tasks
3.5.5.1.3. Requirements Analysis Tasks
3.5.5.1.4. Solution Assessment and Validation Tasks
3.5.5.2. Handling a Presentation
3.5.5.3. Who is involved in this process

3.6. Solution Assessment and Validation
3.6.1. Assess Proposed Solution
3.6.1.1. Assessing a single solution
3.6.1.2. Assessing multiple solutions
3.6.1.3. Selecting a solution
3.6.2. Allocate Requirements
3.6.2.1. Solution components
3.6.2.2. Release handling
3.6.3. Assess Organizational Readiness
3.6.3.1. Cultural Assessment
3.6.3.2. Operational or Technical Assessment
3.6.3.2.1. Training
3.6.3.2.2. Documentation
3.6.3.2.3. Stakeholder Impact Analysis
3.6.4. Define Transition Requirements
3.6.4.1. What is Transition Requirements
3.6.4.2. Why it is needed
3.6.5. Validate Solution
3.6.5.1. Investigate Defective Solution Outputs
3.6.5.1.1. Requirement or
3.6.5.1.2. Application
3.6.5.1.3. Assess Defects and Issues
3.6.6. Evaluate Solution Performance
3.6.6.1. Post-implementation assessment
3.6.6.1.1. Understand and evaluate the value of the solution
3.6.6.1.2. Solution Replacement or Elimination

3.7. Underlying Competencies
3.7.1. Analytical Thinking and Problem Solving
3.7.2. Behavioral Characteristics
3.7.3. Business Knowledge
3.7.4. Communication Skills
3.7.5. Interaction Skills
3.7.6. Software Applications

3.8. Techniques and Hands-on BA exercises are listed here.
3.8.1. Techniques
3.8.1.1. Decision Analysis
3.8.1.2. Estimation
3.8.1.3. Metrics and Key Performance Indicators
3.8.1.4. Risk Analysis
3.8.1.5. SWOT Analysis
3.8.1.6. Vendor Assessment

4. Software Testing Life Cycle
4.1. Test Plan Preparation
4.1.1. Test Case Design
4.1.2. What is testing? Why to test?
4.1.3. What is a test case?
4.1.4. How to develop test cases from IT requirements?
4.1.5. Test Case Design Techniques
4.1.6. Test Cases: In class 9 to 10 Manual Testing Exercises and Homework
4.1.7. Cover real-time applications.
4.2. Test Execution
4.3. Defect Reporting
4.3.1. What is Defect?
4.3.2. Bug Life Cycle
4.3.3. Defect Log Format
4.3.4. Understanding Priority and Severity
4.3.5. Example
4.4. Test Report preparation
4.5. Testing Types
4.5.1. White box testing
4.5.2. Blackbox testing
4.5.2.1. Functional
4.5.2.1.1. Smoke Testing, System Testing
4.5.2.1.2. End to End Testing, Regression Testing
4.5.2.1.3. Retesting
4.5.2.1.4. Concurrency Testing, Exploratory Testing
4.5.2.1.5. Compatibility Testing, User Acceptance (UAT) Testing
4.5.2.2. Non Functional Testing
4.5.2.2.1. GUI Testing
4.5.2.2.2. Performance testing
4.5.2.2.3. Security Testing

5. SQL and Advanced SQL
5.1. Introduction to SQL
5.1.1. SQL
5.1.2. Database
5.1.3. Table, Rows and Columns
5.1.4. Data Types
5.1.5. Primary, Alternate/Secondary Keys/NOT NULL/UNIQUE/CHECK and Foreign Keys
5.2. Statements:
5.2.1. SQL
5.2.2. Select and Select *
5.2.3. Column Alias, Null Value, Arithmetic Expressions
5.2.4. Concatenation Operator(||), Literal, DISTINCT
5.2.5. Where
5.2.6. Order By (Desc, Asc)
5.2.7. And & OR, Like
5.2.8. Not
5.2.9. IN
5.2.10. Not In
5.2.11. Insert, Update, Delete
5.2.12. DESCRIBE
5.3. Advanced SQL with Oracle
5.3.1. SQL commands:
5.3.2. Update, Delete
5.3.3. Create, Alter, Drop
5.3.4. Truncate, Select with various operators,
5.3.5. Count, Sum, Distinct,
5.3.6. Order by, Group by, Having
5.3.7. Working With Dates
5.3.8. Sub Query
5.3.9. Introduction to Joins
5.3.9.1. Inner Join
5.3.9.2. Self Join
5.3.9.3. Outer Joins – Left/Right/Full
5.3.10. Hands on all above with Oracle APEX online
5.4. Why QA professionals need to know SQL basics
5.4.1. Sample queries for data verification
5.4.2. acquiring test data
5.4.3. SQL Injection attack
5.4.4. What to test in Relational DB apps

Disclaimer: Yes-M Training and/or their instructors reserve the right to make any changes to the syllabus as deemed necessary to best fulfill the course objectives. Students registered for this course will be made aware of any changes in a timely fashion using reasonable means.