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
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
Consequences for the Requirement Specification?
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?
How to achieve this association?
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?
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
With the concepts of cookies in place, you could divide the implementation into five buckets
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
To see this concept in a live format – visit our demo webcast on youtube.