Requirements profile of custom software with regard to defects

A work contract applies to software when the computer software is tailored to the individual needs and purposes of a specific user and is provided to that user on a permanent basis. The purchaser/client must prove agreements concerning the agreed or customarily expected characteristics of the software, which also applies after acceptance has taken place.

In principle, it is the responsibility of the purchaser to develop the requirements profile (specification document). However, the contractor is obliged to cooperate to the extent that it must ascertain the internal business needs and clarify any apparent ambiguities.Court's Decision

According to the court's correct understanding (OLG Köln, judgment of 29.07.2005 – 19 U 4/05), the second contract between the parties is a work contract. Such a contract exists whenever computer software is created for a special use and purpose of a specific user and is provided to that user on a permanent basis. These prerequisites were met in the present case.

On this basis, the question in dispute was whether the functionality missed by the plaintiff was contractually agreed upon and whether its absence therefore constitutes a defect in the software. The court considered the purchaser (plaintiff) to be subject to a duty of assertion and proof with respect to agreements that more specifically characterize the agreed and/or customary characteristics or that could establish a promised feature, which follows from the general procedural principle that the party asserting a claim must generally prove the circumstances that establish that claim. According to the judgment, this applies both before and in particular after acceptance of the custom software. This proof was not successful because the relevant software requirements were neither specified in the specification document/requirements document nor otherwise disclosed.

Finally, the court took the view that the ordinary use of the software was not impaired by the alleged defects either, so that no claim for reimbursement and damages would arise from this either.

Furthermore, the defendant did not breach any advisory or duty of disclosure. It is namely generally the task of the software purchaser to create a specification document with the requirements profile of the software. The contractor does have a duty to cooperate to the extent that it must of its own accord ascertain the internal business needs, wishes and ideas of the purchaser, clarify any ambiguities apparent to it, assist in formulating the needs and make organizational proposals for solving the problem. The intensity of this cooperation also depends on the IT experience of the purchaser, which in the present case existed due to the plaintiff's maintenance of its own IT department. As an "experienced layperson", the plaintiff was therefore expected to provide precise specifications. The defendant had thus sufficiently fulfilled existing duties to cooperate. There was no occasion for further investigation.

The action was dismissed in its entirety by the court of first instance (LG Köln), which the Higher Regional Court (OLG Köln) confirmed in the appeal proceedings on the basis of the foregoing.

Conclusion

The purchaser's burden of proof for agreements regarding characteristics, regardless of acceptance, must not be confused with the question of who must prove software defects in the event of a dispute. Here, the important principle continues to apply that the software manufacturer must prove that its work is free of defects up to acceptance, while the purchaser must prove the existence of defects after acceptance. By accepting the software, the client acknowledges that the software is substantially in accordance with the contract.

The decision makes clear how important the careful development of the requirements profile in the form of a detailed specification document is when ordering custom software. Ambiguities and misunderstandings are later borne by the software purchaser.