I work in Fintech, I think training people on how to write good requirements and specifications is lacking
But I am asking myself if it is just lack of knowledge and knowhow or is it also lack of time, processes and tools for writing and maintaining requirements.
My observations are that along with not knowing how to gather and write requirements people at the project level also threat them as second hand objects for the success of project.
Eg: some people in agile talk about requirements being user stories with clarifications and decisions around them. Other people say that in agile requirements are conversation starters.
In a way these might be good points but also it creates the impression that we should not invest quality in requirements. As it will anyhow change.
They almost need some training on how to think like a program in some sense to understand just how much detail is needed to provide a good spec.
I remember a computer history class, where the teach mentioned time sharing was invented in the mid 60's and one guy was insistent it should have been invented earlier. He felt the requirement was always there, and should have been done in the 40's...
A key problem with many requirements documents is that they're documents (often in Word if "formal", or communicated via email or similar otherwise). You have to be able to separate out the individual requirements and understand the difference between requirements and specifications.
A requirement is what it most do, a specification is how. So if a customer has levied a "requirement" of "Using Java, create classes to handle the following...". That's a spec (even a design doc, really), not a requirement. So get them to answer the why of it. Maybe you're writing something to run on their existing app server, so Java as a requirement makes sense. But maybe that's just what they're familiar with, and so should be dropped or altered.
Next you need to start collecting all the requirements. Maybe some come direct from the customer (The system MUST display account balance). But maybe it comes from a legal authority (The system MUST flag all transfers over $10,000). Find those and list them out. Some of these requirements will be linked to each other, figure out which. And when you get to developing specifications, it's the same.
"SPEC-10345: In order to meet regulatory requirements a log will be maintained of all transactions over $10,000 <REQ-10011>. SPEC-10346: This log will be retained for a minimum of 3 years <REQ-10012>.". That link allows you to know the element of the specification isn't arbitrary, it has a reason. And by linking you can update the related spec when the requirement changes. The law changes next year and the threshold increases to $20,000. Update your requirement and all linked requirements and specs will be flagged for review. Now you know to update this specification element, and the code which implemented it.
But the hard thing is, this has to be automated and disciplined. Either with custom tools (all this written in plaintext and hand written perl or whatever to generate reports and analyses) or an actual requirements database software solution. Every project I've been on where they insisted on using Word (or Excel, only slightly better) for this has been a cluster fuck when it comes to maintenance and tracking later on. You can afford to be slack on this in many industries, but where there are significant legal and regulatory elements or safety factors to consider this is critical.
Writing out these more formal specs and requirements you'll also find those edge cases you mention in another post (though not all). It'll be obvious when a requirement isn't satisfied by any specification elements. And on review, when a specification element doesn't actually satisfy the related requirement.