Masterarbeit/Versuche/Versuch_02/02_Prompt.md

Versuch 02 - Agentengestuetzt - Prompt-Version 03-A

Metadaten

• Versuch: V2 Agentengestützt (rollenspezialisierte Agentendateien)

• Prompt-Version: 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)

• Basis: Versuche/Versuch_01/03_Prompt.md, SHA-256 B8C8764F…C030F07

• Codebasis: c-entron ERP-Suite (Windows, C#/XAML, MSSQL)

• Zeitstempel: 2026-08-31

• Vorgänger: 01_Prompt.md (Prompt-Version 02-A, SHA-256 DCDC0E3F…B71BCF), kein Lauf durchgeführt

• Änderungsgrund gegenüber 01_Prompt.md: Version 02-A leitete sich von Prompt-Version 02 ab. Versuch 1 ist inzwischen auf Prompt-Version 03 weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in zwei Größen unterscheiden — Agentenrollen und Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.

  Änderung gegenüber Versuch_01/03_Prompt.md	Grund
  Neuer Abschnitt „Arbeitsteilung"	Prompt-Version 03 unterstellt stillschweigend einen Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen.
  In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung	Die 7-Datei-Regel aus Version 03 entstand an einem solo-Lauf (Kimi legte SwRS-Ergaenzungen.md an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt.
  In der Arbeitsteilung: Zuständigkeitsbindung — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt	V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist statisch deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten.
  In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe	Gebunden wird wer eine Teilaufgabe ausführt, nicht wie viel davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b.
  In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung	Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen subagent_stats und die Subagenten-Prompts prüfbar.
  Angehängte Tabellenzeilen und Schlussblockquote aus 03_Prompt.md an ihren Platz gerückt	In 03_Prompt.md stehen zwei Zeilen der Änderungstabelle nach dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die gesamte Datei sendet (_meta/combined_prompt.md), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein.

  Der Prompt nennt keine Rolle namentlich. Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen solo-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin nicht vorgegeben; sie bleiben Teil der Untersuchung.

  Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.

Dieser Prompt enthält ausschließlich die Analyseanweisung und ist damit unabhängig von einem bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.

---

Prompt

Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach ISO/IEC/IEEE 29148:2018. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.

Auftrag

Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:

1. StRS - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. SyRS - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. SwRS - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)

Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.

Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)

Der Untersuchungsgegenstand ist die gesamte Codebasis im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.

Breite geht vor Tiefe. Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt Vorgehen: erst Inventar, dann Mindestabdeckung, dann Vertiefung.

Vorgehen (statische Analyse, keine Ausführung)

Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:

Schritt 0 - Modulinventar (vor der ersten Anforderung). Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im Analysebericht.md als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, bevor die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.

Schritt 0b - Mindestabdeckung. Jedes Modul des Inventars erhält mindestens eine Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als nicht analysiert mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. Mehr als 10 % der Module als nicht analysiert zu führen, ist ein Hinweis auf unvollständige Erkundung – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.

Schritt 0c - Vertiefung nach Risiko. Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.

2. Artefakterhebung: Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. Technische Analyse: Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. Semantische Interpretation: Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. Formalisierung: Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. Traceability-Anreicherung: Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.

Pflicht-Eigenschaften jeder Anforderung

• Belegpflicht: Jede Anforderung muss mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, schreibe die Anforderung nicht - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
• Trennung von Fakt und Interpretation: Die belegte technische Beobachtung (Feld Fakt) wird getrennt von der fachlichen Interpretation (Feld Aussage) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
• Risikobasierte Priorisierung: Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen PRIMÄR-Beleg, andernfalls sind sie zwingend als [HYPOTHESE] zu kennzeichnen. Ein PRIMÄR-Beleg benennt hier die durchsetzende Stelle - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
• Belegklassifikation: Kennzeichne jeden Beleg als
  • PRIMÄR (durchgesetzte Regel im Code oder DB-Constraint),
  • SEKUNDÄR (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  • KONTEXT (Kommentar, Commit-Message, Ticketreferenz).
• Hypothesenmarkierung: Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit [HYPOTHESE] und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
• Verifizierbarkeit: Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
• Eindeutigkeit: Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
• Übernahmewürdigkeit: Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide übernehmen (fachlich weiterhin erforderlich), Workaround (historisch gewachsene Behelfslösung), Sonderfall (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und veraltet (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
• Redundanzfreiheit: Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.

Arbeitsteilung

Die Bearbeitung wird auf mehrere Bearbeiter verteilt. Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.

• Frei bleibt, wie du die Bearbeiter einsetzt. Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
• Zuständigkeit vor Bearbeitung klären. Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
• ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos. Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
• Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter. Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
• Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg. Die Mindestabdeckung ist erreicht, wenn jedes Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
• Der Konsistenzcheck gilt dem zusammengeführten Ergebnis. Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
• Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
• Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig. Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.

Dokumentationspflicht. Halte im Analysebericht.md fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.

Formatvorgabe pro Anforderung

ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
Titel:         <kurzer Titel>
Ebene:         <StRS | SyRS | SwRS>
Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur:        <Rolle / System / Komponente>
Vorbedingung:  <Zustand vor Auslösen>
Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
Prüfidee:      <Akzeptanzkriterium oder Testidee>
Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status:        <belegt | HYPOTHESE>

Traceability

Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:

• Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
• Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
• Erzeuge zusätzlich eine konsolidierte Traceability-Tabelle (Markdown oder CSV): StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg.

Nicht-funktionale Anforderungen

• Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der ISO/IEC 25010 zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld Qualitätsmerkmal ein, nicht in das Feld Typ.
• Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.

Konsolidierungsbedarf

Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld Konsolidierung als Kandidat für eine Zusammenführung im Zielsystem.

Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind kein Konsolidierungsfall - dafür sind die Tracelinks da.

Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)

Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)

Erstelle ausschließlich diese 7 Dateien. Keine Ergänzungsdateien, keine Aufteilungen wie SwRS-Ergaenzungen.md oder SyRS-Teil2.md. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.

Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.

Randbedingungen

• Keine Halluzinationen. Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
• Keine Generierung von Code. Es sollen ausschließlich Spezifikationsartefakte entstehen.
• Keine Annahme über nicht beigestellte Hilfsmittel. Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als [HYPOTHESE] zu kennzeichnen.
• Migrationsperspektive berücksichtigen. Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld Übernahmewürdigkeit, nicht in das Feld Status. Status beschreibt ausschließlich die Belegsituation (belegt oder HYPOTHESE), Übernahmewürdigkeit die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
• Sprache: Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.

Abschluss

Führe vor Abgabe einen Konsistenzcheck über das gesamte Anforderungs-Set durch und dokumentiere das Ergebnis im Analysebericht.md:

• Doppelte oder mehrfach vergebene IDs
• Anforderungen ohne Beleg
• Anforderungen ohne Angabe zur Übernahmewürdigkeit
• Tracelinks auf nicht existierende IDs
• Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
• Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein PRIMÄR-Beleg vorliegt, andernfalls die [HYPOTHESE]-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
• Abgleich Hypothesen.md gegen die Inline-Markierungen: Beide müssen dieselben Anforderungen nennen. Hypothesen.md enthält genau die Anforderungen mit [HYPOTHESE]-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.

Erstelle außerdem die Abdeckungstabelle auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung tief | mittel | flach | nicht analysiert und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.

Beende den Lauf mit einer kurzen Selbstbewertung im Analysebericht.md:

• Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
• Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
• An welchen Stellen war der Beleg dünn (hoher Anteil SEKUNDÄR/KONTEXT oder [HYPOTHESE])?
• Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
• Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?