I had pondered writing a post called "Requirements Decay" about how requirements don't last forever. In my research I found that such a post, complete with "my" words "requirements decay" and "requirements half-life", had already been done comprehensively here. In a compact argument underpinned by half-life mathematics, the anonymous author proposes that a requirement isn't likely to stand forever and explores the implications.
For me, requirements decay is an idea that helps us think realistically about project planning and improves our chances of meeting business needs.
I've observed requirements decay in many settings, so I was surprised to find so few references that take this perspective. There are many, on the other hand, that talk about requirements volatility. Some, like this one, follow the traditional failed pattern of demanding business sign-off, "disallowing" changes after a certain point in the project, and applying a robust (and often dreaded) change control process for incorporating requirements changes.