How to Elicit (Gather), Write, and Analyze 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 of the organization that any IT solution has to support.
• Stakeholder requirements specify the needs of individuals or groups within the organization.
• 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, stakeholder, solution, and transition 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 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

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. Requirements Writing (Clarify)

Writing Effective Business Requirements

The Problem with Natural Language 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

Example: Creating Complete Sentence Requirements

Rules for a “Good” Requirement Sentence

Think “What”, Not “How”

Example: 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

Get More Info

Name

Email

Telephone

• 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
• 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*
Telephone*
Company*
Questions / additional comments: