Anforderungen und Modelle integrieren

Während Requirements Engineering an sich bereits nützlich ist, kann die Integration mit anderen Elementen aus dem Systementwicklungsprozess seinen Wert erheblich steigern. Wir haben dies in unserer wissenschaftlichen Arbeit bereits im Hinblick auf die Rückverfolgbarkeit oder unsere Überlegungen zur Integration mit Topcased angedeutet. Unsere neuesten Ideen wurden gerade zur Veröffentlichung eingereicht. Stellen Sie sich ein Szenario vor…

Während die Anforderungsanalyse an sich bereits nützlich ist, kann sie durch die Integration mit anderen Elementen des Systementwicklungsprozesses ihren Wert erheblich steigern. Wir haben dies bereits in unserer wissenschaftlichen Arbeit angedeutet in Bezug auf Rückverfolgbarkeit, oder unsere Gedanken an eine Integration mit Topcased. Unsere neuesten Ideen wurden gerade zur Veröffentlichung eingereicht.

Stellen Sie sich ein Szenario vor, in dem Sie an Ihren Anforderungen arbeiten, während Sie gleichzeitig ein Modell erstellen. Das Tool verwaltet das Datenmodell (und in gewisser Weise auch ein Glossar) im laufenden Betrieb und gibt sogar Rückmeldung durch farbliche Hervorhebung:

Das obige Bildschirmfoto wurde mit dem Programm Integration von ProR mit Rodin. Sie wurde aus einer Papier, das wir gerade vorgelegt haben und das einen Ansatz zur Rückverfolgbarkeit skizziert. Rodin ist eine Plattform für die formale Modellierungssprache Event-B, aber die gleichen Konzepte können auch mit anderen Modellen, z. B. SysML, verwendet werden.

Welchen Wert hat also eine solche Integration? Stellen Sie sich vor, Sie erhalten einen Satz von Ausgangsanforderungen und die Aufgabe, eine Spezifikation zu erstellen. Ein typischer erster Schritt ist die Identifizierung von Substantiven im Anforderungstext als Ausgangspunkt für die Modellierung der Domäne. Durch die Integration kann die Modellierung der Domäne in Event-B erfolgen. Sobald die ersten Elemente modelliert sind, erscheinen sie mit einer verschnörkelten roten Unterstreichung, die Sie darauf aufmerksam macht, dass Sie möglicherweise die Deklaration eines Elements vergessen haben. Sobald Sie eckige Klammern um sie herum setzen, werden sie blau, um anzuzeigen, dass dies ein modelliertes Element ist.

Der Ansatz kann umgedreht werden: Markieren Sie zunächst alle Domänenelemente, indem Sie sie im Anforderungstext mit eckigen Klammern umgeben. Sie werden rot und zeigen damit an, dass sie noch nicht modelliert worden sind. Nach der Modellierung (oder Umbenennung, wenn Sie ein Synonym gefunden haben) werden sie blau.

Die Integration erlaubt bereits die Erstellung von Traces - dies ist in der rechten Spalte des Screenshots zu sehen. Während Links in ProR generisch sind, verwenden wir in unserem Ansatz Traces, um eine “realisierte” Beziehung zu dokumentieren: Ein verknüpftes Element trägt zur Realisierung einer Anforderung bei. Es ist möglich, Elemente aus dem Modell (z.B. eine Invariante) oder andere ProR-Elemente (z.B. SpecObjects, die Teil der Spezifikation sind) zu verknüpfen.

Im Laufe der Arbeit ändern sich die Spezifikationen, Anforderungen oder Modellelemente. Wenn es eine Spur gibt, wird sie mit einem gelben Dreieck als “verdächtig” markiert, um den Benutzer darauf hinzuweisen, dass die Beziehung verdächtig sein könnte.

Sie verstehen schon - schließlich können Sie Traces verwenden, um nicht realisierte Anforderungen, nicht modellierte Domänenobjekte usw. zu finden. Wenn Sie den Ansatz verfolgen, der in unser Papier, können Sie sogar die Konsistenz der Systembeschreibung überprüfen. (Offenlegung: Unsere Integration unterstützt nicht die Validierung aller Konsistenzeigenschaften, die wir identifiziert haben - wir arbeiten daran).

Wenn Sie mehr darüber erfahren möchten, zögern Sie bitte nicht, sich an folgende Adresse zu wenden Kontaktieren Sie uns.

Ähnliche Beiträge