Time to Impose a Requirements Tax On Your Project?

I’ve been reading and enjoying these beautiful O’Reilly books: Beautiful Architecture, Beautiful Code, and Beautiful Teams. I have yet to read these other titles from the collection: Beautiful Data, Beautiful Security, and Beautiful Testing.

Those books will have to wait because the O’Reilly book that I’m reading right now is Masterminds of Programming. I want to share something that Tom Love wrote on page 248:

I just handed out to some of my friends this week a big pile of buttons with the word REQUIREMENTS and a red slash through it like a European road sign. On the back of the button are 14 acceptable alternatives to that word. Lots of discussions go on between individuals or between groups of the form of “I couldn’t do this work because you didn’t give me the requirements yet,” or “We need to have a group of people that goes out and gathers the requirements for this new system.”

The term is simply too imprecise. You need to have more precise terms as an alternative. On a big project that I’ve been involved in we have imposed a requirements tax. If anybody uses the word “requirements” standalone, they have to add $2.00 to the entertainment fund. If they want to talk about use cases, or if they want to talk about story cards, or they want to talk about performance metrics, or they want to talk about business cases or business process models, those are all acceptable terms. They don’t incur a tax, because now if you say, “I need to have the use cases or the functional specification, or a mockup of the application that needs to be developed,” that’s a precise request.

Let it be known that I will no longer use the word “requirements” standalone. If you catch me, I’ll buy you a beer. Now if you use the word “requirements” standalone, I’m likely to just get angry. Dear reader, you have been warned.

Leave a comment

Your comment