Requirements Management Ruminations

by , , , , , , , , , , ,
A collaborative blog with contributions from members of the PMI Requirements Management Community of Practice and various authors and presenters who have dealt with the topic of requirements management.

About this Blog


View Posts By:

Cameron McGaughy
Abdulilah Angaa
Mike Frenette
Beth Ouellette
Victoria Cupet
Jhansi Vijayarajan
Bobbye Underwood
Sally Elatta
Rich Larson
Elizabeth Larson
Ellen Gottesdiener
Mary Gorman

Recent Posts

Natural Language Processing to sharpen up your requirements

Automating requirements review using Natural Language Processing

Actionable Agile Tools - a book review

What’s Hot and What’s Not--Trends in Business Analysis Webinar Follow-up

Project Managers Find New Rhythm at PMI® Global Congress’ First Agile Open Jam

The Four Levels of Agile Requirements

Categories: Agile

Don’t you just love the word ‘Requirements’? It’s just so clear isn’t it – NOT! Have you ever heard your business customer say ‘I’ve already given you my requirements’ and the team then says ‘We haven’t received clear or detailed  requirements’? the other side to this is when the team tells the customer ‘You are giving us too much details, don’t tell us where the button goes on the screen, just tell us what you want’.  No wonder we have so many requirements related issues on our projects!

During one of my previous PMI webinars we talked about  Agile Requirements – Breaking Down EPICs and Prioritizing.  I’ll take a stab through this blog at summarizing the levels of Agile (and frankly non Agile) requirements and how you can use a four step process for gathering them.

First, let’s start with the picture below. The picture shows 4 levels of requirements and also on the left is the 4 step process for gathering requirements.

Agile Requirements Levels


: This is the initial step of gathering requirements. The goal is to help identify all the Themes and some features desired. This exercise begins to define the scope of what is expected.


: The goal of this step is to identify all the features and stories desired. The key here is Breadth First, Depth Later. So instead of discussing the details of each feature and story, our main goal is to FIND all the features and stories.


: The goal of this step to breakdown and slice the stories that are still too large (EPICs) into smaller chunks. You probably have already done a lot of slicing during brainstorming but as you comb your backlog, the team will realize that some stories are still too large to be completed within an iteration (usually 1-4 weeks). Slicing stories is an art and I will dedicate an entire blog to it!

Deep Dive

: This is the step everyone wants to jump into right away! Yes, finally let’s talk about the details. What will be on the screen, what are the exact business rules and how will we test them, what will the detailed process look like, what are the tasks we need to get done to complete this story. Jumping into this level of detail upfront during the initial phases is one of the main reasons contributing to scope creep later during the project.

Suppose we are developing a system for an online job posting site Here is an example of what the requirements could look like based on the levels above:

1.     Employer Area – Theme

a.     Manage Jobs – Feature

1.As an employer I want to post a job so others can find it. Story

2.As an employer I want to modify a job posting so it is correct. Story

3.As an employer I want view a list of my open job postings so I can analyze them.  Story

4.As an employer I want to expire a job posting so no one can apply. Story

b.     Manage Applicants

1.As an employer I want to view the list of recent applicants so I can respond to them.

2.As an employer I want to view the list of applicants for a specific job positing so I can qualify them.

3.As an employer I want to select the top candidates so I can interview them.

You should gather the levels above (Themes, Features, Stories) upfront when you are planning out your release, especially if you have the raditional projects with begin and end dates. We usually spend more effort on the stories that are coming up in the next few iterations or the next release.

The Deep Dive is where the main difference lies between Agile and Waterfall. Traditional teams would gather this very detailed information upfront for ALL the stories on the backlog, where Agile teams will gather these details Just In Time for the next stories, which is one or two iterations before that story needs to be DONE.

Here is an example of what the details could look like for this selected story:
“As an employer I want to post a job so others can find it.”.

Acceptance Criteria/Tests
How will we know when we’re done):

1.     UAT1 – Verify that only an authorized user with a valid employer account can post a job.

2.     UAT2 – Verify that a duplicate job posting cannot be entered.

3.     UAT3 – Verify that the posting date is past today’s date.

4.     UAT4 –Verify that the positing expiration date within 90 days.

5.     UAT5 – Verify that the screen fields pass our standard field format rules.

6.     UAT6 – Verify that all required fields are entered.

Acceptance criteria are the ‘details’ of the story and they are considered primary requirements in Agile. We gather them upfront before any development begins.

Sample Tasks (The work we need to do to get this done):

1. Create a database tables to store the job posting details.

2. Design and build the screen for job posting.

3. Develop the logic for UAT1 to pass.

4. Document/record the on page video help for the job posting page.

5. Perform user acceptance testing.

6. Deploy the code to the test environment.

7. ….. others..

UI Prototype/Wireframe and Activity Diagrams:
These could be hand drawn sketches of the screen or the process steps involved for the system to accomplish the process defined.

Quiz Time – What is What?

Would you like to test your skills and ability to differentiate between the various levels of requirements? Take a look at the list of requirements’ below and jot down your thoughts on if each item is a Theme, Feature, Story or the Details of a story. I’ve purposely made them tricky and some of them could have two answers depending on the context you define. I will share the answers in my next blog so stay tuned!

a)     We need the ability to filter our reports by date and group #.

b)     We want to manage user access to the site and limit who has access to what.

c)     We want to make sure that only Managers can access the salary data.

d)     We want customers to pay using credit cards online.

e)     We want to verify that discover card payments are not allowed.

f)      We want scheduled and ad hoc reporting.

Please post a comment or question below and share with us your own experience and challenges with requirements. Do the levels above make sense? Do you see value in organizing requirements this way? Please share any tips you have with managing the levels of requirements.


Sally Elatta – President
Agile Transformation, Inc. 

About Me:
I am simply a transformer. Someone who is really passionate about helping organizations move towards building highly engaged collaborative teams that can deliver value predictably. I like to find practical solutions to solve real problems and use a combination of Agile, Scrum, Lean, Soft Skills and Servant Leadership to reach the desired target. I have an interesting mix of technical background as a software Architect in addition to business skills that help me connect with audiences at various levels. My goal is to transform individuals, teams and organizations to doing what they do better. 
Posted by Sally Elatta on: December 23, 2014 10:51 AM | Permalink | Comments (9)

You Don't have Requirements!

Categories: Project Requirements

So you think you know all the answers? Well.... you don't! If you are running projects, the people with the answers are your clients.. They will define the scope of your project, and the detailed requirements of what they want.

And guess what? If you don't ask them, you won't know the requirements. Seems pretty simple, doesn't it? Yet, amazingly, according to the 2014 Project Management Institute's Pulse of the Profession In-Depth Report on Requirements Management, "Poor requirements management is a major cause of project failure, second only to changing organization priorities."

How do you discover requirements on your projects? Conversations? Workshops? Interviews? Surveys? Once discovered, how do you record and confirm them? Documents? Emails? Memos? Phone calls? Texts? Data and Process Models? Other forms of models? And once discovered, documented and, hopefully, reviewed and approved, how do you make sure the project delivers what is expected?

So many questions, so few answers!

Oh... wait. There are answers! The Project Management Institute has recently released Business Analysis for Practitioners: A Practice Guide, written by some real gurus in the industry. I can personally vouch for the authors and the guide, having read their books and attended webinars some of them have presented. I also listened to their apt answers to some great questions from the audience at a recent panel session presented at the PMI Global Congress this past October. I've browsed through the new guide and am happy to report that it is brimming with great tools, tips and techniques to help you define, record and manage requirements in a project.

So - what are you waiting for? Go get the guide while it is still available for free download, read it, use it and spread the word!

In 2015, let's change it so poor requirements management is no longer the number two reason for project failure. Let's make the excellent management of requirements the number one reason for project success!

This same post drew some criticism on LinkedIn in that a responder suggested that you don't always have a client, citing products like the iPhone, Twitter and Facebook as being clientless.  What do YOU think? Is there such a thing as a clientless project where requirements appear out of the ozone? Or might that be a semantical argument about the word "client"?  Respond here (and on LinkedIn if you like.)

Posted by Mike Frenette on: December 23, 2014 09:50 AM | Permalink | Comments (12)

PMI Releases Business Analysis for Practitioners: A Practice Guide - free download for the next 6 months!

Did you know that according to research PMI conducted in 2014 that only 64% of completed projects met their original goals and business intent? That 16% of projects in the last 12 months were failures? That 37% of organizations reported "inaccurate requirements gathering" as the primary cause of project failure? That poor requirements management practices are the second leading cause of project failure, second only to changing organization priorities?

Thankfully, good business analysis on projects and programs result in customer expectations being met, engaged and committed stakeholders, projects that are more likely to be delivered on time and within scope and budget, implemented solutions that provide business value and meet stakeholder needs, all while developing reusable business analysis competencies for future projects.

The above are quotes and paraphrases from the recently released the Project Management Institute's 227 page Business Analysis for Practitioners: A Practice Guide. It is available for free download for the next six months. Written by experts in the field, it is chock full of solid tools and techniques to help you succeed on your projects and programs in the area of business analysis and requirements management.

Why not get it today and learn more about Needs Assessment, Business Analysis Planning, Requirements Elicitation and Analysis, Traceability and Monitoring and Solution Evaluation? From SWOTs and Five Whys to Use Cases and Wireframes, and everything in between, you will be glad you did!

And keep an eye on this Blog for possible posts by some of the Practice Guide's core and review committee members, among them Elizabeth Larson, Rich Larson and Ellen Gottesdiener.

Get your free copy here for the next six months at this link:

Posted by Mike Frenette on: December 09, 2014 03:27 PM | Permalink | Comments (9)

Top Tips for Effective Requirements Management

My colleague Beth Ouellette and I had a little fun at the Phoenix PMI Congress with our presentation of Top Tips for Effective Requirements Management collected through a survey of the 18,000 member Requirements Management Community of Practice and through the webinars presented to the Community over time.  We thought we would liven things up a little by presenting short vignettes acted out by volunteers from the audience.  Following are the names of the skits with a brief explanation of what they were meant to convey. The first five convey project issues. The rest show actions you can take to manage requirements to help drive project success.

  1. Perfect Project, Imperfect Results - The Iron Triangle is satisfied, but the project provides little business value.
  2. The Elastic Project - Your clients want an Agile project, but they still want a fixed price.
  3. Here's Your Hat - What's Your Hurry? - Too many defects found in user acceptance testing.
  4. The Silo Projecct - Integration and interfaces with other projects is unclear.
  5. What to Expect When Your Client is Expecting - Your clients' expectations are too high.
  6. As Time Goes On, You Realize - Time lags for various approvals slows the project life cycle.
  7. The Only Constant Is... - Too many changes through the course of the project.
  8. Ten Pounds of Bologna In a Five Pound Skin - Clients expect budget to be static while scope increases.
  9. Dreamer - You're Nothin' But a Dreamer - Clients do not know what they want.

We wrapped up the session with the seven keys to requirements management success:

  1. Requirements must be managed to ensure true business value is achieved
  2. Involve the right people.
  3. Have the right expectations.
  4. Quality in requirements is as important or even more important than quality in the product.
  5. Consider the interface and integration points with other projects.
  6. Faclilitate timely approvals.
  7. Manage changes to requirements - they can completely alter the nature of a project.

What has been your experience with the impact of requirements on your projects?  Have you experienced any of the project and requirements issues we tried to get across with our humourous skits?  Maybe you were at the session in Phoenix and have something you'd like to add.

Top Tips for Effective Requirements Management
Posted by Mike Frenette on: November 17, 2014 09:15 AM | Permalink | Comments (1)

Be Satisfied With What I Give You--It’s Better Than What You Asked For - Part 2 Managing Changes

My Uncle Bill used to tell us that no matter what type of hotel or where it was located, no matter how many of the hotel staff he talked to in advance of their arrival, Aunt Roslyn would look at the assigned hotel room, find it inadequate, and request a change of rooms. When we were younger, we always felt sorry for Uncle Bill. How patient, how long-suffering he was to put up with the inevitable bother of changing hotel rooms.

However, as we’ve aged, my husband and I find ourselves changing hotel rooms more frequently. In Part 1 of this blog, I wrote about the feature fallacy, citing the example of a hotel front-desk clerk who gave us a hotel room with features we didn’t want, but without those we wanted. After trying unsuccessfully to convince us to stay in the assigned suite, he told us respectfully but firmly that no other rooms were available and change was not possible. In desperation we agreed to pay a fortune to upgrade to get what we originally asked for. Nevertheless, the clerk appeared unhappy. Clearly, the change request was an anomaly and upset his process.

I suspect that many of our sponsors and other business stakeholders are reluctant to request changes because of our body language, because of a burdensome change process, or because they are used to being told “you can’t have that change. It’s out-of-scope.”

In looking back, it seems that we’ve been less likely to change rooms when we’ve taken a virtual tour of the hotel prior to booking a room. Unlike photos taken at just the right angle to make a tiny, bare room look cozy and comfortable, a virtual tour provides a broader perspective of the room in relationship to the rest of the hotel. Pictures provide a structure for us to help the stakeholders discover their requirements, and one of the best ways to provide pictures is prototyping. Unlike static screen shots or wire frames, prototypes that allow our business stakeholders to “use” the end product help elicit not only their requirements, but also those hidden expectations. Even when the prototypes are low tech rough drafts drawn in PowerPoint or on easel pads, they are an effective elicitation technique.

I’m not sure much will change on future vacations. But that’s OK. Few hotel clerks are as crabby as the one above. We have generally found them to be friendly and flexible, like most of the business stakeholders we work with as well. We practitioners just need view change positively, knowing that it will happen, and with tools available to uncover as many expectations as we can. 

Posted by Elizabeth Larson on: September 28, 2014 05:29 PM | Permalink | Comments (10)

"Education is the ability to listen to almost anything without losing your temper."

- Robert Frost