Back to the Future: Reverse Engineering Requirements

Many organizations today have systems that have no or very little documentation. Users and customers have relied on these legacy systems to provide a reliable means to work on vital information. And as the business changes, more of these systems are being asked to be leveraged in ways that were not designed when first implemented. Reverse engineering requirements can dramatically improve an organization's ability to maintain, upgrade, and integrate to its legacy production systems. But the time and cost to do a total system documentation tend to balance the potential benefits. Instead, an incremental reverse engineering approach has the advantages of a quicker return on investment, reduced risk, and more flexibility. Hence, you need to go back to document these systems to move current organizations into the future.

There are two basic approaches to reverse engineering requirements:

Total System Documentation

To fully document the entire system (data files, back-end processes, user interfaces, new platform, etc.) and then validate the requirements can be very expensive and time consuming. And the problem space gets even larger for decentralized systems. But this approach becomes necessary when "the code quality of the original system is so poor that it can't be reused or leveraged", as stated in Blueprint's Application Modernization webinar. Hence, the entire system needs to be documented so that it can be redeveloped. Although an expensive option, redevelopment has the advantage of using modern tools, platforms, languages, and methods. If you need to go down this path, then be aware of a pitfall. Managing requirements of both the existing legacy system and its continual changes is extremely difficult and feasible only if the system is small. Some functional changes cannot wait until the old system has been documented. Thus, modifications to the legacy system must be continually updated in the documentation. This requires significantly more resources (time, money, and personnel). If the legacy system is too large or too dynamic, the organization may not be able to afford the expense of parallel requirements definition.

Incremental Reverse Engineering Requirements

A key decision when planning incremental reverse engineering requirements is how to decompose the legacy system to its components. Most likely, the decomposition decisions will be based on a mixture of the below strategies. There are different ways to decompose a legacy system:

Physical Site
If you have decentralized systems, then this approach works well. For example, all systems at a given site will be documented first. Or documenting a re-hosted system will occur before any other requirements definition activity.

Functional or Business Need
Reverse engineer requirements of software components that are mission-critical to the organization. Once you have those critical components documented, and then identify all the components that contribute to it. And work your way out via a spider web from sub-components to sub-components as time and resources become available.

Interconnectivity
Obviously, stand-alone systems are easier to reverse engineer requirements than systems that are tightly interconnected. A pitfall to this approach is the lure to document noncritical systems and components. If a system is critical and stand-alone, then starting documentation here is a good idea.

Data and Business Rules
An organization's data and how it's manipulated is very important. Reverse engineering data requirements and business rules can help identify redundant data usage. For example, you may discover different business rules are manipulating the same piece of data in different ways.

Finally, reverse engineering requirements wouldn't be complete without a central repository, which will allow you to define, simulate and validate requirements for all your systems. If you need to do total system documentation, then a repository will help you gather the requirements of the system, but also help you maintain any parallel changes to the system that you are documenting. If you choose to do incremental definition, then a repository will help you store and manage the ever evolving requirements to your systems.