Why is any analysis of requirements destructive?

Voiced by Amazon Polly

To analyze is to break apart, reorganize, describe in a different way, so that you can have a different look, to take a different perspective, and we do it to draw some new conclusions, to see and say something you did not before.

Regardless of how exactly you do requirements analysis, that analysis is going to be destructive. Why is this the case? Isn’t the aim to do constructive analysis?

If I ask you to analyze requirements, I would want the outcome to be constructive, to move me closer to the goal of specifying the “right” requirements for the system-to-be.

Your analysis will always have one of three outcomes:

  • You found something that supports the claims I made thus far. Let’s call this a positive outcome.
  • You found something which undermines or contradicts my claims. This will be called the negative outcome.
  • No outcome at all, meaning you found nothing that either supports or counters what I did. It was a useless analysis, in other words.

Both the positive and negative outcomes are constructive for a simple reason: they both give me new information relative to what I previously had – for if I had all the information already, then you would necessarily get the third and useless outcome.

But they are also destructive. They destroy the information which was there before the analysis. Specifically, they replace the information you had before, with something new, even if the differences are minimal. If there are no differences, then you got that third outcome above: a useless analysis.

In other words, any constructive analysis of requirements, one which moves you forward, is also going to destroy what you and others thought was right. There are no perfect requirements; any useful analysis will destroy that conception.

Another way to put it is that if it was not destructive, then the analysis was useless.