Projekt Digital

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.

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.

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.

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.

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).