Writing Requirements for IT — Simply Put!
- 1 hour on-demand video
- 1 article
- Full lifetime access
- Access on mobile and TV
- Certificate of Completion
Get your team access to Udemy's top 3,000+ courses anytime, anywhere.Try Udemy for Business
- 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
- 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
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.
- 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!
The instructor, Tom Hathaway, presents an overview including the scope and purpose of this course and introduces the learning objectives.
- The Problem with Requirements
- The Benefits of Effective Requirements
External Resources with links to articles on the problems and/or benefits of requirements.
- The Uncertainty Principle
- What Do You Really Know?
- THE Question File
- 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:
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)
- 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.
- 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)".
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:
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.
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
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.
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: