Reverse engineering refers to looking at the solution to figure out how it works. Basically, you you’re your business analysis backward from the solution to understand the data, processes, and business rules. Reverse engineering is more common than you think. Have you ever looked into a Microsoft Excel formula to figure out where it’s coming up with the calculation? Congratulations; you’ve reverse engineered!
Usually, reverse engineering is used to examine software or software components to figure out how they’re processing business rules, where they’re sourcing data, and how they make decisions. Basically, you want to understand how the software is supporting the business.
The use of this elicitation technique is increasing across the field because of all the legacy systems (old computer systems) sitting around. These systems need to be updated or replaced. Applications built on the mainframe 30 years ago were never expected to last as long as they have, and technology has progressed so far that these systems have to be reverse engineered so people can figure out how they work.
Here are some more-specific situations in which reverse engineering can be helpful:
When you’re not sure what is happening within your code or need to understand how an old computer system calculates a certain field: Business users may ask about how the system supports the business process, or what business rules are being enforced, which means you have to go in and figure it out.
When the software documentation is out of date: In fact, you may not even have any documentation. Without up-to-date documentation on how the software works, you may have to go into a system and trace the code logic to find out why, say, the system performs a calculation a certain way.
When business users aren’t aware of the business rules being enforced: The business may have changed in the years since the rules were hard-coded into the application. You may have to walk business users through the system to find out what rules are being enforced and how they need to be changed.
When you’re interfacing systems and need to know the correctness of data in each system: This challenge is one you face when you create ongoing interfaces or one-time data migrations. For instance, in order to comply with e-mail regulations, you need to make sure opt-out preferences are always correct. If you do a migration, you need to go back and double-check that the old and new settings match.
Don’t hesitate to ask for help with reverse engineering. If you don’t understand where or how to look through software code, enlist a developer on the project team. He will have a good idea where to start looking for the rules, data, or enforced processes.