Was vorher fertig sein muss
Eine Liste der späteren Konsumenten von Ontology, Knowledge Graph oder GraphRAG-Pipeline liegt vor, sodass Fragen aus echtem Nutzungskontext stammen.
Was vor Start vorliegen muss
Geteiltes Dokument oder Tabelle mit Spalten Frage, Beispielantwort, benötigte Konzepte, Priorität, Coverage-Status; Beispielfragen als Anker; Whiteboard für Clustering.
Ein Facilitator mit Ontology- oder Modellierungserfahrung; zwei bis vier Domain Experts; ein bis zwei Konsumenten (z. B. Data Scientist, GraphRAG-Entwickler); ein Scribe für die Fragen-Tabelle.
Use-Case-Beschreibung des geplanten Modells; bekannte Datenquellen; existierende Vokabulare oder Ontologien für Reuse; Beispielfragen aus vergleichbaren Projekten als Anker.
2-4 h
Tabelle vorbereiten. 3-5 Beispielfragen als Anker einkleben (z. B. „Welche Komponenten hängen von Service X ab?“). Regel ansagen: Fragen müssen vom Modell beantwortbar sein, nicht von Wikipedia.
Die eine Frage, die diese Methode beantwortet
Welche konkreten Fachfragen muss das geplante Modell beantworten können, damit es für die geplanten Use Cases ausreichend und nicht überdimensioniert ist?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Use-Case-Briefing | 20-30 min | Konsumenten beschreiben ihre Use Cases konkret. Pro Use Case ein bis zwei Beispielfragen. Klären, was Wikipedia oder Suche schon liefern und wo das Modell echten Mehrwert geben muss. | Wenn Use Cases vage bleiben („irgendwann KI darauf“), lieber zurückstellen. Ohne reale Frage gibt es keine sinnvolle Competency Question. |
2Phase 2: Fragen sammeln | 45-60 min | Stille Phase plus Round-Robin: jede Person formuliert konkrete Fachfragen, die das Modell beantworten muss. Mindestens 30 Fragen. Eine Frage pro Zeile. Inklusive konkretem Beispiel-Trigger. | Wenn eine Frage mit „Was ist …?“ beginnt, ist sie meist Definitions- statt Modellierungsfrage. Umformulieren zu „Welche …?“, „Wie viele …?“, „Welche Beziehung …?“. |
3Phase 3: Clustern und priorisieren | 30-45 min | Fragen clustern (z. B. Entity Lookup, Beziehungs-Query, Aggregat, zeitliche Frage). Pro Cluster Coverage diskutieren. Priorität setzen: must-have, nice-to-have, out-of-scope. Out-of-scope explizit notieren. | Out-of-scope-Fragen sind wertvoll als Grenzdefinition. Wer sie streicht statt markiert, verliert die Begründung für spätere Scope-Diskussionen. |
4Phase 4: Konzepte ableiten und Test Queries | 30-45 min | Pro must-have-Frage Konzepte, Beziehungen und Properties auflisten, die das Modell braucht. Aus 3-5 Top-Fragen Test Queries als Pseudocode (SPARQL, Cypher, GraphQL) skizzieren. | Wenn dieselben Konzepte in vielen Fragen auftauchen, sind das die Kernklassen. Wenn eine Frage Konzepte verlangt, die nirgendwo sonst auftauchen, prüfen ob sie wirklich must-have ist. |
Was am Ende rauskommt
Tabelle oder Markdown-Dokument mit nummerierten Fragen, Priorität, abgeleiteten Konzepten, Beispiel-Test-Query und Coverage-Matrix gegen Use Cases. Wird zur Akzeptanzbasis für das Modell.
Datum und Modell-Version im Header. Question Set wächst parallel zum Modell. Beantwortete Fragen mit Verlinkung auf Modellbestandteil markieren, nicht löschen. Out-of-scope-Fragen mit Begründung erhalten.
Kompakte Arbeitsvorlage für Competency Questions mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Competency Questions Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Competency Question Set:
- Required Concepts:
- Test Queries:
- Coverage Matrix:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?Konkret gefülltes Szenario
## Competency Questions — Knowledge Graph „Service Dependencies“ (v0.3, 18.05.2026)
**Use Case 1**: Incident Response: schnell wissen, wer von Ausfall betroffen ist.
**Use Case 2**: Architecture Review: Bottlenecks und Single Points of Failure finden.
### Must-have
1. Welche Services hängen direkt von Service X ab? Beispiel: PaymentService. Konzepte: Service, DEPENDS_ON.
2. Welche Teams sind Owner von Services, die DB-Cluster Y nutzen? Konzepte: Team, OWNS, Service, USES, Database.
3. Wieviele transitive Abhängigkeiten hat Service X bis Tiefe 3? Konzepte: Service, DEPENDS_ON*1..3.
### Nice-to-have
4. Welche Services teilen sich denselben Secret Store?
### Out-of-scope (v0.x)
- Historische Abhängigkeiten („wie war es vor 6 Monaten“). Begründung: Versionierung nicht in v0.x.
### Test Query (Frage 1, Cypher)
```
MATCH (s:Service {name:'PaymentService'})<-[:DEPENDS_ON]-(c:Service)
RETURN c.name
```
**Coverage v0.3**: 9 von 12 must-have-Fragen beantwortbar. Lücken: Frage 7, 10, 11 (Konzept SecretStore fehlt).Symptome erkennen, gegensteuern
Modellierer erfinden Fragen, die niemand stellen wird, Test Queries finden im Betrieb keine Anwendung.
Mindestens zwei echte Konsumenten in den Workshop holen. Wenn nicht verfügbar, vorher kurze Interviews führen und Fragen aus diesen Interviews einbringen.
Fragen wie „Was ist eine Microservice-Architektur?“ stehen in der Liste.
Solche Fragen sind Glossar, nicht Modell. Umformulieren in „Welche Services sind als microservice-style markiert?“ oder streichen. Glossar in separate Datei.
Über 80% der Fragen sind als must-have markiert, Priorisierung verlässt sich auf Bauchgefühl.
Strenge Definition: must-have heißt blockiert konkreten Use Case. Bei Unsicherheit zu nice-to-have. Maximal 60% must-have als Faustregel.
Fragen sind formuliert, aber niemand kann sagen, wie sie technisch als Query aussehen.
Mindestens 3 Top-Fragen als Pseudocode-Query skizzieren. Wenn das nicht geht, ist die Frage entweder unklar oder das Modell-Paradigma unpassend.
Question Set wird einmal geschrieben, später nicht mehr gepflegt. Beantwortete Fragen sind nicht verlinkt.
Question Set in Repo neben Modell ablegen. Pro Modell-Iteration Coverage prüfen und Verlinkungen pflegen. CI-Check kann Lücken sichtbar machen.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.