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.

Recipe: Spicy Eggplant (Brinjal) Curry


  • Small thin eggplants: 5 or 6, cut into 1.5cm rings
  • Oil: for deep frying, 2 tablespoons for sauteing
  •  Tomatoes: 3, chopped
  • Red chillies: 4
  • Ginger: small piece, finely chopped
  • Bay leaves: 2
  • Curry leaves: 2
  • Brown sugar: 2 tablespoons
  • Salt: 1 teaspoon
  • Coriander leaves: for garnishing


  1. Blend the tomatoes and the whole chillies into a smooth puree and set aside.
  2. Pour oil for deep frying into a pan over high heat.
  3. When the oil is hot, deep fry the eggplant pieces until they are tender enough to pierce with a knife point.
  4. Set the eggplant pieces aside to drain.
  5. Heat 2 tablespoons of oil in another pan over moderate heat.
  6.  Saute the ginger, bay leaves, and curry leaves for one or two minutes, or until fragrant.
  7. Add the tomato puree and cook for 5 or 10 minutes, or until thick and saucy.
  8. Add the sugar and salt and stir to dissolve completely.
  9. Fold in the eggplant pieces in the cooked puree.
  10. Garnish with coriander leaves and serve hot.

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.

PCLinuxOS 2007 Test release 1 available

To quote Texstar from the following announcement

PCLinuxOS 2007 Test release 1 is now available for download. Please note this is not the final release. PCLinuxOS 2007 final will be released at the end of the month.

Features include:

* Kernel
* KDE 3.5.6
* Mozilla Firefox
* Flash 9
* Mozilla Thunderbird
* Open Office 2.1.0
* Xorg 7.1
* Beryl, Compiz, Aixgl and Xgl for 3D graphics support
* Gcc 4.1.1 and updated glibc
* Updated bootsplash, icons, and more from the beautification project.
* Xdg Menu system
* Rebuild and update of our entire repository against new gcc and glibc
* Simplified Livecd boot options.

Get it from HERE

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