Aufgabe: Vision entwickeln
Diese Aufgabe beschreibt, wie für das System eine Gesamtvision entwickelt wird; dazu gehören die zu lösenden Probleme, die Stakeholder, der Umfang des Systems und seine wichtigsten Funktionen sowie mögliche Einschränkungen.
Zweck

Diese Aufgabe hat folgenden Zweck:

  • Übereinstimmung betreffend der zu lösenden Probleme herstellen
  • Stakeholder im System identifizieren
  • Systemgrenzen definieren
  • Primäre Systemkomponente beschreiben
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Hauptbeschreibung

Bei der Entwicklung der Vision ist Folgendes zu berücksichtigen:

  • Die potenziellen (oder tatsächlichen) Benutzer des Systems werden den Rollen der menschlichen Akteure des zu entwickelnden Systems zugeordnet.
  • Die Methode, Akteure zu verwenden, um die Grenzen des Systems zu definieren und zu beschreiben, ist normalerweise sehr effektiv. Informationen hierzu finden Sie im Abschnitt Akteure und Anwendungsfälle suchen.
  • Die mit dieser Aufgabe erfassten Vorgaben werden als erster Input für die Designvorgaben verwendet, die in ergänzenden Spezifikationen definiert sind. Weitere Informationen finden Sie im Abschnitt Ergänzende Spezifikationen entwickeln.

Schritte
Übereinstimmung darüber herstellen, welches Problem gelöst wird.

Die einfachste Methode, um Einigkeit über die Definition eines Problems zu erhalten, ist es, das Problem aufzuschreiben und festzustellen, ob alle zustimmen.

Fragen Sie die Gruppe: Was ist das Problem?

  • Häufig wird zu schnell versucht, eine Lösung zu entwickeln, obwohl das Problem selbst noch nicht im Detail verstanden wurde. Schreiben Sie das Problem auf und stellen Sie fest, ob alle dieser Definition zustimmen.

Fragen Sie die Gruppe dann erneut: Was ist das Problem?

  • Suchen Sie nach den eigentlichen Fehlerursachen, also dem Problem hinter dem Problem. Das echte Problem ist oft von dem verdeckt, was als Problem gesehen wird.

Akzeptieren Sie nicht die erste Beschreibung eines Problems. Fragen Sie weiter nach dem Warum. Erkunden Sie die Natur des Problems.

Manchmal ist die Gruppe so stark auf eine mögliche Lösung fixiert, dass es schwer ist, sie dazu zu bewegen, das tatsächliche Problem zu beschreiben. Es kann in solchen Fällen sinnvoll sein, die Leistungen der Lösung zu beleuchten und dann über die Probleme zu sprechen, die dadurch gelöst werden. Im weiteren Verlauf können Sie dann feststellen, ob es sich um "echte" Probleme in der Organisation handelt. Allgemeine Techniken, mit denen man das Problem hinter dem Problem findet, sind Brainstorming, Tannenbaumdiagramme und Pareto-Diagramme.

Stakeholder identifizieren

Abhängig vom Fachwissen des Entwicklerteams kann die Identifikation der Stakeholder sehr einfach sein (oder eben nicht). Oft genügt es, Entscheidungsträger, potenzielle Benutzer und andere Interessierte einzubeziehen. Folgende Fragen sind hilfreich:

  • Wer benutzt das System?
  • Wer ist der Geldgeber für das System?
  • Auf wen wirkt sich die Systemausgabe noch aus?
  • Wer nimmt das System ab, wenn es geliefert und implementiert ist?
  • Gibt es interne oder externe Benutzer des Systems, deren Bedürfnisse berücksichtigt werden müssen?
  • Wer wird das System verwalten?
  • Wer sonst noch?
  • Und wer noch?

Beginnen Sie mit der Entwicklung der Profile potenzieller (oder tatsächlicher) Systembenutzer. Erste Informationen zu Hauptbenutzern und ihrer Umgebung sollten im Visionsdokument beschrieben werden.

Systemgrenzen definieren

Die Systemgrenze ist die Grenze zwischen der Lösung und der realen Welt, die die Lösung umgibt. In anderen Worten, die Systemgrenze beschreibt den Umschlag, in dem sich das System befindet. Information in Form von Ein- oder Ausgabe wird vom System empfangen oder zu Benutzern gesendet, die sich außerhalb des Systems befinden. Alle Interaktionen mit dem System finden über Schnittstellen zwischen System und externer Welt statt.

In vielen Fällen sind die Systemgrenzen deutlich erkennbar. Beispiel: Die Grenzen eines handelsüblichen Adressverwaltungsprogramms für Einzelbenutzer, das unter Microsoft Windows® ausgeführt wird, sind recht klar definiert. Es gibt nur einen Benutzer und eine Plattform. Die Schnittstellen zwischen Benutzer und Anwendung bestehen aus den Dialogen, auf die der Benutzer zugreift, um Informationen einzugeben, und den Ausgabeberichten und Kommunikationspfaden, die das System nutzt, um die sich ergebenden Daten zu übertragen.

Einschränkungen des Systems identifizieren

Es gibt verschiedene Quellen für Einschränkungen. Es folgt eine Liste mit potenziellen Quellen und den zu stellenden Fragen:

  • Gibt es interne oder externe geschäftspolitische Themen, die sich auf mögliche Lösungen auswirken können? Wie sieht es zwischen den einzelnen Abteilungen aus?
  • Wirtschaftlicher Aspekt: Gibt es finanzielle Einschränkungen? Gibt es Kosten für verkaufte Produkte oder Überlegungen zu Produktpreisen? Gibt es Lizenzierungsfragen?
  • Umgebung: Gibt es umgebungsbedingte Einschränkungen oder Vorgaben durch Anwendungsstandards? Gesetze? Sonstige Vorschriften?
  • Technik: Gibt es Einschränkungen bei der Auswahl der Technologie? Müssen bestehende Plattformen oder Technologien verwendet werden? Dürfen neue Technologien verwendet werden oder nicht?
  • Realisierbarkeit: Ist der Zeitplan definiert? Dürfen nur vorhandene Ressourcen verwendet werden? Können externe Mitarbeiter eingesetzt werden? Können Ressourcen erweitert werden? Temporär? Permanent?
  • System: Soll die Lösung auf den eigenen Systemen basieren? Ist Kompatibilität mit bestehenden Lösungen erforderlich? Welche Betriebssysteme und Umgebung sollen unterstützt werden?
Problembeschreibung formulieren

Verwenden Sie Flip-Charts und füllen Sie mit der ganzen Gruppe die folgende Vorlage für jedes identifizierte Problem aus:

Das Problem: <Problembeschreibung>
Auswirkungen auf: <Liste der betroffenen Stakeholder>
Auswirkung: <Beschreibung der Auswirkung>.
Eine erfolgreiche Lösung: <Liste mit wichtigen Leistungen einer guten Lösung>.

Sinn und Zweck der Vorlage ist es, besser zwischen Lösungen/Antworten und Problemen/Fragen unterscheiden zu können.

Beispiel:

Das Problem: Unpassende und falsche Lösungen für Kundenserviceprobleme.
Auswirkungen auf: Unsere Kunden, Kundenunterstützung und Servicetechniker.
Auswirkung: Unzufriedenheit der Kunden, gefühlte Qualitätsmängel, frustrierte Mitarbeiter und Umsatzverluste.
Eine erfolgreiche Lösung:
Bietet Zugriff in Echtzeit auf eine Datenbank zur Fehlerbehebung durch die Unterstützungsfunktion, erleichtert das zeitnahe Entsenden von Servicetechnikern nur an solche Lokationen, an denen sie wirklich benötigt werden.

Features des Systems definieren

Entwickeln Sie auf der Basis der Leistungen, die in der Problembeschreibung aufgelistet sind, eine Liste der Features, die im System vorhanden sein sollen. Beschreiben Sie sie kurz und vergeben Sie Attribute, um ihre allgemeinen Zustand und ihre Priorität im Projekt festzulegen.

Ergebnisse auswerten

In diesem Stadium sollten Sie die Vision prüfen, um sicherzustellen, dass Sie mit der Arbeit auf dem richtigen Weg sind, sie aber nicht im Detail untersuchen. Weitere Informationen enthält die Prüfliste: Vision).



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen