The requirements were hammered out in brutal detail by an experienced specialist. Each requirement agreed with the customer, and then each requirement carefully worked into a design. Each requirement clearly linked with every part of the design that fulfilled it. The design reviewed and approved. The code written in literal style (using a variant of noweb), with discussion and commentary, and that noweb document compiling into the source code to be onwards compiled and also a beautiful document listing the full source code and the various commentaries and discussions of it (such that one understood the code not by looking at the code, but by reading the document, which was like a structured guided tour of the code, and to look at the actual code was to see a one-to-one relationship with the documentation).

Each part of that document linked to a part of the design, and thus to the requirements. Tests had been written independently of the code, based on the design and the original requirements. Test documents were printed out, and an individual conducted every test on that document, writing down version numbers and so on, and writing down each results, circling PASS or FAIL, signing their name to it. Successful test documents were sealed in an envelope, with a date and signature, and put into storage against the customer requesting to see one (which happened every so often).

The original requirements could, years later, be followed through the design, through the code, through the tests; the whole chain verified on demand.

The software I worked on was developed over most of a decade (I was only there about four years), with a delivery a couple of times a year. The customer never once reported a bug. Every requirement was met. Other contractors had their part taken away from them and given to us, and when it was finished they took it and asked us if we could start working on the next generation product of the same.

I have never before or since worked on such high quality software. It was only possible because we happened to have really high quality customers, who actually knew what they wanted and had the ability to say it and agree to it.

Because waterfall generally has milestones as a coarser grained way of ensuring evidence of forward progress, all deliverables generated around the time of a milestone just become candidates for delivery. Do you want this version that is missing two features, this version that is missing one but the other might be buggy, or to wait another two weeks to get the whole thing? If you have anything that looks like QA or acceptance tests, those can be run on deliverables, keeping people a little more comfortable with the process than they would with strict Waterfall.

A company doing Agile poorly most likely would do Waterfall poorly too.