Requirements Engineering Methoden

How important is the text of an application, for example in a dialogue box, for the usability and therefore the success of the application?
Enormously!
This fact is often beeing underestimated.
Often the text is written by programmers "along the way" while programming the functionality.

In her article "Dialogue boxes making simple things simple", Leisa Reichelt points out a nice example of a bad dialogue box text.
I think, everybody has seen bad examples of dialogue boxes like this one.

From the point of view of a software company, I have made similar experiences during application development - dialogue box texts completely not helpful to the user.
Luckily, I am in charge of improving this :-)
That's why we started to specify dialog boxes including texts before the get programmed. Wireframes also include dialogue boxes that are called from them.
I also like to ask if the dialogue box is necessary at all. Every dialogue box forces the user to think about something he may not be aware of.
Instead, we want the application to support the user thinking in his way.

An interesting thought though - what to do with experienced users? Scott Sehlhorst puts up some ideas about beginners and experts and the Canyon of Pain.

Auf der EuroIA hatte ich eine spannende Unterhaltung mit Patrick Roelofs über User Centered Design, als ich ihn nach der Bedeutung seines neu gegründeten Unternehmens EXPERIENCE FIRST fragte.
Immerhin ist der Begriff "User Centered Design" (UCD) in aller Munde und wird als wertvoll angesehen.

Patricks Aussagen:
User Centered Design erfüllt primär die Anforderungen der Anwender mit der Gefahr, dass die Anforderungen des Unternehmens nicht erfüllt werden und damit das Projekt scheitert.
User Experience beschäftigt sich dagegen mit dem Erlebnis des Benutzers auf der Website. Das Unternehmen will die Anwender zu Kunden machen und hat daher ein Interesse, das Erlebnis zu beeinflussen.
User Experience bringt die Anforderungen des Kunden mit denen des Unternehmens zusammen.

Die Anforderungen des Unternehmens (Business Requirements) beschreiben Eigenschaften der Website, welche die Anwender aus Sicht des Unternehmens nutzen sollen. Dass die Business Requirements erfüllt werden ist die Voraussetzung dafür, dass das Projektziel erreicht wird. Z. B. will das Unternehmen, dass seine Kunden es als innovativ wahrnimmt.
Die Anforderungen der Anwender Anwender (User Requirements) zeigen die Erwartungen der Anwender. Werden die User Requirements nicht erfüllt, nutzt niemand die Website. Anwender erwarten z. B. aktuelle Trends zu interessanten Themen.
Das Ziel ist, Business Requirements und User Requirements zusammen zu bringen. Das Ergebnis sind die Use-Cases, welche die Möglichkeiten der Website beschreiben. Sie sollen den Anwendern ermöglichen, die von ihnen gewünschten Aktivitäten im Sinne des Unternehmens durchzuführen und zeigen die Innovationskraft des Unternehmens durch Artikel über aktuelle Trends...
Projektziele stehen über den Business und User Requirements als die Ziele, die das Unternehmen mit dem Projekt erreichen will. Im Beispiel könnte die Website im Rahmen der Marketingstrategie das Bild des Unternehmens stärken.

2 Tage EuroIA 2006 in Berlin waren spannend, anstrengend, inspirierend!
Ich bin voll mit neuen Ideen, ein paar davon landen sicher in den nächsten Tagen auf dieser Seite.

Ich habe viele gute Vorträge gehört, über Wireframes (Panel von Philip Borloo), über Findability (Peter Morville), über die Strategie von Applikationen (Olly Wright), über Customer Experience Framework (Jered Folkman).

Ich habe exzellente Vortragsstile gesehen, allen voran Jared Folkmans Vortrag – spannend, unterhaltsam und informativ.

Mein Beitrag in der Panel-Diskussion von Peter Boersma über IA- und Konzeptions-Prozesse hat Spaß gemacht – auch hier habe ich viel gelernt :-)

Einige Highlights aus den Vorträgen, die mir am Abend nach der Veranstaltung noch besonders im Gedächtnis bleiben:
Die Panel-Diskussion von Philip Borloo über Wireframes zeigte verschiedene Ansätze, Wireframes zu zeichnen: Von Stift und Papier bis zu automatisierten Kompositionswerkzeugen. Ich habe einige Ideen mitgenommen, Wireframes im Projekt nützlicher zu machen und sie gemäß agiler Prinzipien nicht länger zu warten als nötig.

Peter Morvilles Vortrag über sein aktuelles Buch "Ambient Findability" zeigte, wie wichtig es ist, eine Applikation nicht isoliert zu betrachten, sondern im Kontext des Geschäftsprozesses, zu dem sie beiträgt (was mich als Business Analyst bestätigt). Sein großes Thema Suche gab mir einige Anregungen durch seine Sichtweise auf die Bedeutung der Suche.

Der Vortrag "The Strategic IA" von Olly Wright zeigte wie wichtig eine explizite Strategie als Grundlage für jede Applikationsentwicklung ist. Er beschrieb ein Vorgehen um eine Strategie umzusetzen, in dem viele Stakeholder einbezogen und berücksichtigt werden müssen. Schließlich muss eine Strategie zum Marketing und dessen Aktivitäten passen.

Das Customer Experience Framework von Jered Folkman zeigte mir, wie wichtig es ist, die Anwender einer Applikation gut zu kennen. Er zeigte grundlegende Fragen, welche die Basis für die Erstellung einer Website liefern.

In der Panel-Diskussion von Peter Boersma "A Place for IA Deliverables", diskutierte ich mit Larisa Warnke, Carlson Marketing, USA und Casper Honijk, Macaw, Holland über IA-Prozesse. Larisa und Casper haben beide enorme Erfahrung mit Entwicklungsprozesse in ihren Unternehmen. Ich fand es spannend, drei sehr unterschiedliche Prozesse gegenüberzustellen und doch festzustellen, dass wir sehr ähnliche Prinzipien zugrunde legen. Ein paar Beispiele:
- Mit wem arbeiten wir zusammen? Mit allen Projektbeteiligten..
- Welche Artefakte erstellen wir? Es kommt darauf an...
- Warum haben wir einen Prozess? Als Hilfsmittel, das Projekt zu lösen.

Unter www.euroia.org werden in den nächsten Tagen die Ressourcen zur Tagung zur Verfügung gestellt.

Am Wochenende vom 30.09. / 01.10. bin ich in Berlin auf der EuroIA. Ich werden an einem Panel teilnehmen, wo wir zu viert über IA Deliverables und das Vorgehen in der Informationsarchitektur diskutieren werden.
Hier die Ankündigung des Panels A Place for IA Deliverables.

Ich bin sehr gespannt, was die Diskussion im Panel ergeben wird. Drei interessante Diskussionspartner mit spannendendem Hintergrund - Peter Boersma ist einer der führenden Informationsarchitekten in Europa!

Außerdem gibt es einige weitere spannende Vorträge und Themen von interessanten Informationsarchitekten. Ich bin gespannt, was andere in diesem Bereich machen, und ich bin sicher, dass ich viele wertvolle Anregungen mit nach Hause nehmen werde.

Networking ist das zweite Thema für mich auf dieser Konferenz. Viele Menschen, die in ähnlichen Themen arbeiten.

Nach der Konferenz poste ich hier sicher ein paar Ideen und Mitbringsel. Ich bin gespannt.

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/