Um die Frage nach den Eigenschaften einer neu zu beschaffenden Software oder Hardware zu beantworten, ist es zunächst einmal notwendig, zu wissen, welche Aufgaben überhaupt erfüllt werden sollen. Das führt uns auf direktem Weg zur Anforderungserhebung und zur Ist-Analyse. Denn bevor Sie die Frage nach dem „Wo will ich hin?“ allumfassend beantworten können, ist es notwendig, zu wissen: Wo stehe ich denn jetzt? Wie sind die Voraussetzungen? Auf welcher Basis arbeitet das System aktuell? Welche Technologien und Methoden werden zurzeit eingesetzt?Erst wenn Sie genau wissen, mit welchem System Sie es zu tun haben, können Sie abschätzen, was auf Sie zukommt, wenn Sie ein Hardware- oder Softwaresystem modernisieren wollen. Die Anforderungsanalyse (englisch Requirements Analysis) hat zum Ziel, die Anforderungen des Projekts an das zu entwickelnde System zu bestimmen. Das Ergebnis einer Anforderungsanalyse fließt in ein Lastenheft/Pflichtenheft ein, das die Grundlage für das Projekt bilden wird. In diesem Zusammenhang spielen auch das Anforderungsmanagement (englisch Requirements Management, RM) sowie die Business-Analyse (BA) oft eine wichtige Rolle.
Zielkategorien
Unabhängig davon, ob Sie eine Hardware-Modernisierung, ein kleines Softwareupdate oder den Austausch eines kompletten Softwaresystems planen, wird es einfacher für Sie, wenn Sie eine Unterscheidung zwischen Primärziel(en) und möglichen Sekundärzielen vornehmen. Eine solche Unterscheidung setzt einen klaren Fokus auf die wirklich wichtigen Dinge. Abgesehen davon hilft eine solche Unterscheidung auch dabei, Kosten zu minimieren. Oft sind es nämlich gerade die Sekundärziele, die ein Projekt teuer werden lassen. In der Ist-/Soll-Analyse spricht man auch von „Muss“-, „Soll“- und „Kann“-Funktionen. Dabei ist das „Muss“ dem Primärziel zuzuordnen, während das „Soll“ sowie das „Kann“ in die Sekundärziele einzuordnen sind. Hinzu kommt, dass Sie funktionale Anforderungen – also Anforderungen, die sich auf das beziehen, was das System leisten soll – von nichtfunktionalen Anforderungen unterscheiden müssen. Funktionale Anforderungen arbeiten nach dem EVA-Prinzip: Eingabe, Verarbeitung, Ausgabe. Nichtfunktionale Anforderungen beziehen sich darauf, wie das System seine Leistungen erbringen soll. Hierzu zählen Faktoren wie Antwortzeiten von Datenbanken, Qualitätsanforderungen an das Hilfesystem, Hardware-Performanz, Speicherkapazität, Zuverlässigkeit und Ausfallsrisiko.Die Schritte zum Anforderungskatalog
Welche Methoden der Anforderungserhebung (englisch Requirements Elicitation) können eingesetzt werden? Ein probates Mittel ist die Befragung der Mitarbeiter, gegebenenfalls auch Beobachtungen, die Mitarbeiter gemacht haben. Fragebögen, die von Benutzern ausgefüllt worden sind, sind eine weitere Möglichkeit der Erfassung von Anforderungen. Fehlermeldungen können ebenfalls ein guter Ideengeber sein, sofern sie ausreichend qualifiziert sind. Wird das Projekt eher von der planerischen Seite angestoßen, finden sich gute Ansätze im Brainstorming. Bei der Sammlung von Ideen für die Definition der Primär- und Sekundärziele ist es immer sinnvoll, diejenigen Mitarbeiter zu befragen, die täglich damit arbeiten. Diese haben meist die besten Vorschläge und kennen die Schwachstellen im Ist-Zustand.Knifflig wird die Sache, wenn Sie die Vielzahl von Vorschlägen nun bewerten müssen. An dieser Stelle kann es durchaus sinnvoll sein, ein Ideenmanagement einzusetzen. Für die Aufgabenliste des neuen Systems müssen Sie unterscheiden, welche der gemachten Vorschläge in die Kategorien Primärziel beziehungsweise Sekundärziel aufgenommen werden sollen. Einige Vorschläge werden Sie auch aussortieren müssen, weil sie am Thema vorbeigehen, nicht machbar sind oder den Kostenrahmen des Projekts sprengen würden et cetera. Die Anforderungsliste beschreibt also das Was und das Wofür. Im Pflichtenheft hingegen wird definiert, wie und womit die Anforderungen umgesetzt werden sollen.Bei großen Projekten kann sich die Erstellung des Anforderungskatalogs als extrem aufwendig und somit auch als sehr teuer herausstellen. Dazu kommt noch der massive Einsatz an Arbeitszeit. Alleine die Bildung einer Fachabteilung, in der mehrere Personen zusammen an der Ausarbeitung des Anforderungskatalogs arbeiten, macht deutlich, wie umfangreich beziehungsweise kompliziert die Erstellung eines Anforderungskatalogs sein kann.Jeder Projektplaner sollte ausreichend Mittel für die Erstellung des Anforderungskatalogs und des Pflichtenhefts einplanen. Eine konkrete Prozentzahl kann an dieser Stelle natürlich nicht genannt werden, weil jedes Projekt anders ist und seine Eigenarten hat. Bei kleineren bis mittleren Softwareprojekten kann man aber schon einmal die durchschnittlichen Kosten bis zur Fertigstellung des Pflichtenhefts auf ein Drittel der gesamten Projektkosten beziffern. Bei großen, aufwendigen oder komplizierten Projekten kann der Kostenanteil sogar deutlich höher sein. Bis zu diesem Punkt sollten die Ist-Analyse, das Grobkonzept, der Anforderungskatalog und das Pflichtenheft mit enthalten sein. Bei Projekten ab einer gewissen Größe oder dort, wo es aus anderen Gründen sinnvoll erscheint, sollte auch ein Projektplan erstellt werden.Typische Probleme bei der Definition der Anforderungen sind Kommunikationsprobleme zwischen den Parteien. In vielen Firmen hat sich eine Art Fremdsprache entwickelt, wenn es um die Beschreibung von technischen Funktionen, Abläufen oder Tätigkeiten geht. Oft werden dann Begriffe verwendet, die außerhalb dieser Firma etwas anderes bedeuten. In solchen Fällen ist es geradezu zwingend, einen Entwickler aus dem eigenen Haus in die Fachabteilung zu integrieren, damit er als eine Art Übersetzer fungieren kann.Gerade bei IT-Projekten kommt noch hinzu, dass Laien häufig mit Begriffen um sich werfen, die im besten Fall etwas im Kontext Ähnliches beschreiben. Oft werden jedoch Begriffe schlicht und ergreifend falsch eingesetzt. Für den externen Entwickler hingegen ist nicht klar, was der IT-Laie an dieser Stelle mit dieser Funktion will, weil er als externer Entwickler natürlich keine Ahnung hat, was der Auftraggeber eigentlich macht. Es ist also ratsam, bei der Anforderungserhebung sehr genau darauf zu achten, dass interne Fachabteilung und externe Entwickler dasselbe meinen, wenn sie Fachbegriffe verwenden.Jeder Projektleiter, Entwickler oder Softwarearchitekt, der schon einmal in einer Projektbesprechung beim Kunden war, weiß zudem, dass Kunden sich nicht klar darüber sind, was sie wirklich wollen. Man ist sich noch einig in der Frage, dass etwas Neues hermuss, doch was das Neue genau sein soll, sieht jeder ein wenig anders. Verschiedene Stakeholder (Anspruchsträger) können widersprüchliche Anforderungen an das System stellen. Dazu passt die alte Weisheit „Zu viele Köche verderben den Brei“.Ein weiteres häufig auftretendes Problem ist, dass Administratoren oft nicht in den Planungsprozess eingebunden werden. Manchmal aus der Überzeugung heraus, dass sie ohnehin nichts dazu beitragen können, manchmal, weil die Fachabteilung denkt: „Der macht das schon – irgendwie.“ In vielen Fällen ist der Ist-Zustand des Systems nicht auf einem aktuellen Stand und die Planungen starten mit einer fehlerhaften Datenbasis. Bei global agierenden Unternehmen können zusätzlich noch Sprachbarrieren auftreten. Verallgemeinerungen und schwammig formulierte Zielvorgaben, die Platz für Interpretationen lassen, sind ein häufig auftretendes Problem, das oft erst sichtbar wird, wenn der Punkt im Pflichtenheft umgesetzt werden soll.Eine hohe Komplexität der Aufgabe erschwert ebenfalls die Definition der Eigenschaften des zukünftigen Systems. Während des Planungsprozesses können sich die Ziele ändern, wenn zum Beispiel ein neuer Stakeholder hinzukommt. Dies kann dazu führen, dass große Teile des Anforderungskatalogs überarbeitet oder gar vollständig neu geschrieben werden müssen.Auch die Qualität der Anforderungsbeschreibung bietet reichlich Raum für Fehler. Formulierungen, die mehrdeutig, unnötig, widersprüchlich, ungenau oder redundant sind, führen regelmäßig zu Verzögerungen, da die Punkte im Pflichtenheft geprüft und geklärt werden müssen. Das Pflichtenheft nutzt den Anforderungskatalog zwar als Ausgangsbasis, geht aber bei der Lösung der Aufgaben viel stärker in die Details der Umsetzung. Das Pflichtenheft beschreibt im Einzelnen, wie die Anforderung erfüllt wird, und es überprüft die Machbarkeit.Ist man an dem Punkt angekommen, an dem man glaubt, der Anforderungskatalog sei komplett, ist es Zeit, mit der Analyse des Anforderungskatalogs zu beginnen. Die gesammelten Anforderungen werden klassifiziert, bewertet, verglichen und geprüft. Dabei spielen unter anderem auch Kosten-Nutzen-Faktoren eine Rolle. Die Dokumentation dieser Vorgänge sollte einheitlich gestaltet werden. An dieser Stelle muss auch die Vollständigkeit überprüft werden, also der Aspekt, ob alle Anforderungen ausführlich beschrieben worden sind. Es darf keine impliziten Annahmen in der Anforderungsbeschreibung geben.Beim Beschreiben einer Anforderung ist darauf zu achten, dass immer nur eine einzige Anforderung pro Abschnitt behandelt wird. Alle Anforderungen müssen eindeutig über eine Anforderungsnummer zu identifizieren sein. Eine präzise Definition der Anforderung ist der Schlüssel für eine reibungslose Übernahme der Anforderung in den Detailentwurf des Pflichtenhefts.Alle Anforderungen müssen konsistent sein, also untereinander frei von Widersprüchen. Ferner müssen alle Anforderungen daraufhin überprüft werden, ob sie in Abhängigkeit zu anderen Anforderungen stehen. Ebenso ist zu prüfen, ob die jeweilige Anforderung eine Voraussetzung für andere Anforderungen bildet.Um nach der Fertigstellung den Erfolg einer Anforderung nachprüfbar zu machen, sollte jede Anforderung mit Abnahmekriterien verbunden werden, denn das vereinfacht die Abnahme des Systems erheblich. Für jede Anforderung sollte zudem eine Testroutine in einer separaten Anwendung erstellt werden, wenn es sich um ein Softwareprojekt handelt.Um die bisherige Theorie mit etwas Praxis zu untermauern, sehen wir uns einfach zwei Beispiele an: eines aus dem Hardware- und eines aus dem Softwarebereich.Beispielprojekt: Hardware erweitern
Bei einer Anforderungsanalyse, die ein Projekt im Hardware-Umfeld vorbereiten soll, haben Sie es mit sehr konkreten Dingen zu tun. Diese können in Form von Schnittstellen, Werten zur Leistungsaufnahme, Speicherkapazitäten und so weiter auftreten.Stellen Sie sich folgendes fiktive Szenario vor: Sie sollen einen neuen PC anschaffen, der mehr Leistung hat und mit drei virtuellen Maschinen nicht überfordert ist.Diese Anforderung ist so schwammig formuliert, dass man kaum etwas damit anfangen kann. Da Sie von der Vorgabenseite keine genauen Angaben erhalten haben, wählen Sie selbst einige Eckdaten aus, die konkret messbar und vergleichbar sind. Dazu gehören Prozessorleistung (Benchmark-Index) und Anzahl der Kerne, der Arbeitsspeicher und die Leistung der Grafikkarte (Rechenleistung und Auflösung).Im Rahmen Ihrer Ist-Analyse ermitteln Sie nun diese Daten. In Ihrer Aufgabenbeschreibung wurden drei VMs erwähnt. Mit dieser sehr ungenauen Angabe können Sie nicht auf nachvollziehbare Kapazitäten für Arbeitsspeicherbedarf und Festplattenbelegung schließen. Sie müssen nun ermitteln, ob es sich um spezielle VMs handelt, deren Daten näher bestimmt werden können, oder ob es sich um eine allgemeine Angabe handelt. Die Festplattenkapazität spielt bei Ihren Überlegungen keine Rolle, weil alle Daten ohnehin auf dem Server gespeichert werden.Da der Ist-Zustand damit ausreichend bestimmt wurde, können Sie nun mit der Anforderungserhebung beginnen. Um die nichtfunktionale Anforderung zu erfüllen, mit drei virtuellen Maschinen nicht überfordert zu sein, ist ein entsprechender Prozessor notwendig. Bei drei VMs und einem Host-System sollte jedem System mindestens ein Prozessorkern zugewiesen werden können. Da es ein besseres System werden soll, entscheiden Sie sich für einen Mehrkernprozessor mit acht physischen Kernen. Nun vergleichen Sie die Benchmark-Werte und den Preis der CPUs.Nachdem Sie sich nun für ein Modell entschieden haben, erzeugt dieses Produkt eine Abhängigkeit: Nicht jeder Prozessor hat den gleichen Sockel! Bei der Auswahl eines Mainboards sind Sie nun auf Mainboards beschränkt, die diesen Sockel unterstützen. Der benötigte Arbeitsspeicher erzeugt ebenfalls eine Abhängigkeit in Verbindung mit dem Mainboard: Jedes Mainboard hat eine begrenzte Anzahl an Steckplätzen, in die Sie den Arbeitsspeicher einbauen können. Es entstehen jedoch noch mehr Abhängigkeiten, denn die Größe der RAM-Module muss ebenfalls vom Mainboard unterstützt werden. Genauso verhält es sich mit dem RAM-Typ und dessen Geschwindigkeit. Für die Grafikkarte, die zwei 4K-Monitore betreiben soll, muss ebenfalls das richtige Bus-System vom Mainboard bereitgestellt werden.Haben Sie bemerkt, wie Anforderungserhebung und Analyse ineinander übergegangen sind? Um die Analyse abzuschließen, vergleichen Sie nun den Ist-Zustand, den Sie ermittelt haben, mit den Daten des geplanten Systems. Konnten die Eckdaten signifikant verbessert werden, dann kann die Anforderungsanalyse als erfolgreich abgeschlossen gelten. Haben sich die Eckdaten nicht signifikant verbessert, müssen Sie das geplante System neu zusammenstellen, bis der gewünschte Effekt eintritt, oder die Anforderungsanalyse mit dem Ergebnis abschließen, dass die Machbarkeit nicht gegeben ist.Beispielprojekt: Software erweitern
Bei einer Anforderungsanalyse, die ein Projekt im Softwareumfeld vorbereiten soll, wird in der klassischen Softwareentwicklung nach der Anforderungsanalyse ein Pflichtenheft erstellt. In der agilen Softwareentwicklung erstellt man aus der Anforderungsanalyse ein Produkt-Backlog.Stellen Sie sich folgendes Szenario vor, das hier stark vereinfacht beschrieben wird: Ihr Kunde möchte, dass dem Modul „Auftragserfassung“ einer Produktionsplanungssoftware ein Schalter (Checkbox) für Eilbestellungen hinzugefügt wird. Sie beginnen mit der Ist-Analyse und der Anforderungserhebung. Grundlage Ihrer Überlegungen sollten nun die folgenden Fragen sein: Wo beziehungsweise wie werden die Aufträge gespeichert? Soll der Schalter ein rein optisches Merkmal darstellen, oder soll durch das Aktivieren des Schalters auch aktiv in die Produktionsplanung eingegriffen werden? Die Auftragsdaten sind wie üblich in einem DBMS (Datenbankmanagementsystem) gespeichert, und die Produktionsplanung soll vollautomatisiert umgestellt werden, weil die Arbeitsstationen entsprechend kleinteilig organisiert sind. Sie haben nur eine einzige funktionale Anforderung, die es zu erfüllen gilt, nämlich das Produkt schnellstmöglich zu produzieren.Die Frage der Machbarkeit stellt sich hier nicht, weil das System vollautomatisiert und kleinteilig organisiert ist und somit geradezu prädestiniert ist für diese Aufgabe. In der Regel wurde eine solche Funktion bereits als Sekundärziel im Pflichtenheft der Produktionsplanungssoftware definiert. Das Abnahmekriterium kann als die schnellstmögliche Fertigung des Produkts beschrieben werden. Da die Datenbasis vorliegt, kann dem Kunden sogar der Vorschlag für die Erstellung von zwei weiteren Sekundärzielen gemacht werden. Sekundärziele könnten die Anzeige der Fertigungszeit und der Fertigstellungstermin sein.Bei der Planung der Eilbestellung gilt es das Produkt in die Liste der zu produzierenden Artikel aufzunehmen, die benötigten Werkstoffe zum richtigen Zeitpunkt an den Arbeitsstationen bereitzustellen und alle Komponenten bevorzugt in die Produktionskette einzureihen. Hier entstehen Abhängigkeiten in der Reihenfolge des Herstellungsprozesses. Das sollte natürlich so geschehen, dass keine Leerläufe an einzelnen Arbeitsstationen entstehen, die daraus resultieren, dass diese auf die Bereitstellung von Komponenten warten, die noch in einer anderen Produktionskette gefertigt werden.Ein messbarer Erfolg der Anforderungsanalyse ist in der Planungsphase dieses Szenarios kaum zu erbringen, da Sie keine Vergleichsdaten haben. Sobald die Funktion in die Software implementiert wurde, lässt sich jedoch leicht eine Testroutine erstellen, die Vorher-nachher-Werte liefern kann.Bei Individualsoftware hat der Kunde kaum eine andere Wahl, als sein System immer weiter entwickeln zu lassen. Anders bei einer Neuentwicklung: Hier muss natürlich vor der Erstellung eines Pflichtenhefts oder eines Backlogs die Frage „Make it or buy it?“ beantwortet werden.
