Non-function requirements: Upgradeability

It's been a while since I last posted on non-functional requirements so I'm going to ease my way in with a simple one, upgradeability. This characteristic defines the ease at which components of a system (e.g., software) can be replaced with newer pieces with minimal changes to the rest of the solution.

Let's use some examples to demonstrate this non-functional requirement. Suppose your system uses a service-oriented architecture approach (you can find lots of information on SOA at ebizq.) Your system handles purchase orders from a web site, calculates taxes and then sends out orders to your fulfillment group. If the tax rules change, you can build or purchase a replacement component to handle the tax calculations. Components are loosely-coupled in a service-oriented architecture, thus changes to one component are transparent to other components (as long as the service itself functions the same way.) In this case, the upgradeability of the system is high.
On the otherhand, suppose you purchased an accounting system and built a lot of direct interfaces (e.g., tightly-coupled) to different applications to provide information to it. Now, a newer version of the accounting program is released that uses XML to transfer data around. The custom interfaces and other custom work will have to be examined to see whether they will still be able to function. There is a high probability that you will need to rework or rebuild a significant amount of them. As such, you would say the upgradeability of the system is low.

In general, tightly-coupled systems and systems with high levels of customization are more difficult to upgrade.