Herzlich Willkommen zum finalen Part unserer Blog-Serie Requirements-Engineering für Einsteiger. Zum Abschluss erzählen unsere jungen SOPHISTen Melissa Müller und Sarid Menzel von ihren ersten Schritten aus ihrer Projektwelt. Wir haben unsere beiden Einsteiger interviewt und stellen Ihnen im Folgenden die Fragen und Antworten vor.

     
Melissa Müller            Sarid Menzel

Was war euer erstes Projekt?

Melissa: Mein erstes Projekt war zusammen mit Sarid bei einem großen Versicherungsunternehmen. Wir haben als Assistenten eines Kollegen im „Homeoffice“, also von hier aus bei uns in der Firma in Nürnberg, ein Versicherungsbeispiel erarbeitet. Außerdem war ich am Leitfaden für die Business-Analyse beteiligt, der in diesem Projekt erstellt wurde.

Sarid: Mein erstes Projekt hatte ich bei einem großen deutschen Automobilhersteller in Deutschland. Meine Kollegin und ich waren beim Kunden vor Ort und haben im Rahmen eines Kick-Off-Meetings die Erwartungen, Ziele und Vorgehensmethoden besprochen und definiert.

Welche Methoden habt ihr in diesen Projekten hauptsächlich eingesetzt?

Melissa: Das waren vorwiegend natürlichsprachliche Dokumentation in MS Word, außerdem UML Modellierung in EA und die Erstellung eines Prototyps mit MS Powerpoint.
Zur natürlichsprachlichen Dokumentation haben wir die SOPHIST-Satzschablone und das SOPHIST-REgelwerk eingesetzt.

Sarid: Wir sind nach der Use-Case-Analyse vorgegangen und haben beim Dokumentieren der Anforderungen das Requirements-Template, also die SOPHIST-Satzschablone, zu Hilfe genommen. Mittels Interviews und Workshops kamen wir an das benötigte Wissen heran und mit Hilfe des SOPHIST-REgelwerks haben wir die Qualität der Anforderungen sichergestellt.

Melissa du hast erwähnt, dass ihr UML-Modellierung eingesetzt habt. Wie waren da eure Erfahrungen? Musstet ihr dafür viel Neues lernen?

Sarid: Melissa und ich konnten UML im Rahmen eines gemeinsamen Projekts praktisch anwenden. Mit Hilfe von UML ist es möglich, komplizierte technische Abläufe mit verschiedenen Diagrammen vereinfacht darzustellen. Dementsprechend braucht es aber auch gewisse Vorkenntnisse, um mit UML umgehen zu können. Daher haben wir Schulungen und Workshops besucht und dabei viel Input zum Modellieren bekommen. Die Schwierigkeit lag vor allem in der Gesamtheit der Darstellungsmöglichkeiten – man kann z.B. Aktivitätsdiagramme oder Sequenzdiagramme modellieren, und jedes Diagramm beinhaltet andere Notationselemente, deren Syntax und Verwendung man erst verstehen und lernen muss.

Melissa: In unserem Projekt ging es beispielsweise darum, die Abläufe in einer Versicherungs-App darzustellen. Dafür haben wir unter anderem Use-Case Diagramme und Klassendiagramme modelliert. Gearbeitet haben wir in unserem Projekt mit dem UML-Tool „Enterprise Architect“- aber die Grenzen dessen, was mit diesem Tool möglich ist, haben wir noch lange nicht ausgeschöpft.

Das Gute an einer Firma wie SOPHIST ist, dass es immer hilfsbereite Kollegen gibt, die einem mit ihrer Erfahrung einen guten Rat oder gute Tipps geben können.

Was waren das für Tipps?

Melissa: Unter anderem, wie man die Anforderungen „richtig“ gliedert. Mit gezieltem Sortieren fällt einem das Modellieren schon um einiges leichter. Wir hätten sonst einfach drauf los modelliert und die Dokumentenstruktur in EA neigt dazu, schnell unübersichtlich zu werden.

Wie seid ihr an eure Anforderungen gekommen? Gab es bestimmte Ermittlungs-Methoden, die von euch eingesetzt wurden?

Melissa: Wir sollten Anforderungen für eine Versicherungs-App schreiben und daraus ein Übungsbeispiel für künftige Trainings-/Workshop-Teilnehmer, erstellen. Um uns die Arbeit zu erleichtern, haben wir einen Prototyp in Powerpoint erstellt, in welchem wir über Hyperlinks den Screenflow einer App realistisch, und auch visuell, nachstellen konnten. Auf diese Weise fielen recht bald auch so simple Anforderungen heraus, wie beispielsweise ein „Logout“-Button oder der „Zurück“-Button auf jeder Seite. Das sind zwei selbstverständliche Anforderungen, die man bei reiner Prosa leicht vergisst. Für solche Anforderungen ist ein Prototyp sehr zu empfehlen.
Sarid: In meinem ersten Projekt gab es da noch die Systemarchäologie. Das heißt wir haben vorhandene Unterlagen über das Altsystem gesichtet und bewertet. Einiges davon konnten wir noch verwenden, aber vieles war auch schon veraltet.

Wie seid ihr mit den neuen Herausforderungen und Aufgaben zu Recht gekommen?

Melissa: Anfangs etwas holprig, doch nach und nach bekommt man ein Gefühl für die Methoden und Dokumente im Projekt und arbeitet fast automatisch damit. Wie etwa mit der Satzschablone. Zu Beginn klang das ziemlich komisch, jeden Satz im gleichen Schema zu formulieren, und der Deutschlehrer aus der Schule ruft im Hinterkopf ständig rein: „Abwechslung! Abwechslung! Nicht immer die gleichen Wörter verwenden!“

Sehr hilfreich sind natürlich unsere netten Kollegen, die einem für alle Fragen zur Verfügung stehen und ehrliche Reviews geben. Und mit jeder Review-Schleife lernt man ein wenig mehr dazu.

Sarid: Mir ging es zu Anfang ebenso. Aber mit der Zeit lernt man worauf man achten muss. Mittlerweile fällt es mir sogar schwer, Anforderungen nicht nach Template zu schreiben oder nicht automatisch zu hinterfragen (siehe SOPHIST-REgelwerk).

Gab es etwas, das euch besonders schwer fiel?

Melissa: Generell ist der Einstieg in ein neues Projekt immer eine große Herausforderung, da man sich mit vielen neuen Menschen und Methoden konfrontiert sieht. Doch es macht auch Spaß, sich immer wieder in neue Themengebiete einzuarbeiten und auf viele verschiedene Menschen zu treffen. Und man lernt jedes Mal ein wenig mehr dazu.

Aus dem methodischen Blickwinkel fiel mir UML am schwersten, da im Zusammenhang mit EA viel Neues auf einen einströmt.
Wir haben ein beispielsweise ein Begriffsmodell erstellt, in dem mit Multiplizitäten gearbeitet wird. Der Eine oder andere stolpert beim Lesen vielleicht über den Begriff. Seien Sie unbesorgt, mir ging es genauso. Multiplizitäten sind kleine Zahlen, die an den Verbindungen zwischen zwei Begriffen stehen und angeben, für wie viele Einheiten dieses Begriffs die Verbindung gelten kann. Das zu verstehen und richtig anzuwenden fiel mir anfangs nicht leicht.

Sarid: Für mich ist immer der Anfang am schwierigsten. Sei es im Projekt oder auch wenn es nur darum geht, einen Projektbericht oder einen Abstract (eine Art Kurzreferat über ein bestimmtes Thema) zu schreiben. In der Regel ist jedes Projekt anders als das vorherige. Andere Methoden, andere Menschen, ein anderer Projektleiter etc. Aber genau das finde ich an der Arbeit eines Requirements-Engineers auch so spannend. Man hat mit vielen (neuen) Menschen zu tun und man kann sehr viel dazu lernen.

Vielen Dank für dieses aufschlussreiche Interview an unsere beiden „Einsteiger“.

Wenn Sie noch mehr über unsere Berater oder zahlreiche Angebote rund um Requirements-Engineering erfahren möchten, können Sie weitere Informationen auf unserer Homepage nachlesen.

Wir hoffen, Ihnen hat der Ausflug in die Welt des Requirements-Engineering gefallen und wünschen viel Erfolg und Spaß beim Sammeln eigener Erfahrungen!

Ihre SOPHISTen

—————————