Why requirements are hard

About 3 minutes to read. Posted on March 3, 2021 10:03

Software projects are notorious for how hard it is to define what the software is supposed to do. If you're reading this, you have probably expierenced this yourself. There are the usual suspects that are hard to get right: Communicating with the right people, navigating internal politics and lack of experience for some of the involved parties are things that come to mind right away.

Today I would like to suggest a more subtle reason why surprises keep popping up, even though you did your best to document every process, every field and every step of whatever scenario you are trying to bring to your application.

Can you drive a car? If you can, I assume you're decent at it. Otherwise you wouldn't be allowed to drive on public roads. Now that we've settled that, I will consult you for the new car I'm builing for you. What are the main requirements that the car needs to fullfill?

Here are a few things you might tell me:

1. Pressing the gas peddle needs to make the car go forward
2. Turning the steering wheel needs to make the car turn left or right respectively
3. There needs to be a reverse gear, to drive in the opposite direction

Now let's think about how we would go about implementing these features. Do you know — in detail — how these things work? Can you explain to someone exactly how these things need to be built? Of course not, since you're not a car mechanic or engineer (If you are, then this example doesn't apply to you).

You would assume the person building your car already knows how cars should work and is just asking for your preferences. That's where the complexity comes in when we apply this analogy to software development.

Key insights

• Your customers will assume they are just giving prefences and not exact definitions
• Even if you ask your customers for exact definitions they most likely are unable to document them in enough detail needed to write code

There is an even subtler scenario that can be missed when trying to define the requirements for software. Everyone has a mental model about how things work. It's when reality and the mental model conflict, that the worst kind of feature creep happens.

One example taken directly from real life: One of my customers wanted to build an import for his products into their new website. The source application has all the fields needed to build the import. We also created a map between the different data models, so all questions could be answered before implementation.

The first time our customer started importing data we got the feedback something was wrong. Categories were not being applied. A quick test seemed to suggest everything was fine. Applying a category in the source application also put it in the corresponding category on the website. After some more discussions it turns out that categorisation is not only done the traditional way — by selecting categories from a tree — but also by checking a combination of other attributes on the product. In fact most of the relevant catregories were defined this way.

In the end this previously unknown behavior turned out to be the most common way to configure products. In total this unknown caused us to take twice as long for this part of the project.

The customer assumed that having access to the source application would be sufficient to cover this requirement, because that's how it worked for all other applications they had previously used. They had no idea that each consumer software had to implement this logic separately and probably causing lots of surprises.

Key insights

• Requirements can exist that nobody is aware of
• Things that look straight forward can turn out to be hard in detail
• The most dangerous scenario is when a client thinks they know how things work, but in fact they are only assuming how things work

These are hard problems to solve and also a big part of the motivation to start using Agile methodology. Since Agile is a can of worms, I will give you a summary in my own words.

There are two primary ways you can mitigate the risk of something like in the above examples happening to you:

First, find hard evidence of how things work. In companies that are already very digital, this can be the source code of the previous software. Alternatives are well documented processes (hard to find in small to medium businesses) or, in simpler cases, a contexual inquiry.

Second, you can do a deep dive into the functionality before developing the rest. For example you can manually recreate a few datapoints for the customer to confirm and sign off, before more code is written.

Both approaches have upsides and downsides. One downside that both share is, that they take additional time and money. If this is not acceptable in your project, be sure that your customer is willing to cover the risk. I don't recommend you cover it yourself.

Key insights

•  Find hard evidence of how things work
•  Do a deep dive into the functionality before developing the rest
• In any case, don't ignore the risk

Thank you for reading

I hope you enjoyed the article and maybe even learned something. If you would like to stay in contact I have a mailing list or you can reach out to me via social media.