Projekt Digital

Der Blog für digitale Business Leader

Requirement specifications for migration projects

Migration projects smell different.
by Stephan La Rocca, PITSS Migration Expert for Oracle Forms, Reports, APEX, ADF

Start reading the blog from Joy Baetty (Vice President Seilevel) titled “Gathering requirements for Migration Projects” I could only nod chapter by chapter: „The requirements gathering effort for migration projects is notably different … “ and the differences are “ … scope definition, understanding original business needs, working with end users, discovering the end-to-end functionality and IT involvement.“
That’s exactly what we figured out in over 100 migration projects in the past. More than that, most customers are experienced in maintaining and enhancing the existing software landscape, even developing new software is captured well, but a huge migration project is not the daily business for them. It requires more than you think.

All starts with the scope definition. In short terms, the first reaction is: „All the same, but better“.

In most cases, the underlying business processes won’t change in a dramatic way

PITSS 2021© Standard ratio of requirement specifications for migration projects
If we consider the amount of Function Points for supporting the various business processes in an existing application, we see such a typical distribution. The sectors treat only the business process, not the user interface, or the underlying implementation. In other words, in an average migration project you improve 17% of your business processes, create 10% totally new, get rid of 14% and correct the behaviour of 4%. More than half will remain the same as before. Once more, not from UX or technology standpoint.

Consequences for the Requirement Specification?

The Key-User is happy to describe in detail the enhancements, he’s keen to point you directly to the bugs, he beliefs to have a complete understanding of the improvements, he’s insecure about the things we could ignore and he doesn’t even have a clue, of the completeness of the things which should stay the same. With classical requirement specification you will cover in best case 31% of the business processes.

If you try to cover the rest, you rely either on existing specification in an actual version of the system – or you have to run into endless interviews with the user to understand the business needs. And you’re not sure if this fits to the actual implementation. So a second iteration of endless code reading follows.

Midsize applications could expand very fast to million lines of code, distributed over different levels of layers (Backend, Midtier, User Interface, Integration Layer, etc.) and we have to consider, that over the years of maintaining, the application is not free of technical debt, which increases the level of complexity.

How to improve 69% of the requirement specification?

Key to success is to combine the required user actions for a business process with the underlying software components. If we could associate each line of code with the order of execution to one or more business processes, we could assign the implementation, the components, more or less all of the software to the business requirements. If there is no association found, the specific part of the application could not be assigned to a business process, we could get rid of it.

How to achieve this association?

We all know the concepts of cookies on web pages, which allow us to analyze user behaviour. Usually legacy applications are not designed to deal with cookies, but with intelligent software parsers it is possible to integrate the concept of the cookies in an existing application without breaking the existing functionalities.

Cookies don’t use a high sophisticated logic, even some minor context information is necessary, to reconstruct the user behaviour. The only manifest is to insert the cookie into each procedure, user interaction object, class, etc. A perfect match for a software parser and a modern IDE.

How does this change the requirement specification?

There are two different approaches that help to get a full picture of the application in a very smooth, fast and absolutely accurate way.

On one hand the user is able to track a single but complete business process, giving a dedicated start and endpoint. The order and level of cookies describe immediately the assigned user interface, all validations, business logic and persistent functionalities. An excellent start of a retrograt business process specification. With additional annotation, the user is allowed to give feedback to existing bugs, possible improvements or any other soft facts to the process.

Do not only talk about - do it, record it, understand it. #SimplifyingComplexity

On the other hand you could observe the application from an overall perspective. Let the user run day by day through the application and let the cookies record their stories. After a while you will identify the hot spots in the application, but also white spaces with no traffic. This allows you to point the user directly to these parts of the application and ask him to record the missing business process or clarify this functionality (and by the way you could perfectly describe this through the knowledge of the missing cookies).

With the concepts of cookies in place, you could divide the implementation into five buckets

PITSS 2021© Dashboard of “DigiDocs” after a couple of recordings.
Blue are the dedicated processes

Yellow are fragments in use, but not assigned to a process

Red is technical debt

Grey is not even touched

Green is in use and assigned

Each of the clusters is clickable and points directly to the appropriate places in the application.

Single processes could be documented in various ways

Example for tabular format

Example for graphic format
All this information about your complete applications, what is needed, what is not needed, what is redundant, what is a hot spot etc…. you get without boring interviews and hunting through undocumented code. #LegacyCodeMatters

To see this concept in a live format – visit our demo webcast on youtube.