Why requirements in software development harm collaboration, stunt innovation, and threaten the quality of our products.

“Software development has been steered wrong by the word ‘requirement,’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”

 

I wish I could take credit for first publishing a quote like this. But it was Kent Beck who actually did in his 2nd edition of Extreme Programming Explained.

Let me see if I can explain why the word “requirement” is just plain wrong.

When faced with challenges or in pursuit of a goal we decide on a course of action

I suspect you’re reading this because you’re somehow involved with software development, and Agile development in particular. In software development, we build tools for other people to use. When done well, the software we eventually release will be used by people to overcome a challenge or reach a goal. If the software doesn’t do that, it was unsuccessful.

For businesses, challenges or goals often boil down to increasing profitability. Sometimes that takes the form of building more appealing products to sell, or supporting a necessary process to make it more efficient thus reducing costs.

There’s lots of ways to make money, and lots of ways to reduce cost. So, exactly how we do either takes a bit of thought, deliberation, and finally some decision on a course of action.

The software we eventually build is the compounding of a great number of decisions

If the motivation for building software originated as some business objective, the person with that objective made a decision that placed software somewhere in the solution.

Assume for instance I’d like to build a new consumer product. I’m doing this because I’ve identified a need in the market – a group of users with an unmet goal, or a goal I believe I can meet better. I’m not in this purely for fun, so I need to make money selling software to meet their goal.

The product to build and user constituencies to serve were decisions I made.

I then need to make some decisions about what the product should do. I might look at the products of competitors to see what they do. I might look closely at my target audience to understand what their problems are. I want to understand how my software will solve their problems, and very importantly, how many features it needs to have to convince them it will solve their problems – otherwise they won’t buy it. (I tried to get at the idea of features that support buying decisions vs. features that support use in designing software for two-headed people.)

Once I’ve decided on the functionality I need to have, I need to make some decisions about how people might use the software. For the software to support my user’s work well, I need to understand that work, and make decisions on how to organize screens and stuff in screens to best support that work.

My users are a picky lot. They expect the software to be esthetically pleasing, so I’ll make decisions about how the software looks and behaves keeping my customer’s esthetics in mind.

I can’t please everyone, so I’ll have to make some tough decisions. I might have chosen the wrong work to support – and consequently the wrong features. I might have misjudged my customer’s esthetic sense and made choices that make the product not so desirable.

When I eventually sit down to write code, I’ve got to make lots of decisions about programming languages, databases, client type – browser based or rich, etc..

I still need to make lots of fine grain decisions about fonts on screens, text in error messages, and layout for stuff that prints.

I’m getting nervous. I’ve made so many decisions that depend on each other here. Most of these decisions were made on the back of previous decisions. How can I know if they were good decisions?

I don’t intend to develop this software myself, so I’ve hired a development team. The development team asks me for my “requirements.” I assume they’re asking me for marching instructions – for me to tell them what to build. They must be referring to all the decisions I’ve made up till now – and I’ve made a lot of them.

“Requirement” is a label we put on our decisions

These were decisions made by fallible humans. The may not be correct.

The reason requirements in software development are hard is because they are decisions. The reason that so often they need to be run by everyone is because everyone wants in on the decision. The reason they’re so hard to validate is because given the same facts, different people make different decisions – let alone given different facts. The reason requirements change is because decisions change. They change when we learn new facts that lead us to believe we could have made a better decision.

Decisions and requirements build on each other

In my story above, my choice of user constituencies was based on the product I believed I could create and the need I believed I could fill. The functionality was based on what I believe those people need. The technical decisions on programming language, browser based or not, database, stuff like that were made based on who I believed my users were, how I believed they’d use it, and the technology choices I understood I had at the time.

In the requirements world functional requirements are based on business requirements, technical requirements on functional requirements.

Whether we’re talking requirements or decisions you can see that if I’ve got a bad one upstream, the one’s based on it will be bad as well.

Giving requirements stops collaboration

Let’s look at the word requirement, and the word decision. I’ll throw them out along with a brainstorming of a number of words that I’d place in the same category.

requirement	decision
mandate	solution
order	problem
necessary	goal
indispensable	creation
non-negotiable	hope
indisputable	idea
contractual	discussed
final	reversible
blame	made by people
irreversible	attribute-able
absolute	explainable
consider as fact	fallible
change is consider to be process failure	change is natural over time

I guess it’s not surprising that the lists vary. Aside from the obvious reason: that I made the lists and I’ve obviously got an axe to grind, “requirement” and “decision” aren’t synonyms. Both words characterize a piece of information. “Decision” describes an idea arrived at by a person or group usually after some consideration of multiple options, where “requirement” describes a contractual arrangement between one person or group and another.

Requirement is the word I label my decision with when I want to request you do something. By placing the word requirement on it, I let you know that the decision’s been made, and you needn’t concern yourself with it, other than to meet my requirement. Any conversation we have will be about the details of my decision. We’re not working together to make it – it’s been made. It’s a requirement.

But, calling it a requirement gives me an uneasy feeling. These were tough decisions to make, and although I feel mostly confident in them, they could be wrong. By labeling them requirements, I now feel they must be right.

Asking for requirements avoids responsibility

Said by Fred Brooks in his 1987 essay “No Silver Bullet.” Notice Fred didn’t say the hardest part was the requirements, but the deciding. He does however say this in a discussion about requirements where he later goes on to say “Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy.”

Since it’s difficult to decide what to build, and since decisions are based on decisions, it’s often likely that in a pile of decisions there’s a few that are just bad decisions. Figuring out which are bad is difficult. By difficult, I mean darn near impossible.

Asking for those decisions as requirements avoids the difficulty of figuring out which are wrong by placing all the responsibility on to the person what made them. By calling them “requirements” we ask this person to take full responsibility for their decisions. We’re not collaborators. We’re not here to help.

Taking responsibility for one’s decisions is usually a good thing. However requirements documents have an aptitude for anonymizing decisions – for obfuscating the person or people who made them, and the motivations for those decisions. Sadly, the net result is no one taking responsibility. And often no one to even ask exactly who decided this was a requirement and why.

Even sadder is when the wrong product is built as a result of failing to understand why specific decisions were made.

Adopting a process that uses “requirements” adopts the assumption we could identify correct requirements, and the resulting risks taken on with that assumption. “Requirements” are risky things.

Requirements come from outside, not inside

Now, at times, there is a place for requirements. Healthcare, banking, and a variety of other industries all have regulatory requirements. Not meeting these can result in bad consequences for our product.

But, these requirements are decisions just the same. Just like other decisions sometimes they’re bad. Sometimes they’re reversed. Sometimes they change.

It may not help much to know the basis for these decisions made by others resulting in requirements for you, since you can’t likely changes them if they’re bad decisions. (Or can you?)

These sorts of requirements come from the outside. These are decisions that aren’t easily questioned, explained, or sometimes even understood. They may be a necessary constraint coming into our organization from the outside.

There’s no reason to stand for the same level of inflexibility or lack of collaboration inside our organization.

Stop using that word and start collaborating to solve problems

At the end of the day, it’s not the word “requirement” that does damage to software development, it’s the ideas and process that often come with it.

My concern is the lack of collaboration that often goes into decisions. Or some using the concept to avoid really understanding the people who will use their software and the problems their software solves. Or, evaluating the product you choose to build on the basis of requirements being met, and not on the bases of user or business objectives being met or problems being solved. In the end, everyone in the organization pays.

I often host collaborative requirements worksessions. (Yes I do use the word.) I’ll often start a worksession by writing on a whiteboard “requirement = decision.” I’ll start by saying “We’re here to understand our goals, and together make the best decisions on how to reach them.”

I’ve seen environments where “requirements” were used in a process-healthy way, where requirements were considered more as decisions, and participants were aware of the details that went into those decisions. But these environments are the exception rather than the rule.

The decisions we make about our software should never reach the state of “mandate.” They should never be unquestionable. They should never stop being measured against their ability to effectively solve business problems. They should always be recognized as fallible.

If I had my way, we’d stop using that word. The baggage is too much for me.

But I don’t know what word I’d replace it with. Perhaps user story? But, that uses one of the other unfortunate words in software, “user.” And what about all the decisions I make that aren’t so closely related to the person using the software?

I’m using the word “decisions” or the phrase “design decisions.” Try out another word around your company and tell me what works for you.

What now?

Thanks for reading this blog/essay/rant! I’d love to hear from you, so please rate this entry, and consider leaving a comment. Or, send email to me directly.

If this blog entry was interesting, please take a look at all blog entries

If you find my brand of thinking valuable, please consider visiting me at a conference, or public class. Or feel free to contact me directly for agile coaching and training.