Was sind Software-Anforderungen? Eine Einführung.

In meinem letzten Artikel "Anforderungen an IT Projekte formulieren" haben wir damit begonnen einen Blick auf das Thema Requirements Engineering - hier speziell in der IT - zu werfen:

Heute wollen wir mit den Grundbegriffen des Requirements Engineering starten, denn wie in vielen Themenbereichen ist es hilfreich, dass man ein einheitliches Verständnis darüber hat, was die Begriffe bedeuten bevor man sich in unglaubliche Flughöhen begibt. In der Praxis wird durch die Vermischung von diesen Begriffen meist schon der erste Baustein gelegt, um ein Projekt später zum Scheitern zu bringen, in dem z.B. Anforderungen mit der Äußerung von Visionen und Zielen verwechselt werden.

Anforderungen (Requirements)

Nach IEEE (Institute of Electrical and Electronics Engineers) ist eine Softwareanforderung eine Beschreibung dessen, was ein Softwareprodukt tun soll, einschließlich der zu implementierenden Funktionalitäten und der Beschränkungen seines Betriebs. Im Original-Ton ist es ungefähr so definiert (entnommen aus dem guten Artikel von Martin Weck)

1. Eine Bedingung oder Fähigkeit, die ein Nutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.
2. Eine Bedingung oder Fähigkeit, die ein System oder eine Systemkomponente erfüllen oder besitzen muss, um einen Vertrag, Standard, Spezifikation oder ein anderes formales Dokument zu erfüllen.
3. Eine dokumentierte Repräsentation einer Bedingung oder Fähigkeit gemäß 1 oder 2

In diesen Begriffen ist schon einmal eine ganze Menge Stoff, über den man philosophieren könnte. Als besonders wichtig empfinde ich den Hinweis, dass man ein "Ziel erreichen will" oder einen Standard/Spezifikation erfüllen muss.

Wenn wir uns in einem der zukünftigen Artikel über die Ermittlungstechniken für die Erhebung on Anforderungen unterhalten, werden wir sehen, wie schwierig es manchmal ist, herauszufinden was

• eigentlich das Ziel ist und wie man es misst
• wer das Ziel formuliert bzw. dafür berechtigt ist, für die breite Masse dieses zu definieren

Aus der Praxis: Blicke ich auf die Zeit vor ca.10 Jahren zurück, in der ich noch hauptsächlich klassische Workshops am Anfang des Projektes durchgeführt habe (Wasserfall-Methode), muss ich feststellen: Leider änderte sich die Einschätzung, "was man braucht" ständig während der Projekte, denn dies ist ein dynamischer Prozess (--> Agilität). Wie oft haben wir am Anfang des Projektes Anforderungen definiert und aufwändig implementiert, die später kein User tatsächlich verwendet hat. Und anders herum: Wie oft, war ein Thema am Anfang des Projektes ein hartes "Must-have" und am Ende wurde es aus dem Pflichtenheft wegen der Kosten herausgestrichen - und es hat nichts ausgemacht! Die Einschätzung der Stabilität einer Anforderung ist deshalb sehr entscheidend.

Kategorien von Anforderungen

Softwareanforderungen werden üblicherweise in zwei Hauptkategorien unterteilt: funktionale und nicht-funktionale Anforderungen.

• Funktionale Anforderungen beschreiben die spezifischen Verhaltensweisen oder Funktionen des Systems. Sie beziehen sich auf, was das System tun soll, zum Beispiel "Das System soll dem Benutzer ermöglichen, sich mit Benutzername und Passwort einzuloggen".
• Nicht-Funktionale Anforderungen hingegen definieren, wie das System seine Funktionen ausführen soll. Sie betreffen Aspekte wie Leistung, Sicherheit, Zuverlässigkeit und Benutzerfreundlichkeit. Ein Beispiel wäre: "Das System soll innerhalb von 2 Sekunden auf Benutzereingaben reagieren".

In der Praxis muss man feststellen, dass der Fokus sehr stark auf der Analyse und Erfassung der funktionalen Anforderungen liegt, was ein großes Problem darstellt. Denn die Anwender haben immer sehr "praktische Themen" vor Augen und wünschen sich bestimmte Funktionen, ohne auf die Nicht-Funktionalen Anforderungen Rücksicht zu nehmen.

Ich erlebe diesen Effekt häufig, wenn ein Kunde z.B. selbst im Haus eine/n Entwickler/in beschäftigt. Die User fangen dann an, diese Entwickler/-innen zu "umgarnen" (und teilweise zu "bestechen") und bitten diese ständig um die Umsetzung spezieller Anforderungen. Kommt man dann als Berater ein paar Jahre später zu so einem System als Experte dazu, findet man ein vollkommen verbautes Software-Produkt vor, welches nun ganz deutlich eine ganze Reihe von nicht-funktionalen Anforderungen nicht mehr erfüllt, wie z.B. die Wartbarkeit, Update-Fähigkeit oder die Performance-Anforderungen. Nicht selten ist das Software-Produkt mit der Zeit so stark individualisiert worden, dass jede/r AnwenderIn ein auf sich komplett zugeschnittenes Funktionsset hat. Nun, wo es selbst der Geschäftsleitung auffällt, dass es implizite Nicht-Funktionale Anforderungen gibt - die man vorher nicht richtig formulieren konnte - ist es allerdings zu spät! Man findet sich - analog gesehen - in einem völlig verbauten Haus wieder, in dem Handwerker an jedem Tag des Jahres an irgendeiner Ecke etwas über Jahre hinweg dazugebastelt haben. Häufig ist es dann das Beste und Günstigste, man reißt das Haus komplett ab, bevor man versucht, hier noch etwas zu retten und aufwendig zu "sanieren", was am Ende dann trotzdem nicht hält.

The Hidden Champion - Nicht-Funktionale Anforderungen

Die Nicht-Funktionalen-Anforderungen (NFAs) sind meiner Meinung nach die "Hidden Champions", denn diese Anforderungen sind es häufig, welche später

• nachhaltige, nicht-kopierbare Wettbewerbsvorteile ermöglichen
• enorme Kostenauswirkungen besitzen (z.B. bzgl. der Update-Fähigkeit/Kontinuität)
• die Zufriedenheit der Anwendenden maßgeblich beeinflussen
• das komplette Projekt scheitern oder gelingen lassen.

Merkwürdigerweise werden diese NFAs selten in Projekten ausführlich analysiert, dokumentiert und beschrieben. Dies hängt damit zusammen, dass viele dieser Punkte aus Sicht des Kunden "selbstverständlich" und "klar sind". Sofern man eine/n Berater/in hat, welche die Firma und die Branche gut kennt, mag dies auch sein. Aber nicht immer kann man von dieser Situation ausgehen.

Praxistipp für Profis: Ich empfehle hierzu in den Tools wie Microsoft DevOps oder Jira eigene Item-Types anzulegen, welche zur Dokumentation von NFAs genutzt werden. Diese können dann mit Nicht-Funktionalen-Anforderungen verbunden werden. In einem SCRUM-Vorgehen kann man z.B. in der Definition of Ready festlegen, dass die Items gegen alle NFAs geprüft und verbunden werden müssen, bevor sie den Sprint betreten dürfen. Damit ist die ständige Berücksichtigung der NFAs während des Projektverlaufes gewährleistet.

Die Klassifikation dieser NFAs ist in der Literatur umstritten, wie diese exakt gegeneinander abgegrenzt werden, aber glücklicherweise muss ich als Praktiker in einem populär-wissenschaftlichen Artikel wie diesem hier nicht so sehr darauf Rücksicht nehmen (LOL). Ich nenne deshalb hier einfach einmal ein paar der gängigen Begriffe, ohne zu gewährleisten, dass diese lupenrein gegeneinander abgegrenzt werden können:

Qualitätsanforderungen, wie z.B.

• Zuverlässigkeit/Ausfallsicherheit
• Benutzbarkeit
• Änderbarkeit
• Performance
• Wiederverwendbarkeit
• Wartbarkeit/Updatefähigkeit

Randbedingungen, wie z.B.

• Rechtliche Voraussetzungen und Einschränkungen
• Nutzung von Standards (z.B. bei Schnittstellen)
• Organisatorische Rahmenbedingungen
• Anforderungen an die Oberfläche, z.B. Barriere-Freiheit
• Unabhängigkeit von einzelnen Wissensträgern

In diesem Zusammenhang würde ich zusätzlich immer empfehlen, eine Liste mit folgenden speziellen Informationen zu einem Projekt zu führen:

Festlegungen

Definieren, wie das System konfiguriert/genutzt wird. Dies könnten z.B. Aussagen sein:

• Als Kontenrahmen wird der DATEV-Kontenrahmen SKR04 verwendet.
• Als Lagerabgangsmethode der Artikel wird das FIFO-Verfahren festgelegt.

Annahmen/Prämissen

Diese Dokumentieren die Rahmenbedingungen/Annahmen, wie man sie zum Zeitpunkt der Anforderungsaufnahme hatte, z.B.

• Anzahl der Aufträge/Rechnungen pro Tag
• Anzahl der gleichzeitigen User, im Online oder Offline-Betrieb
• Aufbau der Organisation und Einschätzung von Übernahmen, bzw. Erweiterung des Geschäfts/Firmen
• Charakterisierungen der Wichtigkeit z.B. des Auslandsgeschäft gegenüber dem Inlandsgeschäfts.
• Die Datenübernahme erfolgt durch den Kunden selbst.
• Es wird nur B2B-Geschäft mit dem System abgebildet, kein B2C.

Die Herstellung der Visibilität dieser Punkte ermöglicht es dem Kunden/Auftraggeber/Sponsor, diese zu prüfen und ggfs. Änderungen vorzunehmen, falls er/sie dies anders wünscht oder einschätzt.

Delta-Anforderungen

Eine Besondere Schwierigkeit ergibt sich, wenn man Anforderungen gegenüber einem Basis-System definieren muss, wie z.B. einem ERP-System (SAP, Microsoft Dynamics 365 Business Central) oder einem Web-System auf Basis von Typo3 oder Wordpress.

Die Schwierigkeit hierbei ist, dass das Grundsystem schon eine Vielzahl an Anforderungen abdeckt und man praktisch "nur noch" das Delta zum Kundenwunsch festlegen muss. Es macht keine Sinn, hier am Anfang eines Projektes ALLE Anforderungen einzusammeln (was unendlich lang dauern würde bei ERP-Systemen). Gleichzeitig ist es aber nicht so einfach mit der Delta-Analyse, wie es scheint:

• Der Kunde kennt am Start eines Projektes in der Regel nicht die Ausgangsbasis/Standard. Er kann deshalb schwer beurteilen, was er sagen muss und was "selbstverständlich" Bestandteil des Basis-Systems ist.
• Der/die Berater/in kennt das System in der Regel auch nur zu einem bestimmten Teil (man sagt grob, ein ERP-Berater kann zwei fachliche Bereiche, wie z.B. Produktion und Logistik, umfassend in der Tiefe beraten). Die Qualität der Delta-Analyse hängt deshalb extrem stark von der Erfahrung des Consultants ab.
• Das Basis-System entwickelt sich - gerade bei Cloud-Produkten - ständig weiter, d.h. man hat ein "dynamisches Delta". Was gestern noch eine Delta-Anforderung war, löst sich in der nächsten Woche in eine Standard-Funktionalität auf.

Die Firma SOPHIST aus Nürnberg hat zum Thema der Delta-Analyse einige gute Artikel veröffentlicht, weshalb ich hier beispielhaft auf diesen Artikel von Dominik Häußer verweisen möchte, der online auf der Webseite von SOPHIST verfügbar ist. Ich denke, es wäre es wert, das Thema der Delta-Analyse auch einmal in einem eigenen Blog-Artikel zukünftig zu behandeln, da es ein besonders schwieriges Umfeld der Anforderungsaufnahme darstellt, denn die Frage ist, wie beschreibt man die Änderungen verständlich und klar, ohne das Grundsystem jedes Mal noch einmal komplett erklären und darstellen zu müssen.

Ausblick

Nachdem wir heute ein paar der Grundbegriffe zum Thema der Anforderungs-Aufnahme geklärt haben, können wir in den nächsten Ausgaben des Newsletters weiter voranschreiten und schauen uns Themen wie Systemkontext, Stakeholer-Analyse und der Artefakten-Dokumentation gemeinsam an.

Stay tuned and learn on!