I was a software engineer in the 90s at a small company (15 people) doing simulation development for the UK Ministry of Defence. We had two distinct software development processes, which were waterfall and a form of rapid development known as the Dynamic Software Development Method (DSDM). (I threw away the manuals years ago so can’t give more info).
The company directors came from an aerospace background so had a very strong software quality focus. Many of our contracts specified waterfall and our project artefacts reflected that – user requirements docs, system requirements, architectural design, detailed design, integration test plans, system tests, acceptance tests, etc etc. Coding happened somewhere in the middle. It did work, sort of, in situations where the customers knew what they wanted, and we mutually understood it. Which was quite often the case, for our regular customers on projects that were extending existing systems.
We trialled DSDM for projects where the customer said ‘prototype’ and I liked it. It lacked the onerous agile / scrum boilerplate and IIRC was based around loosely specified timeboxes and relied on having ‘intelligent customers’ who were prepared to be flexible in terms of what they got at the end.
The need for DSDM was motivated by a project that failed badly (not with the MOD) because the customers said ‘here are our requirements for this prototype system, don’t come back until you have finished and tested it’. Needless to say the result wasn’t what they expected, even though all of the requirements had been, on paper, met.
But for any development where specific technical outcomes were necessary (e.g. a maths module), waterfall would usually be used.