Re: "As is common with IT systems, even after testing issues may also emerge"
"When I write stuff, people generally get what they asked for. (Software developer accepts no liability for people asking for daft stuff.)"
That's kind of the problem. Unless you happen to also be expert in that relevant area, then getting the requirements that no-one thought worth writing down is the key difference between "do what I say" and "do what I want".
At the very least when someone asks for you to make them a glass hammer, you should check whether they intend to bang nails in with it, and point out the obvious flaws.
So if someone wants daft stuff, and will pay you to make it, that's all well and good. But it's usually good practice to check they know *why* it's daft, and get them to confirm it.
Plenty of places I've worked in also had the issue where something bleeding obvious to customers and front line staff was apparently not so obvious to those doing the dev side of things. If you force the buggers to have to actually use the systems* (in prod, not test) then they usually whine and scream (while being less competent at phone support than your average teenager) but end up building much better systems.
It's a bit like pair coding. It's stressful, frustrating, annoying and tiring, but you end up with a much more solid product. No one enjoys it, but it's still good practice.
* it's also a good technique for management too, but they hate being shown up as being unable to do the work of someone below their pay grade.