Some background: part of what the software that I'm working with does is data collection, and we had a bug that showed up during a manufacturing test that I eventually traced back to the working of a feature that had been specifically requested. It turned out that with extremely long scan times, the system would lock up when something went wrong that would trigger this particular feature.
The issue appeared because nobody had ever really considered the ramifications of long scan times in the operation of this feature, and while it could be argued that it was something that should have been thought of in the requirements phase, the fact is that it wasn't, and extrapolating that into the larger picture, it hit me:
Given a system of sufficient complexity, it is impossible to fully define all of the software requirements.
While philosophically this is a nifty thing, the practical implication is that there needs to be some sort of mechanism in the software process to catch exceptions later in the process. This also has broader implications for things like scheduling accuracy, as a requirement exception should be treated as a new requirement for the purposes of planning.