How to Elicit (Gather), Write, and Analyze Business Requirements

The International Institute of Business Analysis (IIBA^®) in their Business Analysis Body of Knowledge^® (BABOK^® v2.0) define 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), capture, write (express), and analyze business requirements. Requirements written in human language can be subjective, ambiguous, and subject to interpretation. To create "good" requirements, you need to become proficient in the “language and techniques” of requirements definition. The course covers how to write effective business requirements and includes business analysis techniques to identify and analyze business problems.

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 live at your site or in two virtual sessions via the Internet.

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.

1. Introduction to Business Analysis

Who Needs Requirements, Anyway?

The Uncertainty Principle

The Fate Chart

Exercise: A Problem with Language

A Question File

The Three C’s of Requirements Elicitation

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

Use Cases in their Environment

Evolution of a Use Case

Requirements Categorization

What Use Cases ARE NOT!

Will Use Cases Meet Your Needs?

What Use is a Use Case?

Exercise: Introducing Use Case Concepts

Changing How the Business Works

Naming Use Cases

Purpose of a Use Case

Details of a Use Case

Use of a Use Case

Components of a Use Case

Discovering Use Cases

Building Use Cases

Of Business Events and Use Cases

Business Events

Determining Event Responses

Exercise: Identifying Business Events

Exercise: Simple Event Response Table

From Business Events to Use Cases

The Role of Actors

Naming Actors

Finding Actors

Exercise: Identifying Actors

Inside the Use Case

Discussion: The Use Case Value Equation

Before the Beginning

In the End

Flow of Events

Identifying Common Elements

Including Use Cases

Use Case Extensions

Extending Use Cases

On Extensions and Inclusions

Exercise: Pros and Cons of Inclusions and Extensions

Inside the Use Case Checklist

Discussion: What Measures Add Value to a Use Case?

User Scenarios: A Bottom-Up Approach to Use Cases

Use Case Scenario Structure: Donald Pays For Insurance

The Advantage of Scenarios

Exercise: Bottom-up Use Cases

Discussion: Pros and Cons of Use Cases

3. Requirements Writing (Clarify)

Writing Effective Business Requirements

The Problem with Natural Language Requirements

Clarifying Requirements

Creating Requirement Statements

Business System Requirements

Rules for a “Good” Requirement Sentence

Reducing Complexity Increases Comprehension

A Complete Sentence Forces a Complete Thought

Structured Requirement Statements

Exercise: Creating Complete Sentence Requirements

Rules for a “Good” Requirement Sentence

Think “What”, Not “How”

Exercise: Finding the What versus the How

Rules Review

Exercise: Applying the Rules

Removing Requirements Ambiguity

Rules for an “Understandable” Requirement Sentence

Relevance Increases Comprehension

Ambiguity Ruins Requirements

Increasing Understandability

Rules for a “Good” Requirement Sentence

Peer Reviews Clarify Requirements

Clarifying Mutual Understanding

Revise, Define and Clarify Your Requirements

Exercise: Desk-Checking

Verifying Understandability

Rules Review

Clarifying Requirements

Writing Measurable Requirement Statements

Rules for a “Testable” Requirement Sentence

To Test or Not to Test is NOT the Question

Requirements Testability

Effective Requirements are Verifiable or Testable

Decomposing Requirements

Components of Requirements

Exercise: Requirements Types

Requirement Subtypes vs the 10 Critical Questions

Testing Requirement Components

Finding Functional Requirements

Testing Functional Components

Exercise: Testing the Functional Components

Finding Rules and Constraining Requirements

Testing Rule and Constraint Components

Exercise: Testing Rule and Constraint Components

Finding Performance Requirements

Exercise: Resolving Subjective Components

Exercise: Decomposing a Requirement

Purpose of Requirements Decomposition

Confirming Performance Requirements

Understanding Performance Requirements

Clarifying Quantitative Performance Requirements

Quantifying Qualitative Requirements

Testing Performance Components

Exercise: Testing Performance Components

4. Requirements Analysis (Confirm)

Identifying Business Components

Exercise: Components of a Business System

Business Information Systems

Clarifying Business Requirements

Exercise: Grouping Requirements

Combining Requirements

Detailed Clarification

Rules for “Effective” Sets of Requirements

Identifying Inconsistent Requirements

Exercise: Identifying Inconsistent Requirements

Rules for “Effective” Sets of Requirements

Of Rules and Requirements

Business Rules Are

Rules vs. Requirements

Rules Relationships

The Rules Challenge

Exercise: Testing Rules

Requirements Prioritization

Rules for “Effective” Sets of Requirements

Need-based Requirements Prioritization

Release-based Requirements Prioritization

Confirming Business Requirements

Rules for “Effective” Sets of Requirements

Confirming Feasibilities

Identifying High Risk Requirements

PASS = Project Audit Support Services

Exercise: Verifying Requirements Completeness

Requirements Tools and Templates

Requirement Documentation Template(s)

Tools Discussion

The Payback

• Manage questions and open items lists
• 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
• Describe what business events are and how they interact with technology
• Define the evolving role of business systems analysts
• Apply 5 methods for discovering use cases
• Present the transition from business events to use cases
• Illustrate the major components of the use case
• Document proposed user interaction in use cases and use case diagrams
• Structure basic use case information in a use case document
• Use use case diagrams as a scoping tool
• Document scenarios to discover use cases
• Detail the sequence of interaction steps for the most common situation
• Determine how to handle alternate and exception situations
• Write audience-focused use cases
• Apply 5 methods for discovering use cases
• Apply the five rules of a "good" requirement sentence
• Translate business needs into well-structured business requirement statements
• Write business requirements that express the what and avoid the how
• Discuss the problem with language based requirements
• Verify the "testability" of a requirement
• Decompose requirements into the major types of requirements and their subtypes
• Further clarify business rules, performance and constraining requirements
• Use a standard readability index to improve understanding
• Discuss the difficulties in writing quality, "-ability" requirements (ex: reliability)
• Distinguish qualitative from quantitative performance factors
• Classify 7 major components of business systems that need analysis
• Apply the four rules for managing a group of requirements
• Prioritize requirements based on business and system needs
• Choose risk reduction alternatives for high-risk requirements
• Evaluate the completeness of requirements
• Categorize requirements based on focus
• Create a requirement/problem matrix to confirm requirements completeness
• Confirm (determine relative importance and feasibility) of requirements
• Use templates to guide writing requirements

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 *
Company
Phone
Questions / additional comments