One of my experiences growing up was learning the myriad of sins one can do as a Catholic. Frankly the list is huge. One of the sins that strikes me as a catch-all in case they forgot any is the Sin of Omission. So it wasn’t enough that you commit a sin but you advertently don’t do something to prevent another sin that is in your power to prevent. Or as Martin Luther King said
“In the end we will not remember the words of our enemies, but the
silence of our friends”
Now jump into software development. When specifications are created, which we should take in general as a good thing, there is an important aspect to consider. This is to read between the lines, to discover those items that have been left out, like non-functional requirements, concurrency issues, network issues etc.
The list of things that could be left out of specifications is large. Experience helps to spot areas that have not been specified or not specified in enough detail. Requirements lists or SRS documents are good places to start. If possible go back to the source to review those requirements. Never assume just what is on the paper is all there is to do.
Gaps in expected functionality is a big red nose day. Therefore it is good to have requirement traceability. Test cases directly related to requirements are hugely beneficial for testers and developers. There have been many times a developer has been grateful for a testers diligence in spotting a requirement that has not been coded for. Usually have the developer has reviewed the test cases.
Finally, to ensure those items that have been omitted by accident or lack of process, try to review the software as early as possible with the end-user, product architect etc. Don't keep your software a secret until the end. When requirements have numbers and can be traced, spotting those omissions becomes a lot easier. In the end traceability and early views mean you rely less on Hail Mary’s and more on sure things.