CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time.
Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall.
And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again.
This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths.
OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain.
CASE, in fact, did theoretically work. In practical, sustainable terms it could not.
The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.