The principle of changeability defines the possibility to change the functionality of software components with as little as possible impact on other components and without having to change the architectural structure of the solution.
Software will change over time, and the anticipation of change drives many aspects of software construction; changes in the environments in which software operates also affect software in diverse ways.
Change cases describe how the system might change in the future, and can be functional or nonfunctional. Examples of change cases to take into account are modified business processes, new technologies, integration with other systems, volumes of users.
Some practical aspects to assess changes against cases are potential benefits of the change, probablility of the change case becoming real, relative priorities.
If you address changeability in the software system being developed, you will need additional efforts to provide an extra degree of flexibility, extensibility, and scalability to support future change. The cost of the extra effort to construct more changeable software, or already anticipating future changes in the solution, must be weighed against the priorities, and the future cost the change to the software.
Applying principles for construction such as Abstraction, Encapsulation, Isolation, Layering and others will deliver software that is generally more robust to change.