When would Reverse Engineering as an elicitation method work well?

with 1 Comment

The BABOK® Guide 2.0 is known as the process and methodology independent reference used to define business analysis tasks there are required to be executed in order to deliver solutions that add real value to an enterprise.

There has recently been a lot of debate over BABOK’s decision to remove reverse engineering as a requirements elicitation technique , whilst it’s been said it isn’t because reverse engineering isn’t a viable approach to uncovering requirements it’s more so that it isn’t as widely use amongst business analysts today.

I have to agree with their decision to remove reverse engineering, and this is why.

Reverse engineering could come in handy is when the system being reverse engineered belongs to the organisation that the requirements are being elicited for. Commercially available third party production systems that add business value are usually obfuscated, here’s an example of what that means http://www.ssware.com/articles/protect-and-obfuscate-your-dotnet-code-against-reverse-engineering-using-crypto-obfuscator.htm and if you could get passed the weirdness of the code, I’m pretty sure it’s not legal to crack open someone else’s IP.

There is open source of course, but open source projects usually fall into the category of software tools and operating systems to name but a few, they don’t really add business value, but rather support its operations. Like a Linux server running an Apache hosting environment. My question is, who would want to elicit requirements from that and why? To build a web server or an operating system.

So reverse engineering as a requirements elicitation process is limited to scenarios for existing in house applications or where the organisation owns the source code to the application being reverse engineered. Even then, what if the system being reverse engineered to elicit requirements from is an old client server network application that utilises multiple open datasets (has access to local machine’s memory) and the new application will be web based, which is a state less environment. The multiple open datasets would have to live on the web server’s memory in sessions, which will severely impact the hosting environment’s performance.

Unless the elicitation process is only used to identify the features that the new solution should have, but would it not then be faster just to use the other requirements elicitation techniques available?

Based on the above I have to say that I support BABOK’s decision to remove reverse engineering as an elicitation technique.

One Response

  1. Malcolm

    Thanks for this post, who wrote it if i may ask? Thanks

Leave a Reply