Wenn Anforderungen miteinander kommunizieren

Auf dem Weg von der Kundenanforderung zum fertigen Produkt gilt es einige Hürden zu nehmen. Im ersten Schritt der Entwicklung müssen verständliche Produktanforderungen zur Umsetzung abgeleitet werden. Und hier verzweigt sich auch schon der Weg. Verschiedene Möglichkeiten des Arbeitsstils sind möglich. Beim klassischen Vorgehen leiten Sie aus Kundenwünschen vom Lastenheft Produktanforderungen zur Umsetzung ab. Diese halten Sie im Pflichtenheft fest. Im Agilen wird die Dokumentation „schmaler“ gehalten: Nach Scrum werden aus den User Stories des Kunden Tasks für den Entwickler abgeleitet. Kärtchen an der Wand informieren, was umzusetzen ist und zeigen den Bearbeitungsstand. Doch beide Methoden haben einen Pferdefuß. Ab einer gewissen Komplexität, werden Zusammenhänge immer schwerer nachvollziehbar. Das Chaos beginnt, wenn mehrere Produktanforderungen umgesetzt werden müssen, um eine Kundenanforderung zu realisieren.

• Was machen Sie, wenn Ihr Klient Änderungswünsche hat?
• Wie können Sie nachvollziehen, dass die Kundenanforderung umgesetzt wurde?

Das Team fängt an Lasten- und Pflichtenheft miteinander zu vergleichen, um die meist per ID in Beziehung stehenden Anforderungen zu verändern. Arbeiten Sie agil und damit dokumentationsärmer, sind Sie schnell auf der Suche nach den richtigen Kärtchen der User Stories und der Entwicklertasks an der großen Wand. Effizient ist anders…
Digitale Transformation steht auf der Wunschliste vieler Unternehmen ganz oben. Doch dazu reicht es nicht aus, schwerfällig dateibasiert zu arbeiten und Post-its an der Wand zu verschieben. Heutzutage arbeitet man datenbank-basiert mit Softwaresystemen, die rollenspezifische User Interfaces bieten und die Nachvollziehbarkeit mit nur einem Klick ermöglichen.
Und ich zeige Ihnen jetzt, wie schnell Sie mit objectiF RPM Traceability gewährleisten, Standard-Prozesse computerisieren und Informationen automatisch „fließen“ lassen.

Eine Beziehung die Traceability sicherstellt

Unsere Ausgangssituation ist Folgende: Wir haben aus einer Kundenanforderung zwei Produktanforderungen oder aus einer User Story zwei Tasks zur Realisierung abgeleitet. objectiF RPM erzeugt bei einer solchen Aktion sofort eine Beziehung zwischen den Elementen. Eine solche Beziehung ist ein eigenes Objekt mit eigenen Eigenschaften, welche Sie auch unterschiedlichst auswerten können. Beispielsweise können Sie auf dieser Basis eine Abfrage erstellen, die alle Kundenanforderungen mit den abgeleiteten Produktanforderungen oder alle User Stories mit den abgeleiteten Tasks darstellt. Alternativ können Sie Zusammenhänge auch grafisch durch Nutzung von UML- und SysML Diagrammen anzeigen lassen.

Eine Traceability zwischen den Anforderungen ist hergestellt. Das lange Suchen nach den zur Kundenanforderung dazugehörigen Produktanforderungen hat mit einem Klick ein Ende.
Gibt es weitere Tätigkeiten, die uns ein Softwaresystem abnehmen kann? Werfen wir einmal einen Blick auf den Lebenszyklus einer Anforderung und die Möglichkeiten von Notifikationen zwischen den Elementen.

Entdecke die Möglichkeiten – Workflows sinnvoll nutzen

Jedes Element wie beispielsweise Anforderungen, Use Cases oder Testfälle besitzen in objectiF RPM einen festlegbaren Lebenszyklus. Das bedeutet, je nach Bearbeitungsstand hat das Element einen Status (Zustand). In der Abbildung sehen Sie die Festlegung für Produktanforderungen. In unserem Beispiel kann die Anforderung verschiedene Zustände wie „definiert“, „eingeplant“, „in Realisierung“ oder „realisiert“ einnehmen. Doch Sie können auch über die objectiF RPM Zustandsautomaten selbst entscheiden, wie der Lebenszyklus einer Anforderung aussieht.

Wie lassen sich nun Benachrichtigungen zwischen den Elementen festlegen? Im Konkreten, wie kann eine Produktanforderung die realisiert wurde, die zugehörige Kundenanforderung darüber benachrichtigen. Mit objectiF RPM ist das ziemlich leicht, denn die besagten Beziehungen können an dieser Stelle genutzt werden. Für unser Beispiel öffnen Sie den „Zustandsautomat …für Produktanforderungen“ unter „Einstellungen/Zustandsautomaten…“ und wählen den Zustand „realisiert“. Mit einem Rechtsklick können Sie den Zustand bearbeiten und gelangen in folgenden Dialog:

Hier können Sie Aktionen festlegen, die bei einem Zustandswechsel automatisch ausgeführt werden sollen. Um die Kundenanforderung zu benachrichtigen, wenn eine Produktanforderung realisiert wurde, wählen Sie die Aktion „Element benachrichtigen“. Das war es schon.
Doch die Kundenanforderung soll erst in den Bearbeitungszustand „realisiert“ wechseln, wenn alle zugeordneten Produktanforderungen umgesetzt wurden?

Nur unter einer Bedingung

Nichts leichter als das. Sie können in objectiF RPM auch Bedingungen definieren. Öffnen Sie dazu den „Zustandsautomaten… für Kundenanforderung“ und bearbeiten Sie den Zustandsübergang „Realisierung beendet“.

Nutzen Sie hier die Bedingung „Zustandsprüfung“, um eine Kundenanforderung in den Zustand „realisiert“ wechseln zu lassen, wenn alle in Beziehung stehenden Produktanforderungen realisiert sind. Fertig!

Fazit

Mit nur wenig Aufwand können Sie immer nachvollziehen, welche Kundenanforderung sich auf eine Produktanforderung bezieht. Die zeitaufwändige Suche bei Änderungswünschen ist vorbei und nebenbei haben Sie noch den Prozess teilautomatisiert. Sind alle Produktanforderungen umgesetzt worden, wechselt die Kundenanforderung in den Zustand „realisiert“ und der Kundenbetreuer sieht sofort, dass der Kundenwunsch umgesetzt wurde. Dazu öffnet er objectiF RPM? Nein, das ist nicht nötig. Auch diesen Vorgang kann man automatisieren. Fügen Sie doch einfach die Zustandsaktion „Projektmitarbeiter benachrichtigen“ hinzu. Schon erhält Ihr Kollege aus dem Sales eine Mail, wenn die Anforderung realisiert wurde.
Sie haben weitere Ideen zur Automatisierung Ihrer Prozesse und Workflows? Dann probieren Sie sich doch einmal mit objectif RPM aus. Die Trial Version steht Ihnen kostenlos zur Verfügung.