In most cases we are developing something that has been done before. We are either enhancing some software or simply rewriting the whole system for some inadequate points. Analysts gather user requests, organize them, make multiple discussions with customers/users and write user requirement documents. That is the standard procedure for most cases. However in some cases especially in re-implementing some systems, customers will request the exact same features of the  old system.

we were really satisfied with this screen/report/graphic we want the same things from the new system

Those cases may become really tricky situations. Customers do not want to spend time to explain what the old program is doing. He may even not know how this output is compiled. He was just interested if it was running and giving the correct results or not. This fact results with incomplete requirement documents. In other words there is only one requirement:

We want the developer build the same output at the same time with the same input. Black box requirements

Reverse Engineering comes into action. You should trace the old system, analyze it and try to understand the data flow in it. Lots of pit falls waiting you. And since you do not have the complete analysis&documentation, there will be neither an accurate project plan nor a well organized software code and documentation. You should feel lucky if you can really understand this black-box and replicate its features. Even after some successful tests there may be some cases that needs handling that you might not found out.

Requirements’ documentation is one of the most important requirement for development. Even in cases of reimplementation, a complete documentation is the key factor for cost effective and successful software cycle.

Related posts:

1. hibernate cache injection: missing…
2. Best Documentation: Prototyping
3. Moving from Tomcat to JBoss