Reverse Engineering it Is Impossible to Create

Reverse Engineering

It is impossible to create requirements and test artifacts by reverse engineering with complete accuracy as explained in this paper. Still, it's a valuable aide for gaining knowledge of existing systems, even though understanding the system as actually built and uncovering known usage modes are difficult.

Reconstructing the design of existing software is especially important for complex legacy systems, but can be a challenge because documents are often not available, dispersed and focused on isolated algorithms and data structures. This makes the formation of a higher-level structural models a time consuming, piece-meal activity. Reverse engineering has been touted as the solution to these issues, but the reality is that it can only automate some design recovery:

'Design recovery recreates design abstractions from a combination of code, existing design documentation (if available), personal experience, and general knowledge about problem and application domains . . . Design recovery must reproduce all of the information required for a person to fully understand what a program does, how it does it, why it does it, and so forth. Thus, it deals with a far wider range of information than found in conventional software engineering representations or code." (Biggerstaff, 1989).

For a large software system, the reconstruction of the structural aspects of its architecture through reverse engineering is also is beneficial. Software structure is the collection of artifacts that include software components such as procedures, modules, and interfaces; dependencies among components such as client-supplier, inheritance, and control-flow; and attributes such as component type, interface size, and interconnection strength (Muller, Wong and Tilley). But, for this information to be useful, it is necessary to know what motivated the requirements of the existing system to determine what needs to be retained from the existing system to meet new requirements (Rayson, Garside and Sawyer). Therefore, in addition to reverse engineering, the requirements engineer must use whatever information resources are available to construct conceptual models of the pre-change organization and its business processes and from these derive the requirements of the legacy software. This typically entails an iterative process of inferring stakeholders, roles, tasks and business objects and verifying these against the structure and behavior of legacy ftware.