The source code existed, but there was no document explaining how the service behaved. Following the screens, APIs, and data structures of artist platform company A, we documented its functions and carried on into overall verification and the development of a point feature.
When taking over development deliverables, having the source code matters. But code alone does not mean operations and the next development can start right away.
Why does this function behave this way, under which conditions must it not run, where is the data created and on which screen is it used. The next person in charge meets these questions before changing a line of code.
Artist platform company A, which manages and trades artists' work, had no documents explaining its requirements or design. On top of having to understand the existing functions, a point top-up and management feature had to be added. Before any development, this project began with making it possible to explain what the next feature would be built on.
Having code and having a baseline turned out to be different things
In a service without documentation, current behavior and required behavior blur together easily. Whatever result a screen shows, it can be hard to judge whether it is the intended function or a problem to fix.
Nor can the current code simply be taken as the requirements. Following the existing implementation tells you how the service was built, but that implementation does not guarantee the result users need.
Takeover verification therefore involves two tasks. Describing the current behavior and establishing the criteria for evaluating it. The absence of documents is not just a handover inconvenience; it also affects where verification can begin.
We traced back from the screens to the APIs and data structures
In the project we read the code, traced the screens, APIs, and data structures, and documented the contents function by function. This is reverse engineering: working back from the implemented result to understand structure and behavior.
Screens show the result the user sees. APIs are the path that processes the action, and data structures show how the result is kept. Only by examining these connections together can you understand relationships that no single screen reveals.
The value of a recovered document lies less in its length than in whether it answers questions. Only when you can find which function connects to which behavior can you define the scope to examine before a change.
This stage does not mean every intention of the original designers was uncovered. It produced, from the implementation and behavior that could be confirmed, a description for later verification and development to refer to.
We compared what the document described with actual behavior
Using the documented functions as the baseline, we carried out overall functional verification. Defects found were recorded with a severity, and the verification results were kept alongside the document.
When documentation and testing are treated separately, the document tends to end up as reference material and the tests as a one-off check. When the two are connected, you can confirm how the functions described actually behaved.
In a takeover project in particular, it is important not to treat the existing behavior as correct simply because the code exists. Whether the result users experience diverges from the criteria for the function has to be examined separately.
In this case, verification did not stop at confirming that the code had been read. What was documented was confirmed by running it, and kept as a record that later changes can look back to.
The point feature also had to connect to existing transactions
Once the existing structure had been understood and verified, we developed the point top-up and management feature. We defined the relationship between top-up, spending, and balance and connected it to the existing service.
A point feature is not a matter of adding one number that looks like an amount. If a balance changed, it must be possible to explain why, and the spending action has to interlock with the existing service's transactions.
If, for example, a balance is shown on screen but there is no way to tell which spending history produced it, the operator cannot handle inquiries. This is why a new feature is hard to think about in isolation from the existing structure.
In company A's case, the feature was added on top of a foundation that had first been understood and verified. That is what sets it apart from rushing into additional development without knowing the structure.
We left the next team assets beyond the code
The project deliverables included a document describing the functions, test assets, and defect records. Along with the additional feature, we left the material the next team needs to understand the service.
Having such material does not automatically resolve every maintenance problem. When functions change later, the document and the verification criteria have to be updated with them. What it does is keep the next piece of work from starting again from code with no explanation at all.
The important change in this case is less that new documents were created than that it became possible to ask questions about the acquired service and confirm the answers.
A software takeover does not end at the moment the files are received. The next development begins when you understand what you have received and can explain which effects to check when changing it.