User Tools

Site Tools


The Requirements-Logic Gap

Software development is a transformation process. It processes requirements provided by the customer as input. Its output are releases to be used by the customer. A stream of requirements is transformed into a stream of releases:

Or to be more precise: The output requested by the customer is just logic. Because logic is the part of a release which creates software behaviour. Logic delivers on the primary requirement categories of functionality and efficiency.

Unfortunately is hard to come up with the logic to fulfil the customer's wishes. From customer to release is a long way with several lossy transformation steps:

  • The customer does not really know what's needed to solve a problem.
  • Whatever the customer knows/wants he/she cannot fully explain.
  • Whatever the customer explained is not fully understood by the software developer.
  • Whatever the developer understood is not fully implemented.
  • Whatever gets implemented and released does not match fully what the customer wants at that point in time.

Agile approaches try to mitigate this kind of lossy transformation by shortening the feedback loop, i.e. by reducing the time from the initial steps until release.

That sure is a good idea - but a question remains: how is the transformation accomplished? Improving on such a demanding task works best when it's not viewed as a monolith.

Flow-Designs defines at least three processing steps to bridge the gap between what the customer wants (requirements) and what is delivered (logic):

  • Analysis creates tangible understanding. Problems are not solved yet, but understood.
  • Design creates models for solutions. Problems are not implemented yet, but solved.
  • Implementation finally creates code from models. The solution gets manifested, feedback can be generated.

The primary concern of all steps is to make production of logic possible and easy. Only running logic is tangible for the customer.

However, productivity and predictability of the transformation process over time are also of concern to the customer. Therefore each step has to take care of sustainability as the third requirements category, too. Code thus will not just consist of logic. It also needs to be structured in a way to enable easy progress in the future.

Helpful differentiation

Flow-Design states that software development always runs through these phases, whether software developer realise it or not. At latest analysis and design are done when sitting at the keyboard. Then coding is interrupted every so often by improving one's understanding and finding a solution approach or model for the solution.

Untangling those phases and making explicit in a process gives a handle on them. With a differentiation of the phases one can ask where to focus improvement efforts. Agility for example focuses on the process as a whole and analysis. Clean Code on the other hand focuses on implementation. And Flow-Design tries to integrate different views and see the process as a whole.

Iterative development

Even though the process is depicted as one pipeline of steps that's not to mean it will be run one once. Right to the contrary! A stream of requirements leads to a stream of intermediate results and finally a stream of releases. All phases are repeatedly (if not constantly) active in some way. And whatever feedback is generated for a release is fed into the process as additional requirements.

Bridging the requirements-logic gap is an ongoing, iterative, and incremental transformation process.

requirementslogicgap.txt · Last modified: 2018/06/04 16:41 by fdadmin