Requirements Engineering Methoden

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/

Ein wundervoller Artikel von Mark Twain, Die schreckliche deutsche Sprache, in dem er die Untiefen und Besonderheiten der deutschen Sprache beschreibt. Absolut lesenswert für alle, die sich mit der deutschen Sprache beschäftigen.

In den meisten Projekten nutze ich Use-Cases zur Analyse und Spezifikation.

Warum?
Weil sie einfach sind und leicht von Kunden verstanden werden.
Weil das Ziel des Anwenders beschrieben ist - sehr wichtig!
Weil sie funktionale Anforderungen in Applikationen sehr gut abbilden - was den Großteil meiner Projekte ausmacht.
Weil sie für die Analyse genauso funktionieren wie für die Konzeption.

Ich verwende Use-Cases, wie sie Alistair Cockburn beschreibt, siehe z. B. Cockburns Artikel "Use case fundamentals".

Die Szenarien sind einfach und logisch aufgebaut. Durch das Beschreiben des Ablaufs spare ich mir, in jedem Requirement den vollständigen Kontext zu beschreiben.
Eine Auswirkung ist, dass z. B. der ganze Use-Case getestet werden muss und Requirements nicht alleine gültig sind. Hat mir aber noch nie Schwierigkeiten bereitet - im Gegenteil: Der Übergang zur Testspezifikation wird einfacher, da diese sowieso ein Szenario beschreiben muss.

Das Use-Case-Schema gibt einige Formalismen vor, die sicherstellen, dass relevante Informationen auftauchen (insb. Ziel des Use-Cases). Die Formulierung gemäß "Wer macht was" stellt sicher, dass viele Formulierungsfehler nicht passieren können.
Ich kann mich also darauf konzentrieren, die funktionalen Anforderungen zu dokumentieren.

Scott Sehlhorst beschreibt in seinem Blog unter "Communicating Intent With Implementers" den Vorteil, dass die Entwickler das "Warum" einer Funktionalität kennen.
Mindestens genauso wichtig ist es für Frontend-Designer, die Ziele der Benutzer zu kennen und deren typische Arbeitsabläufe - Dinge, die ein Use-Case bereits gut beschreibt.

Bei Spirit Link ist es relativ selten, dass wir ein Lastenheft erhalten. Um so schwieriger scheint es mir zu sein, in ein Projekt einzusteigen, in dem der Kunde ein Lastenheft liefert.

Ein Lastenheft beschreibt die Anforderungen des Kunden. Fast noch wichtiger sind die Randbedingungen für das Projekt und die Ziele der Anwender.
Häufig sind Lastenhefte meiner Kunden jedoch keine guten Lastenhefte.
- Typischerweise enthält das Lastenheft alle relevanten funktionalen Anforderungen
- Sehr oft fehlen die Randbedingungen
- Fast immer fehlt das "Warum", die Ziele der Anwender
- Ab und zu: das Lastenheft ist nicht mehr aktuell, und es sind viele Anforderungen nicht enthalten oder entfallen (der Klassiker)
- Typisch auch: Anforderungen auf unterschiedlichen Ebenen (siehe Blogeintrag "Abstraktionsgrad von Anforderungen")

Es ist meinen Kunden nicht vorzuwerfen, dass ihre Lastenhefte nicht perfekt sind - es ist nicht ihre Aufgabe, zu spezifizieren. Meine Kunden sind häufig Anwender oder Abteilungen, die sich mit Geschäftsprozessen beschäftigen.
Ich verstehe es als meine Aufgabe, deren Welt zu analysieren und anschließend die bestmögliche Lösung zu finden. Auch wenn ich ein Lastenheft vom Kunden erhalte, hinterfrage ich immer die Ziele der Anwender, um mögliche bessere Lösungen für die Aufgabe zu finden oder (häufiger) weitere Funktionen, die den Anwendern das Leben erleichtern können.
Mit diesem Wissen kann ich meinen Kunden beraten, wie die beste Lösung für seine Herausforderung aussieht.

In einem Projekt erhielt ich sinngemäß das Feedback "Warum fragen Sie das? Das steht doch alles im Lastenheft."
Letztlich geht es darum, dem Kunden die Motivation für diese vielen Fragen transparent zu machen.

Ich nutze gerne UML. Vielleicht liegt es daran, dass ich bei Sophist viele viele UML-Trainings gehalten habe.
Typischerweise verwende ich UML als Ergänzung zu sprachlichen Spezifikationen, z. B. für
- Zusammenhänge von Dingen (Objekten), z. B. Eine Organisationsstruktur im Klassendiagramm
- Lebenszyklus von Dingen im System, z. B. ein Dokument im Knowledge Management System im Zustandsdiagram
- Kommunikation zwischen Systemen im Sequenzdiagramm
- Natürlich das Use-Case-Diagamm als Übersicht der Dienstleistung des Systems

Selten, aber es kommt auch vor: eine vollständige objektorientierte Analyse habe ich bisher in einem Projekt durchgeführt. Alle Use-Cases habe ich vollständig durch Zustandsdiagramme spezifiziert.
Die Besonderheit war, dass der Kunde UML liebte und ich mit ihm zusammen die Diagramme entworfen habe, die alle Funktionen definierten. Es war phantastisch. Präzise, vollständig, Klar.

Die meisten Kunden würden diese Diagramme allerdings nicht verstehen.
Daher spezifiziere ich meist mit Sprache und ergänze wo sinnvoll durch Diagramme. Mein Ziel ist, einerseits den Kunden eine verständliche Spezifikation zu liefern und andererseits präzise und eindeutig zu definieren. Kunden verstehen Sprache (fast :) immer, allerdings sind komplexe Zusammenhänge schwer beschreibbar. Diese fasse ich in ein Diagramm und ergänze die sprachliche Beschreibung.

In seinem Beitrag How widespread is UML? fasst Julio Cesar Leite spannende Umfragen zum Thema UML zusammen.
Erstaunlich wenige Projekte nutzen UML - zwischen 15 und 30%!
Leider beschreibt der Post nicht, wofür UML (nicht) genutzt wird - Dokumentation / Code-Generierung? Analyse / Design?

Ich hätte die Zahl deutlich höher geschätzt. Nach etwas nachdenken kann ich die Größenordnung gut verstehen. Wann macht es wirklich Sinn, UML zu nutzen?
- Für Code-Generierung - das lohnt sich erst ab einer relevanten Projektgröße und benötigt viel Disziplin des Teams. Würde ich allerdings öfter vermuten
- Für die Dokumentation der Software-Architektur - ich vermute, wenn überhaupt, dann wird die Architektur in einer "erfundenen" Sprache spezifiziert
- Für die Konzeption - das hängt vermutlich primär von der UML-Kenntnis der Konzepter ab. Bin ich nicht sicher, erfinde ich fluchs meine eigene Sprache… Ich nutze häufig UML in der Konzeption, habe aber auch eine fundierte Ausbildung… (siehe Post "Wo ich UML für die Spezifikation nutze").

Der Begriff Anforderungsanalyse bzw. Requirements Engineering schließt streng genommen nur die Analyse ein. D. h. das Ermitteln von bestehenden Informationen und Wissen.

Was ist aber mit der Konzeption?
Also dem Entwickeln von etwas Neuem? Sind Requirements Engineers nur die Moderatoren, die andere dazu bringen das Neue zu entdecken und zu formulieren?

Wikipedia ist sich auch nicht einig. Im deutschen Artikel Anforderungsanalyse werden nur Anforderungen (Forderung = "Was") beschrieben. Der englische Artikel Requirements Engineering schließt auch die System Requirements Specification (SRS) ein, welche das Verhalten des Systems beschreibt (Konzept = "Wie").

Vielleicht liegt dem nur ein ungenau definierter / benutzer Begriff "Anforderung" zugrunde? Das Wort beschreibt eine Forderung, also kein Konzept. Siehe auch den Post Was und Wie.
Wikipedia definiert übrigens eine Anforderung als Teil des Lastenhefts, also als Forderung.

Ich nutze den Begriff "Requirements Engineering" eigentlich übergreifend - also als Analyse und Konzeption. Ich bin Analytiker und Konzepter.
Streng genommen sind jedoch beide wichtige Schritte bei der Entwicklung eines Systems, die eng verzahnt und doch unterschiedlich sind.

Das Lastenheft eines Projekts wird häufig als das "Was" und das Pflichtenheft als das "Wie" bezeichnet. Siehe auch Wikipedia im Artikel zum Lastenheft.

Die Aussage ist richtig. Ich finde sie jedoch irreführend. Jede Anforderung sowohl im Lasten- als auch im Pflichtenheft beschreibt sowohl das "Was" als auch das "Wie" - es kommt auf den Standpunkt an.

Das Lastenheft enthält Anforderungen ("Was"), die vom Konzept ("Wie", im Pflichtenheft) erfüllt werden. Andererseits beschreibt das Lastenheft, wie die Ziele erreicht werden!

In der Pyramide aus dem Post "Abstraktionsgrad von Anforderungen" suche ich mir eine Anforderung. Oberhalb und unterhalb stehen andere Anforderungen. Für die Anforderungen oberhalb beschreibt unsere Anforderung das "Wie", für die unterhalb das "Was".

Anforderungen gibt es auf verschiedenen Abstraktionsebenen, das ist eigentlich nichts Neues.
Sich dessen bewusst zu sein bei der Spezifikation eines Systems ist jedoch notwendig und hilfreich. Am folgenden Bild mit der "Pyramide" ist mir das bewusst geworden.


In der Pyramide befinden sich Beschreibungen eines Systems auf verschiedenen Abstraktionsebenen (vertikal) und zu allen Bereichen des Systems (horizontal).
An der Spitze der Pyramide stehen Ziele, die in wenigen Sätzen das komplexe System beschreiben. Am Fundament steht die 100% detaillierte Spezifikation im Sourcecode.
Irgendwo in der Mitte steht die Trennung von Blackbox zu Whitebox.

Lastenheft und Pflichtenheft beschreiben z. B. das gesamte System, bewegen sich allerdings auf verschiedenen Abstraktionsebenen. Das Pflichtenheft spezifiziert das System und erfüllt die Anforderungen aus dem Lastenheft.

In Chris Rupps Buch "Requirements Engineering und -Management" werden z. B. Anforderungen auf 5 Detailebenen unterschieden. Level 0 sind die Systemziele, Vision, Business Goals an der Spitze der Pyramide. Level 4 die System Requirements Specification, Technische Anforderungen, Schnittstellenbeschreibung, welche an der Grenze zur White-Box-Beschreibung liegen.
Die Pyramide löst die Stufen in einen fließenden Übergang auf. Theoretisch gibt es unendlich viele Ebenen.
In einem Projekt sind allerdings nur wenige (1-5) davon nützlich. Ich nutze in den typischen Projekten bei Spirit Link 2 der Ebenen: Lastenheft und Pflichtenheft.

Ein wichtiges Kriterium für Spezifikationen lässt sich hier anschaulich zeigen: Eine gute Spezifikation bewegt sich auf einer Ebene und beschreibt das ganze System in seiner Breite. Anforderungen auf verschiedenen Abstraktionsebenen sind schwer miteinander vergleichbar. Konsistenz oder Vollständigkeit sind so schwer nachweisbar.
Eine wichtige Ausnahme sind frühe Untersuchungen z. B. nach Risiko oder für die Aufwandsplanung des Projekts. Sie benötigen detaillierte Informationen für einzelne Anforderungen, um ein Risiko abschätzen zu können oder unbekannte Funktionalitäten zu analysieren.

Hallo, herzlich willkommen auf dem Requirements Engineering Blog !

Ich werde hier Erfahrungen, Erkenntnisse und bewährte Methoden aus dem Bereich Requirements Engineering posten.

Ich erhoffe dadurch interessante Diskussionen mit anderen, die ähnliche oder andere Erfahrungen gemacht haben. Außerdem erwarte ich, dass ich mir durch das Formulieren der Erfahrungen diese erst bewusst werden.

Die Themen drehen sich rund um das Requirements Engineering und die Konzeption, die Bereiche in denen ich bei Spirit Link tätig bin. Sicherlich werde ich den einen oder anderen Ausflug in das Projektmanagent und Software Engineering machen.
Vielleicht werde ich auch zum Thema Knowledge Management, Informationsarchitektur oder E-Learning posten - alles Bereiche, die mich in meiner Arbeit beschäftigen.