Anforderung, Funktion, Messgröße: Warum Ingenieure dasselbe meinen und aneinander vorbeireden

Das Phänomen

Wer in einem Projekt arbeitet, das Anforderungs-Ingenieure, Fehleranalyse-Experten und Software-Entwickler zusammenbringt, erlebt es regelmäßig: Alle sprechen von „Anforderungen“ — und meinen vollständig verschiedene Dinge.

Der Anforderungs-Ingenieur schreibt einen Forderungssatz ins DOORS-System. Der Fehleranalyse-Ingenieur öffnet sein Tool und legt eine „Funktion“ an. Der Scrum-Master erstellt eine Nutzerstory. Alle drei beschreiben dasselbe Systemelement — aus drei verschiedenen Blickwinkeln, in drei verschiedenen Systemen, mit drei verschiedenen Wörtern.

Das Ergebnis ist nicht nur Kommunikationsaufwand. Es entstehen doppelter Pflegeaufwand, widersprüchliche Unterlagen und — im schlimmsten Fall — kritische Messgrößen ohne Fehleranalyse, weil jede Disziplin annahm, die andere hätte das abgedeckt.

Drei Formen der Sprachverwirrung

Die Verwirrung im Engineering hat drei Formen:

• Gleiches Wort, verschiedene Bedeutung: „Anforderung“ ist im Anforderungs-Tool ein normierter Forderungssatz. Im Fehleranalyse-Tool derselbe Begriff: ein Freitextfeld ohne klare Methodik.
• Verschiedene Wörter, gleiche Bedeutung: Was Anforderungs-Ingenieure „nicht-funktionale Anforderung“ nennen, heißt in Fehleranalyse-Tools „Merkmal“, in Architektur-Tools „Messwert-Eigenschaft“. Alles dasselbe: eine messbare Größe mit Einheit und Grenzwert.
• Falsche Gleichsetzung: „Funktion = Anforderung“ — die häufigste Verwechslung. Eine Funktion beschreibt, was ein Element tut (Beschreibung). Eine Anforderung beschreibt, was es tun soll (Forderung). Werden beide vermischt, entsteht eine Fehleranalyse ohne Maßstab.

Die gemeinsame Begriffskarte: Sechs Ebenen, vier Sprachwelten

Die folgende Begriffskarte zeigt, wie Anforderungs-Tools, Fehleranalyse-Tools, Architektur-Tools und Aufgaben-Tools dieselben sechs Konzeptebenen benennen — und wo die drei unvermeidbaren Sprachbrüche liegen.

Die sechs Ebenen — und was jedes Werkzeug dazu sagt

Die gemeinsame Begriffskarte von OTSM ordnet alle Konzepte in sechs Ebenen:

• Ebene 1 — Systemelement: Was Anforderungs-Tools „System“ nennen, heißt in Fehleranalyse-Tools „Aufbaubaum-Knoten“, in Architektur-Tools „Baustein“. Alle meinen die Systemgrenze.
• Ebene 2 — Themenblock (Fähigkeit): Anforderungs-Tools sprechen von „Fähigkeit“, Aufgaben-Tools von „Großaufgabe“. Fehleranalyse-Tools haben kein Äquivalent — erster Sprachbruch.
• Ebene 3 — Nutzerwunsch: Anforderungs-Tools kennen „Anwenderanforderungen“, Architektur-Tools „Anwendungsfälle“, Aufgaben-Tools „Nutzerstorys“. Fehleranalyse-Tools haben keine Anwenderperspektive.
• Ebene 4 — Leistungsbeschreibung (★ Kern der Verwirrung): Was Anforderungs-Tools „funktionale Anforderung“ und Fehleranalyse-Tools „Funktion“ nennen, ist dasselbe. Die Unterscheidung Beschreibung/Forderung ist ein Blickwinkel, kein eigener Begriff. OTSM fasst beides unter „Leistungsbeschreibung“ zusammen.
• Ebene 5 — Messgröße: Immer mit Einheit und Grenzwert. Das Gegenstück in Anforderungs-Tools ist die „nicht-funktionale Anforderung“, in Fehleranalyse-Tools „Merkmal“, in Architektur-Tools „Messwert-Eigenschaft“. Aufgaben-Tools: zweiter Sprachbruch — kein Gegenstück.
• Ebene 6 — Fehlerbeschreibung: Die Umkehrung einer Leistungsbeschreibung. Nur Fehleranalyse-Tools kennen diesen Begriff. Anforderungs-Tools, Architektur-Tools und Aufgaben-Tools haben kein Gegenstück — dritter Sprachbruch.

Randbedingung — kein eigener Begriff nötig

Eine Randbedingung ist keine eigene Kategorie. Jede Randbedingung ist eine Leistungsbeschreibung mit einem Zusatz: kein Spielraum, keine Ausnahme. „Das System MUSS X — ohne Wenn und Aber.“ In OTSM wird sie als Leistungsbeschreibung mit dem Kennzeichen „unveränderlich“ erfasst — kein eigener Begriff, keine zusätzliche Verwirrung.

Anforderungs-Tools haben oft einen eigenen Typ „Constraint“. Das ist fachlich nicht notwendig und vergrößert die Verwirrung eher als sie zu lösen.

Die drei Sprachbrüche — und was daraus folgt

Drei Lücken lassen sich nicht wegdefinieren. Sie müssen bewusst überbrückt werden:

• Sprachbruch 1: Fehleranalyse-Tools kennen keine Anwenderperspektive. Der Übergang von Nutzerwünschen zur Fehleranalyse muss von Hand hergestellt werden.
• Sprachbruch 2: Aufgaben-Tools haben keine Messgrößen mit Grenzwert. Abnahmekriterien sind keine Merkmale. Wer hier nicht aktiv überbrückt, hat eine Qualitätslücke.
• Sprachbruch 3: Nur Fehleranalyse-Tools kennen Fehlerbeschreibungen. Anforderungs- und Architektur-Tools haben hier eine strukturelle Lücke — die in der Praxis oft nicht geschlossen wird.

Die Lösung: eine gemeinsame Begriffskarte

OTSM beantwortet das Problem nicht mit einem weiteren Werkzeug, sondern mit einer gemeinsamen Begriffskarte. Dieselbe Entität — eine Leistungsbeschreibung, eine Messgröße, eine Fehlerbeschreibung — wird einmal erfasst und in jedem Werkzeug unter seinem jeweiligen Wort sichtbar.

• Der Anforderungs-Ingenieur sieht seinen Forderungssatz.
• Der Fehleranalyse-Ingenieur sieht dieselbe Entität als „Funktion“ mit abgeleiteter Fehlerart.
• Der Scrum-Master sieht sie als Abnahmekriterium.

Kein doppelter Pflegeaufwand. Keine Widersprüche. Keine übersehenen Messgrößen.

Das ist kein technisches Versprechen, sondern ein methodisches Fundament: Wer die Sprache klärt, muss die Daten nicht zweimal pflegen.

Methodische Grundlagen

Die Begriffskarte basiert auf anerkannten Normen und Methoden:

• Leistungsbeschreibung / Funktionale Anforderung (ISO/IEC/IEEE 29148): Normative Aussage über ein gefordertes Verhalten. Forderungssatz mit SOLL oder MUSS. Muss überprüfbar sein.
• Funktion (AIAG-VDA FMEA-Handbuch 2019, Abschnitt 3): Beschreibung der beabsichtigten Leistung eines Systemelements. Tätigkeitswort mit Gegenstand. Ausgangspunkt der Fehleranalyse.
• Messgröße / Merkmal (AIAG-VDA 2019, Abschnitt 3): Messbare Produkt- oder Verfahrenseigenschaft mit Einheit und Grenzwert. Grundlage für Prüfplanung und Fähigkeitsberechnung.
• Randbedingung (INCOSE Handbuch, 5. Ausgabe): Bedingung ohne Spielraum. Kann als Leistungsbeschreibung mit dem Kennzeichen „unveränderlich“ formuliert werden.

OTSM-Kernaussage: Die methodische Trennung zwischen „Funktion“ (beschreibend, Fehleranalyse-Welt) und „Funktionale Anforderung“ (fordernd, Anforderungs-Welt) beschreibt keine verschiedenen Entitäten, sondern zwei Darstellungsweisen derselben Information. OTSM fasst beide unter dem Begriff „Leistungsbeschreibung“ zusammen.

Fazit: Einmal erfassen, überall sehen

Für Vorhaben mit mehreren Fachrichtungen gilt: Eine gemeinsame Begriffskarte mit sechs Ebenen ermöglicht es, alle vier Werkzeugwelten auf eine einheitliche Datenstruktur abzubilden. Die Sprachbrüche werden nicht beseitigt — aber sie werden sichtbar, benannt und gezielt überbrückt.

Das OTSM-Prinzip „einmal erfassen, überall sehen“ gilt auch für Begriffe: Eine Entität, viele Sichten. Kein Datenverlust beim Übersetzen.

OTSM GmbH · Thomas Arends · 2026 · CC BY 4.0