Requirements Engineering Methoden

Ausgelöst von einem Nebensatz in Scott Sehlhorsts (interessante) Artikel-Reihe über Use-Case-Estimation denke ich darüber nach, wie viel Design in meinen Use-Cases steckt.

Der Nebensatz im Artikel bezog sich auf einen Use-Case-Schritt, in dem der Benutzer weiter klickt, und das System die nächste Seite anzeigt. Scott Sehlhorst ist sich mit Alistair Cockburn einig, dass GUI im Use-Case nichts verloren hat.
Ich habe bisher bereits versucht, die Ausprägung der GUI nicht im Use-Case zu beschreiben. Dass der Benutzer "klickt" schließt z. B. aus, dass es ein Tastenkürzel gibt... Wörtliche Bezeichnung von Buttons wie "weiter" sind ebenfalls gefährlich, weil das Wording erst weit nach der Use-Case-Erstellung bestimmt wird - und hier schon im Use-Case vorgegeben wird.

In meinen Use-Cases habe ich die Funktion beschrieben, welche dem Benutzer zur Verfügung steht. Z. B. auch den Seitenwechsel einer Suchergebnisliste. Z. B.:
7. Das System zeigt die Suchergebnisliste an (okok, Ergebnisliste ist hier nicht definiert ;-)
8. Der Benutzer wählt die Anzahl der angezeigten Einträge:

• 10 (default)
• 25
• 50

9. Das System zeigt die entsprechende Zahl von Ergebnissen an.
10. Der Benutzer wechselt auf die nächste Seite.
11. ...

Diese Funktionen sind Anforderungen an die GUI! Insbesondere werden diese Anforderungen im Wireframe beschrieben (siehe Artikel "Wireframes und Use-Cases").

Ein Wireframe beschreibt zwar nur das Vorhandensein eines Dropdowns mit den Einträgen 10 (default), 25 und 50. Anstatt diese Information jedoch in Wireframe und Use-Case redundant zu dokumentieren, würde ich den Wireframe um eine Notiz ergänzen, in welcher der funktionale Zusammenhang des Dropdowns beschrieben ist.

Scott Sehlhorst schreibt einen interessanten Artikel über Business Requirements, dass sie relativ stabil sind. Die Bedingungen eines Geschäfts, also der Markt in dem das Geschäft agiert, ändern sich relativ langsam. Im Vergleich zu den System Requirements sind die Business Requirements also relativ stabil.
Geht man bei der Analyse von den stabilen Business Requirements aus und verbindet die System Requirements streng mit den Business Requirements, desto stabiler wird die Systemspezifikation.
Wichtig ist noch, den Scope eines Projekts in Bezug auf die Business Requirements zu definieren, um Scope Creep zu verhindern.
Sein Fazit ist, dass Business Requirements essenziell und wichtig für ein Projekt sind, insbesondere wenn die System Requirements nicht einfach sind.

Interessant in diesem Zusammenhang finde ich die weiteren Faktoren, welche bei der Definition der System Requirements berücksichtigt werden. Die System Requirements werden aufgestellt auf Basis der Business Requirements, von Randbedingungen / Einschränkungen des Lösungsraums sowie der Kreativität.
Wie oft ändern sich Randbedingungen?
Der kreative Anteil der System Requirements ist sicher nicht sehr stabil. Schließlich basieren diese auf den Erfahrungen aus ähnlichen Systemen, aus verfügbaren Technologien und aus üblichen Ansätzen in ähnlichen Problemstellungen. Diese ändern sich in der IT relativ schnell. Jeder weitere befragte Stakeholder kann theoretisch eine andere Meinung haben und die bisherige Kreativität infrage stellen...

Scott Sehlhorsts Erklärung der Business Requirements greift mir allerdings etwas zu kurz: Sie wären das "was", während die System Requirements das "wie" beschreiben. Ja, das stimmt, aber... (vgl. "Was und Wie")
Meine Erklärung im Artikel über Business Goals gefällt mir noch immer ganz gut...

Dennoch teile ich Scott Sehlhorsts Schlussfolgerung, dass Business Requirements die wichtige Basis für jedes Software-Projekt sind. Ohne sie fehlt die wichtigste Basis für System Requirements und deren Priorisierung.

Scott Sehlhorst hat auf Tyner Blain eine interessante Methode "Estimating With Use Case Points (alternativer Artikel bei methodsandtools.com) vorgestellt, um den Aufwand für ein Software-Projekt vorherzusagen. Entwickelt wurde die Methode von Gustav Karner bei Rational Software Corporation Mitte der neunziger Jahre.

1. Technische Faktoren
Im ersten Schritt werden nicht-funktionale Anforderungen bewertet. Z. B. bewirken die Faktoren verteiltes System, hohe Usability-Anforderungen, einfache Installation oder kritische Antwortzeiten einen erhöhten Aufwand.

2. Umgebungs-Faktoren
Anschließend wird in der Methode die Umgebung betrachtet, in der das Projekt abläuft. Z. B. die Erfahrung des Projektteams, die Motivation und Anforderungs-Stabilität.

3. Use-Cases
Der dritte Schritt ist die Bewertung der Komplexität der Use-Cases. Komplexere Use-Cases sind aufwendiger umzusetzen.

4. Aktoren
Zuletzt werden die Anwender des Systems bewertet. Einfache Aktoren sind Nachbarsysteme, die das System über eine definierte API ansprechen. Komplexe Aktoren sind Anwender, die das System über eine flexible (z. B. AJAX) Oberfläche nutzen.

Für die Projekte bei Spirit Link ist die Aufwandsschätzung eine ständige Herausforderung, da wir Festpreisprojekte anbieten. Schätzen wir zu niedrig, müssen wir draufzahlen, schätzen wir zu hoch, bekommen wir das Projekt nicht. Wir haben hier eigene Methoden entwickelt, um in kurzer Zeit eine relativ genaue Schätzung zu bekommen.

An Karners Methode gefällt mir gut, dass nicht-funktionale Anforderungen und "weiche" Projektfaktoren eine explizite Rolle spielen.
Im Prinzip werden bestimmte Faktoren bewertet und gewichtet, und aus dem Ergebnis der Aufwand abgeleitet. Interessant sind die Faktoren, die in der Methode einbezogen werden.
Bei der Lektüre der Artikel habe ich keine Überraschungen erlebt. Bei jedem der Faktoren ist es einleuchtend, dass er Einfluss auf den Aufwand des Projekts hat. Selten habe ich aber eine so kompakte und knackige Zusammenfassung gesehen.

Um ein Projekt planen zu können, müssen die Faktoren mit Einfluss auf den Entwicklungsaufwand bekannt sein. Als Business Analyst ist es also meine Aufgabe, die Faktoren möglichst früh in einem Projekt in Erfahrung zu bringen. Dafür ist natürlich eine Art "Checkliste" interessant, um keinen der Faktoren zu vergessen. Genau diese Liste liefert die Methode.
Um meinen Teil der Aufwände in einem Projekt zu schätzen, also die Analyse und Spezifikation, sind diese Faktoren ebenso relevant.

Seit einiger Zeit beschäftige ich mich gedanklich damit wie wir in unseren Projekten durch eine inkrementell/iterativen Vorgehensweise profitieren können.
Methodisch sind wir bei Spirit Link soweit, den nächsten Schritt im Vorgehensmodell zu gehen. Jetzt müssen die inkrementell/iterativen Prinzipien noch auf die Eigenschaften der Projekte bei Spirit Link angepasst werden. Vorteile finden sich genügend.

Wir spezifizieren Use-Cases, die sich grundsätzlich sehr gut eignen, auf Inkremente zu verteilen. Ausgehend von einer Grobanalyse können wir die ersten Inkremente planen. Unsere Zusammenarbeit mit Kunden ist typischerweise eng und partnerschaftlich. Gute Voraussetzungen eigentlich, um inkrementell/iterativ zu entwickeln.
Wir müssen die Use-Cases "nur" noch nach ihrem Wert für den Kunden sowie nach ihrem Risiko bewerten - fertig ist die Iterationsplanung (naja, so ungefähr :).

Vorteile für unsere Kunden:
- hohe Sicherheit, dass das Richtige entwickelt wird
- Einflussmöglichkeiten vor dem Rollout
- früher ROI, wie z. B. Scott Sehlhorst argumentiert

Vorteile für uns:
- Projektrisiken können früh im Projekt erkannt werden
- Höhere Effizienz durch kürzeren Abstand von Konzeption und Umsetzung
- Hohe Lernkurve innerhalb eines Projekts, nicht erst für das nächste Projekt

Dennoch bleiben einige Fragen offen:
- Können Konzept und Umsetzung in dieselben Inkremente geschnitten werden? Oder muss ich doch alles konzipieren, bevor die (iterative) Umsetzung starten kann?
- Spielt der Kunde mit? Wie verkaufen wir es dem Kunden?
- Was mache ich mit den Änderungswünschen, die der Kunde nach der ersten Iteration hat? Die Reviewzyklen und daraus folgenden Änderungen machen es ja teurer!
- Welche weiteren "agilen" Methoden müssen wir nutzen, damit inkrementell/iterativ funktioniert?

Hier noch ein paar Links zum Thema (ohne gründliche Recherche):
Scott Sehlhorst über Timeboxes
Craig Larmans Artikel über UP (Unified Process) aus seinem Buch "Applying UML and Patterns" und über "Iterative & Evolutionary" aus "Agile and Iterative Development - A Manager's Guide"

Im Artikel "Goal Oriented Requirements" bei Seilevel habe ich dieselbe Diskussion über Ebenen von Anforderungen gefunden wie in meinem Artikel "Abstraktionsgrad von Anforderungen". Die Kollegen von Seilevel treffen dieselbe Aussage, dass eine Anforderung sowohl Ziel als auch Teil der Lösung sein kann, abhängig davon ob man die Anforderungen darunter oder darüber betrachtet.
Ein wichtiger Hinweis ist, dass sich durch diese Beziehung von Anforderungen zur Lösungsbeschreibung, welche wieder Anforderungen für die nächste Ebene stellt, keine hierarchische Struktur von Anforderungen ergibt. Das Ergebnis ist mehr ein in sich zusammenhängendes Netz von Anforderungen.

Im Podcast Interview von Christian Höcht beleuchtet Dr. Gernot Starke die Aufgaben und das Zusammenspiel von Projektleiter, Software-Architekt und Analytiker.
Ich finde das Interview hörenswert, weil Gernot Starke einige wichtige Aspekte der Projektarbeit in klaren Worten beschreibt. Außerdem der trockene Humor von Gernot Starke und die unkonventionellen Fragen von Christian Höcht.

Highlights:

• Der Projektleiter ist ein Katalysator für Kommunikation im Projekt. Er ist dafür verantwortlich, dass die richtigen Leute miteinander kommunizieren.
• Der Analytiker beantwortet nur einen Teil der Fragen. Der technische Projektleiter ist dafür verantwortlich, dass die Detailfragen der Umsetzung geklärt werden.
• Der technische Projektleiter kennt und betreut alle Projektbeteiligten persönlich.
• Der technische Projektleiter trifft Lösungsentscheidungen. Diese betreffen teilweise die Oberfläche / Usability.
• Heute ist es Standard, dass Anforderungen notwendig sind.

Beim Lesen des Wikipedia-Artikels zum Lastenheft bin ich über ein Beispiel gestolpert, das mich zum Nachdenken gebracht hat:

• Das Lastenheft enthält die Kundenforderung: "Es soll ein bemanntes Labormodul für die ISS geliefert werden, das mit dem Space Shuttle dorthin transportiert werden soll."
• Der Auftragnehmer antwortet darauf mit der Spezifikation "Ein zylinderförmiges Druckmodul mit bestimmtem Durchmesser und Länge"

Die Spezifikation passt für mich noch nicht ganz mit der Anforderung zusammen.
Die beiden Anforderungen sind auf unterschiedlichen Ebenen der Pyramide:


Da fehlt mir eine Anforderung dazwischen. Oder?
Ein zylinderförmiges Druckmodul ist sicherlich ein Teil der Lösung der Anforderung oben.
Aber: Ist es ein Teil des Labormoduls oder der Transportverpackung?
Mir fehlt der Kontext der Anforderung. Schön wäre es doch, wenn eine Anforderung auf einer höheren Ebene existiert, die mir diesen Kontext gibt!?

Oder reicht es, die Anforderungen der unteren Ebene zu sammeln, wodurch ein Gesamtbild entsteht und schließlich die Frage beantwortet wird, wie die Anforderung des Kunden gelöst wird?
Allerdings wird es aufwendig, die ganze Spezifikation lesen zu müssen, um eine Anforderung zu verstehen...

Oder ist das Kapitel "Zusammenfassung" der Spezifikation genau die mittlere Ebene?

Interessant wäre außerdem eine Anforderung eine Ebene über der Lastenheftebene. Warum brauche die ISS das bemannte Labormodul? Ist das alte zu klein? Wird das alte ersetzt? Sollen damit neue wissenschaftliche Experimente unterstützt werden?
Abhängig davon stelle ich andere Fragen als Auftragnehmer.

Kürzlich hatte ich einem Projekt mal wieder die Gelegenheit, Business Goals und ihre Bedeutung für ein Software-Projekt zu erklären. Den Gedankengang möchte ich bei dieser Gelegenheit vorstellen.

Business Goals sind ein wichtiger Grundstein für jedes Software-Projekt. Was will das Unternehmen mit dem System erreichen?
Nur wenn die Business Goals bekannt sind, können fundierte Entscheidungen in der Konzeption getroffen werden.

Business Goals beantworten, welche Mehrwerte durch das System geschaffen werden. Jede Entscheidung in der Konzeption kann so an den Mehrwerten gemessen werden - und eine Priorisierung der Requirements wird dadurch erst möglich!
Mithilfe der Mehrwerte kann das Projekt fundiert akquiriert werden (inhouse oder als Auftragnehmer).

Um so erstaunlicher, dass kaum ein Auftraggeber über Business Goals nachdenkt. Ich habe die Erfahrung gemacht, dass die Business Goals zwar intuitiv erkannt werden, aber selten explizit formuliert werden. Als Konzepter benötige ich allerdings die Business Goals, um meinen Kunden zu beraten und schließlich den größten Wert für die Anwender und das Unternehmen herzustellen.

Also beginnt mein typisches Projekt damit, dem Kunden zu erklären was Business Goals sind und wofür sie gut sind…
Die Kunden reagieren unterschiedlich - manche sind aufgeschlossen, weil ich sie unterstütze, internes Buy-In zu betreiben. Andere sind verärgert, weil ich ihnen unterstelle, ihre Business Ziele nicht zu kennen.

Immerhin kann ich inzwischen gut erklären, was Business Goals sind: Der Mehrwert, den das Unternehmen mit dem System erreicht.
Und zwar konkreter als "Gewinn" oder "Effizienz in Projekten"… Abstrakter als "ein xyz-Verwaltungs-Tool"
Einen Schlüssel dazu liefert die Pyramide der Abstraktionsebenen der Requirements. Durch die Frage, wie der Gewinn / die Effizienz mit dem System verbessert wird und durch die Frage, warum das xyz-Verwaltungs-Tool benötigt wird, komme ich sehr gut auf die richtige Ebene ("Was und Wie").
Wichtig ist nur noch, den Stakeholder mit Sinn für Geld (Mehrwerte) und Interesse für die Prozesse (Prozessanalyse) zu befragen.

Ich habe mal wieder in meinem Lieblings-Use-Case-Buch von Alistair Cockburn, "Writing effective Use Cases" geschmökert und mich über seine Zeichnung der Abstraktionsebenen von Use-Cases gefreut (eine Rohfassung davon gibt es hier in einem lesenswerten Artikel über Use-Cases). Er unterscheidet 5 Abstraktionsebenen von Anforderungen (Use-Cases) und beantwortet die Frage, wie diese Ebenen zusammenhängen.
Tiefere Use-Cases beschreiben, wie ein Use-Case gelöst wird. Use-Cases darüber beantworten, warum der Use-Case benötigt wird.
Durch die Fragen "Wie?" und "Warum?" kann man also Anforderungen unter bzw. über einer gegebenen Anforderung ermitteln.

Ein spannender Kommentar von Rolf Götz zum Artikel "Was und Wie" regt zum Nachdenken über Service-orientierte Archtektur (SOA) und Requirements Engineering an.

Ich denke, bei SOA sind Anforderungen für verschiedene Kontexte wichtig.
Zum einen im Kontext des Unternehmens, fokussiert auf die Geschäftsprozesse, zum anderen im Kontext jedes einzelnen Services.
- Unternehmenskontext: Welche Anforderungen ergeben sich durch die Geschäftsprozesse im Unternehmen an eine IT-Landschaft? Eine SOA hat den expliziten Auftrag, die Geschäftsprozesse duch Komposition verschiedener Services zu unterstützen.
- Service-Kontext: Die SOA zerlegt die Anforderungen des Unternehmens in verschiene Services und bildet die Anforderungen auf jeden einzelnen Service ab.
Die SOA beantwortet das "Was" der Anforderungen des Unternehmenskontexts durch ein "Wie" aus der Kombination von Services. Für jeden Service ergeben sich neue Anforderungen "Was".

Rolf: diese Kontexte sind andere Ebenen als die Abstraktionsebenen. Innerhalb eines Kontexts können Anforderungen auf allen Abstraktionsebenen formuliert werden.

In meinem (bislang einzigen expliziten) SOA-Projekt entwickelten wir eine modellbasierte Definition von Prozessen zur Bearbeitung von elektronischem Belegverkehr. Auf oberster Ebene bilden die Prozesse für Kunden sichtbare Verarbeitungsprozesse ab. Die einzelnen Schritte des Prozesses bestehen wiederum aus (technischeren) Prozessen. Prozesse rufen tiefere Prozesse, bis am untersten Ende Code-Routinen über Webservices gerufen werden. Die Tiefe der Aufrufhierarchie ist nicht im Voraus festgelegt.
Die IT stellt Services zur Verfügung, die von den Beratern vor Ort zu kundenspezifischen Verarbeitungsprozessen zusammengestellt werden.
Unsere Leistung war es, die möglichen Strukturen zu definieren, wie Prozesse und Webservices in Zusammenhang stehen können. Wir erstellten außerdem den Editor, mit dem die Prozesse erstellt und konfiguriert werden können.
In dieser Lösung gibt es die Geschäftsprozess-Sicht, deren Anforderungen durch die Berater beim Kunden definiert werden, sowie die Service-Sicht, die durch die Techniker in der IT zur Verfügung gestellt werden.

Für mich als Business Analyst ist SOA eine Besinnung auf die Regel, dass jede Software letztlich den Geschäftsprozess unterstützen muss. Die gesamte Software eines Unternehmens muss im Rahmen der Geschäftsprozesse nützlich sein und dazu zu einer Gesamt-Unterstützung für das Geschäft komponiert werden. Die IT hat den Auftrag, die Arbeit des Unternehmens zu unterstützen.
Die zahlreichen Artikel der Computerwoche zum Thema SOA und CIO haben genau das zum Thema, z. B. im Artikel "Prozessorientierung statt Produktionstiefe".
Ed Yourdon hat in seinem Blog im Artikel "CIO Insight’s predictions of 30 top IT trends for 2007" eine interessante Studie kommentiert, deren Top 1 Trend "Process improvement will be job No. 1" und Top 8 Trend "The division between IT and business will diminish" klar die Ausrichtung auf das Geschäft beschreiben.

Scheint so, dass mein Job als Business Analyst immer spannender und wichtiger wird :-)

Nicht-funktionale Anforderungen sind nach wie vor ein schwieriges Kapitel in jedem Pflichtenheft. Ich erlebe häufig, dass Kunden nicht an Qualität denken, bevor ich sie dazu zwinge ;-)
Schlimmer ist, dass sich auch viele Analytiker schwer tun, nicht-funktionale Anforderungen zu fassen.
In meinen letzten Projekten hatte ein paar spannende Berührungspunkte mit der Dienstleistungsqualität und so sind ein paar Gedanken entstanden, die ich hier in einen Artikel gieße.
Statt dem Begriff "nicht-funktionale Anforderungen" verwende ich gerne "Dienstleistungsqualität" oder allgemein "Qualität". Die Anforderungen klingen einfach zu sehr nach dem oberen Drittel der Abstraktionspyramide.

Qualität gibt es auf jeder Ebene
Qualität ist kein Ding von Lastenheften, die im Pflichtenheft durch eine funktionale Spezifikation "gelöst" werden.
Sicher gibt es Anforderungen, z. B. zur Sicherheit, die im Pflichtenheft (teilweise) durch Funktionalität gelöst werden, z. B. durch ein Login.
Im Allgemeinen gibt es aber auf jeder Ebene von Anforderungen ein "wie gut". (Siehe auch den lesenswerten Kommentar von Rolf Götz zum "Was und Wie".)
Z. B. lässt sich die Sicherheit nicht nur als Funktion beschreiben, die Sicherheitslücken schließt, sondern eben auch als Qualität des Codes, der keine Lücke offen lässt.
Ein anderes Beispiel ist die Erweiterbarkeit, die ein Kriterium von gutem Code ist.

Qualitätsanforderungen sind Risikofaktoren
Eine vergessene funktionale Anforderung führt zu Ärger und zu Nachbesserung. Eine vergessene Qualitätsanforderung führt zum Scheitern des Projekts!
In einem unserer Projekte plante unser Kunde eine Lösung für die interne Nutzung, besann sich dann gegen Ende des Projekts jedoch darauf, sie auch über das Internet jedermann zugänglich zu machen. Die Funktionalität blieb dieselbe, die Software musste nur ins Internet gestellt werden.
Niemand denkt an Sicherheitsaspekte, die plötzlich so wichtig werden wie die Funktionalität.
Plötzlich werden Qualitätsabteilungen hellhörig, die IT des Unternehmens wurde aufmerksam. Vorher unbeteiligte Personen schalten sich ein und die Software wird politisch relevant, die Kreise werden größer. Mit einem Mal ist eine erfolgskritische Anforderung "Sicherheit" relevant!
Unser Kunde ist baff und wir reden plötzlich mit vielen Menschen statt mit einem Kunden. Die Software muss (fast) neu geschrieben werden...

Qualitätsanforderungen sind einfach
Zumindest auf hoher Abstraktionsebenen ist es einfach, Qualitätsanforderungen aufzustellen. Damit sind zumindest die größten Risiken eines Projekts abgedeckt. Ich nutze eine Checkliste mit wenigen Aspekten wie Sicherheit, Usability, Effizienz, um die Anforderungen zu prüfen. Checklisten bieten z. B. DIN 66272 oder Volere.
Eine größere Herausforderung ist, die Qualität der Software messbar zu machen. Ich finde das Prinzip von GQM praktisch, ein anderer Ansatz ist Planguage von Tom Gilb.

Klassische textuelle Spezifikationen sind für viele Stakeholder nicht gut verständlich. Sie tun sich schwer, sie in ihre Problemstellung zu übersetzen.
Ein Papierprototyp mit Wireframes zeigt, wie die spätere Anwendung aussehen wird. Insbesondere für Kunden und Anwender bieten sie die Möglichkeit, die Anwendung durchzuspielen und ermöglichen ihnen, das Konzept zu prüfen.

In unseren Projekten setzten wir die Wireframes ursprünglich lediglich als Präzisierung einer vorhandenen funktionalen Spezifikation sowie zur Usability-Konzeption ein.
Inzwischen nutzen wir Wireframes in der frühen Konzeptionsphase um das Konzept von Stakeholdern prüfen zu lassen. Use-Cases werden durch Abfolgen von Wireframes beschrieben. Der Konzepter spielt Anwendungsfälle mit den Stakeholdern durch und beschreibt das Verhalten der Anwendung.
Die Wireframes können dabei so weit gehen, das nicht sichtbare Verhalten in Notizen zu dokumentieren und können so sogar die funktionale Spezifikation umfassen.

Ich nutze gerne textuell beschriebene Use-Case-Szenarien als strukturiertes Vorgehen, um ein Konzept zu entwerfen. Zur Kommunikation mit Kunden und Anwendern verwende ich dennoch fast ausschließlich die Wireframes. In einem Workshop lese ich Use-Cases und zeige dem Kunden die Wireframes.

Warum sind Use-Case-Szenarien so schwer verständlich? Sie beschreiben einen typischen Ablauf eines Anwenders in seiner Sprache. Von allen textuellen Spezifikationen finde ich Use-Cases am leichtesten verständlich (siehe Artikel).
Trotzdem tun sich Stakeholder schwer! Weil die Use-Cases eine Abstraktion beschreiben, die für Stakeholder ungewohnt ist.
In unseren typischen Projekten sind Stakeholder schließlich keine erfahrenen Software-Ingenieure, sondern Anwender. Marketing-Leiter, Geschäftsprozess-Experten oder Projektleiter, die nur selten RE-Hintergrund besitzen.
Wirklich vorstellen können sich Anwender eine Applikation nur anhand eines Prototypen. Wireframes sind nah genug an der Anwendung, um als (Papier-)Prototyp den Anwendern zu vermitteln, wie die Anwendung funktioniert. Sie können dann ihren Arbeitsablauf mit der neuen Anwendung verbildlichen und Stolpersteine und Erleichterungen erkennen.

Wireframes können in unterschiedlichen Abstraktionstiefen erstellt werden (siehe Abstraktionsebenen). Ich erstelle bereits in einer Grobkonzeption Wireframes, die einen Ablauf verdeutlichen. Mit den richtigen Werkzeugen geht das sehr schnell und ich bekomme sehr schnelles Feedback von den Stakeholdern.

Auf Ed Yourdons Website ist ein Online-Buch über strukturierte Analyse verfügbar - aktuell bis Kapitel 16. Strukturierte Analyse ist nicht mein Spezialgebiet, hier sind trotzdem viele spannende Methoden, Ideen und Ansätze beschrieben - online verfügbar.
Z. B. Ansätze um Prozesse zu spezifizieren. Einige davon kenne ich noch aus der Uni... Hier sind sie umfassend und gut beschrieben.

Ed Yourdon ist ein Urgestein der IT. Kaum ein Thema, bei dem er nicht aktiv war und ist. Mitentwickler der OO-Methodik nach Coad/Yourdon beschäftigt er sich aktuell mit Web 2.0. Schön zu sehen, dass Ed Yourdon nicht von der UML abgelöst wurde sondern weiter gute Ideen produziert!

Ich bin über einen interessanten Ansatz zum Requirements Engineering von nicht funktionalen Anforderungen gestoßen, dem aspektorientierten RE.
Aspektorientierte Programmierung ist eine Methode, um querschnittliche Themen wie Sicherheit, Verfügbarkeit, Persistenz in der Software-Architektur zu kapseln. In der klassischen Objektorientierung ist dies schwer möglich, weshalb die Aspektorientierung neue Konzepte eingeführt hat.

Das aspektorientierte Requirements Engineering führt explizite Methodiken ein, um diese querschnittlichen Aspekte in der Spezifikation separat zu beschreiben.
Es ist vielleicht nicht neu, nicht funktionale Anforderungen separat zu dokumentieren. Hier werden explizite Vorteile davon beschrieben. Z. B. ist die Verbindung zur Software-Architektur (aspektorientiert!) sehr einfach.
Außerdem wird immer wieder die Wichtigkeit dieser Anforderungen als Grundlage für die Architektur betont.
Ich nehme mir die Artikel zum Thema vor, in der Hoffnung auf weitere Anregungen - auch wenn bei Spirit Link nicht aspektorientiert programmiert wird...

Referenz: Early Aspects.net

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.

Auf der EuroIA zeigte mir Casper Honijk in irgendeiner Diskussion ein Bild über Abstraktionsebenen von Anforderungen, das genauso wie meins aussah!
Was mich bestätigt, dass ich auf dem richtigen Weg bin :-)


Casper nutzt die Namen der Ebenen für die Kommunikation über seinen Konzeptions-Prozess mit seinen Kunden. Z. B. macht er deutlich, dass ein Lastenheft des Kunden nur die "Needs" beschreibt, bis zum Requirements aber noch viel Arbeit auch des Kunden nötig ist.

Interessant fand ich, dass er die verschiedenen Ebenen verknüpft und eine durchgängige Traceability erzeugt. (Würde mich sehr interessieren, dies in Aktion zu sehen – ich bin nicht überzeugt, dass Traceability grundsätzlich funktioniert!)
Auf diese Weise ist z. B. sichergestellt, dass ohne Needs keine Requirements entstehen. Findet der Analytiker kein Bedürfnis, wird auch keine Software dazu erstellt.

Die Namen der Ebenen sind einerseits eine gute Idee, allerdings würde ich sie anders benennen...
Gut, weil sie die Kommunikation mit Anwendern unterstützen. Die Namen sind einfach weitere Bezeichnungen neben "Lastenheft" und "Pflichtenheft".
Ich hätte die Needs "Requirements" genannt. Huch, die stehen ja wo anders...

Die Strategie oder die Ziele einer Applikation sind grundlegende Entscheidungen bei ihrer Entwicklung. Manchmal ist es allerdings schwer, diese Entscheidungen zu treffen.
Viele Kunden haben nicht die Erfahrung oder können aufgrund der Abstraktheit der Strategie und der Ziele diese Entscheidung nicht treffen.

In seinem Vortrag über IA Strategy nannte Olly Wright auf der EuroIA 2006 die Personas als guten Startpunkt für eine Strategiediskussion.
Personas beschreiben, welche Anwender mit welchen Zielen das System verwenden. Siehe auch Wikipedia.
Auf ihrer Grundlage kann die Strategie ermittelt werden. Die Strategie beschreibt letztlich, welche Anwender welches Ergebnis erreichen können sollen. Sie hat daher direkte Auswirkung auf die Personas.
Im ersten Schritt stellt der Analytiker mögliche Personas auf, die dann im Workshop mit den Kunden verifiziert werden.

Ein Ansatz für die Strategie- oder Zielediskussion sind konkrete Konzeptions-Ergebnisse, die möglichst direkt aus der Strategie und den Zielen resultieren, wie z. B. Personas oder Use-Cases. Auf ihrer Grundlage können dann wieder Rückschlüsse für die Strategie und die Ziele getroffen werden.

Ich bin gespannt, dieses Vorgehen auszuprobieren. In meinem letzten Projekt, das aufgrund unklarer Ziele litt, wäre dies sicher anstrengend gewesen, hätte aber zum Erfolg führen können...