Antwort.

Geschichte der Frage:

Ursprünglich konzentrierten sich Systemanalytiker in IT-Projekten hauptsächlich auf die Geschäftsanforderungen, während technische Einschränkungen übermittelt oder ignoriert wurden, was zu nicht funktionierenden oder übermäßig kostspieligen Lösungen führte.

Problem:

Technische Einschränkungen sind nicht immer dokumentiert – der Auftraggeber kann sie nicht kennen, die Entwicklung kann sie nicht berücksichtigen, und das Ergebnis kann den Möglichkeiten der Infrastruktur oder der Integrationssysteme widersprechen.

Lösung:

Der Systemanalytiker interviewt aktiv Architekten, DevOps, QA und Integratoren:

• Bestimmt technologische Stapel, geschäftliche und infrastrukturelle Abhängigkeiten.
• Stimmt Anforderungen mit architektonischen Prinzipien ab: SLA, Ausfallsicherheit, Skalierbarkeit, Lizenz- oder Sicherheitsbeschränkungen.
• Dokumentiert und validiert Kompromisse zwischen Möglichkeiten und Wünschen des Unternehmens.
• Wendet Ansätze wie "Szenario-basierte Analyse" und "Nicht-funktionale Anforderungen" an.

Schlüsselmerkmale:

• Frühe Dokumentation von Einschränkungen und Abhängigkeiten mit allen Verantwortlichen.
• Dokumentation von Kompromissen und impliziten Einschränkungen.
• Ständige Überprüfung der Projektlösungen mit der Unternehmensarchitektur.

Fangfragen.

Kann man implizite technische Einschränkungen ignorieren, wenn sie nicht direkt erwähnt werden?

Korrekt: Nein. Implizite technische Einschränkungen (z.B. Integrationszeitüberschreitungen, Nachrichtengrößenlimits) erfordern immer eine detaillierte Betrachtung und Dokumentation, auch wenn sie nicht ausdrücklich erwähnt werden.

Sollte der Analyst an architektonischen Calls/Workshops teilnehmen?

Korrekt: Ja, der Systemanalytiker ist die Verbindung zwischen dem Geschäft und den Architekten, überträgt Anforderungen an beide Seiten und dokumentiert Entscheidungen.

Reicht es aus, nurGeschäftsanforderungen zu sammeln, ohne die geerbten Einschränkungen zu analysieren?

Korrekt: Nicht ausreichend. Geerbter Code, Lizenzen, Integrationen (Legacy) diktieren manchmal eine größere Anzahl von Einschränkungen, als die ausdrücklich festgelegten Anforderungen.

Typische Fehler und Anti-Muster

• Unterschätzung versteckter Einschränkungen und Abhängigkeiten alter Systeme.
• Ignorieren von "nicht schriftlichen" Architekturregeln.
• Dokumentation nur des geschäftlichen Teils ohne Berücksichtigung der technischen Umsetzbarkeit.

Beispiel aus dem Leben

Negativer Fall: Der Analyst dokumentierte die Integration nach dem Geschäftsprozess, erkundigte sich jedoch nicht nach den Einschränkungen bezüglich der Datenübertragungsgeschwindigkeit in der Schnittstelle.

Vorteile: Schnelle Umsetzung der Spezifikation. Nachteile: Das System hielt der Last nicht stand, das Geschäft verlor Geld und Zeit.

Positiver Fall: Der Analyst nahm an architektonischen Sitzungen teil, identifizierte Einschränkungen (maximale Threads = 100, Integration einmal alle 10 Sekunden) und stimmte mit dem Geschäft die kritischen Limits ab.

Vorteile: Lösung ist funktionsfähig, stabile Integration. Nachteile: Es musste funktionalitätstechnisch ein Kompromiss eingegangen werden und dies dem Auftraggeber begründet werden.