Modellierung von Benutzungsoberflächen
Klassendiagramme sind ein zentraler Bestandteil der UML und deren Einsatz im Requirements Engineering weit verbreitet. Zumeist werden Klassendiagramme genutzt, um die Struktur eines Systems zu verdeutlichen. Dabei werden Klassen mit deren Attributen in Beziehung zueinander gesetzt. Inhaltlich geht es dabei um fachlich wertvolle Objekte, deren Eigenschaften und Beziehungen untereinander, um datenorientierte Sichten auf ein System oder um die modellbasierte Darstellung von Glossaren. Eine weitere Anwendungsmöglichkeit von UML-Klassendiagrammen stellt die Modellierung von User Interfaces dar. Wir konzentrieren uns in diesem Beitrag auf die Strukturen der Oberflächen, nicht auf deren Verhalten (wofür die Zustandsdiagramme der UML ein geeignetes Beschreibungsmittel sein können). Da wir diesen Modellierungsansatz weniger häufig als die oben genannten in der Praxis vorfinden, stellen wir ihn hier vor. Problembeschreibung Wir stellen uns ein Projekt vor, dessen Aufgabe es ist ein Onlineportal zu entwickeln, in dem Kunden Formulare online ausfüllen und einreichen können. Die folgenden drei Aspekte gibt es zu beachten: Für die Datenschutzabteilung muss ein Dokument erstellt werden, welches alle für die Nutzenden sichtbaren Bildschirmmasken enthält. Dieses Dokument soll nicht nur die Screenshots der Formularseiten beinhalten, sondern zu jeder Formularseite auch eine Ausgabe aller Oberflächentexte, Hilfetexte und die möglichen Validierungen eines jeden Feldes ausgeben. Zusätzlich gibt es die Anforderung ein Dokument für die Support-Abteilung zu erstellen. Dieses soll inhaltlich dem Dokument für die Datenschutzabteilung gleichen. Es soll den Mitarbeitenden im Support aber ermöglichen schnell zwischen den Formularseiten zu navigieren. So sollen Kundenanfragen zielgerichteter beantworten können. Darüber hinaus verfügt das eingesetzte Modellierungstool über eine API, die aus Diagrammen Code generieren kann. Hier stellt sich die Frage, ob die Modellierung von Oberflächen sinnvoll genutzt werden könnte, um Code zu generieren und den Entwicklern die Arbeit zu erleichtern. Modellierungsbeispiel Um diese drei Aspekte zu lösen, wurde ein Ansatz entwickelt, den wir zur besseren Visualisierung anhand folgender fiktiver Formularseite „Buchung“ vorstellen: Abbildung 1: Oberfläche der Formularseite „Buchung“ Für jede im System umgesetzte Formularseite wird ein Screenshot erzeugt, der im Modell abgelegt wird. Pro Formularseite gilt es eine eigene Klasse zu modellieren und diese mit der Oberflächengrafik der Formularseite zu verbinden. Die Attribute der Klasse entsprechen dabei den Eingabefeldern auf der Oberfläche. Je nach Art der Eingabe wird ihnen ein bestimmter Datentyp zugewiesen. Abbildung 2: Klasse für die Formularseite „Buchung“ mit den Feldern als Attribute Für jedes Attribut können weitere oberflächenspezifische Angaben erfasst werden. Hierzu zählt zum Beispiel der Labeltext und eventuell vorhandene Hilfetexte (in unserem Fallbeispiel das Fragezeichen hinter der Checkbox zum Datenschutz). Abbildung 3: Labeltext und Hilfetext als Tags des Attributs „zustimmungDatenschutz“ Texte ohne Eingabefeld werden ebenfalls als Attribut der Klasse modelliert und der zugehörige Text erfasst. Diesen Textattributen wird kein Datentyp zugewiesen. Abbildung 4: Infotext ohne Bezug zu einem Eingabefeld auf der Oberfläche Darüber hinaus kann jedes Eingabefeld mit Validierungsregeln verknüpft werden. Diese werden als eigene Modellelemente modelliert und möglichst generisch gehalten, um sie mehrfach verwenden zu können. Das Feld „Vorname“ ist zum Beispiel ein Pflichtfeld. Versucht der Benutzer ohne Eingabe weiter zu navigieren, erscheint die Fehlermeldung “Bitte geben Sie einen Text ein“. Außerdem müssen mindestens drei Zeichen eingegeben werden und es sind nicht alle Sonderzeichen erlaubt. Verletzt der Benutzer einer dieser Validierungsregeln, erscheint ebenfalls eine Fehlermeldung. Alle drei Validierungen gelten sowohl für das Eingabefeld „Vorname“ als auch für das Feld „Nachname“ und werden demnach mit beiden Feldern verknüpft. Welche Validierung vom System zuerst geprüft werden soll, kann mittels eines Zahlenwerts in einer weiteren Stereotypeigenschaft festgelegt werden. Je niedriger der vergebene Wert, desto höher ist die Priorität der Prüfung. Abbildung 5: Validierungsregeln für Oberflächenfelder Falls bestimmte Eingabefelder auf mehreren Formularseiten vorhanden sind und deren Validierungen und Labeltexte die gleichen sind, werden diese Attribute in eigene Klassen ausgelagert. So können diese Klassen immer wieder verwendet werden. Ein typisches Beispiel hierfür sind Adressfelder. Abbildung 6: Erweiterung des Beispiels um Felder für Adressangaben Fazit Dieses Vorgehen ermöglicht es, alle drei oben genannten Anforderungen zufriedenstellend zu bedienen: Für die Datenschutzabteilung wurde eine Exportfunktion entwickelt, die aus den Oberflächenmodellen ein Dokument mit allen benötigten Informationen generieren kann. Durch einen Knopfdruck kann zu jeder Zeit ein zielgruppenorientiertes Dokument erstellt und der Datenschutzabteilung übergeben werden. Für die Support-Abteilung wurde eine weitere Exportfunktion zur Verfügung gestellt, die eine Datei im HTML-Format erzeugt. So können die Mitarbeitenden im Support bequem und schnell auf die benötigte Formularseite springen. Über die API des Modellierungstools wird aus den Oberflächendiagrammen Code generiert. Dieser generierte Code dient den Entwicklern dann als Grundgerüst für die Implementierung der Oberfläche. In einer generierten Datei sind sämtliche Oberflächentexte zu finden. Dies erspart das Abtippen der Texte und minimiert Tippfehler seitens der Entwicklung. Bei Textänderungen ist es möglich, die Texte im Modellierungstool zu ändern und eine neue Datei zu generieren, welche dann im Code ersetzt werden kann. Jedoch birgt das Vorgehen auch Nachteile: Gibt es viele Änderungen auf der Oberfläche, ist der Pflegeaufwand des Modells hoch. Bei jeder kleinen Textänderung auf der Oberfläche, muss das entsprechende Attribut im Modell angepasst, Code generiert, der Screenshot ausgetauscht und die Dokumente aktualisiert werden. Die Entwickler sind nur bedingt glücklich damit, dass ihnen der Code von einem Codegenerator zur Verfügung gestellt wird. Manuelle Anpassungen an den generierten Dateien durch die Entwickler sind nicht möglich, da die manuellen Änderungen durch das erneute Einfügen generierter Dateien überschrieben werden. Inzwischen sind wir daher dazu übergegangen, den Code einmal initial aus dem Modellierungstool zu generieren und bei späteren Änderungen nur noch die Datei mit den Oberflächentexten zu generieren. Obwohl die Modellierung der Oberflächen relativ aufwändig ist, ergibt dieses Vorgehen in unserem Projektkontext Sinn. Das Oberflächenmodell dient im Projekt als „Single Point of truth“, aus dem sämtliche Dokumente, Textdateien für die Entwickler und fachliche Beschreibungen generiert werden. Die Pflege der verschiedenen Dokumente erfolgt daher aus einer verlässlichen und aktuellen Datenquelle und trägt somit zu einer konsistenten Dokumentation bei. Da Anpassungen auf der Oberfläche aufgrund von Gesetzesänderungen häufiger vorkommen, besteht ein weiterer großer Vorteil für das Projekt darin, dass die Dokumente für den Support gleichzeitig mit dem Ausrollen der neuen Softwareversion jederzeit aktualisiert werden können. Theresa Mühl Theresa ist Requirements Engineer bei isento
CRM-Erfolg durch praktisches Requirements Engineering
Motivation – Warum ein CRM-System? Ein CRM-System für isento – davon haben wir uns Vieles versprochen: Bessere Organisation, weniger Zeitaufwand, alles schön übersichtlich an einem Ort. Denn unser Kundenstamm, deren Status und Prioritäten, Eigenheiten, Verträge und Vereinbarungen müssen natürlich gepflegt und aktuell gehalten werden, um jederzeit agieren und reagieren zu können. Das mittels Excel-Listen, Notizen, Mailablage und den resultierenden Medienbrüchen hinzubekommen, ist nicht nur unpraktisch und zeitraubend, es birgt auch viele Gefahren im alltäglichen Arbeiten. Ende letzten Jahres haben wir bei isento den Bereich Account Management aufgebaut. Hierfür konnten wir eine neue Kollegin gewinnen, die die neu geschaffene Stelle des Kunden- und Partnermanagements und die dazugehörigen Prozesse definierte. Im Zuge dessen bot es sich an, über eine Einführung eines CRM-Tools nachzudenken. Da auch das Ressort Requirements Engineering im letzten Quartal 2020 deutlich verstärkt wurde, wurde die Chance für ein internes Projekt genutzt. Wir stellten also ein Team zusammen, das die interne Anforderungsaufnahme und -analyse übernahm und das Account Management bei dem Projekt bis zur Beendigung der Testphase begleitete. Stakeholderanalyse – Wer sagt, was gebraucht wird? Bevor das Projekt damit starten konnte, Anforderungen an ein CRM-System aufzunehmen, musste zunächst analysiert werden, von wem diese Anforderungen kommen sollen. Wer würde später mit dem Tool arbeiten? Wer würde davon, vielleicht auch nur indirekt, betroffen sein? Gibt es Gesetze oder Normen, die man beachten muss? Altdaten, die migriert werden sollen? Nachbarsysteme, die man integrieren muss? In einer Stakeholderanalyse sowie einer Kontextabgrenzung hat unser Team diese Fragen aufgenommen und beantwortet. Dabei ergab sich, dass neben dem Account Management auch das Marketing-Team von einem Tool stark profitieren würde, ebenso wie die Geschäftsführung. Diese drei Gruppen – das Account Management, das Marketing und die Geschäftsführung – wurden somit als die zentralen Stakeholder ermittelt. Zusätzlich galt es, das 2018 in Kraft getretene Gesetz des Datenschutzes, die EU-DSGVO, als weiteren Stakeholder zu berücksichtigen. Runde 1: Erhebung der Anforderungen an das CRM-System Die Anforderungen haben wir in mehreren Interviews, aufgeteilt in die entsprechenden Fachbereiche, aufgenommen. Dabei konkretisierten sich die anfänglichen „Wunschkonzerte“ der Stakeholder über mehrere Runden zunehmend zu handfesten Anforderungen, bei der auch schon mal erste Wünsche wieder wegfielen und durch andere Anforderungen ersetzt wurden. Runde 2: Analyse und Konsolidierung der Anforderungen Als Dokumentationsformen für die Anforderungen wählten wir der Wiederverwendung in der zukünftigen Auswahlphase zuliebe eine Funktionsliste in Excel. Darin wurden die Anforderungen nicht nur nach „Muss“, „Soll“ und „Kann“ eingeteilt, sondern auch mit Prioritäten versehen und zu Fachdomänen zugeordnet. So ergab sich eine strukturierte Liste aller Funktionen, nach Aufgabengebieten getrennt, die jederzeit vervollständigt werden konnte. Zusätzlich dazu haben wir mittels eines Begriffsmodells alle Fachbegriffe und deren Beziehungen zueinander beschrieben. Auf Basis dieser beiden Artefakte – Funktionsliste und Begriffsmodell – haben wir die Anforderungen in einer zweiten Runde mit den Stakeholdern konsolidiert. Durch intensive Gespräche und Diskussionen fand noch einiges an Dynamik statt. So wankte manch fest geglaubte Anforderung nach solch einem Meeting und wurde entweder verändert oder auch ganz von Bord geworfen. Sichtung CRM-Tools – Überblick verschaffen im Dschungel der Anbieter Mit diesen beiden Artefakten konnte es nun an die Sichtung der CRM-Tools auf dem Markt gehen. Es galt zunächst, sich auf dem äußerst breiten Markt der CRM-Tool-Anbieter einen Überblick zu verschaffen. Die neue DSGVO sowie die ISO 27001 Zertifizierung halfen hierbei als Selektionsparameter und reduzierten die Anzahl möglicher Tools. Auswahl – Anbieter unter die Lupe nehmen Fünf Tools nahmen wir letztendlich in die engere Auswahl. Vier der fünf Softwarehersteller boten zum Kennenlernen der Software eine geführte Webdemonstration an, in der wir auch eigene Fragen stellen konnten. Direkt im Anschluss wurden Testaccounts erstellt, die für ungefähr 30 Tage freigeschaltet waren. Testphase – Software auf Herz und Nieren prüfen Ausgehend von der Funktionsliste haben wir dann eine Liste aller zu testenden Funktionen erstellt, für die je nach Erfüllungsgrad unterschiedlich viele Punkte vergeben werden konnte. Durch zusätzlich unterschiedliche Gewichtung der einzelnen Funktionen errechnete sich am Ende eine Punktezahl, mit der die verschiedenen Anbieter objektiv miteinander verglichen werden konnten. Entscheidung – die Qual der Wahl Schon früh zeigte sich, dass alle Tools die geforderten Funktionalitäten zum größten Teil mitbrachten, sie sich jedoch trotzdem gravierend voneinander unterschieden. Vor allem im Bereich Benutzerfreundlichkeit und schnelle Erlernbarkeit der Software trennte sich die Spreu vom Weizen. Einige Tools stellten sich als zu mächtig heraus, mit einer Palette von Funktionen, die für isento zu überfrachtet und überdimensioniert gewesen wären. Letztlich haben wir uns für ein Tool entschieden, das nicht nur alle geforderten Funktionen abdeckt, sondern auch intuitiv verständlich, einfach zu bedienen und übersichtlich im Aufbau ist. Durch den modularen Aufbau können nicht relevante Bereich ausgeblendet und weitere Funktionen für das Marketing durch Add-Ons dazu gebucht werden. Somit kann auch auf spätere Veränderungen reagiert und das Tool den sich ändernden Bedürfnissen angepasst werden. Fazit Unser CRM-Projekt lief getreu der typischen Vorgehensweisen unseres Requirements Engineering ab. Unser internes Team konnte ein gemeinsames Verständnis über die Anforderungen aller Projektbeteiligten erreichen und auf dieser Basis das für alle Stakeholder am besten geeignete Tool auswählen. Anna Dodenhöft Anna ist Requirements Engineer bei isento
Requirements Engineering im agilen und klassischen Umfeld
Agilität ist weiterhin in aller Munde und viele Unternehmen bedienen sich agiler Frameworks und Best Practices zur Entwicklung ihrer Software – Tendenz steigend. Während für das Requirements Engineering (RE) in klassischen Vorgehensmodellen wie dem V-Modell oder RUP (Rational Unified Process) ein klarer Platz innerhalb des Entwicklungsprozesses vorgesehen ist, ist die Rolle des RE im agilen Umfeld nicht gleich auf den ersten Blick ersichtlich. Requirements Engineering in klassischen Vorgehensmodellen Das wesentliche Merkmal klassischer Vorgehensmodelle in der Software-Entwicklung ist die Aufteilung des Entwicklungsprozesses in genau definierte, zeitlich begrenzte Phasen. Das Vorgehensmodell gibt vor, in welcher Reihenfolge welche Aktivität stattfindet und wer diese Aktivität durchführt und verantwortet. Die Anforderungsanalyse findet ihren Platz typischerweise am Anfang des Prozesses. Das heißt, schon vor Beginn der eigentlichen Implementierung werden die Anforderungen an das System vollumfänglich ermittelt, abgestimmt und dokumentiert. Erst mit dem Abschluss dieser Phase folgen danach die weiteren Phasen wie Systemdesign, Implementierung und Test. Requirements Engineering im agilen Umfeld Im agilen Umfeld wird meistens zunächst ein sogenanntes MVP (Minimal Viable Product) entwickelt und veröffentlicht. Ein MVP ist das Produkt mit dem minimalst notwendigen Funktionsumfang, welches entwickelt werden muss, um einen Kundenbedarf zu decken. Weitere Anforderungen des Kunden an das Produkt werden danach in weiteren Iterationen nach und nach ermittelt und je nach Priorität umgesetzt. Somit wird es ermöglicht flexibel und schnell auf Kundenwünsche oder geänderte Randbedingungen zu reagieren. Obwohl es in der Praxis gerade bei komplexen Projekten ratsam sein kann, bereits vor dem ersten Inkrement ein Grobkonzept des Projektes zu erstellen, um einen groben Überblick über die Anforderungen zu erhalten, ist eine eigene Phase zur Anforderungsanalyse zu Beginn des Projekts im agilen Umfeld nicht vorgesehen. Doch wo finden die Hauptaktivitäten des Requirements Engineerings Ermittlung, Dokumentation, Prüfung & Abstimmung und Verwaltung statt, wenn es im Gegensatz zu klassischen Vorgehensmodellen keine klar definierte Phase dafür gibt? Deutlich wird dies anhand des Beispiels Scrum: Ermittlung der Anforderungen Die Ermittlung der Anforderungen erfolgt durch den Product Owner (PO). Dieser kommuniziert mit den relevanten Stakeholdern und erfasst deren Anforderungen meist als User Stories im Product Backlog. Diese Aktivität findet bei Bedarf kontinuierlich über den gesamten Produktentwicklungszeitraum statt. Im Zuge des Refinements werden diese Stories mit dem Team besprochen und bei Bedarf angepasst und weiter konkretisiert. Ist die Story ausreichend hoch priorisiert und für den kommenden Sprint vorgesehen, präsentiert der PO diese dem Entwicklungsteam im Sprint Planning Meeting. Auch hier können weitere Anforderungen identifiziert oder konkretisiert werden. Doch nicht nur vor einer Iteration kann eine Anforderungsermittlung stattfinden. Ein wesentlicher Vorteil von Scrum sind die schnellen Feedback-Schleifen. Um die Anforderungen der Stakeholder zu validieren, präsentiert das Team diesen daher im Sprint Review die Arbeitsergebnisse des vergangenen Sprints. Hier können die Teilnehmer fehlende Anforderungen oder neue Erkenntnisse äußern, welche dann gegebenenfalls ebenfalls Änderungen auf das Product Backlog haben können. Dokumentation der Anforderungen Eine erste Dokumentation der Anforderungen stellt bereits das Anlegen einer User Story im Product Backlog und die Ergänzung der zugehörigen Akzeptanzkriterien dar. Außerdem kann es zum besseren Verständnis im Zuge des Refinements oder des Sprint Plannings sinnvoll sein, eine strukturierte Dokumentation wie beispielsweise Kontextdiagramme, Aktivitätsdiagramme, Klassendiagramme oder andere UML Diagramme anzufertigen. Oftmals ist es aufgrund gesetzlicher Anforderungen notwendig eine detaillierte Dokumentation des Systems anzufertigen. Dafür empfiehlt es sich während des Sprints die umgesetzten Features in der Dokumentation des Systems zu ergänzen. Übergreifende nicht-funktionale Anforderungen können in der Defintion of Done festgehalten werden. Somit muss jede User Story für deren Fertigstellung die definierten nicht-funktionalen Anforderungen erfüllen. Abstimmung und Prüfung der Anforderungen Das Abstimmen und das Prüfen der Anforderungen sind essenziell, um ein gemeinsames Verständnis über die Anforderungen zu erlangen. Eine erste Abstimmung der erhobenen Anforderungen mit allen relevanten Stakeholdern findet im Zuge der Erstellung der User Stories für das Product Backlog statt. Darüber hinaus muss im Refinement eine Prüfung mit den Mitgliedern des Entwicklungsteams erfolgen, sodass diese die Inhalte verstanden haben und die notwendige Klarheit für die Umsetzung der Anforderungen herrscht. Verwaltung der Anforderungen Da Anforderungen kontinuierlich erhoben werden, ist das Product Backlog einer ständigen Veränderung unterworfen. Die Liste muss kontinuierlich verwaltet und priorisiert werden, um somit das Backlog stets aktuell zu halten. Dies gilt auch für das Sprint Backlog, welches nach der Erledigung von Aufgaben und Stories aktuell gehalten werden muss, um den tatsächlichen Bearbeitungsstand abzubilden. Fazit Das Ziel der Analysephase im klassischen Umfeld ist es, ein vollständiges Spezifikationsdokument zu erstellen (z. B. Lastenheft), welches im weiteren Verlauf des Entwicklungsprozesses stabil bleibt. Die Anforderungen im agilen Umfeld hingegen können sich ständig ändern und müssen erst dann vollständig sein, wenn deren Umsetzung unmittelbar bevorsteht. Das Requirements Engineering findet daher iterativ, während des gesamten Entwicklungsprozesses statt. Theresa Mühl Theresa ist Requirements Engineer bei isento
