Writing Requirements for IT — Simply Put!
4.2 (101 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
1,078 students enrolled

Writing Requirements for IT — Simply Put!

Use Four Simple Rules to Improve the Quality of Your IT Requirements
Bestseller
4.2 (101 ratings)
Course Ratings are calculated from individual students’ ratings and a variety of other signals, like age of rating and reliability, to ensure that they reflect course quality fairly and accurately.
1,078 students enrolled
Last updated 3/2019
English
English [Auto-generated]
Current price: $45.00 Original price: $54.99 Discount: 18% off
30-Day Money-Back Guarantee
This course includes
  • 1 hour on-demand video
  • 1 article
  • Full lifetime access
  • Access on mobile and TV
  • Assignments
  • Certificate of Completion
Training 5 or more people?

Get your team access to Udemy's top 3,000+ courses anytime, anywhere.

Try Udemy for Business
What you'll learn
  • Write requirements that focus on the business need
  • Test the relevance of each requirement to ensure that it is in scope for your project

  • Create and maintain a question file to reduce the impact of incorrect assumptions

  • Minimize the risk of scope creep caused by missed requirements
  • Confirm that each audience shares a common understanding of the requirements
  • Use our Peer Perception technique to find ambiguous words and phrases that can lead to misunderstandings
  • Apply 3 simple rules to create technology-independent, component-focused requirements
  • Reduce the ambiguity of a statement by adding context and using standard terms and phrases
Requirements
  • No technical background required
  • Need or desire to define user requirements, features, user stories, etc.
  • Interest in finding more efficient ways to communicate business needs to the development community
  • HTML5 compatible browser for exercises
  • No additional materials are required
Description

Effective Requirements Reduce Project Failures

Writing requirements is one of the core competencies for anyone in an organization responsible for defining future Information Technology (IT) applications. However, nearly every independently executed root-cause analysis of IT project problems and failures in the past half-century have identified "misunderstood or incomplete requirements" as the primary cause. This has made writing requirements the bane of many projects.

The real problem is the subtle differences between "understanding" someone else’s requirement and "sharing a common understanding" with the author.

"Writing Requirements for IT — Simply Put!" gives you a set of 4 simple rules that will make your requirement statements more easily understood by all target audiences. The focus is to increase the "common understanding" between the author of a requirement and the solution providers (e.g., in-house or outsourced IT designers, developers, analysts, and vendors).

The rules we present in this book will reduce the failure rate of projects suffering from poor requirements. Regardless of your job title or role, if you are tasked with communicating your future needs to others, this course is for you.

How to Get the Most Out of this Course?

To maximize the learning effect, you will have optional, online exercises to assess your understanding of each presented technique. Lessons prefaced with the phrase “Exercise” contain an exercise that we have prepared to give you an opportunity to try the presented technique yourself.

These exercises are optional and they do not “test” your knowledge in the conventional sense. Their purpose is to demonstrate the use of the technique more real-life than our explanations can supply. We hope you enjoy them and that they make it easier for you to apply the techniques in real life.

Who this course is for:
  • Subject Matter Experts
  • Product Owners
  • Business Process Managers
  • Business Process Users
  • Product and Project Managers
  • Line Managers
  • Business Analysts
  • Anyone wearing the Business Analysis (BA) hat!
Course content
Expand all 19 lectures 01:17:06
+ Setting the Stage for Writing Effective Requirements
4 lectures 17:37

The instructor, Tom Hathaway, presents an overview including the scope and purpose of this course and introduces the learning objectives. 

Preview 02:45
  • The Problem with Requirements
  • The Benefits of Effective Requirements

External Resources with links to articles on the problems and/or benefits of requirements.

Preview 03:22
  • The Uncertainty Principle
  • What Do You Really Know?
  • THE Question File
Preview 08:18
The English language, and any other language for that matter, is very subjective, meaning that the meaning of a word or phrase depends heavily on context. This subjectivity leads to problems on IT projects. I have a little 2-part exercise to demonstrate my point.
Part 1 - The Subjectivity of Language
1 question
This is the continuation of the previous exercise demonstrating the subjectivity of the English language, and any other language for that matter. This subjectivity can lead to major problems on IT projects, in particular, during requirements definition.
Part 2 - The Subjectivity of Language
1 question

A brief look at some real-life examples of communication problems.

The "Real" Problem with Requirements
03:12
+ Capturing Requirements
2 lectures 13:10
  • Express Each Requirement as a Simple Sentence
  • Reducing Complexity Increases Comprehension
  • A Complete Sentence Forces a Complete Thought
  • Structured Requirement Statements

Are you working in an Agile Environment? The video "User Stories: Agile Requirements Definition (Part 1)" below might interest you:

Follow the KISS concept
08:47

Test your understanding of Rule 1. Each question contains a requirement statement. Each presented statement can meet one, two, all, or none of the criteria you learned in Rule 1. Evaluate whether the presented requirement statement meets the criteria of Rule 1, meaning is it:

1.      SIMPLE (a simple and not a compound sentence - one thought, no-if, and's but's, unless, or except)

2.      COMPLETE (the statement stands on its own and has a subject, verb, and object)

3.      WELL-STRUCTURED (the statement identifies who should or should not do what. It is role-based or a constraint)

Rule 1 - Writing Simple, Complete, and Well-Structured Requirements
8 questions
  • Focus on “What”, Not “How”
  • Consider the Business Result, Not the IT Solution

This lecture introduces the second rule for writing better requirements in plain English. For those working in an Agile environment, watch our YouTube video below (User Stories: What, Not How) that describes rule 2 using User Stories.

Define the Business Need
04:23
This exercise will test your interpretation of Rule 2. We modified 6 requirements in this exercise to make sure they are simple, complete, and well-structured. The challenge is whether we agree on how well they comply with the “what-not-how” rule.
Rule 2 - Avoiding the Elusive “How” in Your Requirements Statements
6 questions
+ Requirements and Project Scope
3 lectures 10:33

This lecture addresses the scope issue on IT projects as it relates to requirements. It covers:

  • Enforcing Your Project Scope
  • The Project Scope Statement
  • Defining Scope at the Component Level
Keep Your Requirements in Scope
04:12
This assignment will test your ability to identify common components of an IT business solution. Once you have identified all the components you can, we will give you an example of other student responses to this assignment.
Relevant Requirement Components
1 question
  • Focused Requirements Minimize Misinterpretations
  • Relevant Requirements Reduce Project Effort
  • Identifying Relevant Requirements

If you are working in an Agile environment you might be more interested in our video below "User Stories: Defining IT Requirements (Part 3)".

Combat Scope Creep from the Start
04:44

At this point, we have improved our requirements, but are they relevant (in scope)? That is the question, and this is a neat little exercise to give you an opportunity to test once again whether you agree with us.

We will present you with 4 Requirement Statements. Mark the correct combination of components that are in-scope and out-of-scope based on the following Scope Statement:

Scope Statement
This project will enhance our web-based Policy Maintenance System by allowing policyholders to interact directly with their insurance policies or claims. The system will support web-based policy payments and allow prospects to apply for temporary coverage pending underwriting rate approval.

Testing the Scope Boundaries
4 questions

This lecture gives you an opportunity to test your understanding of the first three rules.

Recap of Rules One through Three
01:37
This exercise will test your ability to evaluate requirements for compliance with all of the rules we have covered.
Applying the First Three Rules
5 questions
+ Finding and Fixing Ambiguous Requirements
4 lectures 19:00

This lecture discusses the difficulties that plague IT requirements. It presents:

  • Avoid Ambiguity in Your Requirements
  • Ambiguity Kills Projects
  • Who Needs to Understand Your Requirements?
  • Roadblocks to Effective Communication
Preview 05:27

This lecture addresses the problem that ambiguity causes in the world of requirements for IT projects. It covers:

  • Rampant Ambiguity
  • Desk-Checking Uncovers Ambiguity
The Challenge to Understanding
02:34
This assignment will test your ability to spot ambiguous terms in 3 different requirement statements.
Finding Ambiguity with the Subject Matter Expert (SME)
3 questions

This lecture a quick-fix for discovering and reducing some of the ambiguity in your requirements. It covers:

  • Requirements Define the Future
  • Restating Requirements to Find Ambiguity
  • Picking the Right Peers
Use Peer Reviews to Increase Understandability
05:17

Having used the Peer Perception technique to ferret out potential misunderstandings, you need to use that newfound knowledge.

Revising Requirements to Reduce Ambiguity
2 questions

This lecture introduces a second technique for reducing some of the ambiguity in your requirements. It covers:

  • Revise Ambiguous Elements
  • Revising, Defining, and Clarifying Your Requirements
Combatting the Major Cause of Project Failure
05:42

Your assignment, should you accept it, is to identify which “rewrite” matches a provided requirement statement? This will show you the power of "rewrites".

Part 1 - Requirements Interpretations
2 questions
Now that you have tested your ability to recognize the rewritten requirements and had an opportunity to see some of the value provided by this technique, it is time for you to do your own rewrite.
Part 2 - Requirements Interpretations
1 question
+ Best Practices for Improving the Understandability of Your Requirements
4 lectures 11:23

This lecture discusses the proper use of acronyms and standard terms for further reducing ambiguity in your requirements. It covers:

  • Acronyms, Yes, BUT …
  • Make Use of Corporate and Industry Standards
  • The Power of a Glossary
Use Acronyms and Corporate Standards
04:18

Deciding whether to expand an acronym, use a glossary, or replace a term with an industry standard could require some thought. Test your ability to make these decisions with this quiz. We will present you with a requirement statement and a set of potential actions that might or might not improve the understandability of the requirement.

Using Revisions to Reduce Ambiguity
3 questions

This lecture explains how maintaining context in your requirements will help you reduce ambiguity. It covers:

  • The Major Cause of Ambiguity
  • Adding Context and Other Missing Information
Add Context to Eliminate Ambiguity
02:51
Test your ability to remove ambiguity from requirements by asking the right questions. Using one requirement statement, you will improve the clarity one term at a time.
Appropriate Context Reduces Ambiguity
4 questions

In this lecture we will explain what readability indices are and how to use them in your requirement writings. An understandable requirement is written to the readability level of the target audience by staying within standard readability indices.

If you work in an Agile project environment, browse these links:

Write to the Readability Level of Your Audience
03:01

What readability level do you score? Test your understanding of applying readability indices to your requirements.   

Using Readability Indices
5 questions

A summary of requirements and ambiguity.

Recap of Rule 4
01:13
This assignment will test your ability to recognize and remove ambiguity from your requirement statements.
Applying Rule 4
6 questions
+ In Closing
2 lectures 05:39

An introduction of rule 5 targeting Solution-level requirements. Download a printable copy of the "5 Simple Rules for Effective Requirements" using the link below.

Claim Your Job Aid
01:33

If you enjoyed this class, you might also enjoy additional training offers from BA-EXPERTS.

Bonus Lecture: Mastering the Learning Curve
04:06