Requirements Churn

Often software development begins with a concept, an idea, a mere verbalization of an intangible. This is followed by a concerted effort to nail down the requirements for the proposed system.

Requirements are seen as a formal necessity for flagging off the development effort.

Usually, a formal requirements statement is approved for conversion into design. In many instances, where the problem domain is novel or fast-paced, the software effort runs into hurdles due to either late-breaking or rapidly-changing requirements. Or the requirements might evolve blazingly fast due to timeline pressures.

This is requirements churn.

The causes for the high rate of change of requirements pose a serious problem to the maintainability of the development effort. It becomes increasingly difficult to ensure that the code base is in sync with the requirements and design models (the boundaries between these two often becoming blurred). This is greatly exacerbated by traditionally elaborative software development processes which posit many implicit implementation assumptions during the coding effort — assumptions which are neither documented in the design nor in the requirements. This is not due to a lack of trying on the developers’ part. In the world of vastly complex enterprise software development, sourcing changes back to the design and requirements models may sometimes entail a substantial investment of effort and resources.

Project documentation and maintenance is not child’s play.

With translational and model driven development, the compiled executable system is deemed an immutable. Changes are mandated to be sourced to the requirements and design models. This ensures that the rationale for design and implementation decisions is captured as information and knowledge, and helps avoid the anachronistic mis-step between requirements and implementation.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.

Hacking Models — The Dark Side

Humans have a penchance for abuse and misuse, perhaps more so than any other creature on this planet (when was the last time we saw tamarins misuse trees… okay I admit I don’t watch the Nature Channel that much!).  With every technology and tooling at our disposal, the urge to abuse it becomes much more greater.

Code hacking is an all too familiar syndrome plaguing the software development industry.  We muck around in a heap of code that doesn’t perform as required and apply source-level hot-wiring to meet immediate needs.  What’s obviously required here is a second inspection, stepping back to re-evaluate the underlying design.  What’s obviously the norm is coding in a tiny tweak (with the Twilight Zone theme playing in the background), recompiling, and observing behavior.  If the system doesn’t blow up in our faces, that’s one more plus for this obviously unhealthy kamikaze behavior.  That’s a lot of “obvious” statements!

Flash-forward to the future.  We are now dealing with a higher level of abstraction when working with model compilers.  With great power comes great responsiblity and blah blah blah.  If Bjarne Stroustroup referred to C++ as dangerously powerful, MDD is obviously one of those glowing devices with hideously devastating potential.

Devastating — if misused, that is.

 Wow!  Modeling is great.   If I just drag this class here, and this relationship there, and this domain there…and compile and execute…hmm… this behavior is not what I had in mind… so let’s try it again.


This is not “Magpie Motel” (that was fun, let’s do it again)!  Advances in modeling tooling can never replace the drudge work that is Analysis.  Incomplete and inadequate attention to the non-modeling tasks will always result in poorly understood requirements, and hence nightmarish models.

Remember.  With great power comes…  and yes, we don’t need to be bit by an arachnid to realize that in MDD!

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.


Executable UML is designed to produce a comprehensive and understandable model of a solution independent of the organization of the software implementation. It is a highly abstract thinking tool that aids in the formalization of knowledge, and is also a way of describing the concepts that make up abstract solutions to software development problems.

The goal of software and systems design is utilize maximal reuse of artifacts and minimize rework and redundancy. xUML takes this layer of abstraction to the next higher layer, and with the tooling necessary to compile and debug a model now becoming available, it has emerged a highly viable development paradigm.

Some Resources to Get Started

  • Executable UML — A Foundation for Model-Driven Architecture : Stephen J Mellor, Marc J Balcer
  • MDA Distilled : Stephen J Mellor et al
  • Model Driven Architecture with Executable UML : Chris Raistrick et al
  • The Object Constraint Language — Getting Your Models Ready for MDA : Jos Warmer, Annekke Kleppe
  • Kennedy Carter iUMLite at

Creative Commons License

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License