Willkommen zurück zu Software Engineering und heute wollen wir uns weiter über das Thema

Requirements Engineering, also Requirements Management unterhalten und wir wollen uns

insbesondere jetzt, nachdem wir in der ersten Einheit uns besonders angeguckt hat, wie man

überhaupt an Requirements kommt, wie ich quasi hergehen kann, um die zu ermitteln und wozu wir

sie brauchen, welche Arten von Requirements es gibt, wollen wir heute fortsetzen und uns

ansehen, was jetzt mit diesen Requirements passiert. Wie komme ich zu konsistenten

Requirements, also wie kriege ich quasi die Anforderungen so zusammengesetzt, dass ich

nachher damit auch was Sinnvolles tun kann und zum Beispiel feststellen, ob sie überhaupt

eingehalten wurden. Okay, das bringt uns zu den heutigen Themen, also wir werden uns mit der

Spezifikation von Requirements zuerst beschäftigen. Das ist letzten Endes, wie ich aus den Ideen,

aus den Anforderungen, die ich quasi jetzt schon ermittelt habe, wie ich wirklich eine formale

Dokumentation davon bekomme und wie man sich das Ganze am besten von der Vorgehensweise her

ansieht. Also letzten Endes wollen wir jetzt aus den Ideen, aus den Ideensammlungen, die wir bisher

haben, die noch auf einer relativ groben Ebene waren, dafür sorgen, dass wir jetzt eine Menge

von Anforderungen haben, die auch miteinander funktionieren. Und das Ganze ist eben so, als

würden wir alles von Anfang an planen, wir haben einen festen Anforderungskatalog, der ist konsistent

und dann muss der entsprechend umgesetzt werden. Als Alternative dazu werden wir uns die agile

Version davon angucken und das ist quasi genau das Gegenteil von dem, dass wir nicht alles bis

ins Detail schon am Anfang durchplanen, sondern eben Anforderungen immer wieder nachschärfen und die

Anforderungen quasi durch weitere Informationen verbessern, wie wir es schon in der agilen

Softwareentwicklung hatten, kann man auch das Requirements Engineering agil machen, also das ist

dann wieder so ein bisschen wie eine offene Welt, wenn man sich anguckt, dass man quasi die Ideen

sammelt, die Anforderungen nachschärft und dann auch verbesserte Anforderungen kommt. Also ein bisschen

so, wie vielleicht so ein Indie Game Studio vorgehen würde, dass man sehr sehr intensiv mit

seinen Spielern, mit seinen Testern, mit seinen Kunden zusammenarbeitet und dann versucht das nach

und nach nachzuschärfen. Und man muss natürlich auch aufpassen, dass es nicht zu agil wird, weil

wenn es zu agil ist, kann es mir passieren, dass ich am Ende nur im Chaos stehe und plötzlich

nichts mehr zusammenpasst. Also das wäre natürlich schlecht, aber dafür braucht man agile Vorgehensweisen,

um da quasi den Überblick nicht zu verlieren. Und dann ist der nächste Schritt quasi, dass wir

diese Anforderungen validieren wollen, das heißt wir wollen feststellen, ob das ganze auch so passt,

ob die Anforderungen zusammenpassen, ob sie prüfbar sind und dass wir am Ende auch wirklich ein

konsistentes Set an Anforderungen haben und man quasi nicht irgendwelche Konflikte vergisst oder

Anforderungen haben, die sich widersprechen. Das wäre also ein Riesenproblem und das wollen wir

eben vermeiden. Dann könnte man sagen, na gut, wenn die Anforderungen validiert sind, könnte man ja

meinen, man ist fertig, man macht jetzt einfach die Produktentwicklung und dann ist alles gut,

aber häufig, gerade bei erfolgreichen Produkten, ist es so, dass diese sich ständig weiterentwickeln.

Wenn man sich zum Beispiel überlegt, wie Minecraft vor zehn Jahren ausgesehen hat und wie Minecraft

heute aussieht, hat sich doch einiges verändert, einiges ist natürlich bleichgeblieben, aber

erfolgreiche Dinge müssen eben ständig nachgeschafft werden und da kann es halt dann auch einfach sein,

dass entsprechend neue Dinge auftauchen müssen, die Benutzung sich ändert und man deswegen quasi

auch Anforderungen aufgibt und neue Anforderungen einfügt und das ist hier eben der Prozess der

Anforderungsevolution und das begleitet quasi ein Produkt oder ein beispielsweise ein Computerspiel

so lange, bis eben der Service eingestellt wird, bis es nicht mehr vertrieben wird,

bis es keinen Support mehr gibt, aber so lange könnte man auch noch an den Anforderungen weiterdrehen.

Sehr gut, dann fangen wir an mit der Spezifikation und wir rufen uns nochmal unseren ganzen

Anforderungsmanagementprozess ins Gedächtnis, wie das Ganze laufen soll und wir hatten jetzt

quasi zunächst uns gesagt, ja, also wir schauen uns mit der Ermittlung von Anforderungen an,

das ist das Links oben und kommen dann langsam in Systembeschreibung und jetzt sind wir quasi

an dem Punkt, wo wir schon ganz viele Anforderungen ermittelt haben und die wollen wir jetzt

spezifizieren, das heißt wir wollen die konkret realisieren, aufschreiben, dokumentieren so,