Systemanalyse in der IT

From Systems analysis wiki
Jump to navigation Jump to search

Systemanalyse in der IT (Systems Analysis and Design) ist ein Ansatz zur Konzeption und Entwicklung von Informationssystemen, von der Idee bis zum Betrieb. Dieser Ansatz umfasst die Ermittlung von Bedürfnissen, die Formalisierung von Anforderungen, die Modellierung der Fachdomäne und der Prozesse sowie die Bewertung von Alternativen und Risiken. Anders ausgedrückt ist die Systemanalyse in der IT die Entwicklungsphase, in der Fachleute eine Problemstellung untersuchen, definieren, was das System leisten soll, und Lösungen für dessen Erstellung erarbeiten.

Die klassische Systemanalyse umfasst ein breites Spektrum an Anwendungsbereichen, nicht nur die Softwareentwicklung, sondern auch organisatorische Veränderungen, Strategien und andere Aspekte.[1] [2]

Gegenstand und Aufgaben der Systemanalyse in der IT

Der Gegenstand der Systemanalyse in der IT ist ein Informationssystem (Softwareprodukt und/oder Dienstleistung) über seinen gesamten Lebenszyklus – von der Konzeption und Begründung bis zur Implementierung und zum Betrieb.

Die Aufgabe der Systemanalyse besteht darin, Geschäftsanforderungen in einen abgestimmten und überprüfbaren Satz von Anforderungen und Architekturentscheidungen zu überführen: die Ziele und Einschränkungen der Stakeholder zu identifizieren und zu dokumentieren, Anforderungen zu formalisieren, die Fachdomäne und Prozesse zu modellieren, die Machbarkeit und Risiken von Alternativen zu bewerten und die gewählte Architektur zu begründen. Das Ergebnis sind abgestimmte Dokumente und nachverfolgbare Verbindungen zwischen Anforderungen, Entwurfsentscheidungen und Tests. Dies gewährleistet die Steuerbarkeit und Kontrolle über den Entwicklungsprozess.

Die Aufgaben der Systemanalyse umfassen:

  • Ermittlung der Bedürfnisse und Ziele der Stakeholder. Der Analytiker sammelt und präzisiert die Erwartungen von Kunden, Benutzern und anderen interessierten Parteien. Hierbei kommen Interviews, Umfragen, Beobachtungen und die Analyse bestehender Prozesse zum Einsatz. Das Ergebnis ist eine erste Anforderungsspezifikation, die in funktionale („was das System tun soll“) und nichtfunktionale Anforderungen (Zuverlässigkeit, Leistung, Sicherheit usw.) unterteilt ist.[1][2]
  • Formalisierung und Dokumentation von Anforderungen. Anfragen werden in überprüfbare Anforderungen umgewandelt. Eine gut formulierte Anforderung muss klar und unmissverständlich, vollständig, widerspruchsfrei, überprüfbar und auf übergeordnete Ziele zurückführbar sein; der Anforderungssatz muss konsistent und in sich geschlossen sein.[3][4] In der Praxis werden standardisierte Dokumente verwendet: SRS (Software Requirements Specification) nach ISO/IEC/IEEE 29148 sowie in bestimmten Branchen URS (User Requirements Specification) und funktionale Spezifikationen.[5][6][7]
  • Analyse und Modellierung des Systems. Um zu verstehen, wie das System funktionieren und mit der Außenwelt interagieren wird, werden Modelle erstellt: Anwendungsfalldiagramme (Use Case) für Nutzungsszenarien, DFD für Datenflüsse und Geschäftsprozesse, Klassen-/Komponentendiagramme usw. Modelle dienen als Grundlage für den Vergleich alternativer Lösungen und Architekturen.[8][9][10]
  • Bewertung der Machbarkeit und Auswahl der Lösung. Es wird eine Feasibility Study (technische, organisatorische, wirtschaftliche, terminliche Machbarkeit) und ein Vergleich von Architektur-Alternativen (Trade-off) durchgeführt. Zur Bewertung der Architekturqualität anhand von Attributen (z. B. Leistung, Skalierbarkeit, Modifizierbarkeit) werden Methoden wie ATAM (Architecture Tradeoff Analysis Method) eingesetzt.[11][12] Die Wahl zwischen beispielsweise einer monolithischen und einer Microservices-Architektur [3] basiert auf expliziten Kompromissen (Betriebskomplexität vs. unabhängige Skalierbarkeit und Liefergeschwindigkeit) gemäß den Empfehlungen von Branchenleitfäden.[13][14]
  • Erstellung von Projektartefakten. Basierend auf der Analyse werden folgende Dokumente erstellt:
    • eine genehmigte Anforderungsspezifikation (mit Angabe der Wichtigkeit),
    • ein konzeptionelles Modell des Systems (Diagramme/Beschreibungen),
    • Architektur- und Entwurfsentscheidungen (Datenschemata, Schnittstellen zu externen Systemen),
    • ein Implementierungsplan (Phasen/Module).
    • Entscheidend ist die Sicherstellung der Nachverfolgbarkeit (bidirectional traceability) von Anforderungen zu Designelementen und Tests.[15][4]

Der Erfolg eines IT-Projekts hängt maßgeblich von ausgereiften Praktiken im Umgang mit Anforderungen und Architektur ab. Eine von McKinsey und Oxford durchgeführte Studie zeigte, dass große IT-Projekte häufig Budget und Zeitplan überschreiten. Diese Studie betonte auch, wie wichtig es ist, die Strategie richtig zu managen, mit den Stakeholdern zu interagieren und die Anforderungen kompetent zu erheben. All dies kann den Erfolg oder Misserfolg eines Projekts stark beeinflussen.[16]

Ansätze und Methodologien in der IT-Systemanalyse

Die Systemanalyse in der IT stützt sich auf die Prinzipien des Systemdenkens und auf für die Softwareentwicklung angepasste Methoden. In der Praxis werden „harte“ und „weiche“ Ansätze, strukturierte Methodologien, objektorientierte Notationen sowie Sprachen zur Modellierung von Prozessen und Anforderungen kombiniert.

  • Harter und weicher Ansatz. In IT-Projekten geht der harte Ansatz (hard systems) von vorab formalisierbaren Zielen und Anforderungen, einer Dekomposition und einem Top-Down-Entwurf aus. Der weiche Ansatz (soft systems) wird bei unklaren Zielen und mehreren Sichtweisen angewendet: Es werden Elemente der Soft Systems Methodology (SSM) (z. B. Rich Picture, Root Definitions, CATWOE) verwendet, um ein gemeinsames Verständnis des Problems und der gewünschten Änderungen zu erzielen; die Ergebnisse werden anschließend in formale Anforderungen überführt.[17][18]
  • SSM-Methodologie (Soft Systems Methodology). Ursprünglich von Peter Checkland für organisatorische Veränderungen entwickelt, ist SSM in den Vorphasen von IT-Projekten nützlich: von der Untersuchung der Problemsituation und der Formulierung von Root Definitions (u. a. durch CATWOE) bis zum Vergleich konzeptioneller Modelle mit der Realität und dem Erreichen einer Akkommodation zwischen den Stakeholdern.[19][20]
  • Strukturierte Methodologien: SADT/IDEF0. SADT modelliert ein System als Hierarchie von Funktionen; die Standardnotation IDEF0 (IEEE 1320.1) erfasst Funktionen und ihre I-C-O-M-Schnittstellen (Inputs, Controls, Outputs, Mechanisms). Die Methode eignet sich gut für die funktionale Dekomposition und die Abstimmung von Systemgrenzen, unabhängig von den Algorithmen.[21][22]
  • Objektorientierte Analyse: UML und SysML (MBSE). UML ist zur Basissprache für Anforderungen und Design geworden (Anwendungsfall-, Klassen-, Sequenzdiagramme usw.) und erleichtert die Validierung von Szenarien mit Benutzern; SysML erweitert UML für das Systems Engineering (Anforderungsdiagramme, parametrische Diagramme) und basiert auf dem MBSE-Ansatz, bei dem das Modell das zentrale Artefakt über alle Phasen von den Anforderungen bis zu den Tests hinweg ist.[23][24][25]
  • Modellierung von Geschäftsprozessen: BPMN. Der BPMN-Standard wird zur grafischen Beschreibung von Prozessen verwendet (Pools, Arbeitsabläufe, Ereignisse, Gateways), einschließlich des Vergleichs von As-is/To-be in Anforderungsspezifikationen und Integrationen.[26][27]
  • Beziehung zum Requirements Engineering. Der Prozess umfasst die Phasen Elicitation–Analysis–Specification–Validation–Change Management; die Kriterien für eine „gute Anforderung“ und die Struktur der SRS sind in der ISO/IEC/IEEE 29148 geregelt. Zur Priorisierung werden Techniken wie MoSCoW (Must/Should/Could/Won’t) und multikriterielle Auswahlverfahren wie AHP eingesetzt. In agilen Prozessen spiegelt sich die Tätigkeit der Systemanalyse im Backlog Refinement und der Nachverfolgbarkeit von Anforderungen wider.[28][29][30][31]
  • Beziehung zum Systems Engineering. Bei komplexen (cyber-physischen) Systemen wird das V-Modell angewendet: Auf dem „linken“ Zweig befinden sich Systemanalyse und Architektur, auf dem „rechten“ Zweig Integration, Verifizierung und Validierung mit Anbindung an die Artefakte des linken Zweigs. Zu den Methoden zur Bewertung der Architektur anhand von Qualitätsattributen gehört ATAM (Trade-off-Analyse).[32][33]

Die Systemanalyse in der IT kombiniert bewährte Ansätze – von weichen Methoden zur Visionsabstimmung bis hin zu formalen Notationen und Standards. Die Wahl der Werkzeuge hängt vom Grad der Bestimmtheit der Aufgabe ab: Bei hoher Unsicherheit steigt die Bedeutung von SSM und Moderation, bei klaren Grenzen die von formalen Modellen (UML/SysML, IDEF0, BPMN) und Regelwerken.

Beziehung zur IT-Architektur und Unternehmensarchitektur

Die Systemanalyse in IT-Projekten ist eng mit dem Architekturentwurf verbunden. Die Rollen des Analytikers und des Architekten überschneiden sich: Der Analytiker formuliert die Anforderungen und das logische Modell, der Architekt bestimmt die Zielstruktur der Lösung und die technischen Kompromisse; die Arbeit erfolgt gemeinsam.

  • Architektur von IT-Systemen. Im engeren Sinne ist die Softwarearchitektur die Organisation von Komponenten, ihre Beziehungen und die Prinzipien, die dem Entwurf der Lösung zugrunde liegen. Für den Analytiker ist es wichtig, Architekturstile (Schichtenarchitektur, Client-Server, Microservices, ereignisgesteuert usw.) zu berücksichtigen, da nichtfunktionale Anforderungen (Zuverlässigkeit, Skalierbarkeit, Modifizierbarkeit) oft die Architekturentscheidungen und ihre Kompromisse bestimmen.[34][35] In einer frühen Analysephase werden eine Architekturvision (High-Level Vision) und ein grober Lösungsentwurf erarbeitet, um die Umsetzbarkeit der Anforderungen zu prüfen (die Länge der Iterationen und der Detaillierungsgrad hängen von der Methodik ab).[36]
  • Muster und vorläufige Entscheidungen. Um nichtfunktionale Anforderungen zu erfüllen, werden Architekturmuster (Architectural Patterns) eingesetzt. Zum Beispiel für asynchrone Interaktion und lose Kopplung wird Publish-Subscribe über einen Message Broker in einer ereignisgesteuerten Architektur verwendet.[37]
  • TOGAF (The Open Group Architecture Framework). Eines der am weitesten verbreiteten Frameworks für Unternehmensarchitektur; es umfasst die ADM-Methode (Architecture Development Method) und Artefakte zur Architekturverwaltung (Repository, Kataloge/Matrizen, Prinzipien). In TOGAF ist das Anforderungsmanagement ein durchgängiger Prozess, der in alle Phasen der ADM integriert ist.[36] Zur Unterstützung von Anforderungen und Nachverfolgbarkeit werden Kataloge und Matrizen verwendet (z. B. Anforderungen ↔ Services, Funktionen ↔ Komponenten), und es wird zwischen Architecture Building Blocks und Solution Building Blocks unterschieden.[38][39] Unternehmensprinzipien und -standards werden in entsprechenden Katalogen festgehalten und dienen als externe nichtfunktionale Anforderungen für Projektteams.[40] Die Übereinstimmung der Lösungen mit der Zielarchitektur wird durch ein Architecture Compliance Review bestätigt.[41] Der TOGAF-Ansatz sieht eine vorläufige Architecture Vision und eine anschließende Detaillierung (Daten/Anwendungen/Technologien) mit einem Migrationsplan und der Verwaltung von Anforderungsänderungen vor.[42][43]
  • Zachman Framework. Eine frühe und einflussreiche Ontologie für Artefakte der Unternehmensarchitektur, dargestellt als 6×6-Matrix (Perspektiven × Aspekte „Was/Wie/Wo/Wer/Wann/Warum“). Die Zeile „Designer“ korrespondiert mit der Systemanalyse und dem Entwurf; die Spalten geben die Vollständigkeit der Betrachtung von Daten, Funktionen/Prozessen, Rollen, Standorten und Motivation vor. Das Framework dient als Klassifikation (nicht als Methodik) und hilft, die Vollständigkeit der Lösungsbeschreibung in der Unternehmenslandschaft sicherzustellen.[44]
  • Beziehung zur Unternehmensarchitektur (Enterprise Architecture, EA). Der Systemanalytiker arbeitet im Kontext der EA: Neue Anforderungen werden auf Geschäftsfähigkeiten und das Betriebsmodell zurückgeführt; es werden Standards und grundlegende Unternehmenseinschränkungen (Sicherheit, Kompatibilität usw.) angewendet.[45][36] In der Initiierungsphase wird eine Architecture Vision (Ziele/Einschränkungen, grobe Anforderungen) formuliert, die der Analytiker anschließend detailliert, wobei die Nachverfolgbarkeit zur Vision und zu den Unternehmensstandards gewahrt bleibt; die Nichteinhaltung von Standards wird bei Architektur-Reviews aufgedeckt und kann zu Nachbesserungen der Lösung führen.[36][46]

Zusammenfassend lässt sich sagen: Systemanalyse und Architekturentwurf bilden eine Kette von „Anforderungen → Architekturentscheidungen → Kompromisse bei Qualitätsattributen“. Die Wahl der Methoden (Stile/Muster, TOGAF-Artefakte, Zachman-Klassifikation) wird durch die Art des Projekts und den Rahmen der Unternehmensarchitektur bestimmt.

Prozesse und Praktiken

Die Systemanalyse ist in den gesamten Lebenszyklus der Softwareentwicklung und des Betriebs integriert und verbindet Geschäftsziele, Architektur und Auslieferung. Sie umfasst die Vorphasenuntersuchung, die Wahl des Ansatzes, die Erstellung überprüfbarer Artefakte und die Anforderungen an Zuverlässigkeit, Leistung, Sicherheit und Wartung. Im Wasserfallmodell wird die Analyse vor dem Entwurf und der Implementierung durchgeführt, in agilen Methoden kontinuierlich in Iterationen, und in DevOps mit einem Schwerpunkt auf betrieblichen Zielen. Unabhängig vom Ansatz gewährleistet die Analyse die Nachverfolgbarkeit, das Änderungs- und Risikomanagement, die Dokumentation von Architekturkompromissen und die Einhaltung regulatorischer Beschränkungen, was die Entwicklung vorhersagbar und steuerbar macht.

  • Klassischer SDLC (Wasserfall). Die Phase der Systemanalyse & Anforderungsdefinition geht dem Entwurf und der Implementierung voraus; die Anforderungen werden in einer detaillierten SRS als Grundlage für Planung und Verträge festgelegt. Dieser Ansatz ist in stabilen und regulierten Domänen effektiv; die Risiken des „Einfrierens“ von Anforderungen werden durch SRR/Reviews und das Änderungsmanagement über ein CCB reduziert.[47][48][49]
  • Agile Methodologien (Agile). Die Analyse ist kontinuierlich: Anstelle einer endgültigen SRS wird ein Product Backlog aus User Stories mit Akzeptanzkriterien geführt, der im Backlog Refinement verfeinert wird; es wird BDD (Given–When–Then) angewendet; das Risiko des Verlusts einer kohärenten Architektur wird durch eine frühe Architekturerarbeitung und transparente Nachverfolgbarkeit von Anforderungen ↔ Implementierung/Tests kompensiert.[50][51][52]
  • DevOps und SRE. Häufige Releases erfordern betriebliche Anforderungen „by default“: Automatisierung, Beobachtbarkeit, Rollback. Nichtfunktionale Anforderungen werden als SLO/SLI formuliert, und das Error Budget wird verwaltet; dem Backlog werden Aufgaben für Logs/Metriken/Traces/Alerts hinzugefügt; für Releases ohne Ausfallzeit werden Muster wie Blue/Green und andere verwendet.[53][54][55]
  • Anforderungs- und Risikomanagement. Anforderungen in einem ALM haben Status und Verbindungen zu Aufgaben/Releases/Defekten; Versionskontrolle, Change Impact Analysis und regelmäßige Neupriorisierung sind obligatorisch.[56][57]
  • Qualitätssicherung (QS). Qualität wird bereits in der Anforderungsphase verankert: Reviews, „Three Amigos“, ein Acceptance Test Plan, automatisierte Tests der Akzeptanzkriterien (BDD/ATDD).[58][59]
  • Beobachtbarkeit und Zuverlässigkeit. In die Anforderungen werden SLA/SLO, MTTR und MTBF mit messbaren Zielen und Kontrollmethoden aufgenommen; die Parameter stammen aus dem Business/Betrieb und fließen in die Architektur und Zuverlässigkeitstests ein.[60][61]

Metriken und Qualität der Artefakte

Zur Bewertung der Arbeit eines Systemanalytikers und der Qualität seiner Ergebnisse werden allgemein anerkannte Kriterien herangezogen. Qualitativ hochwertige Anforderungen und Modelle sind die Grundlage für ein erfolgreiches Projekt und werden daher über den gesamten Lebenszyklus verwaltet (elicitation → specification → verification/validation → change management). Die grundlegenden Qualitätsattribute von Anforderungen sind in den Standards ISO/IEC/IEEE 29148 und (historisch) IEEE 830 festgelegt.[3][62][1]

  • Korrektheit (Correctness) – die Anforderung spiegelt einen echten Bedarf wider und ist mit Fachexperten abgestimmt; sie wird durch Validierung bestätigt (Review/Inspection, Prototypen, Szenarien).[1][4]
  • Vollständigkeit (Completeness) – wesentliche Aspekte und Bedingungen sind berücksichtigt.
    • Vollständigkeit einer einzelnen Anforderung: Notwendige Details sind angegeben (z. B. „der Indikator wechselt bei einem Ausfall in den Status rot“ und nicht nur „wird rot“).
    • Vollständigkeit der Spezifikation: Szenarien/Rollen sind abgedeckt, NFRs sind definiert; dies wird durch Checklisten und die Nachverfolgbarkeit zu Geschäftszielen erreicht; ein unabhängiges Audit der Vollständigkeit (QS/Review) ist nützlich.[3][63]
  • Eindeutigkeit (Unambiguity) – Formulierungen werden nur auf eine Weise interpretiert; dabei helfen ein Glossar, Vorlagen wie „das System soll A tun, wenn B, falls C“ und Beispiele; Diagramme werden mit einer Legende versehen. Überprüfung erfolgt nach dem Vier-Augen-Prinzip.[3][1]
  • Widerspruchsfreiheit (Consistency) – Anforderungen widersprechen weder einander noch externen Einschränkungen; dies wird durch Strukturierung, zusammenfassende Attributtabellen, Team-Reviews und die Überprüfung von Vorschriften/Standards erreicht.[3][63]
  • Überprüfbarkeit/Testbarkeit (Verifiability) – die Erreichung wird durch einen Test/eine Demonstration/eine Analyse bestätigt; nicht überprüfbare Formulierungen werden durch messbare Kriterien ersetzt; für NFRs werden Metriken festgelegt und Akzeptanzkriterien im Voraus definiert.[3][63]
  • Änderbarkeit und Nachverfolgbarkeit (Modifiability & Traceability) – eindeutige IDs, eine logische Struktur („ein Gedanke – ein Absatz“), keine Duplikate; Verbindungen „Anforderung ↔ Quelle/Ziel/Design/Test“ werden gepflegt, eine Traceability-Matrix (RTM) wird geführt.[64][3]
  • Rangordnung und Priorisierung – eine Qualität des Anforderungssatzes; es werden Techniken wie MoSCoW und MCDM (z. B. AHP) verwendet; die Priorisierung gemeinsam mit dem Business beeinflusst die Planung und die Risiken.[65][66]

Metriken für die Anforderungsqualität (Beispiele):[63][1]

  • Dichte der Anforderungsdefekte (Anmerkungen pro 100 Anforderungen);
  • Anzahl der Änderungen nach der Baseline-Fixierung;
  • Coverage-Metriken: Anteil der Anforderungen mit Tests; Anteil der Anforderungen, die auf Geschäftsziele zurückführbar sind;
  • Stabilität der Anforderungen (Verhältnis von hinzugefügten/entfernten zur Gesamtzahl über einen Zeitraum);
  • Größe/Komplexität der Spezifikation (durchschnittliche Anzahl der Anforderungen pro Anwendungsfall, Tiefe der Dekomposition);
  • Zufriedenheit der Stakeholder (Umfrage).

In reifen Prozessen (z. B. CMMI Level 3+) gibt es Qualitätsrichtlinien für Anforderungen: formale Überprüfungen, Audits der Konformität mit Vorlagen, Erfassung/Analyse von Metriken.[67] In kritischen Domänen (Avionik, Raumfahrt usw.) werden formale Methoden zur Erhöhung der Zuverlässigkeit eingesetzt.[68]

Typische Fehler

In IT-Projekten treten häufig Fehler in der Systemanalyse auf: unvollständige und mehrdeutige Anforderungen, Widersprüche, unklare Abgrenzungen, die Vernachlässigung nichtfunktionaler Aspekte, vergessene Integrationen und verspätete Sicherheitsüberlegungen. Dies führt zu Nacharbeiten, Verzögerungen, Kostensteigerungen und Fehlern.

Typische Probleme, ihre Folgen und wie man sie verhindert.

  • Unvollständigkeit und übersehene Anforderungen. Rollen mit besonderen Rechten, Grenzfälle und NFRs werden übersehen. Folgen: Überarbeitung der Architektur und Verschiebung des Starts. Wie man es vermeidet: Checklisten, Brainstorming-Sitzungen zu „Was wäre wenn…“, frühzeitige Einbeziehung von Testern, Nachverfolgbarkeit zu Geschäftszielen.[1][69]
  • Unklare, mehrdeutige Formulierungen. Folgen: Entwickler implementieren „das Falsche“, der Kunde ist unzufrieden. Wie man es vermeidet: messbare Kriterien, ein Glossar, Vorlagen wie „A, wenn B, falls C“, Peer-Reviews.[3][69]
  • Widersprüchliche Anforderungen. Folgen: Verzögerungen durch Klärungsbedarf, Nacharbeiten bei der Integration. Wie man es vermeidet: Strukturierung, Abgleich mit Geschäftsregeln/Vorschriften, Sitzungen zur Konfliktlösung, Überprüfung der Konsistenz in Reviews.[3][1]
  • „Gold Plating“-Syndrom. Folgen: Zunahme des Umfangs, Komplexität, neue Fehlerquellen. Wie man es vermeidet: Jede Anforderung an ein Ziel/eine Metrik binden; in agilen Methoden nichts Überflüssiges ins Backlog aufnehmen; den Scope festlegen; siehe YAGNI.
  • Übermäßige Detaillierung, wo sie nicht benötigt wird. Wie man es vermeidet: Was/Warum (Anforderungen) von Wie (Design/Implementierung) trennen; wo angebracht, design-free requirements anwenden.[3]
  • Verletzung der Steuerbarkeit von Anforderungen. Folgen: Versionschaos, Implementierung des „Falschen“. Wie man es vermeidet: Eine einzige Wahrheitsquelle im ALM, Historisierung und Status, RTM und Change Impact Analysis; Änderungsmanagement über ein CCB.[64][1]
  • Fehlende Beteiligung der Benutzer. Wie man es vermeidet: Interviews, Beobachtungen, Prototypen, regelmäßige Demos; explizite Validierung mit Stakeholdern.[3][1]
  • Zu lange „Analyse-Paralyse“. Wie man es vermeidet: Prinzip der Genügsamkeit, Iterativität und Timeboxing; Start eines MVP/Inkrements und Anpassung basierend auf Feedback.[1]
  • Ignorieren nichtfunktionaler Anforderungen. Wie man es vermeidet: NFRs explizit behandeln (z. B. nach FURPS+), messbare Kriterien definieren, sie in den Testplan und die Architekturentscheidungen einbeziehen.[1][3]
  • Kommunikationsfehler und der „menschliche Faktor“. Wie man damit umgeht: Interview- und Moderationsfähigkeiten entwickeln, Neutralität wahren, Entscheidungen und Anforderungsquellen festhalten (Nachverfolgbarkeit zu Zielen).[1]

Die meisten Probleme lassen sich auf die Qualität der Formulierungen, die Vollständigkeit und die Steuerbarkeit der Anforderungen zurückführen; die Anwendung von Standards wie ISO/IEC/IEEE 29148 und Praktiken aus dem SWEBOK (Validierbarkeit, Nachverfolgbarkeit, Iterativität) reduziert das Risiko von Terminüberschreitungen und Nacharbeiten erheblich.[3][1]

Grenzen und Einschränkungen

Obwohl die Systemanalyse effektiv zur Reduzierung von Unsicherheiten beiträgt, hat sie ihre Grenzen:

  • Die Realität ist veränderlich und komplex. Es ist unmöglich, alle Faktoren zu berücksichtigen, insbesondere bei langfristigen Projekten. Einige Anforderungen werden unweigerlich erst nach dem Start des Systems bekannt. Es ist wichtig, Überraschungen zu minimieren, aber man muss auf Änderungen vorbereitet sein.
  • Anforderungen hängen von Menschen ab. Geschäftsprioritäten, Gesetze und der Markt können sich ändern. Die Systemanalyse erfasst den aktuellen Zustand und kann nicht alle externen Veränderungen vorhersagen. Um sich anzupassen, müssen die Anforderungen regelmäßig aktualisiert und iterativ bearbeitet werden.
  • Benutzer wissen nicht immer, was sie wollen, bis sie es sehen. Dies ist eine bekannte Einschränkung. Prototyping und agile Methoden wie Agile helfen, dieses Problem zu überwinden. Die Analyse auf dem Papier hat ihre Grenzen, und für genaue Daten ist Feedback aus Implementierungen erforderlich.
  • Balance zwischen Zeit und Qualität. Eine übermäßig detaillierte Analyse kann veraltet sein. In innovativen Bereichen ist es besser, schnell ein Minimum Viable Product (MVP) zu erstellen und reale Daten zu sammeln. Die Systemanalyse ist in stabilen Bereichen effektiv, aber in Forschungsprojekten (F&E) ist ihre Rolle begrenzt.
  • Der menschliche Faktor. Selbst die besten Methoden können die Inkompetenz eines Analytikers oder die Nichtverfügbarkeit eines Kunden nicht ausgleichen. Es ist wichtig, dass alle Prozessbeteiligten engagiert und motiviert sind.

Einfluss moderner Technologien auf die Systemanalyse in der IT

Die Systemanalyse in der IT entwickelt sich ständig unter dem Einfluss technologischer Innovationen weiter. Der Analytiker des 21. Jahrhunderts arbeitet unter Bedingungen eines explosiven Datenwachstums, der allgegenwärtigen Einführung von KI, schneller Entwicklungszyklen und erhöhter Aufmerksamkeit für Sicherheit. Eine erfolgreiche Praxis der Systemanalyse erfordert die Aneignung neuen Wissens (Data Science, Cybersicherheit, Cloud-Technologien) und Flexibilität bei der Anwendung von Methoden.

  • Daten und AI/ML: Was zur Analyse hinzukommt. Für Systeme mit KI werden bereits zu Beginn Ziele und Anwendungskontext, Anforderungen an Datenquellen und -qualität sowie Metriken für das Vertrauen in die Modellentscheidungen (Zuverlässigkeit, Sicherheit, Erklärbarkeit, Vertraulichkeit, Fairness) festgelegt. Es werden Prüfungen nach TEVV (Testing, Evaluation, Verification, Validation), die Überwachung im Betrieb und die sichere Abschaltung/Außerbetriebnahme des Modells geplant. Diese Schritte entsprechen den Funktionen GOVERN–MAP–MEASURE–MANAGE aus dem NIST-Framework für das KI-Risikomanagement; sie werden in der SRS, der Architektur und den Verifikations-/Betriebsplänen berücksichtigt.[70]
  • DevSecOps: Sicherheit „von links“ und standardmäßig. Die Integration von Sicherheit in jede Phase der CI/CD-Pipeline wird zur Norm: automatische Prüfungen (SAST/DAST), Scannen von Abhängigkeiten und Containern, Deployment-Richtlinien, grundlegende Beobachtbarkeit. Es werden vertrauenswürdige Artefakt-Register und standardisierte „gehärtete“ Images verwendet; es werden Zero-Trust-Prinzipien angewendet. In der Systemanalyse werden im Voraus die Kontrollpunkte der Pipeline (Bedingungen für das Passieren der Phasen), die Verbindung von Anforderungen mit Sicherheitskontrollen und die Regeln für den Übergang zwischen Umgebungen (dev/test/stage/prod) beschrieben.[71]
  • Was sich in den Dokumenten (Artefakten) ändert. Welcher Abschnitt in den Schlüsseldokumenten bei Big Data und AI/ML sowie bei der Arbeit nach DevSecOps hinzukommt oder präzisiert wird:
    • SRS / Anforderungsspezifikation: Ziele und Anwendungskontext der KI; Anforderungen an Daten (Herkunft, Qualität, ethische und rechtliche Beschränkungen); Modellmetriken (Genauigkeit, Zuverlässigkeit, Antwortzeit); TEVV-Plan (Testing, Evaluation, Verification, Validation); Anforderungen an Transparenz/Erklärbarkeit und Datenschutz; Kriterien für die Abschaltung/Außerbetriebnahme des Modells.[70]
    • Architektur und Entscheidungen (Architecture, ADR): Ergebnisse der Bedrohungsmodellierung; Maßnahmen für „Sicherheit by Default“ (Verschlüsselung, Zugriffskontrolle, Secret-Management, Prinzip der geringsten Privilegien); Einschränkungen bei der Nutzung von Daten/Modellen; ADR-Einträge mit Risikobewertung und Kompromissen.[71][70]
    • Verifikations- und Validierungsplan (V&V / TEVV): Testszenarien für Modelle und Daten; Akzeptanzschwellen für Qualitätsmetriken; Überwachung von Daten-/Modelldrift; Verfahren zur periodischen Neubewertung und erneuten Validierung.[70]
    • CI/CD-Richtlinien und Pipeline-„Gates“: Automatische Prüfungen SAST/DAST, SCA (Abhängigkeiten), Container-Scans; Signierung und Speicherung von Artefakten in vertrauenswürdigen Registern; Regeln für die Beförderung zwischen Umgebungen (dev/test/stage/prod) und Bedingungen für das Blockieren eines Builds bei fehlgeschlagenen Prüfungen; Anforderungen an die standardmäßige Beobachtbarkeit.[71]
    • Daten- und Modellverwaltungsplan: Quellenkatalog und Lineage; Kriterien für Datenqualität und -verfügbarkeit; Versionen von Datensätzen/Modellen; Zeitplan für (Nach-)Training und Kontrolle von Bias; Zugriffs- und Speicherrichtlinien; Plan zur sicheren Deaktivierung des Modells und Löschung von Daten, falls erforderlich.[70]
    • Betrieb und Beobachtbarkeit (Ops/Runbook): KI-Vertrauensmetriken und SLOs; Auditierung und Protokollierung; Alarme bei Degradation/Anomalien; Incident-Response-Plan; Fallback/Kill-Switch für KI-Komponenten; Anforderungen an das Reporting und die Post-Incident-Analyse.[70][71]
    • Nachverfolgbarkeit (end‑to‑end): Explizite Verbindungen „Anforderung ↔ Kontrolle/Prüfung in der Pipeline“ und „Anforderung ↔ Test/Überwachung im Betrieb“, um Sicherheit und Qualität über den gesamten Lebenszyklus nachweisbar überprüfen zu können.[71][70]
  • Rolle des Systemanalytikers.
    • verwaltet den Kontext und die Risiken der KI (Akteure, Anwendungsszenarien, Annahmen und Datenbeschränkungen);
    • stellt die Nachverfolgbarkeit von „Anforderung ↔ Sicherheitskontrolle in der Pipeline“ sicher;
    • formuliert überprüfbare nichtfunktionale Anforderungen (Sicherheit, Transparenz, Beobachtbarkeit) über den gesamten Lebenszyklus des Systems.[70][71]

Unterschiede zur klassischen Systemanalyse

Der Begriff „Systemanalyse“ ist historisch breiter als die Softwareentwicklung. Die klassische Systemanalyse ist ein Ansatz zur Lösung komplexer, interdisziplinärer Probleme (sozial, wirtschaftlich, managementbezogen), der auf Systemdenken und quantitativen Methoden basiert, typischerweise zur Unterstützung von Managemententscheidungen. In der IT versteht man unter Systemanalyse eine angewandte Disziplin im Bereich des Software-Engineerings, die auf die Erstellung von Informationssystemen ausgerichtet ist.

Nachfolgend die wesentlichen Unterschiede.

  • Ziele und Analyseobjekt. Die klassische Analyse löst schlecht strukturierte, „schwammige“ Probleme und verbessert bereits existierende soziotechnische Systeme (städtisches Verkehrsnetz, Unternehmensstrategie, Umweltpolitik). Das Objekt ist ein reales System; die Aufgabe besteht darin, Entscheidungsträgern bei der Wahl einer Vorgehensweise zu helfen. Für die Systemanalyse in der IT ist das Ziel, ein neues Informationssystem oder Softwareprodukt zu entwerfen und zu erstellen, das den Anforderungen entspricht. Das Objekt ist das zu entwerfende System; der Fokus liegt auf dem Verhalten und den Eigenschaften, die die Benutzer benötigen.
  • Methodische Grundlagen. Klassische Schulen stützen sich auf Systemdenken und oft auf Mathematik. Der harte Ansatz (hard systems) umfasst die Formalisierung des Problems, quantitative Kriterien und Optimierung (wie im Operations Research). Weiche Methodologien (soft systems) erkennen die Vielfalt der Standpunkte an; ein Beispiel ist die Soft Systems Methodology (SSM), bei der durch Diskussionen und konzeptionelle Modelle gewünschte Änderungen abgestimmt werden. In der IT bilden Ingenieurdisziplinen die Grundlage: Requirements Engineering, Softwareentwurf, Architektur-Frameworks. Es werden standardisierte Prozesse (ISO/IEC/IEEE 15288, 12207, 29148), UML/SysML-Notationen und Praktiken des Änderungsmanagements angewendet.
  • Rollen und Artefakte. In der klassischen Analyse ist die Rolle des „Systemanalytikers“ oft informell; die Ergebnisse sind ein Analysebericht, Empfehlungen, mathematische Modelle, „Was-wäre-wenn“-Szenarien. In der IT ist die Rolle des Analytikers (oder Business-Analytikers) formalisiert; es werden Anforderungsspezifikationen, Systemmodelle (UML, ER), Schnittstellenspezifikationen, User Stories und ein Backlog erstellt – Artefakte, die direkt von Entwicklern und Testern verwendet werden.
  • Lebenszyklus und Prozess. Die klassische Analyse hat keine einheitliche Vorlage: Die Schritte hängen vom Problem ab (in SSM – von der Untersuchung der Situation bis zur Umsetzung von Änderungen). In der IT sind Standard-SDLC-Zyklen üblich: Im Wasserfallmodell gibt es eine separate Phase der Anforderungsanalyse; in iterativen und agilen Ansätzen ist die Analyse eine kontinuierliche Tätigkeit in jedem Sprint. Moderne Praktiken (DevOps, CI/CD) erweitern den Rahmen der Analyse auf den Betrieb: Anforderungen an Wartung, Beobachtbarkeit und Aktualisierbarkeit werden berücksichtigt. Mit anderen Worten, die Systemanalyse in der IT ist in den Entwicklungslebenszyklus eingebettet, während die klassische Analyse häufiger als Projekt- oder Beratungstätigkeit durchgeführt wird.

Der Systemanalytiker

Der Systemanalytiker in der IT ist ein Spezialist, der für das systemische Denken bei der Konzeption und Entwicklung von Informationssystemen verantwortlich ist: Erstellung und Validierung von Anforderungen, Modellierung (UML/BPMN), Abstimmung von Architekturentscheidungen und Sicherstellung der Integration. Rolle und Qualifikationsanforderungen sind in der Russischen Föderation in einem Berufsstandard und in staatlichen Bildungsstandards (FGOS) verankert.

Hauptziel des Berufsfeldes: Sicherstellung der Übereinstimmung eines IT-Services, eines automatisierten Systems, eines automatisierten Informationssystems, eines automatisierten Steuerungssystems, eines Software-, Informationsprodukts oder -mittels (im Folgenden als System bezeichnet) mit der Umgebung, den ursprünglichen Anforderungen und Einschränkungen, den Automatisierungszielen und der automatisierten Tätigkeit durch die Entwicklung und Übergabe qualitativ hochwertiger und miteinander verknüpfter Projektlösungen an die interessierten Parteien bei der Initiierung und Koordination der Arbeiten einzelner Ausführender über den gesamten Lebenszyklus des Systems (Berufsstandard „Systemanalytiker“ (Verordnung des Arbeitsministeriums der Russischen Föderation vom 27.04.2023 Nr. 367n).[72]

Glossar der Schlüsselbegriffe

Grundbegriffe und Beteiligte

  • Systemanalyse in der IT – Eine Disziplin, deren Gegenstand das Informationssystem über seinen gesamten Lebenszyklus ist, von der Konzeption bis zum Betrieb.
  • Stakeholder – Personen oder Gruppen, die am Projekt interessiert oder davon betroffen sind (Kunden, Benutzer, Manager).
  • Projektartefakte – Dokumente und Ergebnisse, die im Laufe eines Projekts erstellt werden, wie Spezifikationen, Modelle, Pläne und Entscheidungen.

Anforderungen: Arten und Dokumentation

  • Funktionale Anforderungen – Beschreiben, was das System tun soll; seine Funktionen und sein Verhalten.
  • Nichtfunktionale Anforderungen – Beschreiben die Qualitätsmerkmale eines Systems (Zuverlässigkeit, Leistung, Sicherheit, Benutzerfreundlichkeit, Skalierbarkeit usw.).
  • Anforderungsspezifikation (erste) – Ein Dokument, das den ursprünglichen Satz von Anforderungen enthält, die in den Anfangsphasen des Projekts gesammelt wurden.
  • SRS (Software Requirements Specification) – Ein standardisiertes Dokument, das die Anforderungen an die Software gemäß internationalen Standards (z. B. ISO/IEC/IEEE 29148) detailliert beschreibt.
  • URS (User Requirements Specification) – Ein Dokument, das die Anforderungen des Benutzers an das System aus Sicht der Geschäftsprozesse und der Erwartungen des Endbenutzers beschreibt.
  • Architekturrelevante Anforderungen (ASR) – Anforderungen, die Architekturentscheidungen und Kompromisse wesentlich beeinflussen.
  • Cross-funktionale Anforderungen (CFR) – Ein Synonym für nichtfunktionale Anforderungen, das ihren übergreifenden Charakter betont.
  • Akzeptanzkriterien (Acceptance Criteria) – Überprüfbare Bedingungen, bei deren Erfüllung die Arbeit an einer Anforderung als akzeptiert gilt.
  • Definition of Ready (DoR) – Eine Vereinbarung über die Bereitschaft eines Backlog-Elements für die Entwicklung (Klarheit, Schätzung, Kriterien).
  • Definition of Done (DoD) – Eine Vereinbarung über die „Fertigstellung“ einer Arbeit (Code, Tests, Dokumentation, Bereitstellung).
  • Einschränkung (Constraint) – Eine starre Bedingung, die Lösungsoptionen einschränkt (Termine, Plattformen, Standards, Lizenzen).
  • Annahme (Assumption) – Eine Vermutung, die ohne Beweis akzeptiert wird und einer späteren Validierung bedarf.
  • Anforderungsqualität – Eigenschaften gemäß ISO 29148: Eindeutigkeit, Vollständigkeit, Widerspruchsfreiheit, Überprüfbarkeit, Atomarität.

Formalisierung, Nachverfolgbarkeit und Priorisierung von Anforderungen

  • Formalisierung von Anforderungen – Der Prozess der Umwandlung informeller Anfragen in klare, überprüfbare und eindeutige Anforderungen.
  • Nachverfolgbarkeit von Anforderungen – Die Fähigkeit, den Lebenszyklus einer Anforderung von ihrer Quelle bis zur Implementierung, zum Testen und zur Bereitstellung zu verfolgen.
  • Bidirectional traceability (bidirektionale Nachverfolgbarkeit) – Die Fähigkeit, die Verbindungen zwischen Anforderungen, Designelementen und Testszenarien sowohl in vorwärts- als auch in rückwärtsgerichteter Richtung zu verfolgen.
  • MoSCoW – Eine Technik zur Priorisierung von Anforderungen, die sie als Must-have (muss sein), Should-have (sollte sein), Could-have (könnte sein) und Won't-have (wird nicht sein) klassifiziert.
  • BDD (Behavior-Driven Development) – Eine Entwicklungsmethodik, bei der Tests in einer natürlichen Sprache verfasst werden, die sich auf das Verhalten des Systems aus der Sicht des Benutzers konzentriert (Format: Given–When–Then).

Notationen und Modellierung

  • UML (Unified Modeling Language) – Eine standardisierte grafische Modellierungssprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Komponenten von Softwaresystemen.
  • SysML (Systems Modeling Language) – Eine Erweiterung von UML für das Systems Engineering, die die Modellierung verschiedener Aspekte komplexer Systeme unterstützt, einschließlich Anforderungen, Verhalten, Struktur und Parametern.
  • BPMN (Business Process Model and Notation) – Ein Standard für die grafische Notation zur Beschreibung von Geschäftsprozessen, der die Visualisierung von Arbeitsabläufen, Ereignissen, Gateways und Pools ermöglicht.
  • MBSE (Model-Based Systems Engineering) – Ein Ansatz im Systems Engineering, bei dem das Modell das zentrale Artefakt in allen Phasen des Systemlebenszyklus ist, von den Anforderungen bis zum Testen.
  • ArchiMate – Eine Notation für die Unternehmensarchitektur (Geschäft, Anwendungen, Technologien) und ihre Beziehungen.
  • DMN (Decision Model and Notation) – Modellierung von Geschäftsentscheidungen und Regeltabellen.
  • DFD (Data Flow Diagram) – Datenflussdiagramme (Kontext, Dekompositionsebenen).
  • ERD (Entity-Relationship Diagram) – Ein Modell der Fachdomäne mit Entitäten, Beziehungen und Attributen.
  • CRUD-Matrix – Zuordnung von Create/Read/Update/Delete-Operationen zu Entitäten und Rollen/Funktionen.

Architekturstile und Lösungsbewertung

  • Monolithische Architektur – Ein Architekturansatz, bei dem das gesamte System als ein einziges, unteilbares Modul entwickelt wird.
  • Microservices-Architektur – Ein Architekturansatz, bei dem ein System als eine Sammlung kleiner, unabhängig bereitstellbarer und skalierbarer Dienste aufgebaut ist.
  • Trade-off (Kompromiss) – Die Wahl zwischen sich gegenseitig ausschließenden oder widersprüchlichen Merkmalen oder Lösungen, bei der die Verbesserung eines Merkmals zu Lasten der Verschlechterung eines anderen geht.
  • ATAM (Architecture Tradeoff Analysis Method) – Eine Methode zur Bewertung von Softwarearchitekturen, die zur Analyse von Kompromissen zwischen Qualitätsmerkmalen (z. B. Leistung, Skalierbarkeit) verwendet wird.

Unternehmensarchitektur und Frameworks

  • TOGAF (The Open Group Architecture Framework) – Eines der am weitesten verbreiteten Frameworks für Unternehmensarchitektur, das die ADM (Architecture Development Method) zur Entwicklung und Verwaltung von Architekturen umfasst.
  • Zachman Framework – Eine Ontologie für Artefakte der Unternehmensarchitektur, dargestellt als 6×6-Matrix, die verschiedene Aspekte der Architektur aus unterschiedlichen Perspektiven klassifiziert.

Analyseansätze und Entwicklungsprozesse

  • Harter Ansatz (Hard Systems) – Eine Methodik der Systemanalyse, die von vorab formalisierbaren Zielen und Anforderungen, einer Dekomposition und einem Top-Down-Entwurf ausgeht und für klar definierte Aufgaben effektiv ist.
  • Weicher Ansatz (Soft Systems) – Eine Methodik der Systemanalyse, die bei unklaren Zielen und mehreren Sichtweisen der Stakeholder angewendet wird und darauf abzielt, ein gemeinsames Verständnis des Problems und der gewünschten Änderungen zu schaffen.
  • SSM (Soft Systems Methodology) – Eine spezifische Methodik des weichen Systemansatzes, entwickelt von Peter Checkland, die Werkzeuge wie Rich Picture, Root Definitions und CATWOE verwendet.
  • Waterfall (Wasserfallmodell) – Eine klassische Methodik der Softwareentwicklung, bei der die Phasen (Analyse, Entwurf, Implementierung, Testen, Einführung) sequenziell ausgeführt werden, wobei die vorherige Phase vollständig abgeschlossen sein muss, bevor die nächste beginnt.
  • Agile – Eine Gruppe flexibler Softwareentwicklungsmethoden, die auf iterative Entwicklung, Anpassung an Änderungen, Zusammenarbeit mit dem Kunden und kontinuierliche Wertlieferung ausgerichtet sind.

Auswahlmethoden und typische Fehler

  • AHP (Analytic Hierarchy Process) – Eine Methode zur multikriteriellen Entscheidungsfindung, die es ermöglicht, komplexe Probleme zu strukturieren und Alternativen auf der Grundlage einer Hierarchie von Kriterien zu bewerten.
  • Gold-plating („Gold Plating“-Syndrom) – Ein Fehler in der Systemanalyse, der darin besteht, Funktionalität hinzuzufügen, die von den Stakeholdern nicht gefordert wird, was zu einer Zunahme des Umfangs und der Komplexität des Projekts führt.

Literatur

  • ISO/IEC/IEEE (2023). 15288: System Life Cycle Processes.
  • INCOSE (2023). INCOSE Systems Engineering Handbook, 5. Aufl.
  • ISO/IEC/IEEE (2018). 29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering.
  • IIBA (2015). A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3.
  • The Open Group (2022). The TOGAF® Standard, 10th Edition. Offizielle kostenlose Version.
  • OMG (2017). Unified Modeling Language (UML®) 2.5.1 Specification. PDF.
  • OMG (2014). Business Process Model and Notation (BPMN™) 2.0.2 Specification. PDF.
  • OMG (2024). Systems Modeling Language (SysML®) 1.7 Specification. PDF.
  • The Open Group (2022). ArchiMate® 3.2 Specification. Offizieller kostenloser Download (unter Lizenz).
  • Bass, L.; Clements, P.; Kazman, R. (2021). Software Architecture in Practice, 4. Aufl.
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3. Aufl.
  • Rozanski, N.; Woods, E. (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, 2. Aufl.
  • Meadows, D. (2008). Thinking in Systems: A Primer.
  • Senge, P. M. (2006). The Fifth Discipline: The Art & Practice of the Learning Organization (rev. ed.).
  • Blanchard, B. S.; Fabrycky, W. J. (2010). Systems Engineering and Analysis, 5. Aufl.
  • Robertson, J.; Robertson, S. (2012). Mastering the Requirements Process: Getting Requirements Right, 3. Aufl.
  • van Lamsweerde, A. (2009). Requirements Engineering: From System Goals to UML Models to Software Specifications.
  • Hull, E.; Jackson, K.; Dick, J. (2017). Requirements Engineering, 4. Aufl.
  • Kendall, K. E.; Kendall, J. E. (2023). Systems Analysis and Design, 11. Aufl.
  • Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). Systems Analysis and Design: An Object-Oriented Approach with UML, 8. Aufl.
  • Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). Systems Analysis and Design in a Changing World, 7. Aufl.
  • Fowler, M. (2003). UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3. Aufl.
  • Delligatti, L. (2013). SysML Distilled: A Brief Guide to the Systems Modeling Language.
  • Silver, B. (2011). BPMN Method and Style, 2. Aufl.
  • Lankhorst, M. et al. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis, 4. Aufl.
  • Richards, M.; Ford, N. (2020). Fundamentals of Software Architecture.
  • Fairbanks, G. (2010). Just Enough Software Architecture: A Risk-Driven Approach.
  • Keeling, M. (2017). Design It!: From Programmer to Software Architect.
  • Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
  • Vernon, V. (2013). Implementing Domain-Driven Design.
  • Brandolini, A. (2018). Introducing EventStorming: An Act of Deliberate Collective Learning.
  • Simsion, G.; Witt, G. (2015). Data Modeling Essentials, 4. Aufl.
  • Silverston, L. (2008–2009). The Data Model Resource Book, Vols. 1–3 (rev. eds.).
  • Keeney, R. L.; Raiffa, H. (1993). Decisions with Multiple Objectives: Preferences and Value Trade-Offs, 2. Aufl.
  • Saaty, T. L. (1980). The Analytic Hierarchy Process; (1990) Decision Making for Leaders.

Anmerkungen

  1. ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 IEEE Computer Society (2025). Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf
  2. ↑ Zowghi, D.; Coulin, C. (2005/2014). Requirements Elicitation: A Survey of Techniques, Approaches, and Tools. https://eecs481.org/readings/requirements.pdf
  3. ↑ 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 3.11 3.12 ISO/IEC/IEEE 29148 (2011/2018). Systems and software engineering — Requirements engineering. ISO overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html
  4. ↑ 4.0 4.1 4.2 NASA (2020). NPR 7123.1C — Systems Engineering Processes and Requirements. Definition von „well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable“. https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all
  5. ↑ GMU (George Mason University). IEEE Software Requirements Specification Template (SRS). https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc
  6. ↑ Westfall, L. (Cal Poly, .edu). The What, Why, Who, When and How of Software Requirements (erwähnt URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf
  7. ↑ Stanford University IT (.edu). Functional Specification Document Template. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx
  8. ↑ Penn State (.edu). Elements of a Use Case Diagram. https://www.e-education.psu.edu/geog468/l8_p4.html
  9. ↑ UC Irvine (.edu). Data Flow Diagram. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/
  10. ↑ ISO/IEC/IEEE 42010 (2011/2022). Architecture description — Anforderungen an die Architekturbeschreibung und Sichten. https://standards.ieee.org/ieee/42010/5334/
  11. ↑ Cornell University (.edu). CS 5150 — Feasibility Studies. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf
  12. ↑ Carnegie Mellon SEI. Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  13. ↑ Microsoft Azure Architecture Center. Architecture styles: microservices — benefits & complexity. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  14. ↑ Google Cloud. What Is Microservices Architecture? — Monolithic vs. microservices (overview). https://cloud.google.com/learn/what-is-microservices-architecture
  15. ↑ NASA (2023). Requirements Management — Traceability, Bidirectional traceability (definitions). https://www.nasa.gov/reference/6-2-requirements-management/
  16. ↑ McKinsey (2012). Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
  17. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM) — CATWOE, 3Es. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  18. ↑ Lancaster University (ePrints). Soft Systems Methodology and root definitions. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf
  19. ↑ University of Cambridge, IfM. Soft Systems Methodology (SSM). https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/
  20. ↑ UCL Discovery (.ac.uk). M. Haklay. Soft System Methodology (SSM). https://discovery.ucl.ac.uk/1296/1/paper13.pdf
  21. ↑ IEEE Std 1320.1-1998 (R2004). Functional Modeling Language — Syntax and Semantics for IDEF0. https://standards.ieee.org/ieee/1320.1/2003/
  22. ↑ ISO/IEC/IEEE 31320-1:2012. IDEF0: Function Modeling. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf
  23. ↑ University of Washington (.edu). UML Class Diagrams / UML overview (course material). https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf
  24. ↑ JHU/APL (.edu). Modeling with SysML — tutorial. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf
  25. ↑ MIT OCW (.edu). O. de Weck. Introduction to Systems Modeling Languages (incl. SysML, MBSE). https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf
  26. ↑ IBM. What is Business Process Modeling and Notation (BPMN)?. https://www.ibm.com/think/topics/bpmn
  27. ↑ IBM Docs. Business Process Modeling Notation (BPMN) model. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model
  28. ↑ IEEE/ISO/IEC 29148:2018. Systems and software engineering — Requirements engineering (overview). https://standards.ieee.org/ieee/29148/6937/
  29. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  30. ↑ T. L. Saaty. How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19
  31. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  32. ↑ MIT OCW (.edu). V-Model — Fundamentals of Systems Engineering. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/
  33. ↑ Carnegie Mellon SEI (.edu). Architecture Tradeoff Analysis Method (ATAM) — overview. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  34. ↑ Microsoft Azure Architecture Center. Architecture styles. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
  35. ↑ Kazman, R.; Klein, M.; Clements, P. ATAM: Method for Architecture Evaluation. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf
  36. ↑ 36.0 36.1 36.2 36.3 The Open Group. Introduction — The TOGAF® Standard. https://www.togaf.org/chap01.html
  37. ↑ Microsoft Azure Architecture Center. Event-Driven Architecture style. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  38. ↑ Jonkers, H. et al. ArchiMate® and the TOGAF® Framework. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf
  39. ↑ Estrem, W. Building Blocks Revisited. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf
  40. ↑ The Open Group. Architecture Principles. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf
  41. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  42. ↑ The TOGAF® Standard, Version 9.2 (Spezifikation). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf
  43. ↑ Engelsman, W.; van Sinderen, M. Supporting Requirements Management in TOGAF and ArchiMate. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf
  44. ↑ Zachman, J. A. A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276
  45. ↑ MIT CISR. Classic Topics — Enterprise Architecture (Definition von EA als „organizing logic for business process and IT capabilities…“). https://cisr.mit.edu/content/classic-topics-enterprise-architecture
  46. ↑ The Open Group. IT Architecture Compliance. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm
  47. ↑ Royce, W. W. (1970). Managing the Development of Large Software Systems. IEEE WESCON. Reprint (PDF): https://www.praxisframework.org/files/royce1970.pdf
  48. ↑ Defense Acquisition University. System Requirements Review (SRR) — Acquipedia. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/
  49. ↑ NASA (2023). Requirements Management — baseline, change control (CCB). https://www.nasa.gov/reference/6-2-requirements-management/
  50. ↑ Microsoft Learn (Azure Boards). Best practices for Agile project management — Refine each backlog. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management
  51. ↑ MSDN Magazine (Microsoft). BDD Primer: Behavior‑Driven Development with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin
  52. ↑ Microsoft Learn. End‑to‑end traceability in Azure DevOps. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability
  53. ↑ Google SRE. Service Level Objectives; Error Budget Policy. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/
  54. ↑ Microsoft Learn. Azure Monitor — Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview
  55. ↑ AWS Whitepaper. Blue/Green Deployments on AWS. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html
  56. ↑ Microsoft Learn. Manage change — track, triage, and implement change requests. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change
  57. ↑ Microsoft Learn (Azure Boards). Backlogs overview — create and manage your product backlog. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview
  58. ↑ Microsoft Learn (Azure Test Plans). What is Azure Test Plans?. https://learn.microsoft.com/en-us/azure/devops/test/overview
  59. ↑ MSDN Magazine. Behavior‑Driven Design with SpecFlow. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow
  60. ↑ IBM. MTTR vs. MTBF: What’s the difference?. https://www.ibm.com/think/topics/mttr-vs-mtbf
  61. ↑ Google Cloud. Google Cloud Observability. https://cloud.google.com/products/observability
  62. ↑ IEEE Std 830‑1998. IEEE Recommended Practice for Software Requirements Specifications (historischer Standard). Studienkopie (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  63. ↑ 63.0 63.1 63.2 63.3 NASA. Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2). https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf
  64. ↑ 64.0 64.1 NASA (2023). Requirements Management — traceability, baseline, CCB. https://www.nasa.gov/reference/6-2-requirements-management/
  65. ↑ King’s College London (.ac.uk). What is MoSCoW prioritization?. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/
  66. ↑ Saaty, T. L. (1994). How to Make a Decision: The Analytic Hierarchy Process. Interfaces 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19
  67. ↑ SEI / CMMI Institute. Capability Maturity Model Integration (CMMI) — Overview. https://www.sei.cmu.edu/cmmi/
  68. ↑ NASA Langley. What is Formal Methods?; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf
  69. ↑ 69.0 69.1 SEI (CMU). Common Testing Problems: Pitfalls to Prevent and Mitigate (über typische Probleme bei Anforderungen/Nachverfolgbarkeit). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/
  70. ↑ 70.0 70.1 70.2 70.3 70.4 70.5 70.6 70.7 NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
  71. ↑ 71.0 71.1 71.2 71.3 71.4 71.5 U.S. DoD CIO (2021). DoD Enterprise DevSecOps Reference Design. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf
  72. ↑ Berufsstandard „Systemanalytiker“ (Verordnung des Arbeitsministeriums der Russischen Föderation vom 27.04.2023 Nr. 367n).
Retrieved from "https://systems-analysis.ru/int/index.php?title=Systemanalyse_in_der_IT&oldid=9276"