Skip Ribbon Commands
Skip to main content

BA2012 - Business Analysis Workshop 2012

Price:

Duration: 5 Days

Audience:

Level:

Technology:

Delivery Method:

Software Assurance Value:

Microsoft CPE:

Course Information

Course Description

​Business analysis involves understanding and articulating requirements, which always has been the weakest link in projects.  For systems, up to 67 percent of maintenance and 40 percent of development is wasted rework and creep largely attributable to inadequately defined business requirements.  Too often projects proceed based on something other than what the business really needs; and development methodologies commonly focus mainly on the format for representing requirements of the product to be created without adequately ascertaining the content it must provide.  Format of course is important too; and of all the factors that can impact requirements, lack of clarity is the most apparent.   In turn, Testability—the ability to demonstrate that a requirement has or has not been met—is perhaps the single most effective indicator of clarity. 

If one cannot define how to test that a requirement has been met, then it’s unlikely the developer will be able to meet the requirement correctly; and regardless there’s no test to confirm the requirement was met.  Using the powerful Problem Pyramid™ and other techniques, this interactive workshop first gives participants practice discovering and documenting an actual case’s REAL business requirements content what a product must do to produce value for stakeholders.  Next, participants examine factors affecting clarity and ways to overcome testability issues.  Then participants practice defining and writing requirements of a product/system/software how to satisfy the REAL business requirements and testing that requirements indeed have been met.  Finally, the course describes methods for managing the requirements and the business analysis itself.  

Course Objectives

​You will learn:

  • Role, importance, and issues of business analysis and models affecting defining business requirements.
  • Distinctions between the REAL user's (business) requirements and the product's (design) requirements.
  • How to gather data, spot the important things, and interpret them meaningfully.
  • What differentiates more effective requirements discoverers from less effective one.
  • Using the Problem Pyramid™ tool to clearly define problems, value, causes, and real requirements.
  • Formats for analyzing, documenting, and communicating business requirements.
  • Writing ‘good’ clear and testable product/system/software requirements specifications and use cases.
  • Defining ways to test that requirements have been met.
  • Techniques and automated tools to manage requirements changes and the business analysis itself.

Course Audience

​This course has been designed for business analysts, systems and business managers, project leaders, programmer analysts, quality/testing professionals, auditors, and others responsible for assuring projects deliver needed value.

Course Outline

BUSINESS ANALYSIS (BA) ROLE AND IMPORTANCE
  • How requirements produce value
  • Sources and economics of system errors
  • Survey on improving requirements quality
  • Business analysis role inconsistent attention
  • Project management model misses key BA
  • Business analyst vs. project manager roles
  • System development model BA conflicts
  • BABOKÒ v2 model Knowledge Area issues
  • Business vs. product/system requirements
  • Common erroneous requirements beliefs
  • A different, better model
  • Integrating business and analysis
  • Requirements process overview
  • Exercise:  Review BA’s requirements
DISCOVERING REAL BUSINESS REQUIREMENTS
  • Discovering, not gathering, requirements
  • Quantifying value
  • REAL vs. presumed processes
  • Requirements are the should be process
  • Horizontal processes and vertical silos
  • The “we don’t have time” fallacy
  • Problem Pyramid™ tool to get on track
  • Exercise:  Your Problem Pyramid™
  • Exercise:  Applying Evaluation Guidelines
  • Aligning strategy, management, operations
  • Technology requirements vs. design
  • Management/supervisor vs. worker views
  • Who should define requirements
  • Exercise:  Review BA’s recommendation
  • Exercise:  Identifying the REAL problem
GATHERING AND ANALYZING DATA
  • Why bother gathering data
  • Surveys and questionnaires
  • Literature search
  • Reviewing documents
  • Observing operations
  • Participating and learning to do the work
  • Joint Application Development (JAD) limits
  • Prototyping and proofs of concept
  • Interviewing—planning key to success
  • Controlling with suitable questions
  • Exercise:  Plan and conduct interviews
  • Exercise:  Review and evaluate interviews
  • Exercise:  Identifying what else to know
FORMATS/MODELS TO AID UNDERSTANDING
  • Four ways to add meaning to data
  • Business rules, structured English
  • Cause-and-effect graphing
  • Decision trees and decision tables
  • Entity-Relationship diagrams, data models
  • Flow charts and data flow diagrams
  • Organization, responsibility, RACI charts
  • Performance, volume, frequency statistics
  • Sample forms, reports, screens, menus
  • Exercise:  Apply data analysis techniques
  • Natural and non-natural segments
  • Process maps
  • Exercise:  Confirming problem, causes
FORMATS FOR DOCUMENTING/ COMMUNICATING
  • Commonalities of requirements formats
  • Itemized deliverables vs. narratives, diagrams
  • IEEE standard for software requirements
  • “Pigeon-holing” strengths and weaknesses
  • Use cases, advantages and warnings
  • 7 guidelines for documenting requirements
  • Hierarchical business deliverable whats
  • Exercise:  Write top-level requirements
  • Exercise:  Review top-level requirements
  • Conceptual system design solutions
  • Requirements negotiation
  • Requirements vs. implementation scope
  • Iterating to avoid analysis paralysis
  • Key to making reliable cost/time estimates
  • Driving down to more detail
  • Exercise:  Making subjective objective  
DEFINING PRODUCT/SOFTWARE REQUIREMENTS
  • Causes of poor software requirements
  • Specifying the invented the product/system
  • Conceptual design guide to product features
  • Exercise:  Product feature requirements
  • Writing ‘good’ requirements
  • Exercise:  Reviewing feature requirements
  • Characteristics of a ‘good’ SRS
  • Correct, complete, feasible/necessary
  • Exercise:  Review for correct and complete
  • Exercise:  Review for consistency
  • Ambiguity, warning about total elimination
  • Exercise:  Inherently ambiguous terms
  • Exercise:  Logical ambiguities
  • Verifiable (testable),  issues
  • Making the untestable testable
  • Exercise:  Write test cases
  • Writing ‘good’ requirements
WRITING USE CASES AND SPECIFICATIONS
  • Suggested use case creation steps
  • Actors and system boundary
  • Use case diagram
  • Use case textual contents
  • Exercise:  Narrative use case format
  • Exercise:  One-column use cases
  • Exercise:  Happy, alternate paths
  • Use case strengths, weaknesses
  • Exercise:  Supplementary specifications
  • Functionality matrix
  • Structural testing concepts, flowgraphing
  • Exercise:  Flowgraph two-column use case
  • Testing each use case path/scenario, warning
  • Exercise:  Other use case test conditions
PERFORMING REQUIREMENTS-BASED TESTS
  • Business analyst’s testing roles
  • What is requirements-based testing, issues
  • Gurus equating with favored test technique
  • Black-box (functional) risk-based testing
  • Overemphasis on testability/clarity
  • Superficial over-reliance on use cases
  • Proactive Testing™ reviews catch more
  • Exercise:  Identify missing stakeholders
  • Proactive Testing™ planning, design too
  • Risk elements and testing
  • Dynamic, passive and active static testing
  • V-model levels of testing, objectives
  • Proactive TestingÔ Life Cycle model
  • Agile user story acceptance tests vs. UAT
  • Proactive user acceptance criteria
  • Functionality the user must demonstrate
  • How much, how often user must test
  • Determining system quality
  • Who should carry out acceptance tests
  • How acceptance tests should be performed
  • Added benefit, revealing requirements errors
  • IEEE Standard for Test Documentation
  • Overcoming controversial interpretations
  • Testing structure’s advantages
  • Enabling manageability, reuse, selectivity
  • Test plans, designs, cases, procedures
  • Proactive Testing™ risk analysis
  • Exercise:  Identify project-level risks
  • Letting testing drive development
  • Exercise:  Identify detailed test plan risks
  • Exercise:  Identify test design risks
  • Checklists and guidelines identify more
  • Decision trees and tables for business rules
  • Exercise:  Create a decision table
  • Checklist of common test concerns
  • Equivalence classes, boundary testing
  • Test script and matrix formats
MANAGING THE BA AND THE REQUIREMENTS
  • Supporting, controlling, tracing changes
  • Automated requirements management tools
  • Traceability matrix, forward and backward
  • What is a test case, relevance to tracing
  • Business analysis is a project to be managed
  • Project manager’s triangle, triple constraints
  • Project success starts with results
  • Work breakdown structure idenifies tasks
  • Estimate target and reference considerations
  • Weighted average, variance to control risk
  • Intrinsic vs. extrinsic schedule factors
  • Critical path, network (dependency) diagram
  • Monitoring milestones and checkpoints
  • 3 ways to determine percentage completion
  • Earned value measure, depict graphically
  • Project manager’s job, key to advancement
  • Measuring the "proof of the pudding"

Course Prerequisites

Course Schedule
This course is not scheduled yet.