Does the system delivered serve what was contracted? The examination answers by reading the repository, the database and the test environment, with dated evidence.
In a software project that went wrong, the client says the system does not work. The supplier says it delivered and that the delay came from changes the client requested. The judge or the arbitrator needs something else: what was done, when, and why it failed.
That answer lies in the project's own records. The code repository keeps every change (every commit) with date and author. The database shows what the system recorded. The ticketing system shows who asked for what. The staging environment shows what was ready for testing.
Software forensics preserves those records before any analysis, with hash and chain of custody, and reconstructs the project from them. This page deals with the examination of the software itself. The overview of IT contracts and ERP implementations is in Information Security and Compliance. The choice between litigation, arbitration and mediation is in IT Arbitration and Mediation.
"It does not work" has to become a fact: which feature, in which environment, with which data and with what result. The examination runs the disputed flows and measures the behaviour against what was specified. The quality characteristics of ISO/IEC 25010, such as functional suitability, reliability and performance efficiency, give both parties a common vocabulary.
Who caused the delay? The timeline cross-references commits, published versions, tickets, approvals and change requests. It separates development delay from delay caused by the client's dependencies, such as access, data and approvals, and from scope changes that came in without an amendment.
What was ready on the date of termination? The examination compares the code in the repositories with the version in staging up to that date. It separates what was delivered, what was under development and what never started.
Did the supplier reuse code from another client, or does the new system copy the old one? The examination compares the code bases, identifies the origin of each component and shows who wrote each part. The subject has its own page in Intellectual Property, Trade Secrets and Unfair Competition.
A piracy notice arrives, or a licensing audit brought by the vendor. The preliminary licensing examination establishes, with forensic imaging of the equipment, what is installed and what is licensed, before the company responds. In litigation, the role is defending the audited company or, in other proceedings, acting as court-appointed expert in actions brought by vendors.
When a production failure triggers a penalty, the question is where it came from: a code defect, environment configuration, a poorly managed change or a security incident. Database logs, change management records and the testing process, which has its reference in ISO/IEC/IEEE 29119, show the cause and who was responsible for it. Many failures are not cyber incidents. They are process failures.
01 · Preservation. Copy of the repositories with full history, of the database and of the environments, with hash. Nothing is examined in the live environment.
02 · Timeline. Commits, versions, tickets, minutes and e-mails ordered in a single chronology.
03 · Comparison. What the contract, the proposal and the requirements asked for, against what the code and the system do.
04 · Tests. Who tested, what was tested and with what result. Each party's tests are measured separately.
05 · Mirror environment. When the original environment has changed or is unavailable, the examination builds an equivalent environment to reproduce the failures and test competing hypotheses.
06 · Report. Findings, hypotheses tested, declared limits and annexes that both parties can verify.
Software price and deadline are better discussed with a measure. Function point analysis measures the functional size of a system by what it does for the user, independently of language or technology. It is an internationally standardised method (ISO/IEC 20926) and widely used in federal government software procurement, according to the Software Metrics Guide of SISP, the system that brings together the IT bodies of Brazil's federal administration.
In forensic work, the count serves to compare the size of what was contracted with what was delivered, or to assess whether a price has a technical basis. It has been applied, for example, for a client who needed to justify in a public tender the price it charged and show why it differed from that of other bidders (case described in Public Procurement and Infrastructure).
A development contract was terminated with the parties in disagreement over what had been delivered and over the cause of the system's failures.
The project repositories were preserved with full history, and the commits were compared with the staging version up to the date of termination. The examination rebuilt a mirror environment and tested the hypothesis that the failures came from the corporate network's proxy (the intermediate server), and not from the code.
The report delimited, in dated evidence, what was ready at termination and where the failures came from.
A company contracts the development of an app with a six-month deadline. Nine months later, it is still not in production. The supplier says the client changed the scope and was slow to grant access to the systems. The client says the code arrived with errors.
The examination builds a timeline from the commits, the tickets and the approval e-mails. It shows how many features came in after signature, how long each access request sat waiting and how many deliveries came back from staging with defects.
With that chronology, the delay stops being one version against another. Each party sees the share that belongs to it, and the negotiation, the arbitration or the lawsuit start from facts.
See also
IT Arbitration and Mediation → Information Security and Compliance → Intellectual Property, Trade Secrets and Unfair Competition → Judicial and Extrajudicial Expert Work → Public Procurement and Infrastructure → Digital Law and Technology →
Before deciding, it is worth seeing what has already come through this laboratory: cases described without identifying the parties, in the format of challenge, method and result.
The intruder's control channel was written into smart contracts. The examination decoded what he had deleted and handed the authorities concrete routes to identification.
See the case Negative proofThe official examination had concluded that he took part. The re-examination showed the links were false positives, and the accused person was cleared.
See the case