Requirements Elicitation and Analysis When Transforming Legacy Systems

Overall Transformation Lifecycle

The general steps you take in legacy transformation projects are the same as in other system development projects which include the old system as a role model that should be conceptual and technically redesigned. 

Although legacy transformation includes the same phases and activities as other systems development projects, certain activities are more important for legacy transformation projects.

It is important to develop the business case for replacement/transformation early. The real business problem will not be in IT terms, it will be in business terms to explain why they need something.

One of the first steps after the definition of a business case is to initiate a requirement gathering. This means that you will need to involve the company’s most knowledgeable and constrained resources. You need a Subject Matter Expert (SME). Here you must be careful – business users, who spent most of their professional career using a legacy system, usually have one way of looking at things. The real risk here is replicating the legacy with all its problems. The new system will look better to the customer and some functions will surely function better, but it will be just like putting a modern face on old systems.

Therefore, you must carefully choose and plan which business analysis techniques you will use during requirement elicitation. For example, in this situation, brainstorming challenges can be “groupthink” or “dominant personality”, if the group gets fixed on a dominant idea.

Furthermore, be careful with the conventional scope model like the UC model or functional decomposition since they usually do not explicitly show out-of-scope elements. Take the context diagrams for that purpose.

Some suggestions for various business analysis techniques are given in the following table:

When defining the requirements, one should first carry out an AS-IS analysis. This elicitation should above all identify:

• AS-IS business processes and potential improvements
• Legacy data and application (data and app mining)
• Current business rules
• Functionalities (with detection of ones that overlap or are redundant)
• Obsolete or unused functionalities
• Non-functional requirements
• Infrastructure components and constraints

Gap Analysis and Process Model

First, explore the differences between the current state and the desired future state. Change the business processes to match the new business need; do not try to make the new system work like the old one. When modeling AS-IS and TO-BE business processes, be sure to include the statuses and data flow since gap analysis often leads to gaps associated with the distribution of information being identified. (for more details, see Data Integration).

Business Rules

There are two approaches to the extraction of business rules in legacy transformation projects. The code review/walkthrough is the technical approach. The second one is the functional approach – when a business analyst interviews the business people who interact with the system and elicits the rules from them.

Data Integration (Migration)

One of the keys to a successful migration is data integration. The most important thing is to analyse, clean and transform the data through successful data migration.

Successful data migration includes:

• Extracting the existing data. The data in existing legacy systems is usually inconsistent.
• Transforming data. To match the new formats, the data should be transformed through data mapping. This step is crucial to ensure that the new system can use the data from the legacy system.
• Cleansing the data. The quality of data should be checked and data should be cleaned by resolving inconsistency, duplication, and to meet new business categories.
• Validating the migration. Once the data is extracted, transformed, and cleaned, a sample set of data should be imported to test the problems and errors before production.
• Loading the data into the new system. The final step is loading all the data into the new system.

When describing the data sets use the extended data dictionary, as the conventional data dictionary has a limited attribute set and leaves a lot to the developer's discretion.

Usually, the data dictionary describes the data type, data format, field size, description, and example, but you might consider adding min and max values, validation rules, default values, etc.

Scope Implementation and the Challenge of a Moving Target

Defining the scope of the new system is very important in a replacement project. Although the scope is known, the risk is that because the legacy is a live system, some types of functionalities are harder to freeze and wait for the new system. This is often the case in highly regulated business sectors (financial or government) where we have continuous changes to legislation.

You must communicate the possible options to the key stakeholder. The choices are to freeze the legacy for the duration of the project (except for emergency bug fixes) or to accept a reduced set of functionalities for the first release.  

Risk Management

Above all, legacy transformation projects require identifying, anticipating, and mitigating risks. You must ensure that the project risk matrix stays up to date and that the team is aware of it in order to mitigate risks before they become an issue. Some of the risks may be an underestimation of effort/schedule costs, degradation of service, organizational resistance, insufficient knowledge of how the old system works, changes to the business/legislation during the project, etc.

In conclusion, for legacy system transformation, the key point is a strong business case, management of key stakeholders, and alignment to the business strategy. Although modernization programs are primarily seen as a key for resolving technical problems, they are not exclusively technology-based. Business analysis tools and techniques should be carefully selected for these types of projects, with a special focus on risks and scope.

References: Business Analysis for Practitioners – PMI, 2015; Business Analysis – D. Paul, J. Cadle, D. Yeates, 2014