1. Einleitung

Requirements Engineering (RE) ist das Fundament jedes erfolgreichen Software- und Systemprojekts. Die Erfahrung zeigt: Fehler, die in der Anforderungsphase gemacht werden, sind in späteren Phasen am teuersten zu korrigieren. Doch oft scheitert es nicht am Willen zur Gründlichkeit, sondern an der Umsetzung im Projektalltag.

Praxis statt Theorie: Der Unterschied

Die Fachliteratur ist voll von theoretischen Meta-Modellen, Vorgehensstandards und abstrakten Prozessbeschreibungen. Diese Modelle sind wichtig, um den Rahmen zu verstehen, denn sie erklären das „Dass“ (z. B. „Dass Stakeholder analysiert werden müssen“). Doch in der hitzigen Projektpraxis lassen sie den Requirements Engineer oft mit der entscheidenden Frage allein: „Wie?“

  • Wie entlocke ich einem schweigsamen Stakeholder die relevanten Informationen?

  • Wie stelle ich sicher, dass ich bei der Systemabgrenzung nichts vergessen habe?

  • Welche konkrete Frage muss ich stellen, um versteckte Konflikte aufzudecken?

Dieses Kompendium wurde entwickelt, um genau diese Lücke zwischen akademischer Theorie und gelebter Praxis zu schließen. Es ist kein Lehrbuch über abstrakte Konzepte, sondern ein operativer Werkzeugkasten. Es basiert auf der Erkenntnis, dass die Qualität der Anforderungen direkt von der Qualität der Fragen abhängt, die wir stellen.

Ein Kompass für den Projektalltag

Anstatt neue theoretische Konstrukte zu erfinden, konzentriert sich dieses Modell auf die Beantwortung elementarer Fragen, die in jedem Projekt auftreten, unabhängig davon, ob Sie agil (Scrum, SAFe) oder klassisch (Wasserfall, V-Modell) arbeiten. Es bündelt Best Practices aus hunderten von Projekten in handlungsleitende Checklisten.

Um sicherzustellen, dass Sie dieses Werkzeug effektiv nutzen können und nicht von der Menge an Informationen erdrückt werden, haben wir den natürlichen Lebenszyklus einer Anforderung in eine klare Struktur gegossen: das 5-Phasen-Modell.

Dieses Modell dient Ihnen als Landkarte. Es verhindert, dass Sie „das Dach vor dem Fundament“ bauen, und leitet Sie intuitiv von der ersten vagen Idee bis zum Betrieb und der Wartung des fertigen Systems.

Der Inhalt: Ihr Fragenkatalog

Das Herzstück dieses Dokuments ist eine umfassende Sammlung von ca. 2.000 spezifischen Fragen. Diese Fragen sind kategorisiert und 5 Phasen zugeordnet. Sie dienen Ihnen als:

  • Interview-Leitfaden in Workshops mit Fachbereichen.

  • Checkliste für die eigene Qualitätssicherung.

  • Inspirationsquelle, wenn Projekte ins Stocken geraten.

Im Folgenden stellen wir Ihnen das Phasenmodell im Detail vor, bevor wir in die tiefe fachliche Arbeit der einzelnen Kategorien eintauchen.

2. Die 5 Phasen

Um die Struktur dieses Leitfadens und das Zusammenspiel der einzelnen Aktivitäten greifbar zu machen, wurde der Prozess visualisiert. Das folgende Diagramm dient als Landkarte für den gesamten Requirements-Engineering-Zyklus.

Es zeigt nicht nur die fünf chronologischen Hauptphasen, sondern verdeutlicht auch die Abhängigkeiten untereinander:

  • Wie fließen Arbeitsergebnisse von einem Schritt in den nächsten?

  • Wo finden Rückkopplungen zur Qualitätssicherung statt?

  • Wie steuert das Management den gesamten Ablauf?

Diagram

Lesehilfe für das Diagramm:

  • Durchgezogene Pfeile: Zeigen den Informationsfluss. Das Ergebnis des einen Schritts wird zum direkten Arbeitsmaterial für den nächsten (z. B. liefern die Ziele aus Phase 2 die Basis für die Funktionen).

  • Gestrichelte Pfeile: Bedeuten Abgleich & Prüfung. Hier fließt keine neue Information, sondern es wird geprüft, ob das Eine zum Anderen passt (z. B. prüft die Strategie, ob die Funktionen wirklich sinnvoll sind).

  • Rückwärts gerichtete Pfeile: Stellen Feedback-Schleifen dar. Wenn in Phase 4 (Prüfung) ein Fehler oder Konflikt gefunden wird, müssen wir oft einen Schritt zurückgehen und die Ziele in Phase 2 anpassen.

  • Verbindungen zu Phase 5: Zeigen den Datenfluss zur Dokumentation (Ergebnisse sichern) und den Rückfluss bei Änderungen (Change Requests lösen neue Prüfungen aus).

Der Prozess folgt einer natürlichen Reifung der Anforderungen und gliedert sich in fünf aufeinanderfolgende Phasen:

Phase 1: Fundament & Rahmenbedingungen (Der Rahmen)
Bevor inhaltliche Anforderungen formuliert werden, müssen die Spielregeln der Zusammenarbeit und die Rahmenbedingungen geklärt sein. Ohne dieses Fundament fehlt dem Projekt die Bodenhaftung, was zu methodischem Chaos führen kann. In diesem Schritt wird definiert, wie gearbeitet wird, wo das System agiert und welche harten Grenzen existieren.

  • Prozess-Initialisierung: Das Vorgehensmodell wird definiert, wobei festgelegt wird, ob ein klassisches oder agiles Vorgehen gewählt wird. Zudem werden Rollen und Verantwortlichkeiten geklärt, wie etwa die Befugnis zur Anforderungsfreigabe, um Kompetenzstreitigkeiten und methodische Brüche zu verhindern.

  • Infrastruktur-Setup: Die technische Umgebung zur Verwaltung der Anforderungsdaten wird geschaffen. Dazu wählen wir die passende Software aus und richten sie mithilfe von Vorlagen und Zugriffsrechten so ein, dass wir alle Daten geordnet verwalten können.

  • Kontext-Abgrenzung Der Scope wird definiert, indem eine harte Grenze zwischen dem zu gestaltenden System und der Außenwelt gezogen wird. Alle Schnittstellen zu technischen Nachbarsystemen und menschlichen Nutzergruppen werden identifiziert, um sicherzustellen, dass keine externe Abhängigkeit übersehen wird.

  • Restriktions-Analyse Alle Faktoren, die den Lösungsraum einschränken, werden gesammelt, bevor die kreative Arbeit beginnt. Dazu gehören Budgetgrenzen, Zeitlinien, einzuhaltende Gesetze, Normen oder technische Vorgaben, die als Filter für alle späteren Anforderungen wirken.

Phase 2: Ziele & Ermittlung (Der Inhalt)
Auf dem Fundament wird das inhaltliche Verständnis aufgebaut, indem zunächst das "Warum" (Ziele) geklärt und daraus das "Was" abgeleitet wird. Hierbei werden funktionale Datenstrukturen, Qualitätsansprüche und Begeisterungsfaktoren ermittelt, um Unbekanntes sichtbar zu machen.

  • Ziel-Definition: Die strategischen Absichten der Stakeholder werden ermittelt und in Ziel-Hierarchien modelliert. Widersprüche zwischen Zielen werden geprüft und Grundsatzkonflikte geklärt, um eine klare Ausrichtung für die Detaillierung zu schaffen.

  • Strategische Ermittlung: Mithilfe von Modellen und Prototyping-Techniken werden Begeisterungsfaktoren und Alleinstellungsmerkmale identifiziert. Dieser explorative Schritt dient dazu, Ideen zu validieren und Innovationen zu fördern, die über die reine Pflichterfüllung hinausgehen.

  • Fachliche Ermittlung: Es wird ermittelt, welche Daten das System speichern und verarbeiten muss sowie welche Aufgaben es erledigen soll. Die Logik hinter den Abläufen wird geklärt, um sicherzustellen, dass die fachliche Welt korrekt in Anforderungen übersetzt wird.

  • Qualitative Ermittlung: Qualitätsanforderungen werden definiert und quantifiziert, um vage Wünsche in überprüfbare Kriterien zu übersetzen. Dies schafft messbare Vorgaben für Aspekte wie Antwortzeiten oder Sicherheit, die für die spätere Abnahme entscheidend sind.

Phase 3: Dokumentation & Form (Die Ausarbeitung)
Das ermittelte Wissen wird aus den Köpfen der Stakeholder in eine professionelle Form gebracht, die für Entwickler und Tester verständlich ist. Vages Wissen wird in präzise Sprache und eindeutige Modelle transformiert, um die handwerkliche Qualität der Anforderungen zu sichern.

  • Modellierung: Komplexe Sachverhalte und Logiken werden durch standardisierte Notationen visuell dargestellt. Diese Modelle dienen als präziser Bauplan und helfen dabei, Logiklücken aufzudecken, die in reinem Fließtext oft übersehen werden.

  • Textuelle Spezifikation: Anforderungen werden in Dokumenten oder User Stories unter Nutzung von Templates und Satzschablonen syntaktisch korrekt formuliert. Parallel dazu wird ein Glossar aufgebaut, um eine einheitliche Terminologie sicherzustellen.

  • Sprachlicher Feinschliff: Ein linguistischer Qualitätscheck wird durchgeführt, um sprachliche Defekte wie Tilgungen, Verzerrungen oder Generalisierungen zu identifizieren. Ziel ist es, den Interpretationsspielraum der Dokumentation vollständig zu eliminieren.

Phase 4: Prüfung & Einigung (Die Qualitätssicherung)
Bevor eine Anforderung umgesetzt wird, muss sie validiert und abgestimmt sein. Es wird geprüft, ob das Dokumentierte dem Gewünschten entspricht, und Widersprüche werden bereinigt, um teure Fehlentwicklungen zu vermeiden.

  • Validierungsvorbereitung & Durchführung: Die Qualität der Anforderungen wird durch methodische Prüfungen wie Inspektionen oder Walkthroughs sichergestellt. Checklisten und perspektivenbasiertes Lesen kommen zum Einsatz, um Fehler systematisch zu finden.

  • Konfliktmanagement: Widersprüche, die in der Prüfung zutage treten, werden analysiert und durch Techniken wie Verhandlung oder Kompromiss gelöst. Dies schafft eine konsolidierte Basis und bereinigt Interessenkonflikte zwischen verschiedenen Stakeholdern.

  • Entscheidungsfindung & Priorisierung: Anforderungen werden nach Business Value, Risiko und Aufwand bewertet, um eine verbindliche Umsetzungsreihenfolge festzulegen. Auf dieser Basis wird die formale Abnahme durch die Stakeholder eingeholt.

Phase 5: Management & Lebenszyklus (Die Verwaltung)
Anforderungen werden über die gesamte Projektlaufzeit hinweg verwaltet, da sie sich stetig weiterentwickeln. In diesem Bereich wird die Komplexität gesteuert, Änderungen kontrolliert und der Übergang in den Betrieb vorbereitet.

  • Strukturierung & Verwaltung: Attribute und Sichten werden genutzt, um bei großen Mengen an Anforderungen den Überblick zu behalten. Dies stellt sicher, dass unterschiedliche Rollen genau die Informationen sehen, die für ihre Aufgaben relevant sind.

  • Nachvollziehbarkeit: Anforderungen werden untereinander und mit anderen Artefakten verknüpft, um ihre Herkunft und Umsetzung belegen zu können. Dies ist essenziell für Audits und um die Auswirkungen von Änderungen analysieren zu können.

  • Änderungsmanagement: Neue Wünsche und Änderungen werden in einem kontrollierten Prozess bewertet und entschieden. Durch Versionierung und Impact-Analysen wird sichergestellt, dass die Evolution des Systems geordnet verläuft.

  • Transition & Abschluss: Die Überführung des Systems in den Betrieb wird vorbereitet, inklusive der Datenmigration aus Altsystemen und der Erstellung von Schulungsunterlagen. Nach dem Go-Live wird das Projekt formal abgeschlossen.

3. Fragenkatalog

Nachdem das grobe Phasenmodell etabliert ist, tauchen wir nun in die operative Ebene ein. Dieser Abschnitt beschreibt für jede Unterphase, welche konkreten Aufgaben zu erledigen sind, welche Ergebnisse erwartet werden und warum dieser Schritt für den Gesamterfolg kritisch ist.

Phase 1: Fundament & Rahmenbedingungen

Diese Phase ist der "Projekt-Setup". Hier werden Entscheidungen getroffen, die schwer revidierbar sind. Fehler in dieser Phase führen oft zu methodischem Chaos oder rechtlichen Problemen im späteren Verlauf.

Prozess-Initialisierung (Das Vorgehensmodell)
Bevor die inhaltliche Arbeit beginnt, muss das Team definieren, wie es arbeiten möchte. Es wird festgelegt, ob ein klassisches Vorgehen (z. B. Lastenheft/Pflichtenheft nach Wasserfall) oder ein agiles Vorgehen (z. B. User Stories in Sprints nach Scrum) gewählt wird. Zudem werden die Rollen und Verantwortlichkeiten geklärt: Wer darf Anforderungen freigeben? Wer ist der "Owner" welcher Themengebiete? Diese Festlegungen verhindern Kompetenzstreitigkeiten und methodische Brüche.

Details

1.1 Prozess-Initialisierung (Operative Audit-Checkliste)

diagram-1-1-mindmap

A – Prozess-Modell & Taktung: Dieser Abschnitt klärt das grundlegende Vorgehensmodell (linear vs. iterativ) und die Synchronisation zwischen Requirements Engineering und Entwicklung. Er definiert die Länge von Zyklen sowie Meilensteine, um sicherzustellen, dass Anforderungen in der richtigen Granularität und rechtzeitig bereitstehen. Mehrwert: Verhindert „Scope Creep“ durch inkompatible Prozesse und minimiert Risiken durch frühe, vertikale Durchstiche statt theoretischer Konzepte.

B – Vertrag & Verbindlichkeit Hier wird die juristische Relevanz der Anforderungen und das Vertragsmodell (Festpreis vs. Time & Material) analysiert. Es wird festgelegt, wie präzise dokumentiert werden muss, um Missverständnisse und rechtliche Lücken zu vermeiden. Mehrwert: Schützt vor Margenverlusten durch unkontrollierte Änderungen („Scope Creep“) und sichert das Projekt gegen teure Nachforderungen („Claim Management“) ab.

C – Markt & Produktstrategie Dieser Bereich unterscheidet zwischen Individualsoftware und Marktprodukten und prüft die Validierung durch echte Nutzerdaten oder Beta-Tester. Zudem wird die Rolle des Product Owners und dessen Entscheidungsmacht bezüglich Budget und Marktanforderungen beleuchtet. Mehrwert: Stellt sicher, dass das Produkt auf echten Daten statt Meinungen basiert und verhindert, dass Einzelinteressen den Standardkern des Produkts verwässern.

D – Risiko, Safety & Security Es wird ermittelt, ob das System sicherheitskritisch (Safety) oder angriffsgefährdet (Security) ist und welche Compliance-Vorgaben gelten. Darauf basierend werden die Notwendigkeit formaler Methoden, lückenloser Traceability und spezifischer Bedrohungsanalysen festgelegt. Mehrwert: Vermeidet finanzielle Schäden oder Sicherheitsrisiken durch angemessene Testtiefe und garantiert die Auditierbarkeit des Entwicklungsprozesses.

E – Stakeholder & Umfeld Dieser Abschnitt analysiert die Verfügbarkeit, Entscheidungsmacht und geografische Verteilung der beteiligten Personen. Er deckt potenzielle Konflikte auf und klärt, wie das Feedback kanalisiert wird. Mehrwert: Verhindert Projektstillstand durch fehlende Entscheidungen oder Ressourcen und sorgt für effektive Kommunikation trotz verteilter Teams.

F – Team & Skills Hier wird die Methodenkompetenz und das Domänenwissen des Teams bewertet sowie die Zusammenarbeit zwischen RE und Entwicklung definiert. Es prüft auch, ob externe Dienstleister involviert sind und wie die Übergabe an diese geregelt ist. Mehrwert: Identifiziert frühzeitig Schulungsbedarfe und verhindert „Silo-Denken“, das zu Missverständnissen zwischen Fachbereich und Technik führt.

G – Dokumentation & Artefakte Es wird festgelegt, welche Dokumente zwingend geschuldet sind, welche Templates genutzt werden und wie Modelle zur Visualisierung komplexer Logik eingesetzt werden. Auch die Archivierungssicherheit der Daten wird hier thematisiert. Mehrwert: Erzwingt inhaltliche Vollständigkeit durch Struktur und sichert die langfristige Lesbarkeit und Wartbarkeit der Projektergebnisse.

H – Tooling & Verwaltung Dieser Bereich beschäftigt sich mit der Auswahl und Konfiguration des RE-Tools passend zum Prozess. Er definiert Pflichtfelder (Attribute) für Metriken und regelt das Versionierungs- und Änderungsmanagement. Mehrwert: Sorgt dafür, dass das Tool den Prozess unterstützt statt behindert, und ermöglicht eine transparente Nachvollziehbarkeit des Projektfortschritts.

I – Qualitätssicherung & Abnahme Hier werden die Kriterien für die formale Abnahme (Sign-off) und die „Definition of Ready“ festgelegt. Zudem wird geregelt, wie Tester frühzeitig („Shift-Left“) eingebunden werden, um Logikfehler zu finden. Mehrwert: Verhindert, dass schlechte Anforderungen in die Entwicklung gelangen, was teure Bugfixes und Verzögerungen vermeidet.

J – Governance & Improvement Abschließend wird geklärt, wie der Prozess überwacht, auditiert und kontinuierlich verbessert wird. Es definiert Regeln für Anpassungen (Tailoring) und stellt sicher, dass der Prozess auch bei Skalierung funktioniert. Mehrwert: Sichert die Akzeptanz des Vorgehens durch Anpassungsfähigkeit und bietet rechtliche Sicherheit bei Audits durch dokumentierte Abweichungen.

Nr. Frage Operative Implikation & Handlungsanweisung

A

PROZESS-MODELL & TAKTUNG

1

Ist der Gesamtprozess linear (Wasserfall) oder iterativ (Agil)?

Synchronisation: Prüfen Sie die Kompatibilität! Agile RE in einem Festpreis-Wasserfall-Vertrag führt zu massivem Scope-Creep. Definieren Sie Synchronisationspunkte (Synch-Points) zwischen RE und Dev.

2

Müssen Anforderungen zu Beginn feststehen oder ist ein Start mit Unschärfe möglich?

Cone of Uncertainty: Wenn Unschärfe erlaubt ist: Legen Sie einen expliziten Risk-Buffer im Budget an. Wenn nicht: Fordern Sie eine Vorstudie an, bevor die Umsetzung startet.

3

Können wir Anforderungen in Inkrementen liefern?

Slicing: Verbot von horizontalen Schichten (nur DB-Konzept). Fordern Sie vertikale Durchstiche ("Walking Skeleton"), um technische Risiken früh zu validieren.

4

Wie lang sind die Iterationszyklen (Sprints)?

Definition of Ready: Passen Sie die Granularität der Anforderungen an. Eine Anforderung muss in einen Sprint passen (INVEST-Kriterien). Wenn nicht → Split erzwingen.

5

Gibt es harte Meilensteine, die eine lineare Abarbeitung erzwingen?

Bottle-Neck: Identifizieren Sie Quality Gates (z.B. "Pflichtenheft-Abnahme Q3"). Planen Sie Rückwärts: Wann muss der "Freeze" sein, um das Gate zu schaffen?

6

Ist ein "Rolling Wave Planning" möglich?

Waste-Vermeidung: Detaillieren Sie Anforderungen max. 2 Sprints im Voraus. Alles andere ist Lagerhaltung (Waste), die veraltet.

7

Wie oft liefern wir Software an den Kunden aus?

Feedback-Loop: Bei seltenen Releases (1x Jahr): Planen Sie intensive Reviews und Prototypen ein, da das Markt-Feedback zu spät kommt.

8

Müssen wir Rückwärtskompatibilität im Prozess beachten?

Regression: Fügen Sie jeder Anforderung das Attribut "Breaking Change: Ja/Nein" hinzu. Erzwingen Sie Impact-Analysen für Altsysteme.

13

Nutzen wir Proof-of-Concepts (PoC) zur Anforderungsfindung?

Risk-First: Identifizieren Sie technisch riskante Anforderungen sofort. Bauen Sie einen "Spike" (techn. Prototyp) VOR der Spezifikation.

14

Ist das Projekt ein Forschungsprojekt?

Scope-Flexibilität: Wenn Forschung: Setzen Sie Time-Boxing statt Scope-Boxing. Ergebnis ist ein Erkenntnisgewinn, keine Software-Garantie.

33

Dürfen wir "Trial & Error" machen?

Fehlerkultur: Klären Sie: Ist ein "Fail" im Sprint akzeptabel? Wenn nein (Safety), müssen Reviews und Spezifikation massiv hochgefahren werden.

B

VERTRAG & VERBINDLICHKEIT

9

Dienen die Anforderungen als juristischer Vertrag?

Claim Management: Jedes Wort zählt. Vermeiden Sie schwammige Begriffe ("schnell", "schön"). Nutzen Sie Satzschablonen (Rupp/ISO). Jede Änderung erfordert einen Change Request (CR).

10

Welcher Detaillierungsgrad und welche Präzision sind notwendig?

Gap-Analyse: Prüfen Sie, wer liest. Wenn Offshore-Devs lesen: Pixelgenaue Specs und Pseudocode nötig. Wenn Senior-Devs vor Ort: High-Level reicht.

11

Welches Vertragsmodell liegt vor (Festpreis vs. Time & Material)?

Scope-Control: Bei Festpreis: Jede neue Anforderung muss gegen das ursprüngliche Angebot geprüft werden. "Scope Creep" ist der Margen-Killer Nr. 1.

12

Wie detailliert muss die Dokumentation für Dritte sein?

Deliverables: Listen Sie alle Dokumente auf, die nicht zur Entwicklung dienen (z.B. Admin-Handbuch, Revisionsbericht). Planen Sie dafür explizite Tasks ein.

15

Gibt es nicht verhandelbare Compliance-Vorgaben?

Non-Negotiables: Erstellen Sie eine Liste der "Muss"-Kriterien (Gesetze). Diese dürfen auch bei Zeitdruck nicht gestrichen werden (Definition of Done).

C

MARKT & PRODUKTSTRATEGIE

16

Handelt es sich um Individualsoftware oder ein Marktprodukt?

Quellen-Check: Bei Marktprodukten: Misstrauen Sie Einzelmeinungen. Fordern Sie Daten (Marktanalyse). Bei Individual: Fragen Sie den Auftraggeber direkt.

17

Gibt es einen "Product Owner", der den Markt vertritt?

Mandat: Prüfen Sie die Befugnis des PO. Darf er "Nein" sagen? Ein PO ohne Budgethoheit ist nur ein "Scribe" (Schreiberling).

18

Können wir Beta-Tester aus der Zielgruppe rekrutieren?

Validierung: Planen Sie eine "Closed Beta" ein. Feedback von echten Nutzern ist wertvoller als jedes Review.

19

Müssen wir Varianten für verschiedene Kundensegmente planen?

Konfiguration: Planen Sie Feature-Toggles oder Lizenzschlüssel im Datenmodell ein. Vermeiden Sie "Copy-Paste-Code" für Varianten.

20

Wie stark ist der Einfluss einzelner Großkunden?

Roadmap-Integrität: Markieren Sie "Key Account"-Wünsche separat. Verhindern Sie, dass Einzellösungen in den Standard-Core rutschen (Verwässerung).

21

Nutzen wir Fokusgruppen zur Anforderungsermittlung?

Bias-Check: Achten Sie darauf, nicht nur "Fans" zu befragen. Laden Sie kritische Nutzer ein.

22

Müssen wir Konkurrenzprodukte analysieren?

Benchmarking: Erstellen Sie eine Feature-Matrix der Konkurrenz. Definieren Sie das MVP basierend auf "Parity" oder "Killer-Feature".

23

Gibt es ein Kunden-Gremium (Customer Advisory Board)?

Erwartungsmanagement: Protokollieren Sie Zusagen im Board peinlich genau. Das sind oft politische Versprechen.

24

Wie erhalten wir Feedback aus dem Markt nach Release?

Analytics: Definieren Sie Telemetrie-Anforderungen (z.B. "Tracking Events") als NFRs. Ohne Daten kein "Data-Driven RE".

D

RISIKO, SAFETY & SECURITY

25

Handelt es sich um ein sicherheitskritisches System (Safety)?

K.O.-Kriterium: Prüfen Sie ISO 26262 / IEC 61508 Anwendbarkeit. Wenn ja: Formale Methoden und lückenlose Traceability sind zwingend. Keine Diskussion.

26

Geht es um kritische Infrastruktur (KRITIS)?

Verfügbarkeit: Planen Sie BCM-Szenarien (Notfallbetrieb) als Use Cases ein.

27

Welcher finanzielle Schaden droht bei Fehlern?

Test-Invest: Korrelieren Sie das Risiko mit der Testtiefe. Hochrisiko-Features brauchen Code-Audits und Pen-Tests.

28

Wie hoch ist das Security-Risiko (Datenschutz/Hacking)?

Threat Modeling: Führen Sie STRIDE-Analysen für jedes Feature durch. Definieren Sie "Abuse Cases" (Missbrauchsfälle).

29

Muss der Prozess auditiert werden?

Logbuch: Stellen Sie sicher, dass das RE-Tool manipulationssichere Änderungshistorien schreibt. Keine Word-Dokumente auf Sharepoint!

30

Welche Anforderungen bestehen an Traceability und Nachweisbarkeit?

Audit-Proof: Prüfen Sie stichprobenartig: Komme ich von der Anforderung zum Code und zum Test? Lücken sind Audit-Finding Nr. 1.

E

STAKEHOLDER & UMFELD

34

Wie hoch sind Verfügbarkeit und Commitment der Stakeholder?

Ressourcen-Check: Blocken Sie Kalenderslots für Reviews Wochen im Voraus. Wenn der Kunde keine Zeit hat, stoppen Sie den Sprint (Eskalation).

35

Wie sind Stakeholder und Team geografisch verteilt?

Kommunikation: Bei Verteilung: Führen Sie striktere schriftliche Abnahmen ein. "Zuruf" funktioniert remote/zeitversetzt nicht.

36

Sprechen alle Stakeholder dieselbe Sprache?

Glossar: Erstellen Sie ein zweisprachiges Glossar. Klären Sie Begriffe wie "Kunde" (Intern? Extern? Partner?) sofort.

37

Haben die Stakeholder Entscheidungsmacht?

Entscheidungsweg: Identifizieren Sie den "Sponsor". Wenn der PO immer erst Rücksprache halten muss, verdoppeln Sie die Durchlaufzeiten im Plan.

38

Wie gut kennen die Stakeholder ihre eigenen Anforderungen?

Methodenwahl: Wenn Kunde unsicher: Nutzen Sie Prototyping/Mockups statt Text. Text wird oft falsch interpretiert.

39

Gibt es Konflikte zwischen Stakeholder-Gruppen?

Konfliktlösung: Dokumentieren Sie Entscheidungen schriftlich ("Decision Log"). Lassen Sie Konflikte nicht schwelen.

40

Wie technikaffin sind die Stakeholder?

Artefakte: Zeigen Sie dem Fachbereich keine UML-Klassendiagramme. Nutzen Sie Wireframes oder Prozessflüsse (BPMN einfach).

41

Vertrauen die Stakeholder dem Entwicklungsteam?

Reporting: Bei Misstrauen: Erhöhen Sie die Transparenz (Jira-Zugang, Daily Demos), um "Kontrollwahn" vorzubeugen.

42

Wie viele Stakeholder müssen eingebunden werden?

Kanalisierung: Benennen Sie "Key User" als Sprachrohr. Verhindern Sie, dass 50 Leute direkt Anforderungen einwerfen.

F

TEAM & SKILLS

43

Wie hoch ist die RE-Methodenkompetenz des Teams?

Enablement: Wenn Kompetenz fehlt: Bereitstellung von Templates und Checklisten. Coaching on the Job einplanen.

44

Kennt das Team die Anwendungsdomäne?

Onboarding: Planen Sie "Domain-Bootcamps" ein. Entwickler müssen das Business verstehen, nicht nur den Code.

45

Wie stabil ist die Teamzusammensetzung?

Wissenssicherung: Bei hoher Fluktuation: Dokumentation muss "selbsterklärend" sein. Video-Aufzeichnungen von Reviews nutzen.

46

Arbeiten wir mit externen Dienstleistern zusammen?

Schnittstelle: Definieren Sie eine formale "Definition of Ready" für die Übergabe an Externe. Unklare Specs kosten hier bares Geld.

47

Wie groß ist das Entwicklungsteam?

Skalierung: Ab >2 Teams: Einführung von Sync-Meetings (SoS). Gemeinsames Backlog priorisieren, um Doppelarbeit zu vermeiden.

48

Sind Requirements Engineer und Entwickler getrennte Rollen?

Silo-Alarm: Sorgen Sie für direkten Austausch. Verhindern Sie "Stille Post" über Dokumente. REs müssen in Dailies dabei sein.

49

Gibt es einen dedizierten Requirements Manager?

Verantwortung: Benennen Sie einen "Process Owner". Wenn sich niemand um den Prozess kümmert, verfällt er (Entropie).

50

Wie hoch ist das Budget für RE-Aktivitäten?

Effizienz: Priorisieren Sie RE-Aufwand nach Risiko. Triviales (Login) braucht kaum RE, Komplexes (Steuerberechnung) braucht viel.

G

DOKUMENTATION & ARTEFAKTE

51

Welche Dokumente müssen zwingend erstellt werden?

Lieferliste: Erstellen Sie eine Checkliste aller geschuldeten Dokumente. Prüfen Sie diese vor jedem Release.

52

Nutzen wir standardisierte Templates?

Qualität: Erzwingen Sie Nutzung von Vorlagen. Freitext führt zu fehlenden Inhalten (z.B. fehlende Fehlerbehandlung).

53

In welcher Sprache wird dokumentiert?

Konsistenz: Legen Sie die Projektsprache fest. Denglisch vermeiden. Glossar ist die Referenz.

54

Müssen wir Modelle (Diagramme) erstellen?

Visualisierung: Komplexe Logik MUSS visualisiert werden (Aktivitätsdiagramm). Textwüsten werden nicht verstanden.

55

Wie lange müssen die Artefakte aufbewahrt werden?

Archivierung: Nutzen Sie PDF/A oder ReqIF-Exporte für Langzeitarchivierung. Proprietäre Tool-Datenbanken sind in 10 Jahren oft unlesbar.

H

TOOLING & VERWALTUNG

56

Welches Tool wird zur Verwaltung genutzt?

Fit-Gap: Das Tool muss den Prozess unterstützen. Zwingen Sie kein Agile-Team in ein starres Wasserfall-Tool (und umgekehrt).

57

Gibt es ein zentrales Glossar?

Pflicht: Richten Sie das Glossar in Woche 1 ein. Sorgen Sie dafür, dass es gepflegt und verlinkt wird.

58

Wie werden Anforderungen versioniert?

Baseline: Setzen Sie vor jedem Release/Sprint eine Baseline. Sie müssen wissen, was sich seitdem geändert hat.

59

Welche Attribute müssen gepflegt werden?

Pflichtfelder: Konfigurieren Sie das Tool so, dass Prio und Status Pflichtfelder sind. Leere Attribute machen Metriken wertlos.

60

Wie gehen wir mit Änderungen während der Entwicklung um?

Change-Prozess: Definieren Sie: Darf im Sprint geändert werden? Wenn ja → Abbruch oder Tausch von Storys (Scope Neutral).

I

QUALITÄTSSICHERUNG & ABNAHME

31

Wie formal müssen Freigaben erfolgen?

Sign-off: Klären Sie: Reicht "Daumen hoch" in Jira oder muss ein PDF unterschrieben werden? Letzteres braucht Vorlaufzeit.

32

Sind formale Methoden (Mathematik) erforderlich?

Präzision: Bei Safety-Code: Formale Spezifikation nutzen. Natürliche Sprache ist immer mehrdeutig.

61

Wer priorisiert die Anforderungen?

Single Point of Truth: Nur EINE Person (PO) darf priorisieren. Wenn Stakeholder streiten, entscheidet der PO.

62

Wie messen wir den Fortschritt im RE?

KPI: Messen Sie "Ready for Dev"-Vorrat. Wenn der Vorrat auf 0 sinkt, steht die Entwicklung bald still.

64

Wie stellen wir die Qualität der Anforderungen sicher?

QS: 4-Augen-Prinzip für JEDE Anforderung. Schlechte Anforderungen führen zu Bugs und teuren Fixes.

65

Wann gilt eine Anforderung als "fertig" für die Entwicklung?

DoR: Hängen Sie die "Definition of Ready" Checkliste sichtbar auf. Keine Story geht in den Sprint ohne DoR.

66

Wie binden wir das Test-Team ein?

Shift-Left: Tester müssen die Anforderung reviewen, BEVOR Code geschrieben wird. Sie finden Logikfehler am besten.

J

GOVERNANCE & IMPROVEMENT

63

Gibt es regelmäßige Prozess-Reviews (Retrospektiven)?

KVP: RE-Probleme in der Retro ansprechen. "Warum waren die Anforderungen unklar?" → Prozess anpassen.

68

Wer gibt den Prozess frei (Process Owner)?

Audit: Lassen Sie das Vorgehensmodell vom QM abzeichnen. Das ist Ihre Absicherung bei Audit-Abweichungen.

69

Darf das Team den Prozess selbst anpassen (Tailoring)?

Rahmen: Definieren Sie, was angepasst werden darf und was "Gesetz" ist (z.B. Safety-Checks).

70

Wie dokumentieren wir Prozessabweichungen?

Rechtfertigung: Wenn Sie vom Standard abweichen, dokumentieren Sie das "Warum" für den Auditor.

71

Skaliert der Prozess für große Projekte?

Abhängigkeiten: Bei Skalierung: Führen Sie "Dependency Boards" ein, um Blockaden zwischen Teams zu managen.

72

Ist der Prozess für kleine Änderungen leichtgewichtig genug?

Fast-Lane: Definieren Sie einen "Express-Prozess" für Typos und kleine Bugs. Volles RE-Brett wäre hier Verschwendung.

73

Wie schnell können wir den Prozess ändern?

Agilität: Der Prozess darf kein statisches PDF sein. Er muss leben (Wiki) und anpassbar sein.

74

Nutzen wir Best Practices aus der Branche?

Orientierung: Nutzen Sie IREB/IIBA Standards als Basis, aber passen Sie sie an. Nicht alles neu erfinden.

75

Haben wir den Prozess pilotiert?

Test: Rollen Sie einen neuen RE-Prozess nie sofort auf alle aus. Pilotieren Sie mit einem freundlichen Team.

76

Passt der Prozess zur Unternehmenskultur?

Akzeptanz: Ein bürokratischer Prozess in einem Startup wird ignoriert werden. Passen Sie die Formalität an.

77

Ist der Prozess für neue Mitarbeiter verständlich dokumentiert?

Onboarding-Kit: Erstellen Sie ein "RE-Playbook". Neue Mitarbeiter müssen an Tag 1 wissen, wie sie arbeiten sollen.

Infrastruktur-Setup (Die Werkzeuglandschaft)
Requirements Engineering erzeugt eine große Menge an Daten. In diesem Schritt wird die technische Umgebung geschaffen, um diese Daten zu verwalten. Es wird entschieden, welches Tool (z. B. Jira, Confluence, DOORS, Enterprise Architect) genutzt wird. Entscheidend ist hierbei nicht nur die Installation, sondern die Konfiguration: Welche Attributfelder gibt es? Wer bekommt welche Zugriffsrechte? Wie werden Templates hinterlegt? Ein sauberes Setup spart später tausende Stunden manueller Pflege.

Details

1.2 Infrastruktur & Tool-Einführung (Lückenlose operative Checkliste)

diagram-1-1-mindmap

A – Strategie & Nutzungsszenario Dieser Abschnitt fordert die Klärung der konkreten „Pain Points“ und Probleme, die das neue Tool lösen soll, statt Technologie als Selbstzweck einzuführen. Zudem wird der Fokus (Verwaltung vs. Modellierung) definiert und die Grundsatzentscheidung zwischen spezialisierten ALM-Tools und flexiblen Office-Lösungen getroffen. Mehrwert: Verhindert Fehlinvestitionen, indem das Tool gezielt auf echte Prozessprobleme und Nutzergruppen ausgerichtet wird.

B – Infrastruktur & Architektur Hier werden technische K.O.-Kriterien wie Cloud vs. On-Premise (Datenschutz), Betriebssystem-Kompatibilität und Hardware-Anforderungen geprüft. Auch Aspekte wie Performance unter Last, Datensicherung (Backup/Restore) und mobile Nutzbarkeit werden geklärt. Mehrwert: Garantiert die technische Integrierbarkeit in die Unternehmens-IT, die Einhaltung von DSGVO-Vorgaben und die operative Stabilität.

C – Integration & Schnittstellen Dieser Bereich prüft die Vernetzung mit der bestehenden Toolchain (z. B. Jira, DevOps) und die Unterstützung von Industriestandards für den Datenaustausch. Zudem wird die Importfähigkeit von Office-Dokumenten und die Automatisierbarkeit über APIs bewertet. Mehrwert: Vermeidet Datensilos und manuellen Übertragungsaufwand („Copy-Paste“), was Fehler reduziert und die Durchgängigkeit (Traceability) sichert.

D – Kernfunktionen RE Es wird detailliert geprüft, ob das Tool essenzielle RE-Methoden unterstützt: von Modellierung (UML) über Baselining und Historienverwaltung bis hin zum Variantenmanagement. Auch Funktionen für Zusammenarbeit, Workflows und digitale Signaturen werden hier evaluiert. Mehrwert: Stellt sicher, dass das Tool methodisch mächtig genug ist, um komplexe Anforderungen revisionssicher und effizient zu verwalten.

E – Usability & Teamarbeit Hier steht die Nutzererfahrung im Fokus: Unterstützt das Tool gleichzeitiges Arbeiten (Concurrency), ist die Suche leistungsfähig und die Oberfläche intuitiv? Auch die visuelle Darstellung von Abhängigkeiten und die Offline-Fähigkeit werden betrachtet. Mehrwert: Sichert die Akzeptanz bei den Anwendern, da schlechte Usability oft zu Boykott oder Umgehungslösungen führt.

F – Kosten & Lizenzen Neben den reinen Lizenzkosten (Initial vs. Laufend) werden hier das passende Lizenzmodell (Named vs. Floating) und versteckte Kosten für Datenbanken oder Plugins analysiert. Auch interne Aufwände für Administration und externe Beratungskosten fließen ein. Mehrwert: Ermöglicht eine realistische Berechnung der Total Cost of Ownership (TCO) und verhindert Budgetüberschreitungen durch versteckte Gebühren.

G – Anbieter & Zukunft Dieser Abschnitt bewertet die Stabilität und Zukunftssicherheit des Herstellers sowie die Qualität des Supports. Referenzkunden und die Reaktionsgeschwindigkeit bei Sicherheitslücken dienen als Indikatoren für Verlässlichkeit. Mehrwert: Minimiert das Risiko, auf ein „totes Pferd“ zu setzen, und sichert langfristigen Support für eine kritische Infrastrukturkomponente.

H – Pilot & Entscheidung Vor dem Kauf wird das Tool in einem Pilotprojekt mit echten Daten und einem gemischten Team aus Fans und Skeptikern getestet. Klare Erfolgskriterien (KPIs) entscheiden über Go oder No-Go. Mehrwert: Validiert Werbeversprechen in der Realität und verhindert teure Fehlkäufe durch fundierte Praxiserfahrung vor dem Rollout.

I – Customizing & Reporting Es wird geklärt, wie stark das Tool oder der Prozess angepasst werden muss und ob notwendige Vorlagen importiert werden können. Zudem wird die Flexibilität der Berichterstellung und die Verfügbarkeit von Management-Dashboards geprüft. Mehrwert: Sorgt dafür, dass der Output (z. B. Pflichtenhefte) den Unternehmensstandards entspricht und das Management jederzeit Transparenz hat.

J – Migration Dieser Bereich plant den Umzug von Altdaten: Strategien für Bereinigung, automatisierten Import vs. manuelle Erfassung und Validierung werden festgelegt. Alte Projekte werden oft archiviert statt migriert. Mehrwert: Verhindert, dass Datenmüll („Garbage In, Garbage Out“) das neue System verstopft, und sichert den Erhalt historischer Daten.

K – Schulung & Enablement Hier wird das rollenspezifische Schulungskonzept definiert, inklusive Train-the-Trainer-Ansätzen und Self-Service-Materialien. Ein „Tool-Führerschein“ kann als Voraussetzung für Schreibrechte dienen. Mehrwert: Befähigt Mitarbeiter zur korrekten Nutzung und verhindert Frust sowie Datenqualitäts-Probleme durch Fehlbedienung.

L – Betrieb & Governance Es werden Verantwortlichkeiten (Tool Owner, Admin) und Prozesse für Support, Updates und Notfälle (BCM) geregelt. Regelmäßige Audits verhindern Wildwuchs in der Datenstruktur. Mehrwert: Sichert den geordneten Dauerbetrieb und verhindert, dass das Tool durch unkontrollierte Konfigurationen unbenutzbar wird (Entropie).

M – Change Management & Soft Skills Dieser Abschnitt adressiert den menschlichen Faktor: Umgang mit Widerständen, Einbindung von Promotoren und kulturelle Passung. Die Kommunikation des Nutzens („Why?“) steht im Vordergrund. Mehrwert: Erhöht die Erfolgsquote der Einführung massiv, da Tool-Projekte meist an der Kultur scheitern, nicht an der Technik.

N – Sonstige Prüfpunkte Abschließend werden rechtliche und spezielle Themen wie Revisionssicherheit, Mitbestimmung des Betriebsrats, Zugriffsschutz (2FA) und KI-Unterstützung geprüft. Mehrwert: Deckt kritische Compliance- und Sicherheitslücken ab, die sonst zu rechtlichen Problemen führen könnten.

Nr. Frage Operative Implikation & Handlungsanweisung

A

STRATEGIE & NUTZUNGSSZENARIO

1

Welche konkreten Probleme im aktuellen RE-Prozess soll das Werkzeug lösen?

Pain Points: Kein "Tool um des Tools willen". Das Problem (z.B. "Versionierung in Word scheitert") muss klar benannt sein, sonst fehlt die Messlatte für den Erfolg.

2

Welche RE-Aktivitäten sollen primär unterstützt werden?

Scope: Fokus definieren! Ein Tool, das für "Verwaltung" optimiert ist, taugt oft nichts für "kreative Modellierung". Priorisierung ist Pflicht.

3

Soll das Tool spezialisiert oder eine Standard-Office-Lösung sein?

Grundsatzentscheidung: Office ist flexibel aber unkontrollierbar. Spezialtools (ALM) erzwingen Struktur. Entscheidung beeinflusst den Schulungsaufwand massiv.

4

Welche Benutzergruppen werden das Tool nutzen?

Mengengerüst: Nicht raten! Anzahl REs (Schreiben) vs. Entwickler (Lesen) vs. Management (Report) exakt zählen für Lizenzplanung.

B

INFRASTRUKTUR & ARCHITEKTUR

5

Ist eine Cloud-Lösung (SaaS) zulässig oder ist On-Premise Pflicht?

K.O.-Kriterium: Datenschutzbeauftragten vor der Tool-Suche fragen. SaaS in USA ist oft ein Showstopper für deutsche Firmendaten.

6

Welche Betriebssysteme müssen auf Client-Seite unterstützt werden?

Kompatibilität: Wenn Entwickler Linux nutzen, darf das Tool kein Windows-Only-Client sein. Web-Clients sind hier der sicherste Weg.

7

Welche Anforderungen stellt das Tool an die Server-Hardware?

Sizing: RAM/CPU-Bedarf beim IT-Betrieb prüfen. Passt das in die vorhandene Virtualisierungsumgebung?

8

Welche Datenbank wird im Hintergrund benötigt?

Tech-Stack: Bringt das Tool seine eigene DB mit (Wartungsaufwand!) oder nutzt es die Firmen-Oracle/SQL-Server (Lizenzkosten!)?

9

Wie erfolgt die Authentifizierung der Nutzer (SSO/LDAP)?

Security: "Noch ein Passwort" wird vergessen. Anbindung an Active Directory / SSO ist Pflicht für User-Akzeptanz und Sicherheit.

10

Ist das Tool performant genug für unsere Datenmenge?

Skalierung: Herstellerangaben trauen ist gut, Lasttest ist besser. Teste mit 50.000 Dummy-Items. Wenn die Suche >2 Sek braucht → Ablehnen.

11

Wie erfolgt das Backup und Restore der Tool-Daten?

Disaster Recovery: Prüfen: Können wir einzelne gelöschte Objekte wiederherstellen oder nur die ganze Datenbank von gestern (Datenverlust für alle)?

12

Benötigt das Tool eine Client-Installation oder läuft es im Browser?

Rollout: Fat-Clients erfordern Softwareverteilung durch IT (teuer/träge). Zero-Footprint (Browser) ist operativ immer zu bevorzugen.

13

Ist das Tool auch mobil (Tablet/Smartphone) nutzbar?

Mobilität: Wenn POs im Zug freigeben sollen, muss das UI responsiv sein. Test auf iPad durchführen.

14

Wie hoch ist die Verfügbarkeit des Tools garantiert (SLA)?

Business Continuity: Vertragliche Pönale bei Ausfall vereinbaren. 99,5% Verfügbarkeit sind fast 2 Tage Ausfall im Jahr!

15

Wo liegen die Daten bei einer Cloud-Lösung?

Datenschutz: Serverstandort muss vertraglich fixiert sein (z.B. Frankfurt/EU), um DSGVO-Probleme zu vermeiden.

16

Ist die Verbindung verschlüsselt (HTTPS/TLS)?

Security: Zugriff darf technisch nur über gesicherte Kanäle möglich sein. Zertifikatsverwaltung einplanen.

C

INTEGRATION & SCHNITTSTELLEN

17

Welche Schnittstellen zu anderen Tools sind zwingend?

Toolchain: Anforderungen müssen ohne Abtippen nach Jira/DevOps fließen. Synchronisation muss robust gegen Konflikte sein.

18

Unterstützt das Tool den Standard ReqIF (Requirements Interchange Format)?

Austausch: Zwingend, wenn Lastenhefte mit Lieferanten/Kunden ausgetauscht werden. Einzig funktionierender Industriestandard.

19

Können Daten aus Office (Word/Excel) importiert werden?

Realität: Kunden schicken Word. Der Import-Parser muss Überschriften/Tabellen sauber erkennen, sonst droht Tagelanges Copy-Paste.

20

Gibt es eine offene API (REST/SOAP) für Eigenentwicklungen?

Automatisierung: Ohne API keine eigenen Reports oder Skripte. API-Doku technisch prüfen lassen.

21

Wie integriert sich das Tool in die Versionsverwaltung (Git/SVN)?

DevOps: Traceability bis in den Code. Commit-Messages sollten idealerweise Tool-IDs referenzieren und verlinken.

D

KERNFUNKTIONEN RE

22

Unterstützt das Tool Modellierung (UML/BPMN/SysML)?

Methodik: Native Diagramme sind besser als Bild-Uploads, da Elemente im Diagramm verlinkbar sind.

23

Können wir eigene Attribute für Anforderungen definieren?

Flexibilität: Wir brauchen Felder wie "Rechtliche Relevanz" oder "Abnahme-Status". Admin muss das ohne Coding anpassen können.

24

Unterstützt das Tool Basislinien (Baselining)?

Release-Management: Absolut kritisch. Wir müssen den Scope "Release 1.0" einfrieren können, um Änderungen im nächsten Release sauber abzugrenzen.

25

Wie wird die Historie von Änderungen dargestellt?

Audit-Trail: Diff-View (Was war vorher/nachher?) auf Feldebene ist Pflicht. "Geändert am…​" reicht nicht.

26

Lassen sich Verfolgbarkeitsbeziehungen (Traces) einfach erstellen?

Usability: Wenn Verlinken mehr als 2 Klicks kostet oder Drag&Drop fehlt, wird die Traceability nicht gepflegt.

27

Bietet das Tool eine grafische Traceability-Analyse?

Impact Analysis: Visualisierung (Baum/Netz) ist nötig, um bei Änderungen sofort alle betroffenen Downstream-Artefakte zu sehen.

28

Können wir Dokumente (PDF/Word) aus dem Tool generieren?

Deliverables: Der Export muss CI-konform sein (Firmenlogo, Layout) und unterschriftsreif aus dem Tool kommen.

29

Unterstützt das Tool Variantenmanagement?

Produktlinien: Können wir Anforderung A in Projekt X und Y nutzen, aber in Y leicht abwandeln (Branching)?

30

Gibt es eine Kommentar- und Diskussionsfunktion?

Kollaboration: Diskussionen gehören an das Objekt ("@User: bitte prüfen"), nicht in E-Mails.

31

Können Workflows (z.B. Freigabe) im Tool abgebildet werden?

Governance: Das Tool muss verhindern, dass Status "Freigegeben" ohne Review gesetzt wird (State Enforcement).

32

Unterstützt das Tool digitale Signaturen (FDA Part 11)?

Compliance: In regulierten Branchen (MedTech/Automotive) reicht ein Klick nicht. Re-Authentifizierung bei Unterschrift nötig.

33

Ermöglicht das Tool das Wiederverwenden von Anforderungen?

Effizienz: Bibliotheks-Konzept prüfen. Kopieren ist schlecht, Referenzieren ist gut.

34

Gibt es ein integriertes Glossar?

Qualität: Automatische Hervorhebung definierter Begriffe im Text verhindert Missverständnisse.

35

Lassen sich Attribute berechnen?

Automation: Z.B. Prio = Wichtigkeit * Risiko. Spart manuelle Pflege und Rechenfehler.

36

Unterstützt das Tool Branching & Merging von Anforderungen?

Parallelentwicklung: Notwendig, wenn Version 2.0 entwickelt wird, während Version 1.1 noch Bugfixes bekommt.

37

Können wir Testfälle direkt im Tool verwalten?

Test: Wenn ja, spart das Schnittstellen. Wenn nein, ist die Integration zum Test-Tool (siehe 17) umso wichtiger.

E

USABILITY & TEAMARBEIT

38

Muss das Tool kollaboratives Arbeiten (gleichzeitiger Zugriff) unterstützen?

Concurrency: Sperrt das Tool das ganze Dokument, wenn einer liest? No-Go. "Google-Docs"-Feeling ist heute Standard.

39

Wie intuitiv ist die Benutzeroberfläche (Usability)?

Akzeptanz: Wenn es aussieht wie Windows 95 oder 10 Klicks für ein Item braucht, wird es boykottiert.

40

Wie gut ist die Suche im Tool?

Findbarkeit: Volltextsuche über Attribute, Texte und Anhänge (!). Fuzzy-Search (Synonyme) ist ein Plus.

41

Unterstützt das Tool grafische Auswirkungsanalysen?

Visualisierung: Klick auf Anforderung → Zeige alle Testfälle. Muss interaktiv sein.

42

Kann man Offline arbeiten und später synchronisieren?

Außendienst: Kritisch für Arbeit beim Kunden ohne Netz. Sync-Konflikt-Lösung testen!

43

Fördert das Tool die Kommunikation oder verhindert es sie?

Soft-Skill: Gefahr: "Ich habe es ins Tool geschrieben" ersetzt das Gespräch. Prozess muss Kommunikation fordern.

44

Ist die Benutzeroberfläche modern und ansprechend?

Joy of Use: Veraltete UIs senken die Motivation und erhöhen die "gefühlt" benötigte Zeit.

45

Ist das Tool in der Muttersprache der Nutzer verfügbar?

Sprache: Bei internationalen Teams Englisch, aber in DACH oft Deutsch gefordert (Betriebsrat/Fachbereich).

F

KOSTEN & LIZENZEN

46

Wie hoch sind die Lizenzkosten (Initial vs. Laufend)?

TCO: Vorsicht bei günstigen Einstiegspreisen und hohen Wartungsgebühren ("Hockey Stick").

47

Welches Lizenzmodell passt zu uns (Named User vs. Floating)?

Optimierung: REs = Named. Entwickler/Leser = Floating oder Token. Falsches Modell verbrennt Budget.

48

Gibt es versteckte Kosten (z.B. für Datenbank, Plugins)?

Kostenwahrheit: Braucht man für den Jira-Connector ein Extra-Plugin? Kostet die Oracle-DB extra?

49

Was kosten externe Berater für die Einführung?

Setup: Realistisch 10-20 Tage Consulting für Konfiguration und Migration einplanen.

50

Wie hoch sind die internen Kosten für die Betreuung?

Admin: Mindestens 0.5 FTE (Full Time Equivalent) dauerhaft für Admin/Support einplanen.

51

Werden Lizenzen regelmäßig überprüft?

Controlling: Prozess für "Harvesting" (Einsammeln) ungenutzter Lizenzen etablieren.

G

ANBIETER & ZUKUNFT

52

Wie zukunftssicher ist der Hersteller?

Risiko: Wie groß ist die Community? Nischen-Tools können aufgekauft oder eingestellt werden.

53

Wie gut ist der Support des Herstellers?

Hilfe: Reaktionszeit testen! Gibt es deutschsprachigen Support oder nur ein Forum?

54

Gibt es Referenzkunden in unserer Branche?

Validierung: Referenzbesuch machen. "Wie nutzt ihr das Tool wirklich?" (Ungeschminkte Wahrheit).

55

Wie schnell reagiert der Hersteller bei Sicherheitslücken?

Security: Patch-Policy prüfen. Kritische CVEs müssen binnen 48h gefixt sein.

H

PILOT & ENTSCHEIDUNG

56

Erfüllt das Tool alle Muss-Kriterien unserer Kriterienliste?

Auswahl: Keine Kompromisse bei Muss-Kriterien (z.B. ReqIF, Sprache, OS).

57

In welchem Pilotprojekt testen wir das Tool zuerst?

Test: Kleines, unkritisches Projekt wählen (Sandbox), aber mit echten Daten.

58

Wer sind die Teilnehmer des Pilotprojekts?

Team: Mix aus "Nerds" (Fans) und Skeptikern wählen, um realistisches Feedback zu kriegen.

59

Welche Erfolgskriterien gelten für den Piloten?

KPIs: Vorher definieren: "Wenn wir 20% Zeit bei Traceability sparen, kaufen wir."

60

Wie sammeln wir Feedback aus dem Piloten?

Lernen: Wöchentliche Retrospektiven. Feedback muss in Konfiguration einfließen.

61

Wie lange soll die Pilotphase dauern?

Zeitplan: Mindestens 3 Monate, um einen Zyklus (Anlegen bis Abnahme) durchzuspielen.

I

CUSTOMIZING & REPORTING

62

Muss das Tool an unsere Prozesse angepasst werden (Customizing)?

Aufwand: Standard nutzen ist billig, Anpassen ist teuer (und erschwert Updates). Gap-Analyse machen.

63

Müssen wir unsere Prozesse an das Tool anpassen?

Change: Oft besser, den Prozess an das Tool anzupassen als umgekehrt ("Best Practice" des Tools nutzen).

64

Gibt es Vorlagen/Templates, die wir importieren müssen?

Start: Lastenheft-Struktur (z.B. ISO 29148) als Template hinterlegen. Leere Blätter lähmen.

65

Wie flexibel sind die Berichte anpassbar?

Output: Können wir Fonts, Farben und Tabellenbreiten im PDF genau steuern? Wichtig für Kundenakzeptanz.

66

Gibt es ein Dashboard für Projektkennzahlen?

Sichtbarkeit: Management braucht Ampeln und Charts. Müssen konfigurierbar sein (Drill-Down).

J

MIGRATION

67

Wie migrieren wir die Altdaten (Legacy Data)?

Strategie: Big Bang oder schleichende Migration? Skripte vs. Manuell? Aufwände werden meist unterschätzt.

68

Müssen die Altdaten bereinigt werden?

Hygiene: "Garbage In, Garbage Out". Vor Import veraltete Anforderungen löschen/archivieren.

69

Ist ein manueller Übertrag oder ein automatischer Import sinnvoller?

ROI: Für <500 Anforderungen lohnt kein Skript. Studenten/Praktikanten einsetzen.

70

Wie stellen wir sicher, dass beim Import nichts verloren geht?

Validierung: Vergleichs-Bericht (Source vs. Target count). Stichprobenartige Textprüfung.

71

Werden abgeschlossene Projekte auch migriert?

Archiv: Nein! Alte Projekte als PDF archivieren ("Read Only"). Nur laufende Projekte migrieren.

K

SCHULUNG & ENABLEMENT

72

Welches Schulungskonzept brauchen wir?

Rollen: Admin (Technik), RE (Methodik + Tool), Leser (Navigation). One-size-fits-all funktioniert nicht.

73

Wer führt die Schulungen durch (Hersteller oder Intern)?

Train-the-Trainer: Hersteller schult Key-User, diese schulen intern (bessere Akzeptanz, günstiger).

74

Gibt es Online-Tutorials oder Handbücher?

Self-Service: Kurze Videos ("Wie erstelle ich einen Trace?") im Wiki. Niemand liest 200 Seiten PDF.

75

Sind die Schulungen verpflichtend?

Policy: "Tool-Führerschein". Schreibrechte erst nach Schulung. Verhindert Datenmüll.

76

Wie unterstützen wir User nach der Schulung (Coaching)?

Nachhaltigkeit: "Floor-Walking" oder offene Sprechstunde in den ersten Wochen nach Go-Live.

L

BETRIEB & GOVERNANCE

77

Wer ist der Tool-Verantwortliche (Tool Owner) im Unternehmen?

Verantwortung: Es braucht einen "Kümmerer". Ohne Owner verkommt das Tool.

78

Wer darf das Tool konfigurieren (Admin)?

Governance: Restriktiv halten! Wenn jeder Attribute anlegen darf, entsteht Chaos. Zentraler Admin ist Pflicht.

79

Wie gehen wir mit neuen Feature-Updates des Herstellers um?

Wartung: Updates erst auf Testsystem prüfen (Regressionstests eigener Skripte/Reports).

80

Wie ist der Support-Prozess für User geregelt (1st Level)?

Support: Key-User als erste Anlaufstelle. IT-Helpdesk nur für technische Störungen.

81

Gibt es Nutzungsrichtlinien für das Tool?

Regeln: "Keine personenbezogenen Daten in Kommentaren". Naming-Conventions definieren.

82

Wie messen wir die Akzeptanz des Tools?

Feedback: Umfrage nach 6 Monaten. Nutzungsstatistiken (aktive User) prüfen.

83

Wie gehen wir mit Performance-Problemen um?

Operations: Monitoring einrichten. Eskalationspfad zum Hersteller klären.

84

Gibt es ein Notfallkonzept bei Tool-Ausfall?

BCM: "Papier-Notfallplan". Wie arbeiten wir weiter, wenn das Tool 3 Tage weg ist?

85

Wie verhindern wir „Wildwuchs“ in der Datenstruktur?

Qualität: Vierteljährliches Audit der Attribute und Ordnerstrukturen durch Tool-Owner.

86

Wann evaluieren wir das Tool erneut (Exit-Strategie)?

Strategie: Fixer Termin in 3-5 Jahren. Passt das Tool noch zum Prozess?

M

CHANGE MANAGEMENT & SOFT SKILLS

87

Wie groß ist der interne Widerstand gegen das neue Tool?

Psychologie: Widerstand ist normal. Lauteste Kritiker ernst nehmen und einbinden.

88

Haben wir Promotoren (Fans) im Team?

Ambassadors: Begeisterte User finden und als Multiplikatoren nutzen.

89

Passt das Tool zur Arbeitsweise der Teams (Agil vs. Klassisch)?

Kultur: Ein starres Formalismus-Tool wird ein agiles Team ausbremsen und sabotieren.

90

Wird das Tool als „Überwachungsinstrument“ wahrgenommen?

Angst: Klarstellen: Es geht um Produktqualität, nicht um Mitarbeiter-Kontrolle (Betriebsrat!).

91

Wie gehen wir mit Frust in der Anfangsphase um?

Erwartungsmanagement: "Productivity Dip" ankündigen. Frustkanäle bereitstellen.

92

Feiern wir den Go-Live des Tools?

Marketing: Positives Event draus machen. Nicht nur "eine E-Mail von der IT".

93

Haben wir den Nutzen des Tools klar kommuniziert?

Sinn: "Why?" erklären. "Wir machen das, damit ihr weniger Copy-Paste-Arbeit habt."

N

SONSTIGE PRÜFPUNKTE

94

Ist das Tool revisionssicher?

Compliance: Löschen darf nicht spurlos möglich sein (Soft-Delete).

95

Wie werden Zugriffsrechte verwaltet?

RBAC: Rollenmatrix erstellen (Wer darf was?). Komplexität gering halten.

96

Gibt es eine 2-Faktor-Authentifizierung (2FA)?

Security: Bei Cloud-Zugriff von außen zwingend erforderlich.

97

Wurde der Betriebsrat eingebunden?

Recht: Wenn Auswertungen über User möglich sind → Mitbestimmungspflichtig!

98

Gibt es eine KI-Unterstützung im Tool?

Innovation: Nice-to-have. Automatische Prüfung auf passive Sätze (Quality Gate).

Kontext-Abgrenzung (System & Umgebung)
Hier wird der Scope definiert. Wir ziehen eine harte Linie zwischen dem "System" (dem Teil, den wir gestalten und bauen) und dem "Kontext" (der Außenwelt, die wir nicht ändern können, aber berücksichtigen müssen). Es werden alle Schnittstellen zu Nachbarsystemen (technisch) und Nutzergruppen (menschlich) identifiziert. Das Ergebnis ist oft ein Kontextdiagramm, das sicherstellt, dass keine externe Abhängigkeit übersehen wird.

Details

1.3 Systemkontext & Abgrenzung (Lückenlose operative Checkliste)

diagram-1-1-mindmap

A – Systemgrenze & Scope Dieser Abschnitt definiert messerscharf, was nicht zum System gehört (Negativ-Liste) und klärt Verantwortlichkeiten für Hardware, Betrieb und Support. Auch Grauzonen und die Entscheidung zwischen Eigenentwicklung („Make“) und Zukauf („Buy“) werden hier finalisiert. Mehrwert: Schützt das Projekt vor unkontrolliertem Wachstum („Feature Creep“), klärt vertragliche Lieferpflichten und verhindert teure Missverständnisse über den Leistungsumfang.

B – Akteure & Nutzer (Menschlicher Kontext) Hier werden alle Personen identifiziert, die mit dem System interagieren – inklusive ihrer Rollen, Rechte, Standorte und technischen Fähigkeiten. Auch Aspekte wie Sprache (Internationalisierung) und Barrierefreiheit werden berücksichtigt. Mehrwert: Garantiert eine benutzergerechte Gestaltung (Usability), korrekt dimensionierte Infrastruktur (Last-Szenarien) und ein sicheres Berechtigungskonzept.

C – Nachbarsysteme (IT-Kontext) Dieser Bereich erfasst alle externen Systeme, die Daten liefern oder empfangen, und klärt die Abhängigkeiten (z. B. APIs wie Google Maps). Es werden Resilienz-Strategien für den Ausfall von Nachbarsystemen definiert. Mehrwert: Sichert die Datenkonsistenz und verhindert, dass das eigene System abstürzt, nur weil ein externes System nicht erreichbar ist.

D – Schnittstellen (Technisch) Es werden die technischen Details der Kommunikation festgelegt: Protokolle (REST, SOAP), Datenformate (JSON, XML), Verschlüsselung und Latenz-Anforderungen. Auch physikalische Verbindungen (Stecker) werden geprüft. Mehrwert: Vermeidet Integrationsprobleme („Integration Hell“) und Performance-Engpässe durch frühzeitige Klärung der technischen Machbarkeit.

E – Ereignisse & Events Hier wird analysiert, was das System zum Handeln veranlasst (Trigger, Timer, User-Input) und wie es auf Ereignisfluten reagiert. Echtzeit-Anforderungen und die korrekte Reihenfolge von Events werden definiert. Mehrwert: Stellt sicher, dass das System reaktiv und zeitgerecht arbeitet und auch unter Last oder bei Sensor-Spam stabil bleibt.

F – Dokumente & Materialien Dieser Abschnitt regelt den Input und Output von Dokumenten (Rechnungen, Labels) sowie deren Archivierung und Normkonformität (z. B. ZUGFeRD). Auch die Hardware für Scans und Drucke wird betrachtet. Mehrwert: Gewährleistet die Einhaltung gesetzlicher Archivierungspflichten und verhindert Medienbrüche durch inkompatible Dateiformate oder schlechte OCR.

G – Physikalische Umgebung Es werden die Umweltbedingungen am Einsatzort geprüft: Temperatur, Staub, Lichtverhältnisse, Vibrationen und Platzangebot. Dies bestimmt die Wahl der Hardware (z. B. lüfterlose PCs, High-Brightness-Displays). Mehrwert: Verhindert Hardware-Ausfälle im Feld und stellt sicher, dass die Software auch unter widrigen Bedingungen (z. B. mit Handschuhen) bedienbar bleibt.

H – Prozess-Umfeld Hier wird das System in den übergeordneten Geschäftsprozess eingebettet. Es werden Medienbrüche identifiziert, Notfallprozesse (Business Continuity) für Ausfälle definiert und Workflow-Logiken geklärt. Mehrwert: Optimiert den gesamten Arbeitsablauf, nicht nur die Software, und sichert den Betrieb auch bei technischen Störungen ab.

I – Rechtlicher & Organisatorischer Kontext Dieser Bereich prüft die Einhaltung von Gesetzen (DSGVO, Arbeitsrecht), Normen und Lizenzrechten. Auch Haftungsfragen und Exportbeschränkungen werden geklärt. Mehrwert: Schützt das Unternehmen vor Klagen, Bußgeldern und Vertriebsverboten durch Compliance-Verstöße.

J – Zukunft & Dynamik Abschließend wird die Langlebigkeit der Architektur bewertet: Geplante Änderungen im Umfeld, Skalierbarkeit für neue Märkte und Mandantenfähigkeit werden antizipiert. Mehrwert: Verhindert, dass das System eine Sackgasse wird, und ermöglicht kostengünstige Erweiterungen und Anpassungen in der Zukunft.

Nr. Frage Operative Implikation & Handlungsanweisung

A

SYSTEMGRENZE & SCOPE

1

Was gehört definitiv nicht zum System (Out-of-Scope)?

Scope Management: Definieren Sie explizit, was wir NICHT bauen (Negativ-Liste). Das schützt vor "Feature Creep" und falschen Erwartungen.

2

Welche Teile der Realität können wir verändern (Gestaltungsraum)?

Einflusssphäre: Prüfen Sie: Können wir den analogen Prozess anpassen, damit die Software einfacher wird? Wenn ja → Change Request für den Prozess stellen.

3

Ist die Hardware Teil des Systems oder Teil des Kontexts?

Lieferumfang: Müssen wir den Server/Sensor kaufen und liefern, oder stellt der Kunde das Blech? Vertraglich fixieren!

4

Welche manuellen Tätigkeiten soll das System ersetzen?

ROI & Akzeptanz: Listen Sie die konkreten Arbeitsschritte auf (z.B. "Abtippen von Zettel"). Das ist die Basis für die Nutzenargumentation.

5

Gibt es Aspekte, bei denen unklar ist, ob sie zum System gehören (Grauzonen)?

Risiko: Führen Sie eine "Offene Punkte"-Liste für Grauzonen. Grauzonen werden am Projektende teuer.

6

Übernehmen wir Datenhaltung oder nutzen wir externe Speicher?

Datenhoheit: Entscheidung: Sind wir "System of Record" (Master) oder nur ein Viewer für Daten aus dem CRM?

7

Werden bestehende Software-Module integriert oder neu gebaut?

Make-or-Buy: Prüfen Sie Lizenzen und Wartbarkeit von Fremd-Bibliotheken VOR der Integration. Keine Blackbox ohne Wartungsvertrag!

8

Sind wir für den Betrieb der Infrastruktur verantwortlich?

Service-Schnittstelle: Wo endet unser Job? Beim "Git Push" oder wenn der Server läuft (DevOps)? SLA definieren.

9

Wo endet die Verantwortung unseres Supports?

Service-Desk: Klären Sie ab: Rufen Nutzer uns an, wenn Windows nicht startet? Support-Level definieren.

10

Wird ein Altsystem abgelöst oder ergänzt?

Strategische Einordnung: Wenn Ablösung → Siehe Checkliste 5.4 für detaillierte Migrationsplanung. Wenn Ergänzung → Schnittstellen klären.

11

Haben wir alle Grauzonen explizit entschieden?

Review: Gehen Sie die Systemgrenze nochmals durch. "Vielleicht" ist keine valide Antwort für ein Pflichtenheft.

B

AKTEURE & NUTZER (MENSCHLICHER KONTEXT)

12

Welche Personen(gruppen) interagieren direkt mit dem System?

User-Identifikation: Erstellen Sie eine vollständige Liste aller Rollen (nicht nur "User", sondern "Admin", "Gast", "Auditor").

13

Welche Personen profitieren vom System, ohne es zu bedienen?

Stakeholder: Vergessen Sie den "Berichtsempfänger" nicht. Er nutzt das System nicht, aber seine Anforderungen an den PDF-Report sind kritisch.

14

Gibt es Nutzergruppen mit unterschiedlichen Rechten/Rollen?

Berechtigungskonzept: Definieren Sie eine RBAC-Matrix (Role Based Access Control). Wer darf löschen? Wer darf nur lesen?

15

Wie viele Nutzer greifen gleichzeitig zu (Skalierung)?

Last-Szenario: Unterscheiden Sie "Total Users" (Lizenzkosten) von "Concurrent Users" (Server-Last).

16

Wo befinden sich die Nutzer physisch (Standort)?

Netzwerk: Sitzen User im LAN (schnell) oder im Homeoffice/Mobilfunk (langsam/instabil)? UI muss auf Latenz optimiert sein.

17

Welche Sprache sprechen die Akteure?

Lokalisierung: Brauchen wir Multi-Language-Support (i18n) ab Tag 1? Hardcodierte Texte im Code sind ein teures Refactoring-Risiko.

18

Haben Nutzer körperliche Einschränkungen?

Accessibility: Prüfen Sie BITV/WCAG Vorgaben. Brauchen wir High-Contrast-Mode oder Screenreader-Support?

19

Wie technikaffin sind die Akteure?

Usability: Designen Sie für den DAU (Dümmsten Anzunehmenden User) oder für Experten? Experten hassen Wizards, Anfänger brauchen sie.

20

Gibt es externe Wartungstechniker als Akteure?

Sonderzugang: Braucht der Dienstleister einen VPN-Zugang oder einen speziellen "Notfall-User"? Prozess für Passwortvergabe klären.

21

Nutzen Wettbewerber das System (z. B. als Testkunden)?

Security: Schützen Sie Preislisten oder sensible Daten vor Scraping. Captchas oder Rate-Limiting einplanen.

C

NACHBARSYSTEME (IT-KONTEXT)

22

Welche Nachbarsysteme liefern Daten (Quellen)?

Input-Validierung: Trauen Sie niemals externen Daten! Definieren Sie Validierungsregeln für jeden Input an der Systemgrenze.

23

Welche Nachbarsysteme empfangen Daten (Senken)?

Output-Garantie: Was passiert, wenn die Senke (z.B. SAP) down ist? Müssen wir puffern (Queue) und später senden?

24

Sind die Nachbarsysteme aktiv (senden) oder passiv (werden abgefragt)?

Architektur: Push vs. Pull entscheidet über die Architektur. Polling belastet das Netzwerk, Push erfordert offenen Port/Webhook.

25

Welche Altsysteme laufen parallel weiter?

Datenkonsistenz: Wer ist "Master" für die Daten? Vermeiden Sie bidirektionale Synchronisation (Datenchaos-Garantie), wenn möglich.

26

Gibt es gemeinsame Ressourcen mit anderen Systemen?

Konfliktpotenzial: Wenn wir uns die DB mit einem anderen System teilen → Performance-Probleme und Wartungsfenster abstimmen!

27

Welche externen Dienste (APIs) nutzen wir?

Abhängigkeit: Wenn Google Maps die Preise erhöht, platzt unser Business Case. Prüfen Sie Alternativen oder Verträge.

28

Wer ist Ansprechpartner für die Nachbarsysteme?

Kontaktliste: Namen und Telefonnummern der Admins der Fremdsysteme notieren. Im Fehlerfall müssen wir sofort jemanden erreichen.

29

Wie stabil sind die Schnittstellen der Nachbarsysteme?

Änderungsmanagement: Gibt es einen Newsletter für API-Changes? Wenn Facebook die API ändert, steht unser System still.

30

Gibt es Testsysteme der Nachbarsysteme?

Testbarkeit: Fordern Sie Zugang zu einer Sandbox/Stage-Umgebung des Nachbarsystems. Testen gegen Prod ist fahrlässig.

31

Was passiert, wenn ein Nachbarsystem ausfällt?

Resilienz: Definieren Sie Fallbacks (z.B. Cache nutzen, Standardwerte nehmen). Das System darf nicht crashen (Exception Handling).

D

SCHNITTSTELLEN (TECHNISCH)

32

Welche physikalischen Schnittstellen gibt es (Stecker, Kabel)?

Hardware: Prüfen Sie Stecker-Typen (z.B. RS232 vs USB). Adapter sind im Feld oft Fehlerquelle Nr. 1.

33

Welche Protokolle werden an der Schnittstelle gesprochen?

Interoperabilität: Klären Sie exakt: REST (JSON), SOAP (XML), MQTT? "Webservice" ist keine ausreichende Spezifikation.

34

In welchem Format werden Daten übergeben?

Schema: Fordern Sie ein XSD oder JSON-Schema. Definieren Sie Datentypen (Datum: ISO8601 oder US-Format?).

35

Wie häufig fließen Daten über die Schnittstelle?

Last: Batch (1x Nachts 1GB) vs. Realtime (jeder Klick). Das entscheidet über Netzwerk-Bandbreite und Serverlast.

36

Wer initiiert die Kommunikation (Master/Slave)?

Kontrollfluss: Wer darf die Verbindung aufbauen? Wichtig für Firewall-Regeln (Inbound vs. Outbound).

37

Gibt es Sicherheitsvorgaben für die Schnittstelle?

Encryption: TLS 1.2/1.3 ist Pflicht. API-Keys oder mTLS (Zertifikate) zur Authentifizierung der Gegenseite nutzen.

38

Welche Datenmengen werden übertragen (Bandbreite)?

Netzwerk: Prüfen Sie, ob die Leitungskapazität reicht (z.B. bei Video-Uploads am Standort mit schlechtem DSL).

39

Muss die Schnittstelle synchron oder asynchron arbeiten?

User Experience: Wenn die Schnittstelle 10 Sek braucht, darf das UI nicht einfrieren → Asynchrone Verarbeitung (Job Queue) nutzen.

40

Gibt es eine maximale Latenzzeit für die Schnittstelle?

Timeout: Setzen Sie Timeouts (z.B. 5 Sek). Wenn keine Antwort kommt, Abbruch statt unendlichem Warten.

41

Wie werden Fehler an der Schnittstelle gemeldet?

Error Codes: Mappen Sie technische Fehler (HTTP 500) auf verständliche User-Meldungen ("Dienst nicht erreichbar").

E

EREIGNISSE & EVENTS

42

Welches Ereignis in der Welt löst eine Systemaktion aus?

Trigger: Identifizieren Sie alle Startpunkte. Ein System, das nichts tut, bis man klickt, ist einfach. Ein System, das auf Sensoren wartet, ist komplex.

43

Gibt es zeitgesteuerte Ereignisse (Timer)?

Scheduler: Planen Sie Cron-Jobs ein (z.B. "Täglicher Report"). Was passiert, wenn der Server zum Zeitpunkt X down ist? (Nachholen?)

44

Auf welche Benutzereingaben muss das System reagieren?

Interaktion: Erfassen Sie alle UI-Events (Klick, Swipe, Tastatur).

45

Gibt es Ereignisse, die wir ignorieren müssen?

Filterung: Bauen Sie Schwellwerte ein (Entprellen von Tastern, Ignorieren von unplausiblen Sensorwerten).

46

Müssen wir auf Ereignisse in Echtzeit reagieren?

Realtime: Definieren Sie "Echtzeit". <10ms (Hard Realtime) erfordert spezielle OS/Hardware. <1s (Soft Realtime) geht meist Standard.

47

Welche Ereignisse sendet das System nach außen?

Notification: Senden wir E-Mails/Push? Prüfen Sie Spam-Filter-Problematiken und Zustellraten.

48

Wie verhalten wir uns bei einer Flut von Ereignissen?

Throttling: Implementieren Sie Rate-Limiting, um DDoS oder Sensor-Spam zu überleben.

49

Müssen Ereignisse in einer bestimmten Reihenfolge verarbeitet werden?

Konsistenz: Wenn Reihenfolge wichtig ist (Konto anlegen vor Buchung), brauchen Sie eine geordnete Queue (FIFO).

50

Gibt es seltene Ereignisse, die kritisch sind?

Randfälle: Testen Sie Schaltjahre, Zeitumstellung und Zertifikatsablauf. Das sind klassische "Systemkiller".

51

Wie lange sind Ereignisse gültig?

TTL: Verwerfen Sie alte Events (z.B. Sensorwert von vor 1 Stunde ist nutzlos).

F

DOKUMENTE & MATERIALIEN

52

Welche Dokumente fließen in das System ein?

Input: Prüfen Sie Qualität der Scans/PDFs. OCR ist nie 100% perfekt → Manuelle Korrekturmaske einplanen.

53

Welche Dokumente muss das System erzeugen?

Output: Sammeln Sie alle Vorlagen (Rechnung, Lieferschein). Achtung: Drucker-Treiber sind oft problematisch.

54

Müssen physische Materialien verwaltet werden?

Lager: Wenn Software physische Dinge steuert → Konsistenz-Check (Inventur) vorsehen, da Realität und IT abweichen können.

55

Gibt es Vorgaben zum Layout der Dokumente?

CI/CD: Pixelgenaue Umsetzung von Firmen-Layouts ist oft aufwändig. Nutzen Sie Reporting-Engines.

56

In welchen Formaten müssen Dokumente archiviert werden?

Archivierung: PDF/A (Langzeit) ist Pflicht für steuerlich relevante Belege. Kein natives Word/Excel speichern.

57

Müssen Dokumente digital unterschrieben werden?

Signatur: Einbinden von Signatur-Diensten (DocuSign/IDnow). Rechtliche Gültigkeit prüfen!

58

Werden Barcodes oder QR-Codes verwendet?

Hardware: Testen Sie Scanner-Hardware frühzeitig. Prüfen Sie Barcode-Standards (Code128, EAN, QR).

59

Gibt es Normen für die Dokumente?

Compliance: ZUGFeRD / XRechnung für E-Invoicing beachten. Das Format ist gesetzlich vorgegeben.

60

Müssen Dokumente versioniert werden?

Audit: Niemals Dokumente überschreiben! Immer neue Version anlegen, alte behalten (Revisionssicherheit).

61

Wie groß sind die zu verarbeitenden Dateien?

Upload: Begrenzen Sie die Upload-Größe (z.B. 10MB). Große Dateien blockieren den Server-RAM.

G

PHYSIKALISCHE UMGEBUNG

62

Welche Temperatur herrscht am Einsatzort?

Kühlung: Serverraum oder Stahlwerk? Prüfen Sie den Betriebstemperaturbereich der Hardware.

63

Ist die Umgebung staubig oder feucht?

IP-Schutz: IP54 (Staub/Spritzwasser) oder IP67 (Tauchen)? Lüfterlose PCs für staubige Hallen nutzen.

64

Wie sind die Lichtverhältnisse?

Display: Bei Sonnenlicht brauchen Sie High-Brightness-Displays (>500 cd/m²). Dark-Mode für Nachtarbeit.

65

Gibt es Lärm am Einsatzort?

Audio: Warntöne bringen nichts in einer lauten Fabrik. Nutzen Sie Ampeln oder Vibrationsalarme.

66

Steht eine stabile Stromversorgung zur Verfügung?

USV: Bei Stromausfall: Sicher herunterfahren oder weiterlaufen? USV-Integration (Signal "Battery Low") vorsehen.

67

Gibt es Vibrationen oder Erschütterungen?

SSD: Keine rotierenden Festplatten (HDD) auf Gabelstaplern oder in Fahrzeugen! Nur SSDs nutzen.

68

Wie viel Platz ist für die Installation vorhanden?

Maße: Prüfen Sie Schaltschrank-Tiefe. Passt der Server rein inklusive Stecker hinten?

69

Muss das System mobil genutzt werden?

Akku: Laufzeit definieren. Gewicht limitieren (niemand trägt 2kg Tablet den ganzen Tag).

70

Gibt es hygienische Anforderungen?

Reinigung: Hardware muss alkoholbeständig sein (Klinik). Tastaturen müssen abwaschbar sein.

71

Ist Explosionsschutz erforderlich (ATEX)?

Spezial-Hardware: In Ex-Schutzzonen (Chemie/Gas) darf keine normale IT-Hardware eingesetzt werden. Zertifizierungspflicht!

H

PROZESS-UMFELD

72

Welche Geschäftsprozesse starten außerhalb des Systems?

Trigger: Der Prozess beginnt oft analog (Telefonat). Das System muss diesen Startpunkt erfassen können.

73

An welcher Stelle im Prozess wird das System genutzt?

Integration: Vermeiden Sie Medienbrüche. Das System sollte den Workflow führen, nicht unterbrechen.

74

Welche Medienbrüche gibt es im Prozess?

Optimierung: Ziel: Abtippen vermeiden. Wenn Daten gedruckt werden, um sie woanders einzugeben → Schnittstelle bauen!

75

Wie geht der Prozess weiter, nachdem das System fertig ist?

Hand-over: Klarer Abschluss: "Rechnung gedruckt" → Wer bringt sie zur Post? Prozessende definieren.

76

Gibt es Varianten des Geschäftsprozesses?

Logik: Hardcodieren Sie nicht nur den "Happy Path". Sonderwege (Storno, Eilauftrag) müssen konfigurierbar sein.

77

Was passiert bei Systemausfall im Prozess?

Notfallplan: Definieren Sie einen Papier-Prozess für den Ausfall ("Business Continuity").

78

Welche Rolle spielt Zeitdruck im Prozess?

Performance: UX optimieren (Shortcuts, Tab-Reihenfolge), wenn Zeit Geld ist (Callcenter).

79

Gibt es Genehmigungsschritte außerhalb des Systems?

Workflow: System muss Status "Warten auf Unterschrift" kennen und darf den Prozess nicht blockieren.

80

Wie oft wird der Prozess durchgeführt?

Priorisierung: Optimieren Sie Hochfrequenz-Prozesse (1000x am Tag) auf Klicks. Seltene Prozesse dürfen umständlich sein.

81

Ändert sich der Geschäftsprozess durch das neue System?

Change: Schulen Sie den NEUEN Prozess, nicht nur das Tool. Alte Gewohnheiten sind schwer zu ändern.

I

RECHTLICHER & ORGANISATORISCHER KONTEXT

82

Welche Gesetze gelten im Einsatzland?

Legal: Prüfen Sie Fiskalgesetze (Kassenrichtlinie) und Arbeitsrecht im Zielland.

83

Welche Datenschutzregeln gelten (DSGVO, CCPA)?

Privacy: Löschkonzepte vorsehen ("Recht auf Vergessenwerden"). Logfiles dürfen keine Klarnamen enthalten.

84

Gibt es branchenspezifische Normen?

Compliance: Normen (z.B. ISO 13485 Medizintechnik) diktieren den Entwicklungsprozess und die Doku.

85

Müssen wir Barrierefreiheits-Gesetze einhalten?

Inklusion: Für Behörden-Software ist Barrierefreiheit gesetzliche Pflicht. Klagerisiko!

86

Gibt es steuerrechtliche Vorgaben?

Archiv: Unveränderbarkeit von Buchungsdaten sicherstellen (Log, WORM-Speicher).

87

Sind Lizenzrechte von Drittsoftware zu beachten?

Lizenz-Check: Keine GPL-Code in proprietärer Software nutzen! Nutzen Sie SCA-Tools (Software Composition Analysis).

88

Gibt es Arbeitsschutzvorgaben?

Ergonomie: Software darf Nutzer nicht krank machen (Flimmern, zu kleine Schrift). ISO 9241 beachten.

89

Wer haftet bei Fehlern des Systems?

Haftung: Klären Sie Haftungsgrenzen in AGBs. Bei Safety-Systemen: Versicherung prüfen.

90

Müssen Verträge mit Partnern beachtet werden?

Constraint: Prüfen Sie Exklusivverträge oder Lieferbindungen, die technische Entscheidungen einschränken.

91

Gibt es Exportbeschränkungen (Embargos)?

Trade Compliance: Prüfen Sie, ob Krypto-Bibliotheken Exportbeschränkungen unterliegen (Dual-Use Goods).

J

ZUKUNFT & DYNAMIK

92

Ist die Systemgrenze stabil oder ändert sie sich bald?

Architektur: Bauen Sie Schnittstellen modular ("Loose Coupling"), wenn Erweiterungen geplant sind.

93

Gibt es geplante Änderungen in der Umgebung?

Roadmap: Fragen Sie die IT: "Wird SAP bald abgelöst?". Bauen Sie keine Schnittstelle zu einem toten System.

94

Ist das System skalierbar für neue Märkte?

i18n: Währungen, Datumsformate und Steuersätze nicht hardcodieren! Konfiguration statt Code.

95

Werden wir zukünftig weitere Akteure anbinden?

Mandantenfähigkeit: Datenmodell so bauen, dass Mandanten-Trennung später möglich ist (Tenant-ID in jede Tabelle).

96

Welche Technologien im Kontext könnten veralten?

Obsoleszenz: Keine Abhängigkeiten zu IE11, Flash oder veralteten Java-Versionen aufbauen.

97

Sind die Schnittstellen versioniert?

API-Design: Nutzen Sie URL-Versionierung (/v1/…​), um Breaking Changes in Zukunft abzufedern.

98

Wie flexibel ist das Datenmodell für Erweiterungen?

NoSQL/JSON: Nutzung von JSON-Feldern für flexible Attribute prüfen, um Schema-Migrationen zu sparen.

99

Gibt es politische Risiken für den Kontext?

Flexibilität: Regelwerke (Steuern, Zoll) konfigurierbar machen, um auf Gesetzesänderungen schnell zu reagieren.

100

Planen wir, Teile des Kontexts später in das System zu holen?

Strategie: Bauen Sie die Schnittstelle so, dass sie später zur internen Modul-Schnittstelle werden kann.

Restriktions-Analyse (Der Lösungsraum)
Jedes Projekt hat Grenzen. In diesem Schritt werden alle Faktoren gesammelt, die den Lösungsraum einschränken, bevor kreativ gearbeitet wird. Dazu gehören das Budget, harte Zeitlinien, einzuhaltende Gesetze (z. B. DSGVO), Normen (z. B. ISO 26262) oder technische Vorgaben der IT-Abteilung (z. B. "Nur Cloud-Lösungen erlaubt"). Diese Restriktionen wirken als Filter für alle späteren Anforderungen.

Details

1.4 Restriktions-Analyse & Technische Randbedingungen (Operative Checkliste)

diagram-1-4-mindmap

A – Technologie-Stack (Backend & Code) Dieser Abschnitt prüft die zwingenden Vorgaben für Programmiersprachen, Datenbanken und Betriebssysteme, um „Skill-Gaps“ im Team und Lizenzprobleme zu vermeiden. Er klärt zudem Integrationsvorgaben für Middleware und rechtliche Aspekte bei Open-Source-Lizenzen (GPL) und Urheberrechten. Mehrwert: Verhindert den Einsatz inkompatibler Technologien, teure Lizenzverstöße und rechtliche Konflikte bezüglich Code-Eigentum.

B – Infrastruktur & Clients Hier wird definiert, auf welchen Endgeräten (Client-OS, Browser-Versionen, Hardware) die Software laufen muss, inklusive der Berücksichtigung von „Legacy“-Systemen wie dem Internet Explorer. Auch Netzwerkbeschränkungen durch Firewalls, Proxies und Bandbreitenlimits werden analysiert. Mehrwert: Garantiert, dass die entwickelte Software in der realen IT-Umgebung des Kunden – auch auf schwacher Hardware – performant und fehlerfrei läuft.

C – Recht, Normen & Compliance Es werden alle bindenden gesetzlichen Vorschriften (z. B. DSGVO, GoBD) und Industriestandards (z. B. ISO 26262 für Safety) identifiziert. Dies umfasst auch Exportbeschränkungen für Kryptografie und Anforderungen an die Barrierefreiheit (BITV). Mehrwert: Schützt das Unternehmen vor Bußgeldern, Klagen oder einem Vertriebsverbot aufgrund von Non-Compliance.

D – Budget & Zeitplan (Management) Dieser Bereich legt den finanziellen Rahmen („Design-to-Cost“) und harte Deadlines fest, die den Scope beeinflussen. Er prüft Ressourcenverfügbarkeit, Release-Zyklen und vertragliche Bindungen, um die Wirtschaftlichkeit sicherzustellen. Mehrwert: Verhindert Projektstopps durch Budgetüberschreitung und sichert die Einhaltung kritischer Markttermine („Time-to-Market“).

E – Prozess & Methodik Hier wird das vertraglich fixierte Vorgehensmodell (Agil vs. Wasserfall) und die zu nutzende Toolchain (z. B. Jira) geklärt. Auch Standards für Dokumentation, Deployment (CI/CD) und Abnahmeprozesse werden definiert. Mehrwert: Vermeidet methodische Brüche und Doppelarbeit durch inkompatible Tools oder Prozesse zwischen Auftraggeber und Auftragnehmer.

F – Integration & Schnittstellen Dieser Abschnitt analysiert die technischen Schnittstellen zu Nachbarsystemen, inklusive Protokolle (REST, MQTT), Datenformate und Authentifizierung. Er fordert Strategien für den Umgang mit instabilen Verbindungen oder API-Änderungen. Mehrwert: Sichert die reibungslose Kommunikation im Systemverbund und verhindert, dass das eigene System durch Fehler in Fremdsystemen abstürzt.

G – Physische Umgebung & Hardware Es werden die physikalischen Anforderungen an die Hardware geprüft: Schutz gegen Staub/Wasser (IP-Rating), Vibrationen, Lichtverhältnisse und Montagevorgaben. Dies ist entscheidend für den Einsatz in Industrieumgebungen. Mehrwert: Verhindert teure Hardware-Ausfälle im Feld und stellt sicher, dass das System unter realen Bedingungen (z. B. mit Handschuhen) bedienbar ist.

H – Kultur & Internationalisierung Hier werden Anforderungen für den globalen Einsatz geklärt: Unterstützung verschiedener Sprachen, Leserichtungen (RTL), Maßeinheiten und kulturelle Besonderheiten bei Farben oder Symbolen. Mehrwert: Ermöglicht den weltweiten Vertrieb ohne teures Refactoring und verhindert kulturelle Fauxpas, die die Nutzerakzeptanz gefährden.

I – Daten, Privacy & Speicherung Dieser Bereich regelt den physischen Speicherort (Data Residency), Löschkonzepte (Retention Policies) und den Schutz sensibler Daten (Verschlüsselung). Auch Limits für Datenbankgrößen und Backup-Strategien werden festgelegt. Mehrwert: Sichert die Einhaltung strenger Datenschutzgesetze und verhindert Datenverlust oder unkontrolliertes Datenwachstum.

J – Betrieb & Wartung Abschließend werden Prozesse für Support (1st Level), Update-Verteilung und Fernwartung definiert. Es klärt Verantwortlichkeiten (RACI) für Patches und Anforderungen an Monitoring und Logging. Mehrwert: Gewährleistet einen stabilen, wartbaren Betrieb und verhindert Sicherheitslücken durch ungepatchte Systeme oder unsichere Fernzugriffe.

Nr. Frage Operative Implikation & Handlungsanweisung

A

TECHNOLOGIE-STACK (BACKEND & CODE)

1

Welche Programmiersprache muss zwingend verwendet werden?

Skill-Gap: Prüfen Sie VOR Projektstart, ob das Team die Sprache auf "Expert Level" beherrscht. Wenn Java vorgeschrieben ist, aber nur Node.js-Entwickler da sind → Sofortiges Veto.

2

Auf welchem Betriebssystem muss die Server-Komponente laufen?

Infrastruktur-Zwang: Entwickeln Sie nicht auf Windows, wenn Produktion auf RHEL 8 läuft. Docker-Container helfen, ersetzen aber nicht den Test auf dem Ziel-OS.

3

Welche Datenbanktechnologie ist vorgeschrieben?

Lizenzkosten: Prüfen Sie, ob die vorhandenen Lizenzen für das neue Projekt ausreichen (CPU-Cores zählen!). Oracle-Audits sind extrem teuer.

4

Gibt es Vorgaben für das Frontend-Framework?

Standardisierung: Vermeiden Sie "Resume Driven Development" (Entwickler nutzen neues Framework nur für den Lebenslauf). Halten Sie sich strikt an den Firmenstandard (z.B. Angular).

5

Muss eine bestimmte Middleware oder ein ESB genutzt werden?

Integration: Planen Sie Aufwände für die Middleware-Konfiguration ein. Der ESB ist oft der Flaschenhals im Deployment.

6

Welche Webserver oder Application Server sind zugelassen?

Compliance: Nutzen Sie keine "Exoten". Wenn Apache vorgeschrieben ist, wird Nginx von der IT-Security oft blockiert.

7

Welche Version der Java/Python/.NET-Runtime ist auf den Zielsystemen installiert?

Legacy-Falle: Entwickeln Sie nicht mit Features aus Java 21, wenn auf dem Server noch Java 8 läuft. Version-Check ist Pflichtschritt im Kick-off.

8

Gibt es Vorgaben zur Verwendung von Open-Source-Bibliotheken?

Rechtssicherheit: Nutzen Sie Tools wie Sonatype Nexus / Black Duck, um Lizenzen automatisch zu prüfen. K.O.-Kriterium: GPL-Code in proprietärer Software.

9

Wer hält die Urheberrechte am Quellcode?

IP-Transfer: Prüfen Sie Arbeitsverträge von Freelancern. Code muss "Work for Hire" sein, sonst gehört er dem Entwickler, nicht der Firma.

10

Gibt es Vorgaben zur Code-Formatierung (Coding Guidelines)?

Qualität: Richten Sie Linter (Checkstyle/ESLint) in der CI-Pipeline ein, die den Build bei Verstößen abbrechen. Keine Diskussionen über Klammersetzung!

B

INFRASTRUKTUR & CLIENTS

11

Auf welchen Client-Betriebssystemen muss die Software laufen?

Kompatibilität: Definieren Sie exakt: "Windows 10 Build XYZ", "macOS ab Ventura". Prüfen Sie, ob es eine IT-Richtlinie gibt, die Linux ausschließt.

12

Gibt es Hardware-Vorgaben für die Client-Rechner?

Minimalspezifikation: Testen Sie auf dem schwächsten Gerät im Unternehmen, nicht auf dem Entwickler-Laptop. Wenn es dort ruckelt → Performance-Optimierung.

13

Welche Browser-Versionen müssen mindestens unterstützt werden?

Legacy-Support: Prüfen Sie die Standard-Installation der IT. Wenn IE11 Pflicht ist, fallen moderne CSS/JS-Features weg. Budgetaufschlag für Polyfills und Testing einplanen.

14

Sind Cloud-Dienste erlaubt oder ist On-Premises Pflicht?

Architektur-Entscheidung: Klären Sie "Cloud Exit Strategien". Wenn AWS verboten ist, dürfen auch keine AWS Lambda Funktionen genutzt werden.

15

Gibt es Firewalls oder Proxies, die beachtet werden müssen?

Netzwerk: Entwickler vergessen oft Corporate Proxies. Testen Sie frühzeitig, ob die App ins Internet kommt (z.B. für Updates).

16

Wie hoch ist die maximale Bandbreite der Verbindung?

NFR: Simulieren Sie im Test eine Drosselung (z.B. 2 Mbit/s). Apps, die im Gigabit-LAN fliegen, stürzen im Feld oft ab.

C

RECHT, NORMEN & COMPLIANCE

17

Welche gesetzlichen Vorschriften müssen eingehalten werden?

Legal Compliance: Identifizieren Sie zwingende Gesetze (GoBD, KassenSichV). Ein Verstoß hier bedeutet oft, dass die Software nicht verkauft werden darf.

18

Welche Normen oder Industriestandards sind bindend?

Zertifizierung: Bei Medizintechnik (IEC 62304) oder Automotive (ISO 26262) muss die Dokumentation während der Entwicklung entstehen, nicht danach.

19

Muss die DSGVO (GDPR) vollumfänglich angewendet werden?

Privacy: Löschkonzepte und Auskunftsfunktion sind keine Features, sondern Pflicht. Fehlen diese → Bußgeldrisiko.

20

Gibt es Exportbeschränkungen für die Software (z. B. Kryptografie)?

Trade Compliance: Melden Sie Nutzung von starker Verschlüsselung beim BAFA/US-Behörden, wenn die Software Grenzen überschreitet.

21

Müssen wir Barrierefreiheit nach BITV 2.0 garantieren?

Klagerisiko: Bei Behördensoftware Pflicht. Nutzen Sie automatische Tools (Lighthouse/Axe) im Build-Prozess zur Prüfung.

22

Gibt es Vorgaben zur Archivierung von Dokumenten?

Revisionssicherheit: Speichern auf Filesystem reicht nicht. WORM-Speicher oder DMS-Anbindung erforderlich.

23

Gibt es branchenspezifische Regulierungen (z. B. BaFin, FDA)?

Audit-Trail: Jede Datenänderung muss protokolliert werden (Wer, Wann, Was, Alter Wert, Neuer Wert). Nicht abschaltbar!

24

Muss der Quellcode bei einem Treuhänder hinterlegt werden (Escrow)?

Sicherheit: Vertragsklausel prüfen. Prozess aufsetzen, um Code regelmäßig an Notar/Treuhänder zu senden.

D

BUDGET & ZEITPLAN (MANAGEMENT)

25

Welches Budget steht maximal zur Verfügung?

Cost Control: Implementieren Sie ein "Design-to-Cost" Vorgehen. Streichen Sie "Nice-to-Have" Features sofort, wenn das Budget wackelt.

26

Wann ist der absolut letzte Fertigstellungstermin (Deadline)?

Scope Management: Wenn der Termin fix ist (Messe/Gesetz), muss der Scope variabel sein. Priorisierung nach MoSCoW ist zwingend.

27

Gibt es feste Release-Zyklen, in die wir uns einfügen müssen?

Deployment: Verpassen Sie das "Release Train" Fenster nicht. Wenn Deployment nur quartalsweise erlaubt ist, bedeutet ein Bugfix 3 Monate Wartezeit.

28

Wie viele interne Mitarbeiter können für das Projekt abgestellt werden?

Ressourcen: Prüfen Sie die reale Verfügbarkeit. "50% verfügbar" heißt operativ meist "gar nicht verfügbar".

29

Bis wann muss der ROI (ROI) erreicht sein?

Business Value: Hinterfragen Sie Features, die keinen direkten Wertbeitrag liefern. Das Projekt wird gestoppt, wenn der ROI wackelt.

30

Gibt es Pönalen bei Terminüberschreitung?

Risikomanagement: Bei Pönalen müssen Puffer im Zeitplan sein. Melden Sie Verzug sofort schriftlich (Behinderungsanzeige).

31

Wann beginnt das Geschäftsjahr des Kunden?

Rechnungsstellung: Meilensteine so legen, dass Budgettöpfe genutzt werden können (Jahresendrallye).

32

Gibt es Sperrzeiten (Code Freeze), in denen nichts geändert werden darf?

Planung: Planen Sie keine Go-Lives im Dezember (Retail) oder Monatsende (Finance). Diese Zeiten sind tabu.

33

Wie lange muss der Support für das System garantiert werden?

Obsoleszenz-Management: Nutzen Sie nur Bibliotheken (LTS), die auch in 5 Jahren noch Patches erhalten.

34

Sind wir an bestehende Rahmenverträge mit Softwarelieferanten gebunden?

Beschaffung: Nutzen Sie keine AWS-Datenbank, wenn die Firma einen Enterprise-Vertrag mit Azure hat. Das wird der Einkauf blockieren.

E

PROZESS & METHODIK

35

Welches Vorgehensmodell ist vorgeschrieben (Scrum, Wasserfall)?

Methodik: Faken Sie kein Agile, wenn der Kunde Wasserfall (Pflichtenheft) fordert. Der Vertrag diktiert den Prozess.

36

Welche Tools müssen für das Projektmanagement genutzt werden?

Integration: Wenn der Kunde Jira nutzt, nutzen Sie Jira. Doppelpflege in Excel und Jira ist Ressourcenverschwendung.

37

Wie sieht der vorgeschriebene Testprozess aus?

Quality Gate: Planen Sie Zeit für vorgeschriebene manuelle Tests ein. "Dev is Done" heißt nicht "Ready for Prod".

38

Welche Dokumentationsstandards müssen eingehalten werden?

Doku-Pflicht: Schreiben Sie Doku (arc42) parallel zur Entwicklung. "Doku machen wir am Ende" funktioniert operativ nie.

39

Wie erfolgt das Deployment (CI/CD Pipeline)?

Automation: Kein manuelles Kopieren von Dateien! Fordern Sie Zugriff auf den Jenkins/GitLab-Runner des Kunden.

40

Wie müssen Anforderungen dokumentiert werden (User Stories, Lastenheft)?

Abnahme: Klären Sie das Format der "Definition of Done". Ohne klare Akzeptanzkriterien keine Abnahme.

41

Welche Sprache ist die Projektsprache?

Kommunikation: Code-Kommentare und Tickets in Englisch, wenn das Team international ist. Deutsch nur, wenn vertraglich gefordert.

42

Wer muss Arbeitsergebnisse abnehmen (Quality Gates)?

Flaschenhals: Identifizieren Sie die Personen, die unterschreiben müssen. Planen Sie deren Urlaubszeiten ein.

43

Wie ist das Berichtswesen (Reporting) geregelt?

Overhead: Wenn wöchentliche Statusberichte gefordert sind, planen Sie 4h Projektleitung pro Woche extra ein.

F

INTEGRATION & SCHNITTSTELLEN

44

Mit welchen bestehenden Systemen muss eine Schnittstelle realisiert werden?

Kontext: Zeichnen Sie ein Kontextdiagramm. Jede Linie ist ein Risiko. Fordern Sie Interface-Beschreibungen an.

45

Welches Datenformat ist für den Austausch zwingend?

Validierung: Bauen Sie Validatoren für EDIFACT/XML direkt am Eingang. "Garbage In" vermeiden.

46

Gibt es vorgegebene Kommunikationsprotokolle?

Konnektivität: MQTT, REST, SOAP, FTP? Implementieren Sie Retry-Mechanismen für instabile Protokolle.

47

Welche Authentifizierungsmethoden schreiben Nachbarsysteme vor?

Security: OAuth2 / mTLS Zertifikate rechtzeitig beantragen. Zertifikatsausstellung dauert in Konzernen oft Wochen.

48

Gibt es Zeitfenster für die Datenübertragung (Batch-Fenster)?

Scheduling: Job-Scheduler so konfigurieren, dass Wartungsfenster respektiert werden.

49

Dürfen wir die Schnittstellen der Nachbarsysteme ändern?

Constraint: Meistens nein. Schreiben Sie Wrapper/Adapter (Anti-Corruption Layer), um Ihr System sauber zu halten.

50

Müssen wir bestimmte Hardware-Schnittstellen bedienen?

Treiber: RS232/GPIB erfordern oft spezielle Hardware-Treiber oder Dongles. Frühzeitig beschaffen.

51

Gibt es eine maximale Latenzzeit für externe Anfragen?

Timeout-Handling: Was tun, wenn das Nachbarsystem zu langsam antwortet? Circuit Breaker Pattern implementieren.

G

PHYSISCHE UMGEBUNG & HARDWARE

52

In welcher physikalischen Umgebung wird das System genutzt?

Robustheit: Büro vs. Stahlwerk. Büro-Hardware stirbt in der Industrie sofort.

53

Muss die Hardware gegen Staub oder Wasser geschützt sein?

IP-Rating: Beschaffen Sie Hardware mit Zertifikat (IP65/67). Lüfterlose PCs sind in staubigen Umgebungen Pflicht.

54

Wie sind die Lichtverhältnisse am Einsatzort?

Kontrast: High-Contrast-Themes für Outdoor-Nutzung vorsehen. Dark-Mode für Nachtschichten.

55

Muss das System mit Handschuhen bedienbar sein?

Touch: Resistive Screens oder extra große Buttons im UI vorsehen. Kapazitive Screens funktionieren oft nicht mit Handschuhen.

56

Gibt es Vibrationen oder Erschütterungen?

Storage: Verbot von HDDs (rotierende Scheiben). Nur Industrie-SSDs nutzen. Kabel müssen verschraubbar sein.

57

Wie stabil ist die Stromversorgung am Einsatzort?

Data Integrity: USV einplanen oder Filesystem nutzen, das "Hard Power Off" überlebt.

58

Wie viel Platz steht für die Hardware zur Verfügung?

Formfaktor: Messen Sie nach! Nichts ist peinlicher, als wenn der Server 2cm zu tief für den Schrank ist.

59

Gibt es Lärmbeschränkungen für die Hardware?

Ergonomie: Im Büro sind Lüftergeräusche >30dB ein Reklamationsgrund. Silent-PC / Passivkühlung nutzen.

60

Muss die Hardware mobil sein?

Gewicht/Akku: Max. Gewicht definieren. Akkulaufzeit unter Volllast testen, nicht im Standby.

61

Gibt es Vorgaben zur Montage?

Installation: VESA-Mounts oder Hutschienen-Montage (DIN Rail) prüfen.

H

KULTUR & INTERNATIONALISIERUNG

62

In welchem Land/Kulturkreis wird die Software eingesetzt?

Design: Prüfen Sie Farbbedeutungen (Weiß = Trauer in Asien). UI anpassen.

63

Welche Sprachen müssen zwingend unterstützt werden?

i18n: Keine Texte im Code hardcodieren! Nutzen Sie Resource-Files ab Tag 1. Definieren Sie die exakte Liste (DE, EN, FR…​).

64

Gibt es kulturelle Tabus bei Bildern oder Symbolen?

Review: Lassen Sie Icons von Muttersprachlern prüfen. Vermeiden Sie Handgesten-Icons.

65

Wie ist die Leserichtung der Benutzer?

RTL-Support: Für Arabisch/Hebräisch muss das gesamte UI spiegelbar sein (Right-to-Left). Framework-Support prüfen.

66

Welche Maßeinheiten sind Pflicht?

Umrechnung: Interne Speicherung in SI-Einheiten (Meter), Anzeige konfigurierbar (Fuß/Meilen).

67

Gibt es Vorgaben zur Barrierefreiheit für bestimmte Nutzergruppen?

Schriftgröße: Skalierbare Fonts nutzen. Farbkontraste müssen WCAG AA entsprechen.

68

Wie hoch ist das Bildungsniveau der Nutzer?

UX-Text: Einfache Sprache nutzen. Fachbegriffe vermeiden, wenn Nutzer keine Experten sind.

69

Gibt es religiöse Vorschriften zu beachten?

Kalender: Arbeitswoche kann So-Do sein (Israel, arabischer Raum). Hardcodiertes "Wochenende = Sa/So" ist ein Bug.

70

Welche Währungsformate sind zwingend?

Formatierung: Nutzen Sie Standard-Bibliotheken für Währungen, erfinden Sie das Rad nicht neu.

71

Gibt es farbliche Einschränkungen (z.B. Farbenblindheit)?

Signale: Fehler nicht nur rot markieren, sondern auch mit Icon/Text.

I

DATEN, PRIVACY & SPEICHERUNG

72

Wo liegen die Daten physisch (Data Residency)?

Recht: Nutzen Sie Regions-Einstellungen in der Cloud (z.B. "AWS Frankfurt only"). Datenexporte in Drittstaaten verhindern.

73

Wer darf Zugriff auf die Echtdaten haben?

Datenschutz: Testen Sie NIEMALS mit unanonymisierten Produktionsdaten. Entwickler brauchen synthetische Testdaten.

74

Müssen Daten nach einer bestimmten Zeit gelöscht werden?

Retention Policy: Implementieren Sie automatische Lösch-Jobs ("Garbage Collector") für alte Daten.

75

Gibt es Vorgaben zur Datensparsamkeit?

Minimierung: Pflichtfelder hinterfragen. Was wir nicht speichern, kann nicht gestohlen werden.

76

Müssen Daten verschlüsselt auf dem Endgerät liegen?

Mobile Security: SQLite/Datenbank auf Tablets muss verschlüsselt sein (Encryption at Rest).

77

Dürfen Daten in die Cloud geladen werden?

Policy Check: Prüfen Sie Klassifizierung der Daten (Geheim/Vertraulich). Geheime Daten gehören nicht in Public Cloud Storage.

78

Müssen wir uns an ein bestehendes Datenmodell halten?

Integration: Mapping-Tabelle erstellen zwischen internem Modell und Unternehmens-CDM.

79

Gibt es eine maximale Größe für die Datenbank?

Sizing: Wenn SQL Express (10GB Limit) genutzt wird → Archivierungskonzept frühzeitig planen.

80

Wie lange müssen Backups aufbewahrt werden?

Storage-Kosten: Langzeit-Backups auf günstigem Speicher (Cold Storage/Tape) ablegen.

81

Gibt es Vorgaben zum Datenaustauschformat?

Standard: JSON/XML bevorzugen. Proprietäre Binärformate vermeiden (schwer zu debuggen).

J

BETRIEB & WARTUNG

82

Wer übernimmt den 1st-Level-Support?

Handoff: Erstellen Sie Fehlerbäume/FAQs für den Support, damit nicht jeder Anruf bei den Entwicklern landet.

83

Wie müssen Updates verteilt werden?

Mechanismus: MSI-Pakete für Windows, AppStore für Mobile. Updates müssen ohne Admin-Rechte des Users laufen können.

84

Welche Fernwartungstools sind zugelassen?

Remote Access: Integrieren Sie nur zugelassene Tools (z.B. TeamViewer SDK), keine Bastellösungen.

85

Gibt es Wartungsfenster, die zwingend eingehalten werden müssen?

Verfügbarkeit: System darf Updates nur im Fenster installieren. Außerhalb → Pönalen-Risiko.

86

Muss eine Testumgebung (Staging) bereitgestellt werden?

Infrastruktur: Budgetieren Sie Hardware für Staging. "Wir testen in Prod" ist unprofessionell und gefährlich.

87

Wie lange darf ein Update maximal dauern?

Performance: Datenbank-Migrationen optimieren. Wenn Migration 4 Stunden dauert, platzt das Wartungsfenster.

88

Wer ist für das Einspielen von Patches verantwortlich?

RACI: Klären Sie: Wer patcht das OS, wer die Datenbank, wer die App? Lücken hier führen zu Hacks.

89

Gibt es Vorgaben zur Dokumentationssprache für Admins?

Lieferobjekt: Wenn Admins Deutsch sprechen, nützt ein englisches Manual nichts. Übersetzungsbudget einplanen.

90

Müssen Fehlercodes einem bestimmten Standard folgen?

Monitoring: Strukturierte Logs schreiben (JSON), damit Monitoring-Tools (Splunk/ELK) Alarme auslösen können.

91

Wie wird der Zugriff für externe Wartungstechniker geregelt?

IAM: Keine Shared Accounts ("Admin/Admin")! Personalisierte User mit Ablaufdatum nutzen.

Phase 2: Ziele & Ermittlung

In dieser Phase findet die eigentliche "Discovery" statt. Wir bewegen uns vom abstrakten Geschäftsziel hin zu konkreten funktionalen und qualitativen Anforderungen.

Ziel-Definition (Die Strategie)
Anforderungen sind kein Selbstzweck, sie dienen der Erfüllung von Zielen. Hier werden die strategischen Absichten der Stakeholder ermittelt und in Ziel-Hierarchien (z. B. AND/OR-Bäumen) modelliert. Wir prüfen, ob Ziele sich widersprechen (z. B. "Maximale Sicherheit" vs. "Maximale Usability") und klären diese Grundsatzkonflikte, bevor wir uns in Details verlieren.

Details

2.1 Ziel-Definition & Goal Modeling (Operative Audit-Checkliste)

diagram-2-1-mindmap

A – Strategie & Wurzel (Root Goals) Dieser Abschnitt stellt sicher, dass das Projekt überhaupt eine Daseinsberechtigung hat. Es identifiziert das oberste Geschäftsziel („Business Case“) und das konkrete Problem, das gelöst werden soll. Zudem wird geprüft, ob die Ziele im Einklang mit der Unternehmensvision und -ethik stehen. Mehrwert: Verhindert Projekte ohne echten Nutzen („Lösung auf der Suche nach einem Problem“) und sichert die strategische Ausrichtung.

B – Struktur & Dekomposition (AND/OR) Hier wird das große, abstrakte Ziel in kleinere, handhabbare Teile zerlegt. Durch UND-Verknüpfungen (alle Teile nötig) und ODER-Verknüpfungen (Alternativen möglich) entsteht eine logische Struktur. Unnötige Zweige werden gekappt, um Verschwendung („Waste“) zu vermeiden. Mehrwert: Macht komplexe Visionen greifbar und zeigt alternative Lösungswege (z. B. Prozessänderung statt Software) auf.

C – Konflikte & Abhängigkeiten Dieser Bereich deckt Widersprüche zwischen Zielen auf (z. B. „Sicherheit“ vs. „Benutzerfreundlichkeit“) und visualisiert Synergien. Entscheidungen über Prioritäten und Kompromisse („Trade-offs“) werden hier getroffen, bevor sie im Projektverlauf zur Krise führen. Mehrwert: Ermöglicht proaktives Konfliktmanagement und zwingt Stakeholder zu klaren Richtungsentscheidungen statt unrealistischer „Wünsch-dir-was“-Listen.

D – Klassifizierung & Messbarkeit (KPIs) Es wird unterschieden zwischen harten, funktionalen Zielen und weichen, qualitativen Zielen („Soft Goals“). Zentrale Aufgabe ist die Operationalisierung: Vage Wünsche wie „schnell“ werden in messbare Metriken (z. B. „< 200ms“) übersetzt. Mehrwert: Schafft objektive Abnahmekriterien und verhindert endlose Diskussionen darüber, ob ein Ziel („schön“, „benutzerfreundlich“) erreicht wurde.

E – Realität & Machbarkeit Hier werden Ziele auf technische und physikalische Machbarkeit geprüft. Annahmen („User hat immer Internet“) werden dokumentiert und Risiken durch externe Abhängigkeiten identifiziert. Mehrwert: Schützt vor dem Verfolgen unmöglicher Ziele („High Tech Risk“) und sorgt für einen Realitätscheck, bevor Budget investiert wird.

F – Scope, MVP & Zeit Dieser Abschnitt definiert, was sofort gebaut wird (MVP) und was später kommt (Roadmap). Bewusste „Anti-Goals“ (was wir NICHT tun) werden festgehalten, um den Scope sauber zu halten. Die Priorisierung erfolgt oft nach MoSCoW. Mehrwert: Verhindert Verzettelung und sorgt für schnelle, wertstiftende Releases statt jahrelanger Entwicklung im stillen Kämmerlein.

G – Compliance & Randbedingungen Rechtliche und ethische Vorgaben werden als nicht verhandelbare Ziele („Hard Constraints“) integriert. Dazu gehören Gesetze, Normen und Qualitätsansprüche (NFRs) wie Wartbarkeit und Skalierbarkeit. Mehrwert: Sichert die Rechtssicherheit des Produkts und verhindert technische Schulden durch Vernachlässigung von Qualitätszielen.

H – Dokumentation & Formalismus Es werden Regeln für die Formulierung (lösungsneutral, verständlich) und Darstellung (standardisierte Notation) festgelegt. Jedes Ziel erhält eine ID und eine Begründung („Rationale“), um Nachvollziehbarkeit zu sichern. Mehrwert: Garantiert eine konsistente, missverständnisfreie Kommunikation und verhindert den Verlust von Wissen über das „Warum“ hinter den Zielen.

I – Traceability & Validierung Der Kreis schließt sich: Jede Anforderung muss auf ein Ziel einzahlen („Justification“), und jedes Ziel muss durch Anforderungen abgedeckt sein. Lücken oder unnötiger Ballast („Goldplating“) werden hier identifiziert. Mehrwert: Stellt sicher, dass nur das entwickelt wird, was Business-Wert liefert, und ermöglicht eine lückenlose Kontrolle des Projektfortschritts.

Nr. Frage Operative Implikation & Handlungsanweisung

A

STRATEGIE & WURZEL (ROOT GOALS)

1

Warum wollen wir dieses System überhaupt bauen?

Business Case: Identifizieren Sie den "Root Node". Wenn das oberste Ziel fehlt, ist das Projekt führungslos. K.O.-Kriterium: Kein Projektstart ohne definiertes Business-Ziel.

2

Welches Problem wird gelöst, wenn dieses Ziel erreicht ist?

Rationale: Dokumentieren Sie den Schmerzpunkt ("Pain"). Ein Ziel ohne Problembezug ist oft eine "Lösung auf der Suche nach einem Problem".

3

Wer profitiert davon, wenn dieses Ziel erreicht wird?

Owner: Weisen Sie jedem Oberziel einen Stakeholder zu. Ziele ohne "Paten" werden im Projektverlauf verwaisen.

4

Ist die Wurzel des Baums das strategische Geschäftsziel?

Alignment: Prüfen Sie die Flughöhe. "Login bauen" ist kein Wurzelziel, "Conversion Rate erhöhen" schon. Korrigieren Sie die Hierarchie.

5

Sind die Ziele konsistent zur Produktvision?

Strategy-Check: Legen Sie die Vision neben den Zielbaum. Widersprüche (z.B. Vision "Premium" vs. Ziel "Billigst-Lösung") sofort eskalieren.

6

Dient das Ziel nur der Eitelkeit ("Vanity Goal")?

Relevanz: Streichen Sie Ziele wie "Wir wollen Blockchain nutzen", wenn es keinen fachlichen Grund gibt. Technik ist kein Selbstzweck.

7

Gibt es implizite Ziele, die niemand nennt?

Hidden Agenda: Führen Sie 4-Augen-Gespräche. "Mein Prestige steigern" ist ein reales Ziel, das Risiken birgt. Dokumentieren Sie dies vertraulich (Risikoliste).

8

Sind die Ziele mit den Unternehmenswerten kompatibel?

Culture-Fit: Prüfen Sie Ethik-Richtlinien. Ein Ziel "Daten aggressiv abgreifen" kann zum PR-Desaster führen, wenn die Firma "Vertrauen" als Wert hat.

B

STRUKTUR & DEKOMPOSITION (AND/OR)

9

Gibt es Unterziele, die wir erreichen müssen, um das Hauptziel zu schaffen?

Refinement: Brechen Sie abstrakte Ziele ("Sicher sein") herunter, bis sie greifbar sind ("Verschlüsseln"). Ein Baum mit Tiefe 1 ist wertlos.

10

Müssen ALLE Unterziele erreicht werden, damit das Oberziel gilt?

AND-Logik: Zeichnen Sie die UND-Verknüpfung im Modell ein. Wenn ein UND-Zweig scheitert, scheitert das Oberziel. Risikoanalyse nötig!

11

Reicht es, wenn EINES der Unterziele erreicht wird?

OR-Logik: Nutzen Sie ODER-Verknüpfungen für Design-Alternativen. Dokumentieren Sie, wann die Entscheidung für einen Pfad fallen muss.

12

Gibt es alternative Wege, um dieses Ziel zu erreichen?

Lösungsraum: Fragen Sie aktiv: "Geht das auch ohne Software?". Oft ist eine Prozessänderung (ODER-Zweig) billiger als IT.

13

Ist dieses Unterziel wirklich notwendig für das Oberziel?

Challenge: Schneiden Sie den Baum zurück. Wenn ein Ast wegfallen kann, ohne das Oberziel zu gefährden → Löschen (Waste).

14

Wie detailliert müssen wir das Ziel zerlegen?

Abbruchkriterium: Zerlegen Sie so lange, bis Sie auf eine konkrete Funktion oder NFR (Non-Functional Requirement) stoßen.

15

Reicht die Summe der Unterziele aus, um das Oberziel zu erreichen?

Vollständigkeit: Prüfen Sie die Logik. "Sparen" + "Verdienen" = "Reich". Fehlt was? (z.B. "Nicht bestohlen werden").

16

Wie detailliert ist die ODER-Dekomposition?

Varianten: Haben Sie wirklich alle Optionen (Buy, Build, Partner) geprüft oder nur die erstbeste genommen?

17

Ist der Zielbaum balanciert?

Struktur-Audit: Warnung bei Asymmetrie. Ein Zweig mit 10 Ebenen und einer mit 1 Ebene deutet auf "Analysis Paralysis" oder vergessene Bereiche hin.

18

Gibt es Zyklen im Zielgraphen?

Logik-Fehler: Zirkelbezüge (A braucht B braucht A) sind in der Argumentation verboten. Auflösen!

C

KONFLIKTE & ABHÄNGIGKEITEN

19

Behindern sich diese zwei Ziele (Konflikt)?

Negativ-Kanten: Zeichnen Sie Konflikte ("Blitz"-Symbol) explizit ein. Z.B. "Hohe Sicherheit" vs. "Hohe Usability". Das Management muss entscheiden.

20

Helfen diese zwei Ziele sich gegenseitig (Synergie)?

Positiv-Kanten: Nutzen Sie Synergien für die Priorisierung. Features, die zwei Ziele gleichzeitig bedienen, vorziehen.

21

Welches Ziel hat Vorrang im Konfliktfall?

Entscheidung: Definieren Sie Prioritäten VOR der Krise. "Safety vor Security" oder "Time-to-Market vor Quality"?

22

Widersprechen sich Ziele verschiedener Stakeholder?

Politik: Visualisieren Sie den Konflikt im Baum. Lassen Sie den Sponsor entscheiden, welcher Stakeholder gewinnt.

23

Können wir den Konflikt durch eine ODER-Entscheidung lösen?

Varianten: Bauen Sie Varianten ("Pro-User" vs "Easy-User"), um widersprüchliche Ziele zu entzerren.

24

Wie lösen wir den Konflikt "Zeit vs. Qualität" im Baum?

Trade-off: Dokumentieren Sie die "Technical Debt" Strategie bewusst als Ziel-Entscheidung ("Schnell releasen, später fixen").

25

Wie visualisieren wir Konflikte für das Management?

Kommunikation: Nutzen Sie Konflikt-Diagramme für das Steering Committee. Manager müssen Trade-offs unterschreiben.

26

Wie gehen wir mit Zielen um, die sich gegenseitig ausschließen?

XOR: Setzen Sie harte Exklusiv-Kanten. Wir können nicht "On-Premise Only" UND "Cloud Native" gleichzeitig als Architekturziel haben.

D

KLASSIFIZIERUNG & MESSBARKEIT (KPIs)

27

Ist dieses Ziel ein "Hard Goal" (funktional) oder "Soft Goal" (qualitativ)?

Notation: Unterscheiden Sie visuell (z.B. Rechteck vs. Wolke). Soft Goals können nie zu 100% erfüllt, sondern nur "hinreichend optimiert" (satisficed) werden.

28

Wann gilt dieses Ziel als erreicht?

Akzeptanzkriterien: Definieren Sie harte Abbruchbedingungen. Ohne Kriterium ist das Ziel "fertig", wenn das Budget alle ist.

29

Können wir dieses Ziel messen (Metrik)?

Operationalisierung: Wandeln Sie "Schnell sein" in "Antwortzeit < 200ms" um. Nutzen Sie GQM (Goal-Question-Metric).

30

Beschreibt das Ziel den Zustand "Soll sein" oder "Soll vermieden werden"?

Avoid-Goals: Identifizieren Sie Sicherheitsziele ("Kein Datenverlust"). Diese erfordern oft andere Teststrategien (Negative Testing).

31

Wie messen wir "Soft Goals" wie "Benutzerfreundlichkeit"?

Proxy-Metriken: Nutzen Sie SUS (System Usability Scale) oder Net Promoter Score (NPS) als messbaren Ersatz für das Gefühl "freundlich".

32

Sind die Ziele SMART formuliert?

Qualitäts-Check: Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert. Wenn nicht → Refactoring des Textes.

33

Welches Ziel hat den höchsten ROI (Return on Invest)?

Value: Annotieren Sie Ziele mit Geschäftswert (€). Basis für WSJF (Weighted Shortest Job First) Priorisierung.

E

REALITÄT & MACHBARKEIT

34

Ist das Ziel realistisch erreichbar?

Feasibility: Prüfen Sie physikalische/technische Grenzen. "Echtzeit-Videoübertragung zum Mars ohne Latenz" ist physikalisch unmöglich.

35

Haben wir Ziele, die technisch unmöglich sind?

Technik-Review: Lassen Sie den Lead Architect über den Baum schauen. Markieren Sie Risiken "High Tech Risk".

36

Welche Annahmen (Assumptions) liegen dem Ziel zugrunde?

Kontext: Dokumentieren Sie Annahmen ("User hat Internet"). Wenn die Annahme falsch ist, kollabiert der Baumzweig.

37

Wie dokumentieren wir Annahmen, die sich als falsch erweisen?

Learning Loop: Aktualisieren Sie den Baum in der Retro. Ein falsches Ziel muss gestrichen werden ("Zombie-Ziel").

38

Hängt das Ziel von einem externen System ab?

Dependency: Markieren Sie Ziele, die wir nicht kontrollieren ("Wetterdaten anzeigen"). Hier braucht es Fallback-Ziele.

39

Gibt es gemeinsame Unterziele für verschiedene Oberziele?

Redundanz: Identifizieren Sie "Shared Goals" (z.B. "Logging"). Diese sind kritische Infrastruktur-Komponenten.

F

SCOPE, MVP & ZEIT

40

Welche Ziele müssen im MVP (Minimum Viable Product) sein?

Scoping: Markieren Sie den Baum. MVP = Ein Pfad durch den Baum, der das Wurzelziel minimal erfüllt. Alles andere ausblenden.

41

Was ist das "Minimal Marketable Feature" (MMF) pro Ziel?

Slicing: Definieren Sie das kleinste Release-Paket. Nicht "Ganzes Auto", sondern "Skateboard".

42

Sind die Ziele zeitlich terminiert?

Roadmap: Annotieren Sie Ziele mit "Q1", "Q2", "Later". Ziele ohne Termin werden nie fertig.

43

Gibt es Ziele, die erst später relevant werden?

Phasierung: Unterscheiden Sie "Jetzt bauen" vs. "Architektur vorbereiten".

44

Gibt es Ziele, die wir bewusst nicht verfolgen?

Anti-Goals: Dokumentieren Sie explizit: "Wir bauen KEINE mobile App". Das stoppt Diskussionen sofort.

45

Wie gehen wir mit "Wunsch"-Zielen um?

MoSCoW: Markieren Sie "Could"-Ziele deutlich. Diese sind die ersten Streichkandidaten bei Zeitdruck.

G

COMPLIANCE & RANDBEDINGUNGEN

46

Ist das Ziel durch eine externe Vorschrift erzwungen?

Constraint: Markieren Sie "Must"-Ziele (Gesetze) farblich/fett. Diese sind nicht verhandelbar (Hard Constraint).

47

Gibt es gesetzliche Ziele, die wir noch nicht kennen?

Legal Scan: Beauftragen Sie eine Normen-Recherche. Unwissenheit schützt vor Strafe nicht.

48

Was passiert, wenn wir das Ziel nicht erreichen?

Business Impact: Bewerten Sie den Schaden (Bußgeld, Image, Leben). Hochrisiko-Ziele brauchen mehr QS.

49

Gibt es ethische Ziele?

Ethics: Definieren Sie Leitplanken für KI/Algorithmen (Fairness, Transparenz) als Systemziele.

50

Werden Qualitätsziele (NFRs) separat behandelt?

Architektur: NFRs (Performance, Security) sind oft "Cross-Cutting Concerns". Verlinken Sie diese mit den Funktionszielen.

51

Gibt es Ziele für die Wartbarkeit?

Tech-Goals: Nehmen Sie "Refactoring" und "Clean Code" als explizite Ziele auf, sonst verrottet die Software.

52

Gibt es Ziele für die Performance?

Lastenheft: Definieren Sie Durchsatz und Latenz als harte Ziele, nicht als Prosa.

53

Gibt es Ziele für die Skalierbarkeit?

Zukunft: Definieren Sie "User-Wachstum" als Ziel, damit die Architektur nicht bei Erfolg zusammenbricht.

54

Wie gehen wir mit konkurrierenden Standards als Ziele um?

Harmonisierung: Entscheiden Sie bei Normen-Konflikten (z.B. US-Recht vs. EU-Recht) für den strengeren Standard oder trennen Sie per Zweig.

H

DOKUMENTATION & FORMALISMUS

55

Ist das Ziel in einem Satz verständlich?

Klarheit: Nutzen Sie die Schablone: [Akteur] will [Objekt] [Verb], um [Nutzen]. Keine Passivsätze!

56

Sind die Ziele lösungsneutral formuliert?

Abstraktion: Schreiben Sie "Transportieren" statt "LKW fahren". Lösungsneutralität öffnet Innovation.

57

Ist das Ziel "negativ" formuliert?

Wording: Wandeln Sie "Nicht abstürzen" in "Verfügbar bleiben" um. Positive Ziele sind besser testbar.

58

Nutzen wir eine standardisierte Notation (z.B. KAOS, i*)?

Methodik: Vereinbaren Sie eine Legende. Wenn Kästchen mal "Ziel" und mal "Funktion" bedeuten, entsteht Chaos.

59

Sind die Ziele eindeutig nummeriert/identifizierbar?

ID-Vergabe: G-001, G-002. IDs dürfen sich nie ändern (auch nicht bei Umbenennung des Ziels).

60

Wie visualisieren wir den Zielbaum?

Tooling: Nutzen Sie Diagramm-Tools (Enterprise Architect, Visio, PlantUML). Listen reichen bei Komplexität nicht aus.

61

Sind die Kanten (Pfeile) beschriftet?

Semantik: Ein Pfeil ohne Beschriftung ist mehrdeutig. Heißt er "zerlegt in" oder "hilft"? Beschriften!

62

Nutzen wir "Goal-Oriented Requirements Engineering" (GORE)?

Prozess: Etablieren Sie GORE als Methode. Schulen Sie die REs in Zielmodellierung.

63

Wie dokumentieren wir die Quelle des Ziels?

Traceability: "CEO Interview vom 12.05." muss am Ziel stehen. Verhindert "Wer hat sich das ausgedacht?"-Diskussionen.

64

Wie detailliert dokumentieren wir die Rationale (Begründung)?

Knowledge Management: Schreiben Sie das "Warum" auf. In 2 Jahren weiß niemand mehr, warum das Ziel existiert.

65

Können wir Ziele wiederverwenden (Templates)?

Library: Importieren Sie Standard-Ziele (DSGVO, ISO 27001) aus einer Bibliothek. Spart Zeit und Fehler.

I

TRACEABILITY & VALIDIERUNG

66

Sind die Blätter des Baums konkrete Anforderungen?

Übergang: Prüfen Sie die unterste Ebene. Sind das umsetzbare Items für Jira? Wenn nein → weiter zerlegen.

67

Ist jede Anforderung auf ein Ziel zurückführbar?

Justification: Jede User Story braucht einen Parent-Link zum Ziel. Keine Story ohne Business Value!

68

Gibt es Ziele ohne Anforderungen?

Lücke: Ein Blatt im Zielbaum ohne verlinkte Anforderung bedeutet: Das Ziel wird nicht umgesetzt. Absicht oder Fehler?

69

Gibt es Anforderungen ohne Ziel?

Goldplating: Löschen Sie Anforderungen, die auf kein Ziel einzahlen. Das ist unnötiger Ballast.

70

Wie viele Anforderungen hängen an einem Ziel?

Cluster-Analyse: Wenn an einem Ziel 200 Anforderungen hängen: Ziel ist zu abstrakt → Zwischenebenen einführen.

71

Wurde der Zielbaum von den Stakeholdern abgenommen?

Baseline: Lassen Sie den Baum unterschreiben (digital). Das ist der Scope-Vertrag.

72

Wie hängen Ziele und Geschäftsprozesse zusammen?

Mapping: Verlinken Sie Ziele mit BPMN-Prozessschritten. "Ziel: Zeit sparen" → "Schritt: Manuelle Prüfung (entfällt)".

73

Wie binden wir die Ziele in das Testmanagement ein?

Validierung: Erstellen Sie Testfälle auf Ziel-Ebene ("User Acceptance Test"). Wurde das Business-Ziel erreicht?

74

Ändert sich das Ziel, wenn sich die Anforderung ändert?

Impact Analysis: Nutzen Sie "Suspect Links". Wenn eine Anforderung gestrichen wird, muss das Ziel auf "Gefährdet" springen.

75

Wie visualisieren wir den Fortschritt der Zielerreichung?

Dashboard: Ampel-System für Management. Grün = Alle Anforderungen umgesetzt & getestet.

Strategische Ermittlung (Innovation & Begeisterung)
Um ein Produkt zu schaffen, das am Markt besteht, reicht Pflichterfüllung nicht aus. Mithilfe des Kano-Modells und Prototyping-Techniken identifizieren wir hier die "Begeisterungsfaktoren" (Delighters) und Alleinstellungsmerkmale (USPs). Dieser Schritt ist explorativ und kreativ; hier werden Ideen validiert, noch bevor sie spezifiziert werden.

Details

2.2 Strategische Ermittlung & Prototyping (Operative Audit-Checkliste)

diagram-2-2-mindmap

A – Prototyping Strategie Dieser Abschnitt klärt das Ziel und die Art des Prototyps. Soll Code weggeworfen oder weiterentwickelt werden? Geht es um technische Machbarkeit („Spike“) oder Nutzerführung (UI/UX)? Auch der Detailgrad (Papier vs. High-Fidelity) wird passend zur Projektphase festgelegt. Mehrwert: Verhindert Verschwendung durch falsche Erwartungen (z. B. „Wegwerf-Code“ in Produktion) und fokussiert die Ressourcen auf die richtige Fragestellung (Lernen vs. Verkaufen).

B – Basisfaktoren (Must-Haves - Kano) Hier werden die selbstverständlichen Funktionen identifiziert, die Nutzer nicht explizit fordern, deren Fehlen aber sofort zur Ablehnung führt (z. B. Datensicherheit, Gesetzeskonformität, Stabilität). Diese Faktoren sind Hygienefaktoren. Mehrwert: Schützt das Produkt vor dem Scheitern am Markt, da diese Kriterien das Fundament der Akzeptanz bilden und Priorität 0 („Must-Fix“) haben.

C – Leistungsfaktoren (Performance - Kano) Es werden Funktionen ermittelt, bei denen „mehr“ direkt „besser“ bedeutet (z. B. Speicherplatz, Geschwindigkeit, Analysetiefe). Diese Faktoren werden vom Nutzer bewusst verglichen und gefordert. Mehrwert: Definiert die Wettbewerbsfähigkeit und ermöglicht gezieltes „Upselling“ durch bessere Leistungspakete für zahlende Kunden.

D – Begeisterungsfaktoren (Delighters - Kano) Dieser Bereich sucht nach unerwarteten Funktionen, die einen „Wow-Effekt“ auslösen (z. B. KI-Vorschläge, Offline-Modus). Diese Merkmale differenzieren das Produkt vom Wettbewerb (USP). Mehrwert: Schafft emotionale Kundenbindung und fördert Weiterempfehlungen, da Nutzer positiv überrascht werden.

E – Indifferent & Rückweisend (Waste/Risiko) Hier werden Funktionen identifiziert, die dem Nutzer egal sind (Indifferenz) oder ihn sogar stören (Rückweisung, z. B. Autoplay-Musik, Zwangsanmeldung). Solche „Features“ werden gestrichen. Mehrwert: Spart Entwicklungsbudget durch Weglassen unnötiger Funktionen („De-Scoping“) und verhindert Frustration bei den Anwendern.

F – Kano-Methodik (Fragebogen) Dieser Abschnitt beschreibt, wie die Kano-Analyse methodisch korrekt durchgeführt wird. Durch funktionale („Gibt es“) und dysfunktionale („Fehlt es“) Fragen werden die Anforderungen klassifiziert. Auch Segmentierung und Kontrollfragen sichern die Datenqualität. Mehrwert: Liefert datenbasierte Entscheidungsgrundlagen für die Priorisierung und verhindert, dass Bauchgefühl über die Feature-Liste entscheidet.

Nr. Frage Operative Implikation & Handlungsanweisung

A

PROTOTYPING STRATEGIE

1

Was ist das primäre Ziel des Prototyps?

Ziel-Klarheit: Definieren Sie: Lernen wir (Wegwerf) oder bauen wir (Evolution)? Ein Prototyp ohne klare Forschungsfrage ist Geldverschwendung.

2

Soll der Prototyp nach dem Test weggeworfen werden (Wegwerfprototyp)?

Erwartungsmanagement: Kommunizieren Sie dem Management: "Dieser Code kommt in den Müll". Sonst landet schlechter Bastel-Code in der Produktion (Technische Schulden).

3

Soll der Prototyp zur echten Anwendung weiterentwickelt werden (Evolutionär)?

Code-Qualität: Wenn evolutionär: Starten Sie sofort mit sauberer Architektur und Tests. Kein "Quick & Dirty" erlaubt.

4

Wollen wir technische Risiken prüfen (Technischer Durchstich)?

Risiko-Minimierung: Bauen Sie einen "Spike" (PoC) für die kritischste Komponente (z.B. DB-Last), bevor Sie das UI malen.

5

Geht es primär um die Benutzeroberfläche (UI/UX)?

Fokus: Wenn es um UX geht, faken Sie das Backend. Verschwenden Sie keine Zeit mit Datenbank-Anbindung.

6

Reicht eine Skizze auf Papier (Low-Fidelity)?

Effizienz: Nutzen Sie in Phase 1 Papier/Whiteboard. Wer sofort in Figma pixel-perfect designt, verliebt sich zu früh in die falsche Lösung.

7

Benötigen wir einen klickbaren Dummy am Bildschirm (Medium-Fidelity)?

Interaktion: Bauen Sie Click-Dummys, um den "Flow" zu testen. Statische Bilder offenbaren keine Navigations-Sackgassen.

8

Muss der Prototyp wie das fertige Produkt aussehen (High-Fidelity)?

Verkaufs-Modus: Nur für Investor-Pitches oder End-User-Tests nutzen. Warnung: Stakeholder halten Hi-Fi oft für "fast fertig".

9

Muss der Prototyp auf echter Hardware laufen (Native Prototyp)?

Kontext-Check: Testen Sie Touch-Ziele auf dem echten iPad, nicht mit der Maus am PC. Maus-Präzision verfälscht das Ergebnis.

10

Soll der Prototyp "breit" sein (Horizontaler Prototyp)?

Scope-Visualisierung: Bauen Sie das Menü und die Navigation komplett, um die Größe der Anwendung zu begreifen (auch wenn die Seiten leer sind).

11

Soll der Prototyp "tief" sein (Vertikaler Prototyp)?

Prozess-Validierung: Wählen Sie den kritischsten Kernprozess und bauen Sie ihn Ende-zu-Ende. Nur so finden Sie Logiklücken.

12

Welche konkreten Szenarien sollen abgebildet werden?

Drehbuch: Schreiben Sie Skripte für die Tester. Wildes Herumklicken liefert keine vergleichbaren Ergebnisse.

13

Muss der Prototyp mit echten Daten arbeiten?

Realitäts-Check: Nutzen Sie echte Namen (lange Doppelnamen!) statt "Max Mustermann". Lorem Ipsum versteckt Layout-Probleme.

109

Sollen wir Wettbewerbsprodukte als "Prototyp" nutzen?

Benchmark: Sparen Sie Bauzeit. Lassen Sie Nutzer Konkurrenz-Apps bedienen und beobachten Sie, wo sie scheitern.

110

Sollen wir Variationen testen (A/B/C)?

Alternativen: Verlieben Sie sich nicht in Idee A. Testen Sie radikal andere Ansätze gegeneinander.

111

Nutzen wir "Storyboard" Techniken vor dem Prototyp?

Kontext: Zeichnen Sie den Nutzer in seiner Umgebung (Comic). Löst die App das Problem im Kontext (z.B. im Regen an der Bushaltestelle)?

112

Können wir Teile des Codes wiederverwenden?

Effizienz: Klären Sie VORHER, ob das Frontend-Framework des Prototyps auch für die Prod-Entwicklung taugt (z.B. React).

113

Soll der Prototyp verkauft werden (MVP)?

Business: Wenn Geld fließt, ist es kein Prototyp mehr, sondern Produktion. SLA und Support müssen stehen!

B

BASISFAKTOREN (MUST-HAVES - KANO)

14

Welche Funktionen setzen Sie als absolut selbstverständlich voraus?

Hygiene-Faktoren: Fragen Sie nicht "Was wollen Sie?", sondern "Was darf auf keinen Fall fehlen?". Das Fehlen dieser Punkte killt das Produkt sofort.

15

Was würde Sie sofort dazu bringen, das Produkt zurückzugeben?

K.O.-Kriterien: Erstellen Sie eine "Blacklist". Diese Punkte haben Priorität 0 (Must-Fix).

16

Welche gesetzlichen Vorgaben müssen zwingend eingehalten werden?

Compliance: DSGVO, GoBD, Barrierefreiheit. Das sind implizite Basisfaktoren. Nichtbeachtung ist fahrlässig.

17

Welche Standards oder Normen sind in Ihrer Branche unverzichtbar?

Marktfähigkeit: Ein Buchhaltungstool ohne DATEV-Export ist unverkäuflich. Prüfen Sie Branchenstandards.

18

Was erwarten Sie von der Stabilität des Systems?

Qualität: Definieren Sie Verfügbarkeit (99,x%). Niemand applaudiert, wenn es läuft, aber jeder schreit, wenn es abstürzt.

19

Welche Sicherheitsfeatures sind für Sie nicht verhandelbar?

Security: 2FA, Verschlüsselung. Das ist heute Standard, kein Feature.

20

Gibt es Funktionen, die das alte System hatte, die im neuen auf keinen Fall fehlen dürfen?

Legacy-Falle: Analysieren Sie das Altsystem. Nutzer akzeptieren keinen Funktionsverlust bei Migration ("Regression").

21

Wie schnell muss das System reagieren, damit Sie nicht genervt sind?

Performance: Latenz < 1s ist oft Basis. Alles darüber erzeugt Frust (Dissatisfier).

22

Welche Daten müssen auf jeden Fall auf der Rechnung stehen?

Korrektheit: Fehlende Pflichtangaben machen das System rechtlich nutzlos.

23

Müssen Sie das System auch ohne Maus bedienen können?

Accessibility/Power-User: Tab-Navigation ist für Profis ein Basisfaktor. Mauszuhause ist ineffizient.

24

Erwarten Sie eine Hilfefunktion oder ein Handbuch?

Support: Onboarding/Hilfe muss da sein. Fehlt sie, steigen die Supportkosten.

25

Muss das System auf Ihrem aktuellen Betriebssystem laufen?

Kompatibilität: Wenn der CEO einen Mac nutzt, ist macOS-Support ein Basisfaktor (politisch).

26

Welche Sprachen muss die Benutzeroberfläche unterstützen?

Lokalisierung: In internationalen Konzernen ist Englisch Pflicht. Starten Sie nicht "Deutsch-Only".

27

Wie sieht es mit der Datensicherung (Backup) aus?

Data Safety: Automatisches Backup wird vorausgesetzt. Datenverlust ist der Tod des Produkts.

28

Erwarten Sie eine Löschfunktion für Ihre Daten?

DSGVO: "Recht auf Vergessenwerden". Löschen ist technisch schwerer als Erstellen, muss aber sein.

29

Muss das System offline funktionieren?

Kontext: Wenn die Zielgruppe im Keller/Tunnel arbeitet, ist Offline-Fähigkeit ein Must-Have.

30

Welche Export-Formate sind Minimum?

Datenhoheit: PDF/Excel-Export wird erwartet. Nutzer wollen ihre Daten "in der Hand" haben.

31

Wie genau müssen Berechnungen sein?

Präzision: Rundungsfehler im Cent-Bereich sind inakzeptabel. Nutzen Sie BigDecimal statt Float.

32

Muss das System mandantenfähig sein?

Architektur: Für B2B-SaaS ein Basisfaktor. Nachträglicher Einbau ist fast unmöglich (Architektur-GAU).

33

Erwarten Sie eine Bestätigung nach einer Aktion?

Feedback: Systemstatus muss sichtbar sein. "Hat es geklappt?" darf keine Frage sein.

C

LEISTUNGSFAKTOREN (PERFORMANCE - KANO)

34

Welche Funktionen würden Ihre Arbeit am meisten beschleunigen?

Effizienz: Hier gilt: "Mehr ist besser". Optimieren Sie Klickwege für diese Features.

35

Worauf achten Sie beim Vergleich mit Konkurrenzprodukten besonders?

Benchmark: Identifizieren Sie die Vergleichs-Metriken (GB Speicher, Megapixel, Speed). Hier müssen Sie besser sein als der Schnitt.

36

Je mehr das System von [X] kann, desto zufriedener sind Sie?

Skalierung: Identifizieren Sie lineare Treiber (Speicherplatz, Anzahl User). Planen Sie hierfür Upselling-Pakete.

37

Welche Berichte benötigen Sie, um bessere Entscheidungen zu treffen?

Insight: Tiefe der Datenanalyse ist ein Leistungsmerkmal. Bessere Reports = Höherer Wert.

38

Wie wichtig ist Ihnen eine individuelle Anpassbarkeit der Oberfläche?

Flexibilität: Dashboard-Widgets verschieben. Power-User fordern das.

39

Würden Sie für eine schnellere Bearbeitungszeit mehr bezahlen?

Monetarisierung: Identifizieren Sie "Express-Features". Hier liegt Zahlungsbereitschaft.

40

Welche Suchfilter vermissen Sie aktuell?

Findbarkeit: Facettierte Suche (Filter nach X, Y, Z) ist ein starker Leistungstreiber.

41

Wie viele Datensätze wollen Sie gleichzeitig bearbeiten können?

Bulk-Edit: Massenbearbeitung spart Zeit. Ein starkes Argument für Profi-Nutzer.

42

Wünschen Sie sich eine Integration zu Outlook/Kalender?

Ökosystem: Nahtlose Integration in Office 365 ist im B2B ein massiver Leistungsvorteil.

43

Wie detailliert soll die Historie/das Protokoll sein?

Audit: Lückenloses Änderungsprotokoll schafft Vertrauen und Sicherheit.

44

Wäre eine Sprachsteuerung für Sie hilfreich?

Hands-Free: In speziellen Kontexten (Arzt, Werkstatt) ein Leistungsfaktor, im Büro eher Spielerei.

45

Sollen Daten automatisch vervollständigt werden (Autofill)?

Convenience: Spart Tipparbeit. Adress-Vervollständigung reduziert Abbruchraten.

46

Wie wichtig ist Ihnen ein Dark Mode?

Ergonomie: Heute oft schon Basisfaktor bei Entwicklern/Designern, sonst Leistungsfaktor.

47

Wollen Sie Benachrichtigungen per SMS, Mail oder Push erhalten?

Multi-Channel: Geben Sie dem Nutzer die Wahl. Kanal-Flexibilität erhöht die Erreichbarkeit.

48

Sollen wir Vorlagen für wiederkehrende Aufgaben bereitstellen?

Standardisierung: Templates sparen Zeit und sichern Qualität.

49

Wie umfangreich soll die Rechteverwaltung sein?

Governance: Granulare Rechte (Feld-Ebene) ermöglichen den Einsatz in komplexen Organisationen.

50

Wollen Sie Daten auch als Grafik/Chart sehen?

Visualisierung: Management liebt Dashboards. Ein starker Verkaufsfaktor.

51

Soll das System auf Tablets optimiert dargestellt werden?

Portabilität: Responsive Design ist heute oft Basis, spezifische Tablet-UI ein Leistungsfaktor.

52

Wünschen Sie sich eine Import-Funktion für Excel?

Onboarding: Senkt die Hürde für den Wechsel zum neuen System.

D

BEGEISTERUNGSFAKTOREN (DELIGHTERS - KANO)

53

Wie wichtig ist Ihnen eine direkte Chat-Funktion zum Support?

Service: Direkter Draht (Intercom/Chat) überrascht positiv und bindet Kunden.

54

Womit könnten wir Sie bei diesem Produkt völlig überraschen?

Innovation: Suchen Sie den "Wow"-Effekt. Etwas, das der Kunde nicht erwartet hat.

55

Welche Funktion kennen Sie aus Ihrem Privatleben (Apps), die Sie hier gerne hätten?

Consumerization: "Tinder-Swipe" für Bewerber? UX-Muster aus B2C übertragen begeistert B2B-Nutzer.

56

Was wäre, wenn das System diesen Schritt für Sie automatisch erledigt?

Automatisierung: Magie entsteht, wenn Arbeit verschwindet (z.B. Belegerkennung per Foto).

57

Würden Sie sich über eine spielerische Komponente (Gamification) freuen?

Motivation: Badges/Fortschrittsbalken können trockene Aufgaben auflockern (Vorsicht: Nicht kindisch wirken!).

58

Wie fänden Sie es, wenn das System per KI Vorschläge macht?

AI-Assistance: "Kunden, die das kauften…​" – Relevante Vorschläge sind starke Delighter.

59

Was wäre ein "Killer-Feature", das kein Konkurrent hat?

USP: Das Alleinstellungsmerkmal. Ohne das sind Sie nur "Me-Too".

60

Wäre eine Sprachsteuerung, die Dialekte versteht, nützlich?

Robustheit: Übererfüllung von Anforderungen (z.B. extrem hohe Fehlertoleranz) begeistert.

61

Wie wäre es mit einem Design, das sich Ihrer Stimmung anpasst?

Emotionalisierung: Dynamische Hintergründe/Begrüßungen schaffen Bindung.

62

Was wäre, wenn das System Fehler vorhersagt, bevor sie passieren?

Predictive: Wartung bevor der Ausfall passiert. Das spart dem Kunden echtes Geld.

63

Hätten Sie gerne eine Augmented Reality (AR) Unterstützung?

Tech-Innovation: AR im Lager/Wartung. Prüfen Sie, ob es Spielerei oder echter Nutzen ist.

64

Würde es Sie begeistern, wenn das System komplett ohne Login funktioniert (Biometrie)?

Frictionless: FaceID statt Passwort-Eingabe. Entfernt Hürden.

65

Was wäre, wenn Sie das System per Gedanken steuern könnten?

Vision: Nutzen Sie Sci-Fi-Szenarien im Workshop, um mentale Blockaden zu lösen ("Blue Sky Thinking").

66

Wie fänden Sie eine persönliche Begrüßung mit Namen beim Start?

Personalisierung: Kleine Geste, große Wirkung. Fühlt sich weniger nach "Maschine" an.

67

Wäre ein integriertes Lern-Tutorial für neue Features toll?

Onboarding: Interaktive Guides (Walkthroughs) begeistern mehr als PDF-Handbücher.

68

Was halten Sie von einer "Rückgängig"-Funktion für E-Mails (5 Sek. Verzögerung)?

Fehlertoleranz: Ein "Undo"-Button rettet Leben und begeistert durch Stressreduktion.

69

Wie wäre es, wenn das System für Sie Kaffee kocht (IoT)?

Vernetzung: Physische Schnittstellen verbinden digitale und reale Welt.

70

Würde Ihnen eine extrem schnelle Suche (< 0,1 Sek) auffallen?

Instant-Feedback: Performance, die sich "sofort" anfühlt, wird als hohe Qualität wahrgenommen.

71

Was wäre, wenn das System optisch genau wie Ihr Lieblingsspiel aussieht?

Theming: Skins/Themes erlauben Identifikation mit dem Tool.

72

Hätten Sie gerne eine Zusammenfassung Ihres Arbeitsjahres?

Storytelling: "Spotify Wrapped" für Business-Daten. Zeigt dem Nutzer seinen Erfolg.

73

Was wäre, wenn das System offline besser funktioniert als online?

Paradoxon: "Local First" Ansatz. Keine Ladebalken mehr. Massiver Delighter.

E

INDIFFERENT & RÜCKWEISEND (WASTE/RISIKO)

74

Welche Funktionen im aktuellen System nutzen Sie nie?

De-Scoping: Identifizieren Sie "Leichen". Bauen Sie nichts nach, nur weil es im Altsystem war. Mut zum Löschen!

75

Stört es Sie, wenn das System jeden Tag Updates macht?

Reverse: Zu viel Agilität nervt. Finden Sie die richtige Frequenz. Nutzer wollen arbeiten, nicht updaten.

76

Brauchen Sie wirklich eine Fax-Integration?

Legacy-Check: Hinterfragen Sie veraltete Anforderungen kritisch. Oft ist es nur "Gewohnheit".

77

Finden Sie animierte Menüs hilfreich oder nervig?

Polarisierung: Animationen kosten Zeit. Machen Sie sie abschaltbar ("Reduce Motion").

78

Wäre es schlimm, wenn wir das Feature X weglassen?

Indifferenz-Test: Wenn die Antwort "Egal" ist → Streichen! Spart Entwicklung und Wartung.

79

Stört Sie die automatische Musik auf der Startseite?

No-Go: Autoplay (Video/Audio) ist ein klassisches Rückweisungsmerkmal. Niemals tun.

80

Ist Ihnen die Farbe des Speichern-Buttons egal?

Design-Freiheit: Verschwenden Sie keine Meeting-Zeit mit Dingen, die dem Nutzer egal sind. Entscheiden Sie einfach.

81

Fühlen Sie sich durch zu viele Hilfetexte bevormundet?

Experten-Modus: Zu viel "Händchenhalten" nervt Profis. Assistenten müssen ausblendbar sein.

82

Brauchen Sie eine Wetteranzeige im Buchhaltungsprogramm?

Bloatware: Feature Creep vermeiden. Bleiben Sie im Kern-Domain-Kontext.

83

Würde es Sie stören, wenn Sie das Passwort alle 2 Tage ändern müssen?

Security-Theater: Übertriebene Sicherheit behindert die Arbeit und führt zu Zetteln am Monitor.

84

Ist es Ihnen egal, welche Datenbank-Technologie wir nutzen?

Technik: Belästigen Sie Nutzer nicht mit internen Details. Das ist eine Architekten-Entscheidung.

85

Nerven Sie zu viele E-Mail-Benachrichtigungen?

Spam-Faktor: Default sollte "wenig Mails" sein. Nutzer opt-in lassen.

86

Brauchen Sie eine 3D-Ansicht der Daten?

Gimmick: Oft unleserlich. 2D-Balken sind meist besser. Prüfen Sie den Informationsgehalt.

87

Stört es Sie, wenn Sie sich mit Social-Media-Accounts einloggen müssen?

Zwang: Facebook-Zwang im B2B ist ein Showstopper. Immer Alternative (E-Mail) anbieten.

88

Ist Ihnen der Name des internen Servers egal?

Information Hiding: Verstecken Sie technische Interna in Fehlermeldungen/UIs.

F

KANO-METHODIK (FRAGEBOGEN)

89

Frage: Wie würden Sie sich fühlen, wenn das Feature X vorhanden ist?

Funktionale Frage: Standard-Kano. Skala muss exakt sein: "Das setze ich voraus" vs. "Das freut mich".

90

Frage: Wie würden Sie sich fühlen, wenn das Feature X NICHT vorhanden ist?

Dysfunktionale Frage: Zwingend nötig zur Klassifizierung. Ohne Gegenfrage kein Kano!

91

Wie wichtig ist Ihnen dieses Feature insgesamt (Wichtigkeitsskala)?

Gewichtung: Ein "Basisfaktor", der unwichtig ist, darf buggy sein. Ein "wichtiger" Basisfaktor muss perfekt sein.

92

Würden Sie das Feature nutzen, wenn es da wäre?

Nutzungswahrscheinlichkeit: Trennen Sie "Finde ich gut" von "Werde ich nutzen".

93

Können Sie das Fehlen des Features tolerieren?

Härtegrad: Unterscheiden Sie "Nice-to-have" von "Showstopper".

94

Ist dieses Feature für Sie eher ein Werkzeug oder ein Spielzeug?

Einordnung: Hilft bei der Entscheidung, ob es in die "Pro"-Version oder "Basic" kommt.

95

Haben Sie dieses Feature bei einem Wettbewerber gesehen?

Marktdruck: Wenn alle es haben, ist es wahrscheinlich ein Basisfaktor (Commodity).

96

Wie oft haben Sie sich über das Fehlen dieses Features schon geärgert?

Pain-Level: Hohe Frequenz deutet auf dringenden Handlungsbedarf hin.

97

Würden Sie das Produkt weiterempfehlen, wenn es Feature X hat?

NPS-Treiber: Begeisterungsfaktoren treiben Empfehlungen. Basisfaktoren verhindern nur Abwanderung.

98

Was ist der Hauptgrund, warum Sie Feature X wollen?

5-Whys: Verstehen Sie das Problem, nicht den Lösungswunsch. Oft gibt es eine einfachere Lösung.

99

Wenn Sie 100€ hätten, wie viel würden Sie auf dieses Feature wetten?

Priorisierung: "Buy a Feature" Spiel. Zwingt Nutzer zu echten Entscheidungen bei begrenztem Budget.

100

Verändert sich Ihre Meinung zu diesem Feature über die Zeit?

Gewöhnung: Delighter von heute sind die Basisfaktoren von morgen (z.B. WLAN im Hotel). Planen Sie Updates.

101

Welche Benutzergruppe sind Sie?

Segmentierung: Werten Sie Kano NIEMALS über alle Nutzer aus. Segmentieren Sie nach Persona (Profi vs. Anfänger).

102

Haben Sie die Frage richtig verstanden? (Kontrollfrage)

Qualitätssicherung: Bauen Sie Fallen/Kontrollen in den Fragebogen ein, um "Klick-Bots" oder unaufmerksame Leser auszufiltern.

103

Gibt es Abhängigkeiten zu anderen Features, die Ihre Antwort beeinflussen?

Kontext: Feature A macht nur Sinn mit Feature B. Fragen Sie diese Kombi ab.

Fachliche Ermittlung (Daten & Funktionen)
Dies ist der Kern der klassischen Analyse. Wir ermitteln, welche Daten das System speichern und verarbeiten muss (Datenstrukturen, Geschäftsobjekte) und welche Aufgaben es erledigen soll (Geschäftsprozesse, Use Cases). Wir klären die Logik hinter den Abläufen und stellen sicher, dass die fachliche Welt korrekt in Anforderungen übersetzt wird.

Details

2.3 Fachliche Ermittlung: Datenmodell & Funktionsspezifikation (Operative Audit-Checkliste)

diagram-2-3-mindmap

A – Datenobjekte & Entitäten (Core Data) Dieser Abschnitt bildet das Fundament der Software, indem die zentralen Geschäftsobjekte (z. B. „Auftrag“) und deren Beziehungen definiert werden. Es klärt Fragen zu Persistenz (Speichern vs. Flüchtig), Eindeutigkeit (IDs) und Verantwortlichkeit (Data Owner). Mehrwert: Verhindert Architekturfehler, Redundanz und Datenchaos durch ein sauberes, normalisiertes Datenmodell.

B – Attribute & Datenqualität Hier wird definiert, welche Informationen pro Objekt gespeichert werden, inklusive Datentypen, Pflichtfeldern und Validierungsregeln (z. B. Wertebereiche, Formate). Auch Berechnungslogiken und Abhängigkeiten zwischen Feldern werden spezifiziert. Mehrwert: Sichert hohe Datenqualität durch technische Schranken („Constraints“) und verhindert Fehleingaben oder Berechnungsfehler.

C – Beziehungen & Abhängigkeiten Es werden die Verknüpfungen zwischen Objekten (z. B. 1:n, m:n) und deren Verhalten bei Löschung (Referenzielle Integrität) festgelegt. Auch semantische Rollen und Historisierungsanforderungen („Wer war letztes Jahr Chef?“) werden geklärt. Mehrwert: Gewährleistet logische Konsistenz in der Datenbank und vermeidet verwaiste Datensätze oder falsche Zuordnungen.

D – Lebenszyklus, Status & Historie Dieser Bereich definiert die erlaubten Zustände eines Objekts (State Machine) und die Regeln für Statusübergänge. Zudem werden Anforderungen an Audit-Trails (Wer änderte was?), Archivierung und gesetzeskonformes Löschen (Retention Policies) festgelegt. Mehrwert: Sichert Compliance und Nachvollziehbarkeit und verhindert Datenmüll durch geregelte Lebenszyklen.

E – Mengengerüst, Performance & Migration Hier werden das erwartete Datenvolumen und Wachstum sowie die Zugriffsfrequenzen (Lese-/Schreiblast) geschätzt. Auch Anforderungen an die Geschwindigkeit von Suchabfragen und Strategien für die Ablösung von Altsystemen werden betrachtet. Mehrwert: Ermöglicht das korrekte Sizing der Hardware und verhindert Performance-Engpässe bei steigenden Nutzerzahlen.

F – Suche, Filter & Reporting Es wird festgelegt, wie Daten gefunden, gefiltert und für Berichte aufbereitet werden. Dies umfasst Volltextsuche, Filterlogiken, Aggregationen für Dashboards und Datenschutzmaßnahmen (Maskierung) in Reports. Mehrwert: Macht Daten nutzbar und wertvoll für Entscheidungen, schützt aber gleichzeitig sensible Informationen vor unbefugtem Zugriff.

G – Glossar & Begrifflichkeiten (Definition) Dieser Abschnitt fordert die Erstellung eines zentralen Glossars, um Fachbegriffe eindeutig zu definieren und Synonyme oder Homonyme zu bereinigen. Es dient als "Ubiquitous Language" für alle Beteiligten. Mehrwert: Verhindert teure Missverständnisse durch unklare Sprache und erleichtert neuen Teammitgliedern das Verständnis der Fachdomäne.

H – Datenaustausch & Interface-Logik Hier werden Regeln für Import und Export definiert: Formate (XSD, JSON), Validierung vor dem Import und Fehlerbehandlung. Auch die Frage nach dem führenden System („Master“) wird geklärt. Mehrwert: Sichert die Integrität der Daten beim Austausch mit anderen Systemen und verhindert, dass „Schrottdaten“ importiert werden.

I – Funktionale Anforderungen & Prozesse Dieser Bereich beschreibt die eigentliche Logik: Welche Aufgaben (Use Cases) erledigt der Nutzer? Es werden Auslöser, Abläufe, Fehlerbehandlung („Unhappy Path“) und Berechtigungen definiert. Mehrwert: Liefert den konkreten Bauplan für die Entwicklung der Geschäftslogik und stellt sicher, dass alle Prozessvarianten abgedeckt sind.

Nr. Frage Operative Implikation & Handlungsanweisung

A

DATENOBJEKTE & ENTITÄTEN (CORE DATA)

1

Welche zentralen fachlichen Objekte müssen im System verwaltet werden?

Domain Model: Identifizieren Sie die Kern-Entitäten (z.B. "Auftrag"). Erstellen Sie ein klassisches ER-Modell oder Klassendiagramm. Ohne sauberes Datenfundament stürzt die Architektur ein.

2

Gibt es Objekte, die nur als Konzept existieren, aber nicht gespeichert werden müssen?

Persistenz-Check: Unterscheiden Sie transiente Objekte (Warenkorb-Session) von persistenten (Bestellung). Speichern Sie nichts, was nicht gespeichert werden muss (Datenmüllvermeidung).

3

Wie genau definieren Sie das Objekt [X] in einem Satz?

Definition: Vermeiden Sie schwammige Begriffe. Eine Definition muss diskriminierend sein (Was ist es NICHT?). Eintrag ins Glossar ist Pflicht.

4

Gibt es verschiedene Typen oder Varianten dieses Objekts?

Vererbung vs. Typisierung: Entscheiden Sie: Brauchen wir Subklassen (Privatkunde/Firmenkunde) oder reicht ein Typ-Attribut? Falsche Vererbung führt zu komplexem Code.

5

Haben diese Varianten unterschiedliche Eigenschaften oder Verhaltensweisen?

Normalisierung: Wenn Varianten völlig unterschiedliche Felder haben → Separate Tabellen oder Single-Table-Inheritance prüfen. Keine NULL-Wüsten in der DB erzeugen.

6

Gibt es eine übergeordnete Gruppe, zu der dieses Objekt gehört?

Generalisierung: Identifizieren Sie abstrakte Klassen (z.B. "Fahrzeug"), um Redundanz im Code und in der Datenbank zu vermeiden.

7

Ist dieses Objekt ein physischer Gegenstand oder ein immaterielles Konzept?

Asset Management: Physische Objekte brauchen Inventarnummern und Standorte. Immaterielle (z.B. Lizenzen) brauchen Gültigkeitsdaten.

8

Wer ist der Eigentümer (Owner) dieses Datenobjekts im Unternehmen?

Data Stewardship: Benennen Sie EINEN Verantwortlichen (z.B. Head of Sales für Kundendaten). Ohne Owner verkommt die Datenqualität.

9

Ist das Objekt weltweit eindeutig identifizierbar?

Primary Keys: Definieren Sie natürliche Schlüssel (ISBN, VIN) oder künstliche Schlüssel (UUID). Verlassen Sie sich nie auf Namen als ID!

10

Wer darf neue Instanzen dieses Objekts anlegen?

Create-Berechtigung: Schränken Sie die Erstellung kritischer Stammdaten (Kreditoren, Artikel) restriktiv ein. Verhindert Dubletten.

B

ATTRIBUTE & DATENQUALITÄT

11

Welche spezifischen Informationen müssen wir zu diesem Objekt speichern?

Data Dictionary: Listen Sie alle Felder auf. "Wir speichern alles" ist keine Anforderung. Jedes Feld kostet Geld (Migration, UI, Pflege).

12

Welche dieser Informationen sind Pflichtfelder und welche sind optional?

Constraints: Definieren Sie NOT NULL Constraints in der DB. Zu viele optionale Felder deuten auf ein schlechtes Schnittstellen-Design hin.

13

Welchen Datentyp haben die Attribute?

Präzision: Geld ist Decimal, niemals Float. Datum ist ISO8601. Definieren Sie technische Typen präzise für die Entwickler.

14

Gibt es festgelegte Wertebereiche für dieses Attribut?

Validierung: Definieren Sie Min/Max-Werte (Alter > 0, Rabatt ⇐ 100%). Sichern Sie dies in der Datenbank und im Frontend ab.

15

Sollten wir für dieses Feld eine Auswahlliste statt eines Freitextes verwenden?

Standardisierung: Vermeiden Sie Freitext wo immer möglich! Nutzen Sie Enums/Lookups (z.B. Ländercodes), um Tippfehler zu verhindern.

16

Gibt es Standardwerte, die beim Anlegen vorausgefüllt sein sollen?

Usability: Definieren Sie Defaults (z.B. "Land = Deutschland"), um Klicks zu sparen. Prüfen Sie, ob Defaults fachlich gefährlich sein können.

17

Muss der Wert dieses Attributs im gesamten System eindeutig sein?

Unique Constraint: E-Mail-Adressen oder Sozialversicherungsnummern müssen technisch einzigartig erzwungen werden.

18

Gibt es Formatvorgaben?

Regex: Definieren Sie Reguläre Ausdrücke für PLZ, IBAN, Telefonnummern. Lassen Sie keine Phantasieformate zu.

19

Wird dieser Wert vom Benutzer eingegeben oder vom System berechnet?

Redundanz-Check: Speichern Sie keine berechneten Werte (z.B. Alter), sondern die Basis (Geburtsdatum), außer aus Performance-Gründen (Caching).

20

Wenn berechnet: Auf welcher Formel basiert die Berechnung?

Logik-Spezifikation: Dokumentieren Sie die Formel exakt (inkl. Rundungsregeln!). "Mehrwertsteuer berechnen" ist als Anforderung zu ungenau.

21

Gibt es Abhängigkeiten zwischen Werten verschiedener Attribute?

Plausibilität: Wenn Land="USA", darf PLZ nicht 5-stellig numerisch sein. Cross-Field-Validierung definieren.

22

Darf ein Wert nur geändert werden, wenn er größer als der vorherige ist?

Monotonie: Kilometerstände oder Zählerstände dürfen nicht sinken. Validierungsregel implementieren.

23

Gibt es bedingte Pflichtfelder?

Logik: Feld B wird Pflicht, wenn Feld A den Wert X hat. Dokumentieren Sie diese Abhängigkeiten in einer Matrix.

24

Gibt es Regeln für die Formatierung bei der Ausgabe?

Presentation Layer: Trennen Sie Speicherformat (49170…​) von Anzeigeformat (+49 170…​). Definieren Sie Masken.

C

BEZIEHUNGEN & ABHÄNGIGKEITEN

25

Mit welchen anderen Objekten ist dieses Objekt verknüpft?

Relationen: Zeichnen Sie Verbindungslinien. Isolierte Objekte sind verdächtig (Dateninseln).

26

Wie viele Objekte B können einem Objekt A zugeordnet sein?

Kardinalität: 1:1, 1:n oder m:n? Das bestimmt das DB-Design (Fremdschlüssel vs. Mapping-Tabelle). Falsche Annahmen hier sind teuer.

27

Ist die Beziehung zwingend erforderlich?

Integrität: Darf eine Bestellung ohne Kunde existieren? Wenn nein → Foreign Key Constraint erzwingen.

28

Besteht eine Teil-Ganzes-Beziehung?

Komposition: Wenn das Ganze (Auto) gelöscht wird, muss das Teil (Rad) mitgelöscht werden? Klären Sie "Cascading Delete".

29

Wenn das Hauptobjekt gelöscht wird, sollen dann auch die Bestandteile gelöscht werden?

Referenzielle Integrität: Verhindern Sie verwaiste Datensätze (Orphans) durch strikte DB-Regeln.

30

Kann ein Objekt gleichzeitig mehreren anderen Objekten zugeordnet sein?

Komplexität: m:n Beziehungen erfordern oft Zusatzattribute an der Beziehung (z.B. "Zeitraum der Zuordnung").

31

Welche Rolle spielt das Objekt in dieser Beziehung?

Semantik: Benennen Sie die Kanten im Diagramm. Ein Mitarbeiter kann "Chef von" oder "Assistent von" sein.

32

Ändern sich diese Beziehungen im Laufe der Zeit?

Historisierung: Brauchen wir "Slowly Changing Dimensions"? Müssen wir wissen, wer letztes Jahr der Chef war?

33

Gibt es Abhängigkeiten, die verhindern, dass eine Beziehung gelöst wird?

Löschschutz: Verhindern Sie das Löschen von Stammdaten, die noch in offenen Aufträgen verwendet werden.

34

Muss die Reihenfolge der zugeordneten Objekte gespeichert werden?

Sortierung: Wenn die Reihenfolge (z.B. Positionen im Lieferschein) wichtig ist, brauchen Sie ein "SortOrder"-Feld.

35

Müssen Daten konsistent zu einem externen System sein?

Fremdsystem-Check: Referenzieren wir IDs aus SAP? Prüfen Sie, ob diese IDs dort stabil sind.

D

LEBENSZYKLUS, STATUS & HISTORIE

36

Welche Status kann das Objekt durchlaufen?

State Machine: Definieren Sie alle erlaubten Zustände. Vermeiden Sie Freitext-Statusfelder.

37

Welche Ereignisse lösen einen Statuswechsel aus?

Transitionen: Definieren Sie Trigger (User Klick, Zeitablauf, Systemevent) für jeden Wechsel.

38

Dürfen Daten im Status Abgeschlossen noch bearbeitet werden?

Immutability: Sperren Sie Datensätze ("Read Only") nach Abschluss (z.B. Rechnung gedruckt).

39

Müssen wir Änderungen an den Daten protokollieren?

Audit Trail: Wer, Wann, Was, Alter Wert, Neuer Wert. Pflicht für Compliance. Nicht abschaltbar machen.

40

Müssen alte Stände der Daten wiederherstellbar sein?

Versioning: Brauchen wir "Undo" oder echte Versionierung? Das vervielfacht den Speicherbedarf.

41

Wann dürfen Daten endgültig gelöscht werden?

Retention Policy: Definieren Sie Löschregeln. "Nie löschen" ist ein DSGVO-Verstoß.

42

Gibt es gesetzliche Aufbewahrungsfristen?

Legal Hold: Verhindern Sie das Löschen von steuerrelevanten Daten vor Ablauf von 10 Jahren.

43

Sollen gelöschte Daten physisch entfernt oder nur als inaktiv markiert werden?

Soft-Delete: Nutzen Sie is_deleted Flags statt DELETE FROM, um referenzielle Integrität nicht zu brechen.

44

Was passiert mit verknüpften Daten, wenn das Hauptobjekt archiviert wird?

Konsistenz: Archivieren Sie immer ganze Geschäftsvorfälle (Business Objects), nicht nur Tabellenzeilen.

45

Gibt es Regeln für die automatische Archivierung?

ILM: Information Lifecycle Management. Definieren Sie Jobs, die alte Daten auf billigen Speicher verschieben.

46

Was passiert mit verwaisten Daten, die keine Verknüpfung mehr haben?

Garbage Collection: Planen Sie Skripte ein, die temporäre Dateien/Bilder ohne Link regelmäßig löschen.

E

MENGENGERÜST, PERFORMANCE & MIGRATION

47

Mit welchen Datenmengen rechnen wir pro Jahr?

Sizing: Rechnen Sie: Datensatzgröße * Anzahl * Wachstum. Planen Sie Storage für 3-5 Jahre.

48

Wie viele Benutzer greifen gleichzeitig lesend oder schreibend zu?

Concurrency: Optimieren Sie auf Lese- oder Schreiblast. Caching-Strategien prüfen.

49

Gibt es ein Altsystem, das abgelöst wird?

Strategie: Wenn ja → Wechseln Sie zu Checklist 5.4 für detaillierte Migrationsplanung.

50

Wie schnell muss ein Suchergebnis vorliegen?

NFR: "Unter 1 Sekunde". Indexierung (z.B. Elasticsearch) notwendig?

51

Wie oft werden Daten synchronisiert?

Frequenz: Realtime vs. Batch. Batch ist robuster, Realtime ist komplexer.

F

SUCHE, FILTER & REPORTING

52

Gibt es sensible Datenfelder, die verschlüsselt dargestellt werden müssen?

Maskierung: Kreditkarten, PII-Daten. Maskierung muss im Backend passieren, nicht erst im UI.

53

Welche Daten werden für Berichte und Dashboards benötigt?

Analytics: Wenn komplexe Reports nötig sind: Prüfen Sie, ob das operative Datenmodell dafür taugt (oft nein → DWH nötig).

54

Müssen historische Datenverläufe für Trendanalysen gespeichert werden?

Snapshots: Speichern Sie den Zustand "Ende Monat" separat, um Vergleiche zu ermöglichen.

55

Welche Aggregationen (Summen, Durchschnitte) müssen vorberechnet werden?

Materialized Views: Speichern Sie Tagessummen ab, um Dashboards zu beschleunigen.

56

Gibt es Stichtagsbetrachtungen für die Daten?

Bi-Temporalität: Wir müssen wissen, was wir am Tag X wussten (Gültigkeit vs. Transaktionszeit).

57

Welche Kennzahlen (KPIs) müssen aus den Rohdaten abgeleitet werden?

Business Logic: Definieren Sie die Berechnungslogik für KPIs zentral, nicht in jedem Report anders.

58

Benötigen wir eine Trennung von operativen Daten und Analysedaten?

Architektur: Trennen Sie OLTP (Schreiben) von OLAP (Lesen/Report), um die Performance zu schützen.

59

Wie lange müssen Detaildaten für Analysen verfügbar bleiben?

Verdichtung: Löschen Sie uralte Einzelbuchungen, behalten Sie nur Monats-Summen.

60

Gibt es Anforderungen an den Datenexport für Excel oder BI-Tools?

Export: "Export to Excel" ist das meistgenutzte Feature. Planen Sie es für jede Liste ein.

61

Müssen Daten anonymisiert für Statistiken bereitgestellt werden?

Privacy: Entfernen Sie Personenbezug VOR der Weitergabe an die Analyse-Abteilung.

62

Wer darf welche Auswertungen sehen?

Row-Level-Security: Ein Vertriebler darf oft nur seine Region sehen. Das muss die DB filtern.

63

Nach welchen Attributen muss das Objekt suchbar sein?

Indizes: Setzen Sie Datenbank-Indizes auf alle Suchfelder. Sonst stirbt die Performance ("Table Scan").

64

Gibt es Anforderungen an eine Volltextsuche über alle Textfelder?

Search Engine: SQL LIKE %…​% ist langsam. Prüfen Sie Lucene/Solr/Elasticsearch Integration.

65

Muss die Suche fehlertolerant sein (Fuzzy Search)?

Usability: Finden von "Maier" auch bei Eingabe "Meier".

66

Sollen Suchergebnisse gefiltert oder facettiert werden können?

Drill-Down: Filterlogik (UND/ODER) definieren. Facetten (Anzahl Treffer pro Kategorie) berechnen.

67

Gibt es Synonyme, unter denen ein Datensatz gefunden werden soll?

Mapping: Suchbegriff-Tabelle pflegen (Handy = Smartphone). Siehe Abschnitt G (Glossar).

68

Müssen Suchergebnisse nach Relevanz sortiert werden?

Ranking: Definieren Sie den Algorithmus. Was ist "wichtig"? (Umsatz? Datum? Best Match?).

69

Gibt es komplexe Suchabfragen mit logischen Operatoren (AND/OR)?

Power-Search: Query-Builder für Profis bereitstellen?

70

Sollen Benutzer Suchabfragen speichern können?

Personalisierung: "Gespeicherte Suche" als Feature spart Zeit.

71

Gibt es Daten, die in der Suche ausgeblendet werden müssen?

Filterung: Archivierte oder gesperrte Artikel standardmäßig ausblenden.

G

GLOSSAR & BEGRIFFLICHKEITEN (DEFINITION)

72

Welche zentralen Fachbegriffe müssen im Glossar definiert werden?

Definition: Erstellen Sie das Projektglossar. Ohne gemeinsame Sprache (Ubiquitous Language) entstehen Missverständnisse.

73

Gibt es Abkürzungen, die im System verwendet werden?

Verständnis: Listen Sie alle Kürzel auf (z.B. "WE" = Wareneingang). Definieren Sie die Auflösung.

74

Haben Begriffe in verschiedenen Abteilungen unterschiedliche Bedeutungen (Homonyme)?

Disambiguierung: Klären Sie Begriffe wie "Kunde" (Interessent vs. Besteller). Vereinheitlichen oder Präfix nutzen (Sales-Kunde, Support-Kunde).

75

Gibt es unterschiedliche Begriffe für dieselbe Sache (Synonyme)?

Konsolidierung: "Auftrag" und "Bestellung". Entscheiden Sie sich für EINEN Begriff und verbieten Sie den anderen.

76

Gibt es veraltete Begriffe, die nicht mehr verwendet werden sollen (Blacklist)?

Wording: Führen Sie eine Liste verbotener Begriffe (z.B. Altsystem-Jargon). Nutzen Sie die Chance zur Sprachhygiene.

77

Gibt es Übersetzungen für die fachlichen Begriffe?

Internationalisierung: Translation-Memory pflegen. Konsistente englische Begriffe für Code und UI festlegen (Auftrag = Order, nicht "Request").

78

Wie stehen die Begriffe in Beziehung zueinander?

Ontologie: Erstellen Sie ein Begriffsmodell (Concept Map). Hilft neuen Entwicklern massiv beim Verständnis der Domäne.

79

Gibt es Beispiele für diesen Begriff, um ihn verständlicher zu machen?

Konkretisierung: Fügen Sie Beispiele ins Glossar ein. Abstraktes versteht niemand.

80

Wer ist verantwortlich für die Pflege der Begriffsdefinitionen?

Governance: Glossar muss leben. Benennen Sie einen Glossar-Wart.

81

Sind die Begriffe mit externen Normen abgeglichen?

Standardisierung: Nutzen Sie ISO-Codes und Branchenstandards statt Eigenerfindungen.

82

Gibt es visuelle Repräsentationen für komplexe Datenstrukturen?

Visualisierung: Diagramme ins Glossar/Wiki einbinden. Text allein reicht nicht.

83

Wo soll das Glossar für alle zugänglich gespeichert werden?

Zugriff: Wiki / Confluence. Ein Word-Dokument auf dem Sharepoint liest niemand.

H

DATENAUSTAUSCH & INTERFACE-LOGIK

84

Welches Format haben eingehende Datenstrukturen?

Interface Contract: Fordern Sie XSD/JSON-Schema. Validieren Sie strikt gegen das Schema.

85

Gibt es Standards für den Datenaustausch, die wir einhalten müssen?

Interoperabilität: Nutzen Sie Branchenstandards (HL7, Edifact), um kompatibel zu bleiben.

86

Müssen wir Datenstrukturen validieren, bevor wir sie importieren?

Gatekeeper: Validierung VOR dem Speichern. Keine kaputten Daten in die DB lassen.

87

Wie gehen wir mit fehlerhaften Datensätzen beim Import um?

Error Handling: "Alles oder Nichts" (Transaktion) oder "Best Effort" (Gute speichern, Schlechte loggen)? Definieren!

88

Müssen Daten beim Export transformiert werden?

Mapping: Mapper-Logik spezifizieren. Datumsformate und Dezimaltrenner sind Klassiker für Fehler.

89

Gibt es Größenbeschränkungen für Import-Dateien?

Limit: Max. Upload-Größe festlegen (z.B. 10MB) und prüfen. DoS-Schutz.

90

Müssen wir Metadaten zum Datenaustausch speichern?

Provenance: Speichern Sie "Quelle" und "Importzeitpunkt" am Datensatz. Wichtig für Fehlersuche.

91

Wer ist die führende Quelle (Master) für dieses Datenobjekt?

Single Source of Truth: Definieren Sie das Master-System. Schreiben Sie nie in Slave-Systemen Daten zurück, die dem Master gehören.

92

Was passiert bei Datenkonflikten während der Synchronisation?

Conflict Resolution: "Last Write Wins" oder manuelle Klärung? Strategie muss implementiert werden.

93

Dürfen Datensätze dupliziert (geklont) werden?

Deep Copy: Definieren Sie, was mitkopiert wird (Kopfdaten ja, Historie nein).

I

FUNKTIONALE ANFORDERUNGEN & PROZESSE

94

Welche Hauptaufgaben muss der Benutzer mit dem System erledigen?

Use Case Inventory: Erstellen Sie eine Liste aller Anwendungsfälle (Use Cases). Das ist der Scope der Entwicklung.

95

Welches Ereignis startet diesen Geschäftsprozess?

Trigger: Manuell (Button), Zeitlich (Cronjob), Extern (API-Call)? Startbedingung klären.

96

Was ist das gewünschte Ergebnis dieses Prozesses?

Post-Condition: Definieren Sie den Erfolgszustand ("Daten gespeichert UND E-Mail versendet").

97

Welche Schritte sind notwendig, um von A nach B zu kommen?

Workflow: Zeichnen Sie den Ablauf (Activity Diagram / BPMN). Text ist zu ungenau für Logik.

98

Welche Daten müssen eingegeben werden (Eingabedaten)?

Input: Maskenentwurf. Welche Felder muss der User füllen?

99

Welche Daten muss das System ausgeben oder anzeigen?

Output: Was sieht der User als Ergebnis? (Liste, PDF, Bestätigung).

100

Welche Berechnungen oder logischen Prüfungen muss das System durchführen?

Business Logic: Kern-Algorithmen spezifizieren. Hier steckt die Komplexität.

101

Was soll passieren, wenn ein Fehler auftritt (Ausnahmeszenarien)?

Unhappy Path: Spezifizieren Sie Fehlerbehandlung. 80% des Codes sind für Ausnahmen!

102

Gibt es alternative Wege, um das Ziel zu erreichen (Alternativszenarien)?

Varianten: "Gastbestellung" vs. "Login-Bestellung". Beide Wege spezifizieren.

103

Muss das System Daten dauerhaft speichern? Wenn ja, welche?

Persistenz: Explizit fordern. "Eingabe merken" heißt speichern.

104

Welche Berichte oder Auswertungen soll das System generieren?

Reporting: Definieren Sie Layout und Datenquelle der Reports.

105

Gibt es Abhängigkeiten zwischen verschiedenen Funktionen?

Dependency: "Funktion B geht erst, wenn Funktion A ausgeführt wurde". Pre-Conditions prüfen.

106

Muss das System Zustände verwalten (z. B. Antrag: offen → genehmigt)?

State Handling: Siehe Abschnitt D. Zustandsübergänge im Prozess erzwingen.

107

Welche Benutzerrollen haben Zugriff auf welche Funktionen?

RBAC: Funktions-Berechtigungsmatrix erstellen. Wer darf den Knopf drücken?

108

Soll das System Aufgaben automatisieren, die bisher manuell waren?

Automation: RPA-Potenzial prüfen. Alles was Regelbasiert ist, soll das System machen.

109

Müssen Historien oder Logs von Änderungen geführt werden?

Audit: Funktionale Anforderung an das Logging (siehe D.39).

110

Gibt es Funktionen, die nur zu bestimmten Zeiten verfügbar sein sollen?

Timing: "Bestellung nur bis 14 Uhr für Next-Day-Delivery".

111

Soll das System Benutzer proaktiv benachrichtigen?

Notification: Push/Mail bei Statusänderung. Text-Templates definieren.

112

Welche Such- und Filterfunktionen werden benötigt?

Retrieval: Siehe Abschnitt F. Suche muss im Prozess integriert sein.

113

Gibt es Import- oder Export-Funktionen für Daten?

I/O: Siehe Abschnitt H. Dateiformate klären.

114

Muss das System Undo/Redo-Funktionalität bieten?

Usability: Technisch aufwendig (Command Pattern). Frühzeitig entscheiden!

115

Soll es eine Hilfefunktion oder Wizards geben?

Guidance: User-Onboarding und Tooltips einplanen.

116

Wie soll der Prozess bei einem Systemabsturz fortgesetzt werden?

Recovery: Transaktionssicherheit. Darf der Prozess halb-fertig stehen bleiben? (Nein).

117

Gibt es Funktionen, die wir aus dem Altsystem nicht übernehmen wollen?

De-Scoping: Explizite "Out of Scope" Liste für Altsystem-Features führen.

118

Welche Konfigurationsmöglichkeiten soll der Benutzer haben?

Settings: Was ist hardcodiert, was ist Einstellungssache? (Sprache, Farben, Pfade).

Qualitative Ermittlung (Nicht-funktionale Anforderungen)
Ein System, das funktioniert, aber zu langsam oder unsicher ist, ist wertlos. In diesem Schritt definieren wir die Qualitätsanforderungen (NFRs). Wichtig ist hier die Quantifizierung: Statt "Das System soll schnell sein" definieren wir "Antwortzeit unter 200ms bei 1000 gleichzeitigen Nutzern". Dies schafft überprüfbare Kriterien für die spätere Abnahme.

Details

2.4 Qualitative Ermittlung & NFRs (Operative Audit-Checkliste)

diagram-2-4-mindmap

A – Performance & Effizienz Dieser Abschnitt definiert messbare Kriterien für Geschwindigkeit und Ressourcennutzung. Es werden Antwortzeiten, Durchsatz (Transaktionen pro Sekunde), Startzeiten und das Verhalten unter Last (Skalierung, „Graceful Degradation“) festgelegt. Mehrwert: Verhindert subjektive Diskussionen darüber, ob das System „schnell genug“ ist, und ermöglicht das korrekte Sizing der Hardware-Architektur.

B – Zuverlässigkeit & Verfügbarkeit Hier werden die Ausfallsicherheit (SLA, z. B. 99,9%) und Strategien für den Notfall definiert. Zentrale Metriken sind RTO (Wie lange darf es stehen?) und RPO (Wie viel Datenverlust ist akzeptabel?). Auch Offline-Fähigkeit und Wartungsfenster werden geregelt. Mehrwert: Schützt vor geschäftskritischen Datenverlusten und definiert vertraglich bindende Service-Level für den Betrieb.

C – Usability & UX Es werden Anforderungen an die Gebrauchstauglichkeit gestellt: Wie schnell ist das System erlernbar? Wie viele Klicks benötigt eine Hauptaufgabe? Auch Barrierefreiheit, Responsive Design für mobile Geräte und Personalisierbarkeit werden hier gefordert. Mehrwert: Sichert die Akzeptanz bei den Nutzern, senkt Schulungskosten und erhöht die Effizienz in der täglichen Arbeit.

D – Security & Datenschutz Dieser Bereich regelt den Schutz des Systems vor Angriffen und Datenmissbrauch. Dazu gehören Zugriffskonzepte (RBAC), Verschlüsselung (at Rest / in Transit), revisionssichere Logs und Authentifizierungsmethoden wie 2-Faktor-Authentifizierung. Mehrwert: Minimiert das Risiko von Cyber-Attacken und Datendiebstahl und stellt die Einhaltung gesetzlicher Datenschutzvorgaben sicher.

E – Wartbarkeit & Portabilität Hier wird die Qualität des Codes und der Architektur definiert. Anforderungen an Modularität, Testbarkeit („Clean Code“), Installationsroutinen (IaC) und Logging stellen sicher, dass das System auch langfristig pflegbar bleibt. Mehrwert: Reduziert die technischen Schulden und verhindert, dass das System unwartbar wird („Legacy-Falle“), wenn Entwickler wechseln.

F – Kompatibilität & Interoperabilität Dieser Abschnitt prüft, wie gut das System mit anderen interagiert. Es geht um Cloud-Unabhängigkeit, Koexistenz mit anderer Software, Abwärtskompatibilität zu alten Datenformaten und die Unterstützung offener Standards für Schnittstellen. Mehrwert: Verhindert den „Vendor-Lock-In“ und stellt sicher, dass sich das System flexibel in bestehende und zukünftige IT-Landschaften integrieren lässt.

G – Safety (Gefahrenanalyse) Für Systeme, die physischen Schaden anrichten können (z. B. Maschinensteuerung), werden hier Risikoanalysen und Sicherheitsmechanismen wie „Fail-Safe“-Zustände oder Hardware-Watchdogs definiert. Mehrwert: Schützt Leib und Leben und verhindert katastrophale Ausfälle in sicherheitskritischen Umgebungen.

H – Kultur & Lokalisierung Es werden Anforderungen für den globalen Einsatz festgelegt: Unterstützung von Zeitzonen (UTC), Währungen, Datumsformaten und Schreibrichtungen (RTL). Auch kulturelle Aspekte bei Bildern und Farben werden berücksichtigt. Mehrwert: Ermöglicht den weltweiten Rollout der Software ohne teure nachträgliche Anpassungen des Codes.

I – Datenqualität & Ästhetik Hier werden Ansprüche an die Korrektheit (Rundungsregeln), Aktualität (Caching) und Konsistenz der Daten gestellt. Zudem werden weiche Faktoren wie das Vertrauen erweckende Design oder die Vermeidung kognitiver Überlastung definiert. Mehrwert: Sorgt für verlässliche Daten als Entscheidungsgrundlage und erhöht durch ansprechendes Design die emotionale Bindung der Nutzer.

J – Nachhaltigkeit (Green IT) Dieser Abschnitt fordert ressourcenschonende Software: Energieeffizienz (z. B. Dark Mode), Lauffähigkeit auf alter Hardware zur Vermeidung von Elektroschrott und papierlose Prozesse. Mehrwert: Reduziert den ökologischen Fußabdruck der IT und senkt Betriebskosten durch geringeren Energie- und Ressourcenverbrauch.

Nr. Frage Operative Implikation & Handlungsanweisung

A

PERFORMANCE & EFFIZIENZ (ISO 25010)

1

Wie viele Benutzer arbeiten gleichzeitig aktiv im System?

Load-Testing: Definieren Sie "Concurrent Users" (gleichzeitig aktiv) vs. "Named Users" (Datenbank-Einträge). Testen Sie mit 150% der erwarteten Lastspitze.

2

Was ist die maximal akzeptable Antwortzeit für eine Standard-Suche?

Latenz: "Schnell" ist keine Anforderung. Definieren Sie: "95% der Suchen in < 2 Sekunden". Alles darüber ist ein Bug.

3

Wie schnell muss das System hochfahren (Startzeit)?

Boot-Time: Bei Embedded Systems oder Kiosk-PCs (POS) kritisch. "Max. 30 Sek nach Power-On bis zum Login-Screen".

4

Wie viele Transaktionen muss das System pro Stunde verarbeiten können?

Durchsatz: Definieren Sie TPS (Transactions Per Second). Das bestimmt die Datenbank-Architektur (Sharding/Partitioning).

5

Wie verhält sich das System bei Überlastung?

Graceful Degradation: Das System darf nicht crashen. Es muss kontrolliert Anfragen ablehnen (HTTP 503) oder Features abschalten.

6

Welche Hardware-Ressourcen (CPU, RAM) darf das System maximal nutzen?

Footprint: Definieren Sie Limits für IoT/Mobile. "App darf max. 100MB RAM nutzen". Verhindert "Out of Memory" Abstürze.

7

Wie skalierbar muss das System sein, wenn die Datenmenge wächst?

Scalability: Planen Sie Datenbank-Indizes für 5 Jahre Wachstum. Ein Full-Table-Scan bei 1 Mio. Zeilen tötet die Performance.

8

Wie schnell muss ein Bericht generiert werden?

Async-Processing: Wenn Reports > 10 Sek dauern, müssen sie im Hintergrund laufen (Job Queue) und den User benachrichtigen.

9

Gibt es Zeiten mit besonders hoher Last (Lastspitzen)?

Auto-Scaling: Cloud-Ressourcen müssen automatisch hochfahren (z.B. Black Friday). Statische Server reichen nicht.

10

Wie stark darf der Akkuverbrauch bei mobilen Geräten sein?

Energy: Messen Sie den Verbrauch. Hintergrund-Aktivitäten (GPS, Sync) müssen minimiert werden.

B

ZUVERLÄSSIGKEIT & VERFÜGBARKEIT

11

Wie hoch muss die Verfügbarkeit des Systems sein (in %)?

SLA: 99,9% = 9h Ausfall/Jahr. 99,99% = 52 Min. Jede "9" kostet exponentiell mehr Geld (Cluster, Redundanz).

12

Wann darf das System für Wartungsarbeiten abgeschaltet werden?

Maintenance Window: Definieren Sie feste Fenster (z.B. So. 02:00-04:00). Außerhalb dieser Zeiten ist Downtime verboten.

13

Wie schnell muss das System nach einem Absturz wieder laufen?

RTO (Recovery Time Objective): Wie lange darf der Betrieb stillstehen? 4 Stunden? 10 Minuten? Das bestimmt die Backup-Strategie.

14

Wie viele Daten dürfen im schlimmsten Fall verloren gehen?

RPO (Recovery Point Objective): Max. 15 Minuten Datenverlust → Log-Backups alle 15 Min. 0 Datenverlust → Synchroner Spiegel (teuer).

15

Wie fehlertolerant muss das System bei falschen Eingaben sein?

Robustheit: Fangen Sie JEDEN Input ab. Kein Stacktrace im UI sichtbar machen. Validierung an der Schnittstelle.

16

Muss das System auch ohne Internetverbindung funktionieren (Offline-Fähigkeit)?

Offline-First: Lokale Datenbank (SQLite/IndexedDB) erforderlich. Sync-Logik bei Wiederverbindung ist komplex (Konflikte!).

17

Wie stabil muss das System im Dauerbetrieb laufen?

Memory Leaks: Führen Sie Langzeit-Tests (7 Tage) durch, um Speicherlecks zu finden, die erst spät zum Absturz führen.

18

Gibt es automatische Überwachungsmechanismen (Monitoring)?

Health-Check: Implementieren Sie /health Endpoints. Wenn der Health-Check fehlschlägt, muss der Loadbalancer umschalten.

19

Wie werden Dateninkonsistenzen nach einem Absturz repariert?

Self-Healing: Transaktionslogs (WAL) nutzen. Start-Skript muss DB-Konsistenz prüfen.

20

Muss das System redundant ausgelegt sein?

Failover: Aktiv/Passiv oder Aktiv/Aktiv Cluster? Testen Sie den "Stecker ziehen" Fall im Abnahmetest.

C

USABILITY & UX

21

Wie schnell muss ein neuer Benutzer das System erlernen können?

Onboarding: Definieren Sie Schulungsaufwand. "Max. 2h Schulung nötig". Nutzen Sie geführte Touren im Tool.

22

Wie viele Klicks/Schritte sind für die Hauptaufgabe maximal akzeptabel?

Effizienz: Optimieren Sie "High-Frequency" Tasks. Jeder Klick weniger spart im Callcenter tausende Euro.

23

Wie barrierefrei soll die Interaktion für Menschen mit Einschränkungen sein?

Inklusion: Abseits von Gesetzen (1.4): Sorgen Sie für gute Screenreader-Nutzbarkeit (ARIA) und Tastaturbedienbarkeit, um die Zielgruppe zu erweitern.

24

Soll das System auf mobilen Geräten (Smartphone/Tablet) nutzbar sein?

Responsive: Definieren Sie Breakpoints (Mobile, Tablet, Desktop). Testen Sie Touch-Ziele (min. 44x44 Pixel).

25

Gibt es Vorgaben zum Corporate Design (Farben, Logos, Schriften)?

Styleguide: Binden Sie das Design-System (CSS/Komponenten) ein. Keine Hardcoded Farben ("Blue") nutzen.

26

Muss das System Rückgängig-Funktionen (Undo) anbieten?

Fehlertoleranz: "Undo" ist besser als "Sind Sie sicher?"-Dialoge. Technisch aufwendig (Command Pattern).

27

Wie gut muss das System den Nutzer bei Fehlern unterstützen?

Helpfulness: Fehlermeldungen müssen Lösungen bieten ("Versuchen Sie X"), nicht nur Probleme beschreiben ("Error 500").

28

Soll das System personalisierbar sein?

Settings: Speichern Sie Nutzereinstellungen (Spaltenbreite, Sortierung) im Profil. Reset-Funktion nicht vergessen.

29

Gibt es eine kontextsensitive Hilfe?

Support: Tooltips oder "Info"-Icons an komplexen Feldern reduzieren Support-Tickets.

D

SECURITY & DATENSCHUTZ

30

Wer darf welche Daten sehen oder ändern (Zugriffsschutz)?

RBAC: Definieren Sie Rollen (Admin, User, Gast). Testen Sie Negativ-Fälle: "Darf Gast löschen?" → Muss geblockt werden.

31

Wie müssen sich Benutzer authentifizieren?

MFA: 2-Faktor-Auth ist Industriestandard. Passwort-Richtlinien (Länge/Komplexität) erzwingen.

32

Müssen Daten verschlüsselt gespeichert werden?

Encryption at Rest: Festplattenverschlüsselung (Bitlocker/LUKS) oder DB-Verschlüsselung nutzen. Keys sicher verwahren (HSM).

33

Müssen Daten verschlüsselt übertragen werden?

Encryption in Transit: TLS 1.2/1.3 erzwingen. HTTP muss auf HTTPS umleiten (HSTS).

34

Welche Aktionen müssen revisionssicher protokolliert werden?

Audit-Log: Loggen Sie fachliche Änderungen (Wer hat den Preis geändert?), nicht nur technische Errors. Logs dürfen nicht löschbar sein.

35

Wie lange müssen Passwörter sein und wie komplex?

NIST-Standard: Keine regelmäßige Änderung erzwingen (führt zu Zetteln), aber Komplexität und Länge fordern.

36

Muss das System nach einer Zeit der Inaktivität den Nutzer ausloggen?

Session-Timeout: Max. 15-30 Min bei sensiblen Apps (Banking). Bei Kiosk-Systemen kürzer.

37

Wie wird verhindert, dass Daten manipuliert werden (Integrität)?

Hashing: Prüfsummen oder Blockchain-Konzepte nutzen, wenn Daten unveränderbar sein müssen.

38

Gibt es Anforderungen an den Schutz vor Cyber-Attacken?

Härtung: WAF (Web App Firewall) nutzen. Rate-Limiting gegen Brute-Force. Regelmäßige Pen-Tests einplanen.

E

WARTBARKEIT & PORTABILITÄT

39

Wie einfach muss der Code für andere Entwickler lesbar sein?

Clean Code: SonarQube einsetzen. Code Coverage > 80% anstreben. "Bus-Faktor" erhöhen.

40

Wie modular muss das System aufgebaut sein?

Architektur: Microservices oder Modulith? Definieren Sie Schnittstellen zwischen Modulen, um Austauschbarkeit zu sichern.

41

Wie einfach muss das System testbar sein?

Testability: Dependency Injection nutzen, um Module für Unit-Tests zu isolieren (Mocking).

42

Wie schnell muss ein Fehler im Code gefunden und behoben werden können?

Observability: Centralized Logging (ELK/Splunk) und Tracing (Jaeger) implementieren. Logs müssen durchsuchbar sein.

43

Wie einfach muss das System installierbar sein?

IaC: Infrastructure as Code (Terraform/Ansible). Keine manuelle Server-Installation ("Snowflake Server").

44

Dürfen Komponenten des Systems wiederverwendet werden?

Library: Auslagern von generischem Code in interne NuGet/npm-Pakete.

45

Wie einfach muss das System konfigurierbar sein?

No-Code: Geschäftsregeln (Steuersätze, Limits) gehören in die DB oder Config-Files, nicht in den Code.

46

Welche Dokumentation wird für die Wartung benötigt?

Knowledge Base: API-Docs (Swagger/OpenAPI) automatisch generieren. Architektur-Doku (arc42) pflegen.

47

Wie verhält sich das System bei Änderungen der Umgebung?

Containerisierung: Docker nutzen, um Unabhängigkeit vom Host-OS zu erreichen.

48

Wie werden Abhängigkeiten zu externen Bibliotheken gemanagt?

SCA: Software Composition Analysis Tools nutzen (Snyk/Dependabot), um Sicherheitslücken in Libs zu finden.

F

KOMPATIBILITÄT & INTEROPERABILITÄT

49

Wie einfach können Daten in ein anderes System migriert werden?

Export: Standardformate (CSV, JSON, XML) anbieten. Verhindert Vendor-Lock-In Ängste beim Kunden.

50

Muss die Software in verschiedenen Cloud-Umgebungen laufen?

Cloud-Agnostic: Vermeiden Sie proprietäre Cloud-Services (z.B. DynamoDB), wenn Portabilität gefordert ist.

51

Wie leicht lässt sich das System an neue organisatorische Umgebungen anpassen?

Mandantenfähigkeit: Datenlogik muss TenantID überall berücksichtigen. Strikte Trennung der Daten.

52

Darf das System andere installierte Programme stören?

Isolation: Keine globalen DLLs oder Java-Runtimes im System-Pfad installieren. App-lokale Runtimes nutzen.

53

Muss das System Daten mit älteren Versionen seiner selbst austauschen können?

Backward Compatibility: Alte Dateiformate müssen lesbar bleiben. Migrations-Assistenten vorsehen.

54

Welche Schnittstellenstandards sollen unterstützt werden?

Offenheit: Sollen offene Standards (REST, GraphQL) für Drittsysteme angeboten werden? Erhöht die Integrationsfähigkeit.

55

Muss das System mit spezifischer Hardware zusammenarbeiten?

Treiber: Testen Sie mit der echten Hardware (Scanner, Drucker). Treiber-Kompatibilität ist oft ein Problem.

56

Wie verhält sich das System in einer virtualisierten Umgebung?

Virtualisierung: Performance-Tests auf VM durchführen. Ressourcen-Overhead einplanen.

G

SAFETY (GEFAHRENANALYSE)

57

Welche Gefahren für Leib und Leben können vom System ausgehen?

Hazard Analysis: Identifizieren Sie Risiken. Wenn Software versagt → Darf niemand sterben (Safe State).

58

Wie wird sichergestellt, dass kritische Funktionen Vorrang haben?

Priorisierung: Echtzeit-OS (RTOS) nutzen oder kritische Prozesse mit hoher CPU-Prio laufen lassen.

59

Gibt es eine unabhängige Überwachungseinheit (Watchdog)?

Hardware-Safety: Externe Hardware muss den Prozessor resetten, wenn er hängt ("Heartbeat"-Signal).

60

Wie muss das System auf Hardware-Defekte reagieren?

Fail-Safe: Definieren Sie den sicheren Zustand (z.B. "Ampel rot", "Ventil zu").

H

KULTUR & LOKALISIERUNG

61

Welche Währungen und Datumsformate müssen unterstützt werden?

Formatierung: Nutzen Sie Bibliotheken für Locale-Formatting. 1.000,00 vs 1,000.00 beachten.

62

Müssen Texte und Bilder an lokale Kulturen angepasst werden?

Content: Vermeiden Sie kulturell besetzte Farben/Symbole. Bilder austauschbar machen.

63

Wie wird mit verschiedenen Zeitzonen umgegangen?

UTC: Speichern Sie IMMER in UTC. Konvertieren Sie erst bei der Anzeige in die User-Zeitzone.

64

Werden Adressformate flexibel gehandhabt?

Validierung: Keine harten Regeln für PLZ weltweit. Adressfelder flexibel halten.

65

Unterstützt das System verschiedene Schreibrichtungen (z. B. Arabisch)?

RTL: CSS/Layout muss spiegelbar sein. Testen Sie das Layout mit Pseudo-Arabisch.

I

DATENQUALITÄT & ÄSTHETIK

66

Wie genau müssen Berechnungen sein?

Genauigkeit: Definieren Sie Rundungsregeln. Finanzmathematische Genauigkeit ist Pflicht.

67

Wie aktuell müssen angezeigte Daten sein?

Frische: Definieren Sie Cache-Zeiten. Wann muss der Nutzer "Refresh" drücken?

68

Wie vollständig müssen Datensätze sein, um gespeichert zu werden?

Validierung: Definieren Sie Muss-Felder. Speichern von "Entwürfen" erlauben (unvollständig)?

69

Dürfen Dubletten im System existieren?

Deduplizierung: Check bei der Eingabe ("Kunde existiert schon"). Merge-Tools vorsehen.

70

Wie konsistent müssen Daten über verschiedene Masken hinweg sein?

Konsistenz: Datenänderung muss sofort überall sichtbar sein (Observer Pattern).

71

Wie ästhetisch ansprechend muss die Oberfläche sein?

Design: Nutzen Sie Moodboards. Subjektiv, aber wichtig für Akzeptanz.

72

Soll das System Spaß machen (Gamification)?

Engagement: Belohnungssysteme nur nutzen, wenn sie zum Kontext passen.

73

Wie vertrauenswürdig soll das System wirken?

Trust: Keine "verspielten" Fonts im Banking. Seriöses Design.

74

Wie ruhig oder aufgeregt soll die Interaktion sein?

Informationsdichte: Profis brauchen Dichte, Anfänger brauchen Whitespace. Konfigurierbar?

75

Gibt es Vorgaben zur Minimierung von Kognitiver Last?

Simplicity: Wizards nutzen für komplexe Prozesse. Arbeitsgedächtnis des Nutzers schonen.

J

NACHHALTIGKEIT (GREEN IT)

76

Wie nachhaltig ist die Software (Green IT)?

Effizienz: Dark Mode spart Energie bei OLED. Inaktive Dienste abschalten.

77

Kann alte Hardware weitergenutzt werden?

Ressourcen: Optimieren Sie auf Leistung, um Hardware-Lebenszyklen zu verlängern.

78

Wie papierlos ist der Prozess?

Digitalisierung: Drucken nur als Ausnahme. PDF-Versand als Standard.

79

Fördert das System inklusives Verhalten?

Diversity: Gender-neutrale Anrede ("Guten Tag Vorname Nachname") statt "Herr/Frau".

80

Ist der Energieverbrauch der Rechenzentren optimiert?

Cloud-Wahl: Provider mit CO2-neutraler Strategie bevorzugen.

Phase 3: Dokumentation & Form

Das gesammelte Wissen existiert bisher nur in Köpfen, Notizen oder Whiteboard-Skizzen. In dieser Phase wird es in eine professionelle, bindende Form gebracht.

Modellierung (Die Visualisierung)
Komplexe Sachverhalte lassen sich textuell oft schwer beschreiben. Hier nutzen wir standardisierte Notationen (UML für Softwarestrukturen, BPMN für Prozesse, SysML für technische Systeme), um die Logik visuell darzustellen. Modelle dienen als präziser Bauplan für Architekten und Entwickler und helfen, Logiklücken aufzudecken, die im Fließtext übersehen würden.

Details

3.1 Modellierung & Notation (Operative Audit-Checkliste)

diagram-3-1-mindmap

A – Allgemeine Modellierungs-Richtlinien Dieser Abschnitt klärt die Rahmenbedingungen: Welcher Standard (BPMN, UML) und welches Tool werden genutzt? Er definiert Zielgruppe und Abstraktionsgrad, um „Malen nach Zahlen“ zu verhindern, und fordert Legenden sowie klare Verantwortlichkeiten für die Pflege der Modelle. Mehrwert: Verhindert nutzlose Diagramme, die niemand versteht, und stellt sicher, dass Modelle semantisch korrekt sind, um als Basis für Implementierung oder Code-Generierung zu dienen.

B – Anforderungsanalyse (Use Cases) Hier wird die Systemgrenze gezogen: Wer steht draußen (Akteure) und was passiert drinnen? Use Cases werden als fachliche Ziele definiert und müssen durch textuelle Beschreibungen sowie Vor- und Nachbedingungen („Vertrag“) detailliert werden. Mehrwert: Schafft Klarheit über den Scope (Was bauen wir?) und liefert durch die Bedingungen die direkte Basis für Testfälle.

C – Struktur (Klassendiagramme) Dieser Bereich bildet das statische Skelett der Software (Domain Model). Es werden Klassen, Attribute mit Datentypen und Beziehungen (Kardinalitäten, Komposition) definiert, die direkt das Datenbank-Design beeinflussen. Mehrwert: Dient als präziser Bauplan für die Entwicklung und verhindert Datenbank-Fehler durch falsche Annahmen über Beziehungen (z. B. 1:n vs. m:n).

D – Prozesse & Abläufe (Aktivität / BPMN) Es werden dynamische Abläufe visualisiert, wobei BPMN für Fachprozesse und UML für technische Logik genutzt wird. Verantwortlichkeiten werden durch Swimlanes geklärt, und komplexe Logiken wie Verzweigungen oder Nebenläufigkeit werden eindeutig dargestellt. Mehrwert: Deckt Logiklücken und Deadlocks in Prozessen auf, die in reinem Text übersehen würden, und klärt eindeutig, wer für welchen Schritt zuständig ist.

E – Zustände & Lebenszyklus (State Machine) Hier wird definiert, welche Status ein Objekt (z. B. „Auftrag“) annehmen darf und durch welche Ereignisse (Trigger) oder Bedingungen (Guards) ein Wechsel erfolgt. Mehrwert: Essenziell für die korrekte Abbildung von Geschäftsobjekten, um ungültige Zustandsübergänge (z. B. „Bezahlt“ ohne „Bestellt“) technisch zu verhindern.

F – Interaktion & Nachrichten (Sequenz) Dieser Abschnitt stellt den zeitlichen Ablauf der Kommunikation zwischen Objekten oder Systemen dar. Er unterscheidet zwischen synchronen (Warten) und asynchronen (Feuern) Nachrichten. Mehrwert: Visualisiert Abhängigkeiten und Kopplung zwischen Komponenten, was kritisch für die Performance-Analyse und das Schnittstellen-Design ist.

H – Glossar & Begriffe Es wird sichergestellt, dass alle in den Modellen verwendeten Begriffe zentral definiert und konsistent sind. Synonyme und Homonyme werden bereinigt. Mehrwert: Verbindet Modell und Sprache zu einer „Ubiquitous Language“, sodass Fachbereich und Entwickler nicht aneinander vorbeireden.

I – Qualitätssicherung & Visualisierung Dieser Bereich gibt Tipps zur Lesbarkeit (Layout, Kreuzungen vermeiden) und empfiehlt Entscheidungstabellen für komplexe Regeln statt überladener Diagramme. Auch die Versionierung und Validierung („Passt das zur Realität?“) werden gefordert. Mehrwert: Hält die Modelle wartbar und verständlich („Kognitive Last“ senken) und sichert ab, dass das Dokumentierte auch technisch umsetzbar ist.

Nr. Frage Operative Implikation & Handlungsanweisung

A

ALLGEMEINE MODELLIERUNGS-RICHTLINIEN

1

Welcher Modellierungsstandard ist für dieses Projekt vorgeschrieben?

Standardisierung: BPMN 2.0 für Prozesse, UML 2.5 für Software, SysML 1.6 für Systeme. Kein "Malen nach Zahlen". Richtlinie verlinken.

2

Welches Tool wird für die Modellierung verwendet?

Tool-Chain: Enterprise Architect (EA), Cameo, Visio? Wenn das Tool keine Semantik kennt (nur Zeichnung), ist Modellierung wertlos für Code-Generierung.

3

Wer ist die Zielgruppe des Diagramms?

Adressat: Management versteht keine UML-Klassendiagramme. Entwickler hassen schwammige Powerpoints. Passen Sie die Notation an.

4

Welcher Abstraktionsgrad (Detaillierung) ist angemessen?

Zoom-Level: Modellieren Sie nicht jeden Mausklick im BPMN. Bleiben Sie auf der fachlichen Ebene (Was, nicht Wie).

5

Sollen Modelle deskriptiv (Ist-Zustand) oder präskriptiv (Soll-Zustand) sein?

Zweck: Kennzeichnen Sie Diagramme deutlich mit "IST" oder "SOLL". Verwechslung führt zu fatalen Fehlentwicklungen.

6

Wie stellen wir die Konsistenz zwischen verschiedenen Diagrammen sicher?

Integration: Das Objekt "Kunde" im Sequenzdiagramm muss die Klasse "Kunde" im Klassendiagramm sein. Tool-gestützte Konsistenzchecks nutzen.

7

Gibt es eine Legende für das Diagramm?

Verständlichkeit: Wenn Sie Farben nutzen (Rot = Fehler, Grün = Happy Path), muss eine Legende im Diagramm sein.

8

Sollen wir Modelle mit natürlicher Sprache kombinieren?

Hybrid: Annotieren Sie komplexe Logikblöcke mit Textnotizen. Ein Diagramm ohne Kontext ist oft unverständlich.

9

Wer ist für die Pflege und Aktualisierung der Modelle verantwortlich?

Ownership: Ein Modell, das nicht gepflegt wird, ist gefährlicher als gar keins ("Code ist Wahrheit"). Benennen Sie Modell-Paten.

88

Sind die Diagramme nicht zu komplex (7+/-2 Regel)?

Kognitive Last: Ein Diagramm mit 50 Elementen ist Müll. Zerlegen Sie es in Unter-Diagramme (Sub-Process).

89

Haben alle Diagramme einen Titel und eine ID?

Referenzierung: "Abb. 1.2: Login-Prozess". Ohne ID kann man im Review nicht darauf verweisen.

B

ANFORDERUNGSANALYSE (USE CASES)

11

Welche Akteure befinden sich außerhalb der Systemgrenze?

Kontext: Zeichnen Sie die Systemgrenze (Box). Akteure stehen DRAUSSEN. Alles DRINNEN wird programmiert.

12

Handelt es sich bei dem Akteur um einen Menschen oder ein System?

Notation: Strichmännchen = Mensch. Box mit [System] = IT-System. Wichtig für Schnittstellen-Design.

13

Gibt es Generalisierungen zwischen Akteuren?

Vererbung: "Admin" erbt von "User". Vermeidet doppelte Pfeile im Diagramm.

14

Wann nutzen wir „Include“-Beziehungen?

Wiederverwendung: [include] ist wie ein Funktionsaufruf (Pflicht). Nutzen Sie es für "Login" oder "Validierung".

15

Wann nutzen wir „Extend“-Beziehungen?

Optionen: [extend] ist optional (z.B. "Gutschein einlösen"). Definieren Sie die Bedingung (Extension Point).

16

Beschreibt der Use Case ein fachliches Ziel (keine Funktion)?

Level: "Datenbank speichern" ist kein Use Case. "Kunden anlegen" ist ein Use Case. Verb + Substantiv nutzen.

17

Gibt es eine textuelle Beschreibung zu jedem Use Case?

Detail: Das Oval im Diagramm reicht nicht. Schreiben Sie den Ablauf (Main Flow / Alternative Flow) als Text.

18

Sind Vor- und Nachbedingungen für den Use Case definiert?

Vertrag: Pre: "User eingeloggt". Post: "Rechnung erstellt". Ohne das ist der Test nicht möglich.

C

STRUKTUR (KLASSENDIAGRAMME)

21

[Image of UML class diagram example] Welche Klassen bilden die statische Struktur des Systems?

Domain Model: Identifizieren Sie Substantive aus den Anforderungen (Rechnung, Kunde). Das ist das Skelett der Software.

22

Welche Attribute beschreiben eine Klasse?

Daten: Typen angeben! preis : Currency, name : String. Sichtbarkeit (+/-) nur bei Design-Modellen nötig.

24

Wie heißt die Beziehung zwischen zwei Klassen (Assoziation)?

Semantik: Beschriften Sie den Strich! "Kunde --bestellt-→ Produkt". Ein unbeschrifteter Strich ist wertlos.

25

Welche Multiplizitäten (Kardinalitäten) gelten?

Mengen: 1, 0..1, 1..*, *? Das ist die wichtigste Info für das Datenbank-Design (Fremdschlüssel).

27

Handelt es sich um eine Komposition (starke Teil-Ganzes-Beziehung)?

Existenz: Ausgefüllte Raute (♦). Wenn "Auto" gelöscht wird, stirbt "Rad". Wichtig für Lösch-Kaskaden.

29

Nutzen wir Generalisierung (Vererbung)?

Hierarchie: "PKW" ist ein "Fahrzeug". Prüfen Sie "Liskov Substitution Principle" (Ist-ein Beziehung).

31

Nutzen wir Enumerationen (Aufzählungstypen)?

Wertelisten: Status {Neu, Offen, Zu}. Definieren Sie erlaubte Werte im Modell, nicht im Freitext.

34

Sind Constraints (Einschränkungen) definiert?

Regeln: {Alter >= 18}. Nutzen Sie OCL oder Text in geschweiften Klammern für Geschäftsregeln.

D

PROZESSE & ABLÄUFE (AKTIVITÄT / BPMN)

35

[Image of BPMN process diagram] Welche Aktionen finden im Prozess statt?

Workflow: Nutzen Sie Aktivitätsdiagramme (UML) oder BPMN. Start- und Endpunkt müssen definiert sein.

36

Gibt es Entscheidungen (Verzweigungen)?

Logik: Raute (◇). Beschriften Sie die Ausgänge (Guards) zwingend mit [Ja] / [Nein].

37

Laufen Aktionen parallel ab (Nebenläufigkeit)?

Concurrency: Fork (Balken) teilt den Fluss, Join (Balken) führt ihn zusammen. Achtung vor Deadlocks!

38

Wer ist für welche Aktion zuständig (Swimlanes)?

Rollen: Jede Aktion muss in einer Swimlane liegen. Aktionen auf der Linie sind verboten.

39

Fließen Objekte/Daten zwischen den Aktionen?

Input/Output: Zeichnen Sie Objektknoten (Rechteck). "Aktion A" erzeugt "Dokument X", das in "Aktion B" geht.

42

Gibt es Unterbrechungsbereiche (Interruptible Regions)?

Exception: Modellieren Sie den "Abbruch"-Button oder Timeouts. Der Happy Path reicht nicht.

43

Soll BPMN statt UML-Aktivitätsdiagramm genutzt werden?

Business: Für Fachprozesse IMMER BPMN nutzen. IT-Logik in UML. Pools/Lanes korrekt nutzen.

E

ZUSTÄNDE & LEBENSZYKLUS (STATE MACHINE)

45

[Image of UML state machine diagram] Welche Zustände kann das Objekt einnehmen?

Status: Definieren Sie alle erlaubten Zustände (z.B. "Bestellt", "Bezahlt"). Keine "Phantasie-Status".

46

Welche Ereignisse (Trigger) lösen den Übergang aus?

Transition: Pfeil beschriften! Event [Condition] / Action. Ein Pfeil ohne Event ist ein Fehler (außer bei automatischem Übergang).

47

Gibt es Bedingungen (Guards) für den Übergang?

Logik: [Guthaben > 0]. Der Übergang findet nur statt, wenn die Bedingung wahr ist.

48

Welche Aktionen passieren beim Eintritt in einen Zustand (Entry)?

Side-Effect: entry / E-Mail senden. Was passiert automatisch, wenn der Zustand erreicht wird?

53

Ist der Zustandsautomat deterministisch?

Eindeutigkeit: Von einem Zustand darf bei gleichem Event nur EIN Weg abgehen (oder Guards müssen sich ausschließen).

F

INTERAKTION & NACHRICHTEN (SEQUENZ)

54

Welche Objekte tauschen Nachrichten aus?

Szenario: Lifelines (Objekte) oben anordnen. Zeit läuft nach unten. Akteure links, Systeme rechts.

56

Sind die Nachrichten synchron oder asynchron?

Kopplung: Volle Pfeilspitze (Synchron/Warten) vs. Offene Spitze (Asynchron/Feuern). Wichtig für Performance.

57

Gibt es Rückgabewerte (Return Messages)?

Antwort: Gestrichelter Pfeil zurück. Beschriften Sie den Rückgabewert (:RechnungID).

59

Nutzen wir Fragmente für Schleifen (Loop) oder Alternativen (Alt)?

Kontrollfluss: Nutzen Sie loop für Wiederholungen und alt für If/Else-Logik im Sequenzdiagramm.

61

Ist das Diagramm auf ein Szenario beschränkt?

Fokus: Packen Sie nicht alle Varianten in ein Diagramm. Ein Diagramm pro Use-Case-Szenario (Happy Path, Error A, Error B).

G

SYSTEMARCHITEKTUR (SYSML / DFD)

62

Wer sind die Quellen und Senken im Datenfluss?

DFD: Nutzen Sie Datenflussdiagramme für High-Level-Sichten. Wo kommen Daten her (Terminator), wo gehen sie hin?

67

Nutzen wir SysML für Hardware/Software-Systeme?

Systems Engineering: Für Mechatronik (Auto, Roboter) UML durch SysML ersetzen. Blöcke statt Klassen.

68

Wie sind die Blöcke im SysML-Diagramm verbunden?

Flows: Definieren Sie, was fließt (Energie, Materie, Daten). Nutzen Sie Item Flows.

H

GLOSSAR & BEGRIFFE

71

Sind alle Begriffe im Glossar definiert?

Wording: Jeder Begriff im Modell (Klassenname, Zustand) muss im Glossar stehen.

72

Sind Synonyme und Homonyme geklärt?

Mehrdeutigkeit: Klären Sie: "Kunde" vs. "Besteller". "Leiter" (Chef) vs. "Leiter" (Gerät).

73

Sind Akronyme ausgeschrieben?

Verständnis: Keine Abkürzungen im Diagramm ohne Erklärung im Glossar.

77

Ist das Glossar zentral verfügbar?

Single Source: Glossar muss im Modellierungstool oder Wiki integriert sein (verlinkt).

I

QUALITÄTSSICHERUNG & VISUALISIERUNG

80

Nutzen wir Entscheidungstabellen für komplexe Regeln?

Kompaktheit: Wenn Sie mehr als 3 verschachtelte Rauten im Diagramm haben → Ersetzen durch Tabelle.

82

Sollen wir Wireframes/Mockups zur UI-Dokumentation nutzen?

UI: Klassendiagramme beschreiben keine UIs. Nutzen Sie Wireframes für Masken.

86

Wurde das Layout der Diagramme optimiert?

Lesbarkeit: Kreuzende Linien minimieren. Flussrichtung einhalten (Zeit: oben→unten, Prozess: links→rechts).

90

Sind die Modelle versioniert?

Baseline: Diagramme altern schnell. Versionieren Sie Modelle gemeinsam mit dem Code (Git/Tagging).

91

Wurde geprüft, ob das Modell zur Realität passt?

Validierung: Walkthrough mit Fachbereich und Entwicklern. "Können wir das so bauen?"

Textuelle Spezifikation (Der Feinspezifikation)
Hier entstehen die klassischen Anforderungsdokumente (Lastenheft/Pflichtenheft) oder die finalen User Stories. Wir nutzen Dokumentvorlagen, um Struktur sicherzustellen, und wenden Satzschablonen an, um Anforderungen syntaktisch korrekt zu formulieren (z. B. "Das System muss [Wem?] [Was?] ermöglichen"). Parallel wird das Glossar aufgebaut, um eine einheitliche Terminologie zu sichern.

Details

3.2 Textuelle Spezifikation (Operative Audit-Checkliste)

diagram-3-2-mindmap

A – Satzbau & Syntax (Schablonen) Dieser Abschnitt fordert die Nutzung standardisierter Satzschablonen (z. B. nach SOPHIST oder ISO 29148). Anforderungen müssen atomar (eine Funktion pro Satz), kurz (max. 20 Wörter) und aktiv (kein Passiv) formuliert sein. Mehrwert: Erhöht die Verständlichkeit drastisch, verhindert Missverständnisse in internationalen Teams und macht Anforderungen direkt testbar.

B – Verbindlichkeit (Modalverben) Hier wird die juristische Relevanz geklärt: „Muss“ für Pflicht, „Soll“ für Empfehlung, „Kann“ für Möglichkeiten. Wörter wie „vielleicht“ oder „gegebenenfalls“ werden gestrichen. Mehrwert: Schafft Rechtssicherheit im Vertrag (Pflichtenheft) und verhindert Diskussionen darüber, was genau geschuldet ist.

C – Logik & Bedingungen Dieser Bereich präzisiert logische Verknüpfungen (UND/ODER) und Bedingungen („Falls“ vs. „Sobald“). Es wird sichergestellt, dass Verneinungen eindeutig sind und „Sonst“-Fälle spezifiziert werden. Mehrwert: Deckt Logiklücken auf (Was passiert im Else-Fall?) und verhindert Fehlentwicklungen durch mathematisch mehrdeutige Aussagen.

D – Messbarkeit & Präzision Vage Begriffe wie „schnell“, „viele“ oder „sofort“ werden durch konkrete Zahlen und Zeitspannen ersetzt. Einheiten (cm, ms) und Intervalle (inklusive/exklusive) müssen präzise angegeben sein. Mehrwert: Macht Anforderungen objektiv prüfbar und verhindert Streit bei der Abnahme („Für mich ist das zu langsam“).

E – Inhalt & Kontext Es wird geprüft, ob die Systemgrenze eingehalten wird („Das System druckt“ vs. „Der Drucker druckt“) und ob alle notwendigen Informationen (Quelle, Senke, Trigger) vorhanden sind. Implizite Annahmen („wie üblich“) werden expliziert. Mehrwert: Stellt sicher, dass die Anforderungen vollständig sind und keine versteckten Lücken enthalten, die der Entwickler raten muss.

F – Begrifflichkeiten & Sprache Dieser Abschnitt fordert Konsistenz durch Nutzung des Glossars (keine Synonyme/Homonyme) und sachliche Sprache. Emotionale Adjektive („schön“) und Füllwörter („natürlich“) werden entfernt. Mehrwert: Reduziert Interpretationsspielräume und erhöht die Professionalität und Lesbarkeit der Spezifikation.

G – Agile User Stories Für agile Projekte wird das Format „Als…​ möchte ich…​ damit…​“ und die Einhaltung der INVEST-Kriterien geprüft. Akzeptanzkriterien und der Business Value („damit“) sind Pflicht. Mehrwert: Ermöglicht eine effiziente Priorisierung und Umsetzung in Sprints, da der Nutzen klar ist und die Story „Ready“ für die Entwicklung ist.

H – Formatierung & Struktur Jede Anforderung braucht eine eindeutige ID für die Traceability. Referenzen müssen präzise sein, und Listen müssen als abgeschlossen oder offen gekennzeichnet werden. Beispiele werden klar vom Anforderungstext getrennt. Mehrwert: Sichert die Referenzierbarkeit im Test- und Änderungsmanagement und verhindert, dass Beispiele fälschlicherweise als harte Anforderung implementiert werden.

I – Reinheit & Unabhängigkeit Anforderungen sollen frei von Begründungen („Rationale“) und technischen Lösungsdetails („Dropdown“) sein. Aufzählungen werden gesplittet, um Testbarkeit zu gewährleisten. Platzhalter („TBD“) sind verboten. Mehrwert: Hält die Spezifikation lösungsneutral (öffnet Raum für bessere technische Lösungen) und stellt sicher, dass jede Anforderung einzeln testbar ist.

Nr. Frage Operative Implikation & Handlungsanweisung

A

SATZBAU & SYNTAX (SCHABLONEN)

1

Folgt dieser Satz der vereinbarten Satzschablone?

Standardisierung: Nutzen Sie SOPHIST oder ISO 29148. Struktur: [Bedingung] + [Subjekt] + [Modalverb] + [Objekt] + [Prozesswort]. Wildwuchs verhindern.

2

Steht die Bedingung am Anfang des Satzes?

Kontext: "Wenn X, dann Y". Starten Sie mit der Bedingung, damit der Leser sofort weiß, ob die Anforderung für ihn relevant ist.

3

Ist das System (oder die Komponente) als Subjekt benannt?

Verantwortung: "Das System muss…​" ist besser als "Es wird gespeichert" (Passiv). Das Passiv versteckt den Akteur.

4

Steht das Prozesswort (Verb) am Ende des Satzes?

Klammerung: Im Deutschen gehört das Verb ans Ende ("…​speichern"). Das zwingt zum Zu-Ende-Lesen.

5

Enthält der Satz genau ein Prozesswort?

Atomarität: "Das System berechnet und speichert" sind ZWEI Anforderungen. Splitten Sie sie auf, um sie separat testen zu können.

6

Ist die Anforderung in einem Satz formulierbar?

Komplexität: Schachtelsätze mit 3 Nebensätzen sind unverständlich. Faustregel: Max. 20 Wörter.

7

Ist der Satzbau Subjekt-Prädikat-Objekt?

Einfachheit: Einfache Sätze reduzieren Übersetzungsfehler und Missverständnisse bei internationalen Teams.

74

Wurde die Satzschablone an den Projekttyp angepasst?

Tailoring: Nutzen Sie für Agile User Stories, für Safety-Projekte Satzschablonen. Mischen Sie die Stile nicht in einem Dokument.

B

VERBINDLICHKEIT (MODALVERBEN)

8

Ist das Modalverb (muss/soll/kann) korrekt gewählt?

Rechtssicherheit: "Muss" = Pflicht (Vertragsbestandteil). "Soll" = Empfehlung. "Kann" = Möglichkeit. Definieren Sie dies im Glossar.

9

Wird das Wort „wird“ für Zukünftiges oder Fakten verwendet?

Abgrenzung: "Das System wird…​" ist eine Faktenbeschreibung, keine Anforderung. Ersetzen Sie es durch "muss" für Anforderungen.

10

Wird "soll" vs. "sollte" korrekt unterschieden?

Konsistenz: "Sollte" ist juristisch weich. Vermeiden Sie den Konjunktiv in Pflichtenheften.

11

Sind "Kann"-Bestimmungen echte Anforderungen?

Intentions-Check: "Das System kann drucken." → Heißt das, es muss die Fähigkeit haben (Muss-Anforderung)? Dann umformulieren: "Das System muss fähig sein zu drucken."

12

Wurden "Vielleicht"-Wörter vermieden?

Klarheit: Streichen Sie "gegebenenfalls", "eventuell", "u.U.". Eine Anforderung gilt entweder oder sie gilt nicht.

C

LOGIK & BEDINGUNGEN

13

Ist die Bedingung zeitlich („sobald“) oder logisch („falls“)?

Präzision: "Wenn" ist mehrdeutig. Nutzen Sie "Sobald" für Zeitpunkte (Trigger) und "Falls" für logische Bedingungen.

14

Fehlt der „Sonst“-Fall für diese Bedingung?

Vollständigkeit: "Falls X > 10…​" → Was passiert bei X ⇐ 10? Spezifizieren Sie den Else-Zweig oder verweisen Sie auf Standardverhalten.

15

Werden logische Operatoren (UND/ODER) eindeutig genutzt?

Mengenlehre: "Kunden aus A und B" → Beide Städte (Schnittmenge) oder alle aus A plus alle aus B (Vereinigung)? Klären!

16

Sind "und/oder" Verknüpfungen geklammert?

Reihenfolge: "A und B oder C" ist mathematisch mehrdeutig. Schreiben Sie "(A und B) oder C".

17

Ist die Verneinung eindeutig?

Falle: "A und B dürfen nicht auftreten" → (Nicht A) und (Nicht B)? Oder Nicht (A und B)? Formulieren Sie positiv um.

18

Werden doppelte Verneinungen vermieden?

Verständlichkeit: "Es darf nicht fehlen" → "Es muss vorhanden sein". Gehirne verarbeiten positive Sätze schneller.

19

Ist die Anforderung positiv formuliert?

Testbarkeit: "Das System darf nicht abstürzen" ist schwer testbar. "Das System muss verfügbar bleiben" ist besser.

20

Ist die Schachtelung von Bedingungen vermeidbar?

Lesbarkeit: "Wenn A, dann wenn B, dann C". Nutzen Sie Entscheidungstabellen für komplexe Logik statt Text.

D

MESSBARKEIT & PRÄZISION

21

Ist die Bedingung messbar definiert?

Härte: "Bei hoher Last" ist wertlos. "Bei > 1000 Requests/Sekunde" ist testbar.

22

Sind Mengenangaben konkret?

Skalierung: "Viele Nutzer" → Definieren Sie Obergrenzen für Sizing ("Bis zu 5000 Named User").

23

Sind Häufigkeiten definiert?

Lastprofil: "Oft" → "Täglich um 08:00 Uhr". Wichtig für Batch-Fenster-Planung.

24

Wird "sofort" durch eine Zeitspanne ersetzt?

Performance: "Sofort" existiert in der Informatik nicht. Schreiben Sie "Innerhalb von 500ms".

25

Wird "gleichzeitig" präzisiert?

Concurrency: "Gleichzeitig" ist technisch unmöglich (außer bei Quanten-PCs). Meinen Sie "im selben Transaktionskontext"?

26

Ist die Maßeinheit direkt beim Wert angegeben?

Einheiten: "Länge: 50" ist gefährlich (Mars Climate Orbiter Absturz!). Schreiben Sie "50 cm".

27

Sind "Bis"-Angaben eindeutig (einschließlich/ausschließlich)?

Randwerte: "Bis 100" → Ist 100 inkludiert? Schreiben Sie "bis einschließlich 100".

28

Sind "Zwischen"-Angaben eindeutig?

Intervalle: Nutzen Sie mathematische Notation [1, 5] oder Text "von 1 bis einschließlich 5".

E

INHALT & KONTEXT

29

Wurde die Systemgrenze im Satz beachtet?

Verantwortung: "Der Drucker druckt" ist falsch (Kontext). "Das System sendet Druckdaten" ist richtig (System).

30

Beschreibt der Satz das „Was“ und nicht das „Wie“?

Lösungsneutralität: "Daten in SQL schreiben" ist Design. "Daten persistent speichern" ist Anforderung.

31

Fehlt das Objekt, auf das sich das Verb bezieht?

Syntax: "Das System speichert." → Was? Den Datensatz? Das Protokoll? Ergänzen Sie das Akkusativ-Objekt.

32

Fehlt die Herkunft der Information?

Quelle: "Das System zeigt Wetterdaten." → Woher? (Sensor? API?). Definieren Sie die Quelle.

33

Fehlt das Ziel der Information?

Senke: "Das System exportiert." → Wohin? Dateisystem? E-Mail? Drucker?

34

Ist der Ort der Handlung klar (Wo)?

Medium: "Anzeige" → Auf dem Handy? Auf dem Admin-Dashboard? Auf dem Kassendrucker?

35

Ist der Auslöser der Funktion klar?

Trigger: Passiert das Speichern automatisch (Timer) oder manuell (Button)?

36

Werden implizite Annahmen gemacht?

Explizierung: "Wie üblich" ist verboten. Was für Sie üblich ist, ist für den indischen Entwickler fremd.

F

BEGRIFFLICHKEITEN & SPRACHE

37

Werden Synonyme vermieden?

Glossar: Nutzen Sie für "Auftrag" immer "Auftrag", nicht mal "Bestellung" oder "Order". Konsistenz ist King.

38

Werden Homonyme vermieden?

Eindeutigkeit: Prüfen Sie Begriffe wie "Schloss" oder "Bank" auf Doppeldeutigkeit. Nutzen Sie das Glossar.

39

Sind Eigennamen als solche erkennbar?

Formatierung: Schreiben Sie Eigennamen (z.B. Modulnamen) Groß oder Kursiv, um sie von Verben/Adjektiven zu trennen.

40

Werden definierte Zustände verwendet?

State-Machine: Wenn Sie "fertig" schreiben, muss es einen Status "Fertig" im Zustandsmodell geben.

41

Ist die Sprache neutral und sachlich?

Objektivität: Keine Poesie. "Das System verhält sich kooperativ" ist Quatsch.

42

Wurden emotionale Adjektive vermieden?

Subjektivität: "Benutzerfreundlich", "Schön", "Einfach". Ersetzen Sie diese durch messbare Kriterien (Klicks, Zeit).

43

Wurden Tautologien (Doppelungen) entfernt?

Kürze: "Eine eindeutige ID, die einmalig ist." → "Eindeutig" reicht.

44

Wurden Füllwörter wie "natürlich", "selbstverständlich" vermieden?

Noise: Streichen Sie Füllwörter ersatzlos. Sie blähen das Dokument auf und verwässern den Fokus.

45

Sind Abkürzungen bei der ersten Verwendung ausgeschrieben?

Verständnis: "BSI (Bundesamt für…​)" beim ersten Mal. Danach "BSI". Glossar-Link setzen.

G

AGILE USER STORIES

46

Ist die User Story nach dem Muster „Als…​ möchte ich…​ damit…​“ aufgebaut?

Standard: Nutzen Sie das Template. Es zwingt Sie, Rolle, Funktion und Nutzen zu benennen.

47

Ist der Nutzen („damit…​“) in der User Story klar formuliert?

Value: "Damit es funktioniert" ist kein Nutzen. "Damit ich Zeit spare" ist ein Nutzen. Ohne Nutzen keine Priorisierung.

48

Erfüllt die User Story die INVEST-Kriterien?

Qualität: Independent, Negotiable, Valuable, Estimable, Small, Testable. Prüfen Sie jedes Kriterium.

49

Sind die Akzeptanzkriterien vollständig?

Definition of Done: Eine Story ohne Akzeptanzkriterien ist nicht "Ready". Nutzen Sie Gherkin (Given-When-Then).

50

Ist die User Story klein genug für einen Sprint?

Slicing: Wenn die Story > 5 Story Points hat (oder > 3 Tage), splitten Sie sie auf. Elefanten-Carpaccio!

H

FORMATIERUNG & STRUKTUR

51

Ist die Anforderung-ID korrekt formatiert?

Traceability: Jede Anforderung braucht eine ID (REQ-123). Keine Bulletpoints ohne ID verwenden (nicht referenzierbar).

52

Sind Referenzen auf andere Dokumente präzise?

Link: "Siehe ISO 12345 Kapitel 4.2", nicht "Siehe Norm". Dokumente ändern sich, Kapitel bleiben oft stabiler.

53

Wurden Verweise auf "oben" oder "unten" vermieden?

Layout: In HTML/Req-Tools verschieben sich Inhalte. Nutzen Sie absolute Links auf IDs.

54

Sind Listen vollständig oder abschließend?

Scope: "Farben wie Rot, Grün" (offen) vs. "Die Farben Rot und Grün" (geschlossen). "Und zwar" schließt die Liste ab.

55

Sind Beispiele als solche gekennzeichnet ("z. B.")?

Verbindlichkeit: Beispiele sind gut für Verständnis, aber schlecht für Tests. Trennen Sie Anforderungstext von Beispielen.

56

Sind Fußnoten vermieden worden?

Lesefluss: Niemand liest Fußnoten in Spezifikationen. Wichtige Infos in den Text, unwichtige weg.

57

Ist die Formatierung (Fett/Kursiv) konsistent genutzt?

Style: GUI-Elemente immer fett oder [eckig]. Das Auge scannt nach Mustern.

I

REINHEIT & UNABHÄNGIGKEIT

58

Ist die Anforderung frei von Begründungen?

Separation: "Weil der Gesetzgeber das will" gehört ins Attribut "Rationale", nicht in den Anforderungstext.

59

Wurden Aufzählungen in separate Anforderungen zerlegt?

Testbarkeit: "Das System muss A, B und C können." → Wenn A geht, aber B nicht: Ist der Test failed? Besser 3 IDs vergeben.

60

Werden Begriffe aus der Lösungswelt statt der Problemwelt verwendet?

Abstraktion: Schreiben Sie "Auswahlmöglichkeit" statt "Dropdown". Vielleicht ist auf dem Handy ein "Spinner" besser.

61

Ist die Anforderung unabhängig von der Implementierung?

Blackbox: Beschreiben Sie das Verhalten nach außen, nicht die Innereien (Tabellen, Klassen).

62

Wurde die "Einerseits-Andererseits"-Falle vermieden?

Konflikt: "Sicher aber einfach" ist ein Zielkonflikt. Entscheiden Sie sich oder definieren Sie den Kompromiss messbar.

63

Sind Platzhalter (XY) entfernt?

Fertigstellung: Suchen Sie nach "TBD", "?", "XY". Ein Dokument mit Platzhaltern darf nicht freigegeben werden.

64

Ist die Priorität im Dokument/Tool vermerkt?

Wichtigkeit: Prio (Must/Should) muss als Metadatum an der Anforderung hängen, nicht nur im Text ("wichtig").

Sprachlicher Feinschliff (Die Linguistik)
Bevor das Dokument in die Prüfung geht, erfolgt ein linguistischer Qualitätscheck. Wir suchen gezielt nach sprachlichen Defekten wie Tilgungen (fehlende Informationen), Verzerrungen (subjektive Adjektive wie "benutzerfreundlich") oder Generalisierungen ("immer", "nie"). Ziel ist es, den Interpretationsspielraum auf Null zu reduzieren.

Details

3.3 Sprachlicher Feinschliff & Syntax (Operative Audit-Checkliste)

diagram-3-3-mindmap

A – Satzstruktur & Vollständigkeit Dieser Abschnitt prüft Sätze auf fehlende Satzglieder. Jede Anforderung muss Ross und Reiter nennen: Wer tut es (Subjekt)? Mit wem (Objekt)? Wo (Ort) und wann (Zeitpunkt)? Mehrwert: Verhindert das klassische "Passiv-Problem" ("Es wird gespeichert"), bei dem niemand weiß, wer (System oder User?) für die Aktion verantwortlich ist.

B – Nominalisierung & Prozesswörter Hier werden Substantivierungen enttarnt. Wörter wie "Verarbeitung", "Prüfung" oder "Optimierung" verschleiern oft komplexe Prozesse. Diese "Blackboxes" müssen aufgebrochen und konkretisiert werden. Mehrwert: Zwingt dazu, abstrakte Begriffe in konkrete, programmierbare Schritte (Validieren, Berechnen, Senden) zu übersetzen.

C – Vagheit & Unmessbarkeit (Soft Words) Dieser Bereich eliminiert weiche Begriffe wie "benutzerfreundlich", "schnell" oder "ausreichend". Solche subjektiven Adjektive müssen durch messbare Kriterien oder Referenzwerte ersetzt werden. Mehrwert: Macht Qualitätsanforderungen objektiv prüfbar und verhindert Streit bei der Abnahme, da "schnell" für jeden etwas anderes bedeutet.

D – Quantoren (Alle, Keine, Immer) Absolute Begriffe wie "alle", "nie" oder "immer" werden hinterfragt. Gibt es wirklich keine Ausnahme (z.B. für Admins)? Gilt "überall" auch hinter der Firewall? Mehrwert: Deckt logische Fehler und vergessene Randfälle (Edge Cases) auf, die oft erst im Betrieb zu Problemen führen.

E – Referenzen & Bezüge Es wird geprüft, worauf sich Pronomen ("dieser", "er") beziehen, um Missverständnisse zu vermeiden. Auch unklare Orts- ("hier", "dort") oder Rollenbezüge ("wir") werden präzisiert. Mehrwert: Sichert, dass Bezüge eindeutig sind, besonders wenn Sätze isoliert (z.B. in einem Ticket-System) gelesen werden.

F – Modalverben & Verbindlichkeit Hier wird die juristische Härte der Aussage geprüft. "Muss" ist Pflicht, "Sollte" ist Wunsch. Wörter wie "kann" (Fähigkeit vs. Erlaubnis) oder "darf nicht" (technisches vs. organisatorisches Verbot) werden geschärft. Mehrwert: Schafft Rechtssicherheit darüber, was Vertragsbestandteil ist und was nur eine Option oder ein Wunsch darstellt.

G – Logik & Verknüpfungen Dieser Abschnitt analysiert logische Operatoren. Ist das "Oder" ein exklusives Entweder-Oder (XOR)? Worauf bezieht sich das "Und" in einer Aufzählung? Mehrwert: Verhindert mathematische Mehrdeutigkeiten, die zu falscher Programmierung von Filtern oder Bedingungen führen würden.

H – Zeit & Reihenfolge (Temporalität) Begriffe wie "vorher", "während" oder "bis" werden präzisiert. Gehören Grenzwerte (bis Freitag) dazu? Heißt "gleichzeitig" wirklich parallel oder nur schnell hintereinander? Mehrwert: Klärt zeitliche Abläufe und Trigger, was essenziell für die Implementierung von Workflows und Statusübergängen ist.

I – Stil & Lesbarkeit Dieser Bereich sorgt für einen sachlichen, professionellen Stil. Schachtelsätze, doppelte Verneinungen und Füllwörter werden entfernt. Fachbegriffe müssen konsistent zum Glossar sein. Mehrwert: Erhöht die Lesegeschwindigkeit und das Verständnis, reduziert "Rauschen" in der Kommunikation und wirkt professionell.

Nr. Frage Operative Implikation & Handlungsanweisung

A

SATZSTRUKTUR & VOLLSTÄNDIGKEIT

1

Wer führt die Handlung aus (fehlendes Subjekt)?

Verantwortung: Passiv ist verboten ("Es wird gespeichert"). Nennen Sie den Akteur: "Das System speichert" oder "Der User speichert".

2

Wen oder was betrifft die Handlung (fehlendes Objekt)?

Präzision: "Das System überträgt." → Was? Den Datensatz? Alle Datensätze? Ergänzen Sie das Akkusativ-Objekt.

3

An wen richtet sich die Information (fehlender Empfänger)?

Kommunikation: "Das System sendet eine Warnung." → An wen? Den Nutzer (Pop-up) oder den Admin (Log)?

4

Woher stammt die Information (fehlende Quelle)?

Herkunft: "Der Wetterbericht wird angezeigt." → Von welchem Dienst? Definieren Sie die Quelle (API/Sensor).

5

Wohin geht die Information (fehlendes Ziel)?

Senke: "Daten exportieren." → Wohin? In den Download-Ordner? An einen FTP-Server?

6

Wie genau wird die Handlung ausgeführt (fehlendes Instrument)?

Methode: "Der Nutzer authentifiziert sich." → Wie? Passwort? SSO? Token?

7

Wann genau passiert es (fehlender Zeitpunkt)?

Trigger: "Das System erstellt ein Backup." → Wann? Nachts? Bei Klick? Ereignisgesteuert?

8

Wo genau passiert es (fehlender Ort)?

Kontext: "Fehlermeldung anzeigen." → Wo? Im Browser? Auf dem Server-Display?

9

Unter welcher Bedingung passiert es (fehlende Kondition)?

Logik: "Der Rabatt wird gewährt." → Immer? Oder nur >100€? Ergänzen Sie den "Wenn"-Satz.

B

NOMINALISIERUNG & PROZESSWÖRTER

10

Was genau ist mit diesem Nomen gemeint (unspezifisches Substantiv)?

Konkretisierung: "Die Daten" ist zu vage. Prüfen Sie, ob das Nomen im Glossar (2.3) definiert ist. Wenn nicht → Definieren!

11

Was bedeutet „Verarbeitung“ konkret (Nominalisierung)?

Blackbox: "Verarbeitung starten" verschleiert den Prozess. Prüfen Sie, ob der Prozess in 2.3 spezifiziert ist (Berechnen, Speichern, Senden).

12

Was beinhaltet die „Überprüfung“?

Validierung: Was wird geprüft? Format? Inhalt? Berechtigung? Listen Sie die Prüfschritte auf oder referenzieren Sie die Validierungsregel aus 2.3.

13

Was bedeutet „Optimierung“ hier?

Zielkonflikt: Optimieren nach Zeit, Speicher oder Qualität? Definieren Sie die Zielfunktion.

14

Was heißt „Anmeldung“ genau?

Prozess: Registrierung (neuer User) oder Login (bekannter User)? Nutzen Sie die eindeutigen Begriffe aus dem Glossar.

15

Was steckt hinter der „Kommunikation“?

Protokoll: Datenaustausch? Ping? Handshake? Spezifizieren Sie den Inhalt der Nachricht.

16

Was genau ist eine „Fehlermeldung“?

Inhalt: Welcher Text? Welcher Code? Welche Farbe? Referenzieren Sie die Fehlertabelle.

C

VAGHEIT & UNMESSBARKEIT (SOFT WORDS)

17

Was bedeutet „Benutzerfreundlichkeit“ für Sie?

Subjektivität: Ersetzen Sie "freundlich" durch messbare NFRs aus 2.4 (z.B. "Max. 3 Klicks" oder "SUS-Score > 80").

18

Was heißt „schnell“ in Sekunden?

NFR: "Schnell" ist keine Anforderung. "Antwortzeit < 1s" ist eine Anforderung. Siehe 2.4.

19

Was ist „ausreichend“ Speicherplatz?

Sizing: "Ausreichend" für wen? Definieren Sie: "Mindestens 10 GB pro User".

20

Besser als was (unvollständiger Vergleich)?

Referenz: "Besser als das Altsystem". Nennen Sie den Benchmark-Wert.

21

Einfacher als was?

Metrik: "Einfacher" → "Weniger Schritte als vorher".

22

Sicherer als was?

Security: "Sicherer" → "2-Faktor-Auth statt Passwort". Siehe Security-Vorgaben in 1.4/2.4.

23

Was bedeutet „normalerweise“?

Ausnahme: "Normalerweise" impliziert Ausnahmen. Definieren Sie diese! Sonst baut der Entwickler nur den Happy Path.

24

Was heißt „in der Regel“?

Regelwerk: Nennen Sie die Regel UND die Ausnahme explizit.

25

Was bedeutet „transparent“?

Sichtbarkeit: Heißt das "Jeder sieht alles" oder "Nachvollziehbar im Log"?

26

Was heißt „flexibel“?

Konfiguration: Heißt das "Skalierbar" oder "Anpassbar durch User"?

27

Was bedeutet „modern“?

Design: "Modern" veraltet morgen. Referenzieren Sie einen Styleguide.

28

Was heißt „robust“?

Resilienz: Definiert als "Verfügbarkeit auch bei Teilausfall". Siehe 2.4.

29

Was bedeutet „effizient“?

Ressourcen: Weniger CPU? Weniger Zeit? Weniger Geld? Präzisieren!

30

Was heißt „übersichtlich“?

Layout: Definieren Sie "Max. 7 Elemente pro Liste" oder "Sortierbar".

D

QUANTOREN (ALLE, KEINE, IMMER)

31

Gilt „alle“ wirklich ohne Ausnahme?

Universalquantor: "Alle User" schließt oft "Admin" oder "System-User" fälschlicherweise mit ein. Prüfen!

32

Heißt „nie“ wirklich niemals?

Verbot: "Daten nie löschen" verstößt gegen DSGVO. Definieren Sie die Löschfristen als Ausnahme.

33

Meinen Sie mit „immer“ wirklich jeden Fall?

Zwang: "Button ist immer sichtbar" → Auch im Druckmodus? Auch auf Mobile?

34

Ist mit „keiner“ wirklich niemand gemeint?

Zugriff: "Keiner hat Zugriff" → Auch nicht der Root-Admin zur Wartung? (Break-Glass-Account).

35

Was bedeutet „jeder“?

Öffentlichkeit: "Jeder kann das sehen" → Öffentlich im Internet ohne Login?

36

Was heißt „nichts“?

Feedback: "Es passiert nichts" ist schlechte UX. Das System sollte Feedback geben ("Keine Ergebnisse").

37

Gilt „überall“ wirklich an jedem Ort?

Netzwerk: "Zugriff überall" → Auch aus China (Firewall)? Auch ohne VPN?

38

Ist „sofort“ wirklich Echtzeit?

Physik: "Sofort" gibt es nicht. "Unter 100ms" ist wahrnehmbar sofort. Siehe NFRs (2.4).

39

Bedeutet „vollständig“ wirklich 100%?

Scope: "Vollständige Historie" → Seit 1990? Migrierte Daten auch?

40

Heißt „automatisch“ ohne jeden Klick?

Trigger: Muss der User den Prozess anstoßen oder läuft ein Timer?

E

REFERENZEN & BEZÜGE

41

Auf was bezieht sich „dieser/diese/dieses“?

Referenzfehler: "Der Kunde ruft den Auftrag auf. Er wird gelöscht." → Wer? Kunde oder Auftrag? Wiederholen Sie das Nomen.

42

Wer ist „wir“?

Rolle: "Wir geben frei." → Die IT? Der Fachbereich? Nennen Sie die Rolle.

43

Was bedeutet „das System“ hier?

Komponente: In verteilten Systemen unklar. "Das ERP-System" oder "Der Webserver".

44

Welcher „Nutzer“ ist gemeint?

Persona: "Der Nutzer" ist zu generisch. "Der Antragssteller" oder "Der Sachbearbeiter".

45

Was heißt „die Schnittstelle“?

Interface: "An die Schnittstelle senden." → Welche? SAP? Datev? Nennen Sie den Namen.

46

Was bedeutet „der Prozess“?

Ablauf: Der technische Prozess (Thread) oder der Geschäftsprozess?

47

Was sind „die Daten“?

Objekt: "Daten löschen." → Stammdaten? Bewegungsdaten? Logs?

48

Was heißt „hier“?

Ort: "Hier klicken." → Auf welcher Maske? In welchem Dialog?

49

Was bedeutet „oben“?

Layout: "Wie oben beschrieben." → Nutzen Sie absolute Referenzen ("Kapitel 3.1"), da sich Text verschiebt.

50

Was heißt „dort“?

Ziel: "Dort speichern." → In welcher Tabelle? In welchem Verzeichnis?

F

MODALVERBEN & VERBINDLICHKEIT

51

Ist das Modalverb „sollte“ eine echte Anforderung?

Soft: "Sollte" ist ein Wunsch. In Pflichtenheften vermeiden. Nutzen Sie "Muss" oder "Wird".

52

Heißt „kann“ eine Möglichkeit für das System oder den Nutzer?

Fähigkeit: "Der Nutzer kann drucken" (Erlaubnis). "Das System kann abstürzen" (Risiko). Präzisieren!

53

Ist „darf nicht“ ein hartes Verbot?

Constraint: Muss technisch verhindert werden. Nicht nur organisatorisch verbieten.

54

Bedeutet „muss“ eine juristische Pflicht?

Compliance: "Muss" ist vertragsrelevant. Nur für echte Anforderungen nutzen.

55

Ist „wird“ eine Beschreibung der Zukunft oder eine Anforderung?

Fakt: "Wird" beschreibt Fakten ("Morgen wird es hell"). Für Anforderungen "Muss" nutzen.

56

Was heißt „möchte“?

Intention: User Stories nutzen "möchte". Systemanforderungen nutzen "muss".

57

Bedeutet „nicht können“, dass es unmöglich ist oder verboten?

UI: "Kann nicht speichern" → Button ausgegraut (Verbot) oder Fehlermeldung (Fehler)?

58

Ist „brauchen“ eine Anforderung?

Dependency: "Braucht Internet" ist eine Vorbedingung (Prerequisite).

59

Was heißt „wollen“?

Ziel: "Wir wollen wachsen" ist ein Geschäftsziel, keine Systemanforderung.

60

Ist „dürfen“ eine Berechtigung?

Rechte: "Darf sehen" impliziert eine Rolle/Rechte-Prüfung.

G

LOGIK & VERKNÜPFUNGEN

61

Ist die „Wenn-Dann“ Logik vollständig?

Else: "Wenn A, dann B." → Was passiert, wenn nicht A? (Standardverhalten?).

62

Ist das „Oder“ exklusiv (XOR) oder inklusiv?

Auswahl: "Kaffee oder Tee" (XOR). "Milch oder Zucker" (Inklusiv). Schreiben Sie "Entweder…​oder" für XOR.

63

Was bindet das „Und“?

Klammer: "Alte Männer und Frauen" → (Alte Männer) + Frauen? Oder Alte (Männer + Frauen)? Umformulieren!

64

Bezieht sich „nicht“ auf den ganzen Satz?

Negation: "Ich sehe nicht A und B" → Weder noch? Oder eines von beiden nicht?

65

Was bedeutet „sowohl als auch“?

Und: Synonym für Und. Prüfen auf Gleichzeitigkeit.

66

Heißt „außer“ eine Ausnahme?

Exklusion: "Alle außer Admin." Definieren Sie die Regel für den Admin.

67

Was bedeutet „je nachdem“?

Switch: "Je nachdem wie der Status ist." → Listen Sie alle Fälle auf (Case-Statement).

68

Was heißt „in Abhängigkeit von“?

Funktion: "Preis abhängig von Menge." → Definieren Sie die Staffel-Tabelle.

69

Ist „bzw.“ ein Oder?

Unklar: "A bzw. B". Meistens "oder". Ersetzen Sie es.

70

Was bedeutet „sowie“?

Und: Synonym für Und.

71

Ist „gleichzeitig“ technisch möglich?

Parallelität: "Drucken und Speichern gleichzeitig." → Asynchron im Hintergrund?

H

ZEIT & REIHENFOLGE (TEMPORALITÄT)

72

Was heißt „vorher“?

Sequenz: "Vorher prüfen." → Unmittelbar davor? Oder irgendwann im Prozess?

73

Was bedeutet „nachdem“?

Trigger: "Nachdem gespeichert wurde." → Success-Event abwarten.

74

Was heißt „während“?

Zustand: "Während des Ladens." → Ladebalken anzeigen? UI sperren?

75

Was bedeutet „bis“?

Ende: "Bis Freitag." → Einschließlich Freitag (23:59)?

76

Was heißt „seit“?

Start: "Seit 2020." → Ab 01.01.2020?

77

Was bedeutet „regelmäßig“?

Intervall: "Regelmäßig prüfen." → Täglich? Stündlich? Cron-Job definieren.

78

Was heißt „oft“?

Häufigkeit: "Tritt oft auf." → >10%? >50%?

79

Was bedeutet „selten“?

Edge Case: "Wird selten genutzt." → Lohnt sich die Entwicklung?

80

Was heißt „in Zukunft“?

Roadmap: "In Zukunft auch mobil." → Phase 2? Oder nie?

I

STIL & LESBARKEIT

81

Ist die Verneinung nötig?

Positiv: "Nicht unklug" → "Klug". Gehirn verarbeitet positive Sätze schneller.

82

Sind Schachtelsätze vermeidbar?

Kürze: Max. 1 Komma pro Satz. Aufzählungen nutzen.

83

Werden Fachbegriffe konsistent genutzt?

Konsistenz: Prüfen Sie gegen das Glossar aus 2.3. Synonyme ("Kunde" mal "Client") sind verboten.

84

Sind Füllwörter gestrichen?

Noise: "Eigentlich", "Quasi", "Halt" streichen.

85

Ist der Ton sachlich?

Objektiv: Keine Emotionen ("Leider", "Zum Glück").

86

Sind Anglizismen nötig?

Sprache: "Committed" vs. "Verpflichtet". Zielgruppe beachten.

87

Werden Abkürzungen beim ersten Mal erklärt?

Erklärung: "BSI (Bundesamt für Sicherheit…​)" beim ersten Auftreten. Prüfen Sie gegen die Liste in 2.3.

88

Sind Aufzählungen einheitlich formatiert?

Liste: Bullets nutzen statt Komma-Wüsten im Fließtext.

89

Ist die Formatierung (Fett/Kursiv) sinnvoll?

Scanbarkeit: UI-Elemente fett, Variablen monospaced.

Phase 4: Prüfung & Einigung

Bevor eine Anforderung an die Entwicklung übergeben wird, muss sie qualitätsgesichert und abgestimmt sein. Dies ist das "Quality Gate".

Validierungsvorbereitung & Durchführung (Das Review)
Qualität entsteht nicht durch Zufall, sondern durch Prüfung. Wir wählen die passende Prüfmethode (z. B. formale Inspektion für Sicherheitskritisches, Walkthrough für Unkritisches) und führen diese durch. Hierbei kommen Checklisten und perspektivenbasiertes Lesen zum Einsatz, um Fehler systematisch zu finden. Auch Prototypen werden genutzt, um Feedback von Endanwendern einzuholen.

Details

4.1 Validierung, Konfliktmanagement & Priorisierung (Operative Audit-Checkliste)

diagram-4-1-mindmap

A – Validierungs-Vorbereitung & Review-Planung Dieser Abschnitt sichert den organisatorischen Rahmen der Prüfung. Ziel, Scope, Zeitplan und Ressourcen werden definiert, und harte Abbruchkriterien (z. B. zu viele Fehler auf Seite 1) werden festgelegt. Die Prüfung startet erst, wenn das Dokument "Ready" ist. Mehrwert: Verhindert ineffiziente Reviews, bei denen unvorbereitete Teilnehmer über unfertige Dokumente diskutieren, und spart so massiv Zeit und Kosten.

B – Review-Methoden & Rollen Hier wird die passende Prüfmethode gewählt: Vom leichten "Walkthrough" für Wissensverteilung bis zur formalen "Inspektion" für sicherheitskritische Teile. Rollen wie Moderator (führt) und Gutachter (prüft) werden klar getrennt, um Objektivität zu sichern. Mehrwert: Garantiert die angemessene Prüftiefe je nach Risiko und verhindert "Betriebsblindheit", indem unabhängige Experten und Stakeholder eingebunden werden.

C – Inhaltliche Qualitätsprüfung (Checklisten) Dies ist der Kern der Prüfung: Anforderungen werden auf Vollständigkeit, Notwendigkeit ("Goldplating" vermeiden), Konsistenz, Eindeutigkeit und Testbarkeit geprüft. Auch die Lösungsneutralität und korrekte Begriffsverwendung stehen im Fokus. Mehrwert: Findet inhaltliche Fehler frühzeitig, bevor sie programmiert werden, was die Fehlerbehebungskosten drastisch senkt ("Cost of Change").

D – Prototyping-Validierung (Usability & Feedback) Ergebnisse aus Usability-Tests und Prototypen (aus Phase 2.2) fließen hier ein. Es wird geprüft, ob echte Nutzer die Aufgaben lösen konnten und ob die technische Machbarkeit bestätigt wurde. Mehrwert: Validiert, ob das Spezifizierte auch wirklich das Richtige für den Nutzer ist ("Building the right thing") und technisch funktioniert.

E – Formale Qualitätsprüfung Hier geht es um die Einhaltung von Standards: Dokumentenstruktur, eindeutige IDs, Versionierung, Beschriftungen und Rechtschreibung. Auch die Nutzung von Satzschablonen wird stichprobenartig kontrolliert. Mehrwert: Sorgt für professionelle, wartbare und referenzierbare Dokumente, die als verlässliche Vertragsgrundlage dienen können.

F – Abschluss & Freigabe Dieser Bereich regelt den formalen Abschluss: Einarbeitung von Feedback, formales "Sign-Off" (Unterschrift), Baselining im Tool und Archivierung der Protokolle. Mehrwert: Schafft einen verbindlichen Projektzustand ("Vertrag"), auf dessen Basis die Entwicklung starten kann, ohne ständige Nachverhandlungen.

Nr. Frage Operative Implikation & Handlungsanweisung

A

VALIDIERUNGS-VORBEREITUNG & REVIEW-PLANUNG

1

Welches Ziel verfolgen wir mit dieser Prüfung primär?

Fokus: Abnahme (durch Kunden) oder Fehlersuche (intern)? Wenn das Ziel unklar ist, wird das Review zur Zeitverschwendung.

2

Welche Dokumente oder Artefakte müssen genau geprüft werden?

Scope: Definieren Sie exakt (Kapitel/Version). Prüfen Sie nicht "alles", sondern das Inkrement.

3

Bis wann muss das Review abgeschlossen sein?

Timeline: Setzen Sie eine Deadline VOR dem Sprint-Start. Reviews dürfen die Entwicklung nicht blockieren.

4

Wie viel Zeit steht den Prüfern für die Vorbereitung zur Verfügung?

Ressourcen: Planen Sie Lesezeit im Kalender ein (z.B. 4h). Ein Review ohne Vorbereitung ist wertlos.

5

Sind die Eingangskriterien für das Review erfüllt?

Ready-Check: Kein Review von Entwürfen! Das Dokument muss "fertig", versioniert und vom Autor freigegeben sein.

6

Welche Abbruchkriterien gelten für das Review?

Effizienz: Wenn >10 Fehler auf Seite 1 gefunden werden → Abbruch und Rückgabe an Autor ("Not Ready").

7

Ist das Budget für die Review-Tätigkeiten freigegeben?

Kosten: Externe Gutachter (TÜV, Security) kosten Geld und brauchen Vorlauf für die Beauftragung.

8

Findet die Prüfung in einer Sitzung oder asynchron statt?

Methode: Nutzen Sie asynchrone Tools (Kommentare im Doc) für Formales, Meetings nur für Inhaltliches.

9

Wurden alle benötigten Hilfsmittel (Räume, Beamer, Tools) reserviert?

Logistik: Prüfen Sie Tool-Zugänge für externe Reviewer. Nichts ist peinlicher als fehlende Rechte im Meeting.

10

Ist ein Re-Review (Nachprüfung) fest eingeplant?

Qualitätssicherung: Planen Sie den Termin für die Nachkontrolle der Korrekturen sofort mit ein.

B

REVIEW-METHODEN & ROLLEN

11

Ist ein "Walkthrough" (Durchsprache) ausreichend?

Leichtgewicht: Autor führt durch das Dokument. Gut für Wissensverteilung, schlecht für tiefe Fehlersuche.

12

Benötigen wir eine formale "Inspektion"?

Schwergewicht: Fagan-Inspektion mit Messung ist Pflicht für Safety-Kritische Teile (ISO 26262).

13

Reicht eine "Stellungnahme" (Kollegiales Review)?

Effizienz: "4-Augen-Prinzip" per Mail. Reicht für unkritische Features.

14

Sollen wir "Perspektivenbasiertes Lesen" anwenden?

Qualität: Weisen Sie Rollen zu: Einer liest als "Tester", einer als "Hacker", einer als "User". Findet 30% mehr Fehler.

15

Wer übernimmt die Rolle des "Moderators"?

Führung: Benennen Sie einen Moderator, der NICHT der Autor ist. Der Autor darf sich nicht verteidigen, nur erklären.

16

Wer sind die "Inspektoren" (Gutachter)?

Kompetenz: Laden Sie Fachexperten ein, nicht nur Manager. Ein Entwickler muss die Machbarkeit prüfen.

17

Sind die Prüfer unabhängig vom Autor?

Objektivität: Niemals prüft der Autor sich selbst. Betriebsblindheit ist garantiert.

18

Sind Vertreter aller relevanten Stakeholder-Gruppen dabei?

Vollständigkeit: Wenn es um Buchhaltung geht, muss ein Buchhalter dabei sein. IT kann Fachlichkeit nicht validieren.

19

Ist der "Kunde" oder Auftraggeber Teil des Reviews?

Validierung: Nur der Kunde kann sagen: "Ja, das habe ich gemeint." (Building the right thing).

C

INHALTLICHE QUALITÄTSPRÜFUNG (CHECKLISTEN)

20

Ist die Anforderung vollständig (Inhalt)?

Content: Fehlen Ausnahmen? Fehlen NFRs (Performance, Security)?

21

Ist die Anforderung korrekt (adäquat)?

Validität: Löst sie das Problem des Stakeholders? Fragen Sie: "Hilft dir das wirklich?".

22

Ist die Anforderung notwendig?

Goldplating: Streichen Sie alles, was keinen Business Value hat. Jede Zeile kostet Geld.

23

Ist die Anforderung konsistent zu anderen?

Widerspruch: Prüfen Sie auf Konflikte ("Schnell" vs. "Sicher").

24

Ist die Anforderung eindeutig interpretierbar?

Ambiguität: Suchen Sie nach weichen Wörtern ("sollte", "ggf.", "schnell").

25

Ist die Anforderung prüfbar (testbar)?

Testbarkeit: Schreiben Sie gedanklich den Testfall. Wenn das nicht geht → Anforderung ist schlecht.

26

Enthält die Anforderung vorzeitige Entwurfsentscheidungen?

Lösungsneutralität: Beschreibt sie das "Wie" (Button, SQL) statt des "Was"? Raus damit.

27

Sind die verwendeten Begriffe im Glossar definiert?

Sprache: Prüfen Sie Homonyme/Synonyme. Versteht jeder das Gleiche unter "Kunde"?

28

Sind Referenzen auf Quellen korrekt (Traceability)?

Nachweis: Woher kommt die Anforderung? (Gesetz, CEO, User?). Ohne Quelle keine Rechtfertigung.

29

Ist die Anforderung atomar (einzeln testbar)?

Granularität: Keine "Und"-Verknüpfungen von verschiedenen Funktionen in einem Satz.

D

PROTOTYPING-VALIDIERUNG (USABILITY & FEEDBACK)

30

Wurden Prototypen (aus Phase 2.2) durch echte Endnutzer getestet?

Usability: Ein Prototyp ohne Nutzertest ist nur eine hübsche Meinung. Validierung erfordert echtes Feedback.

31

Haben Nutzer die Aufgaben im Prototyp ohne Hilfe lösen können?

Erfolgsquote: Wenn Nutzer scheitern, ist die Anforderung/das Design falsch. Nicht den Nutzer schulen, sondern das System ändern.

32

Wurde ein standardisierter Usability-Score (z.B. SUS) erhoben?

Messbarkeit: "Fühlt sich gut an" reicht nicht. "SUS-Score > 80" ist ein messbares Validierungsergebnis.

33

Wurden die Erkenntnisse aus dem Test in die Spezifikation übernommen?

Feedback-Loop: Aktualisieren Sie die Anforderungen (3.2) basierend auf den Testergebnissen.

34

Bestätigt der Prototyp die technische Machbarkeit?

Proof of Concept: Hat der "technische Durchstich" funktioniert? Wenn nicht, Anforderung anpassen.

E

FORMALE QUALITÄTSPRÜFUNG

35

Wurde die vorgeschriebene Dokumentationsstruktur eingehalten?

Standard: Halten Sie sich an das Template (z.B. Volere). Fehlende Kapitel fallen so auf.

36

Sind die Anforderungen eindeutig identifizierbar (IDs)?

Verwaltung: Jede Anforderung braucht eine stabile ID (REQ-123). Bulletpoints sind nicht referenzierbar.

37

Ist das Dokument versioniert?

Historie: Eindeutige Versionsnummer (1.0, 1.1). Änderungen müssen markiert sein (Change Bars).

38

Sind Grafiken und Tabellen beschriftet?

Lesbarkeit: Jede Abbildung braucht eine Nummer und einen Titel für Referenzen im Text.

39

Wurden die richtigen Satzschablonen verwendet?

Syntax: Prüfen Sie stichprobenartig auf Einhaltung der Satzschablone (SOPHIST/ISO).

40

Sind Rechtschreibung und Grammatik korrekt?

Professionalität: Tippfehler untergraben das Vertrauen in die technische Sorgfalt.

F

ABSCHLUSS & FREIGABE

41

Wurde das Feedback der Stakeholder eingearbeitet?

Loop: Prüfen Sie: Wurden alle Kommentare beantwortet (Akzeptiert/Abgelehnt)?

42

Gibt es ein formales "Sign-Off" (Unterschrift)?

Meilenstein: Digitale Signatur oder E-Mail-Bestätigung. Das ist der Vertrag für die Umsetzung.

43

Wurde das Dokument formal freigegeben (Baseline)?

CM: Setzen Sie den Status auf "Released" und ziehen Sie eine Baseline im Tool.

44

Sind die Ergebnisse archiviert?

Audit-Trail: Speichern Sie das Review-Protokoll revisionssicher ab.

45

Wurde der Validierungsprozess selbst verbessert?

Retro: War das Review effizient? Wenn nicht → Checkliste anpassen.

Konfliktmanagement (Die Einigung)
In der Prüfung treten oft Widersprüche zutage (z. B. Marketing will Feature A, Vertrieb will Feature B). In diesem Schritt analysieren wir die Konfliktart (Sachkonflikt, Interessenkonflikt, Wertekonflikt) und wenden Lösungstechniken an (Verhandlung, Kompromiss, Machtwort), um eine konsolidierte Basis zu schaffen.

Details

4.2 Konfliktmanagement (Operative Audit-Checkliste)

diagram-4-2-mindmap

A – Technik & Fachlichkeit Dieser Abschnitt analysiert sachliche Widersprüche: Technische Unmöglichkeiten („Offline“ vs. „Cloud“), Gesetzeskonflikte oder Budgetprobleme. Er fordert objektive Messungen und Proof-of-Concepts, um Meinungsstreits durch Fakten zu beenden. Mehrwert: Verhindert unlösbare technische Anforderungen und klärt frühzeitig, ob Wünsche realisierbar und finanzierbar sind.

B – Interessen & Ziele Hier werden die versteckten Motive der Stakeholder beleuchtet. Gibt es politische Machtkämpfe, Silo-Denken (Abteilung vs. Unternehmen) oder persönliche Karriereziele („Hidden Agenda“)? Auch der Konflikt zwischen kurzfristigem Gewinn und langfristiger Stabilität („Tech Debt“) wird thematisiert. Mehrwert: Macht die wahren Treiber hinter Forderungen sichtbar und ermöglicht so strategisches Stakeholder-Management statt reiner Symptombekämpfung.

C – Soziales & Kommunikation Dieser Bereich prüft zwischenmenschliche Konflikte: Missverständnisse durch unklare Begriffe, emotionale Verletzungen („Wurde nicht gefragt“) oder Antipathie. Er fordert Transparenz und klärende Gespräche, um die Beziehungsebene zu heilen. Mehrwert: Entschärft "menschliche Blockaden", die oft als sachliche Kritik getarnt sind, und stellt die Arbeitsfähigkeit des Teams wieder her.

D – Analyse & Methoden Es werden analytische Werkzeuge wie Entscheidungsmatrizen, PMI (Plus-Minus-Interessant) oder die „5-Why“-Methode eingesetzt. Ziel ist es, Emotionen herauszunehmen und Entscheidungen auf Basis von gewichteten Kriterien zu treffen. Mehrwert: Objektiviert die Diskussion und führt zu nachvollziehbaren, rationalen Entscheidungen statt Bauchentscheidungen.

E – Verhandlung & Entscheidung Hier geht es um den Prozess der Einigung: Konsens, Kompromiss oder Machtwort? Es werden Deadlines gesetzt und Entscheidungsbefugnisse (Wer darf entscheiden?) geklärt, um Stillstand („Analysis Paralysis“) zu vermeiden. Mehrwert: Erzwingt Fortschritt durch klare Entscheidungswege und verhindert, dass Projekte durch endlose Diskussionen blockiert werden.

F – Technik & Prozess Dieser Abschnitt sucht nach kreativen Auswegen: Können beide Seiten durch Konfigurierbarkeit („Varianten“) zufrieden gestellt werden? Hilft eine zeitliche Entzerrung über die Roadmap oder die Trennung von Systemen? Mehrwert: Ermöglicht oft "Win-Win"-Situationen durch technische Innovation oder kluge Planung, wo vorher nur "Entweder-Oder" gesehen wurde.

G – Eskalation & Externe: Hilfe Wenn das Team feststeckt, regelt dieser Bereich den Zuzug von Außenstehenden: Externe Gutachter für Fachfragen, Mediatoren für Teamkonflikte oder das Eskalieren an ein Steering Committee. Mehrwert: Löst verfahrene Situationen (Patt), die das Projektteam aus eigener Kraft nicht mehr bewältigen kann.

H – Dokumentation & Abschlus: Die getroffene Entscheidung wird im "Decision Log" festgehalten und formal abgenommen. Retrospektiven sorgen dafür, dass aus dem Konflikt gelernt wird. Mehrwert: Verhindert das Wiederaufleben alter Diskussionen ("Zombie-Konflikte") und sichert die Verbindlichkeit der Lösung für die weitere Projektarbeit.

Nr. Frage Operative Implikation & Handlungsanweisung

A

ECHNIK & FACHLICHKEIT

1

Gibt es Anforderungen, die sich technisch widersprechen?

Machbarkeit: Prüfen Sie Paare: "100% Offline" vs. "Live-Daten aus Cloud". Technisch unmöglich. Klären Sie das VOR der Entwicklung.

2

Widersprechen die Anforderungen den gesetzlichen Vorgaben?

Compliance: Business-Wunsch ("Daten nie löschen") vs. DSGVO ("Recht auf Vergessen"). Gesetz schlägt Wunsch. Dokumentieren Sie das Veto.

3

Stehen die Anforderungen im Konflikt mit dem Budget?

Realität: "Champagner-Wünsche bei Bier-Budget". Erstellen Sie eine Streichliste (De-Scoping) mit dem Sponsor.

4

Gibt es Widersprüche zwischen funktionalen und qualitativen Anforderungen?

Trade-off: "Maximale Sicherheit" (3 Passwörter) vs. "Hohe Usability" (1 Klick). Entscheiden Sie die Balance bewusst.

5

Beruht der Konflikt auf fehlenden Informationen (Sachkonflikt)?

Fakten: Streit über Performance ("Zu langsam")? Messen Sie! Objektive Daten beenden Meinungsstreits.

6

Liegt ein Datenkonflikt vor (unterschiedliche Interpretation)?

Semantik: Streit über "Umsatz" (Brutto/Netto?) oder Datumsformate. Glossar und Datenmodell klären das.

7

Werden unterschiedliche Maßeinheiten verwendet?

Fehlerquelle: Zoll vs. cm? Klären Sie Einheiten in Schnittstellenverträgen.

8

Ist die technische Machbarkeit objektiv geklärt?

Proof: Entwickler A sagt "geht nicht", B sagt "geht". Lassen Sie einen PoC (Proof of Concept) bauen.

9

Herrscht Uneinigkeit über die Granularität der Daten?

Detail: Management will Monatszahlen, Fachabteilung will Tageszahlen. Definieren Sie Aggregationsregeln.

10

Ist die Datenherkunft (Source of Truth) strittig?

Architektur: Welches System ist Master für "Kunde"? SAP oder CRM? Definieren Sie den "Leading System"-Status.

B

INTERESSEN & ZIELE

11

Haben verschiedene Stakeholder gegensätzliche Ziele für das System?

Interessen: Marketing (Daten sammeln) vs. Betriebsrat (Mitarbeiter schützen). Visualisieren Sie den Zielkonflikt im Zielbaum.

12

Haben wir einen Interessenkonflikt (subjektive Ziele)?

Motivation: Wer gewinnt, wer verliert durch das System? (Automatisierung kostet Jobs). Planen Sie Change Management.

13

Stehen Abteilungsziele gegen Unternehmensziele?

Silo: Logistik will Lager minimieren (Kosten), Vertrieb will maximieren (Lieferfähigkeit). Eskalation an GF.

14

Will jemand das Projekt nutzen, um Karriere zu machen?

Hidden Agenda: Seien Sie wachsam bei "Prestige-Features" ohne Business Value. Hinterfragen Sie den Nutzen vertraulich.

15

Profitieren Stakeholder unterschiedlich vom Erfolg?

Incentive: Wenn der Vertrieb Provision für das Tool kriegt, der Innendienst aber nur Mehrarbeit hat, droht Sabotage.

16

Geht es um Standardisierung vs. Individualisierung?

Strategie: IT will Standard (billig), Fachbereich will Spezial (passgenau). TCO-Rechnung als Entscheidungshilfe.

17

Steht kurzfristiger Gewinn gegen langfristige Stabilität?

Tech Debt: "Schnell releasen" vs. "Sauber bauen". Dokumentieren Sie die technischen Schulden als bewusste Entscheidung.

18

Wollen Stakeholder den Status Quo bewahren?

Angst: Widerstand gegen Veränderung ist normal. Binden Sie diese Stakeholder früh ein (Key User).

C

SOZIALES & KOMMUNIKATION

19

Gibt es Unklarheiten über die Bedeutung bestimmter Begriffe?

Wording: "Kunde" vs. "Nutzer". Klären Sie das Vokabular im Glossar, bevor Sie über Inhalte streiten.

20

Fühlen sich Stakeholder bei der Anforderungsermittlung übergangen?

Emotion: Binden Sie Kritiker aktiv ein. Oft geht es um Wertschätzung ("Mich hat keiner gefragt"), nicht um Inhalte.

21

Gibt es versteckte Konflikte, die niemand offen anspricht?

Kultur: Achten Sie auf Schweigen im Meeting. Das ist oft Ablehnung. Sprechen Sie es im 4-Augen-Gespräch an.

22

Ist es ein Beziehungskonflikt (persönliche Abneigung)?

Chemie: Trennen Sie Streithähne räumlich oder thematisch. Sachliche Mediation versuchen.

23

Liegt ein struktureller Konflikt vor (Hierarchie/Macht)?

Macht: Abteilung A gönnt Abteilung B das Budget nicht. Hier muss die Geschäftsführung ein Machtwort sprechen.

24

Fehlen einer Partei schlichtweg Informationen?

Wissen: Bringen Sie alle auf den gleichen Stand ("Level Playing Field"). Transparenz entschärft Konflikte.

25

Ist die Ursache eine Falschinformation (Fake News / Gerücht)?

Gerüchte: "Ich habe gehört, das Budget wird gestrichen." Stellen Sie Fakten offiziell klar.

26

Wird Kritik an der Sache als Kritik an der Person genommen?

Identifikation: Trennen Sie Idee von Person. "Die Idee funktioniert nicht" statt "Du hast Unrecht".

27

Gibt es Neid oder Konkurrenzdenken?

Rivalität: Zwei Abteilungsleiter kämpfen um denselben Posten. Klären Sie Rollen und Zuständigkeiten im Projekt.

28

Wird passiv-aggressiv kommuniziert?

Sabotage: "Ja ja, machen wir" (und nichts passiert). Setzen Sie harte Deadlines und kontrollieren Sie Ergebnisse.

D

ANALYSE & METHODEN

29

Haben wir alle Fakten berücksichtigt ("Consider all Facts")?

Methode: Nutzen Sie die CAF-Methode, um Emotionen rauszunehmen und alle Aspekte zu listen.

30

Was sind die positiven, negativen und interessanten Aspekte ("PMI")?

Bewertung: Erstellen Sie eine PMI-Tabelle für beide Optionen. Zwingt zur Objektivität.

31

Welche Kriterien sind für die Entscheidung ausschlaggebend?

Kriterien: Definieren Sie Bewertungskriterien (Kosten, Zeit, Qualität) VOR der Diskussion über Lösungen.

32

Wie gewichten wir die Entscheidungskriterien?

Mathe: Nutzen Sie eine Entscheidungsmatrix (Weighted Scoring). Faktenbasierte Entscheidung.

33

Sollten wir eine Entscheidungsmatrix nutzen?

Tool: Visualisieren Sie das Ergebnis. "Option A hat 80 Punkte, Option B nur 50".

34

Sollten wir die "5-Why"-Methode anwenden?

Ursache: Bohren Sie nach: "Warum willst du das?" → "Weil X" → "Warum X?". Finden Sie das echte Bedürfnis.

35

Hilft eine Visualisierung des Konflikts (z.B. am Whiteboard)?

Transparenz: Zeichnen Sie das Problem auf. Oft reden Leute aneinander vorbei, weil sie unterschiedliche Bilder im Kopf haben.

36

Wäre ein Perspektivenwechsel (Rollenspiel) hilfreich?

Empathie: Lassen Sie den Entwickler aus Kundensicht argumentieren. Fördert Verständnis.

37

Können wir den Konflikt durch Daten widerlegen?

Empirie: Nutzerstudie beweist, dass niemand Feature A will → Streit beendet. Data beats Opinion.

E

VERHANDLUNG & ENTSCHEIDUNG

38

Können wir den Konflikt durch eine Einigung (Konsens) lösen?

Ideal: Diskussion bis zur Einigung. Zeitintensiv, aber nachhaltig.

39

Müssen wir einen Kompromiss schließen?

Realität: Jeder gibt etwas nach. Dokumentieren Sie den "Deal" schriftlich.

40

Sollten wir über die Lösung abstimmen?

Demokratie: Voting bei Gleichstand. Schnell, aber Verlierer sind oft frustriert.

41

Muss eine übergeordnete Instanz entscheiden ("Ober-sticht-Unter")?

Eskalation: Wenn Teams blockieren, entscheidet der Chef. Nutzen Sie dies als Ultima Ratio.

42

Wer hat das Mandat, diese Entscheidung zu treffen?

Governance: Klären Sie Decision Rights (RACI). Wer ist der "Decider"?

43

Bis wann muss die Entscheidung gefallen sein?

Timebox: Setzen Sie ein Ultimatum. "Analysis Paralysis" vermeiden. Entscheidung erzwingen.

44

Was passiert, wenn wir uns nicht entscheiden können?

Fallback: Definieren Sie den "Default" (meist: Status Quo oder Projektabbruch).

45

Gibt es ein "Best Alternative to a Negotiated Agreement" (BATNA)?

Verhandlung: Was ist der Plan B? Wissen Sie, wann Sie den Verhandlungstisch verlassen müssen.

46

Ist eine "Win-Win"-Lösung theoretisch möglich?

Potenzial: Suchen Sie kreativ nach Lösungen, die beide Ziele erfüllen (oft durch Technik/Innovation).

47

Müssen wir eine Seite "auszahlen" (Log-rolling)?

Deal: "Du kriegst Feature A, dafür verzichtest du auf B." Tauschhandel.

F

TECHNIK & PROZESS

48

Können wir Varianten bilden, um beide Seiten zufrieden zu stellen?

Technik: Konfigurierbarkeit ("Experten-Modus" vs "Einfach-Modus") löst oft UX-Konflikte.

49

Ist eine Trennung der Systeme möglich?

Architektur: Entkopplung. Marketing bekommt Tool A, Vertrieb Tool B, Schnittstelle verbindet.

50

Hilft eine zeitliche Entzerrung?

Roadmap: Phasenplan. Feature A kommt in Q1, Feature B in Q2. Beides wird gemacht, nur nicht gleichzeitig.

51

Können wir den Konflikt ignorieren (aussitzen)?

Strategie: Wenn das Altsystem in 3 Monaten eh abgeschaltet wird, lohnt der Streit um dessen Anpassung nicht.

52

Ist das Problem durch mehr Ressourcen lösbar?

Geld: Wenn der Streit nur wegen Ressourcenmangel existiert → Budget erhöhen (wenn ROI positiv).

53

Können wir den Standard ändern?

Normen: Wenn die Richtlinie stört → Richtlinie anpassen (Change Request an QM).

54

Können wir den Konflikt durch einen Prototypen (Test) entscheiden?

Test: A/B-Test. Bauen Sie beide Varianten als Mockup und lassen Sie die User entscheiden.

G

ESKALATION & EXTERNE HILFE

55

Müssen wir externe Experten/Gutachter hinzuziehen?

Neutralität: Streit über Sicherheitsarchitektur → Externer Security-Auditor entscheidet objektiv.

56

Brauchen wir eine Mediation?

HR: Bei tiefen persönlichen Konflikten hilft nur ein Profi-Mediator oder Coach.

57

Ist ein Machtwort nötig?

Ultima Ratio: Der Sponsor droht mit Projektabbruch, wenn keine Einigung erfolgt. Schafft Bewegung.

58

Fehlt eine Eskalationsinstanz?

Patt: Wenn Teams streiten und niemand darüber steht → Steering Committee einrichten.

H

DOKUMENTATION & ABSCHLUSS

59

Wie dokumentieren wir den gelösten Konflikt?

Decision Log: Führen Sie ein Logbuch der Entscheidungen. Verhindert, dass alte Diskussionen wieder hochkochen ("Zombie-Konflikte").

60

Müssen wir die Konfliktlösung von den Stakeholdern unterschreiben lassen?

Verbindlichkeit: Formale Abnahme des Kompromisses im Lastenheft oder Protokoll.

61

Haben wir aus dem Konflikt gelernt (Lessons Learned)?

Prävention: Retrospektive. Wie verhindern wir, dass wir in 6 Monaten wieder über dasselbe streiten?

Entscheidungsfindung & Priorisierung (Die Auswahl)
Nicht alles kann sofort umgesetzt werden. Hier bewerten wir die Anforderungen nach Business Value, Risiko und Aufwand. Wir nutzen Methoden wie MoSCoW oder WSJF (Weighted Shortest Job First), um eine verbindliche Umsetzungsreihenfolge festzulegen und die Abnahme (Sign-off) durch die Stakeholder einzuholen.

Details

4.3 Entscheidungsfindung & Priorisierung (Operative Audit-Checkliste)

diagram-4-3-mindmap

A – Strategie & Ziele: Dieser Abschnitt verankert die Priorisierung in der übergeordneten Geschäftsstrategie. Es wird geprüft, ob Features auf langfristige Ziele (z. B. "Cloud First") einzahlen oder kurzfristigen Umsatz bringen, und ob Speed oder Quality Vorrang hat. Auch Opportunitätskosten ("Cost of Delay") werden betrachtet. Mehrwert: Verhindert, dass das Team an Features arbeitet, die zwar "dringend" wirken, aber strategisch wertlos sind ("Busy Work"), und richtet die Entwicklung am Business Value aus.

B – MoSCoW & Kano (Klassifizierung): Hier werden Anforderungen methodisch sortiert: Nach "Must/Should/Won’t" (MoSCoW) zur Steuerung des Release-Scopes und nach dem Kano-Modell (Basis-, Leistungs-, Begeisterungsfaktoren). Wichtig ist eine Obergrenze für "Must"-Anforderungen. Mehrwert: Schützt das Release vor Überfrachtung, schafft klare Erwartungen ("Won’t have") und sichert einen gesunden Mix aus stabilen Basisfunktionen und spannenden Delightern.

C – Risiko & Dringlichkeit: Dieser Bereich priorisiert nach Schadenspotenzial (z. B. DSGVO-Strafen) und fixen Deadlines (z. B. Messetermine). Unsichere oder riskante Anforderungen werden oft vorgezogen ("Risk-First"), um früh zu scheitern ("Fail Fast") statt am Ende überrascht zu werden. Mehrwert: Minimiert das Projektrisiko, indem "böse Überraschungen" und kritische Pfade zuerst bearbeitet werden, statt sie aufzuschieben.

D – Aufwand & Effizienz (ROI): Es werden Kosten und Nutzen ins Verhältnis gesetzt. Methoden wie "Quick Wins" (viel Nutzen, wenig Aufwand) oder WSJF (Weighted Shortest Job First) helfen, den Durchsatz an Business Value zu maximieren. Wiederverwendbare Komponenten werden höher bewertet. Mehrwert: Maximiert den wirtschaftlichen Ertrag (ROI) des Entwicklungsbudgets und verhindert Ressourcenverschwendung in "Money Pits".

E – Stakeholder & Macht: Hier geht es um den Einfluss der Beteiligten: Kunden-Vetos, "HiPPO"-Entscheidungen (Highest Paid Person’s Opinion) und die Berücksichtigung wichtiger Kundensegmente (A-Kunden). Leise Stimmen werden durch Methoden wie anonymes Voting geschützt. Mehrwert: Sorgt für politische Stabilität und Akzeptanz der Priorisierung, indem Machtstrukturen transparent gemacht und fair gemanagt werden.

F – Methoden & Workshops: Dieser Abschnitt stellt konkrete Werkzeuge vor: "Buy a Feature" (Budget-Spiel), Paarweiser Vergleich, Dot Voting oder Entscheidungsmatrizen. Diese Methoden objektivieren Diskussionen und zwingen zu echten Trade-offs. Mehrwert: Macht Entscheidungsprozesse in Workshops effizient, demokratisch und nachvollziehbar, statt stundenlanger, ergebnisloser Debatten.

G – Technik & Abhängigkeiten: Technische Realitäten diktieren oft die Reihenfolge: Fundament vor Dach. Auch "Technical Debt" (Refactoring) muss eingeplant werden, um das System langfristig am Leben zu halten. Prototypen für Feedback haben Vorrang. Mehrwert: Verhindert unrealistische Pläne, die an technischen Blockaden scheitern, und sichert die langfristige Wartbarkeit der Software.

H – Prozess & Transparenz: Priorisierung ist kein einmaliges Event. Hier wird festgelegt, wie oft repriorisiert wird (z. B. jeden Sprint), wie Entscheidungen visualisiert werden (Backlog) und wer bei Gleichstand entscheidet ("Tie-Breaker"). Mehrwert: Schafft Vertrauen durch Transparenz und ermöglicht agile Reaktionen auf Marktveränderungen, ohne Chaos zu verursachen.

I – Sonstiges Abschließend: werden Themen wie Gruppierung (Epics vor Stories), Marketing-Features ("Showware" für Messen) und Zertifizierungs-Voraussetzungen behandelt. Goldplating wird aktiv verhindert. Mehrwert: Deckt spezielle Randbedingungen ab, die oft vergessen werden, aber für den Markterfolg (z. B. Zertifizierung) essenziell sind.

Nr. Frage Operative Implikation & Handlungsanweisung

A

STRATEGIE & ZIELE

1

Was ist das Hauptziel der Priorisierung?

Fokus: Time-to-Market (Speed) oder Stabilität (Quality)? Wenn das Ziel unklar ist, werden Äpfel mit Birnen verglichen.

2

Welche Anforderung bringt den höchsten Geschäftswert (Business Value)?

Value: Nutzen Sie "Business Value Poker". Jedes Feature muss einen Punktwert (z.B. Umsatz in €) haben.

3

Wie wichtig ist die Anforderung für die strategische Roadmap?

Vision: Zahlt das Feature auf das 3-Jahres-Ziel ein (z.B. "Cloud First")? Strategische Fit > kurzfristiger Umsatz.

4

Berücksichtigen wir Opportunitätskosten?

Verlust: Was entgeht uns, wenn wir X nicht machen? Berechnen Sie den "Cost of Delay".

5

Priorisieren wir Risikominimierung oder Chancennutzung höher?

Leitlinie: In Krisenzeiten: Risiko > Chance. In Wachstumsphasen: Chance > Risiko. Definieren Sie den Modus.

B

MoSCoW & KANO (KLASSIFIZIERUNG)

6

Welche Anforderungen sind "Must-haves" (unverzichtbar)?

Limitierung: Maximal 60% des Backlogs dürfen "Must" sein. Alles "Must" = Nichts "Must".

7

Welche Anforderungen sind "Should-haves" (wichtig, aber nicht kritisch)?

Puffer: Diese Features sind die Verhandlungsmasse, wenn der Zeitplan wackelt.

8

Welche Anforderungen sind "Won’t-haves" (diesmal nicht)?

Scope-Management: Explizites "Nicht im Release 1" verhindert falsche Erwartungen bei Stakeholdern.

9

Welche Anforderungen sind Basisfaktoren im Kano-Modell?

Hygiene: Diese MÜSSEN rein, sonst ist das Produkt unverkäuflich. Prio 1, aber kein Marketing-Wert.

10

Welche Anforderungen sind Begeisterungsfaktoren?

USP: Mindestens ein "Delighter" muss ins Release, um sich vom Wettbewerb abzuheben.

11

Nutzen wir das "Kano-Board" zur Visualisierung?

Visualisierung: Ordnen Sie Features visuell an (Basis vs. Begeisterung). Hilft bei der Diskussion und Balance des Releases.

C

RISIKO & DRINGLICHKEIT

12

Welche Anforderung verursacht den höchsten Schaden bei Nicht-Umsetzung?

Risiko: Strafzahlungen (DSGVO, Steuer) schlagen Umsatzchancen. Diese "Musts" blockieren das Release.

13

Welche Anforderung ist am dringendsten (Urgency)?

Zeit: Fixtermine (Messe, Gesetz) diktieren die Prio. Nutzen Sie das "Cost of Delay" Profil.

14

Welche Risiken reduzieren wir mit dieser Anforderung?

Risk-First: Bauen Sie die unsichersten Teile (z.B. neue Schnittstelle) zuerst (Fail Fast).

15

Wie sicher sind wir uns über die Anforderung?

Volatilität: Unsichere Anforderungen nach hinten schieben, bis sie geklärt sind. Keine Entwicklung auf Vermutungen.

16

Gibt es Strafzahlungen bei Nichteinhaltung bestimmter Anforderungen?

Legal: Pönalen machen eine Anforderung sofort zu "Must". Quantifizieren Sie das Risiko (€).

D

AUFWAND & EFFIZIENZ (ROI)

17

Wie hoch ist der Realisierungsaufwand pro Anforderung?

Kosten: Nutzen Sie "Planning Poker" oder "T-Shirt Sizes". Ohne Kosten keine ROI-Berechnung.

18

Welches Verhältnis von Kosten zu Nutzen hat die Anforderung?

ROI: "Quick Wins" (Viel Nutzen, wenig Aufwand) zuerst machen. "Money Pits" (Wenig Nutzen, viel Aufwand) streichen.

19

Priorisieren wir nach "Weighted Shortest Job First" (WSJF)?

SAFe: (Cost of Delay / Duration). Mathematisch bestes Verfahren für maximalen Durchsatz.

20

Welche Anforderung hat den höchsten Wiederverwendungswert?

Synergie: Ein Modul für 5 Apps ist wertvoller als eine Einzellösung. Architektur-Value beachten.

E

STAKEHOLDER & MACHT

21

Welche Stakeholder müssen bei der Priorisierung dabei sein?

Partizipation: Ohne Key-User und Sponsor ist die Prio wertlos. Entscheider müssen am Tisch sitzen.

22

Hat der Kunde ein Veto-Recht bei der Priorisierung?

Macht: Klären Sie vertraglich, wer "den Stecker ziehen" kann.

23

Wie gehen wir mit "Chefsachen" um (HiPPO)?

Diplomatie: Machen Sie die Kosten der Chef-Wünsche transparent ("Wenn wir das machen, fliegt X raus").

24

Priorisieren wir nach Kundensegmenten?

Value: A-Kunden vor C-Kunden. Nicht alle Nutzerstimmen sind gleich viel wert.

25

Wie stellen wir sicher, dass "leise" Stakeholder gehört werden?

Inklusion: Nutzen Sie anonyme Voting-Methoden (Dot Voting), um laute Stimmen zu neutralisieren.

F

METHODEN & WORKSHOPS

26

Wie würden Sie 100 Punkte (oder Dollar) auf die Features verteilen?

Budget: "Buy a Feature". Zwingt Stakeholder zu echten Trade-offs bei begrenzten Ressourcen.

27

Welche Anforderung gewinnt im direkten Vergleich (Paarweiser Vergleich)?

Ranking: A vs B. Gut für Top-10 Listen, wenn alles "wichtig" erscheint.

28

Welche Top-10-Anforderungen müssen unbedingt rein?

Fokus: Harte Limitierung der WIP (Work in Progress). Nur 10 Zettel an der Wand.

29

Nutzen wir das "Wiegen"-Verfahren (Weighting)?

Matrix: Gewichtete Tabelle (Wert x 2, Risiko x 1). Objektiviert die Diskussion.

30

Nutzen wir "Bubble Sort" zur Priorisierung?

Methode: Manuelles Sortieren im Meeting für Konsens. Schnell und pragmatisch.

31

Nutzen wir "Dot Voting" (Klebepunkte) im Workshop?

Visualisierung: Heatmap der Interessen. Schnell, aber anfällig für Gruppenbias.

G

TECHNIK & ABHÄNGIGKEITEN

32

Gibt es technische Abhängigkeiten, die die Reihenfolge diktieren?

Logik: Man kann das Dach nicht vor dem Fundament bauen. Tech-Stack diktiert oft die Prio.

33

Wie gehen wir mit Abhängigkeiten bei der Prio um?

Kette: Prio der abhängigen Story kann nicht höher sein als die der Voraussetzung.

34

Wie bewerten wir "Technical Debt" (Technische Schulden)?

Hygiene: Reservieren Sie 20% Kapazität für Refactoring. Sonst stirbt das System an Altersschwäche.

35

Was generiert am schnellsten Feedback?

Lernen: Prototypen vorziehen, um Hypothesen zu testen. Validiertes Lernen ist ein Wert.

36

Gibt es saisonale Abhängigkeiten?

Timing: Weihnachts-Feature im Januar ist wertlos. Hard Deadlines beachten.

H

PROZESS & TRANSPARENZ

37

Wie oft priorisieren wir neu?

Agilität: Vor jedem Sprint/Release neu bewerten. Ein Backlog ist lebendig, nicht statisch.

38

Wie visualisieren wir die Priorität für alle?

Transparenz: Nutzen Sie ein priorisiertes Backlog (oben = wichtig) oder Kanban-Board.

39

Wie gehen wir mit Änderungen der Priorität im laufenden Sprint um?

Stabilität: Laufender Sprint ist tabu (außer bei Prio-1-Bugs). Änderungen kommen in den nächsten.

40

Wie dokumentieren wir die Gründe für eine niedrige Priorität?

Nachvollziehbarkeit: Kommentar im Ticket: "Verschoben, weil techn. Abhängigkeit zu X noch nicht gelöst."

41

Gibt es einen "Tie-Breaker" (Entscheider bei Gleichstand)?

Patt: Wenn Abstimmung 50:50 ist, entscheidet der Product Owner final.

42

Prüfen wir regelmäßig, ob die Prio noch stimmt?

Review: In jedem Review-Meeting wird geprüft, ob die Top-Prio-Items noch die richtigen sind.

I

SONSTIGES

43

Sollten wir Anforderungen gruppieren, um sie zu priorisieren?

Cluster: Priorisieren Sie erst Themen (Epics), dann Details (Stories). Verhindert Mikromanagement.

44

Gibt es Anforderungen, die aus Marketing-Sicht wichtig sind?

Show: Features für die Messe-Demo einplanen, auch wenn sie funktional klein sind.

45

Wie gehen wir mit "Goldplating" um (unnötige Extras)?

Disziplin: Entwickler-Spielwiesen konsequent depriorisieren.

46

Ist die Anforderung eine Voraussetzung für die Zertifizierung?

Audit: Ohne Audit kein Marktstart → Prio 1 (Blocker).

Phase 5: Management & Lebenszyklus

Anforderungen sind lebendig. Sie ändern sich, entwickeln sich weiter und müssen über Jahre hinweg verwaltet werden. Diese Phase begleitet das Projekt bis zum Ende.

Strukturierung & Verwaltung (Das Ordnungssystem)
Um bei hunderten oder tausenden Anforderungen den Überblick zu behalten, nutzen wir Attribute (Status, Priorität, Autor, Risiko). Wir richten Sichten (Views) ein, damit Manager nur den Statusbericht sehen, Entwickler aber die technischen Details. Das Requirements-Management-Tool wird hier aktiv gepflegt.

Details

5.1 Strukturierung & Verwaltung von Anforderungen (Operative Audit-Checkliste)

diagram-5-1-mindmap

A – Grundlegende Identifikation (Basis-Attribute): Dieser Abschnitt fordert eine eindeutige, unveränderliche ID (z. B. REQ-101) und einen sprechenden Kurznamen für jede Anforderung. Zudem werden Metadaten wie Autor, Erstellungsdatum und Quelle („Source“) erfasst. Mehrwert: Ermöglicht die eindeutige Referenzierung in Kommunikation und Tests und verhindert Verwirrung bei Textänderungen oder Umbenennungen.

B – Lebenszyklus & Status: Hier wird der Workflow definiert: Welche Status darf eine Anforderung haben (Neu, Review, Abgenommen, Fertig)? Wichtig ist die Unterscheidung zwischen „Inhaltlich fertig“ (Entwurf vs. Final) und „Technisch fertig“ (Done). Mehrwert: Schafft Transparenz über den Fortschritt und verhindert, dass unfertige Anforderungen („Entwürfe“) versehentlich implementiert werden.

C – Priorisierung & Bewertung: Es werden Attribute für den Geschäftswert (Business Value), das Risiko, die Volatilität (Stabilität) und den Aufwand (Schätzung) gefordert. Auch die technische Umsetzungsreihenfolge wird hier festgelegt. Mehrwert: Ermöglicht eine datenbasierte Sortierung des Backlogs, sodass das Team immer an den wertvollsten und risikoärmsten Aufgaben arbeitet.

D – Inhaltliche Attribute: Neben dem Text werden hier Zusatzinfos verwaltet: Die Begründung („Rationale“), Akzeptanzkriterien für Tests, Anhänge (Mockups) und explizite „Nicht-Ziele“ (Out of Scope). Mehrwert: Trennt Problem (Anforderung) von Lösung (Mockup/Idee) und sichert ab, dass Entwickler und Tester alle Kontextinformationen an einem Ort finden.

E – Compliance & Recht: Dieser Bereich markiert Anforderungen, die rechtlich zwingend sind (DSGVO, Legal, Barrierefreiheit). Auch Sicherheitsstufen (Geheim vs. Öffentlich) werden attributiert. Mehrwert: Verhindert, dass gesetzliche Muss-Kriterien im Eifer des Gefechts depriorisiert oder vergessen werden, was zu Bußgeldern führen könnte.

F – Technik & Zuordnung: Hier wird die Zuständigkeit geklärt: Welches Team (Backend/Frontend) liefert? Gibt es Hardware-Abhängigkeiten oder technische Schulden, die später gefixt werden müssen? Mehrwert: Erleichtert die Ressourcenplanung und das Release-Management, indem Abhängigkeiten und Zuständigkeiten klar zugeordnet sind.

G – Handoff & Refinement (Schnittstelle Entwicklung): Es wird sichergestellt, dass die Übergabe an die Entwicklung sauber läuft. Flags wie „Ready for Dev“ oder „Blocked“ steuern den Fluss in den Sprint. Mehrwert: Verhindert, dass Entwickler mit unklaren Aufgaben starten, was Rückfragen und Verzögerungen im Sprint minimiert.

H – Ansichten & Filter (Views): Dieser Abschnitt beschreibt die verschiedenen „Brillen“, durch die man auf die Daten schaut: Management-Dashboards, Entwickler-Listen, Roadmap-Sichten oder Risiko-Filter. Mehrwert: Reduziert die Komplexität, indem jeder Rolle nur die für sie relevanten Informationen angezeigt werden, ohne die Datenbasis zu duplizieren.

I – Suche & Navigation: Hier geht es um die Usability des Verwaltungstools: Volltextsuche, persönliche To-Do-Listen („Meine Aufgaben“) und Traceability-Matrizen zur Lückenanalyse. Mehrwert: Erhöht die Effizienz im Alltag massiv, da Informationen schnell gefunden werden und nichts im „Datengrab“ verloren geht.

J – Tool-Konfiguration & Regeln: Abschließend werden die Regeln für das Tool definiert: Pflichtfelder, Schreibrechte (Wer darf Prio ändern?), Audit-Trails und Farbcodes für bessere Lesbarkeit. Mehrwert: Sichert die Datenqualität im Tool und verhindert Wildwuchs oder Manipulationen durch unberechtigte Änderungen.

Nr. Frage Operative Implikation & Handlungsanweisung

A

GRUNDLEGENDE IDENTIFIKATION (BASIS-ATTRIBUTE)

1

Besitzt jede Anforderung eine eindeutige ID?

Referenz: Die ID (REQ-101) darf sich NIEMALS ändern, auch nicht wenn der Text umgeschrieben wird. Keine "sprechenden" IDs, die ihren Sinn verlieren können.

2

Ist die ID sprechend oder eine reine Zahl?

Lesbarkeit: "SYS-REQ-001" hilft bei der Einordnung (System vs. User Story "US-001"). Definieren Sie Präfixe.

3

Gibt es einen Kurznamen (Titel) für die Anforderung?

Übersicht: Eine Überschrift ("Login Maske") ist Pflicht für Listenansichten. Niemand liest 50 Langtexte im Inhaltsverzeichnis.

4

Wer ist der Autor der Anforderung?

Rückfrage: Automatisch loggen. Nicht verwechseln mit dem "Owner" (Entscheider).

5

Wann wurde die Anforderung erstellt?

Alter: Alte, offene Anforderungen ("Zombies") müssen identifiziert und ggf. gelöscht werden.

6

Aus welcher Quelle stammt die Anforderung?

Herkunft: "Protokoll vom 12.05." oder "Norm ISO 9001". Wichtig, wenn man wissen will, ob man die Anforderung löschen darf.

7

Wer ist der fachlich Verantwortliche (Owner)?

Entscheidung: Der Owner entscheidet über Änderungen. Ohne Owner keine Änderung.

B

LEBENSZYKLUS & STATUS

8

Welchen aktuellen Status hat die Anforderung?

Workflow: Definieren Sie erlaubte Statusübergänge (Neu → Review → Abgenommen). Verhindern Sie "Abgenommen → Neu" ohne Grund.

9

Ist der Status "Abgestimmt" explizit vorhanden?

Baseline: Dieser Status friert den Inhalt ein. Änderungen danach nur über Change Request.

10

Gibt es einen Status für die inhaltliche Reife?

Qualität: "Entwurf" vs. "Final". Entwickler dürfen nur "Finale" Anforderungen umsetzen.

11

In welchem Release soll die Anforderung umgesetzt werden?

Planung: Zuordnung zu Release (z.B. "2.0") oder Iteration ("Sprint 5").

12

Haben wir ein Attribut für „Review-Status“?

QS: "Review offen" / "Review OK". Eine Anforderung darf nicht in Entwicklung gehen, wenn Review nicht OK ist.

13

Gibt es ein Attribut für „Definition of Done erfüllt“?

Abschluss: Checkbox am Ende des Sprints. Verhindert "Fast fertig"-Lügen.

14

Haben wir ein Attribut für „Abnahmedatum“?

Audit: Wann wurde der Status auf "Fertig" gesetzt? Wichtig für Gewährleistungsbeginn.

C

PRIORISIERUNG & BEWERTUNG

15

Welche Priorität hat die Anforderung für den Kunden?

Business Value: MoSCoW (Must/Should) oder Zahlenwert (1-100). Dient der Sortierung des Backlogs.

16

Welche Priorität hat die Umsetzung (Reihenfolge)?

Technik: "Implementation Order". Manchmal muss das Unwichtige (Fundament) zuerst gebaut werden.

17

Wie hoch ist das Risiko der Umsetzung?

Risk: High/Medium/Low. High-Risk-Items zuerst testen (Fail Fast).

18

Wie stabil ist die Anforderung?

Volatilität: Wenn "Instabil", dann nicht schätzen und nicht implementieren. Warten bis stabil.

19

Wie hoch ist der geschätzte Aufwand?

Kosten: Story Points oder Personentage. Pflichtfeld vor dem Sprint-Planning.

20

Haben wir ein Attribut für die „Komplexität“?

Cynefin: Einfach vs. Komplex. Komplexe Items brauchen mehr Puffer.

21

Gibt es ein Attribut für „Markt-Relevanz“?

Strategie: Ist das ein USP oder ein Hygienefaktor? Hilft bei Streich-Diskussionen.

D

INHALTLICHE ATTRIBUTE

22

Gibt es eine Begründung (Rationale) für die Anforderung?

Why: Warum brauchen wir das? "Weil Chef es will" ist keine valide Rationale. "Weil Gesetz X es fordert" schon.

23

Sind Abnahmekriterien direkt am Attribut gepflegt?

Testbarkeit: Gherkin (Given-When-Then) oder Checkliste. Ohne Kriterien keine Abnahme.

24

Werden Anhänge (Bilder, PDFs) als Attribut verwaltet?

Kontext: Screenshots vom Altsystem sind oft besser als 1000 Worte.

25

Gibt es ein Attribut für „Lösungsidee“?

Trennung: Trennen Sie Problem (Beschreibung) von Lösung (Ideen-Feld). Die Lösung kann sich ändern, das Problem bleibt.

26

Haben wir ein Attribut für „Nicht-Ziele“ (Out of Scope)?

Abgrenzung: Explizit reinschreiben: "Drucken gehört NICHT dazu". Verhindert Goldplating.

27

Gibt es ein Attribut für „Mockup-Link“?

Design: Link auf Figma/Sketch. UI-Design ändert sich öfter als der Text.

E

COMPLIANCE & RECHT

28

Ist die Anforderung rechtlich verbindlich?

Legal: Boolean Flag. Diese Anforderungen dürfen niemals aus dem Scope fliegen.

29

Gibt es ein Attribut für „DSGVO-Relevanz“?

Datenschutz: Wenn Ja → Datenschutzbeauftragten ins Review holen.

30

Gibt es ein Attribut für „Sicherheitsstufe“?

Confidentiality: Öffentlich / Intern / Geheim. Bestimmt die Testtiefe.

31

Haben wir ein Attribut für „Barrierefreiheit relevant“?

Accessibility: Muss dieser Screen BITV-konform sein? Ja/Nein.

F

TECHNIK & ZUORDNUNG

32

Gibt es ein Attribut für „Lieferant/Team“?

Zuständigkeit: Welches Team (Backend/Frontend) setzt das um?

33

Haben wir ein Attribut für „Technische Schulden“?

Refactoring: Markieren Sie Hacks. Diese müssen später aufgeräumt werden.

34

Gibt es ein Attribut für „Betriebsauswirkung“?

Ops: Braucht das Feature eine Downtime? Wichtig für Release-Planung.

35

Haben wir ein Attribut für „Hardware-Abhängigkeit“?

Embedded: "Nur für Hardware Revision 2". Wichtig für Testgeräte-Planung.

36

Haben wir ein Attribut für „Testmethode“?

QA: Automatisiert (Unit/E2E) oder Manuell?

G

HANDOFF & REFINEMENT (SCHNITTSTELLE ENTWICKLUNG)

37

Haben Entwickler die Anforderung im Refinement verstanden?

Verständnis-Check: Attribut "Ready for Dev" erst setzen, wenn Entwickler nicken. Schweigen ist keine Zustimmung.

38

Gibt es offene technische Rückfragen?

Blocker: Liste der offenen Fragen direkt an der Anforderung pflegen. Solange Fragen offen sind, darf nicht geschätzt werden.

39

Wurde die technische Machbarkeit bestätigt?

Feasibility: Ein "Architect Approved" Flag verhindert, dass Unmögliches in den Sprint geplant wird.

40

Sind die Akzeptanzkriterien für Entwickler eindeutig?

Klarheit: Fragen Sie: "Wisst ihr genau, wann ihr fertig seid?". Wenn nein → Kriterien schärfen.

41

Gibt es Abhängigkeiten zu anderen Teams, die den Start blockieren?

Dependency: Flag "Blocked by Team X". Diese Items dürfen nicht in den Sprint.

H

ANSICHTEN & FILTER (VIEWS)

42

Brauchen wir eine Sicht für das Management?

Dashboard: Ampeln und Torten. Keine Details. Management will "Status" sehen.

43

Gibt es eine „Entwickler-Sicht“?

Technik: Ausblenden von Marketing-Texten. Fokus auf Akzeptanzkriterien und APIs.

44

Brauchen Tester eine spezielle Sicht?

Test: Fokus auf "Ready for Test" und "Abnahmekriterien".

45

Gibt es eine Sicht für den Kunden/Auftraggeber?

Extern: Nur "Abgenommene" Requirements zeigen. Interne Diskussionen verbergen.

46

Können wir Anforderungen filtern, die noch nicht geschätzt sind?

Planning: Filter "Aufwand IS EMPTY". Das ist die Arbeitsliste für das Refinement.

47

Gibt es eine Sicht für das nächste Release?

Roadmap: Filter "Target Release = 2.0". Das ist der Scope.

48

Wie sehen wir alle Anforderungen mit hohem Risiko?

Risk-Management: Filter "Risk = High". Diese zuerst bearbeiten.

49

Können wir nur die Änderungen seit dem letzten Review sehen?

Effizienz: Diff-View (Was ist neu?). Niemand liest alles zweimal.

50

Gibt es eine Sicht für fehlende Traceability?

Lücken: Filter "Test Case IS EMPTY". Das sind die ungetesteten Risiken.

51

Brauchen wir eine Dokumenten-Sicht (Lesemodus)?

Review: Fließtext liest sich besser als Tabellen. Wichtig für Fachbereichs-Reviews.

52

Können wir Spalten ausblenden, die gerade nicht interessieren?

Fokus: Im Meeting Metadaten ausblenden, um Platz für Text zu haben.

53

Gibt es eine Hierarchie-Sicht (Baumstruktur)?

Struktur: Epic → Story → Task. Zeigt den Zerlegungsgrad.

54

Wie visualisieren wir Abhängigkeiten?

Netzwerk: Graph oder Matrix. Zeigt "Wenn A sich ändert, muss B geprüft werden".

55

Gibt es eine Kanban-Sicht (Board)?

Flow: Karten schieben. Besser als Status in Dropdowns ändern.

I

SUCHE & NAVIGATION

56

Können wir nach Textinhalten suchen (Volltext)?

Recherche: "Wo steht was zu 'Drucker'?". Muss schnell gehen.

57

Gibt es eine Sicht für „Meine Aufgaben“?

ToDo: Filter "Owner = CurrentUser". Das ist die tägliche Arbeitsliste.

58

Brauchen wir eine Sicht für abgelehnte Anforderungen?

Archiv: Filter "Status = Rejected". Wichtig, wenn die Idee in 3 Monaten wiederkommt ("Hatten wir schon, abgelehnt weil…​").

59

Gibt es eine Matrix-Sicht (Anforderung vs. Testfall)?

Coverage: Zeigt weiße Flecken in der Testabdeckung.

60

Können wir Anforderungen nach Priorität sortieren?

Ranking: Drag & Drop Sortierung für das Backlog. Prio 1 muss oben stehen.

61

Gibt es eine Kalender-Sicht?

Zeit: Wann kommt was? Für Marketing und Release-Management.

J

TOOL-KONFIGURATION & REGELN

62

Gibt es ein verbindliches Attributschema für alle Anforderungen?

Standard: Alle müssen die gleichen Felder nutzen. Kein Excel-Wildwuchs.

63

Welche Attribute sind Pflichtfelder (Mandatory)?

Qualität: Ohne "Titel" und "Typ" kein Speichern. Erzwingen Sie Minimum-Datenqualität.

64

Unterscheiden sich die Attribute je nach Anforderungstyp?

Typisierung: Ein "Use Case" hat andere Felder als eine "NFR" (z.B. Messgröße).

65

Gibt es Attribute mit vordefinierten Wertelisten (Enums)?

Sauberkeit: Keine Freitext-Status ("fast fertig"). Nur Dropdowns erlauben Auswertungen.

66

Wer darf welche Attribute ändern?

Rechte: Entwickler darf Aufwand ändern, aber nicht Prio. PO darf Prio ändern, aber nicht Aufwand.

67

Werden Änderungen an Attributen historisiert?

Audit Trail: Wer hat die Prio von "Hoch" auf "Niedrig" gesetzt?

68

Gibt es Plausibilitätsprüfungen für Attribute?

Logik: Wenn Status = "Fertig", darf Restaufwand nicht > 0 sein.

69

Sind Attribute für den Export relevant?

Report: Markieren Sie Felder, die ins PDF-Lastenheft gedruckt werden sollen ("Public").

70

Nutzen wir Farben zur Visualisierung von Attributen?

Usability: Status "Bug" = Rot. Hilft beim schnellen Scannen der Liste.

71

Können Sichten gespeichert und geteilt werden?

Team: Bauen Sie Standard-Sichten für alle ("Shared Views"), damit alle auf die gleiche Liste schauen.

Nachvollziehbarkeit (Traceability)
Wir verknüpfen Anforderungen untereinander und mit anderen Artefakten. Wir stellen sicher, dass wir wissen, warum eine Anforderung existiert (Link zum Ziel) und wo sie umgesetzt wurde (Link zum Code/Test). Dies ist essenziell für Audits und die Analyse von Auswirkungen bei Änderungen.

Details

5.2 Nachvollziehbarkeit & Traceability (Operative Audit-Checkliste)

diagram-5-2-mindmap

A – Strategie & Zielsetzung: Dieser Abschnitt definiert den Zweck und Umfang der Traceability. Es wird geklärt, ob sie nur gesetzlich vorgeschrieben ist oder auch der Impact-Analyse dient. „Muss“- und „Kann“-Pfade werden unterschieden, um ein effizientes Kosten-Nutzen-Verhältnis zu wahren. Mehrwert: Verhindert unnötigen Aufwand („Wartungshölle“) durch das wahllose Verlinken von allem mit allem und fokussiert auf wertstiftende Nachvollziehbarkeit.

B – Quellen-Nachweis (Pre-Traceability): Hier wird die Herkunft jeder Anforderung dokumentiert: Kommt sie aus einem Meeting, einem Gesetz oder einem Geschäftsziel? Dies belegt die Daseinsberechtigung („Justification“) und verlinkt auf Stakeholder und Prozesse. Mehrwert: Ermöglicht es, bei Unklarheiten sofort den richtigen Ansprechpartner zu finden und verhindert „Goldplating“, indem Anforderungen ohne Quelle hinterfragt werden.

C – Struktur & Abhängigkeiten (Inter-Traceability): Dieser Bereich regelt die Verknüpfung von Anforderungen untereinander: Abhängigkeiten („A braucht B“), Hierarchien (System → Software), Konflikte oder Varianten. Auch die Verbindung von User Stories zu Epics gehört hierzu. Mehrwert: Ermöglicht die Analyse von Seiteneffekten bei Änderungen und unterstützt das Variantenmanagement sowie die Fortschrittskontrolle in agilen Projekten.

D – Umsetzung & Architektur (Post-Traceability): Es werden Anforderungen mit den Artefakten der Lösung verknüpft: Architektur-Module, Quellcode (via Commit-Messages), Datenbank-Tabellen und UI-Screens. Mehrwert: Beantwortet die Frage „Wo ist diese Anforderung im Code umgesetzt?“ und erleichtert so das Debugging, Refactoring und Architektur-Reviews massiv.

E – Verifikation & Validierung (Test): Hier wird die Verbindung zur Qualitätssicherung hergestellt: Anforderungen werden mit Testfällen (Planung) und Testergebnissen (Status) verlinkt. Dies ist der wichtigste Trace für die Abnahme. Mehrwert: Liefert den Beweis, dass das System tut, was es soll, und deckt ungetestete Anforderungen („Blind Spots“) gnadenlos auf.

F – Analyse & Reporting: Dieser Abschnitt beschreibt die Nutzung der Daten: Impact-Analysen bei Änderungen, Coverage-Reports („Wie viel ist getestet?“) und das Management von „Suspect Links“ (Verdacht auf Veraltung nach Änderung). Mehrwert: Dient als Frühwarnsystem für Projektrisiken und ermöglicht es, die Auswirkungen von Änderungen („Impact“) vor der Umsetzung abzuschätzen.

G – Compliance & Audit: Für regulierte Branchen (z. B. Automotive, MedTech) ist Traceability gesetzliche Pflicht. Hier wird die lückenlose Nachweiskette und deren Revisionssicherheit für Audits sichergestellt. Mehrwert: Sichert die Zertifizierung und Marktzulassung des Produkts und schützt vor rechtlichen Konsequenzen bei Audits.

H – Tooling & Integration: Es wird die technische Umsetzung geklärt: Nutzung professioneller Tools (Jira, DOORS) statt Excel, Integration über Schnittstellen und automatisierte Verlinkung. Standards wie ReqIF ermöglichen den Datenaustausch. Mehrwert: Reduziert den manuellen Pflegeaufwand drastisch und verhindert Dateninkonsistenzen zwischen verschiedenen Tools der Toolchain.

I – Prozess & Governance: Abschließend werden Verantwortlichkeiten (RACI) geregelt: Wer setzt Links? Wer prüft „Suspect Links“? Traceability wird als fester Bestandteil der „Definition of Done“ verankert. Mehrwert: Stellt sicher, dass Traceability gelebt wird und nicht erst kurz vor Projektende hektisch nachgepflegt wird („Links machen wir am Ende“), was zu Chaos führt.

Nr. Frage Operative Implikation & Handlungsanweisung

A

STRATEGIE & ZIELSETZUNG

1

Welchen konkreten Nutzen versprechen wir uns von der Traceability?

Business Case: Nur gesetzlich nötig oder für Impact-Analyse? Definieren Sie das Ziel ("Warum machen wir das?"), um Aufwand zu rechtfertigen.

2

Welche Traceability-Pfade sind „Muss“ und welche „Kann“?

Kosten-Nutzen: Req→Code ist extrem teuer. Req→Test ist Pflicht. Definieren Sie das minimale Traceability-Modell.

3

Wer sind die Konsumenten der Traceability-Informationen?

Zielgruppe: Wer liest die Matrix? Der Auditor? Der Entwickler? Passen Sie die Granularität an.

4

Wie hoch darf der Wartungsaufwand für die Links sein?

Effizienz: Manuelle Excel-Matrizen sterben nach Woche 4. Planen Sie Ressourcen für Link-Pflege ein.

5

Soll die Traceability bidirektional sein?

Navigation: Können Sie vom Code zur Anforderung springen? Zwingend nötig für "Warum ist dieser Code hier?".

6

Ab welchem Zeitpunkt im Projekt erfassen wir Traces?

Timing: Verlinken Sie erst stabile Anforderungen. Links auf Entwürfe erzeugen Wartungshölle.

7

Ist die Traceability-Strategie dokumentiert?

Plan: Erstellen Sie einen "Traceability Plan" (Teil des QM-Plans). Ohne Plan macht jeder was er will.

B

QUELLEN-NACHWEIS (PRE-TRACEABILITY)

8

Ist jede Anforderung zu ihrer Quelle zurückverfolgbar (Pre-RS)?

Justification: Woher kommt Req-101? (Meeting-Protokoll, Gesetz, Ticket). Ohne Quelle keine Daseinsberechtigung.

9

Verlinken wir Anforderungen mit Geschäftszielen?

Alignment: Req-101 muss auf "Umsatz steigern" einzahlen. Zeigt den Business Value.

10

Verlinken wir zu den ursprünglichen Stakeholdern?

Kontakt: Wer hat das bestellt? Wichtig für Rückfragen bei Unklarheiten.

11

Sind Dokumente (Mails, Protokolle) als Quellen verlinkt?

Evidenz: Verlinken Sie auf das DMS/Wiki. "Wie besprochen" reicht nicht als Quelle.

12

Verfolgen wir Anforderungen zu Geschäftsprozessen zurück?

Kontext: In welchem Prozessschritt wird die Funktion benötigt? Link zum BPMN-Task.

13

Verlinken wir zu Fehlerberichten des Altsystems?

Historie: "Dies ist ein Fix für Bug #500". Verhindert Regression.

14

Bilden wir Änderungswünsche (Change Requests) als Quelle ab?

Change: "Geändert durch CR-05". Wichtig für Abrechnung bei Festpreisprojekten.

C

STRUKTUR & ABHÄNGIGKEITEN (INTER-TRACEABILITY)

15

Gibt es Links zwischen abhängigen Anforderungen?

Logik: "A braucht B". Wenn B verschoben wird, muss A auch verschoben werden.

16

Sind Systemanforderungen mit Softwareanforderungen verknüpft?

Hierarchie: Der "System-Layer" (grob) muss auf den "Software-Layer" (fein) verlinken ("verfeinert durch").

17

Sind widersprüchliche Anforderungen markiert?

Konflikt: Link-Typ "conflicts with". Wichtig für Trade-Off-Entscheidungen.

18

Verlinken wir funktionale mit nicht-funktionalen Anforderungen?

Qualität: "Suche" (Funktion) verlinkt auf "Antwortzeit < 1s" (NFR).

19

Sind Varianten von Anforderungen verknüpft?

Produktlinie: "Basis-Req" verlinkt auf "Premium-Req". Wichtig für Variantenmanagement.

20

Verlinken wir User Stories mit Epics?

Agile: Parent-Child Link. Ohne diesen Link ist keine Fortschrittskontrolle auf Epic-Ebene möglich.

21

Sind Duplikate verlinkt (statt kopiert)?

Redundanz: Link-Typ "duplicates". Löschen Sie Duplikate nicht einfach, verlinken Sie sie als "Obsolete".

22

Sind ausschließende Anforderungen verknüpft (XOR)?

Alternative: Link-Typ "alternative to". Wir bauen entweder A oder B.

D

UMSETZUNG & ARCHITEKTUR (POST-TRACEABILITY)

23

Sind Anforderungen mit Architektur-Komponenten verknüpft?

Allokation: Req-101 wird durch "Modul Auth" realisiert. Wichtig für Architektur-Reviews.

24

Gibt es Links zum Quellcode (Dateien/Klassen)?

Implementierung: Annotationen im Code (@Ref: REQ-123) oder Commit-Messages nutzen.

25

Verlinken wir Commit-Messages mit Anforderungen?

Git: "Implement REQ-123" im Commit. Ermöglicht automatisierte Traceability im CI/CD.

26

Sind Datenbank-Tabellen mit Anforderungen verknüpft?

Daten: Welche Tabelle speichert die Daten für Req-101? Wichtig bei DB-Refactoring.

27

Verlinken wir UI-Elemente (Screens) mit Anforderungen?

Frontend: Welcher Screen setzt die Anforderung um? Link zum Design-Mockup.

28

Sind Konfigurationsparameter verlinkt?

Customizing: Welcher Parameter steuert diese Business-Rule? Wichtig für Betriebshandbuch.

29

Gibt es Links zu Bibliotheken/Frameworks?

Abhängigkeit: "PDF-Export" nutzt "iText-Lib". Wichtig für Lizenz-Audits.

E

VERIFIKATION & VALIDIERUNG (TEST)

30

Sind Testfälle mit der Anforderung verknüpft?

Coverage: Das Wichtigste! Eine Anforderung ohne Test-Link gilt als "ungeprüft".

31

Verlinken wir auf Testfälle oder auf Testergebnisse?

Status: Link zum Testfall (Planung) UND zum letzten Run (Ergebnis: Pass/Fail).

32

Sind Unit-Tests mit Anforderungen verknüpft?

Whitebox: Low-Level-Requirements verlinken auf Unit-Tests.

33

Sind User Acceptance Tests (UAT) verknüpft?

Blackbox: Business-Requirements verlinken auf UAT-Scenarios.

34

Wie verlinken wir gefundene Fehler (Bugs) zur Anforderung?

Defect: Bug #500 blockiert Req-101. Wichtig für Go-Live Entscheidung.

35

Gibt es Links zu Testdaten?

Setup: "Für Req-101 brauchen wir Testdaten-Set 'Kreditkarte'".

36

Sind Sicherheits-Tests (Penetration Tests) verknüpft?

Security: Security-Reqs müssen auf Pen-Test-Reports verlinken.

F

ANALYSE & REPORTING

37

Können wir eine Impact Analysis (Auswirkungsanalyse) durchführen?

Change: Wenn Req A geändert wird → Zeige alle betroffenen Tests und Code-Dateien.

38

Können wir eine Coverage Analysis (Abdeckungsanalyse) erstellen?

Metrik: Report: "10% der Anforderungen haben keinen Test". Das ist ein Projektrisiko.

39

Werden "Suspect Links" (Verdächtige Links) angezeigt?

Warnsystem: Tool muss Test als "Suspect" markieren, wenn sich die Anforderung ändert.

40

Wie visualisieren wir die Traceability?

Sicht: Traceability-Matrix (Zeile=Req, Spalte=Test) oder Graph? Matrix wird bei vielen Daten unlesbar.

41

Wie visualisieren wir die Abdeckung (Coverage)?

KPI: Ampel-Charts im Dashboard. Rot = Ungetestet.

G

COMPLIANCE & AUDIT

42

Gibt es gesetzliche Vorschriften zur Nachweisbarkeit?

Normen: ISO 26262 / FDA. Hier ist Traceability keine Option, sondern Gesetz.

43

Müssen wir lückenlose Traceability nachweisen (Audit)?

Beweislast: Der Auditor prüft stichprobenartig die Kette Req→Test→Ergebnis.

44

Gibt es Anforderungen an die Archivierung der Traces?

Langzeit: Traces müssen mit der Version eingefroren (baselined) werden.

45

Wie beweisen wir die Unveränderlichkeit der Traces?

Integrität: Niemand darf Links löschen, um fehlende Tests zu vertuschen (Audit Trail).

46

Sind die Traces auch im PDF-Export klickbar?

Usability: Für externe Prüfer müssen PDF-Links funktionieren.

47

Wie erklären wir Lücken in der Traceability?

Justification: Wenn kein Test da ist, muss eine Begründung ("Info-Only Req") im Attribut stehen.

H

TOOLING & INTEGRATION

48

Welches Tool nutzen wir für das Requirements Management?

Infrastruktur: Jira, DOORS, Jama? Excel ist für Traceability ungeeignet (Fehleranfällig).

49

Wie integrieren wir verschiedene Tools (Tool-Chain)?

Schnittstelle: Req im Jira, Test im HP ALM? Synchronisation via OSLC oder Plugins nötig.

50

Ist die Traceability manuell oder automatisch?

Aufwand: Automatische Links (durch Namenskonvention) sparen hunderte Stunden Arbeit.

51

Unterstützt das Tool Versionierung von Links?

Historie: Link v1→v1. Wenn Req neu versioniert wird, muss der Link mitwachsen oder suspect werden.

52

Nutzen wir ReqIF zum Austausch von Traces?

Austausch: Standardformat für Traceability über Firmengrenzen hinweg.

53

Wie verhindern wir falsche Verlinkungen?

Regeln: Das Tool muss verhindern, dass ein Testfall mit einem Stakeholder verlinkt wird (Typ-Check).

I

PROZESS & GOVERNANCE

54

Wer ist verantwortlich für das Bereinigen von Suspect Links?

Rolle: Tester müssen nach Req-Änderung das "Suspect"-Flag prüfen und löschen.

55

Wer ist verantwortlich für das Setzen der Links?

RACI: Entwickler verlinkt Code, Tester verlinkt Test. Klären Sie die Zuständigkeit.

56

Wann im Prozess werden Links gesetzt?

Disziplin: Sofort bei Erstellung. "Links machen wir am Ende" führt zu Chaos.

57

Wird Traceability im Review geprüft?

QS: Checklistenpunkt: "Sind alle Links vorhanden?".

58

Ist Traceability Teil der Definition of Done (DoD)?

Schranke: Keine Story gilt als "Done" ohne Test-Link.

59

Wie gehen wir mit Traceability über Firmengrenzen hinweg um?

Vertrag: Zulieferer muss Traces liefern. Teil des Liefergegenstandes.

60

Wird der Aufwand für Traceability eingeplant?

Budget: Link-Pflege kostet Zeit. Berücksichtigen Sie das in den Story Points.

Änderungsmanagement (Die Evolution)
Wenn neue Wünsche aufkommen ("Change Requests"), werden diese nicht einfach durchgewunken, sondern in einem kontrollierten Prozess bewertet. Wir führen eine Impact-Analyse durch (Was kostet die Änderung? Was geht dadurch kaputt?), entscheiden im Change Control Board (CCB) und versionieren die Anforderungen neu (Baselining).

Details

5.3 Änderungsmanagement & Change Requests (Operative Audit-Checkliste)

diagram-5-3-mindmap

A – Prozess & Governance: Dieser Abschnitt definiert den formalen Weg einer Änderung: Wer darf Anträge (CRs) stellen? Wer entscheidet darüber (CCB, PO)? Es werden Prozesse für den Standardfall und den Notfall („Fast-Lane“) sowie der Workflow bis zum Abschluss („Closed“) festgelegt. Mehrwert: Verhindert Chaos durch unkontrollierte Zuruf-Änderungen und stellt sicher, dass Entscheidungen transparent und autorisiert getroffen werden.

B – Analyse & Impact (Auswirkung): Hier wird der Rattenschwanz einer Änderung beleuchtet: Welche Kosten entstehen (Code, Test, Doku)? Welche Seiteneffekte gibt es auf Architektur, Performance oder Security? Eine fundierte Schätzung durch Experten ist Pflicht. Mehrwert: Schützt vor bösen Überraschungen, indem die wahren Kosten und Risiken einer Änderung vor der Genehmigung transparent gemacht werden.

C – Versionierung & Baselining: Dieser Bereich regelt den Umgang mit verschiedenen Ständen: Eindeutige Versionierung (v1.0, v1.1), Einfrieren von Zuständen („Baseline“) zum Release und die Möglichkeit zum Rollback. Diff-Views machen Änderungen sichtbar. Mehrwert: Sichert die Revisionssicherheit und ermöglicht es, jederzeit zu einem stabilen, definierten Projektzustand zurückzukehren.

D – Kosten, Nutzen & Risiko: Es werden wirtschaftliche und strategische Aspekte geprüft: Lohnt sich die Änderung (ROI)? Zahlt sie auf die Vision ein oder ist es nur ein „Quick Hack“? Auch Alternativen (Workarounds) und Risiken für das Release werden abgewogen. Mehrwert: Verhindert Ressourcenverschwendung für unwirtschaftliche Änderungen und schützt die Stabilität des Systems vor riskanten Eingriffen kurz vor Go-Live.

E – Kommunikation & Stakeholder: Hier geht es um die Einbindung der Betroffenen: Zustimmung aller Stakeholder einholen, das Team informieren (Push statt Pull) und Nutzer über Release Notes schulen. Mehrwert: Sichert die Akzeptanz der Änderung und verhindert, dass Nutzer oder Entwickler von Neuerungen überrascht werden und falsch reagieren.

F – Technische Umsetzung & Traceability: Dieser Abschnitt verknüpft den Änderungsprozess mit der Technik: Commit-Messages müssen CRs referenzieren, Testfälle müssen aktualisiert werden („Suspect Links“). Der Weg von der Anforderung bis zum Code muss nachweisbar bleiben. Mehrwert: Garantiert, dass Code-Änderungen immer auf einen genehmigten Auftrag zurückzuführen sind, was für Audits und Wartung essenziell ist.

G – Agilität vs. Stabilität: Es wird der Spagat zwischen Flexibilität und Chaos gemeistert: Änderungen sind willkommen, aber nur geordnet (Backlog). Feature Toggles und strikte Sprint-Regeln schützen den laufenden Betrieb. Mehrwert: Ermöglicht schnelle Reaktionen auf Marktänderungen, ohne den Entwicklungsfluss („Flow“) ständig zu unterbrechen.

H – Umfeldfaktoren & Volatilität: Hier werden externe Treiber betrachtet: Gesetzesänderungen, API-Updates von Partnern oder saisonale Effekte. Bei instabilen Anforderungen („Moving Targets“) wird gewartet statt entwickelt. Mehrwert: Vermeidet Fehlinvestitionen in Features, die sich extern bedingt sofort wieder ändern würden, und spart so "Waste".

I – Vertrag & Abrechnung: Abschließend werden die kommerziellen Folgen geregelt: Kein Change ohne Auftrag („Change Order“), Nutzung von Change-Budgets und Schutz vor schleichendem Umfangswachstum („Scope Creep“) durch Nachforderungen („Claims“). Mehrwert: Sichert die Profitabilität von Projekten (besonders bei Festpreis) und verhindert unbezahlte Mehrarbeit durch unkontrollierte Kundenwünsche.

Nr. Frage Operative Implikation & Handlungsanweisung

A

PROZESS & GOVERNANCE

1

Wer darf einen Änderungsantrag (Change Request - CR) stellen?

Filter: Wenn jeder Entwickler "auf Zuruf" ändert, explodiert der Scope. Nur PO oder Projektleiter dürfen CRs einstellen.

2

Wie muss ein Änderungsantrag formal aussehen?

Standard: Pflichtfelder: Titel, Grund, Nutzen, Kritikalität. Leere Anträge ("Mach mal X") sofort ablehnen.

3

Wer entscheidet über die Genehmigung (Change Control Board - CCB)?

Mandat: Kleine CRs (<2 Tage) entscheidet PO. Große CRs (>5 Tage) das CCB. Definieren Sie die Grenzen.

4

Wie oft tagt das Change Control Board (CCB)?

Rhythmus: Fixer Termin (z.B. Freitags). Ad-hoc Entscheidungen führen zu Chaos.

5

Gibt es einen beschleunigten Prozess für Notfall-Änderungen?

Fast-Lane: Kritische Bugs (Prio 1) brauchen keinen CCB-Beschluss, sondern sofortigen Fix und nachträgliche Doku.

6

Wie werden abgelehnte Änderungen kommuniziert?

Transparenz: E-Mail an Antragsteller mit Begründung. Verhindert Frust und erneutes Einreichen.

7

Wie wird der Status eines CR nachverfolgt?

Workflow: Status "Neu → Analyse → Genehmigt → In Arbeit → Fertig". Alles muss im Tool sichtbar sein.

8

Wann wird der Change Request formal geschlossen?

Abschluss: Erst wenn der Code in Prod ist UND der Kunde das OK gegeben hat.

B

ANALYSE & IMPACT (AUSWIRKUNG)

9

Wer bewertet den Aufwand einer Änderung?

Schätzung: Entwickler + Tester müssen schätzen. "Nur Code ändern" vergisst oft Testaufwand und Doku.

10

Welche anderen Anforderungen sind von dieser Änderung betroffen?

Seiteneffekte: Traceability-Check: Wenn ich A ändere, gehen B und C kaputt? Impact-Analyse ist Pflicht.

11

Welche Systemkomponenten müssen angepasst werden?

Architektur: Betrifft es nur UI oder auch DB? DB-Änderungen sind teuer (Migration).

12

Welche Testfälle müssen angepasst oder neu erstellt werden?

QS: Planen Sie Zeit für Test-Updates ein. Alte Tests laufen oft auf Fehler ("False Positives").

13

Müssen Dokumentationen (Handbücher) aktualisiert werden?

Doku: Screenshots im Handbuch veralten sofort. Planen Sie das Budget dafür ein.

14

Hat die Änderung Auswirkungen auf die Performance?

NFR: "Kleine" Änderung an der Suche kann die DB lahmlegen. Performance-Check vor Freigabe.

15

Entstehen neue Sicherheitsrisiken durch die Änderung?

Security: Neuer Upload = Neues Viren-Risiko. Security-Review bei Architektur-Changes.

16

Beeinflusst die Änderung die Benutzeroberfläche (UI)?

UX: Passt der neue Button noch ins Layout (Mobile)? UI-Mockup aktualisieren.

17

Verursacht die Änderung Schulungsaufwand?

Change: Wenn der Prozess sich ändert, müssen User geschult werden. Kostenfaktor!

18

Gefährdet die Änderung den Zeitplan (kritischer Pfad)?

Risiko: Wenn der CR den Go-Live verschiebt → Eskalation an Lenkungsausschuss.

C

VERSIONIERUNG & BASELINING

19

Wie identifizieren wir jede Anforderungsversion eindeutig?

Historie: Req-101 v1.0 (alt) vs v1.1 (neu). Keine Änderungen ohne Versionssprung.

20

Können wir zu einem alten Stand zurückkehren (Rollback)?

Sicherheit: Das Tool muss "Undo" oder "Revert to v1.0" erlauben.

21

Wie gruppieren wir zusammengehörige Versionen (Baselines)?

Snapshot: "Baseline 1.0" friert den Stand zum Release ein. Änderungen danach nur in "Baseline 1.1".

22

Dürfen wir an Anforderungen arbeiten, die schon freigegeben sind?

Locking: Freigegebene Reqs sind "Read-Only". Änderung erfordert CR und neue Version.

23

Welche Version der Anforderung ist aktuell gültig?

Klarheit: Entwickler darf nur die "Approved" Version sehen, nicht "Draft".

24

Werden Änderungen an Anforderungen automatisch historisiert?

Audit Trail: Wer hat wann was geändert? (Diff-View).

25

Wie vergleichen wir zwei Versionen einer Anforderung (Diff)?

Tool: Rot durchgestrichen (alt) / Grün unterstrichen (neu). Niemand liest alles neu.

26

Haben wir eine Namenskonvention für Baselines?

Ordnung: "BL_Rel_2.0_Final". Wildwuchs bei Namen vermeiden.

27

Wer darf eine Baseline erstellen oder schließen?

Rechte: Nur der Release-Manager oder Lead-RE.

D

KOSTEN, NUTZEN & RISIKO

28

Welche Kosten verursacht die Änderung (Implementierung + Test)?

Preisschild: CR ohne Kostenschätzung wird nicht bearbeitet.

29

Welchen Nutzen bringt die Änderung (Business Value)?

ROI: Kostet 5 Tage, bringt aber nur 1 Tag Ersparnis? → Ablehnen.

30

Wer trägt die Kosten für die Änderung?

Budget: Zahlt das Projekt oder der Kunde (Extra-Auftrag)? Wichtig bei Festpreis.

31

Gibt es Alternativen zur Änderung (Workarounds)?

Vermeidung: "Können wir das organisatorisch lösen?" ist oft billiger als Code.

32

Wie hoch ist das Risiko der Änderung?

Stabilität: Eingriff in den Core-Code kurz vor Release = Hochrisiko.

33

Passt die Änderung noch in das aktuelle Release?

Scope: Wenn der Sprint voll ist → Verschieben auf nächstes Release oder "Swap" (etwas anderes rausnehmen).

34

Ist die Änderung strategisch sinnvoll?

Vision: Kunde will "Quick Hack", wir wollen "Saubere Architektur". Strategie schlägt Taktik.

35

Wird der Mehraufwand für Wartung durch die Änderung berücksichtigt?

TCO: Feature ist schnell gebaut, aber teuer zu warten. TCO berechnen.

E

KOMMUNIKATION & STAKEHOLDER

36

Stimmen alle betroffenen Stakeholder zu?

Konsens: Vertrieb will Änderung, Support hasst sie. Einigung vor Umsetzung.

37

Wie kommunizieren wir Änderungen an das Entwicklungsteam?

Push: Nicht "steht im Wiki", sondern "Ticket-Update" oder Daily Standup.

38

Wie erfahren die Nutzer von den Änderungen (Release Notes)?

Marketing: "What’s New" Pop-up oder E-Mail.

39

Müssen Schulungsunterlagen aktualisiert werden?

Enablement: Screenshots austauschen. Veraltete Handbücher frustrieren User.

40

Wie stellen wir sicher, dass alte Versionen nicht mehr genutzt werden?

Rollout: Zwang zum Update (App) oder Abschalten der alten API.

F

TECHNISCHE UMSETZUNG & TRACEABILITY

41

Wie verfolgen wir Änderungen bis in den Code?

Git: Commit-Message muss CR-Nummer enthalten ("Fixes CR-123").

42

Sind Testfälle mit der spezifischen Version der Anforderung verknüpft?

Präzision: Test T1 prüft Req v2. Wenn Req v3 kommt, muss Test T1 "Suspect" werden.

43

Zeigt das Tool an, welche verknüpften Objekte "suspekt" sind?

Warnsystem: Automatische Markierung betroffener Artefakte.

44

Können wir beweisen, warum eine Änderung durchgeführt wurde?

Nachweis: Trace: Code → CR → E-Mail vom Kunden.

45

Wie dokumentieren wir Änderungen an der Traceability selbst?

Meta: Wer hat den Link gelöscht? (Audit Log).

G

AGILITÄT VS. STABILITÄT

46

Ist unser Entwicklungsprozess auf Änderungen ausgelegt (Agil)?

Mindset: Änderungen sind willkommen, ABER nur geordnet (Backlog Refinement).

47

Wie gehen wir mit "Scope Creep" um?

Disziplin: "Nur noch ein kleines Feld" x 100 = Projektverzug. "Nein" sagen.

48

Nutzen wir Feature Toggles für unfertige Änderungen?

Technik: Code ist drin, aber inaktiv. Erlaubt Release trotz unfertigem CR.

49

Wie integrieren wir Änderungen in laufende Sprints?

Regel: Laufender Sprint ist tabu (außer Prio 1 Bug). Änderungen kommen ins Backlog.

50

Wie priorisieren wir Bugfixes vs. Change Requests?

Triage: Bug = Fehler im Bestehenden. CR = Neuer Wunsch. Bugs gehen meist vor.

H

UMFELDFAKTOREN & VOLATILITÄT

51

Wie hoch ist die Wahrscheinlichkeit, dass sich diese Anforderung bald ändert?

Stabilität: Wenn Gesetzgebung noch läuft → Nicht implementieren, warten.

52

Welche externen Faktoren könnten Änderungen erzwingen?

Abhängigkeit: API-Änderung von Google/Apple. Wir müssen reagieren.

53

Gibt es saisonale Schwankungen?

Timing: Weihnachts-Feature im Januar ändern ist sinnlos.

54

Ist die Anforderung ein "Moving Target"?

Forschung: KI-Projekte ändern sich ständig. Agile Verträge nutzen (T&M), keinen Festpreis.

55

Gibt es konkurrierende Standards?

Wette: Blu-Ray vs. HD-DVD. Setzen wir aufs richtige Pferd?

I

VERTRAG & ABRECHNUNG

56

Müssen Änderungen vom Kunden explizit beauftragt werden?

Geld: Keine Arbeit ohne Auftrag (Change Order). Schutz vor unbezahlter Mehrarbeit.

57

Gibt es ein Budget für "Unvorhergesehenes" (Change Budget)?

Puffer: 10-20% Reserve für Changes einplanen.

58

Wie vermeiden wir "Scope Creep" durch viele kleine Änderungen?

Masse: Viele kleine CRs bündeln und als Paket bewerten.

59

Wie gehen wir mit Änderungen nach Vertragsabschluss um?

Claim: Jede Abweichung vom Lastenheft ist ein CR (Mehrkosten).

60

Werden die Kosten für Änderungen dem Verursacher berechnet?

Verrechnung: Interne Leistungsverrechnung diszipliniert die Fachbereiche.

Transition & Abschluss (Der Rollout)
Am Ende des Zyklus steht die Überführung in den Betrieb. Wir planen die Migration der Daten aus Altsystemen, erstellen Schulungsunterlagen basierend auf den Anforderungen und bereiten den Rollout vor. Nach dem Go-Live werden Altsysteme abgeschaltet und das Projekt formal abgeschlossen.

Details

5.4 Transition & Abschluss (Operative Audit-Checkliste)

diagram-5-4-mindmap

A – Migrations-Strategie & Scope: Dieser Abschnitt klärt das "Wie" und "Was" der Umstellung: Wird alles auf einmal ("Big Bang") oder stufenweise umgestellt? Welche Datenhistorie muss mitgenommen werden (z. B. nur 2 Jahre)? Auch der Parallelbetrieb und Strategien für "Schattendaten" (Excel-Listen) werden definiert. Mehrwert: Minimiert das Risiko eines Totalausfalls beim Go-Live und verhindert, dass das neue System mit unnötigem Datenballast verstopft wird.

B – Datenqualität & Mapping: Hier wird die "Übersetzung" vom Alt- ins Neusystem geregelt. Mapping-Tabellen, Dublettenbereinigung und Datentyp-Konvertierungen (z. B. Währungsumrechnung) sind zentral. Daten müssen vor dem Import bereinigt werden ("Garbage In, Garbage Out"). Mehrwert: Sichert die Integrität und Nutzbarkeit der Daten im neuen System und verhindert böse Überraschungen durch inkompatible Formate.

C – Cutover-Planung (Go-Live): Dieser Bereich plant das finale Umstellungswochenende minutengenau ("Runbook"). Downtime-Fenster, Go/No-Go-Entscheidungen und die technische Umschaltung (DNS, Schnittstellen) werden festgelegt. Mehrwert: Sorgt für einen geordneten, stressfreien Go-Live und stellt sicher, dass alle Beteiligten genau wissen, wann was passiert.

D – Rollback & Notfall (BCM): Es wird der "Plan B" definiert: Was tun, wenn die Migration scheitert? Der "Point of No Return" und getestete Restore-Verfahren für das Altsystem sind Lebensversicherungen für das Business. Mehrwert: Schützt das Unternehmen vor existenzbedrohendem Stillstand, falls das neue System am Montagmorgen nicht läuft.

E – Test & Validierung der Migration: Hier werden Prüfmethoden definiert: Zählen von Datensätzen (Alt vs. Neu), Summenvergleiche und "Smoke Tests" am Stichtag. Auch die formale Abnahme des Mappings durch den Fachbereich gehört dazu. Mehrwert: Liefert den Beweis, dass keine Daten verloren gegangen sind, und gibt dem Management die Sicherheit für die Freigabe.

F – Schulung & Onboarding: Dieser Abschnitt regelt die Befähigung der Nutzer: Wann finden Schulungen statt? Wer sind die Key User ("Train the Trainer")? Kurzanleitungen und Sandbox-Umgebungen helfen beim Start. Mehrwert: Sichert die Produktivität ab Tag 1 und verhindert Frust bei den Anwendern, die sonst das neue System ablehnen würden.

G – Betrieb & Hypercare: Nach dem Go-Live folgt die Phase intensiver Betreuung ("Hypercare"). Ein "War Room", schnelle SLAs und transparente Kommunikation über bekannte Fehler stabilisieren den Betrieb. Mehrwert: Fängt Anfangsschwierigkeiten sofort auf und gibt den Nutzern das Gefühl, gut betreut zu sein, was die Akzeptanz massiv erhöht.

H – Altsystem Abschaltung (Decommissioning): Das alte System darf nicht ewig weiterlaufen. Kündigungsfristen, Read-Only-Zugriffe für Archive und die sichere Löschung von Daten werden hier geplant. Mehrwert: Spart doppelte Lizenz- und Betriebskosten und erfüllt datenschutzrechtliche Löschpflichten.

I – Nachbearbeitung & Lessons Learned: Abschließend wird aufgeräumt: Temporäre Berechtigungen löschen, alte Links umleiten und aus Fehlern lernen (Retrospektive). Mehrwert: Schließt das Projekt sauber ab, schließt Sicherheitslücken und verbessert die Organisation für zukünftige Projekte.

Nr. Frage Operative Implikation & Handlungsanweisung

A

MIGRATIONS-STRATEGIE & SCOPE

1

Ersetzt das System ein Altsystem vollständig oder nur teilweise?

Strategie: Klären Sie den Umfang der Ablösung. Mischbetrieb ist komplex. Wenn Altsystem weiterlebt: Synchronisationsregeln definieren.

2

Welche Datenobjekte müssen zwingend aus dem Altsystem übernommen werden?

Scope: Definieren Sie eine Whitelist. Alles andere wird nicht migriert. "Alles übernehmen" ist teuer und riskant.

3

Wie weit zurück reicht die Historie, die migriert werden muss?

Archivierung: Migrieren Sie nur aktive Daten (z.B. letzte 2 Jahre). Alte Daten ins Archiv (Read-Only).

4

Sollen abgeschlossene Vorgänge migriert werden oder nur offene?

Filter: Migrieren Sie nur offene Tickets. Geschlossene bleiben im Altsystem (als Archiv).

5

Erfolgt die Einführung auf einen Schlag ("Big Bang") oder stufenweise?

Risiko: Big Bang ist am riskantesten. Prüfen Sie "Phased Rollout" nach Standorten oder Abteilungen.

6

Müssen wir einen Parallelbetrieb fahren?

Sicherheit: Teuer, aber sicher. Daten müssen doppelt gepflegt werden. Definieren Sie das Ende des Parallelbetriebs hart.

7

Was ist der Plan B, wenn die Migration scheitert (Rollback)?

Notfall: Definieren Sie den "Point of No Return". Bis dahin muss ein Rücksprung ins Altsystem möglich sein.

8

Gibt es "Schattendaten", die migriert werden müssen (Excel-Listen)?

Vollständigkeit: Suchen Sie nach Excel-Listen auf Desktops. Diese Daten fehlen sonst im neuen CRM.

9

Sollen Protokolle und Audit-Logs übernommen werden?

Compliance: Logs migriert man selten (technisch schwer). Sichern Sie diese als durchsuchbares PDF/Archiv.

B

DATENQUALITÄT & MAPPING

10

Welches Feld im Altsystem entspricht welchem Feld im Neusystem?

Mapping: Erstellen Sie eine Excel-Tabelle: Quelle → Ziel → Transformationsregel. Das ist die Bibel der Migration.

11

Müssen Daten vor der Migration bereinigt werden (Data Cleansing)?

Hygiene: Bereinigen Sie im ALTSYSTEM, bevor Sie exportieren. "Garbage In, Garbage Out".

12

Wie gehen wir mit Dubletten um?

Merge: Definieren Sie Regeln: "Neuester Datensatz gewinnt" oder manuelle Bereinigung vor Migration.

13

Gibt es Daten im neuen System, die im alten fehlen (Anreicherung)?

Defaults: Wenn "E-Mail" im Altsystem fehlt, aber im neuen Pflicht ist: Setzen Sie einen Dummy-Wert oder fordern Sie Nachpflege.

14

Müssen Werte umschlüsselt werden (Mapping)?

Logik: Status "1" (Alt) = "Neu" (Neu). Status "99" (Alt) = "Archiviert" (Neu).

15

Müssen mehrere Felder zusammengefügt oder getrennt werden?

Struktur: "Name" (Alt) → "Vorname" + "Nachname" (Neu). Das ist fehleranfällig (z.B. "Dr. Hans Müller").

16

Wie gehen wir mit unterschiedlichen Datentypen um?

Konvertierung: Text "100,00" zu Zahl 100.00. Achten Sie auf Dezimaltrenner (Punkt/Komma).

17

Müssen IDs neu vergeben werden oder bleiben sie erhalten?

Referenz: Behalten Sie alte Kundennummern als "Legacy_ID" bei, um Suchbarkeit zu gewährleisten.

18

Müssen Währungen umgerechnet werden?

Historie: Alte DM-Beträge nicht 1:1 als Euro importieren! Umrechnen oder Währungskennzeichen mitnehmen.

19

Gibt es Datenformate im Altsystem, die wir nicht mehr unterstützen?

Kompatibilität: Prüfen Sie alte Binär-Blobs oder proprietäre Formate. Können wir diese lesen?

C

CUTOVER-PLANUNG (GO-LIVE)

20

Wie lange darf das System für die Umstellung offline sein (Cutover-Fenster)?

Downtime: Reicht das Wochenende (48h)? Testen Sie die Laufzeit des Imports mit voller Datenmenge!

21

Wer entscheidet über den finalen Go-Live (Go/No-Go)?

Entscheidung: Meeting am Freitagmittag. Checkliste muss 100% grün sein.

22

Gibt es einen Drehbuch-Plan für den Cutover?

Runbook: Minutiöser Plan (Excel): "Samstag 08:00: DB-Dump", "09:00: Import Start". Mit Verantwortlichen.

23

Gibt es manuelle Schritte, die während des Cutovers nötig sind?

Checkliste: DNS-Umstellung, Firewalls öffnen, Schnittstellen aktivieren. Nichts vergessen!

24

Wie informieren wir Kunden/Partner über die Wartung?

Kommunikation: E-Mail 1 Woche vorher. Wartungsseite ("Under Construction") schalten.

25

Wann erfolgt die Umschaltung der DNS-Einträge / URLs?

Switch: TTL (Time To Live) der DNS-Einträge vorher reduzieren, damit die Umschaltung schnell greift.

26

Wie stellen wir sicher, dass niemand mehr im alten System arbeitet?

Lock: Setzen Sie das Altsystem auf "Read-Only" oder ändern Sie Passwörter.

27

Müssen Schnittstellen während des Cutovers gepuffert werden?

Queueing: Wenn Bestellungen reinkommen, während das ERP down ist: Warteschlange einrichten.

D

ROLLBACK & NOTFALL (BCM)

28

Wie lange dauert der Restore des Altsystems?

RTO: Wenn der Import am Sonntagabend scheitert: Schaffen wir es bis Montag 08:00 zurück zum Altsystem?

29

Was passiert mit Daten, die während des fehlgeschlagenen Versuchs entstanden sind?

Verlust: Diese Daten sind meist verloren oder müssen manuell nacherfasst werden. Klären!

30

Wer darf den Rollback auslösen?

Eskalation: Nur der Lenkungsausschuss/CIO. Ein Rollback ist ein massiver Imageschaden.

31

Ist das Rollback-Szenario getestet worden?

Sicherheit: Üben Sie den Restore. Ein ungetestetes Backup ist kein Backup.

32

Gibt es eine Notfall-Lösung für den Geschäftsbetrieb (Business Continuity)?

Papier: Können wir Bestellungen auf Papier aufnehmen, wenn das System Montag nicht läuft?

E

TEST & VALIDIERUNG DER MIGRATION

33

Wie validieren wir den Erfolg der Migration?

Vergleich: Anzahl Datensätze Alt = Anzahl Neu? Summe aller Rechnungsbeträge Alt = Neu?

34

Wie prüfen wir am Stichtag, ob das System läuft (Smoke Test)?

Test: Ein User loggt sich ein, sucht einen Kunden, legt einen Auftrag an. Erst dann Freigabe für alle.

35

Gibt es Daten, die anonymisiert werden müssen?

Testdaten: Für Test-Migrationen (nicht Prod!) müssen Echtdaten anonymisiert werden (DSGVO).

36

Wer nimmt das Mapping formal ab?

Verantwortung: Der Fachbereich muss bestätigen, dass Feld A wirklich in Feld B gehört.

F

SCHULUNG & ONBOARDING

37

Welche Benutzergruppen müssen geschult werden?

Zielgruppe: Admins brauchen Technik-Schulung, User Prozess-Schulung.

38

Wann sollen die Schulungen stattfinden?

Timing: Max. 2 Wochen vor Go-Live. Sonst ist das Wissen wieder weg.

39

Wer sind die Key User / Multiplikatoren?

Skalierung: Schulen Sie Key User intensiv, die dann ihre Kollegen schulen (Train the Trainer).

40

Gibt es Kurzanleitungen (Quick Reference Guides)?

Hilfe: Ein "Spickzettel" (1 Seite PDF) hilft mehr als ein 100-Seiten-Handbuch.

41

Brauchen wir eine eigene Schulungsumgebung?

Sandbox: User dürfen nicht im Produktionssystem üben! Eigene Instanz bereitstellen.

G

BETRIEB & HYPERCARE

42

Wie ist der Support in den ersten Wochen geregelt (Hypercare)?

War Room: Entwickler und Support sitzen in einem Raum (oder Chat), um sofort zu reagieren.

43

Welche SLAs gelten in der Hypercare-Phase?

Reaktion: Schnellere Reaktionszeiten als normal. Tägliche Status-Calls.

44

Wie melden Nutzer Fehler nach dem Go-Live?

Kanal: Dedizierte E-Mail-Adresse oder Ticket-Queue "Go-Live Probleme".

45

Gibt es bekannte Fehler (Known Issues), mit denen wir live gehen?

Transparenz: Liste der bekannten Bugs veröffentlichen, damit User sie nicht nochmal melden.

46

Wann endet die Hypercare-Phase?

Exit: Wenn Ticket-Anzahl < 10 pro Tag ist. Formaler Abschluss.

H

ALTSYSTEM ABSCHALTUNG (DECOMMISSIONING)

47

Wann wird das Altsystem abgeschaltet?

Termin: Kündigungsfristen für Hardware/Lizenzen beachten.

48

Benötigen wir einen Lesezugriff auf das Altsystem (Read-Only)?

Archiv: Altsystem oft noch 1-2 Jahre im "Nur-Lese-Modus" für Recherche nötig.

49

Wie lange laufen Lizenzen für das Altsystem weiter?

Kosten: Doppelte Lizenzkosten in der Parallelphase einplanen.

50

Gibt es rechtliche Auflagen zur Löschung des Altsystems?

Datenschutz: Alte Festplatten sicher vernichten. Löschprotokoll erstellen.

51

Werden Schnittstellenpartner über die Abschaltung informiert?

Abhängigkeit: Partner müssen wissen, dass sie keine Daten mehr an das alte System senden dürfen.

I

NACHBEARBEITUNG & LESSONS LEARNED

52

Haben wir Lessons Learned dokumentiert?

KVP: Retrospektive durchführen. Was lief beim Cutover schlecht?

53

Gibt es Verknüpfungen (Links) im Intranet auf das alte System?

Aufräumen: Redirects einrichten oder Links aktualisieren.

54

Wurden alle temporären Migrations-User und -Berechtigungen gelöscht?

Security: Admin-Rechte der Migrations-Consultants sofort entziehen.