Das 5 Phasenmodell der Anforderungsanalyse

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.

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).

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.

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.

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.

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.

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).

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.

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?"

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.