Anforderungsmanagement in sieben Tagen: Der Weg vom Wunsch zur Konzeption

Von Thomas Niebisch

Obwohl professionelles Anforderungsmanagement als unbestrittene Notwendigkeit für den Erfolg von IT-Projekten gilt, werden die dafür erforderlichen Kenntnisse oft nur einzelnen Spezialisten zugeschrieben. Das Ergebnis der IT-Projekte könnte deutlich positiver ausfallen, wenn maßgebliche Projektbeteiligte wie Projektmanager, Entscheidungsträger oder Fachspezialisten ebenfalls mit den wesentlichen Aspekten des Anforderungsmanagements vertraut wären. Diesem Gedanken folgend ist es an der Zeit, das Anforderungsmanagement für Jedermann verständlich vorzustellen.

Dieses Buch beschreibt anhand einer konkreten Aufgabenstellung alles Wissenswerte rund um das Anforderungsmanagement für diejenigen, die mit IT-Anforderungen konfrontiert werden, ohne selbst Anforderungsmanager zu sein. Didaktisch ist der zu vermittelnde Inhalt auf sieben Tage verteilt, an denen die Vorgehensschritte durch zwei handelnde Protagonisten diskutiert werden.

• Sprache: Deutsch
• Herausgeber: Springer Gabler
• Erscheinungsdatum: 9. Apr. 2013
• ISBN: 9783642348570

Buchvorschau

Thomas NiebischAnforderungsmanagement in sieben Tagen2013Der Weg vom Wunsch zur Konzeption10.1007/978-3-642-34857-0_1© Springer-Verlag Berlin Heidelberg 2013

1. Wer das Buch lesen sollte

Thomas Niebisch¹  

(1)

Bereich Systems Engineering, und Entwicklung, GISA GmbH, Leipziger Chaussee 191a, 06112 Halle (Saale), Deutschland

Thomas Niebisch

Email: [e-mail]

Zusammenfassung

Ihr Griff zu einem Buch mit diesemTitel lässt mich vermuten, dass Sie bereits in Ihrem beruflichen Alltag mit dem Thema IT-Anforderungsmanagement in Berührung gekommen sind; sei es durch die Einbindung in IT-Projekte, die Formulierung von Anforderungen oder dem Treffen wichtiger Entscheidungen im IT-Umfeld. Aber Hand aufs Herz: Sie gehören zur großen Gruppe derer, die keine Informatiker sind! Sie empfinden Spezifikationen als Bücher mit sieben Siegeln und geben Konzepte oft nach Ihrem Bauchgefühl frei! Ihre fachlichen Anforderungen werden von den IT-Spezialisten oft anders verstanden als Sie es meinten!

Dann gehören Sie exakt zu dem Personenkreis, den ich mit diesem Buch ansprechen möchte.

Ihr Griff zu einem Buch mit diesem Titel lässt mich vermuten, dass Sie bereits in Ihrem beruflichen Alltag mit dem Thema IT ¹ -Anforderungsmanagement in Berührung gekommen sind; sei es durch die Einbindung in IT-Projekte, die Formulierung von Anforderungen oder dem Treffen wichtiger Entscheidungen im IT-Umfeld. Aber Hand aufs Herz: Sie gehören zur großen Gruppe derer, die keine Informatiker sind! Sie empfinden Spezifikationen als Bücher mit sieben Siegeln und geben Konzepte oft nach Ihrem Bauchgefühl frei! Ihre fachlichen Anforderungen werden von den IT-Spezialisten oft anders verstanden als Sie es meinten!

Dann gehören Sie exakt zu dem Personenkreis, den ich mit diesem Buch ansprechen möchte.

Grund-Satz

In Ihren Händen halten Sie ein Buch für Fachexperten, Führungskräfte, Projektmanager und andere in IT-Projekte involvierte Rollen, die sich mit Anforderungen auseinandersetzen müssen, ohne selbst Spezialisten des Anforderungsmanagements zu sein.

Das Buch ist weniger für Anforderungsmanager, Requirements Engineers, Business Analysten oder weitere Akteure gedacht, deren Tätigkeit in der professionellen Anforderungserhebung liegt. Es versteht sich von selbst, dass diese trotzdem herzlich eingeladen sind, Ihren persönlichen Wissen- und Erfahrungsstand an dem Geschriebenen zu spiegeln.

Mein Ziel ist es, allen Lesern das Anforderungsmanagement als eine Disziplin mit großer methodischer und kommunikativer Vielfalt näher zu bringen. Ich möchte Ihnen die Welt des Anforderungsmanagements so weit erläutern, dass Sie es als Bereicherung empfinden und damit verbundene Aufgaben erfolgreicher und gelassener in Angriff nehmen können. Wir werden gemeinsam die Projektphase, die Sie mit hoher Wahrscheinlichkeit unter der Bezeichnung Konzept erstellen aus dem täglichen Projekt- und Berufsleben kennen, im Detail betrachten. Zur Vorbeugung gegen Missverständnisse sei darauf hingewiesen, dass ich unter Anforderungsmanagement nicht nur das Verwalten, sondern ergänzend auch das Erheben, Analysieren, Dokumentieren und Qualitätssichern verstehe.

Aber was ist meine Triebfeder, dem Buchmarkt ein weiteres Werk über das Anforderungsmanagement hinzuzufügen? Ist nicht alles Wissenswerte bereits niedergeschrieben worden? Mit hoher Wahrscheinlichkeit ist es das. Allerdings sind die meisten Bücher an Experten gerichtet und behandeln das Anforderungsmanagement sehr tiefgründig. Für viele Projektmitarbeiter ist solch eine Expertenpublikation eine echte Herausforderung. Meiner Meinung nach sollten aber gerade diejenigen, die Anforderungen an eine IT-Lösung stellen, einen auf sie zugeschnittenen Einblick in das Thema Anforderungsmanagement erhalten, oder nicht?

Zumindest wäre es zum Vorteil für die Projektqualität. Mangelhaftes Anforderungsmanagement wird immer wieder als Grund für viele gescheiterte Projekte angeführt und als deren Achillesferse bezeichnet. Nach meiner Beobachtung hat aber die Distanz zwischen den in Büchern theoretisch aufgezeigten bestmöglichen Mitteln und Möglichkeiten und deren praktischer Lebendigkeit in Projekten in den letzten Jahren kaum abgenommen. Zwar mag diese These branchen- oder projektspezifisch geprägt sein, aber der Eindruck bleibt bestehen, dass das Anforderungsmanagement oftmals im Status des schwer zu Bewerkstelligenden verharrt. Eine Ursache dafür sehe ich darin, dass es von nur relativ wenigen Spezialisten Beachtung findet; für die anderen bleibt es bestenfalls das unumgängliche Konzept erstellen. Aber Anforderungsmanagement wird IT-Projekten erst dann den richtigen Erfolg verleihen, wenn sein Grundlagenwissen ein weit verbreitetes und akzeptiertes Gedankengut ist. Der Anforderungsmanager bleibt weiterhin der Spezialist des Themas, aber möglichst viele Projektbeteiligte sollten seine Methodik kennen. Dieser Überzeugung folgend finde ich ein Buch Anforderungsmanagement für Jedermann schon längst überfällig. Oder etwas salopper formuliert:

Grund-Satz

Anforderungsmanagement ist für alle wichtig!

Indem Sie zu diesem Buch greifen, zeigen Sie als Leser Ihr grundsätzliches Interesse am Anforderungsmanagement. Wahrscheinlich nimmt es aber eher einen Randbereich als den Mittelpunkt Ihrer beruflichen Tätigkeit ein und dient nur dem Zweck, Ihre Ansprüche an die IT zu formulieren. Dies stellt mich vor die Herausforderung, Ihnen das Wesentliche zum Thema zu erläutern ohne zu langweilen. Mein Vorschlag ist, Sie innerhalb des Buches einem Anforderungsmanager in Aktion über die Schulter schauen zu lassen. Sie können als Leser aus dessen gezeigten Modellen und Methoden Ihre persönlichen Favoriten wählen, die Ihnen bei der Formulierung, Strukturierung und Visualisierung Ihrer eigenen Anforderungen an eine IT-Lösung am hilfreichsten erscheinen. Verfeinern Sie Ihre eigene Sensibilität gegenüber dokumentierten Anforderungen und daraus abgeleiteten Lösungsansätzen. Verinnerlichen Sie die Überzeugung, das Projekt frühzeitig durch professionelles Anforderungsmanagement auf den richtigen Weg zu bringen und Projektentwicklungen zu vermeiden, vor denen schon Franz Joseph Strauß warnte: „Wenn der Zug in die falsche Richtung fährt, dann sind alle einzelnen Stationen falsch."²

Nun gilt Franz Joseph Strauß bekannter Maßen nicht als Protagonist für die IT-Branche, doch sein Ausspruch lässt sich noch allzu oft als Analogie für eine Vielzahl von IT-Projekten heranziehen. Lassen Sie uns kurz gemeinsam abschweifen und ein IT-Projekt als Reise mit der Bahn betrachten. Gönnen wir uns diesen kleinen gedanklichen Umweg, um die Bedeutung des Anforderungsmanagements für den finalen Projekterfolg besser zu verstehen.

1.1 Das IT-Projekt als Zugfahrt

Die grundsätzliche Erwartungshaltung an eine Zugfahrt ist, ruhig und entspannt von A nach B zu gelangen. Der Startpunkt steht fest, das Ziel ist ausgewählt und die Umsteigebahnhöfe sind benannt. Den Zeitplan hat schon jemand berechnet und auf dem Schienennetz fällt das Falschfahren schwer. Theoretisch kann nichts schiefgehen – und bei der Bahn klappt das meistens.

IT-Projekte verlaufen nicht ganz so reibungslos. Wenn man das Gleichnis der Zugfahrt auf die IT überträgt, sind IT-Projekte spannende Zugreisen mit oftmals überraschendem Ausgang. Alles beginnt damit, dass sich eine Reisegruppe findet und beschließt, den Zug als Transportmittel zu nutzen. Rechtzeitig am Bahnsteig wartend (das heißt das Projekt ist geplant) wird ein Projekt-Zug gechartert. Ein professioneller Projekt-Reiseleiter ist gefunden, das Reiseziel scheint auch klar zu sein. Allen Reiseteilnehmern wird ihr Platz zugewiesen. Der Zug setzt sich in Bewegung und voll freudiger Erwartung beginnt die Projekt-Fahrt.

Der Zug fährt eine Weile durch die blühenden Landschaften der initialen Projektplanung. Alles sieht perfekt aus, alles läuft wie am Schnürchen. Plötzlich verändert sich überraschend die Außenwelt. Auf den vorbeirasenden Bahnhofsschildern stehen unbekannte Ortsnamen – nicht mehr die der Projekt-Reiseroute. Es tauchen Wälder auf, wo Felder sein sollten. Anfängliche Befürchtungen, dass sich der Zug nicht mehr entlang der geplanten Strecke bewegt, bewahrheiten sich. Eine Standortbestimmung ist aufgrund fehlender Orientierung nur schwer möglich. Genauso wenig wie ein Umkehren. Einige Reiseteilnehmer stellen fest, dass sie voneinander abweichende Vorstellungen über das Reiseziel hatten und geraten sich darüber in die Haare. Und es kommt noch schlimmer: Der Zug wird auf freier Strecke langsamer. Signale stehen auf Rot, das Projekt wird gestoppt.

Was ist passiert? Mit großer Wahrscheinlichkeit waren bereits die ersten Projekt-Weichenstellungen fehlerhaft. Der Zug wurde ungewollt nicht auf dem Hauptgleis, sondern parallel zu diesem losgeschickt. Er war nur scheinbar in die richtige Richtung gestartet und folgte im weiteren Reiseverlauf zwangsläufig seinem falsch vorgegebenen Gleisbett. Doch die Projekt-Reisenden hatten sich die ganze Zeit auf dem richtigen Weg gewähnt. Mit ihrer Überzeugung, das Reiseziel und damit die Grundlagen für die Streckenplanung bestmöglich erläutert zu haben, unterlagen Sie einer kollektiven Selbsttäuschung.

Wir sind bei einem Hauptgrund für gescheiterte IT-Projekte angekommen; der angemessenen Beschreibung dessen, was man am Ziel der Reise erwartet. Unser Gleichnis fortführend wird in IT-Projekten das Reiseziel mit all seinen Details durch eine Vielzahl von Anforderungen beschrieben. Anforderungen nehmen die Vorstellungen vieler Projektbeteiligter auf und bilden somit für die Planung der Lösung das Fundament, welches entsprechend seiner Qualität massiv oder brüchig ist.

Grund-Satz

Mit der Qualität Ihres Anforderungsmanagements entscheiden Sie, ob Sie Ihr Projekt auf Stein oder auf Sand bauen.

Was war aber in unserem Fall schief gelaufen? Selbstverständlich war auch die eben beschriebene Reise ausführlich geplant worden. Eine Menge Gedanken wurde vor Reiseantritt hin- und her gewälzt. Es wurde zwischen unterschiedlichen Alternativen und Aspekten gewählt, Details wurden gegeneinander abgewogen. Letztendlich hat man ganz klar das Ziel der Reise beschrieben – so dachte jeder. Umso größer ist die Enttäuschung, wenn die Reise nicht an den geplanten Wunschort führt. Doch wo sind die Fehler zu suchen? Liegt es an der Planung? Liegt es an der Kommunikation mit den anderen Reiseteilnehmern? Und: Wer aus der Reisegruppe ist eigentlich für die Planung des Reiseziels verantwortlich?

Schauen wir uns die Aufgabenteilung und Verantwortlichkeiten in der Reisegruppe genauer an: Die Organisation komplexer Reisen wird durch das Projektmanagement wahrgenommen. Ein Projektmanager lädt alle Reisenden ein, koordiniert sie und kümmert sich, dass alle rechtzeitig mit gepackten Koffern am Bahnhof stehen. Seine Aufgabe besteht darin, seine Reisegruppe an das avisierte Ziel zu führen. Er ist der Organisator, Motivator und Kontrolleur. Wie selbstverständlich wird von ihm ebenfalls erwartet, dass er das konkrete Reiseziel detailliert kennt bzw. von den Reiseteilnehmern ermitteln kann. Aber das ist nicht die Aufgabe eines Projektmanagers. Das Ermitteln, Erfassen und ausführliche Darstellen von Reisezielen erfordert Kenntnisse und Fähigkeiten, die andere Reisende mitbringen müssen – in diesem Fall sogenannte Anforderungsmanager.

Grund-Satz

Die Aufgabe von Anforderungsmanagern ist es, die Erwartungshaltung an konkrete Reiseziele, sprich die Anforderungen an IT-Lösungen, in Anforderungsspezifikationen zu beschreiben.

Anforderungsmanager befragen die Reiseteilnehmer zu deren Vorstellungen und leiten ein gemeinsames Verständnis des Reiseziels her. Dazu benötigen sie Spezialwissen, das ihnen bei der für alle Reisenden nachvollziehbaren Beschreibung der IT-Reiseziele hilft. Das Spezialwissen umfasst unterschiedliche Vorgehensweisen, Standards und Methoden. Wie ein Handwerker, der das jeweils passende Spezialwerkzeug aus seiner Werkzeugkiste holt, bringt auch der Anforderungsmanager sein Spezialwissen je nach Situation zur Anwendung. Sie als Leser sollten dabei nicht nur staunend zuschauen, sondern auch das Vorgehen nachvollziehen können.

Der Inhalt des Buches, das Sie gerade in den Händen halten, beschreibt die Durchführung solch einer Reiseplanung. Es wird aufgezeigt, was zu beachten ist, wo überall Fußangeln ausliegen und wie das Anforderungsmanagement helfen kann, diese zu umgehen.

1.2 Das Buch-Beispiel

Ihr Weiterlesen signalisiert, dass Sie sich der erwähnten Zielgruppe zurechnen. Sie möchten Ihre Kenntnisse des Anforderungsmanagements erweitern und erfahren, wie Sie zukünftig Ihre IT-Reiseziele besser beschreiben können. Um diesem Interesse gerecht zu werden, lassen Sie uns gemeinsam ein Buch-Beispiel konstruieren, anhand dessen ich Ihnen die Aspekte des Anforderungsmanagements anschaulich erläutern kann. Das Beispiel sollte kein branchenspezifisches Wissen voraussetzen und trotzdem eine hinreichend überschaubare Komplexität aufweisen. Für diesen Fall nutzen wir ein mittelständisches Unternehmen als Kulisse. Die Sparte, in der das Unternehmen tätig ist, ist für unser Beispiel nicht ausschlaggebend. Wir nehmen an, dass dieses Unternehmen in erster Linie Leistungen für Privatkunden bereitstellt und demzufolge eine Vielzahl an Kundenschreiben verarbeiten muss. Weiterhin unterstellen wir, dass in den Prozessen, die sich mit der Bearbeitung der Kundenpost befassen, spürbare Schwächen zu Tage treten bzw. dass Kundenpost zum Teil erst mit großer Verzögerung bearbeitet wird.

Grund-Satz

Das Beispiel, anhand dessen die unterschiedlichen Aspekte des Anforderungsmanagement vermittelt werden, beinhaltet die umfassende Verbesserung der Kundenpostbearbeitung.

Ausgangspunkt unseres Beispiels ist die typische Aufgabenstellung der Geschäftsführung an die zuständige Führungskraft (den Abteilungsleiter des Kundencenters), Schwächen in den zu verantworteten Prozessen zu beseitigen. Der Abteilungsleiter möchte sich selbst des Themas annehmen und es nicht an andere Kollegen delegieren. In ersten Gesprächen hat er in Erfahrung gebracht, dass es mit der rein organisatorischen Neugestaltung der Prozesse nicht getan ist. Er schlussfolgert daraus, dass er nur mit Hilfe einer geeigneten Software die angestrebte Verbesserung der Prozesse erreichen kann. Folgerichtig bittet er um Unterstützung aus dem IT-Bereich. Diese erhält er in Person eines jungen Kollegen, der sein Informatik-Studium erst unlängst beendet hat und seit kurzem im Unternehmen tätig ist.

Der beauftragte Abteilungsleiter des Kundencenters heißt Hagen, der Jung-Informatiker Ole. Die beiden sind die Protagonisten des Buch-Beispiels und erarbeiten sich die Themen rund ums Anforderungsmanagement vorwiegend in gemeinsamen Gesprächen und Diskussionen. Am besten, die beiden stellen sich erst einmal vor:

Hagen

Mein Name ist Hagen. Ich bin seit gut 15 Jahren in dieser Firma beschäftigt – jetzt bin ich Leiter des Kundencenters. Die Firma, in der ich arbeite, ist nicht riesig, aber auch nicht klein. Wir sind ein gutes mittelständisches Unternehmen. Mir unterstehen mehrere Gruppen, die sich um die Vielzahl der Belange unserer Privatkunden kümmern. Zwei dieser Gruppen sind für die Kundenpostbearbeitung zuständig; eine für Interessenten und Neukunden, die andere für die Bestandskunden.

Ab und zu arbeite ich noch in Projekten mit, auch in IT-Projekten. Leider ging in der Vergangenheit auch schon einiges gründlich schief. Wie letztens. Der Betriebsrat hatte die Einführung einer Anwendung gestoppt, weil sie eine mitarbeiterbezogene Auswertung zuließ. Das war mein Fehler, denn ich hatte nicht auf diesen Aspekt geachtet. Wir konnten die Lösung erst zwei Monate später produktiv setzen und das Budget haben wir auch überschritten. Im nächsten Projekt darf ich mir solche Fehler nicht mehr erlauben.

Jetzt wurde mir eine sehr anspruchsvolle Aufgabe übertragen. Begonnen hat es damit, dass die Geschäftsführung im Revisionsbericht Schwachstellen im gesamten Unternehmen aufgezeigt bekommen hat. Eine davon ist scheinbar die Posteingangsverarbeitung bzw. unsere Reaktion auf Kundenkorrespondenz. Es wurde festgestellt, dass die Briefe zu langsam oder gar nicht beantwortet werden. Aber ein Monitoring fehlt, eine belastbare Übersicht über Mengen und Zeiten haben wir tatsächlich nicht. Diese Misere betrifft meine Abteilung Kundencenter und fällt damit direkt in meinen Verantwortungsbereich. Die Arbeit von zwei meiner Gruppen gerät in den Blickpunkt. Solch ein Optimierungsprojekt ist zwar einerseits ärgerlich, da ich die Notwendigkeit nicht selbst erkannt habe, andererseits aber auch besonders reizvoll und anspornend. Deshalb möchte ich das Projekt, welches die Arbeit meiner eigenen Abteilung verbessert, nicht aus der Hand geben.

Die Geschäftsführung erwartet von mir zunächst ein Konzept, das die derzeitigen Schwachstellen der Prozesse untersucht und Lösungen aufzeigt. Solch eine Konzepterstellung ist grundsätzlich nichts Neues und war auch bereits in der Vergangenheit Teil unserer Arbeit. Aber (ehrlich gesagt) keiner schrieb diese Konzepte wirklich gern. Oft gab es Diskussionen und Missverständnisse mit den Kollegen, meistens Kleinigkeiten. Am Ende hatten die erstellten Konzepte auch wenig mit der realisierten Lösung zu tun, denn viele Anforderungen änderten sich während des Projektes. Das führte im Ergebnis dazu, dass die Aufgabe Konzepterstellung heute keinen guten Ruf geniest.

Dieses vorliegende Projekt wird neben dem organisatorischen wahrscheinlich auch einen hohen IT-Anteil besitzen. Das macht es nicht einfacher. Ich weiß, dass heutzutage die Durchführung von Prozessen wie der Postbearbeitung, deren Steuerung und Auswertung, ohne IT kaum vorstellbar ist. Doch ich bin kein IT-Experte. Deshalb habe ich mir Unterstützung durch einen jungen Kollegen aus der IT-Abteilung ins Projekt geholt. Mein erster Eindruck von ihm ist durchaus positiv, manches sieht er halt anders als ich. Das muss nicht schlecht sein. Hoffentlich ist er nicht zu theoretisch unterwegs.

Ole

Ich heiße Ole. Seit vergangenem Herbst bin ich in unserer Firma tätig. Nach diversen Praktika in verschiedenen Unternehmen ist das meine erste feste Anstellung. Die Grundlagen des Anforderungsmanagements sind mir noch aus Studienzeiten in guter Erinnerung. Jetzt freue ich mich, diese in der Praxis anzuwenden. Mein IT-Leiter hat mich bezüglich eines neuen Projektes angesprochen, in dem ich mitarbeiten werde. Es geht um die Posteingangsverarbeitung unseres Unternehmens, aber genaueres weiß er auch noch nicht. Ich soll mich an Hagen wenden, den zuständigen Abteilungsleiter. Diesen habe ich kurz auf dem Gang getroffen. Er sagt, er will eine praktische Lösung, nichts Verkopftes. Das liegt ganz in meinem Interesse. Ich werde mich morgen länger mit ihm zusammensetzen. Mal sehen, wie ich mich einbringen kann.

Gleich zu Beginn möchte ich meine aus den bisherigen Tätigkeiten gewonnene Auffassung zum Thema Anforderungsmanagement zur Diskussion stellen: Im Studium wurde dieses Thema klar definiert und im Prinzip auf die IT begrenzt. Meine bisherigen Erfahrungen und Gespräche mit Kollegen zeigen aber, dass sich die heutige Arbeitswelt nur noch schwer in IT und Nicht-IT unterteilen lässt. Die Grenzen sind fließend oder künstlich, je nach Blickwinkel. Für mich persönlich ist Anforderungsmanagement eine Disziplin, mit der ich Erwartungshaltungen anderer an eine zukünftige Lösung grundsätzlich ermitteln kann; unabhängig von den enthaltenen IT-Anteilen. Das bedeutet daher auch, angrenzende oder organisatorische Themen, die vielleicht nicht in einer IT-Lösung münden, ebenfalls zu betrachten. Für mich ist es deshalb ok, wenn als Ergebnis des Anforderungsmanagements größtenteils Prozesse organisatorisch umgestellt werden. Vielleicht wäre dann der Begriff Business Process Management der bessere. Aber solch eine eher akademische Abgrenzung der Inhalte von Anforderungsmanagement, Requirements Engineering, Business Analyse, Business Process Management oder was es sonst noch gibt, die Diskussion rund um deren Gemeinsamkeiten und Unterschiede, fällt mir schwer. Den Fachbereichen, mit denen ich bisher gearbeitet habe, ist diese Differenzierung sowieso egal. Sie sind in erster Linie an Ergebnissen zu Ihren Themen interessiert. Deshalb halte ich mich lieber an die alte Mediziner-Weisheit Wer heilt hat Recht. Hauptsache, die Lösung ist am Ende für alle Beteiligten akzeptabel.

Soviel zur Kurzvorstellung der beiden Akteure des Buch-Beispiels.

Sie halten gerade ein für die Fülle des Themas eher schlankes Werk in den Händen, welches Ihnen in Ihrer Rolle als Fachexperte, Projektleiter oder Entscheider einen guten Überblick über das Anforderungsmanagement gibt. Es erläutert Ihnen am Beispiel Reorganisation der Kundenpostbearbeitung, wie Hagen und Ole den Kontext des Projektes abgrenzen, Details von allen Anforderungsinhabern erfragen und die Ergebnisse zusammenstellen und prüfen. Als Leser erfahren Sie, wie die beiden an die gestellte Aufgabe herangehen, welche Tätigkeiten aus deren Sicht erforderlich und welche Modelle in welchem Fall brauchbar sind. Aufgrund der genannten Zielgruppe Jedermann werden allerdings einige Themen nur angerissen oder kurz erläutert. Es werden durchaus Themen stiefmütterlich behandelt, die schon für sich allein eigene Bücherreihen füllen würden, aber für Jedermann den Rahmen sprengen.

Der gesamte Inhalt des Buches ist aus didaktischen Gründen auf sieben Wochentage verteilt. Die Fülle der Anforderungsmanagement-Themen wird dadurch überschaubar portioniert, ohne zu unter- oder zu überfordern. Im Anschluss an diese sieben Tage gibt es einen Blick über den Tellerrand des Anforderungsmanagements hinaus, indem es in das Gesamtprojekt eingebettet wird und Zusammenhänge mit anderen Projektphasen hergestellt werden. Zusätzlich gibt es am Schluss, wie Sie es von anderen medialen Werken kennen, noch Bonusmaterial. Das Bonusmaterial enthält ein Kompendium des Anforderungsmanagements bzw. beleuchtet wichtige Aspekte des Anforderungsmanagements aus einer anderen Sicht als der der Projektphasen.

Grund-Satz

Das Buch behandelt alle Themen rund um das Anforderungsmanagement, die mir permanent, wenn auch in unterschiedlicher Intensität, in meinen IT-Projekten begegnet sind. Die daraus resultierenden, sich wiederholenden Gedankengänge habe ich niedergeschrieben in der Hoffnung, dass diese Ihnen in ähnlichen Situationen nützlich sein werden.

Zwei stilistische Hinweise:

1.

Grund-Sätze und Leit-Fragen formulieren wesentliche Aussagen und erleichtert Ihnen die Orientierung in der Fülle des Textes.

2.

Am Ende des Hauptkapitels wird eine stichpunktartige Übersicht die wichtigsten Inhalte zusammenfassen.

Die Lektüre dieses Buches macht Sie leider nicht zu Meistern des Anforderungsmanagements. Aber sie hilft Ihnen, die vorgeblichen Meister zu hinterfragen und die tatsächlichen Meister besser zu verstehen. Innerhalb einer Woche werden Sie so zu Anforderungsmanagement‐Verstehern. Im Minimalfall sollte die Lektüre Ihre Arbeit vereinfachen, im optimalen Fall finden Sie Gefallen am Anforderungsmanagement. Und jetzt viel Spaß und maximalen Erkenntnisgewinn.

Fußnoten

1

IT: in den meisten Unternehmen eine gängige Abkürzung für Informationstechnologie; gemeint ist meistens alles rund um die Hard- und Software

2

[BUND06] Deutscher Bundestag (2006) Plenarprotokoll 16/56, Deutscher Bundestag, 56. Sitzung, 18. Oktober 2006, S. 5454. http://dip21.bundestag.de/dip21/btp/16/16056.pdf

Thomas NiebischAnforderungsmanagement in sieben Tagen2013Der Weg vom Wunsch zur Konzeption10.1007/978-3-642-34857-0_2© Springer-Verlag Berlin Heidelberg 2013

2. Die Notwendigkeit des Anforderungsmanagements

Thomas Niebisch¹  

(1)

Bereich Systems Engineering, und Entwicklung, GISA GmbH, Leipziger Chaussee 191a, 06112 Halle (Saale), Deutschland

Thomas Niebisch

Email: [e-mail]

Zusammenfassung

Lassen Sie uns einleitend die Notwendigkeit des Anforderungsmanagements aus offensichtlichen

Schwachstellen der Projekte ableiten. Schauen wir uns an, worin der Nutzen des Anforderungsmanagements für den Projekterfolg besteht.

Für Sie als Leser besitzt dieses Kapitel die gleiche Bedeutung wie ein Warm-Up für einen Sportler, denn es stimmt Sie auf die anstehenden Aufgaben ein und bringt Ihre wichtigsten

Körperfunktionen auf Betriebstemperatur. Im Prinzip ginge es auch ohne diese Aufwärm-Übung. Trotzdem empfehle ich, dass wir gemeinsam ein wenig die Gedanken lockern und auf die kommenden Kapitel vorbereiten.

Eine Formalie gleich zu Beginn:Wie Sie auf den ersten Seiten des Buches selbst feststellen konnten, ist das Wort Anforderungsmanagement für den dauerhaften Gebrauch recht

sperrig. Für das flüssige Lesen wird deshalb künftig auch auf das Kürzel AM zurückgegriffen.

Lassen Sie uns einleitend die Notwendigkeit des Anforderungsmanagements aus offensichtlichen Schwachstellen der Projekte ableiten. Schauen wir uns an, worin der Nutzen des Anforderungsmanagements für den Projekterfolg besteht.

Für Sie als Leser besitzt dieses Kapitel die gleiche Bedeutung wie ein Warm-Up für einen Sportler, denn es stimmt Sie auf die anstehenden Aufgaben ein und bringt Ihre wichtigsten Körperfunktionen auf Betriebstemperatur. Im Prinzip ginge es auch ohne diese Aufwärm-Übung. Trotzdem empfehle ich, dass wir gemeinsam ein wenig die Gedanken lockern und auf die kommenden Kapitel vorbereiten.

Eine Formalie gleich zu Beginn: Wie Sie auf den ersten Seiten des Buches selbst feststellen konnten, ist das Wort Anforderungsmanagement für den dauerhaften Gebrauch recht sperrig. Für das flüssige Lesen wird deshalb künftig auch auf das Kürzel AM zurückgegriffen.

2.1 Zwei Seiten einer Medaille

IT-Projekte bestehen oftmals wie eine Medaille aus zwei gegenüberliegenden Seiten: Auf der einen Seite der Medaille befinden sich die Fachbereiche und Geschäftsleute, die ihr Tagesgeschäft mittels der IT bewältigen wollen. Die IT spielt aus deren Perspektive nur eine dienstleistende Rolle, die die Fachprozesse unterstützen und dabei fehlerfrei funktionieren soll. Auf der anderen Seite der Medaille sind die IT-Spezialisten. Ihnen fehlt die Kenntnis der konkreten fachlichen Abläufe und somit das Wissen über eine notwendige Gestaltung der IT-Lösung hinsichtlich einer optimalen Unterstützung der Fachbereiche. Dieses Defizit kompensieren sie mit ihrem Selbstverständnis, dass die IT sich zum Herzstück aller betrieblichen Vorgänge entwickelt hat und alles andere sich drum herum anpasst.

Auch wenn das Gleichnis sehr überspitzt formuliert ist, tragen beide Seiten der Medaille schwer an