How to Elicit (Gather) Requirements

Get More Info

Name

Email

Telephone

The International Institute of Business Analysis (IIBA^®) in their Business Analysis Body of Knowledge^® (BABOK^® v2.0) defines four major categories of requirements that are common to information technology projects:

• Business requirements define the goals and objectives that any IT solution has to support.
• Stakeholder requirements specify the needs of individuals or groups.
• Solution requirements describe functions, information, and specific qualities that the delivered technology has to enable.
• Finally, transition requirements define behaviors that facilitate moving from the as-is state of the enterprise to the to-be state.

This course gives you a proven set of core techniques, methods, and tricks to elicit (gather or capture) business, stakeholder, solution, and transition requirements. Requirements elicitation is more than simply asking stakeholders what they want. The course offers a variety of techniques that force stakeholders to consider different dimensions of the solution which helps them recognize and express requirements they did not know they had.

NOTE: The techniques taught in this course are methodology-neutral, meaning they are relevant to traditional, UML or Agile development environments. This instructor-led course can be delivered in a series of virtual sessions via the Internet or live your site.

IIBA^®, the IIBA^® logo, BABOK^® and Business Analysis Body of Knowledge^® are registered trademarks owned by International Institute of Business Analysis. These trademarks are used with the express permission of International Institute of Business Analysis.

Get More Info

Name

Email

Telephone

1. Introduction to Business Analysis

Who Needs Requirements, Anyway?

The Fate Chart

A Question File

Exercise: A Problem with Language

Exercise: Initial Requirement Statements

Requirements Defined

Requirements a la BABOK®

Types of Requirements

The Business of Requirements

Stakeholder Perspectives

Defining the Solution

Getting from the AS-IS to the TO-BE

Analysis of Business Systems Analysis

2. Requirements Elicitation (Capture)

Who Do You Talk to about What?

Identifying Stakeholders

Using an Org chart

Exercise: Stakeholder Identification

Document Analysis

System Vision

WasteTheWaist “Vision Statement” from CEO

Exercise: From Vision to Requirement Statements

Vision Statement Evaluation

Exercise: Structured Vision Statement

Problem Definition

Defining the Real Problem

Exercise: Problem Identification

Aristotelian Problem/Symptom Reduction

Rewriting a Problem Statement

Getting Written Problem Statements

Exercise: Aristotelian Problem Symptom Reduction

Exercise (cont.): Problem Statements

From Problems to Requirements

Exercise: Getting Requirements from Problems

Interviewing Techniques

Exercise: Characteristics of a “Good” Interviewer

Interviewing Steps

Plan for the Interview

Perform the Interview

Follow Up the Interview

Exercise: Interviewing: Some Other Ideas

Exercise: Using Interviewing Techniques

Email Interviews 10 Steps

Exercise: Face-to-Face Interview versus Email Interview

Types of Requirements Gathering Meetings

Workshop Sessions (groups)

Brainstorming Sessions

Focus Groups

User Groups

Exercise: The Need for Speed

Accelerated Workshop Sessions

Time Compression and Understanding

Using Surveys to Elicit Requirements

The Delphi Technique (Survey)

The Delphi Technique

Analysis by Walking Around (Site Visits)

Exercise: Analysis by Walking Around (site visits)

Walking Around Notational Technique

Requirements Elicitation Critical Questions

Critical Questions

Applying the 10 Critical Questions

Considering Prototyping

Prototyping and Requirements

Four Levels of Prototyping

Prototyping & Ten Critical Questions

3. Introduction to User Stories

What Are User Stories

User Stories: “First Rules"

User Stories: Defined by Example

Major Components of User Stories

When Are User Stories Written?

4. Use Stories are Driven by Roles

When are user stories written

Who Writes User Stories

User Roles

Adding Role Details

Rewriting the Roles “Second Rules"

5. How do you get user stories (techniques)

How Do You Get to User Stories

Standard Techniques

Story Writing Workshops

How Do You Manage User Stories?

6. What is a good user story

Business Focused User Stories

Value and User Goals

Story Value

Value Measurement-Right Sized

Complex User Stories

Dependency

7. How do user stories support testing

From User Stories to Test Scenarios

Testing Begins with the First User Story

Tests and Cards

Questions to Guide the Test Process

Case 6: group/individual: Discussable/Testable Stories?

Case 7: pairs: Did You Write Testable Stories?

8. User Stories Summary

Good and Not-So-Good User Stories

Properties of a Good Story

Properties of a Bad Story

Not All Things Are Stories

Summary

9. Event-based Requirements Elicitation

Business Event/Response Analysis

Business Events and Responses

Business Events Defined

Business Event Naming Convention

Defining Business Events

Exercise: Finding Business Events

Identifying Project Scope

Exercise: Confirming Project Scope

Determining Event Responses

Event Response Naming Convention

Exercise: Documenting Business Events

Exercise: Event/Response Table (v 1.0)

Understanding Triggers

Non-Triggered Events

Scheduled Events

Exercise: Adding Event Triggers

Exercise: Event/Response Table (v 1.1)

Additional Event/Response Information

Event/Response Table (v 1.2)

Get More Info

Name

Email

Telephone

• Manage questions and open items lists
• Classify the 5 types of requirements described in the BABOK^®
• Identify the value of good requirements
• Evaluate a management vision statement
• Write business requirements that solve business problems
• Creates requirements during "analysis by walking around"
• Develop and process surveys
• Prepare, perform and follow up requirements interviews
• Use 10 critical requirements questions to guide the requirements capture process
• Contrast the pros and cons of prototyping for requirements
• List the components of a user story
• Explain the strengths and weaknesses of User stories
• Identify the appropriate time to use user stories
• Describe how user stories support testing
• Describe what makes a "good" user story
• Create business event/response tables
• Develop requirements based on business events and responses

The pdf file will open or has opened in a new window.

 

We do not currently have a public offering of this class scheduled. To add your name to the waiting list or request alternate offers, please contact us.
Check All Scheduled Business Analysis Training Offers

Name*
Email*
Telephone*
Company*
Questions / additional comments: