Anforderungen erheben: funktional vs. nicht-funktional

Bevor irgendeine Zeile Code geschrieben wird, muss klar sein, was die Software überhaupt leisten soll. Genau diesem Schritt widmet sich dieser Kurs zur Softwarearchitektur – beginnend mit dem Fundament: dem Erheben von Anforderungen. Studien zeigen, dass mehr als 50 % aller fehlgeschlagenen Software-Projekte auf unzureichend erfasste oder missverstandene Anforderungen zurückzuführen sind. Anforderungs-Analyse ist also kein bürokratisches Übel, sondern eine der wichtigsten Disziplinen der Software-Entwicklung.

In dieser Lektion lernst du die zwei großen Klassen von Anforderungen kennen: funktionale und nicht-funktionale. Du lernst, wie man sie aus Gesprächen mit Stakeholdern extrahiert, wie man sie sauber formuliert und welche Techniken zur Anforderungs-Erhebung in der Praxis und in IHK-Prüfungen erwartet werden.

1) Was sind Anforderungen überhaupt?

Eine Anforderung (engl. Requirement) ist eine Aussage über eine Eigenschaft oder Fähigkeit, die die zu entwickelnde Software besitzen muss. Anforderungen kommen von verschiedenen Quellen: vom Auftraggeber, von Endnutzer*innen, vom Fachbereich, manchmal auch aus Gesetzen, Normen oder technischen Zwängen.

Anforderungen beantworten die Frage: Was muss das System können? Sie sagen nichts darüber aus, wie es das tut – das ist Sache der späteren Entwurfsphase (siehe L6 Schichtenarchitektur und Folgelektionen). Die Trennung zwischen „Was" und „Wie" ist eine der wichtigsten Disziplinen der Anforderungs-Analyse.

2) Vom Wunsch zur formalen Anforderung

Anforderungen entstehen selten als fertige, präzise Sätze. Sie kommen als vage Wünsche in Gesprächen mit Stakeholdern auf und müssen erst zu verwertbaren Anforderungen verdichtet werden. Diese Filterung von ungenauen Ideen zu formalen Spezifikationen ist das Herzstück des Requirements Engineering:

3) Funktional vs. nicht-funktional – die wichtigste Unterscheidung

Die zentrale Klassifizierung in der Anforderungsanalyse: funktionale Anforderungen beschreiben was das System tun muss (Funktionen, Features, Verhalten). Nicht-funktionale Anforderungen beschreiben wie gut es das tun muss (Qualitätseigenschaften). Diese Unterscheidung wird in IHK-Klausuren regelmäßig abgefragt:

4) Die Kategorien nicht-funktionaler Anforderungen (FURPS+)

Nicht-funktionale Anforderungen sind eine bunte Sammlung sehr unterschiedlicher Eigenschaften. Um Ordnung reinzubringen, gibt es Schemata wie FURPS+ (entwickelt bei Hewlett-Packard) oder die ISO/IEC 25010. FURPS+ ist gut zu merken und in der IHK-Prüfung beliebt:

5) Anforderungen klassifizieren – Übung

Jetzt teste dich selbst: bei den folgenden Aussagen, was ist das jeweils – funktional oder nicht-funktional? Klick auf einen Button:

6) User Stories – das Standard-Format

Funktionale Anforderungen werden in der Praxis oft als User Stories formuliert, ein Format aus der agilen Software-Entwicklung. Das Schema ist einfach, aber wirkungsvoll: jede Anforderung wird aus der Perspektive einer konkreten Nutzergruppe formuliert, mit einer klar benennbaren Aktion und einem nachvollziehbaren Nutzen.

Eine gute User Story erfüllt die INVEST-Kriterien: Independent (unabhängig), Negotiable (verhandelbar), Valuable (wertvoll), Estimable (schätzbar), Small (klein genug), Testable (testbar). Wer eine Story formuliert, die diese sechs Kriterien erfüllt, hat schon viel richtig gemacht.

7) Erhebungstechniken

Wie kommt man überhaupt an Anforderungen? Stakeholder können sie oft nicht von alleine präzise formulieren – sie brauchen die richtige Methode. Hier die gängigsten Erhebungstechniken aus dem Requirements Engineering:

8) Der Anforderungs-Prozess

Anforderungs-Erhebung ist kein einmaliger Akt, sondern ein Prozess mit mehreren Phasen. In den meisten Vorgehensmodellen sieht der Ablauf so aus – auch wenn die Bezeichnungen variieren:

9) Lastenheft und Pflichtenheft

In der deutschen Praxis (und IHK-Prüfung!) sind zwei Dokumenttypen zentral: das Lastenheft und das Pflichtenheft. Die beiden werden oft verwechselt, aber die Unterscheidung ist klar – und Prüfungsstoff:

• Lastenheft: vom Auftraggeber erstellt. Beschreibt, was die Software können soll und welche Anforderungen erfüllt werden müssen. Es beantwortet die Frage: „Was will ich haben?"
• Pflichtenheft: vom Auftragnehmer als Antwort erstellt. Beschreibt, wie die Anforderungen des Lastenhefts umgesetzt werden sollen. Es beantwortet die Frage: „Wie werde ich es umsetzen?"

Eine bewährte Eselsbrücke: das Lastenheft beschreibt die Last (das Problem), das Pflichtenheft die Pflicht (die Verantwortung zur Lösung). Beide Dokumente sind Vertragsbestandteile und damit rechtlich relevant. In der Klausur: das Pflichtenheft setzt das Lastenheft voraus – ohne Lastenheft kein Pflichtenheft.

10) Qualitätskriterien für Anforderungen

Wie erkennt man eine gute Anforderung? In der Literatur gibt es verschiedene Kriterienkataloge. Die wichtigsten Eigenschaften, die auch in der IHK-Prüfung als Stichworte auftauchen:

• Eindeutig: nur eine Interpretation möglich. Keine Wörter wie „benutzerfreundlich" oder „schnell" ohne Konkretisierung.
• Vollständig: alle relevanten Aspekte sind erfasst, keine offenen Lücken.
• Konsistent: keine Widersprüche zu anderen Anforderungen.
• Testbar / Verifizierbar: es muss objektiv überprüfbar sein, ob die Anforderung erfüllt ist. „Antwortzeit < 200 ms im 95. Perzentil" ist testbar, „soll schnell sein" nicht.
• Realistisch: mit den verfügbaren Mitteln und in der gegebenen Zeit umsetzbar.
• Priorisiert: die Wichtigkeit ist klar (Must-have / Should-have / Could-have / Won't-have → MoSCoW-Methode).
• Verfolgbar (Traceability): jede Anforderung ist eindeutig identifizierbar (Nummer, ID) und ihr Ursprung dokumentiert.

Wer eine Anforderung formuliert, kann sich diese Liste durchgehen und prüfen, ob sie hält. Wenn nicht: nachschärfen. Diese Disziplin spart später unzählige Stunden Diskussion und Bug-Fixing.

11) Typische Fehler bei der Anforderungs-Erhebung

Aus der Praxis: diese Fehler tauchen in fast jedem Projekt mindestens einmal auf – und sind in IHK-Klausuren beliebte Fragen:

• Lösungen statt Probleme erfassen: der Kunde sagt „ich brauche einen Excel-Export". Was er eigentlich braucht, ist eine Möglichkeit, Daten extern auszuwerten. Vielleicht reicht eine API. Wer nur Lösungen aufschreibt, verbaut sich bessere Optionen.
• Stakeholder vergessen: das Marketing wird vergessen, die IT-Sicherheit nicht eingebunden, der Datenschutzbeauftragte erfährt erst kurz vor Go-Live. Ergebnis: nachträgliche teure Änderungen.
• Nicht-funktionale Anforderungen unterschätzen: Funktionen sind sichtbar, NFRs unsichtbar. Wer sie ignoriert, bekommt am Ende eine Software, die zwar funktioniert, aber zu langsam, unsicher oder unbedienbar ist.
• Vague Begriffe akzeptieren: „benutzerfreundlich", „modern", „performant", „sicher" – alles ohne Konkretisierung ist eine tickende Bombe. Im Streitfall hat jede Seite eine andere Vorstellung.
• Keine Versionierung der Anforderungen: „Stand der Anforderungen vom 14. April" vs. „aktuelle Version" – wer nicht versioniert, weiß irgendwann nicht mehr, was Vertragsbestandteil ist.
• „Gold Plating": der Entwickler baut Features ein, die niemand gefordert hat, weil er sie „cool" findet. Verschwendung von Zeit, oft unwartbar.

12) Anforderungen als Grundlage für alles Weitere

Anforderungen sind das Fundament des gesamten Software-Projekts. Die Folgelektionen dieses Kurses bauen direkt darauf auf:

• Modellierung: aus funktionalen Anforderungen werden Use-Case-Diagramme (L2), Aktivitätsdiagramme (L3), Sequenzdiagramme (L4).
• Architektur: aus nicht-funktionalen Anforderungen ergeben sich Architekturentscheidungen – Skalierbarkeit führt zu Microservices (L7), Klarheit zu Schichtenarchitektur (L6).
• Schnittstellen: Anforderungen an Datenaustausch münden in REST-APIs (L8) und Datenformaten (L9).
• Tests: testbare Anforderungen sind die Vorlage für Testfälle – zentraler Aspekt des Qualitätsmanagements.

Zusammenfassung

Anforderungs-Erhebung ist die wichtigste Phase eines Software-Projekts – unzureichend erhobene Anforderungen sind die häufigste Ursache für Projekt-Misserfolge. Zwei zentrale Klassen: funktionale Anforderungen (was das System tun muss – Features, Funktionen) und nicht-funktionale Anforderungen (wie gut, unter welchen Bedingungen – Qualitätseigenschaften wie Performance, Sicherheit, Benutzbarkeit). Klassifikationsschema FURPS+: Functionality, Usability, Reliability, Performance, Supportability + Constraints. Funktionale Anforderungen werden oft als User Stories formuliert („Als X möchte ich Y, damit Z"), die INVEST-Kriterien sollten erfüllt sein. Erhebungstechniken: Interviews, Workshops, Beobachtung, Fragebögen, Prototypen, Dokumenten-Analyse. Der Prozess hat vier Phasen: Ermitteln, Dokumentieren, Prüfen, Verwalten. Wichtige Dokumenttypen in Deutschland: Lastenheft (vom Auftraggeber, „was will ich haben?") und Pflichtenheft (vom Auftragnehmer, „wie setze ich es um?"). Gute Anforderungen sind eindeutig, vollständig, konsistent, testbar, realistisch, priorisiert (MoSCoW) und verfolgbar. Typische Fehler: Lösungen statt Probleme, vergessene Stakeholder, unterschätzte NFRs, vage Begriffe, fehlende Versionierung, Gold Plating. Anforderungen sind die Basis aller weiteren Lektionen: UML-Diagramme, Architekturentscheidungen, Schnittstellen. Nächste Lektion: Use-Case-Diagramme als erste UML-Modellierung der funktionalen Anforderungen.