Hi Kumar,

First of all reverse engineering is the activity of analysis a systems' structure, function, and operation in order to understand what it does and how it does it. What the reverse engineering process cannot fully accomplish is clearly identify the "why" aka the requirements. For example, the fact that the background color of the screens is yellow is that a requirement or that was the color the developer picked?

You first need to understand why you are doing the reverse engineering. Why does the business need to have documented functional specification documents and/or requirements?

If the reason is to be able to perform impact analysis as a result of future change requests, then documenting just the system's behavior/functional specs (aka. what the system does and how it does it) would suffice.

However, if the goal is to build a brand new system which needs to meet the same requirements as the old system then how the system does things is not as important. What is important is to identify the requirements. In this case, the business analyst would look at the functionality of the system (what features), at the business rules (constraints enforced by the system), and the look and feel (usability of the system) and document those as assumed requirements.

The requirements document would then have to be reviewed by the stakeholders and look for missing requirements which should be added, incorrect requirements which should be fixed, and non-requirements which should be removed from the document. The updated document becomes the basis for the new system.

Hope this helps!
- Adrian