I think it does. I only ever encountered the concept in connection with employment law, but I suspect that implied terms of contract are a general legal principle. (I would take advice on this if you have a particular contract in mind…)

I wonder if that also applies to B2B commercial transactions?

In employment law, there are things called “implied terms of contract” – things that are not written into an employment contract, but which any reasonable person would consider to be part of the contract as a matter of course – that the contract should not break any laws, that both parties will observe reasonable standards of conduct, that custom and practice in the employment situation will not be breached without consultation and so on. The same thing goes for requirements (or at least, it ought to).

Thanks for joining the conversation, Robert. I too have seen such tings, one in particular one to mind: the requirements for the Post Office technology refresh project, which was to become “New Horizons” was an impenetrable Doors document of some 1200 pages. Pretty sure “protecting the users from being sued for fraud” wasn’t in there. Probably also missing was “protecting the government from embarrassment and compensation claims”.

In my last role, I came in as a tester on a project that had been kicked off some six months previously, but no code had been written. Customer requirements had been produced by a team of consultants, who had delivered their list and then gone on to the next job. Unfortunately, no-one reviewed what they had written. When we rolled the product out to customers, they came back with a list of things they wanted the product to do, none of which had been mentioned in the requirements. And the manager who had commissioned the project in the first place had moved on, of course.

Even once we put in place measures to meet customer requirements, we ran into more trouble., The product was part of a business workflow that had to integrate with an API and downstream accounting and invoicing apps. But there were things that had been put into our new product that had no analogue in the data schema in either the API or the downstream apps.

First problem was that some features in the product (a work scheduling app) didn’t show up in the invoices because there was nothing in the API that would accept these data items. Worse was to follow. The data schema in the product was a complete mis-match with the invoicing app. We ended up with about £3 million of business that couldn’t be invoiced because the app couldn’t parse the data files that were being generated.

Once that was all fixed – and it took six months – our next project was given a far more generous timescale for requirements gathering. But too generous for the company’s owners. They pulled the plug on all in-house IT systems development, and went out and bought a proprietary product to take the place of the project we were working on. Then they went out and bought the company that made the proprietary product, because what our company’s owners were good at was buying companies rather than understanding software development projects.