Aus dem Kurs: Einführung in die Softwaretechnik 1 – Grundlagen, Analyse, Design, Vorgehensweisen

Requirements Engineering verstehen

Aus dem Kurs: Einführung in die Softwaretechnik 1 – Grundlagen, Analyse, Design, Vorgehensweisen

Gratismonat starten Für Ihr Team erwerben

Requirements Engineering verstehen

“

Wir wollen uns jetzt mit dem Thema Requirements auseinandersetzen. Requirements-Engineering besteht aus den Worten Requirements und Engineering. Engineering kennen wir bereits. Auf Deutsch also etwa Anforderungsanalyse, Anforderungsmanagement oft genannt. Dabei möchte man verhindern, dass man Vermutungen in irgendwelchen Dokumenten hat, von dem Produkt, das in Zukunft entstehen soll, die nicht verfolgbar sind. Denn Fakt ist, jeder denkt etwas anderes, hat oft ein bisschen andere Vorstellungen von dem, was eigentlich gebaut werden soll. Das Ganze Thema Requirements-Engineering hat auch ein bisschen Überschneidungen mit der Analyse, worauf wir später noch eingehen. Schauen wir uns mal an, was im Projektverlauf so alles passieren kann. Aller Anfang ist einfach, der Code ist klein, das Produkt ist klein, die ersten Anforderungen werden implementiert. Aber mit der Zeit treten immer mehr Probleme auf. Eins der wichtigsten Problem ist sicherlich auch: Keiner blickt mehr durch durch den Sourcecode. Die Developer sind nur noch am debuggen. Ein großer Berg an Spaghetti-Quelltext entsteht. Aber ein wichtiges anderes Problem in Zusammenhang mit dem Requirements-Engineering ist, dass der Stakeholder seine Meinung ändert, also der, der das Produkt beeinflusst und später haben will, seine Meinung ändert und vielleicht andere Features haben will. Das sind so die üblichen ersten Probleme, die auftauchen. Es können aber auch noch viele weitere typische Probleme auftauchen, die Sie aber alle zu einem gewissen Teil schon sehr gut mit einem guten Requirements-Engineering angreifen können. Dies sind z.B. auf der linken Seite ungenaue Planung und Verfolgung des Projektes, unklare Zielvorstellung auf jeden Fall. Was will ich eigentlich? Hoher Komplexität des Systems hatten wir schon, aber auch Kommunikationsprobleme, sich verändernde Ziele und Anforderungen auf der rechten Seite und auch schlechte Qualität der Anforderung und sogenannte Goldrandlösungen, neue Wünsche, die dazukommen, die eigentlich gar nicht dem Kerngeschäft entsprechen, die alles komplizierter und schwieriger machen. Viele von diesen Dingen, die hier aufgezählt worden sind, kann man aber sehr gut mit Requirements-Engineering angehen. Dazu gibt es noch eine schöne Anekdote, die oft in der Literatur herumgeistert, nämlich der Untergang der Vasa. Sie sehen hier hinten in dem Bild ein wundervolles Schiff. Um sich 1625 hat der König von Schweden ein Kriegsschiff in Auftrag gegeben, es sollte ein großes Kriegsschiff werden, da andere Länder auch große Kriegsschiffe bauten. Er hat dazu bekannte Schiffbauer engagiert, einen Wald angelegt. Aber weil er gesehen hat, dass die anderen Länder immer besser und immer größere Schiffe bauen, hat er ebenfalls sehr schnell die Anforderungen verändert, neue Features hinzugefügt und wie man hier in dem Bild sehr schön sieht, auch ein zweites Kanonendeck im letzten Moment gefordert, was dann auch angebaut wurde. Und Sie ahnen vielleicht, was kommt: Das Ganze konnte nicht mehr getestet werden, üblicherweise lässt man auch Matrosen von links nach rechts laufen, um das Schiff zu testen. Und es kam, wie es kommen musste, nach wenigen Stunden sank dieses Schiff, weil es überhaupt nicht mehr schwimmfähig und instabil war, wegen viel zu vieler Anforderungen. Jetzt fragt man sich natürlich und Sie könnten mal überlegen: Wer es Schuld? Und wie hätte das vermieden werden können?

Inhalt