What is a specification if it’s not the intent?

There was a recent BBC article on contactless/NFC cards triggering transactions inadvertently.

What was most interesting in the article was that, not only did one customer manage to reproduce the behaviour, but Martin Emms, a researcher into new payment technologies, commented that “The terminal is working within the specification of Near Field Communication but not within the intent”.

This got me thinking. Isn’t the specification the intent?

I’m sure nearly every software developer has had the following conversation with a customer (I certainly have):

Customer: “It’s not doing what it should.”

Developer: “It’s performing according to specification.”

Customer: “Then the specification is wrong”.

Developer: “Erm…”

Of course, it’s not just up to the developer to get the specification right – as we all know (we do know, don’t we?) it’s a collaborative process which the customer should buy into as well.

The crucial question is how far down the development process this occurs. Agile/iterative development allows for correction along the way, and allows for the design to be brought back in line at the least cost. With traditional waterfall development, we’ve got a problem. How much is it going to cost to correct the system to perform as intended?

So for me as a software designer and developer – and potential (but not current) user of NFC cards, the crucial question is whether the specification for a system which has been rolled out is at fault, or the terminals are in fact not performing within specification. I hope it’s the latter.