January 25, 2007 § 4 Comments
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.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.