That requirement simply makes no sense and the biggest mistake here isn’t over-engineering; it’s starting work on a nonsensical requirement.

“Build 3 clickable images where clicking on each one of them with cause the one being clicked to become bigger half the size of the original and after 1 second to become small again.”

“with cause” — Probably meant to be “will cause”, check with customer.

“cause the one being clicked to become bigger half the size of the original” — that’s grammatically nonsense and seems to be a direct contradiction. “become bigger half the size”. What? Did this start life as more than one requirement? Was half of this meant to be deleted at some point when they decided between “bigger” and “half the size”? Send the whole thing back with red circled around the nonsensical parts.

“ and after 1 second to become small again.” How small? If they meant “original size”, they’d have written “original size”, wouldn’t they? Would they? Given how this requirement has been written so far, who knows. Definitely don’t guess. Highlight this bit as well before sending it back.

To begin coding anything based on this mess of a requirement is a very bad idea. I thought that the first couple of coding examples were going to lead up to the reveal that the requirement had been nonsensical and that it needed sending back.

If the requirements are solid, it’s far easier not to over-engineer because it’s far easier to see exactly what is, and is not, needed.