Speaking as a developer who works for a government, option 2 is rarely possible.
Keep in mind that the "government" is a collection of departments, branches, sections, or whatever you call them. Those are run by managers, which are run by more managers, which all have their own agendas, budgets, and powers to protect. Now add in politicians at the top, who change pretty regularly and have very different goals from everyone else.
So, in the best case scenario, at the start of a project everyone agrees on what it needs to do, what needs to be replaced, and everything else. You have specs, and you know what the goals are. Great! Then an election happens. New party in power, and priorites change. Now it has to do something else.
Oh, then a manager retires and a new one comes in. Now it has to do something else.
A new law is passed, now it has to do something else.
Someone changed their mind, and now it has to do something else. ... on, and on, and on it goes. This happens *all the time*. And that's if the people actually know what they want, which in my experience often isn't true in itself (like the Air Force ERP that didn't know how many systems it was replacing).
In a case where there is clear goals and strong management, #2 works great. Often times things just change too much and the only sensible way to accomplish anything is to go with #1 and do the project in smaller, more manageable pieces.