Exactly, when selling a big software system like this to the government, the contractor will very deliberately ensure that it follows the requirements exactly (because requirements are never specific enough) so that the government will then have to go back to them for fixes and upgrades forever. If they see a poorly worded requirement that they can implement as-is knowing it will cause a problem, they celebrate because its a future revenue source.
The only way I can see to avoid this is for a government to have its own dedicated software developers who make these types of applications and maintain them. Preferably open-source so that other governments can use them as well. The incentives change and they'd probably save a ton of money.
If they don’t implement that poorly worded requirement, they are entering a world of pain of having to justify the deviation through 10 layers of project managers and qa, all from different organisations (either customer or other contractors). And at the end they’ll be the troublemakers who delayed the milestone
This is also true I don't doubt, but I've heard directly from contractors that they look for requirement holes so they can monetize them to the maximum extent possible.
Having a dedicated developer team who work directly for government whose sole job it is to make and maintain software like this for the long term, still seems like the most cost-effective and durable solution.
The only way I can see to avoid this is for a government to have its own dedicated software developers who make these types of applications and maintain them. Preferably open-source so that other governments can use them as well. The incentives change and they'd probably save a ton of money.