4.15 out of 5
4.15
565 reviews on Udemy

Getting and Writing IT Requirements in a Lean / Agile World

Business Analysis Techniques for Discovering Requirements, User Stories, Features, and Gherkin (Given-When-Then) Tests
Instructor:
Tom and Angela Hathaway
4,263 students enrolled
English [Auto-generated]
Define the capabilities and challenges of Lean and Agile software development philosophies
Adapt 10 different requirements gathering (elicitation) techniques to Lean, Agile, and Continuous Delivery software development environments
Support Lean or Agile teams by expressing business needs and wants in formats that optimally support all modern Software Development Methodologies (SDM)
Reduce the time wasted on miscommunication between stakeholders of IT projects by recognizing and removing terms and phrases that can be easily misinterpreted
Drill-down into requirements, features, user stories, and functions to identify and express test scenarios in Given-When-Then statements to facilitate automated testing
Identify 17 types of Non-Functional Requirements (NFR) and develop Given-When-Then (GWT) test scenarios for them
Leverage the learning curve to incorporate the presented techniques into your job

Meeting the Agile, Lean, and DevOps Requirements Challenge

Problem solvers are in demand in every organization, large and small, from a Mom and Pop shop to the federal government. Increase your value to yourself and to your group or organization by improving your ability to extract, express, and analyze business needs in formats that are supported by Agile, Lean, and DevOps philosophies.

The single largest challenge facing organizations around the world is how to leverage their Information Technology to gain competitive advantage. This is not about how to program the devices, it is determining what the devices should do. The skills required to identify and define the best IT solutions are invaluable for every role in the organization. These skills can propel you from the mail room to the boardroom by making your organization more effective and more profitable.

An Agile Approach for Getting from Visions and Requirements to Test Scenarios

In this course, you will learn how the concepts of Agile, Lean, and Continuous Delivery software development philosophies influence the discovery, expression, and analysis of business needs.

You will learn how to express those needs in user story format, as features or requirement statements, and ultimately as Given-When-Then structures. This is the language that allows developers to deliver the IT solutions the organization needs.   

This exercise-rich, interactive requirements discovery workshop provides a proven set of core business analysis techniques, methods and tricks. The presented content will help agile and lean software development teams, business analysts, product owners, test developers, and subject matter experts discover, capture, clarify, and confirm the kind of IT requirements that solution providers need to deliver the right information technology solutions for the business.

Introduction to the Course

1
Course Description and Learning Objectives

This introductory section gives viewers a sense of how the class works, and what they will learn in this course. Students will also gain a feel for how the instructor presents the material to see if it matches their preferred learning style.

2
Instructor Bio

This section introduces Tom and Angela Hathaway, the instructor and course developers. Learn why they are uniquely qualified to present this material.

Requirements in a Lean and Agile World

1
Agile and Lean Philosophies

The Agile Manifesto and Lean Manufacturing Principles have changed the IT landscape. This lecture provides a basic understanding of what these are and why they are important.

2
Communicating Business Needs in Lean and Agile Environments

Over the past 70 odd years, every study of IT project failures has identified missing and misunderstood requirements as the major contributor. This section explains how Agile and Lean philosophies attempt to solve this seemingly intractable problem.

3
Using Cynefin to Prioritize and Analyze Features, User Stories, and Requirements

Cynefin is a concrete, simple yet powerful weapon in your arsenal identifying and dealing with IT project issues. It has proven to be effective in many different settings. You will find it useful in determining which projects are more likely to succeed before you spend a ton of resources. It is also a valuable tool for assessing and prioritizing individual Features, User Stories, and literally any form of expressing a business need.

4
Cynefin Applied to Proposed Initiatives
5
Analysis in Lean and Agile Environments

When do you perform critical business analysis activities in Lean and Agile approaches and what level of detail do the activities need to achieve?

Requirements Discovery for Agile and Lean IT Projects

1
Common Elicitation Techniques and Challenges

Eliciting requirements includes the simple process of asking questions but that is just the tip of the iceberg.

2
Tracking Progress with a Question file

The simple act of creating and maintaining an open Question File from the beginning of the project through to the end keeps you abreast of your analysis progress and provides a detailed project history. This is the ideal format for a lessons-learned evaluation.

3
What Makes a Good Requirements Elicitor?
4
Tips and Tricks for Effective Conversations

There are 5 fundamental approaches for eliciting requirements and each has its own pros and cons. In addition, each requires some level of planning, performing, and publishing.

5
Comparing Types of Requirements Elicitation Meetings
6
Identifying and Interacting with Stakeholders

Stakeholder identification is one of the more critical early project activities. Missing critical stakeholders early in the project always leads to missed delivery dates or failed projects.

7
Stakeholder Identification
8
Agile Requirements: Tips for Stakeholder Interactions / User Story Conversations

Although you have been communicating with other people since before you learned how to talk, finding the right tone and content of a requirements elicitation conversation can still be challenging.

9
Non-Verbal Communication

The core idea of non-verbal communication sound trivial, but experience teaches us that words not spoken often contribute more to accurate understanding than everything the person says.

10
Dealing with People

A comedian once quipped, "Earth would be such a lovely planet if it weren't for all the people." Whether you agree with that comment or not, it obviously is not a great attitude for anyone trying to elicit requirements. We all have issues with certain behaviors of other people, in particular when we are trying to achieve a specific outcome from our interaction. The good news is that there are ways of dealing with every behavior, if you only have time to think about them and plan ahead.

11
Problem People or People Problems?
12
Listening Techniques

Listening is an art, no doubt. When you are trying to elicit requirements, you need to apply powerful listening techniques to ensure that you get the right information out of the conversation.

13
Listening Techniques Applied
14
Success Criteria for Effective Communication

There are seven critical criteria for conducting effective requirements gathering conversations.

15
Business Problem Definition

Before you can start to discuss solutions, you should make sure that you are looking to solve the right problem. This simple problem analysis approach will start you down the right path.

16
Defining Business Problems
17
Problem Analysis Uncovers Requirements and Features

Once you have a list of potential problems, the challenge becomes how to reduce the list to the essential or "real" problems and separate out solutions or symptoms. 

18
Aristotelian Problem Symptom Reduction Applied

Writing Business and Stakeholder Features and Requirements

1
User Stories Are Stakeholder Requirements

The simple construct called a "User Story" is one of the best modes for expressing stakeholder requirements.

2
Reducing Complexity Increases Comprehension

There is immense power in simplicity. Expressing your requirements in simple, single, complete sentences will dramatically increase the number of people who understand what it really means. A good User Story is not a Victorian novel but a trigger for a conversation.

3
First-cut User Stories
4
User Stories Deliver Business Value

Unless the agile team knows what value a user story delivers, they have no way of determining its relative importance.

5
Relevance of Features, Requirements, and User Stories

Given that projects are restricted by budgets, you should ensure that every request is relevant, meaning in scope, for your project before you spend time delving into details of the request. Your first question should always be, "How does this request contribute to meeting the goal of the project?"

Avoiding Ambiguity and Subjectivity

1
Misunderstandings Kill Projects

Recognize how ambiguity and subjectivity in requirement statements, user stories, features, etc. impede achieving a common understanding among all audience members.

2
Causes of Requirements Ambiguity

Identify four common contributors to ambiguity that cause misunderstandings.

3
Commonly Used Terms Can Be Ambiguous
4
Revealing and Removing Ambiguity
5
Ensuring a Common Understanding

Use desk checking, peer reviews, and peer rephrasing to discover hidden ambiguity and subjectivity

6
More Ambiguity Reduction Techniques

Evaluate who is best suited to critique and revise your requirements, user stories, etc.

7
Using Out-of-Box Thinking to Reduce Ambiguity

Finding Test Scenarios in a LEAN, AGILE World

1
Test Scenarios Are the Ultimate Requirements

In spite of impressions, testing is the most time-consuming activity in the process of delivering IT applications. Unit, Integration/system, and acceptance testing consume about 45% of the total development time. This lecture introduces test-driven development techniques for improving the efficiency of the testing process.

2
What Are Scenarios and Outlines Using (Gherkin) Given-When-Then Format

Modern test-driven development approaches rely on test scenarios expressed in the language of Gherkin which relies on Given-When-Then (G-W-T) structures. This lecture provides a basic explanation of the meaning of G-W-T steps.

3
Expressing Scenarios in Given-When-Then Format
4
Engineering AGILE Test Data

Test data engineering uses equivalence classes, boundary values, and probable error to limit the number of tests required to achieve confidence that the application works as intended.

5
Engineering Test Data
6
Decision Tables Identify Scenarios

Decision tables are a reliable analysis tool for ensuring that an application behaves as intended in all possible situations.  A bonus is that the decision table leads directly into test scenarios.

7
Using Decision Tables for Test Scenario Identification
8
Symptoms Are Great Test Scenarios

Assuming you are able to perform basic problem analysis to distinguish symptoms from problems, the symptoms provide a treasure test of test scenarios for acceptance testing.

9
From Use Cases to Test Scenarios

Commonly considered a development or analysis tool, use cases lay the groundwork for testing as well.

10
Discovering Tests Scenarios Using a Use Case
11
More Test Scenario Identification Techniques

This lesson introduces 2 additional, lesser-known methods for identifying test scenarios that other approaches miss.

12
Functional Solution Requirements Reveal Scenarios

Identifying the functions that the application must support or that people need to use the application leads inexorably to test scenarios for unit, integration/system, and ultimately acceptance testing.

13
Functional Decomposition
14
Identify Given-When-Then (Gherkin) Scenarios From Functional Requirements

Once you have identified the functions the application performs, you need to consider what data each function needs and what data it creates to fine-tune your test scenarios.

15
Informational Decomposition

Dealing with Non-Functional Requirements (NFR)

1
Common Categories and Characteristics of NFR

Non-Functional Requirements (NFR) are often the cause of IT project failure. It is not enough to know the application does what it should do. The question is does it do it well enough, fast enough, often enough? Learn the most common types of NFR that are often neglected.

2
Discovering Non-Functional Requirements

Asking the right questions early in the process is key to determining which Non-Functional Requirements your project has to meet.

3
Identifying Given-When-Then (GWT) test scenarios for Non-functional Requirements

Discover why constraints form a special category of Non-Functional Requirements and are the most challenging to test.

4
Testing Non-Functional Requirements (NFR)

From Showtime to Go Time!

1
Bonus Lecture
You can view and review the lecture materials indefinitely, like an on-demand channel.
Definitely! If you have an internet connection, courses on Udemy are available on any device at any time. If you don't have an internet connection, some instructors also let their students download course lectures. That's up to the instructor though, so make sure you get on their good side!
4.2
4.2 out of 5
565 Ratings

Detailed Rating

Stars 5
219
Stars 4
243
Stars 3
80
Stars 2
20
Stars 1
3
8bb7bc62c97f443796b1e3b4c912ee3a
30-Day Money-Back Guarantee

Includes

5 hours on-demand video
1 article
Full lifetime access
Access on mobile and TV
Certificate of Completion