Requirements Volatility and its impact on System Design:

System designing is a dynamic process where the demands for change are inevitable. All modifications made to user requirements result in modification of system design. There could be various sources for this change like users, technology, or business.

These changes are what makes the requirements volatile. In simpler words, requirements are likely to change over time. Requirement Volatility is considered to be a major source of risk to the development and management of software projects. This is the reason why you should never develop a system design on the basis of requirements.

If we perform a background check for requirement volatility, it is very much evident that the requirements do change. You must have encountered situations where you were delivered what you asked for only to find out that you asked for the wrong stuff. So, business requirements become understood throughout the journey of delivery and during their solution’s operational use. By all means get paid based upon the requirements that are met.

Let’s assume the customer state's a requirement for cooking in the kitchen and have an indoor meal and you start designing based on these requirements. But towards the end of the project the customer realizes that they want to have a barbeque in the garden when it is sunny. Now, the whole design you developed is obstructed. And the cooking functionality now has to be moved into an entirely different setting which is the garden in this case.

What’s even funnier is the whole object orientated approach to designing systems. It becomes object centric too early and becomes concrete too quickly.

In older systems, for gender representation of males and females check box system was used, if it was checked in it would imply male otherwise female. Well that was quite simple right? However, within some UK NHS systems there are 7 options for gender. So you see how it all depends upon requirements. There used to be a time when we had only one bank account but today we have a collection of accounts, yet requirements are stated firmly and explicitly always.

To avoid the impact of requirement volatility on our system designing we must look for the parts of the requirements that are stable. It means that the requirements which are constant and will always be the part of business need must be recognized for development of design.

In order to protect your project from the risks of time always consider the volatility of requirements while developing the system design.