Die Elementgrenze als Anker des Requirements Engineering — Vollständigkeit gegen ein endliches Raster

#

Status: DRAFT v0.3 · 19.10.2026 (v0.2: Fremdsystem, §6.5 HARA, §6.6 Fehlanwendung, E1 entschieden · v0.3: Teil A neu für Entscheider, §6.7 Kapitelhierarchie, §6.8 Aspekte, Schnittstellen als Rendersicht, §12 aktualisiert) · Methodenpapier (SSoT nach Standing Order 21.3) Autor: Thomas Arends, OTSM GmbH Bezug: claude/methodenbeschreibung-publizierbar-v3.md (Bezugssystem) · claude/KONSOLIDIERT_consumes-delivers-grenzdeklaration.md (Delta 25.08.2026) · claude/KONSOLIDIERT_interface-contract.md · claude/PLAN_2026-10-01_kontext-aspekte-querschnitt.md (CR-2026-246 W2/W2b) Quell-Thread: Grundsatzdiskussion 19.10.2026 Umsetzung: nicht Teil dieses Papiers. UI-Konzept: claude/MOCKUP_2026-10-19_grenz-editor.html (klickbar). Umsetzungsplan und CR folgen als eigener Cycle.

Teil A — Executive Summary (für Entscheider)

#

Worum es geht

#

Lastenhefte beschreiben, was „das System" tun muss. Sie beschreiben fast nie, an welcher Stelle des Systems das geschieht, was dafür von außen hereinkommen muss und wer auf der anderen Seite steht. Die Folge sieht jede Entwicklungsabteilung regelmäßig: Die FMEA findet Schnittstellen, die im Lastenheft fehlen. Das Handbuch beschreibt Bedienfälle, die kein Requirement kennt. Der Transport, die Reinigung, der Werkstattbesuch tauchen erst auf, wenn etwas kaputtgeht. Nicht, weil die Ingenieure schlecht arbeiten, sondern weil keine Methode verlangt, Vollständigkeit an jedem Bauteil nachzuweisen.

Die Änderung in einem Satz

#

Jedes Bauteil deklariert seine Grenze selbst: was es aufnimmt, was es zusagt, von wem, an wen, in welcher Lebensphase, in welchem Zustand — und wo nichts deklariert ist, zählt das System eine Lücke.

Was sich konkret ändert

#

Vier Dinge, alle aus bekannten Methoden zusammengesetzt (4M aus der FMEA, Lebensphasen aus ISO 15288, Verträge aus dem Contract-Based Design, Störgrößen aus Taguchis P-Diagramm):

1. Die Gegenseite wird benannt. Mensch, Fremdsystem (Netz, Lieferantenteil, Buspartner), Umwelt, Material. Für jede Klasse, jede Lebensphase, jeden Zustand ist eine Grenze entweder deklariert, begründet nicht zutreffend oder eine Lücke. Leer ist nie stilles Einverständnis.
2. Der Anforderungssatz wird gerendert, nicht geschrieben. Aus derselben Deklaration entstehen Anforderung, FMEA-Zeile, Gefährdungsanalyse, Handbuchschritt und Testfall. Nichts davon wird ein zweites Mal gepflegt.
3. Use Cases und vorhersehbare Fehlanwendung werden erzeugt. Der Bediener ist eine Gegenseite mit Handlungen; die Handlung ist der Use Case, ihre Negation die Fehlanwendung. Beides fällt aus dem Raster, statt in Workshops gesammelt zu werden.
4. Die Bilanz findet, was keiner deklariert hat. Energie und Stoff, die hineingehen, müssen hinaus. Der Rest (Wärme, Vibration, Lärm) ist ein undeklarierter Abgang und wird sichtbar, ohne dass jemand daran gedacht hat.

Was es bringt

#

• Vollständigkeit wird zählbar je Bauteil, nicht geschätzt je Review.
• Die Bewertungsendpunkte der FMEA sind berechnet, nicht per Hand gesetzt; die Bewertung läuft dort, wo das System tatsächlich nach außen wirkt.
• Handbuch, Testspezifikation, Schnittstellenspezifikation und HARA sind Sichten auf dieselben Daten. Eine Änderung ist überall gleichzeitig da.
• Lücken nach einem Lastenheft-Import sind die Fragen an den Kunden, bevor der erste Entwurf steht.

Was es kostet

#

Eine Umstellung der Denkweise: Anforderungen werden an Bauteilen deklariert, nicht über „das System" geschrieben. Das ist der bekannte Blocker beim Schritt vom Merkmal zur Funktion, und er wird nicht kleiner. Technisch: ein Vokabular für Gegenseiten, Lebensphasen und Flussgrößen, das einmal gepflegt wird, und Standardvorlagen je Komponententyp, damit niemand Wärme und EMV an jedem Bauteil von Hand deklariert.

Was passiert, wenn man es nicht tut

#

Die Vollständigkeit bleibt dort, wo sie heute ist: in der FMEA, im Feld und in der Reklamation. Jede dieser drei Stellen ist teurer als die Deklaration am Bauteil.

Nächste Schritte

#

Drei Methodenentscheidungen (Teil B §10), davon eine gefallen. UI-Konzept liegt als klickbares Mockup vor. Danach Umsetzungsplan als eigener Cycle.

Teil B — Langfassung

#

1. Ausgangslage

#

1.1 Was heute passiert

#

Ein Lastenheft enthält Sätze der Form „Das Gerät muss den Betriebszustand anzeigen." Das Subjekt ist „das Gerät". Realisiert wird der Satz am Bedienpanel, hörbar vielleicht am Summer. Die Anforderung steht oben, die Lösung steht unten, und zwischen beiden gibt es keine Deklaration, an welcher Grenze die Zusage tatsächlich gegeben wird.

Was von außen hereinkommt — Netzspannung, Umgebungstemperatur, ein Bediener mit bestimmter Qualifikation, ein Topf auf dem Kochfeld — steht entweder in einem Kapitel „Randbedingungen" ohne Bezug zu einzelnen Elementen, oder gar nicht. Die generischen Merkmale, die ein Element einhalten muss (Schutzart, EMV, Temperaturbereich), stehen in Normkapiteln und werden pauschal „für das Projekt" gültig erklärt.

Die Konsequenz ist bekannt und in jeder Organisation sichtbar: Die Vollständigkeit wird später rekonstruiert. Die FMEA fragt nach den 4M, weil sie die Gegenseite jeder Grenze braucht und das RE sie nie deklariert hat. Das P-Diagramm listet Störgrößen, die im Lastenheft fehlen. Das Handbuch beschreibt Use Cases, die kein Requirement kennt. Das ICD definiert Signale, deren Annahmen nirgends stehen.

1.2 Der Logikfehler

#

Das Requirement beschreibt die Kante in der dritten Person — einer schreibt beide Enden auf, und keiner deklariert die eigene Grenze. Damit sind zwei Dinge prinzipiell nicht berechenbar:

• Verträglichkeit: Ob das, was die Senke annimmt, in dem liegt, was die Quelle zusagt (Assume ⊆ Guarantee).
• Vollständigkeit: Ob an einer Elementgrenze alle Flüsse eine Funktion haben.

Beides landet im Review und in der FMEA, also beim Menschen, nach der Spezifikation.

1.3 Was dieses Papier leistet und was nicht

#

Es ordnet Bekanntes neu. Jedes Fragment existiert: Contract-Based Design hängt Assume und Guarantee an die Komponente; Taguchi listet fünf Störgrößenklassen; Ishikawa liefert die 4M; ISO 15288 die Lebensphasen; HAZOP die Abweichungsleitworte; Leveson die UCA-Typen. Keines davon ist ein Requirements-Schema, keines prüft gegen das andere, keines ist verbindlich an jedem Element. Dieses Papier macht aus den Fragmenten eine Deklaration je Element gegen ein endliches Raster und leitet die übrigen Artefakte daraus ab.

Es behauptet nicht, Vollständigkeit „gegen die Welt" zu beweisen. Es behauptet, die Lücke zwischen den bekannten Fragmenten zählbar zu machen.

2. Begriffe

#

3. Die Grenzdeklaration

#

3.1 Format

#

Je Element, je Funktion, je Fluss:

consumes [Flussgröße] von [Gegenseite] · Assume [Band]    · gilt-für [Lebensphase, Zustand]
delivers [Flussgröße] an  [Gegenseite] · Guarantee [Band] · gilt-für [Lebensphase, Zustand]

Der Anforderungssatz bleibt die Leseform:

Im Zustand ⟨Z⟩, wenn ⟨Wenn-Block⟩, muss ⟨Träger⟩ ⟨Verb⟩ ⟨Flussgröße⟩ an ⟨Senke⟩ ⟨mit Band⟩.

Er ist der Render des Matches zweier Halb-Deklarationen (Delivers der Quelle ∧ Consumes der Senke) und wird nicht mehr geschrieben.

3.2 Regeln

#

1. Die Deklaration hängt an der Funktion, nie am Element. Wer beides schreibt, baut den Doppelbestand wieder ein. Die Elementgrenze ist berechnet.
2. Jede Funktion hat genau einen Output. Ein unbeabsichtigter Abgang (Wärme) ist eine eigene Funktion, nie zweiter Output der Hauptfunktion.
3. Die Richtung ist Funktion des Zustands, nicht des Kanals. Dieselben Klemmen tragen „liefert 24 V, gilt-für Entladen" und „nimmt Ladung auf, gilt-für Laden".
4. Assumes gegen das Modell werden geprüft, Assumes gegen den Kontext werden deklariert. Liegt die Quelle im Modell, ist Assume ⊆ Guarantee berechenbar. Liegt sie im Kontext, ist das Assume ein Kontextwert mit Band, Quelle und Provenienz; fehlt die Quelle, ist es „Annahme ohne Beleg".
5. Eine Guarantee des Systems ist eine Funktion, deren Senke ein Kontextwert ist. Die Schnittstellenliste des Systems ist ein Filter, keine Liste.
6. Ein Fluss an der Grenze ohne Funktion ist eine unvollständige Deklaration — ein Befund, kein zulässiger Modellzustand.
7. Kontextwerte sind nie Subjekt, nie unter einem Systemelement, nie als „muss"-Satz gerendert. Ein Satz über den Menschen („Die Wartung muss alle 500 h …") ist nicht verifizierbar; er zerfällt in eine Annahme über die Rolle und eine Zusage des Systems.

3.3 Korrektur zweier naheliegender Vereinfachungen

#

• „Externe Schnittstelle = Guarantee" ist nur die Hälfte. Ein Versorgungsanschluss ist eine externe Schnittstelle, die nur aus einem Assume besteht.
• „Alle Assumes = Randbedingungen" gilt nur für Assumes mit Quelle im Kontext. Assumes zwischen internen Elementen werden gegen eine Guarantee im Modell geprüft.

4. Das Vollständigkeitsraster

#

4.1 Warum ein Raster

#

Vollständigkeit lässt sich nur gegen eine endliche, geschlossene Referenzmenge beweisen. „Gegen die Welt" geht nicht; „gegen die Achsen A bis N, je abzählbar" geht. Daraus folgt eine Architekturregel, die vor jeder Umsetzung gilt: Schlüsselachsen sind die Achsen, die jede Deklaration adressieren muss — sie gehören ins Schema, und nur sie erzwingen bei Änderung einen Umbau. Katalogachsen sind Vokabular — sie können wachsen, ohne dass eine Deklaration wandert.

4.2 Schlüsselachsen (sieben)

#

Zu Achse 4. Ishikawa nennt „Maschine". Hier heißt die Klasse Fremdsystem (Begriff aus dem Interface-Contract-Papier: „Fremdsystem = Lieferant = Kunde, ein Baustein"), weil „Maschine" sich mit dem eigenen Produktbaum beißt: Die anderen Elemente des eigenen Modells sind keine Gegenseite im Sinne des Rasters, ihre Grenzen werden im Modell geprüft (Regel 3.2.4). Fremdsystem ist alles Technische außerhalb des Modells: Stromnetz, Lader, Buspartner, Tester, Lieferantenteil, Topf auf dem Kochfeld. Die Systemgrenze ist der Ort aller vier Klassen; der Unterschied zwischen Fremdsystem und Mitwelt ist der Eigentümer:

Interferenz (EMV, Wärme, Vibration) ist keine Gegenseite, sondern ein Flusstyp; sie kommt von der Mitwelt oder von einem Fremdsystem und läuft quer über alle vier Klassen. Ohne die vierte Klasse wäre der Netzausfall ein Umweltereignis statt ein Vertragsbruch des Netzbetreibers.

Zu Achse 6. Die Lebensphase ist der größte Befund dieser Arbeit. Transport hat eigene Zustände (Hauptschalter aus, verzurrt), eigene Rollen (Spediteur), eigene Umwelt (Seefracht, Stoß), eigene Guarantees (Verpackung hält). Reinigung hat einen Sperrzustand. Fertigung hat ESD. Ein Band je Betriebszustand reicht nicht; es braucht Band je Phase × Zustand. Zustandsgruppen hängen unter Phasen, nicht unter einem globalen Katalog.

4.3 Katalogachsen (Vokabular)

#

Adressat und Fehlgebrauch sind keine eigenständigen Prüfzeilen, sondern Lieferanten für die Schlüsselachsen: „Kind" wird zur Rolle (Gegenseite), „Kindersicherung" zum Zustand, „Nachbarschaft" zur Senke von Lärm. Deshalb sind sie Einstiegskataloge, keine Schlüssel.

Alterung verdient eine eigene Erwähnung: „Guarantee am Tag 1" und „Guarantee nach 10 000 h" sind zwei Bänder. Das RE kennt nur das erste. Alterung ist eine Abweichungsart (Katalog), kein Schlüssel; sie wird als Band-Verlauf über die Zeit deklariert.

4.4 Die drei Zustände einer Rasterzelle

#

Je Element × Gegenseite-Klasse × Lebensphase × Zustand:

Ohne das explizite „nicht zutreffend" ist eine Lücke von Absicht nicht unterscheidbar. Die 21700-Zelle hat keinen Menschen — das muss jemand gesagt haben.

4.5 Textfassung der Grafik

#

                    Lebensphase →   Fertigung  Transport  Install.  Betrieb  Wartung  Entsorgung
Gegenseite ↓
Mensch                              [D]        [D]        [D]       [D]      [D]      [n.z.]
Fremdsystem                         [D]        [n.z.]     [D]       [D]      [D]      [n.z.]
Mitwelt                             [D]        [D]        [D]       [D]      [L]      [D]
Material                            [D]        [n.z.]     [n.z.]    [D]      [D]      [D]

D = deklariert · n.z. = nicht zutreffend (begründet) · L = Lücke
Jede Zelle: × Betriebszustände der Phase · × Richtung (consumes / delivers)
Jede deklarierte Zelle verweist auf Funktionen am Träger, nie auf eine Liste am Element.

5. Vier Mechanismen für Unbekanntes

#

Ein Raster findet nur Lücken auf bekannten Achsen. Für unbekannte Kanäle gibt es vier Mechanismen, die stärker sind als jede Liste.

5.1 Bilanz. Energie, Masse, Impuls, Information: Was hineingeht, muss heraus. Ein Element nimmt 1,2 kW Kraftstoff auf und gibt 1 kW elektrisch ab; dann fehlen 200 W Wärme als Abgang an irgendwen. Die Bilanz je Element je Zustand erzeugt die ungewollten Kanäle (Wärme, Vibration, EMV, Verlustmasse) von selbst, ohne dass jemand an sie denkt. Kein RE-Werkzeug macht das; es ist die einzige Methode, die Unbekanntes findet. Voraussetzung: Flussgrößen mit Einheit (UCUM). In der Validierung (§7) findet die Bilanz in allen drei Systemen dieselbe Lücke: ungewollte Abgänge.

5.2 Paarung. Jede Annahme braucht eine Quelle, jede Zusage einen Adressaten, jede Rollen-Annahme eine Systemzusage, jeder Fluss an der Grenze eine Funktion. Fehlt der Partner, ist es eine Lücke. Das ist als Regel vorhanden, aber noch nicht als durchlaufende Prüfung.

5.3 Rendern. Handbuch, Bedienkonzept, Testfall, FMEA-Formblatt, Schnittstellenspezifikation: Hat eine Sicht ein leeres Kapitel, ist das Modell unvollständig. Backward-Calculation aus der Output-Forderung. Fünf Sichten sind fünf Sonden.

5.4 Feld. Reklamation, Drift-Signal, Nacharbeit: jede ist eine nicht deklarierte Grenze. Das ist Pflicht 5 des Lebensfähigkeitsmodells und der einzige Weg, der Referenzmenge neue Achsen hinzuzufügen. Vollständigkeit ist nicht statisch; sie wächst per Beleg.

6. Ableitungen

#

6.1 Guarantees des Systems und Bewertungsendpunkte

#

Eine Funktion mit Senke ∈ Kontext ist eine Guarantee des Systems. Die Gruppierung nach Gegenseite-Klasse der Senke ergibt die Kapitel „an den Menschen" und „an die Schnittstelle". Die Merkmale der Guarantee sind die Merkmale der Funktion und liegen beim Träger.

Der Träger einer solchen Funktion ist ein Bewertungsendpunkt der FMEA — berechnet, nie gesetzt. Damit sind Bedienpanel und Abgabekote Endpunkte, ohne oben im Baum zu stehen. Mehrere Abnehmer (Trafo mit mehreren Spannungen, mehrere Panels) ergeben mehrere Endpunkte. Das löst den Befund „FMEA-Bewertung nur auf oberster Ebene" ohne neue Regel.

Schnittstellen sind eine Rendersicht, kein Editor (entschieden 19.10.2026). Dieselbe Mechanik wie die Betriebszustände-Sicht: Liste aller Funktionen mit Quelle oder Senke im Kontext, gruppiert nach Gegenseite-Klasse, mit „Funktion hier anlegen", das an der Gegenseite startet und die Funktion unter dem gewählten Träger im Requirements-Editor ablegt. Die Marker „extern" (Quelle oder Senke ∈ Kontext) und „Bewertungsendpunkt" (Senke ∈ Mensch oder Fremdsystem) sind berechnet. Authored ist an einer Schnittstelle nur der Eigentümer und die ICD-Referenz, beides am Kontextwert des Fremdsystems. Die Verträglichkeit Assume ⊆ Guarantee ist eine Query, dreiwertig.

6.2 Use Cases

#

Ein Use Case ist Mensch-Zeile × Betriebszustand × Steueraktion. Der Wenn-Block trägt das Ereignis ([Rolle] tut was [an was]), die Funktion die Systemantwort. Use Cases sind damit kein eigenes Artefakt, sondern eine Sicht über die Mensch-Zeile des Rasters. Die Story-Rolle („Als Bediener will ich …") ist die Halb-Deklaration der Gegenseite; es fehlt nur die Guarantee des Systems am Träger.

6.3 Handbuch, Bedienkonzept, Testfall

#

Ein Bedingungsterm, fünf Dokumente: Handbuchschritt, Bedienkonzept, Requirement, FMEA-Ursache, Testfall entstehen aus demselben Wenn-Block und derselben Funktion. Das ist die bestehende Linie (Plan 01.10.2026, W6) und wird hier nur mit der Vollständigkeitsprüfung verbunden: Ein leeres Handbuchkapitel ist eine leere Rasterzelle.

6.4 P-FMEA

#

Derselbe Mechanismus, anderer Baum. Prozessschritt = Träger. Die Merkmale des Zusammenbaus (ZSB) sind die Guarantees des Schritts. Die 4M des Schritts sind seine Gegenseite: Werker (Mensch, optional bei Vollautomatik), Betriebsmittel (Fremdsystem), Halle (Mitwelt), Eingangsmaterial (Material). „Funktion Mensch macht" ist die Rolle als Quelle der Steueraktion am Schritt. Der Werker ist Kontextwert des Prozessschritts, nicht des Produkts.

6.5 Functional Safety: HARA als Projektion des Rasters

#

Sicherheitsziele sind Zweck-Blöcke mit benanntem Adressaten (Entscheidung 02.10.2026); Funktionen verfeinern sie. Ein Safety Goal wird validiert, eine Funktion verifiziert — deshalb Z, nicht F, auch wenn ISO 26262 von „top-level safety requirement" spricht. Mit Fremdsystem als vierter Klasse fällt die Gefährdungsanalyse (HARA) fast vollständig aus dem Raster heraus:

Drei Attribute, keine neue Tabelle: E an Zustand × Phase, ASIL als Klassifikator am Z und am Link, FTTI als gewöhnliches Merkmal. Controllability ist die Größe, die heute niemand deklariert, weil der Mensch kein Element ist; hier ist sie ein Band am Rollen-Kontextwert und damit prüfbar.

6.6 Vorhersehbare Fehlanwendung als Mensch-Zeile × UCA

#

Vorhersehbare Fehlanwendung (ISO 12100, ISO 14971, Maschinenverordnung, MDR) ist keine eigene Achse, sondern die Mensch-Zeile des Rasters mal UCA-Satz. Der Bediener ist Controller (Leveson); sein Ereignis-Term [Rolle] tut was [an was] trägt den UCA-Satz unverändert: UCA-1 Commission (Kind drückt Boost), UCA-2 Omission (Topf vergessen), UCA-3 Timing und Reihenfolge (Betankung im Lauf), UCA-4 Dauer (Taste klebt). Fehlanwendung wird damit erzeugt, nicht aufgezählt — derselbe Mechanismus wie der Fehler-Generator, mit der Rolle als Quelle statt des Steuergeräts.

Authored bleibt nur die Einstufung „vernünftigerweise vorhersehbar" mit Begründung, in derselben Form wie das „nicht zutreffend" des Rasters: ein Dreiwert an einer generierten Zeile (vorhersehbar · ausgeschlossen mit Begründung · offen). Jede als vorhersehbar markierte Zeile wird an vier Stellen gerendert, ohne eigenen Bestand: als Wenn-Bedingung einer Guarantee (Kindersicherung, Topferkennung), als Mensch-Ursache in der FMEA, als Hazardous Event in der HARA (§6.5), als Restrisiko-Warnung im Handbuch. Security läuft identisch: Angreifer ist eine Rolle mit Absicht, STRIDE ein zweiter Abweichungskatalog auf derselben Zeile; nicht Teil dieses Papiers.

6.7 Kapitelhierarchie der Anforderungsbeschreibung (Ebene 0)

#

Feste Reihenfolge als Firmenvorlage (Methodenbeschreibung v3, Grundsatz 1). A = authored, R = gerendert ohne Bestand.

Querregeln: Header und Information unter jedem Knoten erlaubt. Assembly nur in der D-FMEA-Sicht. Kapitel 8 steht vor der Struktur, weil der Kunde die Schnittstellen vor der Zerlegung liest.

Editoren: 1, 3, 4, 6 (Zustandsteil), 9 vorhanden; 5 (Kontextwert-Editor) und 6 (Phasen-Ebene) geplant; 2, 8, 10, 11 sind Sichten. Der Funktionseditor ist überall dieselbe Komponente (Requirements-Editor, Architektur-Elementdetail, S-FMEA-Panel, Ingress-Pipeline); die fünf Fragen des Mockups liegen auf seinen bestehenden Feldern, ergänzt um typisierte Quelle/Senke, Lebensphase, Term-Builder und Merkmals-Liste. Mehrfach ist die Merkmals-Liste, nicht Verb und Flussgröße: eine Funktion = ein Verb + eine Flussgröße + genau eine Senke; zwei Flussgrößen sind zwei Funktionen.

6.8 Aspekte und Querschnittsanforderungen

#

Aspekte sind eine Katalogachse, kein Kapitel. Sie laufen an fünf Stellen durch das Raster:

Die Querschnittsanforderung ist die Antwort auf den Befund aus §1.1, dass generische Merkmale nirgends sauber gehalten werden: einmal am TOP oder an einem Teilbaum deklariert, von jedem Element mit diesem Aspekt geerbt, Erbstatus sichtbar. Mit der Ableitung aus der Flussgröße setzt der Anwender den Aspekt fast nie von Hand. Das Raster erhält damit eine umschaltbare dritte Achse: Klasse × Phase oder Aspekt × Phase.

7. Validierung an drei Systemen

#

Die sieben Schlüsselachsen und die Katalogachsen wurden gegen drei Systeme durchgespielt: Stromerzeuger im Container (SE), KFZ-Steuergerät (SG), Induktionsherd (H). Die vollständige Tabelle liegt im Quell-Thread; hier die Befunde.

Befunde:

1. Keine Achse bleibt bei allen drei leer; jedes System hat mindestens eine echte „nicht zutreffend"-Zelle. Das explizite „nicht zutreffend" ist damit bestätigt notwendig.
2. Lebensphase und Budget liefern die meisten Anforderungen, die im RE regelmäßig fehlen: Reinigung, ESD im Transport, Ruhestrom, Leistungsmanagement, Lärm an die Nachbarschaft.
3. Die Bilanz findet in allen drei Fällen dieselbe Lücke: ungewollte Abgänge.
4. Fremdsystem kommt in allen drei vor und ist weder Mensch noch Mitwelt noch Material. Der Topf ist das sauberste Beispiel.
5. Fehlgebrauch und Adressat liefern Rollen, Zustände und Senken; sie sind Einstiegskataloge, keine Schlüssel.
6. Zustände hängen unter Phasen (Transport hat eigene, Reinigung hat einen Sperrzustand).
7. Die sieben Schlüsselachsen haben gehalten; nichts im Test verlangte einen achten Schlüssel.

8. Einordnung in die Literatur

#

Nicht nie angesprochen, aber nie zusammen.

Grenzdeklaration formal. Heninger (1980, A-7E) mit Modes, monitored/controlled variables und Umgebungsannahmen; Parnas/Madey (1991) Four-Variable-Model; Jackson/Zave (1997, „Four dark corners of RE"): Umgebungsannahmen ∧ Spezifikation ⊢ Requirement — exakt Assume ∧ Guarantee; Gunter/Gunter/Jackson/Zave (2000) Reference Model; Jackson (2001) Problem Frames. Alle an der Systemgrenze außen, keine je Element, kein Raster.

Vertragsform. Benveniste et al. (2018) „Contracts for System Design"; Broy, FOCUS (Assumption/Commitment). Am Element, aber ohne Gegenseite-Klassen, Lebensphase und Vollständigkeitszählung.

Enumeration der Einflussfaktoren. Taguchis P-Diagramm mit fünf Störgrößenklassen (Stück-zu-Stück, Änderung über Zeit, Nutzung/Duty Cycle, externe Umgebung, Systeminteraktion) — in Kurzform die Achsenliste dieses Papiers, aber im AIAG-DFMEA-Handbuch, also in der FMEA, nie im RE. Ishikawa 4M als Ursachenklassen nach dem Fehler, hier als Vollständigkeitsachse vor dem Satz.

Lebenszyklus und Normen. ISO 15288 als Phasenliste; ISO 29148 nennt „operational environment", „life cycle" und „interfaces" als Pflichtinhalte und als Anforderungskategorie — ohne Raster, ohne Elementbezug. HAZOP-Leitworte und STPA-UCA-Typen als Abweichungs- und Verhaltenskataloge.

Was nach Kenntnis des Autors fehlt: Lebensphase × Gegenseite-Klasse × Zustand als verbindliche Deklaration an jedem Element mit Lückenzählung, aus der Requirement, FMEA, Handbuch und Test gerendert werden. Die Formalisten blieben an der Systemgrenze außen, die FMEA-Methodik beim Formblatt, keiner bei jedem Element. Dieser Abgrenzungsanspruch ist vor Publikation durch Literaturrecherche zu belegen.

9. Konsistenz zur Methodenbeschreibung v3

#

Abgleich nach Standing Order 21.4.

Keine Stelle widerspricht v3. Zwei Delta-Kandidaten für die nächste Rendering-Runde: (a) gilt-für um Lebensphase erweitern, (b) K-Klasse erhält die Gegenseite-Klasse als Pflichtattribut. Beides ändert die Methode nicht, es macht sie zählbar.

10. Offene Entscheidungen

#

Drei Entscheidungen, die vor einem UI-Konzept fallen müssen. Keine davon ist technisch; alle drei sind Methode.

E1 — Klasse „Fremdsystem" am Kontextwert (entschieden 19.10.2026). Plan 01.10.2026 (W2) schließt „Maschine" am Kontextwert aus, weil Maschine der Produktbaum ist. Das Raster braucht eine Zeile für technische Gegenseiten außerhalb des Modells (Netz, Lader, Buspartner, Lieferantenteil, Topf). Entschieden: Klasse „Fremdsystem" zulassen, ausschließlich für Gegenseiten außerhalb des Modells; W2-Acceptance-Zeile „4M Maschine am Kontextwert nicht wählbar" wird zu „Maschine nicht wählbar, Fremdsystem nur mit Eigentümer". Verworfen: zweites Wurzelelement neben TOP (bricht „genau ein Systemelement auf Ebene 0").

E2 — Lebensphase als Schlüsselachse. Folge: Zustandsgruppen hängen unter Phasen; jedes Band am Kontextwert und jedes gilt-für an der Funktion trägt Phase × Zustand. Das ist ein Schema-Schlüssel, der nachträglich teuer wäre. Entscheidung vor der ersten Zeile Architektur. In dieselbe Migration gehören die drei Safety-Attribute aus §6.5 (E an Zustand × Phase, ASIL am Z-Block und am verfeinert-Link), damit es eine Migration wird und nicht zwei.

E3 — „nicht zutreffend" als authored Datum am Element. Je Element × Gegenseite-Klasse (× Phase), mit Begründung, mit History. Das einzige neue Datum des gesamten Konzepts. Ohne es ist Lücke von Absicht nicht unterscheidbar.

Nachgelagert, nicht blockierend: Alterungsband als Band-Verlauf (Katalog); Budget-Prüfung je Quelle (Read-Model); Fehlgebrauchs-Katalog als Einstieg für Rollen und Zustände.

11. Einordnung als FuE

#

Neuheitsanspruch gegenüber dem Stand der Technik: die Vereinigung von Elementgrenz-Deklaration, Gegenseite-Klassen, Lebensphase und Zustand zu einem Vollständigkeitsraster mit Lückenzählung, aus dem Requirement, FMEA, Use Case, Handbuch und Test gerendert werden, ohne dass eines davon geschrieben wird.

Technische Unsicherheit, die zu lösen ist: (1) Ob das Raster bei realer Modellgröße (hunderte Elemente × Phasen × Zustände × Klassen) ohne Pflege-Explosion bleibt — Standard-Facetten am Komponententyp sind die Hypothese, nicht der Beweis. (2) Ob die Bilanz-Prüfung bei gemischten Flussgrößen (Signal ohne Erhaltungssatz) tragfähig bleibt. (3) Ob die Lückenzählung in der Praxis akzeptiert wird oder als Zwang empfunden wird — die Akzeptanz der Funktionsformulierung ist bereits ein bekannter Blocker.

Die drei Fragen sind messbar: Pflegeaufwand je Element in Minuten, Anteil template-instanzierter Deklarationen, Anzahl der vom Raster gefundenen Lücken, die die FMEA nicht gefunden hätte.

12. Nicht Teil dieses Papiers

#

Datenmodell, Convention-Inventur (Standing Order 3c), Migrationsplan, Umsetzungsplan und CR-Schnitt. Das UI-Konzept liegt als klickbares Mockup vor (claude/MOCKUP_2026-10-19_grenz-editor.html): fünf Fragen je Deklaration, Raster je Element mit Dreiwert und Begründungs-Pflicht, Term-Builder mit UND/ODER, sechs Renderings (Anforderung, FMEA, HARA, Handbuch, Test, Fehlanwendung). Reihenfolge: E2 und E3 entscheiden → Umsetzungsplan auf bestehende CRs (246 W2/W2b/W3, 342, 166, 288) plus genau ein neuer CR (Raster, Lebensphase, Fremdsystem, Safety-Attribute, Schnittstellen-Sicht) → Architektur als eigener Cycle. Ein eigenständiger Einseiter für Leser ohne Methodentiefe wird separat geschrieben; Teil A ist dafür die Vorlage, nicht der Text.

Anhang — Methoden-Inbox-Eintrag (zum Übertragen nach docs/METHODEN_INBOX.md)

#

19.10.2026 · Auslöser: Grundsatzdiskussion RE / Befund FMEA-Bewertung nur oben
Kernsatz: Die 4M sind keine FMEA-Ursachenklassen, sondern das Vollständigkeitsraster der Elementgrenze; eine Grenze ohne Deklaration je Klasse, Phase und Zustand ist eine Lücke, kein Einverständnis.
Test 21.1: bestanden (tool-unabhängig · domänenübergreifend · ohne OTSM handelbar)
Referenz: claude/METHODENPAPIER_2026-10-19_elementgrenze-vollstaendigkeitsraster_DRAFT.md · methodenbeschreibung v3 §2 (gilt-für), §8a Grundsatz 1–3

OTSM GmbH — Thomas Arends. Methodenpapier Elementgrenze und Vollständigkeitsraster, DRAFT v0.3, 19.10.2026. „Ein Requirement ohne deklarierte Elementgrenze ist eine halbe Deklaration — nicht falsch, aber unprüfbar."