Problemstellung
Eine der Ursachen für gescheiterte Softwareprojekte liegt in der Transformation der Wünsche und Vorstellungen der Anwender in die technische Umsetzung. Requirements-Engineering setzt hier an und versucht die Vorstellungen der Anwender in technische Anforderungen an die Applikation umzusetzen. Diese Methoden stützen sich mehr auf die technische Seite und schaffen, wie z.B. UML, BPMN, etc., eine (semi-)formale Spezifikation aus den Aussagen der Anwender. Mit den hier vorgestellten Methoden lässt sich noch ein Schritt zuvor ansetzen und vertiefen. Indem nicht nur die Aussagen der Anwender herangezogen werden, sondern er wirklich beim Erkennen seiner Wünsche unterstützt wird. So entsteht die Möglichkeit, in die Tiefe zu gehen, wo normale RE-Methoden an der Oberfläche bleiben. Der gewonnene Input kann von der Planung des Funktionsumfangs bis zur Oberflächengestaltung das ganze Projekt unterstützen.
Begriffsdefinitionen
- Anwender: nutzt später die Applikation
- Kunde: bezahlt die Applikation
- Stakeholder: ist in irgendeiner Form am Projekt beteiligt
- Team: Entwicklungsteam
Walt-Disney-Strategie
Die Vision der Applikation fassen und prüfen.
Vorgehen: Die drei Rollen (Träumer, Kritiker, Planer) mit der Vision der Applikation durchlaufen.
Ergebnis: Klärung der Vision, Realitätscheck, erste Aktionsschritte
VAKOG-Modell
Vorstellungen der Anwender erfahren.
Vorgehen:
- Der Anwender taucht in seine Vorstellung der Applikation ein.
- Der Anwender beschreibt seine Vorstellung visuell, kinestäthisch und auditiv.
Ergebnis: detailliertere Beschreibung der Vorstellungen des Anwenders, ausgeprägte Wahrnehmungskanäle des Anwenders, Gemeinsamkeiten der Zielgruppe erfahren.
UI und Usability
Vorgehen:
- Dem Anwender Konzepte der Oberfläche und Bedienung visuell, kinestäthisch und auditiv präsentieren.
- Der Anwender gibt Feedback.
Ergebnis: Korrekturen und Anpassungen durch das Feedback des Anwenders. Verfeinerung der Details und des Bedienkonzepts.
Submodalitäten
UI und Usability konzipieren
Vorgehen:
- Der Anwender taucht in seine Vorstellung der Applikation ein.
- Der Anwender stellt sich die Oberfläche, die Haptik und die Workflows der Applikation vor.
- Der Anwender verändert die Submodalitäten bis ein für ihn stimmiges Bild/Gefühl entsteht.
Ergebnis: Ideen für die Anpassung der Oberfläche, der Bedienung und der Workflows.
Dilts Pyramide
Zukunftsbild der Applikation prüfen und verinnerlichen.
Vorgehen:
- Visualisieren des fertigen Produktes (Funktionen, Nutzen, UI).
- Durchlaufen der Dilts-Pyramide und das Produkt in den Ebenen erleben und prüfen:
- Umwelt: Auf welche Umgebung (technisch) und welches Umfeld (Einstellung der Anwender) trifft sie?
- Verhalten: Wie kann mit der Applikation gearbeitet werden? Welche Workflows bietet sie an? Wie interagiert die Applikation mit dem Anwender?
- Fähigkeiten: Was kann die Applikation? Welche Funktionen und Möglichkeiten bietet sie?
- Werte/Glauben: Welche Leitideen verfolgt die Applikation? Welche Architektur- und Designkonzepte verwirklicht sie?
- Identität: Welchen Geschäftsprozess unterstützt die Applikation?
- Vision: Welchen Nutzen stiftet die Applikation beim Anwender? Welches Gefühl hinterlässt sie nach der Arbeit?
Wahrnehmungspositionen
In die Lage der Stakeholder versetzen.
Vorgehen:
- Teammitglied (Entwickler, Designer, etc.) versetzt sich über Raumanker in die Position eines Stakeholders (Anwender, Kunde, Management, Support, Betrieb).
- Teammitglied fühlt in die Position hinein und beschreibt die Erwartungen, Wünsche und Sichtweise auf das Projekt/Produkt.
Ergebnis: Besseres Verständnis aller Projekt- und Produktbeteiligten.
Mentor-Technik
Befragung der wichtigsten Kunden/Anwender.
Vorgehen:
- Als Mentoren werden konkrete Kunden/Anwender der Applikation herangezogen.
- Fragestellungen werden aus Sicht der Mentoren beantwortet. Ideen für Fragestellungen:
- Welchen Nutzen/Wert soll die Applikation bringen?
- Welche Funktionen haben die höchste Priorität? Welche nicht?
- Welche Plattformen sind relevant? Welche nicht?
- Worin liegt der Fokus bei der Bedienbarkeit?
- Was sind No-Gos für die Akzeptanz der Applikation?
Ergebnis: Laufender Check ob das Projekt noch in die richtige Richtung steuert. Zusätzlich zu realen Kundeninterviews.
Modelling für den Entwicklungsprozess
Entwicklungsprozess erfolgreicher Projekte modellieren.
Vorgehen:
- Suche und Identifizierung von erfolgreichen Projekten, passend zum eigenen Vorhaben.
- Elizitieren der Strategie.
- Transfer der Strategie auf das eigene Vorgehen, Anpassung an die eigenen Bedürfnisse und Vorgaben.
Ergebnis: Verbesserter Entwicklungsprozess, neue Sichtweise, Anwendung von Best Practices
TOTE-Modell
Der agile Entwicklungsprozess.
Vorgehen: Einsatz iterativer Entwicklungsmodelle wie z.B. Scrum. Kurze, fixe Iterationen zwischen 2 und 4 Wochen
- Im Planungsmeeting werden die Aufgaben der nächsten Iteration geplant. Die Priorität bei der Auswahl der Aufgaben liegt beim höchsten (Geschäfts)-Wert für die Applikation und auf Aufgaben, die auch während dieser Iteration komplett abgearbeitet werden können.
- Während der Iteration werden die Aufgaben vom Team abgearbeitet.
- Am Ende der Iteration findet ein Reviewmeeting statt, in dem das Ergebnis der Iteration dem Anwender/Kunden präsentiert wird. Dieser kann durch Feedback und Input den Fortlauf der nächsten Iteration beeiflussen und mitgestalten.
- Sind nach x Iterationen alle Anforderungen umgesetzt (Applikation entspricht der Kunden/Anwender-Erwartung) ist die Entwicklung abgeschlossen.
Ergebnis: Ein sich selbst justierender Prozess mit kurzen Feedbackschleifen, der schnelle Korrekturen ermöglicht.
Häufig gestellte Fragen
Warum scheitern Softwareprojekte häufig an der Übersetzung von Anwenderwünschen in Technik?
Weil die Anwender ihre Wünsche selbst oft nur an der Oberfläche benennen können. Requirements-Engineering setzt an ihren Aussagen an und formt daraus (semi-)formale Spezifikationen, etwa mit UML oder BPMN. Der Schritt davor bleibt dabei offen: den Anwender beim Erkennen seiner eigenen Vorstellungen zu unterstützen. Genau dort setzen die beschriebenen Methoden an, deren Ergebnisse vom Funktionsumfang bis zur Oberflächengestaltung wirken.
Wie lassen sich die Vorstellungen eines Anwenders von einer künftigen Software genauer erfassen?
Über mehrere Wahrnehmungskanäle. Der Anwender taucht in seine Vorstellung der Applikation ein und beschreibt sie visuell, kinästhetisch und auditiv. Das ergibt eine detailliertere Beschreibung als eine reine Aufzählung von Wünschen, zeigt seine ausgeprägten Wahrnehmungskanäle und macht Gemeinsamkeiten innerhalb der Zielgruppe sichtbar. Dieselbe Vorgehensweise eignet sich später, um Oberflächenkonzepte zu präsentieren und Feedback einzuholen.
Wie kommt man zu Ideen für Oberfläche und Workflows, bevor ein Prototyp existiert?
Indem der Anwender sich Oberfläche, Haptik und Abläufe innerlich vorstellt und die Details dieser Vorstellung verändert, bis für ihn ein stimmiges Bild oder Gefühl entsteht. Aus diesen Veränderungen entstehen konkrete Anpassungsideen für Bedienung und Workflows, noch bevor Entwurfs- und Entwicklungsaufwand investiert wird.
Auf welchen Ebenen sollte man ein geplantes Produkt durchdenken?
Sechs Ebenen sind sinnvoll, nachdem das fertige Produkt mit Funktionen, Nutzen und Oberfläche visualisiert wurde: Umwelt, also technische Umgebung und Einstellung der Anwender; Verhalten mit Workflows und Interaktion; Fähigkeiten, also Funktionen und Möglichkeiten; Werte mit Leitideen sowie Architektur- und Designkonzepten; Identität, also der unterstützte Geschäftsprozess; und Vision, der gestiftete Nutzen und das hinterlassene Gefühl.
Wie kann ein Entwicklungsteam die Sicht anderer Projektbeteiligter besser verstehen?
Ein Teammitglied versetzt sich über Raumanker in die Position eines Stakeholders: Anwender, Kunde, Management, Support oder Betrieb. Aus dieser Position heraus beschreibt es Erwartungen, Wünsche und Sichtweise auf Projekt und Produkt. Wichtig ist die Trennung der Rollen: Der Anwender nutzt die Applikation später, der Kunde bezahlt sie. Beide haben unterschiedliche Erwartungen.
Wie prüft man laufend, ob ein Projekt noch in die richtige Richtung steuert?
Konkrete Kunden oder Anwender werden als Mentoren herangezogen, und das Team beantwortet Fragen aus deren Sicht: Welchen Nutzen soll die Applikation stiften? Welche Funktionen und Plattformen haben Priorität, welche nicht? Worin liegt der Fokus bei der Bedienbarkeit? Was sind No-Gos für die Akzeptanz? Reale Kundeninterviews ersetzt das nicht, es ergänzt sie zwischen den Terminen.
Warum sind kurze Iterationen mit Kundenfeedback wirksamer als eine einmalige Anforderungsaufnahme?
Weil sich der Prozess dadurch selbst nachjustiert. Der Artikel beschrieb 2015 fixe Iterationen von zwei bis vier Wochen: Geplant wird nach dem höchsten Geschäftswert und danach, was innerhalb der Iteration vollständig fertig wird. Am Ende sieht der Anwender das Ergebnis und gestaltet mit seinem Feedback die nächste Iteration mit. Abgeschlossen ist die Entwicklung, wenn die Applikation der Erwartung entspricht.
