9	IT-Anforderungsmanagement

Ernst Tiemeyer

Fragen, die in diesem Kapitel beantwortet werden:

       Inwiefern ist ein professionelles IT-Anforderungsmanagement für den Erfolg von IT-Organisationen wesentlich und welche Erfolgsfaktoren sind zu beachten?

       In welchen Phasen wird IT-Anforderungsmanagement typischerweise in der Praxis umgesetzt?

       Wie können die Anforderungen an IT-Systeme (IT-Infrastrukturen, IT-Applikationen und IT-Services), die auf Seiten der (internen) Kunden vorliegen, unter Anwendung ausgewählter Instrumente systematisch erhoben, gesammelt und nach Abstimmungen in einer Anforderungsspezifikation bzw. Systemspezifikation dokumentiert werden?

       Wie lassen sich die dokumentierten Kundenanforderungen – ggf. unter Einsatz geeigneter Methoden und Tools – analysieren und hinsichtlich der Notwendigkeiten und Möglichkeiten der Umsetzung priorisieren?

       Auf welche Weise können die Anforderungen, die die Fachbereiche an die IT haben, in Systemanforderungen für IT-Entwickler (IT-Architekten, System- und Softwareentwickler) transferiert werden?

       Wie lässt sich durch ein organisiertes Anforderungsmanagement die Zusammenarbeit der IT mit dem Fachbereich erfolgreich steuern?

9.1	Anforderungsmanagement – Notwendigkeit und Erfolgsfaktoren

Das Generalmanagement Ihrer Organisation schätzt die Leistungen der IT, die Anwender loben die Qualität der bereitgestellten IT-Infrastrukturen, die Benutzer Ihrer Applikationen sind motiviert und hochzufrieden mit den bereitgestellten Lösungen und dem IT-Bereich, die Kooperation von IT und Fachbereich funktioniert bestens und die IT-Services werden umfassend in Topqualität aus Kundensicht erbracht. Stellen Sie sich vor, diese „heile Welt“ wäre für Sie gegeben! Stellen Sie sich vor, dass das Generalmanagement sowie Ihre Anwender und Enduser die Leistungen des IT-Bereichs, die bereitgestellten IT-Applikationen, IT-Systeme und IT-Services sowie die Ergebnisse Ihrer IT-Projekte tatsächlich in hohem Maß anerkennen und honorieren. Ein erstrebenswerter Zustand ist dies in jedem Fall.

Die Realität ist jedoch von dem zuvor beschriebenen Niveau oft weit entfernt. Es liegt deshalb nahe, zu überlegen, wie das IT-Anforderungsmanagement optimiert und so die Zusammenarbeit von IT und Fachbereich erfolgreich organisiert werden kann. Gleichzeitig stellt sich im Zeitalter der Digitalisierung auch die Herausforderung, in einem agilen Entwicklungsumfeld auch neue Formen und Verfahren im Anforderungsmanagement für digitale Lösungen zu etablieren.

Unter Beachtung von Unternehmensgröße, Branche und Unternehmenskultur ist das Thema IT-Anforderungsmanagement (= Requirements Engineering) in der Bedeutung und Anwendung unterschiedlich stark eingeschätzt. Während in einigen Unternehmen IT-Anforderungsmanagement als lästige Zusatzaufgabe betrachtet wird, haben andere Unternehmen spezifische Teams und Abteilungen für das IT-Anforderungsmanagement etabliert. Grundsätzlich gilt darüber hinaus: Nahezu in jedem Projekt wird Anforderungsmanagement – bewusst oder unbewusst – als wesentliches Handlungsfeld verankert. Es ist letztlich die Basis für den weiteren Entwicklungsprozess, die Validierung/Verifikation und die Plan- und Messbarkeit eines Business-IT-Projekts. Übereinstimmung besteht in folgender Frage: Fehler, die auf der Anforderungsebene „entdeckt“ werden, lassen sich leichter beheben als in späteren Entwicklungsphasen des Projekts.

9.1.1

Ausgangssituation und Handlungsszenarien

Ursprünglich war die IT-Welt durch eine starke Technikbezogenheit gekennzeichnet. Dies führte dazu, dass sich IT-Abteilungen von ihrem Selbstverständnis her primär als Lieferanten von IT-Infrastrukturen, Netzwerken und zu installierender Software sahen. Diese Zeit ist jedoch schon längst vorüber. Heute reicht es nicht mehr aus, nur Technologie für die Anwender bereitzustellen. Es müssen vielmehr auf die Anforderungen der Kunden bezogene Lösungen entwickelt werden, die zudem noch über den Lebenszyklus hinweg betreut werden müssen (im Sinne eines professionellen Product-Life-Cycle-Managements).

Dementsprechend sind auch Wünsche der Anwender an die IT immer vielfältiger und komplexer geworden und können sich auf unterschiedliche Bereiche (Applikationen, Infrastrukturen, Dienste) beziehen. Dies können sein:

       Softwareanforderungen (selbst neu entwickelte bzw. weiterentwickelte bzw. angepasste Applikationen, firmenspezifische Adaption von Standardanwendungen)

       Anforderungen an die Ausstattung mit IT-Systemen/IT-Infrastrukturen (Arbeitsplatzsysteme, mobile Lösungen, Vernetzung, Speicher- und Serverleistungen)

       Wünsche für die Implementationsunterstützung (Systembereitstellung, Systemeinführung, Systemschulungen etc.)

       Erbringen von Serviceleistungen bzw. Anforderungen an die IT-Unterstützungsprozesse (Support bei Ausfällen, Fehlern etc.)

Grundsätzlich kommt dem IT-Management die Aufgabe zu, den Fachabteilungen (bzw. den Kunden der IT) ein umfassendes Angebot an IT-Systemen und IT-Services zur Verfügung zu stellen, diese sachgemäß zu implementieren und dazu kundengerechte Dienstleistungen zu bieten. Im Einzelnen ist festzustellen:

       Die Leitungen der Fachabteilungen und ihre Mitarbeiter wünschen heute eine sehr differenzierte IT-Infrastruktur (Desktops, mobile Systeme, Netzanschlüsse etc.), auf die An­forderungen adaptierte Applikationen und umfassende IT-Unterstützungsleistungen. Beispiele dafür sind der Betrieb und das Monitoring von Netzwerken (LAN, WAN), die Bereitstellung von Netzwerkdiensten (Print, Directories, Storage-Services, . . .) sowie die Installation und der Betrieb von Web- und Portalzugriffen (E-Mail, SAP, File, . . .).

       Auf Seiten der Anwender werden die Implementation und die umfassende Pflege von betriebswirtschaftlichen, produktionstechnischen und logistischen Applikationen sowie von Office- und Groupware-Lösungen erwartet.

       Eine integrierte Bereitstellung von umfassenden IT-Dienstleistungen wird heute als selbstverständlich erwartet. Wichtig sind oft auch ein „Rund um die Uhr“-Service sowie transparente Ansprechpartner.

       Trotz steigender Komplexität der IT-Technologien (etwa gemischte Client-Server-Strukturen, Cloud Computing) sowie der Zunahme geschäftskritischer Anwendungen müssen sowohl die Qualität der bereitgestellten Informationen (Stichwort „Big Data“) als auch die Verfügbarkeit der Informationssysteme und Informationen selbst gesichert werden.

       Der wachsende Kostendruck erfordert eine effektive Auslastung der IT-Infrastruktur sowie integrativ ganzheitliche Applikationen. Dazu werden vom IT-Management vor allem wirtschaftliche und effektive Lösungen erwartet, sowohl von der Unternehmensführung als auch von den Fachabteilungen (insbesondere wenn auch eine interne Verrechnung von IT-Leistungen erfolgt).

Das Ziel der IT-Abteilung lautet daher nicht mehr „Beherrschung und Unterstützung der Technik“, sondern „bestmögliche Unterstützung der Geschäftsprozesse (und Kunden) im Unternehmen“. Mit dieser Formulierung findet auch der Servicegedanke immer mehr Berücksichtigung.

Aufgrund der Vielfältigkeit der Anforderungen und der gewachsenen Ansprüche der Kunden an die IT wird deutlich, dass sich die Implementierung eines IT-Anforderungsmanagements in der Praxis lohnt bzw. meist unverzichtbar ist.

Praxistipp:

Durch die Einführung und Umsetzung von geeigneten Vorgehensweisen und Instrumenten im Anforderungsmanagement (u. a. Positionsbestimmung zu IT-Anforderungsmanagement im Unternehmen, Stakeholder-Analyse und Scoping, Anforderungserhebung, Anforderungsanalyse, Anforderungsspezifikation, Anforderungsmodellierung, Anforderungsreviews) kann den Herausforderungen der Praxis nach Kunden- und Serviceorientierung in besonderer Weise Rechnung getragen werden. Insbesondere ist ein erfolgreich absolvierter Serviceauftrag bzw. ein positiver Abschluss eines IT-Projekts wahrscheinlicher.

9.1.2

Erfolgsfaktoren

Um ein erfolgreiches IT-Anforderungsmanagement zu etablieren, müssen die Rahmenbedingungen „stimmen“. Es lohnt sich deshalb für Sie, darüber nachzudenken, welche Erfolgsbedingungen für das IT-Anforderungsmanagement grundsätzlich gegeben sind, und dazu die eigenen Unternehmenssituationen zu reflektieren. Ggf. sind die bisherigen Festlegungen zu den Prozessen und Rollen bei der Bearbeitung von Anforderungen zu verändern und die vorhandenen organisatorischen und personellen Verankerungen bzw. Regelungen entsprechend anzupassen.

Wichtig ist in jedem Fall eine klare Kundenorientierung für das Handeln im IT-Bereich; das bedeutet etwa im Fall einer internen IT-Gruppe/IT-Abteilung eine abgestimmte klare Sichtweise auf die Fachabteilung als einen sogenannten internen Kunden. Eine heute auch aus vielfacher Erfahrung bestätigte These lautet, dass prinzipiell der Wertbeitrag der IT steigt, je besser sich die IT-Organisation um ihre Kunden im Unternehmen kümmert.

Für das Finden und sachgerechte Beurteilen der Kundenwünsche ist es besonders wichtig, den Zweck zu verstehen, mit dem der Kunde eine Anforderung formuliert:

       Wofür will der Kunde ein neues System bzw. eine verbesserte Applikation?

       Warum ist der Anwender bereit, in neue IT-Infrastrukturen bzw. in neue oder veränderte Applikationen zu investieren? Welche Ziele lassen sich damit im Detail besser erreichen?

       Was sind Erfolgskriterien für eine erfolgreiche Zusammenarbeit mit dem Kunden bei der Umsetzung seiner Wünsche und Anforderungen an die IT?

Im Sinne einer verstärkten Kundenorientierung wird zunehmend empfohlen, die IT-Abteilung wie ein kleines Unternehmen zu führen – samt eigenem Marketing. Das IT-Management muss sich damit Gedanken darüber machen, wie die IT ihre Aufgaben möglichst gut erledigt.

Mitunter wird auch für einen Kundenbeauftragten innerhalb der IT plädiert (oft auch Produktverantwortlicher genannt). Er koordiniert, wer welche IT-Themen (= Domänen) betreut, sodass für jeden Bereich ein zentraler Ansprechpartner zur Verfügung steht. Dieser Kundenbeauftragte kennt sich sowohl bei den laufenden Geschäftsprozessen als auch bei IT-Themen aus, hat gute Kontakte ins übrige Unternehmen und die Kompetenz, schnell Entscheidungen zu treffen.

Um zu guten, der Sache angemessenen und fachgerechten Anforderungen zu gelangen, ist natürlich der richtige Ansprechpartner auf Seiten der Anwender eine äußerst wichtige Erfolgsgröße (im Fachjargon Requirements-Provider genannt).

Als Ansprechpartner für die Anforderungsentwicklung sollten Personen der Fachabteilung bzw. aus dem Generalmanagement fungieren, die über spezifische Kompetenzen verfügen. Am Beispiel der Entwicklung von Softwareanforderungen können als gewünschte Fähigkeiten und Kompetenzen seitens der Anwender genannt werden:

       Kenntnis der Arbeits- und Geschäftsprozesse, die durch die neue Lösung unterstützt werden sollen (Sachverstand im Anwendungsgebiet für die angestrebte IT-Lösung);

       Wissen um die vorliegenden Richtlinien bzw. die einschlägigen Vorschriften (Rechtsvorschriften, Normen) sowie der firmenspezifischen Architekturvorgaben, die bei der Lösungsentwicklung einzuhalten sind;

       Fähigkeit, sich in die von Experten oder gemeinsam im Team angedachten IT-Lösungskonzepte und ihre Auswirkungen hineinzudenken;

       systembezogenes Know-how, um systemtechnische Vorgaben zu beurteilen bzw. festzulegen, die bei der Realisierung zu befolgen sind und den IT-Lieferanten bei der Entwicklung von Lösungsvorschlägen einen klaren Rahmen geben;

       systemtechnisches Verständnis, um die Abbildung der User Requirements auf System Requirements nachvollziehen zu können;

       ausreichende Entscheidungskompetenz, um tragfähige Vereinbarungen mit dem IT-Koordinator (dem Kundenbetreuer) abschließen zu können (denken Sie daran: Qualität basiert auf Vereinbarungen über Anforderungen!).

Beachten Sie:

Es ist leicht einsichtig, dass für die Anforderungsermittlung in der Regel eine Reihe von ausgewählten Ansprechpartnern benötigt werden. Darüber hinaus ist von entscheidender Bedeutung, bei der Anforderungsanalyse alle relevanten Interessenspartner (Stakeholder) ins Boot zu holen.

Nicht nur auf Seiten der Anwender sind entsprechende Voraussetzungen zu beachten, um im Anforderungsmanagement zu nachhaltigen Lösungen zu gelangen. Anforderungsentwickler (IT-Koordinatoren) sollten ebenfalls bestimmte Fähigkeiten und Voraussetzungen mitbringen, um die Wünsche der Anwender sachgerecht zu beurteilen und zu kanalisieren:

       Verständnis für die Geschäftsprozesse des Kunden/der betroffenen Fachabteilungen;

       systembezogenes Wissen (Wissen um die infrastrukturellen und softwarebezogenen Lösungsmöglichkeiten unter Beachtung integrativer Komponenten);

       Kompetenz, User Requirements in System Requirements zu übertragen;

       Fähigkeit, Informationen zu den IT- und Geschäftsarchitekturen genau zu strukturieren, methodisch sauber zu modellieren und unter Anwendung bewährter Methoden transparent zu dokumentieren;

       kommunikative Fähigkeiten und Verhandlungskompetenz mit dem Kunden (Vereinbarungen zu den anzugehenden Lösungswegen kompetent aushandeln);

Beachten Sie:

Ein guter Anforderungsentwickler für Kundenanforderungen und Systemanforderungen muss weder im Anwendungsgebiet noch als Softwareentwickler oder als Netzwerk- und Systemfachmann ein Experte sein, sondern im Wesentlichen ein gut ausgeprägtes Grundlagen- und Einordnungswissen haben. Besonders wichtig sind darüber hinaus Fähigkeiten als Vermittler zwischen der IT-Welt und dem Fachbereich.

9.1.3

Organisatorische Verankerung und Qualitätsmanagement für das IT-Anforderungsmanagement

Wesentliches Ziel des IT-Anforderungsmanagements ist es, effiziente und fehlerarme (störungsfreie) IT-Systeme bzw. IT-Lösungen zu entwickeln und dem Anwender kundenorientiert bereitzustellen. Anforderungsmanagement ist vor allem dann von Bedeutung, wenn der Einsatz komplexer IT-Systeme geplant ist, wobei die Entwicklung und Implementierung dieser Systeme in einem relativ hohen Grad arbeitsteilig erfolgt. Dabei zeigen die Erfahrungen der Praxis, dass das Formulieren von Anforderungen durch den Kunden bzw. den Anwender von IT-Lösungen allein nicht ausreicht. Wichtig für die erfolgreiche Entwicklung einer Applikation bzw. die Bereitstellung einer IT-Infrastruktur bzw. einer Standardapplikation ist es, dass ein ganzheitlicher Prozess für das Anforderungsmanagement in der betrieblichen Praxis definiert und realisiert wird.

Ausgangspunkt zur Positionierung sollte es sein, die Hauptprozesse im Anforderungsmanagement für die IT zu bestimmen. Bild 9.1 zeigt den Zusammenhang der Aufgaben und Prozesse im Überblick.

Bild 9.1 IT-Anforderungsmanagement – Einordnung der Aufgaben/Prozesse

Um ein professionelles IT-Anforderungsmanagement in der Praxis zu realisieren, haben sich vielfach in den Unternehmen IT-Koordinatoren etabliert. Dabei handelt es um Stellen/Rollen, die entweder im IT-Bereich angesiedelt sind oder auch dem Fachbereich zugeordnet sein können (synonym finden sich auch Bezeichnungen wie Key User, Power User, IT-Beauftragter, Fachkoordinator oder Business-Analyst). Besondere Merkmale, die der Rolle eines IT-Koordinators zugewiesen werden, sind:

       IT-Koordinatoren bilden die „Drehscheibe zwischen IT und Fachbereich“, indem sie die beiden Bereiche zusammenführen und wichtige Vermittlungsfunktionen wahrnehmen.

       IT-Koordinatoren gewährleisten effiziente, harmonisierte und ganzheitliche IT-Lösungen.

       IT-Koordinatoren sorgen für eine verbesserte Kooperation und Kommunikation von IT und Fachbereich.

       IT-Koordinatoren sind vielfach nicht nur Vermittler zwischen den beiden Polen/Fronten, sondern gleichzeitig Innovatoren im technischen Wandel.

Es bietet sich an, für das IT-Anforderungsmanagement gleichzeitig ein transparentes Qualitätsmanagement zu etablieren. Wesentlich sind das Schaffen optimaler Rahmenbedingungen sowie eine umfassende Qualitätssicherung und Weiterentwicklung der Prozesse und Ergebnisse im Anforderungsmanagement.

Folgende Grundsätze für ein qualitativ abgesichertes Anforderungsmanagement werden hervorgehoben:

       Die Anforderungen, die seitens der Kunden an die IT-Lösung gerichtet werden, sind vollständig aufzunehmen und systematisch zu strukturieren! Achten Sie darauf, dass Anforderungen nicht doppelt dokumentiert werden; umgekehrt dürfen natürlich auch wichtige Anforderungen nicht vergessen werden (Prinzip der Vollständigkeit zum Grundsatz machen). Es empfiehlt sich darüber hinaus, die erhobenen Kundenanforderungen nach ausgewählten Kriterien (etwa nach Art, Wichtigkeit, Herkunft etc.) zu gliedern. Dies ermöglicht es, die Kontrolle über die Anforderungen zu behalten, indem zum Beispiel auch im Nachhinein feststellbar ist, von wem diese Anforderung formuliert wurde. Gleichzeitig kann so die Qualität der dokumentierten Anforderungen bzw. ihre Realisierung zuverlässig überprüft werden.

       Leiten Sie aus den erhobenen Kundenbedürfnissen die tatsächlichen Anforderungen an die IT-Lösung ab! Wichtig ist es, die formulierten Ist-Bedürfnisse der Kunden insofern zu harmonisieren, als daraus die tatsächlich erforderlichen Bedarfe abgeleitet werden. Ausgangspunkt und Ergebnis der Erhebung (sei es per Fragebogen, Interview oder Gruppenworkshop) sind typischerweise die Kundenanforderungen „als Ist-Bedürfnisse“. Aufgabe der für das Anforderungsmanagement Verantwortlichen ist es, dass diese Bedürfnisse mehr generisch (nach einem Standard) harmonisiert werden bzw. eine Se­lektion erfolgt, sodass die daraufhin generierte Systemlösung mehrere Kundenbedürfnisse befriedigen kann und nicht „überzogen“ auf einzelne individuelle Bedürfnisse eingegangen wird (was in der Regel auch unwirtschaftlich wäre).

       Nehmen Sie eine Visualisierung und Dokumentation der Anforderungen nach einem abgesicherten Verfahren vor und achten Sie auf die Testbarkeit! Die Erfahrungen zeigen, dass es hilfreich ist, sich auf ein grafisches/visualisiertes Dokumentationsverfahren zu den Anforderungen zu verständigen. Beispiele sind UML (Unified Modeling Language) und ähnliche Verfahren. In der Praxis ist es einfacher, mit visualisierten Anforderungen umzugehen, denn es erleichtert das Verständnis zwischen dem Entwicklungs- bzw. Integrationsteam für IT-Lösungen und den Kunden bzw. Stakeholdern. Anforderungen müssen außerdem mit Testkriterien verbunden sein („testbar“ sein). Das hilft nicht nur, spätere Phasen des Projekts besser vorzubereiten, sondern zwingt auch den Verfasser der Anforderungen bzw. den System- und Softwareentwickler, „in die richtige Richtung“ zu denken.

       Fixieren Sie die Ergebnisse der Anforderungserhebung in einer Anforderungsspezifikation (Vorlage)! Mittels einer Vorlage für die Anforderungsspezifikation müssen die harmonisierten Benutzerbedürfnisse erfasst werden. Dabei sind gleichzeitig eine intelligente Rückverfolgbarkeit sicherzustellen und Change-Impact-Analysen zwischen ihnen herbeizuführen. Spezifikationen und vertragliche Dokumente können ggf. auch aus einer Anforderungsdatenbank heraus generiert werden (Vorlagen für Spezifikationen, Verträge). Dieser zentrale Ort sollte auch Links zu äußeren Elementen beinhalten (wie z. B. Kundendokumentation, E-Mails und Verträge). Auch die Randbedingungen (nicht funktionale Anforderungen) sind zu erfassen und zu managen. Typische nicht funktionale Anforderungen sind Performance, Interface, Security/Sicherheit, Ausfallsicherheit, effektive Verfügbarkeit, Wartbarkeit.

       Die dokumentierten Anforderungen sind zu priorisieren! Es empfiehlt sich, die Priorisierung der Anforderungen in Kooperation mit dem Kunden vorzunehmen. Der IT-Produktmanager/IT-Koordinator muss sich im Einvernehmen mit dem Anwender entscheiden, welche Anforderungen am meisten nützlich für seine Kunden sind. Das ist realisierbar, indem man den für den Kunden gelieferten Wert und die Prioritätsinformationen kombiniert und daraus eine richtige Anforderungskombination definiert.

       Änderungen von Anforderungen müssen kontrollierbar gemacht werden! Im Verlauf der Zeit (während des Projekts) können sich Änderungen bezüglich der IT-Anforderungen ergeben. Dies muss unbedingt beachtet werden. Es ist nicht genug, am Anfang eine perfekte Anforderung zu definieren, wenn ihre Entwicklung mit der Zeit nicht verfolgt wird – das kann nicht akzeptierte IT-Systeme und mangelhafte Software zur Folge haben.

       Anforderungen müssen kommuniziert werden! Um ermittelte Anforderungen bzw. dokumentierte Anforderungsspezifikationen kommunikationsfähig zu haben, sind diese in einheitlicher Form den potenziellen Kunden und Stakeholdern bereitzustellen.

9.2	A nforderungen im Fachbereich erheben – Techniken und Vorgehen

Eine systematische Anforderungsermittlung (engl. „Requirements Elicitation“) bildet die Basis, um daraufhin die notwendige Dokumentation sämtlicher Anforderungen (bzw. die Ausarbeitung der Anforderungsspezifikation) vornehmen zu können. Die Sammlung kann durch den Anwender getrieben sein, der Regelfall ist jedoch die „Einsammlung“ durch einen IT-Koordinator/Anforderungsmanager oder durch einen zuständigen IT-Systementwickler bzw. einen IT-Architekten.

Oft müssen die Anforderungen auch kollaborativ über Abteilungs- und Unternehmensgrenzen hinweg gesammelt, kommentiert und erfasst werden. In diesem Fall ist eine geeignete Mischung der Gruppe aus Vertretern der Fachbereiche und IT-Experten sinnvoll.

Bild 9.2 zeigt den Zusammenhang der Teilaufgaben, Ergebnisse und Instrumente im Rahmen der Anforderungsermittlung.

Beachten Sie: Eine Anforderung gibt an, was zu realisieren ist, aber nicht, wie dieser Zu­stand erreicht wird. Es gibt also eine klare Trennung zwischen Anforderungen und Lösungen (vgl. auch [Eb08], S. 21).

Bild 9.2 Teilprozess „IT-Anforderungen sammeln bzw. erheben und erfassen (Requirements Capture)“

9.2.1

Anforderungsarten – Möglichkeiten der Systematisierung

Anforderungen der IT-Kunden können sich auf unterschiedliche Domänen beziehen, etwa auf verschiedene Architekturbereiche (Standardanwendungen, Individualapplikationen, Datenarchitekturen und Storage, Infrastrukturen etc.) oder auf verschiedene Funktions- und Prozessfelder. Abhängig von den sich ergebenden Anforderungsarten kann ein unterschiedliches Vorgehen für die Präzisierung der Anforderungen notwendig sein.

Typische Arten von Anforderungen im IT-Umfeld sind:

       Anforderungen in Bezug auf die Neuentwicklung eines Softwareprodukts

       Wunsch nach der Veränderung einer vorhandenen Softwarelösung (Modifikationen, Erweiterungen, Optimierungen)

       Integration einer Standardlösung (Einführung von Business Software)

       Erbringung von IT-Dienstleistungen verschiedener Art (IT-Services, Digitalisierungslösungen)

Wichtig ist natürlich auch, ob sich die Anforderung im Rahmen eines Systemgestaltungsprozesses (etwa Anforderungssammlung für ein IT-Projekt) oder als überschaubare Einzelanforderung bzw. als Arbeitsauftrag (mit einer überschaubaren Anzahl an Anforderungen, die von einer Person in einem überschaubaren Zeitraum abgearbeitet werden können) ergibt.

Eine weitere Unterscheidung ergibt sich durch die Tatsache, dass es sich bei der Anforderungsentwicklung und der Anforderungsumsetzung typischerweise um einen mehrstufigen Prozess handelt, an dem verschiedene Akteure/Experten beteiligt sind, wodurch sich oft eine Dreiteilung ergibt; z. B.:

       Definition der Kundenanforderungen (User Requirements);

       Definition der Systemanforderungen (sie definieren das zu entwickelnde oder zu liefernde System);

       Definition der Anforderungen an die Komponenten des Systems, die primär von den Systemanforderungen und der Architekturkonzeption der Unternehmensorganisation abgeleitet werden (vgl. Kapitel „Enterprise Architecture Management“).

Beachten Sie:

Der typische Fall für das IT-Anforderungsmanagement sind die Anforderungen, die sich als Bündel im Rahmen von IT-Projekten ergeben und im Rahmen der Systementwicklung (Softwareentwicklung) durch eine Projektlösung erfüllt werden können. Davon zu unterscheiden sind Anforderungen, die eine direkte Problemlösung ermöglichen und im Rahmen einer Auftragsbearbeitung umgesetzt werden (und damit nicht die spezielle Organisationsform eines Projekts für die Umsetzung erfordern).

9.2.2

Varianten des Vorgehens

Unterschiede bestehen natürlich bezüglich der Frage, in welcher Weise die Anforderungen gesammelt werden. So ist etwa festzuhalten, dass Anforderungen der Kunden auf sehr unterschiedlichen Wegen beim IT-Bereich bzw. beim IT-Koordinator eintreffen können. Möglich ist, dass einerseits die Kunden von sich aus Anforderungen anmelden, andererseits eine gezielte Erhebung durch den IT-Bereich/IT-Koordinator erfolgt.

Zu beachten ist auch, dass es keine zentrale Informationsquelle dafür gibt, aus der die Anforderungen an bestimmte IT-Lösungen einfach abgeleitet werden können. Die typische Situation der Anforderungsermittlung ist im Gegenteil dadurch gekennzeichnet, dass eine Vielzahl unterschiedlicher Akteure (Stakeholder) zu berücksichtigen sind, die Anforderungen an die zu entwickelnde IT-Lösung haben und entsprechend bei der Festlegung und Formulierung der Anforderungsspezifikation zu berücksichtigen sind. Es ist deshalb auch wichtig, die Akteure genau zu bestimmen und festzulegen, damit nicht wesentliche Betroffene ggf. übersehen werden.

Soll ein Anforderungsmanagement im klassischen stringenten Sinn im Rahmen eines generischen Projektmanagements erfolgen, dann sollen – so die vorherrschende Auffassung – die meisten und wichtigsten Anforderungen schon zum Start des IT-Projekts bekannt sein. So können dann auch klare Meilensteine und Projektphasen für den Systementwicklungsprozess definiert und im Anforderungsmanagement berücksichtigt werden. Die Anforderungen werden in diesem Fall gemeinsam im Projektteam mit den Beteiligten und Betroffenen erhoben und anschließend in einen ganzheitlichen Zusammenhang gebracht, sodass sich ein Gesamtsystem als Dokumentation ergibt (etwa für ein CRM-System, das aus verschiedenen Teilsystemen mit spezifischen Anforderungen besteht; zum Beispiel für Vertrieb, Service und Marketing).

Bei einem solchen Vorgehen ist klar, dass bereits im Projektantrag eine Skizzierung der gewählten Projektphasen erfolgen muss. Abhängig von dem Projektgegenstand sind entsprechende Vorgehensmodelle und die Beachtung des Anforderungsmanagements zu adaptieren. In einem typischen (generischen) Vorgehen muss zu Beginn eines Projekts eine möglichst exakte Anforderungsspezifikation erstellt werden. Davon ausgehend ergeben sich dann das Lastenheft bzw. das Pflichtenheft, die gemeinsam die Grundlage zur Realisierung eines IT-Projekts bilden.

Beachten Sie:

Werden stringente Vorgehensmodelle zur Grundlage gemacht, ist es wesentlich, dass die Anforderungen möglichst stabil gehalten werden können und schon im Vorfeld bzw. zu Projektbeginn relativ genau bekannt sind. Es ist aber keine zwingende Voraussetzung, dass bei diesem Vorgehensmodell die Anforderungen nicht mehr verändert werden dürfen. Es ist allerdings hilfreich, wenn die Anforderungen, die sich ändern können, ermittelt werden und die IT-Architektur dementsprechend angepasst wird.

Unterschiede bezüglich der Anforderungsfestlegungen ergeben sich bei agilem Softwareprojektmanagement, wobei als Ausgangspunkt des agilen Vorgehens die Personen in den Fokus gestellt werden, die Software entwickeln bzw. die in den Softwareentwicklungsprozess eingebunden sind. Deshalb ist es in diesem Fall wesentlich, den Auftraggeber verstärkt in das IT-Projekt und den Entwicklungsprozess so einzubinden, dass zeitnah und flexibel (agil) auf Änderungen bezüglich der Anforderungen des Kunden reagiert werden kann. Die Ziele werden in diesem Fall zum Projektstart nur grob vereinbart, allerdings nicht die umzusetzende Funktionalität im Detail, wie dies beim klassischen Lastenheft üblich ist.

Bei einer agilen Vorgehensweise erfolgt das Erstellen der Detailspezifikation im Idealfall „realtime“ integriert in den Entwicklungsprozess. Als Vorteil wird daraus abgeleitet, dass ein unnötiger Dokumentations- und Entwicklungsaufwand, der durch laufend veränderte Anforderungen entsteht, vermieden werden kann. Sobald sich Fragen oder Probleme im Entwicklungsprozess ergeben, können diese ohne großen Dokumentationsaufwand (unter Vermeidung aufwendiger Änderungsaufträge) in der persönlichen Kommunikation relativ schnell und einfach geklärt werden sowie daraufhin einer einvernehmlichen Lösung zugeführt werden. Ein weiteres Merkmal: Am Ende einer Iteration in einem agilen Projekt werden die jeweiligen Prozesse reflektiert und weiterentwickelt. Dies erhöht ggf. die Qualität der Spezifikation.

Festzuhalten ist, dass sich bei agilem Vorgehen im IT-Projekt ein adäquates iteratives Anforderungsmanagement und die kontinuierliche Integration der Applikation als wesentliche Merkmale erweisen. Dabei werden Anforderungsanalysen nicht mehr mittels eines Lastenhefts dokumentiert, sondern es werden sogenannte Benutzergeschichten (User Stories) erfasst, die es in drei verschiedenen Ausführungen gibt.

       Funktional: Funktionale Anforderungen ergeben sich aus Anwendungsfällen für den Benutzer und beschreiben Aktionen, die vom IT-Produkt (der Applikation) durchgeführt werden können.

       Nicht funktional: Nicht funktionale Anforderungen sind Eigenschaften des IT-Produkts und müssen messbar sein. Gemäß ISO (bzw. DIN) werden die Eigenschaften nach Qualitätskriterien wie Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit bewertet.

       Rahmenbedingungen: Hierzu zählen Anforderungen, die sich nicht auf die Funktionalität der IT-Lösung, sondern auf das Projektvorhaben als solches beziehen. Es handelt sich zum Beispiel um Vorgaben zum Projektablauf, einzuhaltende Normen und Gesetze, zu beachtende Schnittstellen und Informationen zur Plattform, auf der die IT-Lösung eingesetzt werden soll.

Zusammenfassend lässt sich festhalten, dass bei der agilen Vorgangsweise die Kundenanforderungen erst unmittelbar vor der Umsetzung feinspezifiziert werden. Am Anfang eines agilen Projekts steht deshalb eine relativ grobe Planung. Diese besteht aus einer Sammlung aller vom Kunden gewünschten Anforderungen (beispielsweise einer Auflistung der gewünschten Funktionen des neuen IT-Systems), von denen nur die wichtigsten feinspezifiziert sind. Klar definiert sind hingegen die Ziele, die mit der Umsetzung erreicht werden sollen, bzw. was die Projektergebnisse leisten sollen.

Grundsätzlich bietet sich dieses Vorgehen an, wenn noch nicht alle Anforderungen vor bzw. zum Projektstart bekannt sind und diese sich möglicherweise auch noch ändern. Das iterative Anforderungsmanagement kommt unter anderem

       in IT-Projekten mit Prototyping

       sowie in IT-Projekten, in denen der Kunde Teilergebnisse geliefert haben will,

zur Anwendung. Wichtig ist allerdings auch, dass beim Projektstart bekannt ist, welches die kritischen Anforderungen sind, da diese Einfluss auf die Lösungsarchitektur und die Performance der IT-Lösung haben.

Beachten Sie:

Bezüglich der Anforderungserhebung im Rahmen des Projektmanagements ist festzuhalten, dass hier zwischen sequenziellem/stringentem und agilem Vorgehen ein gravierender Unterschied im Anforderungsmanagement besteht. (Hinweis: Agile Methoden haben sich heute für ausgewählte Softwareentwicklungsprojekte vielfach bewährt.)

Die Wahl des Softwareentwicklungsmodells hat insofern Konsequenzen für das Anforderungsmanagement, als der Detaillierungsgrad, wie die Anforderungen zu erheben sind, vom Softwareentwicklungsmodell beeinflusst wird. Je unflexibler ein Softwareentwicklungsmodell ist, umso detaillierter und vollständiger müssen die Anforderungen schon in der Erhebungsphase vorhanden sein. Je flexibler, agiler das Vorgehensmodell ist, umso häufiger kommt es vor, dass die Anforderungen erst parallel zum Projekt erarbeitet oder identifiziert werden. Unabhängig davon hat jedes Softwareentwicklungsmodell die Phasen des Anforderungsmanagements sowie eine Testphase integriert (vgl. [Eb08], S. 65).

9.2.3

Methoden und Techniken der Anforderungserhebung

Vielen IT-Verantwortlichen sowie IT-Koordinatoren ist das folgende Problem bei der Ermittlung der Anforderungen an IT-Lösungen aus der Praxis nicht unbekannt: IT-Kunden ist oft gar nicht bewusst oder zumindest nicht vollständig bewusst, was sie haben wollen und damit von der IT konkret als Ergebnis erwarten. Sie haben meist nur sehr vage Vorstellungen von ihren Zielen und nur eine gewisse Ahnung davon, was sie nicht haben wollen.

Voraussetzung zur Aufnahme von Anforderungen der Kunden ist deshalb, dass einmal seitens der IT ein Verständnis für die Probleme und Bedürfnisse des Kunden entwickelt wird. Daraus lassen sich dann die Anforderungen ableiten. Dabei gilt es nach geeigneten Methoden und Techniken zu suchen, die es ermöglichen, die Anforderungen gezielt zu bestimmen und transparent für alle Seiten zu dokumentieren.

Es hat sich als sinnvoll erwiesen, in einem ersten Schritt die relevanten Informationsquellen zu identifizieren, die Wissen über die zu bearbeitende Thematik (insbesondere zu den zugrunde liegenden Arbeits- und Geschäftsprozessen) besitzen. Zu den Informationsquellen rechnen im Wesentlichen alle Stakeholder; insbesondere die betroffenen Mitarbeiter, aber auch das Management der Fachbereiche. Aus den Stakeholdern werden Repräsentanten ausgewählt, um sinnvolle Anforderungen erheben zu können. Im Ergebnis ist also festzulegen, bei welchen Personengruppen bzw. Personen Informationen im jeweiligen Einzelfall erhoben werden.

Darüber hinaus sind aber auch Richtlinien, Gesetze, Verordnungen, Organisationsstandards, bestehende Systeme, Konkurrenzprodukte und länderspezifische Gegebenheiten als wichtige Informationsquellen zu beachten, wenn bestimmte IT-Lösungen zu entwickeln sind. Träger von Informationen sind also nicht nur Menschen. Belege, Statistiken, Literatur, technische Zeichnungen, Datenbanken etc. enthalten ebenfalls Informationen, aus denen heraus geeignete Anforderungsdefinitionen abgeleitet werden können.

In einem weiteren Schritt werden die relevanten Anforderungen und das Wissen aus den unterschiedlichen Informationsquellen erhoben. Dabei kann sich ein typisches Problem ergeben: Infolge der verschiedenen Quellen ist es nur natürlich, dass die unterschiedlichen Informationsquellen (Stakeholder-Gruppen) durchaus unterschiedliche Anforderungen an das zu entwickelnde IT-System stellen. Aufgrund dieser Gegebenheiten muss oft eine Harmonisierung und Gewichtung der definierten Anforderungen erfolgen.

In jedem Fall lassen sich die anstehenden Fragen und Probleme in der Regel nur lösen, wenn zunächst eine Bestandsaufnahme zu den IT-Anforderungen erfolgt. Damit stellt sich die Aufgabe der Erhebung der zur IT-Lösung nötigen Informationen. In den Analyseschritten (Projektarbeit, Auftragsarbeit) müssen dabei vorwiegend anforderungsorientierte Informationen bzw. lösungsorientierte Informationen beschafft werden.

Die Auswahl der geeigneten Erhebungstechnik hängt immer vom konkreten IT-Projekt bzw. dem definierten Arbeitsauftrag ab. Tabelle 9.1 gibt einen ersten Überblick über mögliche Informationsbeschaffungstechniken (Erhebungstechniken gegliedert nach der Datenaktualität):

Tabelle 9.1 Anforderungserhebungstechniken im Überblick

Technik	Vorgehen und Anwendung
Dokumentenanalyse	Zunächst werden die vorhandenen Informationsquellen (Dokumentenarchive, Datenbanken) gesichtet und gezielte Recherchen (Web etc.) durchgeführt. Gefundene Dokumente werden ausgewertet und im Hinblick auf den Erhebungszweck neu strukturiert.
Interview	Im Rahmen von Interviews findet eine persönliche mündliche Befragung statt. So befragt etwa der IT-Koordinator oder der Anforderungsmanager den Kunden (Enduser, General Management etc.) zu den Detailanforderungen. Auch auf Interviews gilt es sich – im Hinblick auf die Erhebungsziele und die Zielgruppe – sorgsam vorzubereiten (etwa durch Ausarbeitung eines Interviewleitfadens). Grundlage der persönlichen Befragung sollte ein strukturiert geleitetes Befragen der Beteiligten sein.
Fragebogen	Ausgangspunkt zur Durchführung von Befragungen ist zunächst die Abgrenzung des Untersuchungsfelds und die Konfiguration des Fragebogens. Die sinnvolle Konfigurierung bestimmt die Möglichkeit der Fragestellung sowie die Fragenkreise, die sinnvollerweise angesprochen und später ausgewertet werden können. Üblicherweise wird ein Fragebogen als Printfassung oder in elektronischer Form verschickt, der in einem vorgegebenen Zeitraum zu beantworten ist. Bei der Konstruktion des Fragebogens sollte bereits auf die Auswerteoptionen geachtet werden.
Beobachtung	Es erfolgt eine Erhebung unmittelbar in Bezug auf die Arbeits- und Geschäftsprozesse durch einen Beobachter. Möglich ist entweder eine Vollzeit- oder Multimomentbeobachtung.
Gruppentechniken	Im Teamwork werden die auf die angestrebte IT-Lösung bezogenen Geschäftsprozesse in Bezug auf Aufgaben, Bearbeiter, verwendete Dokumente und Hilfsmittel/Ressourcen erfasst und mittels darauf bezogener Anforderungsdokumente dargestellt.

Einige Hinweise für die Anwendung der genannten Erhebungstechniken:

       Die Dokumentenanalyse macht sich die Tatsache zunutze, dass Träger von Informationen nicht nur Menschen, sondern auch Statistiken, Datenbanken, Internet (Netzwerke) sind, die für die sachgerechte Anforderungsermittlung genutzt werden können. Nach der Sammlung der geeigneten Dokumente gilt es Kriterien festzulegen, nach denen eine Auswertung durchzuführen ist.

       Interviews sind geeignet, um etwas über das Handeln, die Motive, Einstellungen und Empfindungen von Personen zu erfahren. Es empfiehlt sich, Interviews gut vorzubereiten (inhaltlich strukturieren, Interviewleitfaden entwickeln) sowie auch den zu befragenden Personenkreis sorgfältig auszuwählen.

       Die Gruppenmethode ist eine der wichtigsten Methoden, um für das gesamte IT-Projekt Motivation, Partizipation und Akzeptanz zu erzeugen und in diesem Kontext harmonisierte Anforderungen an IT-Lösungen zu generieren. Die Teammitglieder und die Vertreter der Fachbereiche lernen, „in Prozessen und Zusammenhängen zu denken“, indem Beziehungen zwischen den zu gestaltenden Elementen transparent werden. Durch dieses Umdenken alleine können Anforderungen zielgerichtet harmonisiert werden.

Beachten Sie:

Das Design der Geschäftsprozesse hat zu einem Teil Einfluss auf die Kundenanforderungen an die IT-Lösung. Demgegenüber entscheidet das Design des IT-Systems (Systemarchitektur) über einen Teil der Systemanforderungen. Die Aufteilung der Funktionalität auf die Komponenten des Systems (eine Designentscheidung) entscheidet über einen Teil der Anforderungen an diese Komponenten. Von der Logik her ist dies ein strikter Top-down-Prozess, der ein guter Leitfaden ist, in der Praxis aber oft nicht so streng gehandhabt wird.

Wie kann eine Qualitätssicherung der erhobenen Anforderungen hergestellt werden? Natürlich beginnt die Qualitätssicherung der Anforderungen schon bei der Auswahl der richtigen Ansprechpartner für die Analyse und endet bei der qualifizierten Prüfung und Bestätigung der Anforderungen. Im traditionellen (sequenziellen) Software-Entwicklungsprozess erfolgen Prüfung und Bestätigung der Anforderungen in der Regel über Reviews und die Freigabe der Anforderungsdokumente. Zur Unterstützung können bei Bedarf Prototypen oder bei Standardsoftware-Lösungen Pilotinstallationen dienen.

9.2.4

Toolgestützte Erfassungsmöglichkeiten

Zur Unterstützung für das IT-Management bzw. den IT-Koordinator kann es sich anbieten, spezielle Software für das Anforderungsmanagement zu nutzen. Auf diese Weise lassen sich

       Anforderungen besser strukturieren,

       Redundanzen bei der Formulierung von Anforderungen vermeiden sowie

       eine Rückverfolgbarkeit der Anforderungen (wann? von wem?) relativ einfach ermöglichen.

Vielfach werden anstelle einer speziellen Software für das Anforderungsmanagement Textverarbeitungssysteme oder Tabellenkalkulationsprogramme verwendet. Allerdings können damit viele Vorteile von Lösungen, die auf einer Datenbank beruhen, nicht genutzt werden. In letzterem Fall werden die Einzel-Requirements systematisch gespeichert und anschließend ihre Abarbeitung verfolgt und überwacht. Zu jedem Requirement wird

       der Start der Bearbeitung der Anforderung,

       das Erreichen von Meilensteinen und

       der (erfolgreiche) Abschluss der Anforderungsbearbeitung vermerkt.

Bezüglich des Erfassens von Anforderungen ist einerseits zu beachten, dass dies unter anderem dazu dient, jederzeit zu wissen, welche Anforderungen vorliegen, von wem und in welchem Zusammenhang sie entstanden sind. Außerdem kann eine Bewertung erfolgen bzw. eine Angabe, in welchem Status sie sich befinden.

Computergestützt ist es in der Regel für die Erfassung von Anforderungen sinnvoll,

       eine formularbasierte Erfassung der Anforderungen vorzunehmen und ggf. ein Anlegen von Anforderungshierarchien zu ermöglichen,

       die Anforderungen zu versionieren sowie automatisch eine Änderungshistorie zu führen,

       eine Definition spezieller Sichten auf die Anforderungen und ein individuelles Reporting zu ermöglichen,

       den aktuellen Bearbeitungszustand der Anforderungen anzuzeigen (unter Festlegung von Kriterien),

       den Weg der Anforderungen von ihrer Definition bis zur Abnahme nachzuvollziehen,

       die Generierung von Dokumenten – zum Beispiel von Lasten- und Pflichtenheften – vorzusehen.

Beachten Sie:

Anforderungsmanagementsoftware, die auf einer Datenbankunterstützung basiert, gestattet es, Anforderungen in Beziehungen zu setzen. Damit wird es möglich, Systemanforderungen auf Kundenanforderungen zurückzuführen und so unter anderem Systemanforderungen festzustellen, die auf keine Kundenanforderungen zurückzuführen sind. Genauso können Tests mit den Anforderungen in Beziehung gesetzt werden, um eine Vollständigkeit von Tests zu gewährleisten.

Anforderungsmanagement verwendet zur Darstellung die natürliche Sprache oder bei Bedarf eine formalisierte natürliche Sprache mit eingeschränktem Vokabular und festen Satzkonstruktionen, den sogenannten Requirements Templates. Die Erfahrung zeigt, dass Sprachen zur Modellierung wie z. B. UML in vielen Situationen eine Formulierung der Anforderungen erleichtern.

Ziel einer Anforderungsspezifikation (u. a. Lastenheft, Pflichtenheft, Fachkonzept) ist es, die Anforderungen so zu formulieren, dass zwischen dem Auftraggeber und Auftragnehmer ein gemeinsames Verständnis über das zu entwickelnde System geschaffen wird. Um das bei natürlicher Sprache zu erreichen, sollten Regeln eingehalten werden. Eine Erweiterung für die Erhebung und Dokumentation der Anforderungen ist dann gegeben, wenn die Möglichkeit zur grafischen Definition von Anforderungen mit der UML und Geschäftsprozessdiagrammen in der Business Process Modeling Notation (BPMN) vorliegt.

Zu jedem grafischen Element in einem UML- oder BPMN-Diagramm können einheitlich strukturierte Anforderungen angelegt werden. Ausgehend von vordefinierten Formularen, die sich an einen spezifischen Dokumentationsbedarf anpassen lassen, werden die Anforderungen erfasst. So kann auch nachvollzogen werden, wie eine bestimmte Anforderung entstanden ist (z. B. personelle Zuordnung).

9.3	IT-Anforderungen in einer Anforderungsspezifikation dokumentieren

Die IT-Anforderungen werden – wie bereits herausgestellt – typischerweise in einem gesonderten Dokument – einer Anforderungsspezifikation – festgehalten. Zweck der Erstellung eines Dokuments „Anforderungsspezifikation für XYZ“ ist es,

       detailliertere Informationen zur Einschätzung der Machbarkeit der formulierten Anforderungen bzw. des geplanten IT-Projekts zu erhalten,

       eine transparente Form zu finden, wie durch eine neue bzw. modifizierte IT-Lösung zukünftig eine Optimierung der Geschäftsprozesse erreicht werden kann (Zielpräzisierung, Nutzendarstellung),

       eine ganzheitliche Übersicht über die Vielfältigkeit der Anforderungen zu IT-Systemen/IT-Lösungen zu erhalten und daraus im Gesamtinteresse des Unternehmens Harmonisierungen herzustellen bzw. Doppelarbeiten zu vermeiden,

       eine klare Basis für eine Aufwandsschätzung für IT-Projekte zu geben und damit auch eine Grundlage für ggf. notwendige Ausschreibungen zu haben,

       eine unverzichtbare Grundlage zu erarbeiten, um ein Lastenheft zu erstellen und mit der zentralen IT-Steuerung für das Erstellen eines Pflichtenhefts abstimmen zu können.

9.3.1

Anforderungen – Dokumentationsvarianten

Ohne eine schriftliche Dokumentation der Kundenanforderungen bzw. der Systemanforderungen ergeben sich vielfach Probleme. Das entsprechende Dokument für eine Anforderungsspezifikation ergibt sich quasi als Vereinbarung von „Sender“ und „Empfänger“. Im Fall der Softwareentwicklung bzw. der Softwareimplementation kann der Sender als Person gesehen werden, die die Spezifikation erstellt. Der Sender gibt das Wissen über die zu realisierende Applikation an die Entwickler/Entwicklerteams weiter. Ähnlich ist bei der Hardwarebeschaffung der Anwender der Sender, der definiert, welche Anforderungen die IT-Infrastruktur bzw. die darin involvierten IT-Komponenten (Netzwerke, Server, Arbeitsplatzsysteme) erfüllen sollen.

Es gibt schon eine Menge Techniken, um Anforderungen grafisch darzustellen. Für objektorientierte Architekturen hat sich die Unified Modeling Language (UML) als Standard he­rausgestellt, für strukturierte Entwicklungen sind die Strukturierte Analyse (SA) und das Information Engineering (IE) sehr brauchbare Ansätze, aber noch kein allgemein akzeptierter Standard (vgl. [Sc01], S. 42ff.).

Zunächst bedarf es einer Grundsatzentscheidung: Wie sollen die Anforderungsspezifikationen der Kunden des IT-Bereichs dokumentiert werden? Unterschieden werden:

       informelle Techniken,

       semiformale Verfahren,

       formale Techniken.

Informelle Techniken verwenden kein komplettes Regelwerk zur Erstellung von Anforderungsspezifikationen bzw. Modellen. Die Gestaltungsmöglichkeiten der Dokumentation werden kaum eingeschränkt. Natürliche Sprache und einfache Schaubilder (Box-and-Arrow-Diagramme) sind Beispiele für eine informelle Spezifikation.

Semiformale Verfahren verwenden eine definierte, eindeutige Syntax. Das kann eine grafische Notation sein, mit präzisen Regeln zur Erstellung der Diagramme oder eine textuelle Notation mit ähnlichen Regeln. Diese grafischen und textuellen Verfahren bieten in der Regel eingeschränkte Überprüfungen der Modelle (z. B. einen Syntax-Checker oder einen Simulator). Beispiele für semiformale Sprachen sind UML und ER-Diagramme.

Formale Techniken haben eine streng definierte Syntax und Semantik. Eine Spezifikation, die in einer mathematischen Notation mit entsprechenden Symbolen ausgedrückt wird, kann mit mathematischen Methoden auf Widersprüche und Vollständigkeit verifiziert werden. Formale Verfahren wie etwa Petri-Netze erlauben die (teil-)mechanische Verifikation von Programmen oder den Beweis bestimmter Modell- oder Programmeigenschaften. Dies ist mit semiformalen und informellen Verfahren kaum möglich. Sie decken unterschiedliche Teile des Softwareentwicklungsprozesses ab. Einige Ansätze gehen nicht über eine reine Notation hinaus. Deshalb wird erst über ein Nutzungskonzept und Werkzeuge eine formale Spezifikationstechnik praktisch nutzbar.

9.3.2

Typische Inhalte einer Anforderungsspezifikation

Im Rahmen einer Organisation des IT-Anforderungsmanagements sollte jedes Unternehmen insbesondere festlegen, welche Eigenschaften in einer Anforderungsspezifikation vorliegen sollten, die ein IT-Produkt (bzw. ein zu entwickelndes IT-System bzw. eine Softwarelösung) oder ein IT-Service erfüllen muss.

Es gibt keine Grundregel, in welcher Form Anforderungen zu dokumentieren sind. Die Dokumentation sollte immer an die Beteiligten angepasst sein. Es sollten auch nur so viele Fachbegriffe verwendet werden, dass jeder Beteiligte die Anforderung lesen kann. Sind Fachausdrücke unumgänglich, sind diese in einem Glossar zu konkretisieren. Ein Standard-Template für eine Anforderungsspezifikation mit inhaltlichen Vorgaben ist in der folgenden Darstellung gezeigt.

0.      Management Summary ..................................................................... 4

0.1.   Movaon ................................................................................ 4

0.2.   Aktuelle Situaon ...................................................................... 4

0.3.   Anforderungsübersicht zur Situaonsverbesserung. ................ 4

0.4.   Vorschläge für die nächsten Schrie ........................................ 4

1.      Einführung / Allgemeines ................................................................... 5

1.1.   Zweck des Dokuments .............................................................. 5

1.2.   Änderungsübersicht .................................................................. 5

1.3.   Verteiler .................................................................................... 5

1.4.   Abkürzungen / Glossar .............................................................. 5

1.5.   Zugehörige Dokumente ............................................................ 6

2.      Ausgangssituaon und Problemstellung des Projekts ........................ 7

2.1.   Auslöser und Herausforderungen ............................................. 7

2.2.   Konkresierung der Zielsetzungen ............................................ 9

2.3.   Konkresierung der Ergebnisse ................................................ 9

2.4.   Interessengruppen (Stakeholder) ............................................. 9

3.      Ist-Situaon – Darstellung und Beurteilung ...................................... 11

3.1.   Geschä˜sprozessabgrenzung .................................................. 11

3.2.   Beschreibung der Ist-Geschä˜sprozesse ................................ 11

3.3.   Geschä˜sobjekte / Daten (Datenmodelle) ............................. 11

3.4.   Beurteilung der aktuellen Situaon ........................................ 12

3.5.   Vorhandenes IT-System / Systeme und ihre Bewertung ......... 13

4.      Soll-Situaon .................................................................................... 16

5.      Anforderungen – Anwendungsfälle und Anforderungsliste ............. 18

5.1.   Anwendungsfälle (Anwendungsfunkonen) ........................... 18

5.2.   Prozessuale und funkonale Anforderungen .......................... 20

5.3.   Tes›älle ................................................................................... 21

6.      Schnistellen .................................................................................... 22

7.      Nich›unkonale Anforderungen ...................................................... 23

7.1.   Zu beachtende Richtlinien für die Projektergebnisse ............. 23

7.2.   Qualitätsanforderungen .......................................................... 23

7.3.   Sicherheits-Anforderungen / Berechgungen ........................ 24

7.4.   Gesetzliche Anforderungen und Randbedingungen ............... 24

7.5.   Technische Anforderungen und Risikoplanung ....................... 24

8.      Vorschläge für die nächsten Schrie ................................................ 26

Das Template der Gliederung zeigt, dass es sinnvoll ist, eine Management-Summary zu Beginn (quasi für den „schnellen“ Leser) einzufügen. Darüber hinaus sind die Ausgangssituation und die Problemstellung bei IT-Projekten zu skizzieren.

Die Formulierung der konkreten Anforderungen zu einem Projektantrag macht eine Erhebung, Beschreibung und Analyse des Ist-Zustands (unter Berücksichtigung der Rahmenbedingungen) erforderlich. Eine Darstellung der gesamten von der Umstellung betroffenen derzeitigen Organisation mit den aufgefundenen Problemen bildet die Grundlage für eine künftige Lösung.

Dazu einige ausgewählte Hinweise:

Geschäftsprozessabgrenzung: Die angestrebte IT-Lösung soll/muss die Geschäftsprozesse unterstützen. Dies ist heute übereinstimmend als Kernaufgabe zu konstatieren. Deshalb gilt es für die IT-Anforderungen beim Kunden zunächst an den Geschäftsprozessen anzusetzen. Im Rahmen von prozessorientiert „aufgestellten“ Organisationen entscheidet das Design der Geschäftsprozesse über einen Großteil der Kundenanforderungen an die IT-Lösung. Wichtig ist dabei, dass eine klare Geschäftsprozessabgrenzung vorliegt. Für eine Einordnung der Geschäftsprozesse, auf die sich die neue IT-Lösung bezieht bzw. die sie unterstützt, ist eine Darstellung als Wertschöpfungskette (möglichst grafisch) nützlich.

Beschreibung der Ist-Geschäftsprozesse: Zur Umsetzung der ganzheitlichen Anforderungen an IT-Lösungen sind eine Modellierung der Geschäftsprozesse, der IT-Architekturen und eine darauf aufbauende Vernetzungsanalyse empfehlenswert. Dazu sind alle Elemente der Geschäftsprozessorganisation zu erfassen und in ihrem Beziehungszusammenhang darzustellen. Damit kann dann eine exakte Ist-Situation der Geschäftsprozesse erstellt werden, was die Konzeption ganzheitlich orientierter Lösungswege ermöglicht. Auch die dazu notwendige Beschreibung der Geschäftsprozesse sollte möglichst grafisch erfolgen. Dazu sollte die in der Organisation typische Notation zur Darstellung von Geschäftsprozessen verwendet werden.

Geschäftsobjekte/Daten (Datenmodelle): Die Datenarchitektur beschreibt den statischen Zusammenhang zwischen Daten, die für das gesamte Unternehmen von Interesse sind, in Form von Datenmodellen. Folgende Fragen/Punkte bedürfen in diesem Zusammenhang einer Klärung und Skizzierung: Verzeichnis aller Daten (Datenbanken/Datenbestände) im Zusammenhang mit der angestrebten IT-Lösung, Klassifikation der Daten nach der Bedeutung für das Unternehmen, Pflichten/Rechte der Dateneigner.

Für die Detailbeschreibung der Soll-Applikationsarchitektur kann eine Unterscheidung nach folgenden Bausteinen erfolgen:

       Soll-Applikationslandschaft: Diese Option dient der Darstellung der Soll-Funktionalität der Anwendungen bezogen auf die Geschäftsprozesse des Unternehmens.

       Die technische Sicht zeigt die Systeme aus IT-Sicht mit ihren Bausteinen, ihrem Zusammenwirken sowie der datenmäßigen Integration.

       Das Systemdesign zeigt die Designprinzipien und genutzten Standards beim Aufbau der Applikationen, inklusive der Positionierung und Integration von eingekauften Komponenten.

Die Prozessarchitektur beschreibt im Wesentlichen die Ziele und Inhalte der Geschäftsprozesse sowie die hierfür erforderliche Aufbauorganisation (Strukturen, Rollenkonzept) des Unternehmens. Notwendig sind zunächst einmal folgende Aktivitäten:

       Festlegung einer prozessorientierten Ausrichtung für die angestrebte IT-Lösung.

       Erstellung einer Prozesslandkarte, in der alle wesentlichen Geschäftsprozesse identifiziert und definiert sind.

Zur Darstellung von Anwendungsfällen wird die Nutzung der Modellierungssprache UML empfohlen. Dies ist eine Sprache zum Spezifizieren, Konstruieren, Visualisieren und Dokumentieren eines Softwaresystems. Grundsätzlich gilt: Mit UML lassen sich die Anforderungen der Benutzer darstellen. Entsprechende Modelle können als Basis für die Optimierung von Geschäftsprozessen dienen und den Entwurf der Anwendungsprogramme unterstützen. Mit dem Use-Case-Konzept werden durchgängige Geschäftsprozesse dargestellt; sie be­schreiben abstrakt das Zusammenwirken von Menschen mit einem System und bilden den Ausgangspunkt für eine GPM (Geschäftsprozessmodellierung) nach UML. Sie liefern zu­nächst einen groben Überblick.

Im Rahmen des nächsten Detaillierungsschritts erfolgt die Spezifizierung der Use-Cases. Nach UML kommen hier einerseits die textuelle Spezifikation in Frage, andererseits die Interaktionsdiagramme und letztlich Aktivitätsdiagramme. Diese zeigen, wie (Geschäfts-) Objekte miteinander kommunizieren, um eine bestimmte Transaktion durchzuführen. Aktivitätsdiagramme sind vergleichbar mit Zustandsdiagrammen, nur steht eben nicht der Zustand im Mittelpunkt des Interesses, sondern die Aktivität.

9.3.3

Qualitätssicherung der Anforderungsdokumentation

Eine Spezifikation ist eine Art der schriftlichen Kommunikation. Das entsprechende Dokument ergibt sich quasi als Vereinbarung von „Sender“ und „Empfänger“:

       Im Fall der Softwareentwicklung bzw. der Softwareimplementation kann der Sender als Person gesehen werden, die die Spezifikation erstellt. Der Sender gibt das Wissen über die zu realisierende Applikation an die Entwickler/Entwicklerteams weiter. Ähnlich ist bei der Hardwarebeschaffung der Anwender der Sender, der definiert, welche Anforderungen die Infrastruktur erfüllen soll.

       Als Empfänger kommt ein IT-Produktmanager, Systemarchitekt oder Softwarearchitekt (Programmierer etc.) in Betracht. Er erhält die Information (= Anforderungsspezifikation) und verarbeitet diese in weiterer Folge.

In einer Anforderungsspezifikation werden die Eigenschaften vereinbart, die ein IT-Produkt/eine IT-Applikation oder ein IT-Service erfüllen muss. Dies geschieht mitunter gerade im IT-Bereich in einem mathematisch-logischen Formalismus.

Die wesentlichen Hauptmerkmale, die eine gute Anforderungsspezifikation im IT-Bereich aufweisen soll, sind der Tabelle 9.2 zu entnehmen:

Tabelle 9.2 Hauptmerkmale einer IT-Anforderungsspezifikation

Merkmale	Hinweise/Leitfragen
Vollständigkeit	Dokumentiert die Spezifikation alle Wünsche des Kunden? Ist die Spezifikation darüber hinaus auch formal vollständig, d. h. werden Standards, Reglements oder Formatierungen eingehalten?
Verständlichkeit	Liegen die Anforderungen zur Spezifizierung in einer verständlichen und überschaubaren Form vor? Sind die Anforderungen prägnant formuliert?
Widerspruchsfreiheit	Widersprechen sich Anforderungen in der Spezifikation? Werden in der Spezifikation unterschiedliche Aussagen gemacht, die nicht in Einklang zu bringen sind? Werden unterschiedliche Begriffe für ein und denselben Sachverhalt verwendet oder existieren falsche Verweise und Bezugnahmen, beispielsweise in Indizes und Verzeichnissen?
Prüfbarkeit bzw. Traceability (Nachvollziehbarkeit)	Lassen sich die festgelegten Anforderungen überprüfen? Existieren Verfahren, um die Anforderungen zu prüfen? Sind die Anforderungen nachvollziehbar?
Eindeutigkeit	Ist die Spezifikation unterschiedlich auslegbar? Lassen alle dokumentierten Anforderungen genau eine Interpretation zu?
Adäquatheit	Dokumentiert die Spezifikation das, was vom Kunden gefordert und gewünscht wird?

9.4	IT-Anforderungen analysieren und bewerten

Eine wesentliche Zielsetzung eines professionellen Anforderungsmanagements ist es, zwischen den Kunden und den Entwicklern/Projektmitgliedern ein Einverständnis über die Anforderungen, die ein neues bzw. ein modifiziertes IT-System erfüllen soll, zu erreichen. Dazu müssen zunächst die Anforderungen ermittelt und dokumentiert werden, daraufhin sind eine Analyse und eine Bewertung der Anforderungen nötig. Dieses Ergebnis wird dann entsprechend in einer Vereinbarung bzw. einem Lastenheft fixiert. Den Zusammenhang zeigt Bild 9.3.

Bild 9.3 Teilprozess „IT-Anforderungen analysieren, darstellen und bewerten“ (Requirements Analysis)

Die Phase „Entwicklung/Integration“ ist das Herzstück des allgemeinen Systementwicklungsprozesses für den Normalfall. Sie enthält grundsätzlich die folgenden Teilphasen:

       Analyse (Festlegung der detaillierten Anforderungen an das konkrete Systementwicklungsvorhaben oder -teilvorhaben)

       Design (Festlegung der technischen Umsetzung der Anforderungen)

       Implementierung (Umsetzung der im Design vorgegebenen Anforderungen)

       Test (Test des resultierenden IT-Systems oder -Teilsystems)

Die Teilphase „Analyse“ dient der Konkretisierung der Anforderungen an das im Pflichtenheft beschriebene IT-System. Ergebnis dieser Phase ist die Anforderungsspezifikation. Teilergebnisse fließen in den QS-Plan ein. Zur Dokumentation empfiehlt es sich, entsprechende Templates zu verwenden.

Für das Analysieren der Anforderungen sollten diese inhaltlich und formal strukturiert werden, sodass eine Konsolidierung vorgenommen werden kann. Darüber hinaus ist es notwendig, eine Konsistenz zu den Anforderungen herbeizuführen. Hierzu sind die Be­schreibungen zu vervollständigen sowie Abhängigkeiten zwischen den einzelnen Anforderungen herauszuarbeiten.

Eine hilfreiche Voraussetzung für eine Strukturierung von Anforderungen ist dann gegeben, wenn diese „sauber“ formuliert wurden. Durch das Festlegen und Vereinbaren von Richtlinien kann erreicht werden, dass die Formulierung von Anforderungen die gestellten Herausforderungen erfüllt:

       Die formulierten Anforderungen sollten möglichst eindeutig und konsequent durchnummeriert werden.

       Die Anforderungen sollten sinnvollerweise geclustert werden, indem eine Strukturierung in Klassen und Gruppen erfolgt.

       Typischerweise kann eine Dokumentation der Quellen (Ausgangspunkte), Funktionen und Prozesse von Anforderungen notwendig sein.

       Es ist sicherzustellen, dass Änderungen und Beziehungen ständig gepflegt werden.

       Abhängigkeitsbeziehungen zu funktionalen Beschreibungen (beispielsweise Implementierungssicht, SW-Klassen, Komponenten) sind zu berücksichtigen.

Liegen die Anforderungen systematisch strukturiert vor, ist eine gezielte Anforderungsanalyse nötig. Damit kann insbesondere die Kluft zwischen tatsächlichem Bedarf/Anforderungsproblem und denkbarer Lösung überbrückt werden. Im Ergebnis sollte schrittweise durch die Analysen auch ein (Lösungs)Modell mit einer unterschiedlichen Genauigkeit er­stellt werden.

Um die Anforderungsanalyse durchzuführen, sind unterschiedliche Methoden denkbar. Verbreitete Methoden zur Bewältigung dieser Aufgaben sind Use Cases (Anwendungsfälle bzw. Anwendungsfallanalyse) sowie Begriffs- oder Bedeutungsanalysen. Die Anwendungsfallanalyse zeigt besonders gut auf, welche Beteiligten (Akteure) etwa für die geplanten Systeme (Applikationen) aufgrund der Anforderungssituationen Zugriffsrechte benötigen. Wichtig ist dabei auch festzuhalten, welche Abhängigkeiten zwischen den Anwendungsfällen bestehen. Während der Modellierung der Anwendungsfälle können mitunter auch neue Anforderungen identifiziert werden. Es kann auch ergänzend ein Berechtigungskonzept mithilfe der Anwendungsfälle erarbeitet werden.

Nachdem alle Anforderungen in geeigneter Weise analysiert wurden bzw. auf die Machbarkeit geprüft wurden, können diese bewertet und priorisiert werden. Es empfiehlt sich, ein einfaches Prioritätensystem zu verwenden. Hierfür werden zum Beispiel folgende Kategorien angewendet:

       „Need to have“ (Muss-Anforderungen): Anforderungen, die umgesetzt werden müssen.

       „Want Need to have“ (Soll-Anforderungen): Anforderungen, die umgesetzt werden sollen.

       „Nice to have“ (Kann-Anforderungen): Anforderungen, die dann umgesetzt werden, wenn noch ausreichende Ressourcen dazu verfügbar sind.

       „Not to have“ (nicht umzusetzende bzw. nicht umsetzbare Anforderungen).

Nachdem die Anforderungen entsprechend der zuvor skizzierten Varianten bewertet wurden, sollten diese Zuordnungen auch mit dem Kunden besprochen werden. Dies macht das spätere Arbeiten mit den Anforderungen deutlich leichter. Hinweis: In der Umsetzung der Bewertung kann zwischen der Anwendung der ABC-Analyse bzw. einer Punktbewertung (Nutzwertanalyse) differenziert werden.

9.5	Systemanforderungen definieren

Liegen abgestimmte und geprüfte Kundenanforderungen vor, ist diese Anforderungssammlung im nächsten Schritt um die Informationen zu ergänzen, die festhalten, was das künftige IT-System letztendlich machen soll und wie das System (das IT-Produkt) aussehen soll (insbesondere hinsichtlich Architektur, Funktionalität). Gleichzeitig sind auch die Schnittstellen genau zu definieren. Diese Dokumente werden zu einer „System Requirements Specification“, in der alle systemtechnischen Anforderungen an das Produkt (die IT-Lösung) enthalten sind, vereint. Dieses Dokument wird von den IT-Architekten und Entwicklern in der Regel in Teamwork erstellt.

Die Dokumente sind dann von den Softwaredesignern, Systementwicklern und Programmierern zu analysieren und umzusetzen. Wichtig ist, dass eine ganzheitliche, umfassende Systemanforderungsdefinition typischerweise in einem mehrstufigen Prozess realisiert wird. Ausgehend von der Definition der Kundenanforderungen sind dies z. B.:

       Definition der Systemanforderungen (sie definieren das zu entwickelnde oder zu liefernde System),

       Definition der Anforderungen an die System-/Produktarchitektur (Architekturspezifikation),

       Definition der Anforderungen an die Komponenten des Systems, die von den Systemanforderungen und der ausgewählten Architektur abgeleitet werden.

Bei der Formulierung und Festlegung der Systemanforderungen werden verschiedene iterative Schritte durchlaufen. Neben einer Analyse wird auch ein Konzept mit einer unterschiedlichen Genauigkeit erstellt und darauf bezogene Systemspezifikationen werden als Dokumente erzeugt. In Bild 9.4 sind noch einmal die Zusammenhänge und Aktivitäten dieser Phase dargelegt, indem auch Instrumente und Akteure genannt werden.

Bild 9.4 Teilprozess „Lösungswege zur Umsetzung der Anforderungen formulieren“ (= Systemanforderungen)

Bisher lag der Schwerpunkt der Darstellung auf der fachlichen und anwenderorientierten Seite. Es müssen Informationen über den Ist-Zustand beschafft werden. Diese müssen dann analysiert und dokumentiert werden. Als Ergebnis sollte hier die Gesamtheit der Funktionalitäten des Systems spezifiziert werden. Nach Versteegen et al. (2004, S. 22) sind folgende Aktivitäten (nach der Ist-Aufnahme und Ist-Analyse) zu realisieren:

       Künftiges IT-System beschreiben: In einem ersten Schritt sollte das geplante bzw. zu entwickelnde IT-System zunächst relativ grob skizziert werden. Die sich ergebende Systembeschreibung bildet dann den Rahmen für alle weiteren Detaillierungen und Verfeinerungen. Gleichzeitig können daraufhin Ergänzungen/Modifikationen zu den Kundenanforderungen notwendig werden.

       Kritikalität und Anforderungen an die Qualität definieren: Im Rahmen der zu definierenden Kritikalität des IT-Systems sind die Gefahrenpotenziale zu prüfen und zu skizzieren, die existieren können oder durch die Anwender verursacht werden können. Anforderungen an die Qualität aus der fachlichen Sicht werden zumeist auf Basis der DIN ISO festgelegt. Dabei werden die externen Vorgaben hinzugezogen, die bei der Auftragsvergabe vereinbart werden.

       Randbedingungen definieren: Alle technischen, organisatorischen und weiteren Anforderungen, die Einfluss auf das zu entwickelnde IT-System haben, müssen dokumentiert werden.

       System fachlich strukturieren: Dabei wird das System aus fachlicher Sicht strukturiert und beschrieben/dokumentiert. Die Systemstruktur wird nach Vorgaben durch den Kunden dokumentiert und modelliert. Für die Darstellung der Funktionen des Systems und der Definition der Geschäftsprozesse sind Vorgaben zu fixieren.

       Bedrohung und Risiko analysieren: Integriert sollte zu den zu entwickelnden IT-Produkten eine Bedrohungs- und Risikoanalyse erstellt werden. In diesem Rahmen werden die für das System relevanten Bedrohungen und die damit verbundenen Risiken ermittelt. Diese Risiken werden hinsichtlich ihrer Eintrittswahrscheinlichkeit und des zu erwartenden Schadens bewertet. Die Ergebnisse dieser Bedrohungs- und Risikoanalyse bilden die Grundlage für die Formulierung von Anforderungen an die IT-Sicherheit bzw. zur Risikoabsicherung des Systems innerhalb der Anwenderforderungen.

Merke:

Mit der Systemspezifikation wird ein Dokument ausgearbeitet, das die Aufgaben, die das IT-System erfüllen soll (das „Was“), möglichst vollständig definiert. Damit wird aber nicht die Umsetzung (das „Wie“) festgelegt, weder Entwurf noch Implementierung noch Projektorganisation. Letztlich werden darin fachliche Funktionen detailliert, konsistent, vollständig und nachvollziehbar beschrieben.

Grundsätzlich geht es bei der Festlegung der Systemspezifikation um folgende Aspekte:

       Festlegung der Funktionen eines IT-Systems

       Was wird wann wie mit der neu entwickelten IT-Lösung gemacht?

Die Systembeschreibung stellt eine Beschreibung des IT-Systems dar. Es ist primär eine Beschreibung der wesentlichen Merkmale und soll den Endanwendern des Anforderungsmodells (User bzw. Development) wichtige Basisinformationen für die darin dokumentierten Anforderungen geben. Als weitere typische Inhalte einer Systemspezifikation können genannt werden:

       Benutzerschnittstelle: Masken, Dialogabläufe

       Objektmodell: Daten- und Funktionenmodell

       Nachbarsysteme (Hardware oder Software): Schnittstellen beschreiben die Abgrenzung in die aktuell bestehende Systemlandschaft und die dazu bestehenden Schnittstellen.

Hauptergebnisse der Phase „Grobanalyse und Systemarchitektur“ sind neben der Anforderungsspezifikation vor allem das Systemkonzept. Teilergebnisse fließen in den QS-Plan für die Systemspezifikation ein. Zur Dokumentation sind die entsprechenden Templates zu verwenden.

Beispiele für die notwendigen Aktivitäten (incl. der Dokumente bzw. der Akteure) zeigt Tabelle 9.3.

Tabelle 9.3 Systemspezifikation

Dokumente	Tätigkeit, Aktivität	durchzuführen von
Anforderungsspezifikation	Analyse des Ist-Zustands	Systementwickler, Fachabteilungsmitarbeiter
Anforderungsspezifikation	Fachliche Analyse des Soll-Zustands des Gesamtsystems (Detaillierung des Pflichtenhefts auf Basis von Use Cases)	Systementwickler, Fachabteilungsmitarbeiter
Anforderungsspezifikation	Angabe von Mengengerüsten (Anwenderanzahl, Häufigkeit der Verwendung von Systemfunktionen etc.)	Systementwickler, Fachabteilungsmitarbeiter
Anforderungsspezifikation	Festlegung von Benutzerprofilen	Systementwickler, Fachabteilungsmitarbeiter
Schnittstellenmodell	Identifikation systemexterner Schnittstellen	Systementwickler, Fachabteilungsmitarbeiter, RZ-Mitarbeiter
QS-Plan für die Systemspezifikation	Detaillierung von Qualitätsanforderungen (z. B. IT-Sicherheitsanforderungen (Datensicherheit, Datenschutz, Ausfallsicherheit, Archivierung etc.), Anforderungen bzgl. Produktionsfähigkeit, Anforderungen an das User Interface etc.)	QS-Beauftragter (in Projekten), Produktverantwortlicher, RZ-Mitarbeiter, Auftraggeber, Fachabteilungsmitarbeiter
QS-Plan für die Systemspezifikation	Definition von QS-Maßnahmen (z. B. IT- Sicherheitskonzept, Planung von Reviews, Planung von systemspezifischen Richtlinien für User Interface, Programmierung etc.)	QS-Beauftragter (in Projekten), Projektleiter (in Projekten), Produktverantwortlicher, RZ-Mitarbeiter

9.6	IT-Anforderungen validieren

Fast kein IT-System (keine Softwareapplikation) läuft fehlerfrei und erfüllt die an das System gestellten Anforderungen der Kunden vollständig. Die Gründe dafür sind vielfältig:

       unzureichende Anforderungsdefinitionen,

       fehlerhafte (funktionale bzw. technische) Systementwürfe oder

       Programmierfehler bei der Softwareentwicklung bzw. Softwareanpassung.

Unzureichende Anforderungsabdeckung und Fehler verursachen mitunter erhebliche Nachbearbeitungen und Folgekosten. Dies ist ein weithin bekanntes Problem. Um derartige Fehler zu vermeiden, sollte im Vorfeld eine systematische Planung erfolgen und die Anforderungen einer Validierung unterzogen werden. Ein adäquates Qualitätsmanagement kann in besonderer Weise helfen, rechtzeitig potenzielle Fehlerquellen zu eliminieren, und damit die Wahrscheinlichkeit eines Fehlerauftritts minimieren.

In Bild 9.5 werden noch einmal die Zusammenhänge und Aktivitäten dieser Phase dargelegt, indem auch Instrumente und Akteure genannt werden.

Bild 9.5 Teilprozess „IT-Anforderungen validieren“ (Specification Validation)

Der Prozess der Qualitätssicherung von Anforderungen bezieht sich auf die Aspekte Verifikation und Validierung

       Die Verifikation sagt aus, ob die Anforderungen im Kontext auf das zu entwickelnde System richtig spezifiziert wurden. Aufgrund eines Abnahmetests wird bestätigt, dass festgelegte Anforderungen erfüllt worden sind.

       Die Validierung sagt aus, ob die richtigen Anforderungen an das System spezifiziert wurden. Aufgrund einer Untersuchung wird bestätigt, dass die besonderen Forderungen für einen speziellen beabsichtigten Gebrauch erfüllt worden sind.

Die Ausführungen legen ein integriertes Testmanagement nahe, das klar definierte Kriterien und erprobte Techniken vorsieht. Erforderlich sind die zu den Anforderungen definierten Abnahmekriterien, die bei der Erstellung der Testdrehbücher – als Soll-Werte – verwendet werden.

Beachten Sie:

Um eine ganzheitliche Qualitätssicherung zu ermöglichen, sollte das Anforderungsmanagement unmittelbar die Anforderungen/Vorgaben an eine Applikation mit Testfällen verknüpfen. So wird bereits früh eine praktische Umsetzbarkeit von formulierten Anforderungen überprüft. Mögliche Abweichungen können rechtzeitig erkannt werden, sodass Änderungswünsche bzw. Nacharbeiten innerhalb eines gesteckten Projektrahmens erfolgreich umgesetzt werden können. Fazit: Mit integriertem Anforderungs- und Testmanagement kann ein höherer Projekterfolg gewährleistet werden.

9.7	Besonderheiten des Anforderungsmanagements in agilen Entwicklungsumgebungen

Das International Requirements Engineering Board [IREB] hat als zeitgemäße Interpretation des Begriffs „Requirements Engineering“ Folgendes vorgeschlagen:

„Requirements Engineering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist, zu gewährleisten, dass

       alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,

       die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen,

       alle Anforderungen konform zu den Dokumentationsvorschriften des Unternehmens dokumentiert sind.“

Durch Verwendung der Adjektive „kooperativ, iterativ und inkrementell“ wird das Anforderungsmanagement für die IT bewusst weg vom klassischen Wasserfallmodell geführt. Somit wird auch von der Annahme, dass möglichst alle Anforderungen am Anfang eines Projekts präzise und detailliert festgelegt werden müssen, „abstrahiert“. Der Weg geht vielfach hin zu einem agilen Vorgehen, in dem die Zusammenarbeit aller Projektbeteiligten und Projektbetroffenen gefordert wird (vgl. [Hru18], S. 454 ff.).

Im agilen Umfeld – insbesondere bei Scrum – fallen die Tätigkeiten bzw. die Verantwortung für die Erhebung und Kommunikation der Anforderungen in den Aufgabenbereich eines Product Owners oder Produktmanagers. In wiederum anderen Projekten – vor allem bei kleineren Teams – ist es eine Aufgabe, die alle Teammitglieder erledigen müssen. Wer auch immer für das Anforderungsmanagement zuständig ist, die Anforderungen bedürfen in allen Fällen einer hinreichenden Klärung und Spezifikation.

Unabhängig von der Art des IT-Projekts und dem gewählten Vorgehensmodell ist es in allen Projekten notwendig, erforderliche Änderungen bei den Anforderungen im Projektverlauf systematisch zu analysieren und zu bewerten. Der Kunde muss dabei immer eine Rückmeldung erhalten, ob und warum die Änderung von den anderen Beteiligten (Entwickler etc.) als notwendig eingeschätzt wird. Es besteht daher in jedem Projekt die Notwendigkeit, zu Beginn zumindest eine grobe Planung und Spezifikation zu erstellen. Das Product Backlog und die Releaseplanung sind in agilen Entwicklungsumgebungen genau solche Pläne, auf die hier Bezug genommen werden kann (vgl. [Be14], S. 7).

Das Wichtigste – zusammengefasst

       Jede IT-Organisation benötigt eine konsequente Kunden- und Serviceorientierung, um nachhaltig bedarfsgerechte IT-Gesamtlösungen für das Unternehmen bereitzustellen.

Zur Umsetzung der Kunden- und Serviceorientierung ist eine kontinuierliche Maßnahmenentwicklung unumgänglich, die unter anderem auch eine Harmonisierung der Kunden- und IT-Anforderungen (Customer-Relationship-Management, Demand-Management) ermöglicht.

       Wesentliches Ziel für das kundenorientierte IT-Anforderungsmanagement ist es, effiziente und fehlerarme (störungsfreie) IT-Systeme bzw. IT-Lösungen zu entwickeln und dem Anwender so bereitzustellen, dass eine hohe Kundenzufriedenheit erreicht wird.

Anforderungen der IT-Kunden können sich auf unterschiedliche Domänen beziehen, etwa auf verschiedene Architekturbereiche bzw. Systemebenen (Standardanwendungen, Individualapplikationen, Datenarchitekturen und Storage, Infrastrukturen etc.), oder verschiedene Funktions- und Prozessfelder betreffen. Abhängig von den sich ergebenden Anforderungsarten kann ein unterschiedliches Vorgehen für die Präzisierung der Anforderungen notwendig sein.

       Schaffen Sie optimale Voraussetzungen für ein professionalisiertes Anforderungsmanagement!

Im Rahmen einer Organisation des IT-Anforderungsmanagements sollte insbesondere festgelegt werden, welche Eigenschaften in einer Anforderungsspezifikation vorliegen sollten, die ein IT-System oder ein IT-Service erfüllen muss. Erfahrungen der Praxis zeigen außerdem, dass das Aufstellen von Anforderungen allein nicht ausreicht, sondern für die erfolgreiche Realisierung einer IT-Lösung oder eines IT-Systems ein umfassender Prozess des ganzheitlichen Anforderungsmanagements notwendig ist.

       Beachten Sie, dass für ein erfolgreiches Anforderungsmanagement eine verstärkte Kunden- und Serviceorientierung wesentlich ist!

Vielfach muss eine Verhaltensänderung der IT-Akteure einerseits realisiert werden, andererseits muss damit auch eine andere Wahrnehmung und Verbindlichkeit der IT-Leistungen bei den Fachabteilungen einhergehen. Das Verständnis des IT-Bereichs, ein interner Dienstleister zu sein und auch als dieser aufzutreten, kann auf diese Weise gestärkt werden. IT-Services werden letztlich transparent, nachvollziehbar und besser planbar.

       Die Anforderungsanalyse und das Anforderungsmanagement entscheiden über den Erfolg Ihrer IT-Projekte und die Qualität der eingesetzten IT-Systeme. Sie nehmen die zentrale Stellung in der Systementwicklung ein.

Wichtig sind die Definition und die Anwendung als Prozess, Anforderungen an Systeme zu erheben und ihre ständige Veränderung zu managen. Anforderungsmanagement ist letztlich als eine Managementaufgabe für die effiziente und fehlerarme (störungsfreie) Entwicklung und Bereitstellung komplexer IT-Systeme bzw. IT-Lösungen zu verstehen.

       Ein professionalisiertes IT-Anforderungsmanagement leistet für die Unternehmen einen wesentlichen Beitrag zu optimierten IT-Lösungen, die den Anforderungen der Anwender (Fachbereiche, Endbenutzer) in besonderer Weise unter Beachtung von Wirtschaftlichkeitsaspekten Rechnung tragen.

Die Wünsche der Anwender an die IT können sich auf unterschiedliche Bereiche beziehen. Dies können sein: Softwareanforderungen (Applikationen, Anwendungen), Ausstattung mit IT-Systemen (Arbeitsplatzsystem, Vernetzung, Speicher- und Serverleistungen), Implementationsunterstützung (Schulung etc.), das Erbringen von Serviceleistungen (Support bei Ausfällen, Fehlern etc.) sowie Beratungsunterstützung.

9.8

Literatur

[Be14]	Bergsmann, J.: Requirements Engineering für die agile Softwareentwicklung. dpunkt.verlag, Heidelberg 2014.
[GaTi06]	Gadatsch, A.; Tiemeyer, E. (Hrsg.): Betriebswirtschaft für Informatiker und IT-Experten. Elsevier, Heidelberg 2006.
[Eb08]	Ebert, Chr.: Systematisches Requirements Engineering und Management: Anforderungen ermitteln, spezifizieren, analysieren und verwalten. dpunkt, Heidelberg 2008.
[Eb09]	Ebert, Chr.: Systematisches Requirements Management. dpunkt, Heidelberg 2009.
[Hru14]	Hruschka, P.: Business Analysis und Requirements Engineering – Produkte und Prozesse nachhaltig verbessern. Hanser, München 2014.
[Hru18]	Hruschka, P.: Requirements Engineering. In: Handbuch IT-Projektmanagement – Vorgehensmodelle, Managementinstrumente, Good Practices. 3. Auflage. Hanser, München 2018.
[Ru09]	Rupp, Chr.: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis. 5., aktualisierte und erweiterte Auflage. Hanser, München 2009.
[Ru14]	Rupp, C.: Requirements-Engineering und -Management – Aus der Praxis von klassisch bis agil. 6., aktualisierte und erw. Aufl. Hanser, München 2014.
[Sc01]	Schienmann, B.: Kontinuierliches Anforderungsmanagement: Prozesse – Techniken – Werkzeuge. Addison-Wesley, München 2001.
[Ti08]	Tiemeyer, E.: IT-Projekte erfolgreich managen. Zeit, Kosten und Ziele im Griff. rauscher. Verlag, Haag i. Obb. 2008
[Ve04]	Versteegen, G.; Heßeler, A.; Hood, C.; Missling, C.; Stücka, R.: Anforderungsmanagement. Springer, Berlin, Heidelberg, New York 2004.
[Ve09]	Versteegen, G.: Anforderungsmanagement in Zeiten der Wirtschaftskrise. Objektspektrum online-Ausgabe 2009.