Programmers tend to know this without questioning it and often without being able to describe why: you can't reverse engineer requirements from code. This idea seems to be irresistibly seductive to non-developers though.

Requirements are, at their heart, declarative. Code is imperative. Well I suppose that depends and I'll come back to this topic later. A program is one possible solution to the requirement, one possible implementation. It is not the requirement.

Requirements declare "clean the car". Code says "Get a bucket. Get the car wash soap. Get rags. Get the hose. Turn on the hose. Fill the bucket." and so on. It could also have said "Drive to the car wash". Of course those instructions aren't necessary if the car isn't dirty (but you can't tell that from the instructions). They also could have meant "Wash the dog" or "Make lots of bubbles". If you didn't already have it in your head that the intent was to wash a car you'd probably be lost. Worse, you'd be lucky to figure out what it meant.

And what are the chances that there is a bug in the code? That bug would leave you with an error in your requirement. What if the instructions in the code are working around limitations in the programming language? What about the OS? The network? The database? What if....what if the program is working around errors in the data, which were introduced by some other application? What if it's a legacy version of the program itself?

You can use code as a clue though, as a guide. If you know what the goal probably was you can use the code as a way to try to disprove your hunch.

You can't reverse engineer requirements from code - you'll never hit the spirit or the meaning of the original requirements. You can certainly use the existing code to produce requirements for a system that re-implements the code itself (including workarounds, bugs and all), but you'll never produce the intent or core need that caused the application to be created in the first place. Not from looking at the code alone.

So, what about the earlier supposition? When you use non-imperative approaches to implement requirements what you end up with is a declarative (or functional) statement of...the requirements. They are stated in a more formal manner certainly, but they will be a statement of the requirements nonetheless.

This a core reason DSLs and XML configurations are often good solutions. SQL is successful because it allows you to say what you want, not how to get it from some internal, vendor specific, database API.