Instead of trying to understand all the requirements for a system as a whole, I prefer to try and understand _what the system currently does_ and _how I want to change that behaviour_. Changing behaviour could mean fixing bugs or adding new features. This applies equally at all levels of abstraction (eg. the entire business system, or a single interface/class).

So far, we are getting confusion over why we are doing the rewrite, but once we explain, the client is very willing to work with us to collect the requirements.

Often it is because the stakeholders themselves do not know what they don’t know and don’t always know what they want. And sometimes they get what they want but it’s not what they need, etc. etc.

No silver bullets here.

By the way, the most difficult part of rewrite is to collect back the requirement, how do you overcome that?

What I usually see in practice though is that the requirements are *not* 100% and the legacy code contains various little bits of logic to handle accumulated undocumented reqs. Or it contains “features” that other logic depends on without necessarily realizing it.

When you have that rat nest of issues a rewrite usually ends up working until it gets to the end user or someone notices the new code does not handle case xyz properly or like the “old code did.”

If you have the time (who does?) you can begin covering the legacy code in behavior tests to discover just what it is doing. You can then apply those tests to your new code and ensure both sides pass.

Code coverage tools are essential to make sure you cover the old stuff sufficiently. Of course, by the time you get to this point, the pendulum swings back to just refactoring (since you now have an extremely high test coverage!)

No good answer yet. I usually lean towards rewrite because if it breaks a “feature” that isn’t spec’d out… it usually points to a bigger problem anyway.