One of the first major hurdles to rewriting legacy applications is requirements gathering: New requirements should be accurately written and detailed. They may introduce deliberate changes, but shouldn’t overlook the intricacies of how the current system operates. This is especially difficult when rewriting legacy applications that are a decade or more old and created by multiple development teams. As software consultancy, we run into this a lot, especially with AS/400 COBOL systems or Delphi rewrites. Constantly evolving regulations and business needs can leave behind overly complex or unused elements, making it difficult to fully comprehend the application.
Requirements roadblocks for rewriting legacy applications
Before a modernization project gets funded, there’s usually a high-level backlog that provides a cursory understanding of the work that needs to be done, which is vetted just enough to determine an estimated total cost. The next step in the process is turning those high-level backlog items into detailed requirements for the new project.
For a legacy application rewrite project, stakeholders often want to use the same requirements gathering methodology that they would use to enhance the current system. Usually, this begins with an idea from a business unit about a new feature or functionality to add. For example, the business may need to update the application to comply with new regulations. This mandate is turned into a technical requirement to update the system, which is then handed off to the development team.
Once the development team picks up this feature, things often turn out to not be so straightforward. The proposed change might be in contradiction to existing business rules: then the requirement must evolve to include existing ones that business stakeholders may have added years ago and not considered since.
Ultimately, contention and confusion around new requirements comes down to three competing questions:
- What does the business think the software is doing?
- What is the software actually currently doing?
- What changes or enhancements do we want to make regarding how it behaves?
There are two primary methods of requirements gathering for rewriting legacy applications, each with their own benefits and drawbacks—and each preferred by different stakeholders. However, we’ll show you how to arrive at an approach that combines perspectives and successfully resolves all three questions.
Method 1 – “Extract” requirements from the legacy code
This is often the preferred or default approach for the IT organization, wherein developers define the detailed requirements for the application. Either the developer pulls the legacy code up on one screen and rewrites it on another, or they write out what the code does in English, to be reviewed by others and turned back into code.
- Ensures the system’s behavior does not change. If it’s doing exactly what it did before, nothing has broken.
- Unearths hidden bugs. For example, two similar business processes that should work the same might actually work differently in particular circumstances—which forces a resolution.
- Often brings forward needlessly complex or undesired logic.
- Can be very tedious, as basically every line of code needs to be reviewed and analyzed.
- Developers generally have difficulty attempting to convey complex program logic into plain English, especially quickly.
Method 2 – Write new requirements from scratch
Among business stakeholders, the preferred requirements gathering approach for rewriting legacy applications is usually to just “start over” and write a clean set of requirements based on what they think the system needs to do. This usually isn’t truly starting from scratch: user guides, prior meeting notes, and other documentation usually serve as a starting point. One of the biggest hurdles here is that documentation is not always kept up to date, and new requirements can overlook nuanced details.
- Ensures that unused, existing functionality is not built, improving efficiency and reducing costs.
- Naturally lends itself to simpler solutions. The current system has been built over decades and requirements have often grown over time.
- Makes it easy to forget functionality—sometimes even entire systems (such as special tools used for end-of-year reporting).
- Danger of oversimplifying and missing nuanced requirements, especially in heavily regulated industries like healthcare and finance.
Combined Approach – Guess and check
Ideally, we want the efficiency and simplicity of Method 2, but the accuracy and reliability of Method 1. To accomplish this, we have engagement leads work with business stakeholders to define new system requirements and cross-check them against artifacts such as current user guides. Once that is completed, the work is handed off to a technical lead who reviews the new behavior against the current system. The benefits of this approach are that:
- Less code is ultimately written, as the business side ensures only essential behavior is brought forward. This leads to lower total development cost and a shorter schedule.
- The existing compliance and functionality is maintained because developers ensure that nothing was overlooked.
This approach to requirements gathering for rewriting legacy applications for a rewrite ensures that you get all the requirements right, as efficiently as possible. By documenting business needs and checking them against what the system actually is, we can make sure the right changes are made and secure cross-organizational confidence in the success of the modernization project.