Wir setzen fort mit dem zweiten Abschnitt. Wir sind
immer noch im Punkt 1-1, frühe Phasen.
Was ist Anforderungsmodellierung? Anforderungsanalyse. Ich habe mal hier ein nettes Comic mitgebracht,
was in verschiedenen Formen in der Welt ist und möchte ihnen
daran zeigen, was Anforderungsanalyse eigentlich ausmacht.
Ja, also es gibt so verschiedene Bildchen.
Hier können wir jetzt mal uns drüber amüsieren,
was der Anwender eigentlich wollte, also eine schnittige Limousine,
aber er hat wahrscheinlich eher betont,
es geht um die Beförderung von Personen und der Anwender
hat das verstanden
Programmierer hat vielleicht nur verstanden,
Beförderung und dachte eher an sowas und hatte aber hochfliegende Pläne,
also er wollte gern irgendsuchen, ganz schnittiges Rennauto draus bauen.
Ganz so toll waren seine Fähigkeiten dann auch nicht,
aber weiß ich, worauf ich sie besonders hinweisen möchte,
ist eigentlich, was hätte der Anwender tatsächlich gebraucht.
Wenn man jetzt mal die Gegenüberstellung zwischen dem,
was er wollte, was er gesagt hat,
was er wollte und dem, was er wirklich gebraucht hat,
sehen,
dann merken wir ja wirklich etwas über die Bedeutung dieser Phase,
Anforderungsanalyse,
warum in Softwareentwicklung
häufig als Beratung verstanden wird
Wir müssen, wie wir sind, diejenigen,
die technische Möglichkeiten kennen und manchmal bessere technische Möglichkeiten kennen,
als der Anwender im Kopf hat. Das heißt,
wir sind nicht nur der gute Auftragserfüller, der immer sagt,
jawohl, jawohl, jawohl, wir machen das so.
Natürlich können wir das. Nein, wir sollten eigene Vorschläge mitbringen,
wir sollten genauer sagen, was für Möglichkeiten bestehen,
sodass der Anwender am besten eine Lösung bekommt,
die noch besser ist.
Da ist das, was er sich vorgestellt hat.
Die Antwortungsanalyse ist selber eine eigene Disziplin und dazu gibt es eine eigene Qualifikation.
Wir haben leider keinen Studiengang hier bei uns und auch in
Lehrveranstaltungen spielt sie nur einen Teil, eine Rolle,
aber ich möchte kurz drüber sprechen,
worum es dabei geht
Wenn sie dann später vielleicht in diesem Berufsspiel zu tun haben,
werden sie auf jeden Fall noch weiteres Wissen dazu erarbeiten.
Es gibt auch Bücher dazu und sie können sich da in
diese Richtung weiter qualifizieren. Doch zunächst zu den Zielen.
Ich möchte dazu kommen zu Zielen und die nächste Folie zu
Techniken und dann zu den Ergebnissen etwas sagen.
Lassen Sie uns erst zu den Zielen etwas sagen.
Das Ziel ist zunächst, ein gleichartiges Verständnis zu erreichen.
Warum mit Stift dazu
Und ich ermutige sie einfach mitzuschreiben,
nicht nur am Bildschirmfoto zu nehmen, sondern selbst das mitzuschreiben,
die Möglichkeit dazu, sollten sie haben.
Gleicher Gleichartiges Verständnis zwischen Auftraggeber. Und Entwickler,
mit Entwickler meine ich mal alle Leute,
die eine Entwicklung beteiligt sind, nicht nur den Programmierer selber.
Und dazu gehört,
dass die Entwickler das Anwendungsgebiet kennenlernen
Also man erfährt mehr, wie funktioniert ein Bekleidungshandel,
wie funktionieren eine Bank,
wie funktioniert die Verwaltung von Immobilien oder irgend so etwas,
damit man weiß,
worauf es dabei ankommt.
Man sammelt Informationen über die Aufgabenstellung
Denn es ist ganz häufig so, dass nicht alles gesagt wird.
Klar sollte der Auftraggeber eigentlich in der Lage sein zu sagen,
was er will. Aber ganz häufig wird Selbstverständliches
nicht genannt. Oder es gibt Widersprüche in dem,
was die Leute wollen,
was die Leute sagen
Und was auch noch wichtig ist, dass man den gegenwärtigen Zustand kennenlernt.
Entwickler lernen den gegenwärtigen Zustand kennen. Wenn man das Verständnis
einfach reicht hat, wenn man das alles gesammelt hat,
dann wäre der nächste Schritt, dass man versucht,
das zu beschreiben.
Ich bezeichne das mal als Modellieren der Anforderungen
Ein Modell ist eine vereinfachte Abbildung der Realität. Das ist das Anforderungsmodell.
Auf Englisch wird das häufig als Requirement Specification bezeichnet. Specification to Specify,
ah ja, hier können Sie jetzt das,
das Bild ist nicht so ganz sehen,
da mache ich mal die, das hier ein bisschen niedriger,
Requirement Specification, Ist etwas,
was genaue Beschreibung der Anforderungen enthält.
Dabei beschreiben wir die Anforderungen, die Aufgabenstellung.
Diese Beschreibung wird später ja Vertragsbestandteil. Man bezeichnet das
auch mit den Begriffen,
Pflichtenheft und Lastenheft
Und es geht hier um einen Vertrag, das Bienchen muss
nochmal weg hier, sodass sie das besser sehen können.
Ja, gleichzeitig möchten wir den Anwender vertraut machen mit
den Möglichkeiten, wo der Komplexität einer solchen Lösung
Gleichzeitig legen wir die Nutzerschnittstelle fest, das heißt,
wie sieht das ganze Gerät aus?
Wie ist es am Ende zu bedienen?
Sind das Tasten und Leuchtdioden oder ist das ein Touchscreen oder
wie auch immer
Dazu gibt es ja auch eine sebale Disziplin,
Human Computer Interaction bei unserem Fachbereich vertreten durch eine Professur und entsprechende Lehrveranstaltung.
Was weiterhin das Ziel ist, und das ist der letzte Punkt,
den ich jetzt hier nennen möchte,
bei der Antwortungsanalyse,
das Bereitstellen der Basis für die Planung
Denn wenn wir Termine und Kosten abschätzen können,
dann sind wir in der Lage, über die Kosten,
darüber zu verhandeln, wann wird so eine Software fertig,
wie viel darf sie kosten?
Und das ist die Voraussetzung dafür,
dass man einen Vertrag zwischen Auftraggeber und Auftragnehmer schließen kann.
So, soweit zu den Zielen.
Die Frage ist, wie kann ich das erreichen?
Wie kann ich welche Techniken spielen dabei eine Rolle?
Und diese Techniken sind eigentlich relativ simpel.
Wir reden mit Menschen. Und wenn wir Informationen ermitteln wollen
, sind Fragen
am wichtigsten
Ja? Natürlich ist es ganz wichtig zuzuhören.
Nicht jeder wissen wir alle, aus unserem privaten Umfeld,
jeder kann das in gleicher Weise.
Also Zuhören ist ganz wichtig. Aber es ist auch wichtig,
dass gehörte zu strukturieren, daraus ein System zu bauen.
Wir haben den Begriff Modell ja eben schon gehabt,
um Widersprüche zu erkennen,
fehlendes zu erkennen.
Also Informationen festhalten und strukturieren
Gleichzeitig wollen wir eine Lösung haben, die nicht nur für
einen konkreten Einzelfall, sondern für noch mehr Dinge funktioniert.
Also wollen wir Verallgemeinerungen finden. Wir wollen nicht etwas bauen,
was nur für eine Abteilung funktioniert, sondern am besten für
verschiedene Industrien, damit wir das häufiger machen können.
Und dazu muss man, das kann man durchaus bezeichnen,
als Theorien bilden,
Hypothesen aufstellen
Und wir müssen, ganz wichtig ist es, diese Informationen
zu prüfen, die wir gesammelt haben, bekommen haben.
Dazu gehört zum Beispiel, sind die Informationen vollständig.
Es sind Widersprüche enthalten. Habe ich
alles korrekt verstanden
Um das zu prüfen, zum Beispiel, ist eine wichtige Technik Prototypen.
Bilden. Prototyping ermöglicht es uns, zu prüfen,
dem Aul-Anwender etwas zu zeigen, damit er sieht,
ist es das, was ich brauche.
Typischerweise gibt es hier im Englischen die Bezeichnungen, Alicitation.
Für die Erhebung der Gebung und Fragetechniken Dein Structuring.
Für Modelle bilden Modelle aufbauen, Informationen dabei vervollständigen.
Und Widersprüche entdecken
Und als drittes hier nach Estructuring noch Validation.
Das ist das Prüfen. Zum Beispiel mit einem Prototyping oder
mit einem Mock-up. Ja, wir haben auf der folgenden
Folie werden wir dazu
noch etwas sagen
Soweit zu den Techniken und nun zum Ergebnis,
das Ergebnis ist ein Anforderungsmodell.
Ein Modell ist etwas, eine vereinfachte Abbildung der Realität.
Das nur zum Begriff. Wir brauchen dazu vielleicht noch
ein Schnittstellenmodell
Was uns sagt, wie ist das Ganze,
hängt das Ganze mit der Ergebnis, mit dem Ergebnis zusammen und etwas,
was in die Dokumente für den Vertrag kommt,
zum Beispiel ein Lastenheft oder etwas.
So ähnliches für den Vertrag. Was Vertragsbestand hält. Soweit zu dem,
was dabei rauskommt, das entspricht,
das hatten wir in einer der Fragen hier,
muss ich ein bisschen zurückgeben,
also ziehe die Frage zwei Ziele und Techniken der Antwortungsanalyse.
Das hatten wir hier dabei
Für diese Anforderungsbeschreibung gibt es, ich bringe mal wieder dorthin
zurück, wo wir eben waren. Gibt es die,
wollen wir ein Modell entstehen lassen und dieses Modell,
ich hatte eben den Begriff Theoriebildung genannt und da möchte ich den Autor Fairbanks mal zitieren,
der das Wort Theoriebildung dafür geprägt hat.
Das klingt erstmal ein bisschen abstrakter, aber ich denke,
wenn ich Ihnen das erkläre, verstehen Sie,
warum brauchen wir das?
Und zwar brauchen wir das,
um möglichst verallgemeinerte Lösungen zu bilden.
Wir wollen
grundlegende Konzepte erkennen
Diese grundlegenden Konzepte erkennen und natürlich auch benennen.
Diese grundlegenden Konzepte helfen uns, grundlegende Lösungen zu bauen,
die stabil sind über längere Zeit. Das sind zum Beispiel
, dass wir erkennen, welche Werkzeuge werden gebraucht.
Was sind Materialien? Sie kennen diese Begriffe Werkzeuge und Materialien
aus SE1 und SE2. Nimm diesen grundlegenden Konzepten,
brauchen wir auch
gemeinsame Konzepte
Diese gemeinsamen Konzepte ermöglichen es uns von mehreren Leuten gut verstanden zu werden.
Das ist zum Beispiel, würden wir vermeiden,
dass die unterschiedliche Wahrnehmung zu unterschiedlichen Lösungen führt.
Leute haben nun mal eine unterschiedliche Wahrnehmung.
Unterschiedliche Wahrnehmung oder die Leute
haben unterschiedliche Vorkenntnisse
Um das zu überbrücken, macht es notwendig, dass man
verallgemeinerte Konzepte hat. Und diese Verallgemeinungen ermöglichen es auch,
zukünftige Veränderungen zu vorherzusehen oder zu vereinfachen.
Denn es kann keiner die Zukunft vorhersehen.
Also niemand weiß, was morgen kommt.
Keiner hat die magische Glaskugel
Soweit das zu dem Punkt,
den ich hier mit Modellierung und Theorie eben noch genannt hatte.
Doch nun möchte ich dazu kommen, was muss ich denn
an einer Anforderungsbeschreibung prüfen? Wann ist so eine Anforderungsbeschreibung gut?
Also wir hatten ja das Ergebnis, Anforderungsmodell, Schnittstellenmodell.
Und ich habe hier mal ein paar Punkte zusammengestellt,
die dazu, die aufgehören, typischerweise genannt werden,
wenn es um die Prüfung einer Anforderungsbeschreibung geht.
Lass uns uns dazu kurz etwas überlegen.
Eindeutigkeit, das klingt erstmal wunderbar und sehr schön.
Wir möchten gern, dass das, was wir gesagt haben
, eindeutig ist
Eindeutig meint, das Geschriebene, das Ausgedrückte,
erlaubt nur eine einzige Interpretation. Vollständig,
wir haben wirklich alle Informationen erfasst, wir wissen es komplett,
haben die Beschreibung komplett und können das jemand anderen geben,
da kann das komplett danach bauen.
Überprüfbarkeit meint, dass wir das nicht nur ein bisschen sagen,
sondern von wegen, das System soll schnell sein,
sondern das System soll, wie schnell soll das System sein?
Also hier, Anforderungen zum Beispiel,
quantifiziert,
durch Zahlen ausgedrückt
Widerspruchsfrei, das ist eine Forderung,
die ganz schwierig ist, wenn wir große Systeme haben.
Große Systeme haben häufig ganz viele Anforderungen, wenn sie sich vorstellen,
der Bordcomputer eines Airbus oder sowas, da sind,
wenn man es ausdrucken würde, mehrere Aktenordner voll Papier.
Und wenn das alles natürliche Sprache ist, ist es sehr schwierig darin,
Widersprüche zu finden. Die Widersprüche sind auf jeden Fall drin.
Wir müssen nur versuchen, sie zu finden. Verständlichkeit ist ein weiterer,
wichtiger Punkt, benutzen wir die Worte des Auftraggebers,
versteht man das alles, das mit der Herkunft ist deswegen wichtig, um Konflikte zu erkennen.
Also die Konflikte, die kann man meistens dadurch auflösen,
dass man sagt, okay, das eine hat der gesagt,
das andere hat der gesagt, wie kann ich denn das Besser rauskriegen und das wäre hier die Verfolgbarkeit.
Das steht hier unten nochmal, kommt das nochmal als Punkt. Ja,
weitere, weitere wichtige Punkte sind hier Flexibilität,
ist das Ganze möglichst unabhängig,
kann ich damit von konkreten Implementierungen abstrahieren,
sind die Risiken klar,
lässt sich das überhaupt realisieren,
das ist eine ganz wichtige Sache,
wir können ja nicht als Firma etwas in Auftrag nehmen oder
am Ende stellen wir uns nach einem halben Jahr Entwicklung,
sagen wir mal,
es geht leider nicht,
dann müssen wir
wahrscheinlich Vertragsstrafe zahlen
Und Angemessenheit bezeichnet dieser Begriff Angemessenheit, zeigt,
ist die Lösung denn passend für das, was der Anwender überhaupt will.
Damit haben wir eine ganze umfangreiche Liste und die wichtigsten Punkte möchte ich mal unterstreichen,
die wichtigsten Punkte sind hier die ersten, die ich wirklich,
die auch schon schwierig genug zu erfüllen sind.
Damit man das vollständig auch hinbekommt, arbeitet man häufig mit Anachso,
vielleicht sollte ich kurz sagen, das gibt dir eine Frage dazu.
Die Frage war, hier volle, das war die Frage.
Drei nennen Sie Kriterien für die Prüfung einer Anforderungsbeschreibung.
Das war das, was wir jetzt eben gerade hatten.
Und ich möchte Ihnen als Beispiel noch zeigen, wie so
eine Textbeschreibung aussieht. Dieses bouläre, was sich hier,
was ich hier angebe, ist ein kommerzielles Produkt.
Da kann man eine Mustergliederung und noch viele weitere Dokumente kaufen.
Und diese Gliederung hilft uns eigentlich, nichts zu vergessen,
eine vollständige Beschreibung zu machen. Ist schon relativ klar,
dass es darum geht, was man,
wenn wir in der Punkt 13 angucken,
was sollen für Operationen durchgeführt werden
Das ist relativ klar. Oder von Punkt 9, Funktionen
und Daten. Das würde man auf jeden Fall aufschreiben.
Aber würde man denn auch aufschreiben, wer sind die Benutzer?
Was ist der Zweck des Produktes oder Scope? Wie weit
, was gehört alles dazu? Scope of the work.
Oder was sind die Risiken? Was sind neue Probleme?
Nummer 19, was für Lösungen existieren schon bei Trippen?
Also solche Sachen, was sind Sicherheitsanforderungen?
Viele von diesen Sachen würden nicht abgefragt, wird nicht genannt.
Und deswegen hilft uns, eine Mustergliederung wie diese,
das ist für ein Lastenheft,
hilft uns sehr,
dafür eine korrekte Beschreibung aufzustellen
Damit beenden wir diesen Abschnitt und weiter
geht es dann mit der Anforderungsbeschreibung mit UML