A software engineering course I once took categorized modeling/specification techniques in three groups: informal, pseudo-formal and formal. Informal specs are

A software engineering course I once took categorized modeling/specification techniques in three groups: informal, pseudo-formal and formal. Informal specs are just prose with maybe some diagrams. They are very helpful and not too labor-intensive to produce, so their usefulness is obvious, but they lack precision. Formal specs use some formalism to exactly define (often in some mathematics-inspired notation such as Z) the behavior of a program. Very useful if you have it, but labor intensive to produce, not too many people can read or write these comfortably, and keeping up with changing requirements is hard. I think the selling point of pseudo-formal notation, like UML, was that it would be a "best of both worlds", where you get most of the benefit of formal specification, while the workload is more similar to informal specification. Instead, my impression is that it's the worst of both worlds. The additional work isn't quite as high as for formal specification, but you get very little benefit for the additional work: the preciseness of your specification is still much closer to informal specs than to formal specs.