Hi there,

Here you will find blog posts by microTOOL experts on useful and interesting topics about project management and software development.
Join us! Chat with us about methods, processes and tools in practice.

Agiles Requirements Engineering – erste Etappe: „Wir hätten da gerne noch...“ – Kundenanforderungen verstehen

Written by Ursula Meseberg on 3/26/2014 9:01:00 AM

Unsere Kunden erzählen keine Geschichten

Wenn Sie Softwareprodukte entwickeln, dann kennen Sie das: Anforderungen von Kunden können jede nur erdenkliche Form besitzen – von einer E-Mail mit ein paar Sätzen der Art „Wir hätten da gern noch ...“ bis zu einem umfangeichen Lastenheft. User Stories, die direkt in die agile Entwicklung einfließen können, "erzählen" unsere Kunden nur selten.

Im Beitrag Agiles Requirements Engineering – gibt’s das überhaupt? habe ich ein Framework für agiles Requirements Engineering im Vorfeld agiler Softwareentwicklung vorgestellt. Ausgehend von Kundenanforderungen – in welcher Form auch immer – liefert es in kurzen Iterationen User Stories für das Product Backlog. Hier ist noch einmal der Ablauf im Überblick:

Das Analysieren und Zerlegen der Kundenanforderungen, das Verwalten von Anforderungen, Epics und User Stories in mehreren Backlogs – ist all das praktikabel? Bleibt jederzeit transparent und nachvollziehbar, was aus einer Anregung, Idee oder Anforderung eines Kunden geworden ist? Für die Lösung, die ich Ihnen vorstellen möchte (und die wir selbst in unserer Produktentwicklung praktizieren), lautet die Antwort auf beide Fragen ja. Das liegt nicht zuletzt an der Tool-Unterstützung durch das neue in-Step RED.

Ich lade Sie zu einer kleinen Reise ein: Begleiten Sie eine Kundenanforderung durch das Requirements Engineering bis hin zur spezifizierten Komponente. Die Reise führt über das Requirements Backlog zum Product Backlog und schließlich zur Sprint-Planung. Und sie führt Sie mitten hinein in in-Step RED.

Heute geht es auf die erste Etappe ...

More

Tags: , ,

Dokumentieren im objectiF Requirements Modeller mit MS Word

Written by Steffi Fritz on 11/14/2013 8:42:00 AM

In dieser Woche hatten wir eine interessante Kundenanfrage zum objectiF Requirements Modeller, unserem Tool für modellbasiertes Requirements Engineering, die ich gerne mit Ihnen teilen möchte. Es ging um das Thema Dokumentieren mit MS Word.

Wer den objectiF Requirements Modeller kennt, der weiß, dass man Modelle nicht nur einfach als Bild in Word-Dokumenten abbilden kann. Man kann ihre Inhalte auch – individuell aufbereitet – in Dokumente übernehmen. Hinter dieser Tatsache steckt ein Generierungsmechanismus, der vielfältig konfigurierbar ist. Einmal damit vertraut, bietet dieser Mechanismus jedem Anwender eine Vielzahl an Möglichkeiten für zielgruppenorientierte Projektdokumentation einfach per Knopfdruck.

Unser Standard-Template liefert bereits einige Dokumente und Dokumentvorlagen mit. Aber wie das Leben nun einmal ist: Manchmal fehlt genau das, was man gerne hätte. So ging es auch unserem Kunden: Er benutzt Blockdiagramme der SysML®, einer Erweiterung der UML®, um Architekturaspekte zu spezifizieren. In Blockdiagrammen hatte er Schnittstellen modelliert, die jeweils über einen Standardport eine Use- bzw. Realize-Beziehung zu Blöcken seines Systems besaßen. Das sah etwa so aus:

 

Kundenwunsch: Modellinhalte in Tabelle in MS Word umsetzen

In seiner Word-Dokumentation wünschte er sich nun eine Tabelle, die eine Schnittstelle mit ihren Beziehungen und den Blöcken als Einheit darstellte. Der Tabelleneintrag für eine Schnittstelle sollte aus dem Modell automatisch erzeugt werden und so aufgebaut sein:

Ein Blick in die vorhandenen Dokumente bzw. Dokumentvorlagen half ihm an dieser Stelle leider nicht weiter. Was jedoch half, war eine E-Mail an uns, an rm.service@microtool.de :-)

More

Tags: , ,

in-Step RED – Wie geht es denn unserer Organisation?

Written by Ursula Meseberg on 9/26/2013 8:48:00 AM

Wie ist die Auslastung unserer Mitarbeiter? Haben wir noch freie Kapazität? Wie viele Kundenanforderungen liegen uns vor, die wir noch nicht bearbeiten? – Linienmanager, Multiprojektmanager und Programmmanager brauchen Antworten auf Fragen wie diese. Und das nicht nur projektbezogen, sondern auch aus Sicht der gesamten Organisation oder einzelner Organisationseinheiten.

in-Step RED – unsere neue Software für anforderungsbasierte Produktentwicklung, die ich Ihnen in meinem letzten Beitrag erstmals vorgestellt habe – bietet Ihnen als Anwender die Möglichkeit, auf Organisationsniveau Analysen durchzuführen. Diese Analysen in Form von Charts und tabellarischen Auswertungen sind in in-Step RED bereits vorbereitet. Sie können sie mit wenigen Klicks konfigurieren und zum Beispiel das gewünschte Auswertungsintervall und den Auswertungszeitraum festlegen, wie es die nachfolgende Abbildung an einem Beispiel zeigt. Als Anwender können Sie außerdem eigene wiederverwendbare Abfragen erstellen, die Ihnen mit jedem Aufruf aktuelle Daten liefern. 

Bereitstellung von Ressourcen – ein Beispiel für ein konfigurierbares Chart

Wenn Sie strategische Entscheidungen auf Organisationsebene treffen müssen, ist oft ein Blick auf sämtliche Meilensteine der geplanten und bereits laufenden Projekte hilfreich. Diesen Blick bietet Ihnen die organisationsweite Roadmap. Daneben ist die Roadmap ein Hilfsmittel zur schnellen und einfachen Navigation in ein Projekt  –  z.B. in den aktuellen Projektplan als Gantt Chart oder direkt zu den Ergebnissen, die an einem Meilenstein eines Projekts vorliegen müssen. Letzteres sehen Sie in dem kurzen Film (2:30 Minuten), mit dem ich Ihnen die organisationsweite Roadmap vorstellen möchte:

Haben Sie Lust bekommen, mehr von in-Step RED zu sehen? Dann laden wir Sie zu einer der Veranstaltungen auf unserer Product Launch Tour ein – in Leipzig, Stuttgart und München. Wir freuen uns auf Sie und auf Ihr Feedback zu in-Step RED.

Tags: , ,

in-Step RED kommt! Ein erster Blick in die neue Software

Written by Ursula Meseberg on 8/27/2013 8:28:00 AM

Ab Mitte September gehen wir mit unserer neuen Software in-Step RED auf Product Launch Tour kreuz und quer durch Deutschland. Ich lade Sie heute schon ein, einen ersten Blick auf in-Step RED zu werfen. Was ist in-Step RED und was ist das Besondere daran? 

 

 

in-Step RED bietet einem Team, das Produkte, Software & Systeme entwickelt, eine gemeinsame Arbeitsumgebung. Als Projektleiter finden Sie darin genau die Instrumente, die Sie für die Projektplanung brauchen, zum Beispiel Gantt Charts oder Ressourcendiagramme. Als Linienmanager verschaffen Sie sich schnell einen Überblick über die Ressourcenauslastung – auch über Projektgrenzen hinweg – und haben u.a. die Möglichkeit zur Earned Value Analyse.

Aber für erfolgreiche Produktentwicklung braucht man mehr als Planungs- und Controlling-Instrumente. Man braucht eine klare Zielorientierung und das Wissen darüber, was die Stakeholder wirklich wollen – also möglichst präzise Anforderungen.

Als Requirements Engineer oder Anforderungsanalytiker finden Sie in in-Step RED zahlreiche Hilfen für das Ermitteln und Beschreiben von Anforderungen. Sie reichen von Systemkontext- und Zieldiagrammen bis zu den klassischen Elementen der UML® und SysML®. Anforderungen erfassen Sie formularbasiert und, wenn Sie wollen, die Testfälle gleich dazu. Dokumentation erzeugen Sie auf Knopfdruck. Und natürlich wird für alle Ergebnisse automatisch eine Änderungshistorie fortgeschrieben. Als Produktmanager priorisieren Sie die Anforderungen und verschaffen sich mit Hilfe von Auswertungen jederzeit einen Überblick über den Stand der Arbeit.

Klar, sowohl für das Projektmanagement als auch für die Anforderungsanalyse gibt es zahlreiche Werkzeuge. Das Besondere an in-Step RED ist, dass es beide Disziplinen miteinander verbindet: das Requirements Engineering und das Projektmanagement. So entsteht Synergie. 

Anforderungsbasiert Planen

Ein Beispiel: Für Sie als Projektleiter hat der direkte Zugriff auf die Ergebnisse des Requirements Engineering ganz praktischen Nutzen. Die Anforderungen mit allen Informationen über Priorität, Zustand und geschätztem Aufwand stehen Ihnen bei der Projektplanung unmittelbar zur Verfügung. Das bedeutet, dass Sie bei einem iterativen, inkrementellen Vorgehen, wie es heute in vielen Projekten üblich ist, einer Iteration mehrere Anforderungen einfach per Drag & Drop zuordnen können. Die Anforderungen bringen den geschätzten Aufwand mit, sodass die Auswirkungen dieser Zuordnung auf die Iterationsplanung im Gantt Chart und in der Ressourcenauslastung sofort sichtbar werden, ohne dass Sie irgendetwas dazu tun müssen.

Musterbasiertes Gliedern eines Projekts

Bevor Anforderungen einer Iteration zugeordnet werden können, muss es überhaupt Iterationen geben, d.h. ein Projekt muss zunächst strukturiert und verfeinert werden. Um ein Projekt in Aktivitäten und Meilensteine zu gliedern, ihre Reihenfolge zu bestimmen, die Ablage der Ergebnisse zu organisieren, Konfigurationen und vorstrukturierte Ergebnisse anzulegen, Beziehungen zu bestehenden Produktkomponenten herzustellen ..., bietet Ihnen in-Step RED eine sehr mächtige Technik an: das Strukturieren von Projekten mithilfe von Mustern. Muster bilden modular Wissen – Ihr Wissen – über die Verfeinerung oder Erweiterung beliebiger Projektinhalte ab. In Muster "verpackt" ist das Wissen organisationsweit wiederverwendbar. So definieren Sie Standards für Ihre Projekte orientiert an Ihren eigenen Best Practices.

Muster werden immer kontextorientiert angeboten. Das macht ihre Anwendung denkbar einfach. Schauen Sie selbst: 

 

 

Nachvollziehbare Anforderungen

„Haben wir diese Anforderung schon realisiert und wenn ja, durch welche Komponente, welches Systemelement?“ – eine typische Frage in jedem Entwicklungsprojekt. Mit in-Step RED haben Sie volle Traceability. Sie beginnt  bei den Stakeholderzielen und reicht über die Anforderungen bis zu den Elementen der Systemarchitektur.

Skalierbare Architektur

Ihre Projekte sind groß? Sie haben Projektteams an mehreren Standorten? Die Arbeit im LAN auf einer gemeinsamen Datenbank, der Datenaustausch zwischen Standorten, die nicht online verbunden sind, der Zugriff über den in-Step RED Web-Client per Internet-Browser – all das ist möglich. Sie entscheiden über die Form der Arbeit. 

Egal, ob mit dem Windows-Client (links) oder dem Web-Client per Internet-Browser (rechts) - Sie haben Zugang zu Ihren Projekten über eine weitgehend identische Benutzeroberfläche

Wenn Sie dieser kurze Einblick neugierig gemacht hat, dann laden wir Sie ein: Kommen Sie doch zu einer der Veranstaltungen auf unserer Product Launch Tour für in-Step RED in Düsseldorf, Frankfurt, Berlin, Leipzig, Stuttgart, München-Unterschleißheim und Hannover.

Übrigens, falls Sie sich fragen: „RED“ – hat das auch eine Bedeutung? Ja, RED steht für Requirements Engineering & Development – ein Tool eben für alle, die gemeinsam Produkte entwickeln.

Tags: , , ,

Produktmanagement mit dem objectiF Requirements Modeller

Written by Mirko Pracht on 7/30/2013 8:00:00 AM

Neulich starteten wir den Einsatz des objectiF Requirements Modeller bei einem Hersteller von Softwareprodukten. Natürlich stand dabei auch das Requirements Engineering zur Strukturierung des fachlichen Modells im Vordergrund:

  • Welche Ziele verfolgen wir für das neue Release bzw. Produkt?
  • Welche Anwendungsfälle bestehen aus der Sicht des Produktnutzers?
  • Welche Anforderungen an das aktuelle Release / Produkt leiten sich daraus ab?
  • Wie lassen sich Anwendungsfälle durch Aktivitätsdiagramme fachlich noch weiter detaillieren?

Jedoch war der Einsatz des Requirements Modeller nicht auf die Dokumentation des fachlichen Modells begrenzt ...

More

Tags: ,

Anforderungen an das User Interface skizzieren – und dann, wohin damit?

Written by Ursula Meseberg on 4/16/2013 9:05:00 AM

objectiF® Requirements Modeller – Anforderungsschablone um benutzerdefinierte Eigenschaft für UI Prototyp erweitern

Wenn Sie als Requirements Engineer häufig mit zukünftigen Anwendern eines geplanten Systems zusammenarbeiten, dann wissen Sie, dass sich Anwender gern von der Benutzeroberfläche her den funktionalen Anforderungen „nähern“. („Kann es denn nicht oben auf dem Bildschirm so ein Symbol geben wie in vielen Apps, also so ein kleines Zahnrad … und wenn man da draufklickt, dann  …?) Und schon sind sie in der Welt: die Anforderungen an User Interface und User Interaction. Sie sollten genau wie alle anderen Anforderungen der Stakeholder festgehalten und dokumentiert werden – allerdings nicht mit allzu viel Text, sondern am besten gleich grafisch. Um die Vorstellungen der Anwender zu skizzieren, gibt es viele bewährte Tools. Bleistift und Papier zum Beispiel und – wenn Sie sich nicht zum Künstler berufen fühlen oder es zu komplex wird – Wireframing Tools. Manche davon liefern Bilddateien (.jpg oder .png), andere Prototypen z.B. in HTML. Manche generieren sogar Artefakte für die Implementierung der Benutzeroberfläche.

Wenn Sie Anforderungen mit dem objectiF Requirements Modeller entwickeln und verwalten, stellt sich die Frage: Wie kommen die mit einem Wireframing Tool erstellten Ergebnisse als Anforderungen in den objectiF Requirements Modeller hinein? Ganz einfach. Das geht so:

Der kurze Film (6:48 Minuten) zeigt Ihnen zwei mögliche Fälle: …

More

Tags: , , , ,

objectiF® Requirements Modeller: Steht „Modeller“ drauf – ist aber auch „Manager“ drin

Written by Ursula Meseberg on 3/19/2013 10:00:00 AM

Der objectiF Requirements Modeller enthält neben vielfältigen Möglichkeiten zum Modellieren und Dokumentieren von Anforderungen auch Funktionen, um Anforderungen sicher zu verwalten. In der Version 1.2, die seit Kurzem verfügbar ist, hat sich einiges getan, speziell was das Versionieren von Ergebnissen des Requirements Engineering angeht. Mehr dazu  – speziell zum Versionieren von Diagrammen  – erfahren Sie hier.

More

Den Workspace im objectiF® Requirements Modeller rollenspezifisch zuschneiden - Teil 4

Written by Michael Dutz on 3/5/2013 9:11:00 AM

Teil 4: Funktionen aktivieren und deaktivieren

In Teil 3 dieser Beitragsreihe hatten Sie gesehen, dass Sie in einem Nutzungsprofil im objectiF Requirements Modeller die Komponenten vollständig deaktivieren können, die nirgendwo benötigt werden. Im Nutzungsprofil „Anforderungen verfolgen“ sind deshalb nur noch Komponenten vorhanden, die absolut notwendig sind. Jetzt folgt die Konfiguration der Funktionen, die in diesem Profil bereit stehen sollen – konkret: Welche Menübefehle Dr. Fiebich in Packages, Anforderungen, Anforderungsdiagrammen und Dokumenten zur Verfügung stehen. Drei Komponenten müssen bearbeitet werden:

1. Zu den Anforderungen an das Nutzungsprofil gehört, dass die im Projekt definierten Anforderungen mit Ihren Beziehungen betrachtet, aber nicht bearbeitet werden können. Die Bearbeitungsfunktionen der Komponente RequirementComponent müssen also sowohl für Sichten, als auch für Anforderungsdiagramme deaktiviert werden.

2. Die Befehle im Kontext eines Package ausgeblendet werden, denn Dr. Fiebich soll auch keine neuen Elemente erzeugen können. Dafür ist die Packagekomponente (PackageComponent) zuständig.

3. Damit Dr. Fiebich Dokumente öffnen, aber nicht bearbeiten kann, muss die OfficeCoreComponent bearbeitet werden. In ihr sind alle Funktionen zum Bearbeiten von MS Word-Dokumenten und Word-Templates zu finden.

Alle drei Schritte können Sie im nächsten Video verfolgen (5:01 min):

More

Tags: , , , , ,

Den Workspace im objectiF® Requirements Modeller rollenspezifisch zuschneiden - Teil 3

Written by Michael Dutz on 2/5/2013 9:02:00 AM

Teil 3: Nicht benötigte Komponenten ausblenden

In Teil 2 dieser Reihe habe ich Ihnen gezeigt, wie Sie im objectiF Requirements Modeller Packages aus einem Profil für einen Benutzer bzw. eine Projektgruppe ausblenden. Zwei Dinge sind noch zu tun: Im Profil „Anforderungen verfolgen“ kann ein Mitglied der Klinikleitung noch Funktionen ausführen, die nicht zu seiner Rolle gehören, wie das Anlegen und Bearbeiten von Zielen und weiteren Elementen. Diese Funktionen müssen deaktiviert werden, denn Dr. Fiebich soll Zugriff auf angelegte Dokumente, Anforderungen und Anforderungsdiagramme haben, nicht aber neue anlegen können.

Die Konfiguration der Funktionen in einem Profil erfolgt unter Komponenten:


Abb. 1: Die Komponenten eines Nutzungsprofils

Welche Komponente für was zuständig ist, erkennen Sie am Namen, RequirementsComponent liefert alle Teile für die Modellierung von Anforderungen und Anforderungsdiagrammen, GoalComponent alles für die Modellierung von Zielen und Stakeholdern usw. Komponenten die für Mitglieder der Gruppe „Klinikleitung“ keine Relevanz haben, können vollständig deaktiviert werden – vorausgesetzt aus ihnen wird nichts an anderer Stelle benutzt. Ein Beispiel: Wenn die Testfälle in einem Anforderungsdiagramm sichtbar sein sollen, muss die zuständige Komponente (TestComponent) aktiviert bleiben.

More

Tags: , , , , ,

3 Wege durch das Requirements Engineering: Zum Schluss off-road von abstrakten Zielen über Anwendungsfallszenarien zu Anforderungen

Written by Ursula Meseberg on 1/29/2013 8:23:00 AM

Hier ist nun der letzte Teil der Serie "3 Wege durch das Requirements Engineering". Nach angenehmer Fahrt  über die Autobahn – von Stakeholder-Anforderungen zur Systemarchitektur – und der zumindest gut ausgeschilderten Landstraße – von Stakeholder-Zielen zur Systemarchitektur – geht es heute für den Requirements Engineer ins Gelände: Der Stakeholder bleibt bei der Formulierung seiner Ziele auf hohem Niveau stecken, liefert wenig Konkretes und schon gar keine Anforderungen. Wie kann man abstrakte Ziele gemeinsam mit dem Stakeholder konkretisieren und daraus Anforderungen ableiten? Durch …

…die Macht des Beispiels

Wie soll die Interaktion mit dem zu entwickelnden System bei einer konkreten Aufgabe aussehen? Das ist die Schlüsselfrage, die dem Requirements Engineer aus dem unwegsamen Gelände heraushilft. Sie führt zur Entwicklung von Szenarien, von denen jeweils mehrere in einem Anwendungsfall zusammengefasst werden. Aus den Szenarien lassen sich  – meistens jedenfalls – Anforderungen an das zu entwickelnde System ableiten.

Schauen Sie sich das doch einmal im Film an: Er zeigt (in gut 20 Minuten - off-road dauert es halt etwas länger), wie Sie mit dem objectiF Requirements Modeller den Zielen der Stakeholder konkrete Anwendungsfälle zuordnen und zu jedem Anwendungsfall Szenarien definieren. 

Die Textschablone für Anwendungsfälle und die zugehörigen Szenarien bietet das Tool als Bildschirmformular an. Sie können also – solange Sie wollen – textorientiert arbeiten. Modelle sind, wenn Sie mit diesem Tool arbeiten, immer eine Option, nie ein Muss. Je mehr Anwendungsfälle Sie definieren, umso nützlicher werden allerdings Anwendungsfalldiagramme. Sie können sie jederzeit – auch zu bereits mit Text beschriebenen Anwendungsfällen – anlegen. Anwendungsfalldiagramme unterstützen die Orientierung und helfen bei der Navigation. Szenarien können Sie im objectiF Requirements Modeller alternativ auch mit Aktivitätsdiagrammen beschreiben.

Was die Notation von Anwendungsfall- und Aktivitätsdiagrammen angeht, so ist unsere Haltung: weniger ist mehr. Je einfacher, umso hilfreicher sind Diagramme in der Kommunikation mit den Stakeholdern.

Was gewinnen Sie durch die Entwicklung von Szenarien im Requirements Engineering?

Einerseits sind Szenarien – weil sie Lösungswege beispielhaft beschreiben – konkreter als Ziele. Andererseits sind sie gerade für Stakeholder verständlicher als die daraus abgeleiteten Anforderungen an das System. Sie bilden damit genau die Kommunikationsebene, auf der sich Stakeholder und Requirements Engineer wohl am ehesten treffen können.

objectiF Requirements Modeller sorgt dafür, dass der Weg von Zielen über  Anwendungsfälle und Szenarien zu Anforderungen und schließlich zu Systemelementen ohne Mühe nachvollziehbar bleibt.

Der Weg durch das Gelände – so unpassierbar ist er also gar nicht.

Tags: , , , , ,