Requirements Engineering Methoden

Bei Spirit Link habe ich gelernt, Wireframes (auch Funktionale Layouts) für die Konzeption zu nutzen und habe großartige Erfahrungen in der Kombination mit Use-Cases gemacht.

Wireframes sind schematische Abbildungen von Screens, die Funktion und Information, vom Design jedoch nur die Anordnung enthalten (keine Abstände, nur ungefähre Größenverhältnisse, keine Farben und gestalteten Icons). Sie dienen dazu, die benötigte Funktion und Information auf Screens aufzuteilen und nutzbar zu machen. Siehe auch in Wikipedia.

Ich erstelle Use-Cases, um mir einen Benutzungs-Ablauf und die benötigte Information zu überlegen. Der Use-Case zwingt mich, das Ziel des Benutzers und seinen Weg durch die Applikation zu formulieren.
Parallel dazu beginne ich damit, Wireframes für den Use-Case zu zeichnen. Die Wireframes zwingen mich, alle Benutzungs-Eventualitäten zu bedenken.
In Kombination decken sie die funktionalen Anforderungen ab.
Die Wireframes ermöglichen zudem (natürlich), die Usability zu optimieren. Häufig erkenne ich anhand eines Wireframes zusätzliche nützliche Funktionalität, die ich dann im Use-Case ergänze. Der Use-Case sichert dann die Vollständigkeit und Konsistenz der Funktionalität. Iterativ beleuchte ich so verschiedene Aspekte und optimiere so das Konzept.

Ich habe außerdem festgestellt, dass jeder Kunde eines der beiden bevorzugt. Einige Kunden sprechen lieber über formulierte Anforderungen / Use-Cases. Viele Kunden bevorzugen Wireframes, anhand derer sie die Abläufe des Systems leicht nachvollziehen können.
Die Entwickler benötigen beides, um das System umzusetzen.

Wireframes eignen sich ausschließlich für Funktionalität, die an der Oberfläche sichtbar ist. Algorithmen und Constraints sind nur im Use-Case dokumentiert.
Besteht ein System nur aus Algorithmen und kommuniziert nur mit Systemen, eignen sich Wireframes natürlich nicht. Bei Spirit Link sind praktisch alle Projekte für menschliche Anwender, die häufig über keinen Informatik-Background besitzen. Der Usability-Aspekt ist hier natürlich doppelt interessant.

Informationsarchitektur ist eine spannende Disziplin, die sich mit dem Requirements Engineering überlappt, aber andere Ursprünge hat.

Die Informationsarchitektur stammt ab vom Design, mit Einflüssen aus dem Bibliothekswesen und kümmerte sich ursprünglich um die Strukturierung von Websites. Heute versteht sich Informationsarchitektur als übergreifende Disziplin, die das Ziel verfolgt, dem Anwender maximalen Nutzen zu bringen. Business Requirements und User Requirements sind den Informationsarchitekten keine Fremdworte mehr - sie müssen daher sehr stark mit dem Requirements Engineering kooperieren.
Eine bessere Definition bietet z. B. das Information Architecture Institute oder Wikipedia.

Von meinem Kollegen Wolf Nöding habe ich Informationsarchitektur kennen und schätzen gelernt, weil es meine Methoden zur Spezifikation um wichtige Methoden ergänzt - von Wireframes und Informationsflussdiagrammen, die ich inzwischen in fast jedem Projekt nutze, bis zu grafischen Kontextspezifischen Szenarienbeschreibungen.
Wir beide lernen viel voneinander indem wir unsere Methoden austauschen. Ein Designer denkt außerdem ganz anders als ich als Informatiker - es ist immer wieder spannend, uns beide für die Konzeption in einen Raum zu sperren :-)
Zwei Welten treffen aufeinander und ergänzen sich prächtig!

Ein paar weitere Links auf Blogs von bekannten Informationsarchitekten:
http://www.peterboersma.com/blog/
http://findability.org/
http://louisrosenfeld.com/home/