The other day I was having a conversation with someone about requirements and software design. We had a description for a small system, and I was saying “this is the design; this is how we should implement it.” He had a different point of view, and was saying “These are requirements; we are free to create our own design.”

Design and requirements seem distinct, so how did we come to have different points of view about the same document? Requirements are what a system should do; the design is how it should do it. That seems clear. But perhaps the distinction is not always so clear in practice. On reviewing the text, I thought what we were looking at was best described as “business rules”. These are a description of the logic that’s in the end user’s head, and if we don’t implement their logic then sooner or later the system will start to drift from their expectations. They are requirements, in the sense that they express what should happen, but there is good reason for them to include logical design to explain how it should work, too.

In many of the best development situations there is a feedback loop between requirements and design. Requirements start the process; candidate designs are drawn up; the designs are found to have various positive and negative consequences (cost, security, ease of change, etc); alternative designs are suggested which would offer more positives if the requirements were slightly different; the requirements are adjusted; and so the loop continues until a happy medium is found.

Developing any non-trivial system is, in part, an exercise in managing uncertainty. And just as with managing uncertainty in general, it’s helpful to separate two things to make decisions and move forwards, and it’s helpful to recognise the proximity and interaction between the two when we’re seeking to solve problems creatively.

Photo by Sakuto