Im ersten Abschnitt des Kapitels 4 besprechen wir über Requirements Engineering
insgesamt und bevor wir zu den anderen Abschnitten,
wo es um Modellierung geht, kommen.
Wenn Sie also über Requirements Engineering schon genügend Bescheid wissen aus
früheren Lehrveranstaltungen, können Sie den Rest dieses Videos überspringen.
Sie sollten allerdings in der Lage sein,
zu die Fragen 1 und 2 zu beantworten,
um die es hier geht.
Wenn Sie doch nicht sicher sind, bleiben Sie gern dabei.
Ansonsten springen Sie einfach zum nächsten Video
Kommen. Wir beginnen damit zu sagen, worum geht es bei Requirements Engineering?
Ich fange mal an mit einer Definition, diese Definition,
ITrible E ist IIE, ist eine amerikanische Ingenieurgesellschaft,
die durchaus die Ansprache hebt, international tätig zu sein.
Es gibt auch eine deutsche, einen deutschen Zweig davon,
ein paralleler Gesellschaft ist ECM Association of Computing Machinary.
Sie haben eine Definition herausgebracht, worum es bei Requirements Engineering geht.
Zunächst ist es, bezeichnen Sie das als eine als einen Teil des Systems Engineering.
Systems Engineering, da geht es darum, bei Systeme zu entwickeln,
mit den ingenieurmäßigen Methoden, um herauszubekommen, Manage heißt Steuern,
ja, die gewünschten Eigenschaften von softwareintensiven Systemen.
Dieser Begriff softwareintensive Systeme, dabei geht es um eingebettete Systeme,
die einen wesentlichen Teil ihrer Funktion aus Software beziehen,
also zum Beispiel eine Maschine,
eine Werkzeugmaschine,
die etwas fertigt,
die durchaus intern durch Software weitgehend gesteuert wird und nicht durch
zum Beispiel Engetriebe oder nur durch
vorrangig durch elektrischen Antrieb
Ja, und es geht darum, die Ziele,
die man erreichen möchte, und zwar in der Umgebung.
So, sie beschäftigt sich damit,
von der Problemanalyse bis zur Implementierung und Wartungsstufe. Ja,
also die ganze, durch die Phase heißt die Stufe.
Also durch die, durch alle Phasen zieht sich das,
wie man mit Anforderungen umgeht. Es geht darum,
dass man Unterschiede besteht, bezieht für verschiedene Anwendungsgebiete,
ja,
also die werden jetzt ja nochmal genannt
Das eigentliche Problem hierbei ist das Verstehen.
Und dazu habe ich mal hier einen Comic mitgebracht.
Den gibt es in ganz verschiedenen Ausführungen. Ja,
also wir gehen mal davon aus, das ist das,
was der Anwender wollte, aber er hat es ein bisschen anders gesagt.
Zum Beispiel hat er gesagt, okay,
es geht ein Fahrzeug für die Straße zur Befürderung von Personen.
Ja, und er hat gedacht, okay,
er hat ja einen Bus gedacht.
Also er wäre auch verständlich geworden von seinen Worten.
Aber der Programmierer hat vor allen Dingen von Transport auf der Straße
verstanden. Er wollte etwas super Tolles bauen,
dass er das nicht ganz konnte
Lag vielleicht an seinen begrenzten Fähigkeiten, da könnte man sich über die beiden,
die Unterschiede dieser beiden Bilder ein bisschen den Kopf machen,
aber eigentlich möchte ich sie darauf hinweisen, auf das Bild,
auf den Unterschied zwischen dem Ersten und dem Letzten.
Ja, also das, was der Anwender ursprünglich gebraucht hätte,
ist doch ein bisschen was anderes als das, was er selbst im Kopf hat. Es geht also,
hier geht es um die Rolle des Softwareentwicklers als Dienstleister,
Dienstleister nicht im Sinne wie so ein Diener, der alles,
seine Herrschaft, alles vom Mund abliest und sagt,
jawohl, jawohl, jawohl, sondern ist durchaus jemand,
der mit eigenen Vorschlägen können, weil wir kennen die Technologien,
wir kennen die Möglichkeiten können dann vielleicht Vorschläge machen,
die über das noch deutlich hinausgehen und die Ziele noch besser verstehen,
wenn die der Anwender möchte.
Es geht also ganz stark um Kommunikation und um Verstehen und Beraten,
also wirklich Lösungen vorschlagen,
dass die anderen Sachen vielleicht nicht ganz so gut gelaufen sind,
wollen wir mal auch noch besser darstellen.
Ja, also die, und dieses Kommunizieren ist tatsächlich
beim Requirement Engineering als separaten Zweig ein ganz wesentlicher Punkt.
Das nächste Bild zeigt hier, Das stammt aus der Enzyklopie.
Wirtschaftsinformatik, also auch einem Wörterbuch, wo man etwas Definitionen findet.
Und das hat manche Unterschiede zu der IT-BI-Definition.
Also hier geht es um das Ermitteln, Analysieren,
Spezifizieren, Validieren von Eigenschaften und Rahmenbedingungen,
die in dem gesamten Lebenszyklus gewünscht sind, relevant sind.
Also diese verschiedenen Phasen des Lebenszyklus hatten wir vorhin auch.
Hier sind diese Phasen nochmal genannt. Und das sind die,
auf die wir mit der ersten Frage eingehen wollen.
Ja, ich schaue nochmal kurz auf die erste Frage
Wie wir hier haben, welche Ziele werden dabei verfolgt.
Springen wir mal zurück und schauen mal,
was diese Ziele alle sind,
welche Ziele wir hier nehmen können und fügen,
ich nehme hier eine neue Seite,
wie muss ich hier einfügen,
eine leere Seite,
Querformat und wir wollen jetzt
hier über die Ziele sprechen
Wir fangen an mit dem Ermitteln.
Also wir sind beim Beantworten der ersten Frage.
Diese Frage ermitteln, da geht es um das Verstehen.
Wir wollen ein gleichartiges Verständnis erzielen. Zwischenauftraggebern und Entwickler Entwickler
etwas breiter gefasst, das geht von allen Leuten von,
die in dem Softwareentwicklungsunternehmen arbeiten, sind da mit einbezogen.
Also auch die, die fachlich ein Gebiet strukturieren,
die das Projekt leiten, bis da zu denen,
die dem am Ende das Programmieren.
Und zwar über Informationen, über die Aufgabenstellung.
Das ist sicherlich der Kern.
Was soll gebaut werden
Ja, da gehört es auch dazu,
dass wir selbstverständliches erfragen und erfahren, was man vielleicht,
was der Auftraggeber sonst eigentlich gar nicht sagen würde,
weil er es für selbstverständlich hält oder auch widersprüchliches.
So, dann geht es darum,
dass wir den gegenwärtigen Zustand kennenlernen
Zum Beispiel in Form eines, wenn es um ein Informationssystem geht,
welche was einem betrieblichen Prozess steuert,
was für Abläufe gibt es dort,
was für Funktionen werden ausgeführt.
Abläufe, Rollen von Beteiligten,
von bedienten Personen,
Dann gehört es durchaus noch dazu, Informationen über das Anwendungsgebiet.
Das sind auch Informationen, die darüber über das eigentliche System hinausgehen.
Zum Beispiel Qualitätsanforderungen. Wenn wir ein System haben,
was den Schienenverkehr steuert, was dort für Anforderungen an Abnahmen,
Riesig, Ausschluss von Risiken gemeint sind,
wie Systeme für fliegende Gerätschaften wie ein Airbus oder so etwas,
wie die gesteuert wird, wie die abgenommen werden,
was für Erwartungen gemacht werden an die Häufigkeit von Änderungen,
für ein Webshop-System.
Ja, also diese Sachen, die man grundsätzlich in der Domäne annimmt,
die sind, sollen hier alle gemeint werden.
Sollen hier kennengelernt werden. So, damit,
das ist beim Ermitteln der Fall. Ja, so,
das ist so umfasst die Ziele,
die wir hier beim Ermitteln brauchen
Beim Analysieren geht es darum, dass wir verstehen,
prüfen, ob die ganzen Sachen denn vollständig sind.
Dann braucht man wieder einen Stift.
Vollständigkeit, Widerspruchs,
Freiheit prüfen
Prüfen, soll das heißen. Ja, das sind Tätigkeiten,
die wir hier, die wir hier haben,
dann würde ich mal fortsetzen mit Spezifizieren,
to Specify heißt etwas genau beschreiben.
Also wir wollen dort
weitere Details erfassen.
Detaillierte Informationen ergänzen
Zum Beispiel das Verhalten im Fehlerfall, werden wir hier vorne Funktionen,
Abläufe grundsätzlich dargestellt haben, fragen wir jetzt genauer nach.
Ja, wenn der und der Fehlerfall eintritt, was tun wir
denn dann? Wie soll denn die Datenstrukturen genau aussehen?
Was sind die Grenzen von Wertebereichen? Das sind,
ich gebe dir das als Beispiel nur an, Verhalten im Fehlerfall, Wertebereiche
Das sollte man noch lesen können, machen wir doch mal.
Wertebereiche von Parametern. Ui, graphical, graphical user interface
, also visuell die Benutzerschnittstelle aussehen. Ja,
und dann haben wir hier noch einen weiteren Schritt,
validieren, das ist eigentlich Abgleich,
ob das mit dem Anwendervorstellungen übereinstimmt
Vorstellung, das bleiben wir bei dem Begriff Auftraggebers.
Und als Beispiel gebe ich ihr an,
dass wir das Mittel über eines Prototypen machen kann.
Häufig ist das der Prototyp erst das Mittel,
was dem Anwender zeigt,
ob er seine Vorstellungen denn verstanden worden sind
Ja, es wird also zum Beispiel ein Petri-Netz,
würde das sicherlich das Verhalten wunderbar abbilden.
Dummerweise, vielleicht versteht der Eintraggeber das Petri-Netz nicht.
Also deswegen, man muss es eben in einer Form zeigen,
wo Darstellung gut möglich ist. Soweit die Ziele,
die wir hier auf diesem Diagramm haben, und das werden dann gleichzeitig,
wir gehen zu den Fragen zurück, die Antwort zu Frage 1.
Ich möchte als weitere Verdeutlichung,
jetzt kommen wir zu der Frage,
2 hier mit frühen Entscheidungen, möchte ich deutlich machen,
dass in dieser Phase Requirements Engineering
eine ganze Menge tatsächlich Entscheidungen getan haben
Ja, wir haben jetzt hier in diesem Bildchen eigentlich nur gesagt,
ja, wir müssen eigentlich rausbekommen, was der Anwender wirklich braucht.
Das heißt, wir müssen ihm eine Lösung vorschlagen und dabei
strukturieren wir eine Lösung, dabei gestalten wir durchaus die Lösung.
Und das möchte ich gern mit einem weiteren Bild darstellen.
Wir brauchen hier nochmal eine leere Seite.
Die kommt hier und ich nenne das Gewicht früher Entscheidungen
Dazu male ich mal ein Diagramm auf der senkrechten Achse,
haben wir das Gewicht, eine Entscheidung oder umgekehrt könne man
es auch formulieren als Risiko eine Entscheidung und hier haben wir die Entwicklungsschritte.
Ich will nicht von Phasen sprechen,
weil sie sonst vielleicht ein Wasserfallmodell denken, ihr Rechtsschreiben wir da noch,
kommen dann gleich noch ein paar Punkte hin und ich starte mal mit der Idee,
Dann mit der Spezifikation, dann haben wir den Entwurf,
ich quetsche das ein bisschen, dass wir insgesamt hinpassen hier,
das kann man doch schöner schreiben, trotz quetschen und Ruf,
dann haben wir hier die Implementierung.
Sie können es gerne als Kudierung auch verstehen, dann haben wir hier die Integration
Dann haben wir die Inbetriebnahme. Und dann haben wir den Betrieb.
Der setzt sich natürlich hier entsprechend fort. So,
die Idee könnte man durchaus sagen, dass man überlegt sich,
was man eigentlich bauen will, wenn wir Geschäftsprozesse macht,
dann wäre das das Business Process Reengineering oder Business Process Engineering.
Wenn wir dort entscheiden, wir wollen ein System haben,
um unsere Lager besser zu verwalten,
zügig Lagerdauer oder Ausnutzung oder Zugriffszeiten oder was auch immer,
dann können wir sagen, okay, diese Idee,
die entscheidet über ganz viel des Rests.
Ja, und wenn wir dann die Spezifikation aufstellen,
Spezifikation heißt, habe ich schon gerade gesagt,
die genaue Beschreibung dessen, was wir dort machen wollen,
dann bewegt die sich im Rahmen der Dinge, die wir machen.
Aber wenn wir entscheiden,
zum Beispiel das Fehlerverhalten sieht so aus oder die Nutzerschnittstelle sieht so aus,
dann ist das zwar noch im Rahmen der Idee,
aber halt großen Einfluss darauf, wie das System insgesamt ist.
Das heißt, auch hier haben wir ein rittes Sternchen für
dieses Gewicht einer solchen Entscheidung
Verzeihung relativ hoch. Wenn wir dann das System entwerfen,
das wäre also,
dass die Arbeit zum Beispiel des Architekten oder eines Entwicklers,
der das Konzept dann macht, dann setzt er das um.
Aber er trifft auch noch ganz wesentlich Entscheidungen.
Zum Beispiel, welche Technologie nehme ich für die Nutzerschnittstelle?
Wie organisiere ich den Datenbankzugriff? Aber die grundlegenden Entscheidungen über
die Abläufe sind ja durch die Spezifikation getroffen. Das heißt,
seien das Gewicht einer Entscheidung, die er trifft,
ist auf jeden Fall geniedrig. Wenn wir damit sagen,
das sind die Entscheidungen schon alle getroffen,
dann ist das weit gefehlt,
weil auch wenn der Implementierung treffe ich noch ganz wichtige Entscheidungen,
am Ende ist das wie das System vom Zeitverhalten
her ist
Wie es von der Sicherheit her ist, wo du sowas,
die ganzen Realisierungen treffen, finden dabei immer statt.
Das heißt, auch hier haben wir Gewichtentscheidungen von einigermaßen Gewicht.
Auch wenn wir dabei denken, damit ist alles fertig. Nein,
auch beim Zusammenbauen, beim Integrieren des Systems mit anderen,
zum Beispiel auch, indem wir Trittprodukte anbinden,
indem wir Schnittstellen gestalten, treffen wir noch Entscheidungen,
die sich auf Eigenschaften des Systems auswirken,
aber eben deutlich mit deutlich weniger Gewicht.
Während er in Betriebnahme selbst, da konvertieren wir Daten,
wir installieren das System, weißen Speicher zu, entscheiden,
auf welcher Plattform was läuft.
Auch dort haben wir noch Entscheidungen, die das Gesamtverhalten betreffen.
So, und während des Betriebs entscheiden wir auch noch
über die Performance, über die Leistungsfähigkeit des Systems.
Also auch hier gibt es noch Entscheidungen mit einigermaßen Gewicht. So,
wenn wir das jetzt mal verbinden, ich mache das mal hier mit,
mit einer Farbe, ja, dann könnte es durchaus sein,
dass wir irgend so eine Kurve rausbekommen.
Mit abnehmendem Gewicht, aber die frühesten frühen Phasen sind sehr stark.
Und was ich jetzt, warum ich das zeige, ist,
weil für viele gerade Leute mit Entwicklerperspektive und hier modellbasierte Softwareentwicklung,
da geht es sehr stark um eine technische Ausrichtung.
Die sehen doch vor allen Dingen, ja, okay,
ich bin Entwickler und ich treffe solche Entscheidungen.
Oder ich bin vielleicht Entwerfer, Architekt und treffe solche Entscheidungen.
Aber ich möchte damit verdeutlichen, solche Entscheidungen,
die vorher getroffen werden, haben ein viel größeres Gewicht.
Und nun ist die Frage, warum haben Sie das Gewicht?
Das möchte ich kurz noch mit Ihnen zusammenstellen.
Diese grundlegenden Entscheidungen Die frühen Entscheidungen sind grundlegend Entscheidungen.
Früh heißt früh im Entwicklungszyklus, dass wir oft für Zeit,
wo Uhrzeiten zutrifft, ist noch eine andere Sache.
Da sind grundlegende Entscheidungen. Grundlegend bedeutet, dass sie den
Entscheidungsspielraum eingrenzen
Für alle nachfolgenden Entscheidungen. Ja, das ist der eine Punkt,
der dazu führt, dass die ersten das größte Gewicht haben.
Ein zweiter Punkt, den ich nennen möchte, ist,
dass wir mit den Volkerarbeiten immer auf den früheren Entscheidungen basieren,
eingehen und dass es doch dazu führt, wenn wir spätere entscheiden,
wenn wir diese frühen Entscheidungen mal revidieren würden,
müsste alle Arbeit,
die danach kommt,
nochmal gemacht werden oder
jedenfalls angepasst werden
Spätere Entscheidungen und Entwicklungen basieren auf den früheren Entscheidungen, auf den frühen Entscheidungen und deswegen
Änderungen wird einen hohen Aufwand erfordern. Eben weil alles
nochmal angefasst werden muss, was danach gemacht worden ist,
was da für eine Rolle dabei spielt.
Soweit die Antwort auf die erste und zweite Frage.
Wo waren die nochmal hier? Ja, also wir haben jetzt
kurz etwas zu diesen Phasen gesagt und zum Gewicht einer Entscheidung.
Damit sind wir im Moment sind wir hier.
Damit hätten wir den ersten Punkt schon kurz abgehandelt,
um eine Einführung zu geben