Beiträge

Kennen Sie das auch? Eine Excel-Liste mit Anforderungen liegt vor Ihnen. Vogelwild sind die Anforderungen auf dieser notiert. Angaben zu Anforderungsquellen fehlen gänzlich.
In unseren Beratungsprojekt hören wir an dieser Stelle oft zwei Fragen:

  1. Inwieweit haben wir keine Anforderung vergessen?
  2. Wie lässt sich die große Liste von Anforderung sinnvoll gruppieren?

In beiden Fällen hilft Ihnen das 6S Modell für Systemanforderungen. Im mosaiic Impuls stellen wir das kompakte Konzept vor.

Das 6S Modell für Systemanforderungen

Regelmäßig stoßen wir in den Digitalisierungsprojekten unserer Kunden auf lange Anforderungslisten. Anforderung reiht sich an Anforderung, Schnittstellen, Systemfunktionen und Nutzerfeatures werden durcheinander beschrieben. Eine Quellenangabe zu den Anforderungen – fehlt gänzlich. Dem gegenüber steht die Frage nach Vollständigkeit und der Wunsch nach Systematisierung.

Doch es gibt Abhilfe. Früh im Projekt bringen wir das von uns entwickelte und in unterer Abbildung illustrierte 6S Modell für Systemanforderungen ins Spiel. 6 Mal S, da jedes Element mit einem S beginnt und entweder die Quelle einer Anforderung oder die Anforderung selbst systematisiert.

Abbildung 6S Modell für Systemanforderungen

Abbildung: Das 6S Modell für Systemanforderungen

Stakeholder, Systeme und Schriften – die Quelle aller Systemanforderungen

Beginnen wir mit dem Ursprung für die Anforderungen an ein System. Analog dem International Requirements Engineering Board (IREB) können Sie hier zwischen drei Anforderungsquellen unterscheiden:

Stakeholder
Ein Stakeholder ist eine Person oder Organisation mit einem Einfluss auf die Anforderung an das entwickelnde System. Der Teufel steckt im Detail. Stakeholder müssen nicht unbedingt eine Anforderung nennen bzw. haben. Es ist ausreichend, wenn sie diese beeinflussen.

Stakeholder sind die präsenteste Anforderungsquelle in Projekten. Ein gutes Stakeholdermanagement sorgt dafür, dass Sie keinen Stakeholder bzw. die mit ihm verbundenen Anforderungen übersehen.

Systeme
Auch Systeme stellen Anforderungen. Kategorie 1 ist das Vorgängersystem. Wenn Sie ein Bestandssystem ersetzen werden Sie ein Teil der Funktionen und Merkmale in das Nachfolgesystem übernehmen müssen. Kategorie 2 sind die Nachbarsysteme. Diese interagieren mit dem System, stellen Daten zu Verfügung oder benötigen Daten von diesem.

Große Systeme werden selten, kleine regelmäßig als Anforderungsquelle übersehen. Am besten Sie fertigen zu Beginn ein Systemkontextdiagramm an und notieren mit Pfeilen die eingehenden und ausgehenden Datenflüsse.

Schriften
Die letzte Gruppe von Anforderungsquellen sind Schriften. Lastenhefte, ISO Normen, BAFIN Rundschreiben, Datenschutzgrundverordnung – das alles sind potentielle Anforderungen an das System.

Erstellen Sie eine Liste mit anforderungsrelevanten Dokumenten. Durchkämen Sie die Dokumente und extrahieren Sie Anforderungen an Ihr System.

Stakeholder-Aktionen, Systemaktivitäten und Schnittstellen – der Typ aller Systemanforderungen

Anforderungen repräsentieren einen Bedarf eines Nutzers bzw. eine Fähigkeit oder Eigenschaft, die ein System besitzen sollte. Jede Anforderung, die Sie definieren, lässt sich genau einem der folgenden Typen zuordnen.

Stakeholder-Aktivitäten
Ein System stellt seinen Benutzern Funktionen zur Verfügung oder tritt mit ihnen in Interaktion. Typisch im Business Software Kontext sind die Datenausgabe oder Auswahlmasken.

Viele Anforderungen zahlen auf Stakeholder-Aktivitäten ein, schließlich werden Systeme für Menschen entwickelt und betrieben. Das Usability Engineering mit Techniken wie Mock-ups oder High-Fidelity Prototyping unterstützt Sie bei der Konkretisierung dieses Anforderungstyps.

Systemaktivitäten
Ein System startet einen Teil seiner Funktionen automatisch und führt diese auch automatisch aus. Typische Beispiele für Business Software sind der Datenimport und die Datenaufbereitung sowie die Kalkulation von Berichten.

Systemaktivitäten leiten sich häufig aus den Stakeholder-Aktivitäten ab. Aber auch Nachbarsysteme bzw. dokumentierte Anforderungen können diesen Anforderungstyp erzwingen. Nützlich zur Dokumentation ist die IREB Satzschablone sowie Modelle der Unified Modeling Language (z.B. Sequenzdiagramm).

Schnittstellen
Der letzte Anforderungstyp sind die Schnittstellen. Mit Schnittstellenanforderungen wird der Fall abgedeckt, dass ein System eine Funktion nur in Anhängigkeit der Informationseingabe durch ein externes System ausführen kann bzw. an ein externes System Information bereitstellt.

In der Regel resultieren Anforderungen an Schnittstellen aus bestehenden Verbindungen zwischen Vorgängersystem und Nachbarsystemen. Bauen Sie auf diesen auf und dokumentieren Sie Schnittstellenanforderungen, beispielsweise mit einem Informationsflussdiagramm.

Fazit

Das 6S Modell für Systemanforderungen ist eine griffige Formel, um keine Anforderung zu vergessen sowie eine Anforderungsliste zu strukturieren. Nutzen Sie das 6S Modell direkt zu Projektbeginn. Fragen Sie nach weiteren Stakeholdern, Systemen und Schriften. Setzen Sie das Modell dann im Projektverlauf ein. Gruppieren Sie dazu die Anforderungen nach Stakeholder-Aktionen, Systemaktivitäten und Schnittstellen. Ein Modell, zwei Einsatzmöglichkeiten. Gutes Gelingen!

 

Sie planen Requirements Engineering bei sich als Unternehmensfunktion zu etablieren? Bestehende RE-Prozesse sollen agil und fit für die Digitalisierung gemacht werden? Sie suchen ein passendes Requirements Engineering Tool?

Gerne unterstützen wir Sie dabei! Vereinbaren Sie ein Gespräch mit unserem Requirements Engineering Experten und decken Sie Verbesserungspotentiale in Ihrem Management von Anforderungen auf.

“Why Software Is Eating the World” titelte Marc Andreessen einst im The Wall Street Journal. Das war am 20. August 2011. Inzwischen sind sieben Jahre vergangenen und inzwischen wissen wir: Andreessen betrachtete in seinem vielzitierten Beitrag nur die halbe Wahrheit. Denn so viel steht nach Amazon Alexa, Apple iPhone und Facebook Oculus Go fest: Nicht Software allein, sondern Software in Kombination mit Hardware „is eating the World“. Doch wer setzt sich eigentlich in unseren Unternehmen mit beiden Aspekten auseinander? Dem reibungslosen Zusammenspiel von Softwarecode sowie den physischen Trägerkomponenten? Dr. Kim Lauenroth meint: der Digital Designer. Interessante Berufsbezeichnung und für uns ein Grund für ein Interview.

Weiterlesen