Bei Anforderungen an ein Softwaresystem wird häufig zwischen funktionalen Anforderungen und Qualitätsanforderungen unterschieden.

Funktionale Anforderungen beschreiben, was ein System leisten muss. Sie lassen sich beispielsweise durch Anwendungsfälle (Use Cases), User Stories oder Diagramme mit UML und BPMN darstellen. Solche Darstellungen helfen dabei, unterschiedliche Vorstellungen sichtbar zu machen und Missverständnisse zu vermeiden.

Qualitätsanforderungen beschreiben, welche Eigenschaften ein System besitzen muss und wie gut es diese erfüllen soll. Beispielsweise: Wie zuverlässig, sicher, performant, wartbar oder bedienbar muss es sein?

Eine Orientierung dafür bietet das internationale Qualitätsmodell ISO/IEC 25010:2023. Es hilft dabei, wichtige Qualitätseigenschaften systematisch zu betrachten und zu bewerten.

Unklare Anforderungen führen zu Missverständnissen und Fehlentwicklungen. Das kostet Zeit, Geld und Nerven. Im schlimmsten Fall entstehen Systeme, die nicht den tatsächlichen Bedürfnissen entsprechen, oder Projekte scheitern sogar.

Manchmal fehlen wichtige Anforderungen, sind veraltet, widersprechen einander oder sind über zahlreiche Jira-Tickets und Confluence-Seiten verteilt. Mitunter wissen nur noch einzelne Mitarbeiter, warum bestimmte Funktionen überhaupt existieren.

Gute Anforderungen sollten deshalb:

• verständlich sein, damit alle Beteiligten sie verstehen können,
• eindeutig sein, damit unterschiedliche Interpretationen möglichst ausgeschlossen werden,
• notwendig sein, damit keine überflüssigen Funktionen entwickelt werden,
• vollständig sein, damit keine wesentlichen Informationen fehlen,
• überprüfbar sein, damit sich feststellen lässt, ob sie erfüllt wurden,
• angemessen sein, damit sie die tatsächlichen Bedürfnisse des Unternehmens widerspiegeln.

Gute Anforderungen schaffen eine gemeinsame Vorstellung davon, was entwickelt werden soll und warum.

Dadurch können:

• Fehlentwicklungen vermieden werden, weil Missverständnisse frühzeitig erkannt werden.
• Kosten gesenkt werden, weil unnötige Funktionen und aufwendige Nacharbeiten entfallen.
• Projekte besser geplant werden, weil Umfang und Prioritäten klarer sind.
• Ergebnisse zuverlässiger überprüft werden, weil nachvollziehbare Kriterien für die Abnahme vorliegen.
• Änderungen leichter umgesetzt werden, weil verständlich dokumentiert ist, welche Funktionen welchen Zweck erfüllen.

Das reduziert Risiken und hilft Unternehmen, ihre Entwicklungsbudgets gezielter einzusetzen.

Zunächst muss geklärt werden, welche Anforderungen bereits bekannt und dokumentiert sind und welche Probleme damit bestehen.

Fehlende oder unklare Anforderungen können beispielsweise durch Gespräche mit Anwendern, Entwicklern und anderen Beteiligten ermittelt und präzisiert werden.

Bei bestehenden Systemen lohnt sich zusätzlich ein Blick auf die Software selbst. Denn manchmal verrät erst der Programmcode, welche fachlichen Regeln tatsächlich implementiert wurden.

Anschließend können Anforderungen auf Widersprüche, Lücken und unnötige Komplexität untersucht, verständlich dokumentiert und nach ihrem Nutzen priorisiert werden.

Das Ziel ist nicht, möglichst viele Anforderungen möglichst ausführlich zu dokumentieren, sondern ein gemeinsames und verlässliches Verständnis davon zu schaffen, was wirklich benötigt wird.

Bei historisch gewachsenen Systemen fehlen häufig die ursprünglichen Anforderungen oder sie sind längst veraltet. Doch wie lassen sie sich wiedergewinnen?

Zwei besonders wichtige Informationsquellen sind das bestehende System selbst und die Benutzer, die täglich damit arbeiten.

Das bestehende System liefert wertvolle Hinweise darauf, welche Anforderungen ursprünglich umgesetzt wurden.

Zunächst lohnt es sich, die Softwarearchitektur zu betrachten, um einen Überblick über das System zu gewinnen. Anschließend können die Ein- und Ausgaben, die Verarbeitung und Speicherung von Daten sowie die Schnittstellen zu anderen Systemen untersucht werden. Für konkrete Fragestellungen kann schließlich der Quellcode analysiert werden.

Allerdings zeigt das System zunächst nur, was es tatsächlich tut – nicht unbedingt, was es tun soll. Denn auch Fehler, überholte Geschäftsregeln und unerwünschte Verhaltensweisen können über Jahre hinweg bestehen bleiben.

Die Benutzer des Systems sind deshalb eine weitere wichtige Informationsquelle.

In Interviews können sie erklären, wie sie das System verwenden und welche Aufgaben sie damit erledigen. Besonders aufschlussreich kann es sein, ihnen bei ihrer täglichen Arbeit zuzusehen und gezielt nachzufragen, was sie gerade tun und warum – selbstverständlich mit ihrer Zustimmung.

Auch Fachexperten können helfen, fachliche Regeln, Zusammenhänge und Hintergründe zu verstehen.

Weitere Hinweise können sich aus alten Dokumentationen, Tickets, Tests und Prozessbeschreibungen ergeben.

Durch den Abgleich dieser Informationsquellen lassen sich verlorene Anforderungen schrittweise rekonstruieren und überprüfen, welche davon heute noch benötigt werden.

Anforderungen ändern sich mit der Zeit, genau wie der Code eines Systems. Während Anforderungen beschreiben, was ein System tun soll, zeigt der Code, was es tatsächlich tut. Dieser Unterschied klingt banal, ist aber entscheidend für die langfristige Wartbarkeit eines Systems.

Manche Anforderungen werden überflüssig. Beispielsweise weil Geschäftsprozesse entfallen oder Funktionen nicht mehr benötigt werden. Dann kann geprüft werden, ob sich auch der entsprechende Code entfernen lässt. Das verringert die Komplexität und erleichtert die weitere Wartung.

Neue Anforderungen kommen hinzu. Sie können Erweiterungen des bestehenden Systems notwendig machen, beispielsweise neue Funktionen, zusätzliche Schnittstellen oder die Integration neuer Technologien.

Andere Anforderungen verändern sich. Bestehende Funktionen müssen angepasst oder in manchen Fällen vollständig ersetzt werden.

Entscheidend ist, dass die dokumentierten Anforderungen mit diesen Veränderungen Schritt halten.

Andernfalls entsteht mit der Zeit eine immer größere Lücke zwischen dem, was das System laut Dokumentation tun soll, und dem, was es tatsächlich tut.

Wer Anforderungen kontinuierlich pflegt, sorgt dafür, dass auch zukünftige Änderungen auf einer verlässlichen Grundlage geplant, umgesetzt und überprüft werden können.

Klare Anforderungen allein reichen nicht aus, um ein erfolgreiches Softwaresystem zu entwickeln und weiterzuentwickeln. Ebenso wichtig sind eine gute Softwarearchitektur und geeignete Tests.

Eine gute Softwarearchitektur strukturiert ein System in Teile mit klaren Aufgaben und bewusst gestalteten Abhängigkeiten, die zusammenarbeiten, um die Anforderungen an das System zu erfüllen.

Tests helfen dabei, zu überprüfen, ob das System die Anforderungen erfüllt und ob Änderungen unerwünschte Nebenwirkungen verursachen. Je früher Fehler erkannt werden, desto geringer ist häufig der Aufwand, sie zu beheben.

Anforderungen, Softwarearchitektur und Tests ergänzen sich damit gegenseitig und tragen gemeinsam zur Qualität und langfristigen Änderbarkeit eines Systems bei.

Mehr darüber erfahren Sie in meinen Artikeln:

• Welche Softwarearchitektur darf es denn bitte sein?
  
• Wetten, dass … das System funktioniert? (Über das Testen)
• Großes KIno: was KI kann und was Unternehmen davon haben