Wenn es nicht so traurig wäre, wäre es lustig. Erschreckend oft höre ich in der Praxis:
"Requirements Engineering / UML / Use Cases haben wir schonmal probiert, aber das hat nicht geklappt. Also lassen wir es." Das ist genauso gruselig wie: "Ich finde ja schon, dass man Requirements Engineering machen sollte, aber jetzt muss ich erstmal die Software erstellen und ausliefern. Danach kann ich mich wieder mit Requirements beschäftigen."
Ähäm?

Bei jeder komplexeren Tätigkeit muss gelten: "First plan, then do!" Man begibt sich doch auch nicht auf eine Reise, ohne zu wissen, wo man hin will und wozu. Ich recherchiere immer vor der Reise genau, wie ich hin komme und wie lange ich dafür brauche, damit ich weiß, wann ich los fahren muss, um pünktlich anzukommen. Daher kann ich mir gar nicht vorstellen, wie man ohne Requirements Engineering und Entwurf eine ordentliche Software produzieren kann. Natürlich kann man etwas hinbasteln, das nach außen hin wie eine Software aussieht, und wenn irgendwelche Funktionalitäten fehlen, behauptet man einfach: "Das ist technisch nicht möglich." Aber das ist wie wenn ich bei einer Reise dann streckenweise mein Gepäck zu Fuß tragen muss, aus Ermangelung eines Transportmittels, oder immer wieder zurück fahre zum letzten Umsteigeknoten, weil es auf dieser Route leider doch nicht ans Ziel geht. Mal abgesehen davon, dass ich am Ziel feststellen könnte, dass ich eigentlich ein anderes Ziel hätte ansteuern müssen.

Man könnte ja vermuten, die Profis machen durchaus RE, denn offensichtlich liefern sie ja lauffähige Software aus. Vielleicht meinen sie mit "RE" einfach nur alles, was aufwändiger ist als ihre handgekritzelten Workflows und White-Board-Architektur-Skizzen. Dann bestünde kein Verbesserungsbedarf: Die leichtgewichtigen Modellierungsansätze, die sie verwenden, funktionieren ja. Allerdings zeigt gerade ihre Hektik à la "Wir haben keine Zeit für RE, weil unsere Software so viele Fehler enthält" oder "Unsere Software ist so komplex, dass man sie gar nicht modellieren kann", dass hier irgendetwas dann doch nicht ganz rund läuft. (Tipp: Ist Ihre Software zu komplex, um modelliert zu werden, brauchen Sie entweder mehrere Modelle oder eine besser strukturierte Software, also ein gründliches Refactoring. Ich weiß: Dafür hat auch wieder keiner Zeit. Aber zu komplexe, nicht modellierte und nicht verstandene Software ist eine tickende Zeitbombe!)

Worauf ich aber hinaus will:
1.) Requirements Engineering ist nichts, was auf Anhieb klappen muss. Diese Tätigkeit, die nicht nur die Kenntnis von Standard-Notationen voraussetzt, sondern auch gewisse erfahrungsbedingte Fingerfertigkeit und kommunikative Softskills, erlernt man nicht auf den ersten Versuch. Beispielsweise auf die Frage "Wie detailliert muss ich denn modellieren?" lautet die richtige Antwort immer: "Das kommt darauf an, für welchen Zweck Sie modellieren!" Und letztlich findet man dies heraus durch... Ausprobieren.
2.) Requirements Engineering und Modellierung machen Probleme sichtbar, die vorher schon vorhanden waren, aber nicht so greifbar. Die Software war ja allmählich zu einem komplexen, undurchschaubaren und unmodellierbaren Gestrüpp angewachsen. Bisher war es den Beteiligten vermutlich nur intuitiv klar, nun erhalten sie den schmerzhaften Beleg dafür. Modellierung dokumentiert nicht nur das vorhandene Wissen, sondern eben auch
Wissenslücken.

Und das ist ja auch der Nutzen von Requirements Engineering: Es zwingt zu klaren Aussagen,
zu Entscheidungen, die man ansonsten unbemerkt offen gelassen hätte, zu Überlegungen
à la "Wie ist es denn nun genau? A sagt X und B sagt Y!"