I think it is very hard (nearly impossible) to transform Waterfall, so it meets nowadays’ software development requirements. However, as a quick thing, the excessive documentations should be removed. As Royce mentioned in describing the Waterfall model, he’d expect 1500 pages of documentation for a 5 million dollar project. WhatsApp was a 20 billion dollars project, so I’m pretty sure nobody would have read the 6 million pages long documentation. So step 1, limit the documentation to a reasonable level.
Coding and testing should never be separated in two different steps. That would partially imply that developers are not writing any unit tests, and all the bugs ranging from trivial to blocker are discovered once the full coding part is done. This implies going back to coding and then testing again, which can be a waste of time. Coding and testing shall be kept together, so as the project progresses, parts getting done are validated in one go.
Today’s market is so volatile that the full project just cannot be designed up front. Smaller units, like features, maybe could be designed very well before starting the coding phase, so the process could be broken down into delivering features (we are getting closer and closer to what we call Agile software development). At most one feature would be analyzed , designed and built at a time, and the whole project would entail several mini waterfall cycles, packed back to back.
These new features, however, would still not make the waterfall process capable of handling all kinds of software development efforts. I am pretty sure that for Facebook or Amazon these continuous waterfall cycles would not be flexible enough to roll out new features to an extreme number of customers. This new, improved waterfall would still only be suited for short to medium timescale projects. Due to breaking the software down into distinct features, more projects could benefit from the waterfall model, but larger projects still don’t qualify.