Course Taxonomy: Enterprise & Product Agility

CBAP Certification Prep Boot Camp

Posted on October 17, 2020 by -

Part 1: Welcome to Boot Camp

We'll start the CBAP® Certification Prep Boot Camp with an overview of what "Certified Business Analysis Professional® " means—what it is and what it isn't. Under your instructor's guidance, you'll have a chance to discover some of the most important philosophies and aspects of the CBAP® examination, setting the tone for this fast-paced and interactive learning experience. And to get you ready for the workshop to come, we'll give you a preview of the CBAP® course content and our process for delivering a valuable learning experience.

  1. Components of the CBAP® certification
  2. Introduction to the CBAP® examination
  3. Philosophy of the exams
  4. Overview of CBAP® exam content
  5. Overview of the CBAP® Prep Boot Camp

Part 2: CBAP® Certification: The Credentials

Armed with a sense of what the certification is and a taste of the examination experience, you and your fellow CBAP course participants will then receive a guided tour of the CBAP® certification. We'll explore the certifying body—the International Institute of Business Analysis (IIBA)—and the requirements for certification. The CBAP course will take you through the application and examination processes, including tips, tools, and best practices for packaging your Business Analyst experience and education on the application. Next, we'll familiarize you with the professional standards and ethics of the CBAP® certification. And we'll conclude this module with a look at how the examination is structured and show you the best way to improve the efficiency and effectiveness of your exam preparation.

  1. The International Institute of Business Analysis (IIBA)
  2. The CBAP® certification
  3. The certification application processes
  4. The examination processes
  5. The professional code of conduct
  6. The examination structures

Part 3: Business Analysis & Key Concepts Overview

Before we can focus on the Body of Knowledge, we will need to cover critical foundational material on the topic of business analysis. We'll start by providing an overview, including common terms, concepts, techniques, and models that all business analysts must know to pass the CBAP® examination. During this overview, you'll have numerous chances to demonstrate your own knowledge, learn from your fellow Boot Camp participants, and gain useful insights from your instructor. You'll also practice exam questions to test your mastery, help you identify weaknesses, and effectively plan for further study on these important and often underemphasized exam topics.

  1. What is business analysis?
  2. The role and competencies of the business analyst
  3. The Systems/Software Development Life Cycle (SDLC)
  4. Project & Requirements Life Cycle Management
  5. Project roles and competencies
  6. Requirements engineering basics
  7. Levels of requirements, tool, and techniques
  8. Perspectives, systems, processes, and actors

Part 4: The Business Analysis Knowledge Areas

At the heart of IIBA certification is demonstrated knowledge of the Business Analysis Body of Knowledge® v 3.0 (BABOK®). In this section of the Boot Camp, we'll dive deeply into each Knowledge Area. As we cover each of these six subject-matter areas, we'll share the essential information you need to know for the CBAP examination. You'll come to understand the structure of the BABOK® and discover some practical tips for remembering what you need to know. And of course, the Boot Camp will help you continue to increase your comfort and confidence with the examinations through realistic practice exercises. Combined with the opportunity to discuss your questions, these activities will help you further refine your personalized preparation plan.

  1. Business Analysis Planning and Monitoring
  2. Elicitation & Collaboration
  3. Requirements Life Cycle Management
  4. Strategy Analysis
  5. Requirements Analysis & Design Definition
  6. Solution Evaluation

Part 5: Underlying Competencies

Having attained a deep knowledge of the BABOK® Knowledge Areas, you must still understand and know critical business analysis fundamentals. This module takes a detailed, structured look at the underlying competencies you need to know for the CBAP® certification.

  1. Analytical Thinking and Problem Solving
  2. Behavioral Characteristics
  3. Business Knowledge
  4. Communication Skills
  5. Interaction Skills
  6. Tools and Technology

Part 6: Techniques

A Business Analyst employs a variety of tools and techniques during a project to ensure successful results. Throughout the course, we will examine and study a number of these tools and techniques and learn the best time and place in which to use each.

  1. Elicitation & Collaboration techniques
  2. Diagramming and modeling techniques
  3. Root cause analysis techniques
  4. Acceptance and evaluation definition techniques
  5. Post-project assessment techniques

Part 7: Perspectives

Most projects use one or more perspectives that provide focus to the business analyst for tasks and techniques. We will examine several perspectives identified in the BABoK.

  1. Agile
  2. Business Intelligence
  3. Information Technology
  4. Business Architecture
  5. Business Process Management

Part 8: A Guide to Success on the Exam

By this point in the Boot Camp, you'll have a clear understanding of the application and examination processes. Using our specially developed tools, you'll be ready to map out your experience and knowledge and know what you personally need to do to complete a successful application. You'll also have an individualized study plan to help you prepare efficiently and effectively for the examination. All that remains are a few final tips to improve your examination experience. In this final Boot Camp section, you'll get our best tips and tricks and have a chance to practice with a sample examination. As we wrap up our four-day journey, you'll put the finishing touches on your personal exam preparation plan so that you can quickly and easily study for your own examination.

  1. Review of key topics
  2. Key tips to remember for the exam
  3. Final test hints and tricks
  4. Practice examination
  5. Your personal preparation plan

Business Analyst Boot Camp

Posted on October 17, 2020 by -

Part 1: The Business Analysis Profession

It's only in recent years that business analysis has begun to be recognized as a profession in its own right. While people have been performing the Business Analyst role in organizations for several decades, differing definitions of the role abound. We'll start the workshop by exploring some of them, as well as gaining a clear understanding of where the industry appears to be heading and some emerging standards for the profession.

  1. IIBA® and the BABOK®; The PMI® Guide to Business Analysis and the Business Analysis For Practitioners: A Study Guide
  2. What is Business Analysis?
  3. Business and Solution Domains—how they relate
  4. Key roles in requirements development in SDLC and Agile projects
  5. The competencies of the Business Analyst
  6. Distinguishing novice and expert Business Analysts
  7. Effective communication
  8. Six important BA skills

Practice sessions:

  • Business analysis definition
  • Competencies of a business analyst

Part 2: The Business Case for Good Requirements

IT projects have especially high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with IT project requirements. We also examine some common terms and concepts in requirements engineering.

  1. What is a good requirement?
  2. Requirements versus design
  3. Requirements attributes—who needs them?
  4. Key practices that promote excellent requirements
  5. The cost of requirements errors
  6. Requirements engineering overview

Practice sessions:

  • Characteristics of good requirements
  • Explore the differences between requirements and design
  • Evaluate requirements for effectiveness
  • Factors to improve project success

Part 3: Foundations of Requirements Development

In order to increase project success, we need to implement a repeatable, scalable strategy for effective business analysis. In this section, we'll explore a framework in which good business analysis occurs and we'll discuss ways to maximize project success using this framework.

  1. Key terms in requirements development
  2. A strategy for analyzing systems
  3. Common requirement-classification schemes
  4. The three levels of a system
  5. Levels and types of requirements
  6. The importance of traceability
  7. Understanding the business context of projects

Practice sessions:

  • Define key terms
  • Use a framework to drive out requirements
  • Types of requirements
  • Classifying stakeholders' input
  • Evaluate a fictitious but realistic organization for project alignment

Part 4: Project Initiation: Eliciting High-level and Mid-level Requirements

What most people think of as business analysis is central to project initiation. Because of the depth of skill these activities require, most Business Analysts demand separate training to develop true mastery. This course module therefore provides an overview and introduction to crucial business analysis activities by demonstrating common tools for identifying and documenting project scope, for modeling current and desired states, and for stakeholder and persona identification. And because effective initiation can lay the foundation for effective use case or user story development, we'll introduce use cases and user stories by identifying them in this module, too. After we've elicited the high-level and mid-level requirements for our project, we want to check to be sure that what we have so far is a good description of the project's scope.

  1. Understanding product vision and project scope
  2. Identifying and describing project stakeholders and personas
  3. Modeling the business
  4. Analyzing the current state and defining the future state
  5. Identifying systems and actors
  6. Determining scope
  7. Understanding and identifying use cases and user stories
  8. Taking the Agile approach: writing user stories
  9. Identifying and defining data
  10. Documenting business rules
  11. Finding quality attributes
  12. Defining and documenting the project scope

Practice sessions:

  • Modeling the business
  • Context diagramming
  • Ways to identify use cases and user stories
  • Brainstorming and chunkifying
  • Roles and Permissions matrix
  • Use case diagramming
  • User stories
  • High-level data definition
  • Entity relationship diagramming
  • Writing business rules and quality attributes
  • Evaluate a Scope Statement

Part 5: Eliciting Detailed Requirements

Savvy business analysts and project team members have a variety of techniques for finding the detailed functional and non-functional requirements on their projects. This section introduces several of the most powerful and effective analysis techniques and discusses their use in requirements elicitation. As various techniques are covered, the workshop explores how to capture and document the requirements, including effective requirements analysis and traceability.

  1. Overview of requirements-elicitation techniques
  2. Decompose processes to lowest levels
  3. Document analysis
  4. Modeling processes to generate interview questions
  5. Interviewing the stakeholders
  6. Documenting the interview and resulting requirements
  7. Adding detail to requirements we already have
  8. Refining and rewriting for clarity

Practice sessions:

  • Elicitation techniques – advantages/disadvantages
  • Process modeling
  • Generating good interview questions
  • Coping with challenging situations
  • Interview simulations
  • Writing new requirements and refining existing requirements
  • CRUD matrix and CRUD functional requirements

Part 6: Improving Requirements Quality

After we've elicited the detailed requirements for our project, we want to analyze and refine the requirements. Writing requirements is one thing—writing "good" or "effective" requirements is another matter. As we are hearing and documenting requirements from our stakeholders, we should be evaluating them for effectiveness and refining/rewriting those that are not. In this section, we'll learn to derive maximum benefit from reviews throughout the life cycle. We'll then take a closer look at the issue of requirements quality, focusing on writing effective requirements through analysis, refinement, and review. Finally, we'll discuss how to document the scope of the project to minimize rework and scope creep.

  1. Requirements quality
  2. Common problems with requirements
  3. Analyze for ambiguity
  4. Requirements inspection, analysis, and improvement

Practice sessions:

  • Analyze and rewrite requirements

Part 7: Documenting Requirements with Use Cases and User Stories

Developing use cases is fairly straightforward, but someone actually has to document the use cases and requirements discovered during the requirements elicitation process. There is also an art to writing user stories and defining acceptance criteria for the requirements. This section of the workshop focuses on how to apply the knowledge you've gained so far to writing use cases and user stories. It also examines more complex aspects of uses cases, including sub-use cases and use-case linkages in larger systems.

  1. Better user stories using the INVEST model
  2. Defining acceptance criteria
  3. Decomposition of user stories
  4. Considering use cases for decomposing user stories
  5. Use case basics
  6. Use cases and requirements
  7. Usage narrative
  8. Anatomy of a fully dressed use case
  9. Writing effective use case narratives
  10. Understanding sub-use cases
  11. Linking use cases for larger or more complex systems
  12. Use case quality
  13. Avoiding common traps and pitfalls

Practice sessions:

  • Write acceptance criteria and perform peer reviews
  • Decompose user stories
  • Write a usage narrative
  • Write a fully dressed use case and perform peer reviews
  • Check use case quality

Part 8: Packaging and Presenting Requirements

Once we've worked with stakeholders to define their functional and non-functional requirements and to document, refine, and organize the requirements, we have to package those requirements into a specification. In addition, most systems also possess a significant number of requirements that aren't necessarily associated with specific business functions. These types of non-functional requirements must also be captured and documented as part of the complete requirement specification. This portion of the Boot Camp covers how to package the requirements into a specification that can be used for system development and testing.

  1. Organizing and packaging requirements
  2. Presenting requirements for review
  3. Baselining the requirements
  4. User story backlog management
  5. Managing requirements changes
  6. Getting to consensus and approval
  7. Conducting formal and informal reviews
  8. Documenting requirements in a Requirements Specification

Practice sessions:

  • Examine and evaluate a sample Requirements Specification
  • Discuss strategies for presenting requirements to stakeholders
  • Review how to determine impact analysis for changes to the requirements
  • Create a personal action plan for success

Effective User Stories

Posted on October 17, 2020 by -

Part 1: Agile Review in Five Minutes

  • User stories in agile practices
  • Value proposition canvas
  • Product innovation lifecycle

Part 2: User Stories then, User Stories now

  • The user story relationship to business analysis and agility
  • Why a well-written story is beneficial
  • Traditional analyst and requirements activities translated to agility
  • Differences in alignment to an agile practice

Part 3: User Story Overview

  • The concept of stories and their formatting
  • Roles involved at different levels of story planning and creating stories 
  • Different techniques of writing stories 
  • Benefits of well written stories 
  • Acceptance Criteria best practices
  • INVEST overview
  • 3Cs
  • Examples

Part 4: User Personas

  • Understanding User Personas
  • User stories and Personas- 3C’s
  • Benefits of personas 
  • Using your roadmap for creating personas 
  • Aligning user personas with stories 

Team Exercise: Teams will practice writing stories using the Roles identified from the User Persona exercise. As a group, acceptance criteria will be written, simulating a backlog grooming session.

  • Using User Personas inside a story 
  • Determining user experience

Team Exercise: Teams will create User Personas to understand the concept and identify details that make them unique

  • Identifying roles
  • Other types of backlog items 
  • What is a spike?
  • How to use them
  • Example
  • Non-functional (tech debt) 
  • What is a non-functional requirement (NFR)? 
  • How to use them
  • Defects and their management
  • Example

Team Exercise: Individually the group will write an example of a Spike, Non-Functional requirement, and a Defect. Focusing on what makes them unique and how best to document the details for development.

Part 5: Levels of Planning

  • Vision
  • Epics
  • Roadmap
  • Features
  • Creating Definition of Ready and Definition of Done 
  • Story Mapping
  • Estimation and story sizing (story Points / T-shirt sizing)
  • Backlog Management
  • Planning/ Review / Retrospective 

Team Exercise: Teams will create a list of features, focusing on the evolution of an application and ways in which to build upon a feature over time.

  • Product Backlog
  • Prioritization techniques
  • Story slicing, splitting

Part 6: Getting hands-on: User stories in practice

During this workshop section of the course, the group will spend time practicing application of user stories as they will back at work after class. Workshop participants will critique stories that have been given to them, learning what to look for when grooming stories (size, unclear, dependencies).

  • Building a Comprehensive Release Plan and Backlog
  • Process Mapping
  • Impact mapping
  • Story Mapping

Team Exercise: Teams will create Epics for the features identified in the previous exercise, focusing on how to break down the work into valuable slices.

Team Exercise: The group will be given a sample process map, they will break the process into stories that remain independent and valuable, even if the value varies.

Team Exercise: Teams will write stories that relate to the Epics written in the previous exercise. Focusing on the INVEST strategy of story writing and using group feedback to further refine.

Part 7: Prep and Support of Sprints

  • Story Writing Sessions
  • Backlog Grooming
  • Relative Sizing
  • Acceptance test-driven development (A-TTD)
  • Behavior-driven development (BDD)
  • Story Preparation Kanban
  • Backlog Prioritization
  • Release Planning

Part 8: Application Workshop

Team Exercise: Individually, the group will get to focus on real-world examples, getting feedback from the group intermittently, similar to a series of grooming sessions. Ideally bringing these stories back to their own projects.

Part 9: Retrospective

  • Handling and Adjusting to Team Feedback
  • Educating Others

Certified Scrum Product Owner® (CSPO®)

Posted on October 17, 2020 by -

Part 1: Product Owner Core Competencies

  • Product Owner in different organizations
  • Demonstrate progress on goals to Stakeholders
  • Gathering insights
  • Product Owner Interaction with Scrum teams
  • Product Ownership of multiple teams
  • Owning the Product backlog 
  • Collaborating with the Scrum team

Part 2: Goal Setting and Planning

  • Defining Value
  • Product Visions and Product Goals
  • Creating a Sprint Goal
  • Product Planning and Release Planning
  • Identifying small valuable increments

Part 3: Understanding Customers and Users

  • Product Discovery
  • Segmenting customers and users
  • Conflicting customer needs
  • Defining Product Outcomes
  • Connecting developers to users

Part 4: Validating Product Assumptions

  • Validating Product assumptions in Scrum
  • Approaches to validate assumptions

Part 5: Working the Product Backlog

  • Outcome vs Output
  • Maximizing outcomes
  • Product economics
  • Describing and measuring value
  • Creating Product Backlogs, Product Goals, and Product Backlog Items
  • Refining a Product Backlog

Part 6: Scrum Theory

  • Empiricism and the three empirical pillars
  • Benefits of an iterative and incremental approach
  • The Scrum Framework
  • Scrum Values
  • Scrum alignment to the Agile Manifesto

Part 7: Scrum Teams 

  • The responsibilities of the Scrum Team
  • The responsibilities of the Product Owner, Developers, and Scrum Master
  • Working with stakeholders
  • Working with multiple teams

Part 8: Scrum events and activities

  • Benefits of timeboxing
  • Purpose of a Sprint
  • Define and perform Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
  • Product Backlog Refinement

Part 9: Artifacts and commitments 

  • Purpose of the Product Backlog, Sprint Backlog, Increment
  • The commitments of Product Goals, Sprint Goals, and Definition of Done
  • Product Backlog emergence
  • Attributes of a Product Backlog
  • Sprint and Increment relationship
  • Evolution of a Definition of Done

Applying Enterprise Business Architecture

Posted on October 17, 2020 by -

Part 1: Business Architecture Organizational Maturity & Roles

Organizational and individual expectations will be set for the workshop. The roles and competencies relevant to the business architecture activities will be discussed. Is your organization ready to support the effort?

  1. What to Expect
  2. Enterprise Support
  3. Business Architecture Maturity Levels
  4. Business Architecture Capabilities
  5. Business Analyst and Architect Synergy
  6. What Do Architects Do
  7. More Advanced Competencies

Activity: Competency Assessment

Part 2: Understand the Enterprise & Business Architecture Key Concepts

The value proposition for building a business architecture and industry best practices will be introduced. This information can also be used to sell the business architecture concept to the enterprise.

  1. The Shift: Strategic to Tactical
  2. Part of the Enterprise Architecture
  3. Benefits of Aligning Architectures
  4. What is Business Architecture
  5. Capture the Knowledge in Blueprints
  6. Build Relationship Maps for Decision Making
  7. Outcome Driven Business Architecture
  8. Why Have a Business Architecture?

Activity: Tactical or Strategic, Selling the Business Architecture

Part 3: Bodies of Knowledge and Frameworks

There are many frameworks that exist that can provide guidance for building the business architecture. But what is out there, what are the benefits and challenges of each and how do I know which combination is right for me? We will provide you with guidance to help you make that decision.

  1. Frameworks Overview
  2. Zachman Framework
  3. TOGAF®
  4. DODAF
  5. FEA
  6. Relevant Bodies of Knowledge
  7. BABOK®
  8. BIZBOK®

Activity: Which Framework to Apply

Part 4: Common Architectural Building Blocks

There are some common elements to business architectures regardless of the framework that should be considered. We will step through those elements or building blocks.

  1. Architecture Requirements
  2. Architecture Boundaries
  3. Applying the Context Diagram and Solution Views
  4. Architecture Structure
  5. Which Components, Relationships and Views
  6. Modeling Hints and Tips
  7. Notations and Modeling Languages
  8. BIZBOK®

Activity: Stakeholder Views, Building Blocks Reality Check, Name Two Quiz

Part 5: Set the Stage: Understand the Business

Understanding the business is critical to the business architecture’s success. This needed business information can be presented in different ways. We will look at a few of the most common ways this information is or can be captured and used to build your business architecture.

  1. Needed Inputs to the Business Architecture
  2. Business Model Canvas and Benefits of Asking Business Model Questions
  3. Strategy and Benefits of Asking Strategy Questions
  4. Balanced Scorecard
  5. Business Operating Model
  6. Identifying Business Scenarios
  7. Assess Maturity and Capabilities

Activity: Applying Business Model & Business Operating Model, True or False Quiz

Part 6: Create a Roadmap

There is a general approach to creating a business architecture that we will logically step through, but many elements should still be considered to tailor the approach. We will look at both so you can develop your own roadmap to success.

  1. Architecture Development
  2. Define Boundaries and Analyze Stakeholders
  3. Select Components, Frameworks and Notations
  4. Identify Elicitation, Analysis Techniques and Tools
  5. Why Approaches Vary
  6. Create a Business Case
  7. Present to Management
  8. Presenting Complex Content

Activity: Agenda for Future State Model, Challenge Scenario, Prepare for Building

Part 7: Build the Knowledgebase

  1. Leverage What You Have – Existing Assets
  2. Adding More Models and Maps
  3. Organizational Model
  4. Functional Decomposition Model
  5. Swim Lane and Value Streams
  6. Business Capabilities and Services
  7. Relationship and Alignment Maps

Activity: List Business Capabilities, Which Maps, Pick One Quiz

Part 8: Use the Business Architecture

  1. Business Architecture Engagement Model
  2. Sell to the Enterprise
  3. Adoption Assessment and Organizational Acceptance
  4. Get Others to Leverage the Business Architecture
  5. Quickly Build Trust with Stakeholders
  6. Be an Advisor, Find Opportunities
  7. Connect to Tactical Projects
  8. Reusing Organizational Assets

Activity: Reuse Examples, Lessons Learned

Developing Requirements with Use Cases

Posted on October 17, 2020 by -

Section I. Review of Requirements Development with Use Cases
Use cases are one of the best approaches for developing requirements. In this section of the workshop, we will review key definitions and terms, overview a requirements management framework, and review how use cases fit into the development life cycle. We’ll refresh your knowledge of how to find requirements from use cases, and we’ll conclude with a discussion of use cases and Agile methods.

  • Definitions of terms
  • Levels and types of requirements
  • Characteristics of effective requirements
  • Requirements, use cases, and the development life cycle
  • Review and assess use case quality
  • Identify requirements associated with a use case
  • Use cases and Agile methods

Practice Session
With your instructor, revisit key concepts of requirements engineering and then review poorly written requirements to discover characteristics of effective requirements. Work with your team to review and analyze several use cases and then extract possible requirements from those sample use cases.
 

Section II. IT Project Initiation and Use Cases
To exploit the full advantages of use cases, seasoned analysts plan for them from the very beginning of each project. This section explores project initiation and its relationship to use cases, particularly how to identify and capture them early in the project life cycle. In particular, you'll review whether use cases are appropriate for a specific project. You'll strengthen your understanding of the connection between project scope and use cases. We'll conclude this module with an exploration of other methods for identifying the use cases that comprise a system, and a chance for you to practice constructing a use case diagram.

  • Project scope and stakeholders: how they relate to use cases
  • Actor/goal definition and use cases
  • Event identification
  • User stories for agile development
  • Use case briefs and usage narratives
  • The use case diagram

Practice Session
Examine a hypothetical but realistic business and one of its emergent projects. You'll work in a small group to practice determining whether the use case approach is appropriate, identifying the use cases using the actor/goal identification method, and writing user stories and use case briefs for the case project. You will also practice diagramming the actors and the use cases.
 

Section III. Documenting Requirements with Use Cases
At some point, we must document the use cases and requirements discovered during the requirements elicitation process. This section of the workshop focuses on how to apply the knowledge you already have to writing better use cases. It also examines more complex aspects of uses cases, including includes and extends relationships and use case linking on larger systems.

  • The use case preamble: the big picture
  • Describing the normal course (i.e., main success scenario)
  • Identifying and describing extension scenarios
  • Identifying includes (sub-function use cases) and extends relationships (extension use cases)
  • Linking uses cases for larger or more complex systems

Practice Session
You'll work with your team to write a fully dressed use case for our case project, including a preamble, the main success scenario, and the extension scenarios. You'll also have a chance to write an included (or sub-function) use case and an extension use case.

Section IV. Improving Use Case Quality
As with most aspects of system development, the quality of downstream work products (design elements, test plans, etc.) depends directly upon the quality of the use cases. During this part of the workshop, we will apply standards for quality to our use cases and requirements and look at some proven ways to prevent common problems. We'll also explore how to derive maximum benefit from reviews throughout the life cycle.

  • Characteristics of well-written use cases
  • Recognizing common problems with use cases
  • Avoiding use case traps and pitfalls: advice and examples
  • Validating use cases through reviews and inspections

Practice Session
Your team will review another team's use case using a quality checklist. You'll then have the opportunity to refine your own team's use case based on feedback from another team.

Section V. Use Cases and Other Requirements
Merely writing use cases is not sufficient for capturing all project requirements. While desired user functionality yields a major set of project requirements, experienced analysts know there are also non-functional aspects of the desired system that must be identified and captured. In this section, we will examine ways to derive other typical requirements from use cases and how to identify constraints on the solution design. In addition, we'll explore how use cases not only trace back to one or more business requirements, but also how they trace forward through the development life cycle to design and testing.

  • Deriving non-functional requirements: business rules, data definitions, interfaces, and quality attributes
  • Relating use cases to other requirements
  • Identifying design constraints
  • Documenting requirements and use case traceability

Practice Session
Your team will work together to derive and capture non-functional requirements from the use case your team has already refined. Then your instructor will work with the class to develop and document traceability between the requirements and the use cases for our course project.
 

Section VI. Use Cases and Testing
One of the most powerful aspects of the use case approach is its improvement in test procedure development. Well-written use cases directly impact the outcome of the very portion of the life cycle most likely to suffer when time is of the essence. Here, we'll look at how use cases can help identify test cases early in the life cycle. Next, we'll examine an example use case and its associated test plan side-by-side. Finally, we'll discuss how use of automated tools can reduce not only testing time, but also the time required to produce the test procedures.

  • Benefits of early test case development
  • Relating use cases to test cases
  • Automated tools: reducing test procedure development time and testing time

Demonstration
Your instructor will demonstrate the use of a popular automated use case documentation tool and will then use it to develop a partial set of test procedures for our case project.
 

Section VII. Use Cases and Design Elements
Once we have the use cases developed, we can use them as a basis for discovering the elements needed for the design and development of the solution. In this section, we'll learn how to find typical design elements such as screens, messages, and dialog boxes, creating another layer of detail (sometimes called a "system use case").

  • What are design elements?
  • The relationship between a use case and design elements
  • Functional decomposition for finding design elements
  • Specifying design elements from a use case
  • Validating requirements from user stories, use cases, and interface design

Practice Session
With your team, you'll analyze the use case you've already written to identify and specify required design elements. With your instructor, prototype an interface design for a use case from our case project and use it to validate the requirements.

Critical Skills for Writing Better Requirements

Posted on October 17, 2020 by -

I. The Business Case for Requirements Engineering
Projects have high failure rates, and evidence points to problems with defining requirements as one primary cause. This section presents an overview of the challenges inherent in projects in general, and specific problems typically encountered with project requirements.

A. The goal of a project
B. Facts and figures about project success and failure
C. Types of requirements errors and their frequency
D. The high cost of requirements errors

II. Foundations of Requirements Development
Developing requirements is key to project success. In this section, we’ll cover some basic definitions, review a requirements development framework and process, and introduce an example system we’ll use for our practice sessions.

A. The Business Analysis Body of Knowledge
B. Definitions of terms
C. Types of requirements
D. Characteristics of well-written requirements
E. The requirements development roadmap
F. Requirements and the development life cycle
G. Enterprise analysis

Practice Session
Gain an in-depth look at a hypothetical but realistic business and one of its key systems that you’ll be eliciting and managing requirements for during the class.

III. Project Initiation
Projects arise in part to solve business problems, and understanding the underlying problem or problems is therefore key to being able to identify the correct requirements. During this section, you will refresh your knowledge of and practice defining and documenting project scope and key business requirements.

A. Defining goals and objectives
B. Identifying stakeholders and user classes
C. Identifying constraints and benefits
D. Specifying exclusions
E. Modeling the system scope
F. Documenting requirements in the Initiate phase

Practice Session
Guided by your instructor, you will work with a team to define the goals and objectives in an example project. You’ll have a chance to practice identifying stakeholders and constraints and discovering important aspects of the project scope. You’ll participate in documenting the project scope using a variety of business models.

IV. Eliciting Functional and Non-functional Requirements
As we come to understand the business problem at the heart of a project, we need to learn to capture our business customers’ functional and non-functional requirements. This section explores several powerful and effective analysis techniques for requirements elicitation and development.

A. Problems with requirements elicitation
B. Techniques for eliciting customer requirements
C. Analyzing and reviewing documents and artifacts
D. Modeling processes, analyzing gaps and generating questions
E. Interviewing the stakeholders
F. Identifying data requirements
G. Establishing requirements traceability
H. Capturing the requirements

Practice Session
In your team, you will analyze business artifacts and documents to discover the customers’ functional requirements for the solution. You’ll practice identifying what functionality customers want to keep, remove, add and/or change in moving from their current system to the solution. You’ll practice generating questions for key stakeholders and interviewing those stakeholders. Finally, you’ll learn to use a variety of tools to discover and document stakeholders’ data requirements.

V. Use Cases: A First Look
A”use case” is a sequence of events performed by an actor (person, automated system, or both) in a business environment to get their job done. Use cases carry significant requirements for a system from the perspective of a business user. Use cases are a critical tool in the analysis process, helping us understand what the system needs to do. Later in the development life cycle, use cases aid in design and implementation, testing, and user documentation for the new system. This section introduces the concept of use cases and gives you an opportunity to explore this analysis technique.

A. The benefits of use cases
B. Use case basics
C. Finding use cases
D. Building a use case model
E. Deriving requirements from a use case
F. Tracing requirements from use cases

Practice Session
Your team will create a use case model for one process of our example system. You’ll learn how to identify and extract important functional requirements from the use case, how to elicit additional requirements, and how to maintain traceability among the requirements. You’ll discover how the use case becomes the basis for future development tasks.

VI. Reviewing and Refining Requirements
Well-defined requirements are critical to producing a system that meets the needs of the project stakeholders. Finding the requirements is only the first challenge. Once discovered, requirements must be reviewed, analyzed, validated and possibly rewritten. All requirements must then be confirmed with project stakeholders before the final specification is published.

A. Writing requirements
B. Reducing ambiguity
C. Validating requirements through reviews and inspections
D. Analyzing requirements for validity, consistency and effectiveness
E. Refining requirements
 

Practice Session
Your team will evaluate the requirements that have been found and written for the example project to identify any that don’t meet the quality characteristics we’ve defined. We’ll practice rewriting any unclear or ambiguous requirements.
 

VII. Creating a Requirements Specification
“The job’s not finished ‘til the paperwork’s done.” The final deliverable for many projects is a Requirements Specification of some kind. Writing a clear, concise and informative specification is a critical step in providing the implementation team with the information they need to design and implement a solution that is right for the stakeholders of the project. This section focuses on the creation and communication of the final requirements specification.

A. Organizing and classifying requirements
B. Documenting requirements: the Software Requirements Specification (SRS)
C. Documenting traceability

Practice Session
Your team will consider a model template for documenting the final requirements specification for our case project. You will have an opportunity to write sections of the specification in the course.

Collaborating and Communicating Agile Requirements

Posted on October 17, 2020 by -

Section I: Agile Overview
More than simply a methodology or approach to software development, Agile embraces a set of principles that drive more effective software development. Agile focuses on the customer, embraces the ever changing nature of business environments and encourages human interaction in delivering outstanding software. In this introduction, we'll discuss the following:

  • Agile Manifesto
  • Agile Principles
  • Agile Methodologies
  • Agile Benefits 

Section II. Project Initiation
Among the key contributing factors leading to project failure is poor communication between the customer and developer groups. It is critical, therefore, that each successful project start out right. In this section we'll cover the following topics:

  • Project Charter
  • Project Roles
  • Project Planning
  • Communication 

Class Exercise
Working in small teams, you will establish a project charter including goals and objectives for a sample project. You will participate in defining key roles for project team members and set clear expectations for project communication.

Section III: Focus on the Customer
It is critical that the customer be the focus of a product throughout the development lifecycle. Every requirement should bring some value to the customer. Therefore, prior to defining requirements, it is important to define the customer. This will include the following topics:

  • Customer Involvement
  • Customer Roles
  • Creating and Using Personas
  • Constraints 

Class Exercise
Within your teams you will brainstorm some customer roles for your example project. From the brainstorming, you will consolidate the larger list of roles into key roles that will be the focus of your sample project. For each of the key roles, each team will create personas and share them with the class.

Section IV: User Stories
User stories are a way to capture requirements from a customer point of view. Stories do not capture all of the detailed requirements, but require enough information to estimate and plan. A proven tool used in Agile teams to capture initial requirements, in this section we will explore the following topics:

  • User Stories
  • Goals and Objectives
  • Acceptance Criteria and Acceptance Tests
  • Non-user Stories

Class Exercise
Led by the instructor, the class will come up with some user stories for a sample project. We will discuss how to determine as a team what is appropriate for your user stories to be effective.

Section V: Product Backlog
The Product Backlog is the complete list of desired elements, or requirements, for the product. It is NOT a Requirements Specification, but a high level identification of what the software may satisfy. In this section we will discuss effective means of creating, prioritizing and maintaining the Product Backlog. We will peruse the following topics:

  • Who owns the Product Backlog?
  • Functional and Non-functional Requirements
  • Story-Writing Workshop
  • Prioritizing the Product Backlog
  • Maintaining the Product Backlog
  • Techniques for further elaboration

Class Exercise
In small teams identified previously, you will engage in a story-writing workshop as a means of building a product backlog for your sample project. Subsequently, you will participate in prioritizing your product backlog and present the highest priority stories to the class.

Section VI: Estimating and Planning
Among the greatest challenges in developing software and delivering against stakeholder expectations is estimating accurately and subsequently planning how those expectations can be met. Agile cannot make that challenge disappear, but offers some very helpful tools that enable teams to set and meet the appropriate expectations.

  • Relative vs. Actual Estimating
  • Using Story Points
  • Planning Poker (Grenning 2002)
  • Five Levels of Planning in Agile
  • Estimating Team Velocity

Class Exercise
Using the estimating techniques taught using story points, you'll enjoy a few rounds of Planning Poker with your team to establish estimates for your highest priority stories. This fun and highly effective method of relative estimating is certain to be a valuable tool for you to incorporate into your own estimating process.

Section VII: Release Plan
The release plan identifies a goal for the stories that will be included for a release of the software. Through the prior processes, the team will have prioritized the stories and estimated the team velocity. These key elements will come together to give the team a level of confidence that they can deliver the necessary requirements for a product release in what is normally a fixed timeframe. We'll examine the following topics:

  • Iteration Estimates
  • Prioritization Revisited
  • Ownership and Participation
  • Communication 

Class Exercise
Each team will establish a release plan for their sample project incorporating priority, estimates and velocity as appropriate. We'll discuss how real experiences of fixed time and requirement projects that work well with an Agile release plan.

Section VIII: Use Cases
At the appropriate time, prior to entering into the development of a story, requirements will need to be discussed in more detail. Use cases are a proven method for documenting the appropriate detail from a user interaction point of view. In this section, the instructor will introduce use cases and discuss some of the foundational elements that support the development process.

  • Use Case Advantages
  • Use Case elements
  • Success Path
  • Alternate Paths
  • Exceptions

Class Exercise
Teams will discuss and document use cases, including alternate paths and exceptions, for some of their high priority stories. As a class we'll discuss the relationship between use cases and stories, and how they complement each other.

Section IX: Iteration Plan and Execution
An iteration is a fixed amount of time in which stories/requirements will be developed, tested and ready for release. Because the requirements communication process takes you into each iteration throughout the product release, we'll explore the iteration planning and execution process. During this section we will discuss the following topics:

  • Iteration Planning
  • Defining "Done"
  • Test-Driven, Test Often
  • Demonstrate Working Software (Delivered Requirements)
  • Inspect and Adapt applied to Requirements
  • Finding your rhythm 

Section X: Retrospective on Communicating Requirements
Using Agile Methods – Retrospectives are a key practice in Agile. We will take an opportunity to review our learning collectively and how we can improve. Each participant will identify one or two things that they will adapt in their working environment based on their learning. The instructor will also identify any elements of the course that should be adapted for a better learning experience, thus benefiting future course participants.

In-Class Group Exercises:

In-class exercises help you identify and examine firsthand problems that you may experience. With our demonstrations and case studies, you will discuss ways you can handle problems up front, and how you can make improvements, throughout the phases of requirements development.

  • Establish a project charter, define roles for the project team and determine appropriate communication
  • Define customer roles and personas 
  • Document requirements with user stories 
  • Create and maintain a product backlog 
  • Determine customer value and priority for each user story 
  • Participate in engaging and innovative estimating techniques 
  • Communicate a release plan for a product 
  • Document requirement details with use cases 
  • Plan and execute an iteration cycle 
  • Learn how to continuously improve requirements collaboration

Business Analysis in Agile Projects (ICP-APO)

Posted on October 17, 2020 by -

Part 1: Getting Started

As we get started we will get to know each other and understand the objectives of the course. We will introduce the importance of Conversation in the Agile environment and how the Conversation can be managed for better communication and results. We will model the creation of Working Agreements that contribute to building trust on a team.

  1. Introductions
  2. Course Objectives
  3. Impact of other Domains on Agile Beginnings
  4. The Agile Conversation
  5. Working Agreements

Part 2: Agile Overview

You’ve heard it all before: “Agile means developing software without any documentation. Agile means developers decide on a product’s features. Agile is the same thing as Scrum.” Perhaps you’ve heard the most misleading concept of all: “Agile means we don’t do business analysis anymore.” Nothing could be more false.

Learn what Agile really is, what the variations and hybrids of Agile are, and how business analysis is critical to project success.

  1. Lean Beginnings
  2. Why Agile?
  3. Agile Manifesto & Principles
  4. Agile Practices

Part 3: Building an Agile Team

In Agile the Business Analyst has various possible roles from Voice of the Customer or Product Owner, member of the Customer side team, or member of the Development side team. In this section, we will explore how to create an effective Agile team with an Agile mindset and then see how the Business Analyst fits into this team framework and provides value.

  1. The Team as a System
  2. The Business Analyst

Part 4: Project Initiation

Agile follows an Adaptive, Just-in-Time planning model. In this section, we will learn how Adaptive Planning can better meet the customer’s needs and provide them more value with fewer resources by only elaborating requirements Just-in-Time.

  1. Five Levels of Planning
  2. Vision
  3. Themes & Roadmap
  4. User Roles and Personas

Part 5: Backlog Planning

The Agile vehicle of communicating requirements is the User Story. The Business Analyst is central in the process of writing and elaborating User Stories. This section will help the Business Analyst learn about User Stories and how to write and elaborate good User Stories.

  1. The Product Backlog
  2. Writing User Stories
  3. Guidelines for Good Stories
  4. Acceptance Criteria

Part 6: Managing the Backlog

After User Stories are written, they need to be prioritized and estimated. As part of the Customer side team, the BA has a major role in prioritization. As a member of the Development side team, the BA will contribute to User Story estimation. Both of these come with low cost, low waste techniques that allow us to do this quickly and get on to the important work of implementing requirements.

  1. Prioritization
  2. Estimating

Part 7: Release Planning

The Business needs to know when they will receive product deliverables. In this section, the Business Analyst will learn how milestones are set and how deliverables will be slated for a release with high confidence in meeting dates.

Part 8: Backlog Refinement

Backlog Refinement is where the Business Analyst is really worth their weight in gold. User Stories represent very thin statements of Customer wants and needs but they don’t contain the details until the development team is close to working on them. As the time to work on them approaches, the details need to be filled in and the Business Analyst is the central figure in requirements elaboration.

  1. Agile Documentation
  2. Requirements Elaboration

Part 9: The Iteration

When Requirements are ready to go – ready to go does not mean mountains of documentation. Much of the details are maintained as tacit knowledge with the Business Analyst and the others who have been involved with the Conversation. Continued collaboration is essential to turning what we’ve learned about the needs of the customer into working software. The Business Analyst is always there involved in answering real-time questions from the team.

  1. Iteration Planning
  2. Iteration Execution

Part 10: Inspect and Adapt

Agile is an Empirical Process for developing complex software. Essential to an Empirical Process is feedback loops. Feedback loops can be both formal and more informal. In this section, we will learn about the formal feedback loops that are built into the end-of-iteration timeframe for driving continuous improvement back into the process.

  1. The Iteration Review
  2. The Demo
  3. The Retrospective

Part 11: Agile Adoption

So you want to drive these concepts into your organization as you leave the class and go back to your work. This section will help you do that effectively.

Software Tester Certification Boot Camp

Posted on October 17, 2020 by -

Part 1: Course and Exam Overview

  1. ISTQB and ASTQB overview
  2. Exam format
  3. Study and exam-taking tips
  4. Course flow and agenda topics
  5. Outline of the daily schedule (varies on day 3)
  6. Explanation of supplementary material

Part 2: Fundamentals of Testing

  1. Testing overview and key terminology
  2. Common testing principles
  3. Basic test process
  4. Psychology of testing
  5. Code of ethics
  • Interactive Session: Testing missions and test objectives
  • Pop Quiz: Seven testing principles
  • Interactive Session: Context drivers for testing

Part 3: Testing throughout the Software Life Cycle

  1. Software development models
  2. Test levels and test types
  3. Maintenance testing
  • Interactive Session: Understanding test impacts of software development models
  • Interactive Session: Illustrating verification and validation for better understanding
  • Interactive Session: Linking test levels with entry and exit criteria
  • Interactive Session: Compare and contrast black box and white box testing
  • Interactive Session: Understanding goals, targets, and issues within test levels
  • Interactive Session: Compare and contrast test types using examples

Part 4: Test Management

  1. Test organization
  2. Planning and estimation
  3. Progress monitoring and control
  4. Configuration management
  5. Risk and testing
  • Incident management
  • Pop Quiz: Understanding project constraints
  • Pop Quiz: Test team organizational structures
  • Pop Quiz: Driving more accurate test estimates
  • Pop Quiz: Choosing a test approach
  • Interactive Session and Pop Quiz: Performing risk assessment
  • Pop Quiz: Identifying incidents
  • Hands-on Exercise: Write an incident report
  • Hands-on Exercise: Perform a review session
  • Interactive Session: Developing oracles

Part 5: Test Design Techniques

  1. The test development process
  2. Specification-based techniques
  3. Structure-based techniques
  4. Experience-based techniques
  5. Selecting test techniques
  • Pop Quiz: Using specification-based techniques
  • Interactive Session: Review tests designed with equivalence partitioning
  • Hands-on Exercise: Use equivalence partitioning as a test design method
  • Hands-on Exercise: Use boundary value analysis to create tests
  • Interactive Session: Analyze and map out complex logic in requirements
  • Hands-on Exercise: Use a decision table to develop tests
  • Interactive Session: Walk through a state model
  • Hands-on Exercise: Use a state model to build tests
  • Pop Quiz: Use case basics
  • Interactive Session: Generate tests from use cases
  • Interactive Session: Analyze code flow with control flow diagrams
  • Hands-on Exercise: Develop structural tests for code and analyze coverage
  • Pop Quiz: Differentiate experience-based techniques
  • Pop Quiz: Choose a test technique

Part 6: Static Techniques

  1. Static testing techniques
  2. The review process
  3. Static analysis by tools
  • Review test sets to evaluate test design*
  • Perform a peer review and feedback session (these practice sessions are embedded elsewhere to perform reviews on real targets)

Part 7: Tool Support for Testing

  1. Types of tools
  2. Effective use of tools
  3. Introducing tools into an organization
  • Pop Quiz: Test frameworks
  • Pop Quiz: Understanding probe effect
  • Pop Quiz: Pros and cons of tools
  • Pop Quiz: Piloting a tool

Part 8: Course Wrap-up

  1. Exam tips, procedures, and guidelines
  2. Exam cram
  • Open review session
  • Practice exam review

At the conclusion of the software testing training course, you will have the opportunity to take the ISTQB™ Certified Tester —Foundation Level exam. The exam is held at 3:30 p.m. on the third day of the course. The ISTQB™ Certified Tester —Foundation Level certification exam is independently administered by the American Software Testing Qualifications Board, Inc. (ASTQB).