Requirements Engineering in system and data migration

Nowadays, migration projects are commonplace for companies. Migrating a system to the state of the art can reduce costs, increase system availability and data integrity, and allow the company to continue to evolve. In brief: Migration helps to boost competitiveness. However, migration projects are complex and full of risks. Requirements engineering supports the realisation process over the entire course of the project, from reverse engineering to requirements analysis, planning of the migration and derivation of test cases. Older systems tend to be limited in terms of their extendibility and scalability. There is also the high cost of maintenance and the fact of operating partially obsolete hardware. Moreover, for legacy systems that have been in operation for longer periods of time, the relevant knowledge about the application is typically not fully documented and – to the extent that it exists – is concentrated among only a few employees. As with any other complex project with a high level of importance, requirements engineering is crucial in migration projects. This is true particularly if the new version of the software is developed by an outsourcing partner in Asia or Eastern Europe. Systematic elicitation and analysis of the requirements ensure that the finished product will support the business processes as desired. If such work is omitted entirely, there is a risk that deviations will not be detected until the acceptance tests are performed, which will invariably result in costly adaptations and completion delays. In any case, it is necessary to take into account new requirements to be integrated into the further development as well as requirements associated with the existing application. Accordingly, the first step usually involves reverse engineering, and a great deal of attention and resources must be dedicated to adaptations and revisions. This is necessary due to the high level of importance but also because migration projects are complex and can, if they involve the core system, even be critical to the company’s survival.

Example 1: Reverse engineering of a core application

In its back office, a large service company uses a core application that it developed itself. The application reads in large quantities of data, processes the data using specified business rules and distributes the results to internal customers in the company. The application now requires further development. In the first step, the existing solution is analysed with the aid of reverse engineering. Some eighty business rules are identified, two unknown interfaces to peripheral systems are discovered and the supported business processes are documented for the first time. This example pertinently shows how little explicit knowledge is available about existing applications in organisations. In many cases, there is some documentation but it is generally not up to date. After only a few years, changes as well as newly added business rules have caused the application to be so extensively modified that older documentation is hardly relevant any more for the current version. Accordingly, it is a general rule for migrations that requirements that were elicited years ago for the development of an application cannot be used. Even though reverse engineering might entail a relatively large outlay, it is still recommended in very many cases. It should definitely be performed in cases where the migration of a core application is involved.

Example 2: Problem solving in data migration using requirements engineering

In a large service company, there is an older system that no longer fulfils internal requirements in the areas of technology and security. Accordingly, it must be replaced. A solution is to be newly applied that is already used for somewhat different purposes elsewhere. Along with introducing the application, the data must be migrated. During the reverse engineering work, the requirements engineer discovers that the existing application and the planned new application use different data models. Results from the two systems appear to be identical at first glance. However, detailed analysis reveals that the results are based on different data sources, which would lead to critical errors upon introduction of the new system. The difference is important because the result has legal relevance. Accordingly, the requirements engineer works with the technical department to develop a solution ensuring that both applications produce an identical result when presented with the same body of evidence.

Data migration using requirements engineering

Fig. 1: Data migration using requirements engineering

This example illustrates a typical problem occurring in data migration, i.e. differences in cardinality between entities of new data and old data. However, the example also raises an important point that goes beyond data migration: It is generally a challenge to match the old to the new in migrations. This also applies to the requirements. After all, the aim is to improve the existing application and not just to replace it. In particular, all of the requirements must be checked for consistency. It is possible that the behaviour of the new system will differ considerably from that of the old system. The subsequent project steps cannot be taken until the requirements exist in their entirety as a consistent and complete unit. This forms the necessary basis for writing test cases and beginning the development of the new application. This is why the requirements engineer ought to be involved in the go-ahead decision in both cases. The knowledge about the existing application gathered by the requirements engineer is also important for planning the actual migration process. Out of the existing possibilities (big bang, parallel adoption, phased adoption), the third one is chosen in many cases simply because it minimises the risks. Of course, phased adoption requires taking into account dependencies between the new application and the peripheral systems. In the case of migrations, the role of the requirements engineer is not restricted to ascertaining and analysing the requirements. On the contrary, he acts as a subproject manager. This once again illustrates the immense importance of requirements engineering in migration projects. If this discipline is tightly controlled, the prospects for successful implementation of complex migration projects are good.