I have friends that used to work in the medical device industry. Processes there are pretty strict, so it might very well be the case that they do. However, 1 million lines of code is a lot so I would still be worried about bugs.
> Another example: how many projects on GitHub provide a comprehensive list of requirements/features? If you don't have a traceable list of requirements you don't know what you are building (or testing).
That's a bit different. That's usually people scratching their own itch.
> And, on your job: how many projects you worked on that have a comprehensive list of requirements?
I don't know that a comprehensive list is what is valuable. What is valuable is being able to explain the provenance of a particular piece of code. The best way to do that is with version control. With version control, you can usually figure out why the specific piece of code was written either because:
1. The commit referenced an ticket in a work ticket database
2. The commit has an explanation for the change in the commit description
3. The commit contains a code comment or a piece of documentation that explains the change
I think many people assume that they need a separate master database of requirements, and so only (1) is valid. However, whenever I've had to do maintenance on a piece of legacy code, the version control system has been my most reliable source of truth.
Of course, a lot of these old mainframe systems were built before proper version control techniques were developed. Revamping them is going to benefit greatly from advances in those techniques.