2+ decades ago, US Air Force acquisition classes taught exactly this method. I don't recall whether they used the word "waterfall", but they showed the same diagrams and treated software development like massive hardware projects, such as building an F-16: first you write a long requirements document, then generate a voluminous design document, then break the design into a work breakdown structure, farm out component implementation to developers, then finally integrate, test, and ship. It borrowed heavily from the field of Systems Engineering.

In my experience it never worked. We were able to achieve success only by secretly ignoring the rules and process and instead developing software in what detractors called a "cowboy" process. When "agile" came out, it changed our lives. We adopted a few new good ideas, but mostly kept working as we had been. But now we could point to this quasi-official "agile process", with tailoring as they recommend. As long as we were following a process, and not being "cowboys", folks seemed satisfied.

These days the Air Force has caught on to "agile". They even have 400-page manuals on the process to follow to be "agile"! We still cut some corners here and there and do what we think makes sense, but there's far less process push-back than there was in the past.