Das akkumulierte Wissen

Das bei der Anforderungsermittlung gesammelte Wissen ist die Grundlage fü r die Syste­mentwicklung. Wie Sie das Wissen in Anforderungen dokumentieren, hä ngt sehr stark vom, gewä hlten V or^ehensmodell ab, SrWprgrwirRri ge Modelle schlagen Dutzende vo n (A^tefaktep'vö rT^Ie" im Laufe der Systementwicklung erzeugt werden sollen. Artetakte stellen" dokumentierte Ergebnisse eines definierten Entwicklungsschritte dar, also zum Beispiel eine Anforderungsspezifikation oder den implementierten Code einer SW-Komponente.

Leichtgewichtige und agile Prozesse, allen voran eXtreme Programming, dokumentieren viele Entscheidungen im Code und lassen nur wenige weitere schriftliche Dokumente zu, da fü r diese Pflegeaufwand anfä llt.

Wir empfehlen Ihnen, die Art der Dokumentation von den Zielen und Randbedingungen Ihres Projektes abhä ngig zu machen und so wenig wie mö glich, aber so viel wie nö tig zu dokumentieren. Sind Sie auf der Seite des Auftraggebers und mö chten Sie eine grobe Spezifikation fü r den ersten Schritt eines Ausschreibungsprozesses erstellen? Arbeiten Sie ebenfalls als Auftraggeber an einer Spezifikation, die Sie fü r eine Offshore-Entwicklung verschicken mö chten, bei der ein Fixpreis fü r die Entwicklung hart verhandelt wird? Oder sind Sie auf der Seite des Auftragnehmers und mö chten ein sehr detailliertes Pflichtenheft erzeugen?

In Kapitel 1 „In medias RE" haben wir die Metapher des Requirementsgehirns eingefü hrt. Darin wird sich das Wissen ü ber die Anforderungen sammeln. Im realen Projektgeschä ft muss es das Ziel sein, das von anderen Stakeholdern benö tigte Wissen aus dem Requirementsgehirn explizit zu machen. Bei diesem Schritt des Dokumentierens wird ein positiver Nebeneffekt auftreten: Sie werden die weiß en Flecken in Ihrem Requirementsgehirn entde­cken und kö nnen somit gezielt auf ihre Stakeholder zugehen, um die fehlenden Stellen zu ergä nzen.

3.1.3 Eine Anforderung ist wie ein Chamä leon...

Anforderungen ä ndern sich im Lauf der Zeit. Ein wichtiger Bestandteil der Systemanalyse ist es daher, mit diesen Ä nderungen umzugehen.

Sich ä ndernde Anforderungen sind meist nicht nur auf mangelhaftes Requirements-Enginee­ring, sondern auch auf projektexterne Faktoren zurü ckzufü hren. Wenn sich beispielsweise Geschä ftsprozesse eines Unternehmens ä ndern, ä ndert sich die von einem System benö tigte Unterstü tzung dieser Prozesse. Zudem haben Stakeholder zu Beginn eines Projekts oft keine prä zise Vorstellung vom System und stellen zunä chst Vermutungen ü ber sein Verhalten an. Mit fortschreitendem Projekt prä zisieren die Stakeholder ihre Vorstellung und ä ndern dadurch die anfangs genannten Anforderungen.

Verschiedene Vorgehensmodelle (siehe den folgenden Abschnitt) haben unterschiedliche Strategien, mit Anforderungsä nderungen umzugehen. In einem Vorgehen nach dem klassi­schen Wasserfall-Modell ist nach der Analyse-Phase keine weitere Analyse vorgesehen. Der schwergewichtigere Rational Unified Process empfiehlt dagegen Requirements-Management als Best Practice und definiert eine Disziplin, um Requirements-Tracing zu ermö glichen und Ä nderungen an den Anforderungen wä hrend des gesamten Entwicklungsprozesses zu ver­walten. Agile Prozesse versuchen noch stä rker, Ä nderungen einzubinden und die Stakeholder „Sogar zu Ä nderungen zu ermutigen. Das entstehende System soll sich mö glichst nah an den aktuellen Bedü rfnissen der Anwender orientieren. In kurzen Iterationen werden stä ndig neue Anforderungen ermittelt und realisiert. Stakeholder haben jederzeit die Mö glichkeit, geä nderte Anforderungen einzubringen.