Project Management

Acceptance: A Tale of Requirements and Their Meaning

From the PMI Global Insights Blog
by , , , , , ,
Whether it’s in-person or virtual, PMI events give you the right skills to complete amazing projects. In this blog, whether it be our Virtual Experience Series, PMI Training (formerly Seminars World) and our inaugural PMI® Global Summit 2022, experienced event presenters past, present and future from the entire PMI event family share their knowledge on a wide range of issues important to project managers.

About this Blog


View Posts By:

Cameron McGaughy
Kimberly Whitby
Julie Ho
Heather McLarnon
Brantlee Underhill
Laura Schofield
Michelle Brown

Past Contributors:

Johanna Rusly
April Birchmeier
Nikki Evans
Dalibor Ninkovic
Dr. Deepa Bhide
Chris DiBella
Nic Jain
Karen Chovan
Jack Duggal
Catalin Dogaru
Priya Patra
Josh Parrott
Scott Lesnick-CSP
Antonio Nieto
Dimitrios Zaires
Ahmed Zouhair
Carmine Paragano
Te Wu
Scott Bain
Katie Mcconochie
Fabiola Maisonnier
Erik Agudelo
Paul Capello
Kiron Bondale
Jamie Champagne
Esra Tepeli
Renaldi Gondosubroto
Mel Ross
Kim Essendrup
Geetha Gopal
David Summers
Fabio Rigamonti
Archana Shetty
Geneviève Bouchard
Randall Englund
Kristy Tan Neckowicz
Moritz Sprenger
Mike Frenette
O. Chima Okereke
David Maynard
Nancie Celini
Sandra MacGillivray
Sharmila Das
Gina Abudi
Greg Githens
Sarah Mersereau
Lawrence Cooper
Donna Gregorio
Bruce Gay
Wael Ramadan
Fiona Lin
Erik Rueter
Joe Shi
Michel Thiry
Heather van Wyk
Barbara Trautlein
Steve Salisbury
Yves Cavarec
Drew Craig
Stephanie Jaeger
Diana Robertson
Zahid Khan
Benjamin C. Anyacho
Nadia Vincent
Carlos Javier Pampliega García
Norma Lynch
Emily Luijbregts
Michelle Stronach
Sydni Neptune
Louise Fournier
Quincy Wright
Nesrin Aykac
Laura Samsó
Lily Woi
Jill Almaguer
Marcos Arias
Karthik Ramamurthy
Yoram Solomon
Cheryl Lee
Kelly George
Dan Furlong
Kristin Jones
Jeannette Cabanis-Brewin
Carlene Szostak
Hilary Kinney
Annmarie Curley
David Davis

Recent Posts

Acceptance: A Tale of Requirements and Their Meaning

Upcoming Presentation: Is Your Team Connected and Productive? How Do You Know?

Presentation Recap: Show Me Your RAID Log!

Engaging PM from Cultural and Creative Industries

Show Me Your RAID Log!

Categories: PMI Training

By: Scott L. Bain

A developer was working for a large financial company. The company leaders had an idea for a new product that would allow their customers to participate in foreign stock exchanges without having to stay up all night to time their transactions.

There would be many things to develop. A website that allowed customers to enter buy, sell, limit, and margin orders throughout the day to be transacted later when the foreign markets were open. A database would store all these accumulated transactions. Marketing would have to come up with a plan to promote this new product. Also a component, running on the server, would trigger at midnight to access a web service and commit these transactions as a batch.

The developer in question was assigned to create that timed component. The requirements seemed rather simple: The component would run on the main server and watch the system clock.  At midnight it would activate, retrieve all the transactions that had been stored throughout the day, open a connection to the external service, commit the transactions in the order they were entered, receive a confirmation code from the service, and write a log entry into the company’s daily activity log that included that code.

They knew how to open that web service connection, what the correct logic was to “commit” a transaction, and how to access the company’s logging API. Of course, they knew was “midnight” was. They met with the database administrator to learn the exact nature of the SQL table that would hold the transactions and what key to use to retrieve them in order. All of this seemed relatively familiar and straightforward and so they gave a low estimate on time and effort needed to get the work done.

Indeed, they got the component finished well within that time frame and checked the code in. The website and marketing were still in development and so they moved on to other work.

A few weeks later, the rollout of this new service was scheduled for a Monday. The day arrived and the product launched. It was immediately popular; many transactions were entered all throughout the day and everyone was enthusiastic about the product. The developer went home at the end of the day confident that the component would trigger at midnight and process the orders.

In the wee hours of the morning, they received a text. Disaster occurred; everyone was being called into the office. None of the transactions had gone through and they were anticipating many unhappy customers, perhaps even some legal action taken against the company. The developer went into work feeling a sense of puzzled dread.

What had gone wrong?

The transaction batch did not commit on time. It was too late. An SEC rule stated that if not every transaction was committed then none of them could be as a matter of fairness, so the external service had rejected the entire batch. Massive financial implications were the result.

This developer was relating this story to me a couple of years later.  I knew this person because they had been a student in several of my courses and in them had studied design, analysis, and testing.

“I didn’t know there was a deadline, a window past which the transaction would fail,” they said.

“An unasked question; that’s often the problem,” I replied. 

“Sure,” they said, “but then I realized something.  Even if I had known what that window was, I had accepted the requirement that the batch commit had to happen at midnight.  At midnight.  Nothing can happen at midnight.  Midnight is an infinitely short period of time and computers are not infinitely fast, and neither are internet connections.  Once it is midnight, it is immediately after midnight, right?  So what did the requirement actually mean?  By midnight?  Then how long before midnight should or can I start?  Starting at midnight?  Then how long do I have?  Also, this SEC regulation about all-or-nothing was something I had no idea about.”

“It sounds like this was not your fault,” I said.

“I guess not,” they replied, “but I realize that now, today, the way I work would have prevented this.  Today I would be driving everything from tests and the tests themselves would force me to ask the questions I didn’t.  The acceptance tests would make me ask ‘how will I know if I’ve failed?’ because I would need to start with a failing test.  Also, I would have realized the SEC was a stakeholder to my work and I would have included someone who understood their perspective.  The unit tests would force me to think carefully about the design of the component itself so I could do things like test it without having to execute the test at midnight in my pajamas.”

“Separation of concerns,” I said.

They smiled.  “Exactly. I now know how to achieve that without overcomplicating my designs.  But the real crux here was the fact that I didn’t understand what the requirements really meant, because the communication and collaboration had failed.  I lost that job as a result.”

This is not uncommon, unfortunately.  Communication, especially between technical and non-technical people is extremely unreliable.  Even when everyone intends well, there are too many mismatches among perspectives and too many questions that are missed.

Acceptance Test-Driven Development (ATDD) seeks to address this problem in a fundamental and comprehensive way.  How can we achieve a complete, meaningful, shared view of the product that is being proposed?  How can we record the results of the collaboration in a way that can be validated against the actual work as it is completed?  How will we know when we’ve succeeded?  How will we know when we’ve failed?

ATDD is a framework for highly effective collaboration across all parts of an organization.  It produces tests, but is not a testing activity.  It is a way to ensure that a product’s requirements are fully understood, including everyone’s perspectives. 

It is not a difficult framework, but it is essential if you want to ensure that everyone is on the same page and that the work to be done will be in complete alignment with the business value that drives it. It is something that everyone needs to know how to do.


Join me at PMI Training 17-18 April for NEW! Acceptance Test-Driven Development: Improving Communication, Empowering Collaboration, and Creating a Shared Specification for New Products with Scott Bain ( 

Interested in learning more about trainings specifically developed by project management experts for project managers in a small group setting? Check out the PMI Training website for upcoming offerings. 

Posted by Scott Bain on: March 15, 2023 10:53 AM | Permalink

Comments (4)

Please login or join to subscribe to this item
Dear Scott
Very interesting the theme that brought to our reflection and for debate
Thank you for sharing and for your opinions.
Does the ATDD solve the lack of maturity in the profession (technical and human)?

Solve? No, but it increased that maturity level I would say. I think we need a lot of things in software development, including a more organized/defined way to train developers. Much like there are defined paths to become a doctor or a lawyer.

Dear Scott
Thank you for sharing your thoughts and experiences. It's really interesting to hear how Acceptance Test-Driven Development can help with collaboration and understanding requirements across an organization.

Dear Scott,
Thanks for sharing yours views. ATDD will definitely resolve the issue and we have to do a lot more work for software development.

Please Login/Register to leave a comment.


What's so great about a mom and pop store? Let me tell you something, if my mom and pop ran a store I wouldn't shop there.

- George Costanza