Requirements Churn

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.

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

Advertisements

§ 4 Responses to Requirements Churn

  • jogeshwar says:

    Dude, use extreme programming.

  • David Locke says:

    Actually, requirements churn is caused no by a subject domain changing, but by the politics in determining which parts of what domains are included and at what priority. Multiple stakeholder projects are always problematic. Single stakeholder projects still might be clouded by changing paradigms within the subject domain, but single stakeholder projects are ALWAYS more stable than multiple stakeholder projects.

    Change management practice says that you must have an executive sponsor. Why? Because that stakeholder is going to determine the amount of churn and the amount of work design the stakeholders need to get any value out of the application once it is developed. A single stakeholder project does not need an executive sponsor, will not change rapidly, and will not incur the need to develop desktop workarounds. A single stakeholder project should automate the tasks performed by the stakeholder, and do so completely.

  • Lee Riemenschneider says:

    So far, the comments are batting .000

    On extreme programming … one could use the tenets of extreme programming with xtUML. Just remember that the models are the code.

    On the politics of inclusion … if your xtUML domains can be parted out, then you’ve failed to properly abstract your subject matters.

  • Only 40-60% of the features will be known at the time of the first release to alpha test (equivalent to initial operational capability, of a 400 function point or larger system, because:
    1. In the time it takes to develop the system, about 15- 24 months, the business needs will change as the business and the competitors evolve.
    2. There is a 10-20% disagreement or misunderstanding with clients, business analysts, users and developers abut what the requirements really mean and what is really needed for the system to become economically viable.

    3. The IT environment is changes.

    For medium to large projects we try to “hit a bullet with a bullet.” This is why incremental development, prototypes, and getting to market early with limited fetures is so vital.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Requirements Churn at csrins.

meta

%d bloggers like this: