Vortrag von Johannes Motz, Kapsch CarrierCom AG, Wien

Die Unterstützung für das Testmanagement, die Sie in der in-Step Version 4.10 finden, geht auf eine Lösung zurück, die in Zusammenarbeit zwischen der Kapsch CarrierCom AG und microTOOL entstanden ist.

Kapsch CarrierCom setzt seit mehreren Jahren in-Step als firmenweite Lösung für das Anforderungsmanagement und für die Steuerung von Entwicklungsprojekten ein. Zur Bereinigung seiner Tool-Landschaft beschloss das Unternehmen 2012, bestehende Lösungen für das Testmanagement abzulösen und durch in-Step zu ersetzen. Johannes Motz berichtet in seinem Vortrag, den er am 24. April 2013 in Berlin gehalten hat, über die speziellen Herausforderungen dieses Projekts. Dazu gehörte u.a. der Umstieg in „lebenden“ Projekten – also die Operation am offenen Herzen.

Wie ist das Vorhaben geglückt? Die Antwort erfahren Sie in diesem Videomitschnitt (29:55 Minuten) von unserer diesjährigen NutzerKonferenz.

Wer ist der Referent?

DI Johannes Motz ist seit 1984 bei Kapsch in Leitungsfunktionen im Bereich Qualitätssicherung und Entwicklung, seit 1999 bei Kapsch CarrierCom tätig. Derzeit leitet er eine Entwicklungsgruppe im Bereich Technology & Services und ist als Prozessverantwortlicher für den Entwicklungsprozess und als Firmenvertreter in der Mitgliederversammlung des Forschungszentrums ftw tätig. Er leitet gegenwärtig das Projekt DPE (Design Process Enhancement).

Wir danken Johannes Motz für die Erlaubnis, seinen Vortrag zu veröffentlichen. 

Für die Erstellung unserer Konferenzfilme danken wir:

Aaike Stuart
StuartFilm
www.stuartfilm.nl

Auf unseren NutzerKonferenzen gibt es einen festen Programmpunkt: Mindestens ein Vortrag stammt immer aus unserer Beratungspraxis. Darin geht es um typische Kundenprojekte des zurückliegenden Jahres. Mirko Pracht, der Leiter unseres Bereichs Customer Services, hat auf der diesjährigen NutzerKonferenz im April in Berlin zwei Themen herausgegriffen, die gleich mehrere in-Step Anwender im Jahr 2012 beschäftigt haben:

Zu einen geht es um den Einsatz von in-Step für das Management von Kundenanforderungen in Unternehmen, die Produktentwicklung betreiben. Wie kommen die Kundenanforderungen in die Projekte einer Organisation? Wie organisiert man Kunden- und Systemanforderungen? Wie macht man die Beziehung zwischen Systemelementen, Systemanforderungen und Kundenanforderungen nachvollziehbar? Mirko Pracht betrachtet drei Lösungsansätze und bewertet sie.

Zum anderen geht es um die Unterstützung des Testmanagements mit in-Step. Mirko Pracht erläutert hier die Lösung, die inzwischen Produktbestandteil von in-Step geworden ist.

Sehen Sie in den Vortrag doch einfach mal hinein (25:06 Minuten).

Sie erfahren darin übrigens auch Details zu unseren neuen Seminaren und Webinaren, mit denen wir Sie beim Einsatz von in-Step und dem objectiF Requirements Modeller sowie bei der Vorbereitung zur Prüfung zum Certified Professional for Requirements Engineering unterstützen wollen.

Die Reihe der Filme von der 23. microTOOL NutzerKonferenz setzen wir ab der nächsten Woche mit Mitschnitten von Anwenderberichten aus ganz unterschiedlichen Branchen fort. Also schauen Sie wieder mal vorbei.

Für die Erstellung unserer Konferenzfilme danken wir:

Aaike Stuart
StuartFilm
www.stuartfilm.nl

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

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

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.

Das neue Jahr hat schon  Fahrt aufgenommen. Machen wir uns also auch wieder auf den Weg - durch das Requirements Engineering.

Die komfortable Strecke über die Autobahn von den Stakeholder-Anforderungen zur Systemarchitektur, die ich Ihnen beim letzten Mal im Film gezeigt habe, ist in der Praxis wohl eher eine Wunschvorstellung: Selten formulieren Stakeholder bereits zu Projektbeginn klare Anforderungen. Oft wissen sie zwar ganz genau, wo sie hin wollen. Das heißt, sie kennen ihre fachlichen und wirtschaftlichen Ziele. Aber daraus konkrete Anforderungen an ein neues System abzuleiten, das erfordert dann doch den Einsatz des Requirements Engineers.

Wie kommen Sie als Requirements Engineer auf dieser zwar ganz gut ausgeschilderten, aber doch recht holprigen Landstraße zu Anforderungen und schließlich zur Spezifikation des neuen Systems? Die Antwort heißt:

Ziel eingeben – Zielführung starten

Oder anders gesagt: einen zielorientierten Ansatz des Requirements Engineering verfolgen.

Ein Ziel ist eine Eigenschaft, die durch das System erreicht werden soll. Haben Sie Ziele gefunden und dokumentiert, dann können Sie sich fragen, wie jedes einzelne Ziel durch das zu entwickelnde System verwirklicht werden kann. Diese Frage führt Sie zu den Anforderungen an das System. Anders ausgedrückt: Anforderungen beschreiben die Zielerfüllung.

Allerdings, ganz so einfach wie es klingt, ist es dann doch nicht. Nicht selten gibt es zwischen den Zielen der Stakeholder Konflikte. Eine Zielanalyse mit einfachen Zieldiagrammen hilft, diese Konflikte aufzudecken und nach Lösungen zu suchen. Deshalb finden Sie im objectiF Requirements Modeller eine sehr einfache Notation für Zieldiagramme - so einfach, dass Ihre Stakeholder nach ein paar kurzen Erläuterungen vermutlich die Zieldiagramme schnell lesen können und Sie eine Diskussionsgrundlage haben.

Wie der Weg über die Landstraße zu den Anforderungen und der Systemararchitektur mit dem objectiF Requirements Modeller aussieht, zeigt der nachfolgende Film (ca. 15 Minuten – klar, etwas länger als der Weg über die Autobahn dauert dieser hier schon).

Und das nächste Mal verlassen wir die Straße. Es geht ins Gelände, nämlich dann, wenn die Ziele der Stakeholder noch sehr abstrakt sind.

microTOOL wünscht Ihnen allen – liebe Anwender, Interessenten und Partner – ein gesundes neues Jahr und viel Glück für Ihre beruflichen und privaten Vorhaben 2013.

microTOOLs Kalender ist für das neue Jahr schon reichlich gefüllt. Hier eine kleine Vorschau …

More

Vor ein paar Tagen bin ich in einem Blog auf einen kurzen Post mit dem Titel „Wer liefert eigentlich Anforderungen an das System?“ gestoßen. Die Antwort erhält man als Leser gleich im ersten Satz: die Stakeholder. Die Schlüsselrolle der Stakeholder für die Anforderungsermittlung, die Aspekte, die man pro Stakeholder festhalten sollte und der Hinweis, dass diese Informationen kontinuierlich zu pflegen sind – das bringt der Beitrag sehr schön auf den Punkt. Ich möchte daran anknüpfen und die Frage beantworten: Wenn man die Stakeholder kennt, was dann? Wie kommt man zu den Anforderungen und zur Systemspezifikation?

Es gibt drei vom „Gelände“ abhängige Wege. Heute starte ich mit dem günstigsten Fall – sozusagen …

Über die Autobahn von der Stakeholder-Anforderung zur Systemarchitektur

Diesen Weg können Sie gehen, wenn die Stakeholder ihre Anforderungen gut kennen und benennen können. Der Requirements Engineer muss im Anschluss an die Befragung der Stakeholder die Anforderungen dann „nur noch“ ausformulieren, detaillieren, verfeinern und vervollständigen, „zu Papier“ bringen, gewichten und abstimmen. Parallel dazu kann er in einem iterativen Prozess daran gehen, die Systemkomponenten zu entwerfen, die später die Anforderungen erfüllen sollen. Wenn die Stakeholder-Anforderungen schon klar auf dem Tisch liegen, worin besteht dann noch die Herausforderung für den Requirements Engineer? Darin:

• bei zunehmender Komplexität den Überblick zu behalten und
• den Weg von den Stakeholder-Anforderungen zum Systementwurf und umgekehrt nachvollziehbar zu machen, damit die Auswirkungen von veränderten Anforderungen schnell erkannt werden können.

Wie kann man diese Herausforderung meistern? Wo immer es darum geht, Komplexität beherrschbar zu machen und Nachvollziehbarkeit herzustellen, sind Diagramme das Mittel der Wahl. Im Requirements Engineering sind es speziell die der UML/SysML und ganz besonders das – leider noch viel zu wenig bekannte – Anforderungsdiagramm.

Wie die Fahrt über die Autobahn durch das Requirements Engineering – unterstützt durch den objectiF Requirements Modeller – aussieht, zeigt Ihnen dieser Film (ca. 10 Minuten):

Demnächst zeige ich Ihnen ...

More

Seit Ende August gibt es ihn nun – den objectiF Requirements Modeller. Im September haben wir das neue Tool auf mehreren Workshops vorgestellt und uns über das lebhafte Feedback gefreut.

Da kamen zum Beispiel Anregungen wie diese: „Was Sie uns da gezeigt haben, also Auswertungen der Ziele, Stakeholder oder Anforderungen zu machen und diese dann ins Pflichtenheft in Word zu generieren, das ist schon sehr schön. Aber hilfreich wäre auch, wenn man mit dem Tool einfach Excel-Tabellen erzeugen könnte.“ Oder zum selben Thema: „Ein Excel-Export der Anforderungen wäre gut. Dann könnten wir die Anforderungen per Excel-Import auch für die Projektplanung nach in-Step reinziehen.“

Die Anregungen und Wünsche, die das Workshop-Team mitgebracht hat, hat es direkt in die Entwicklung gegeben. Und siehe da: Einiges davon ist in der Version 1.1, die es seit Kurzem gibt, schon umgesetzt.

Dazu gehört auch der Wunsch nach einem MS Excel-Export – einer einfachen, pragmatischen, aber wirksamen Funktion, die für alle Auswertungen im objectiF Requirements Modeller zur Verfügung steht.

Aber sehen Sie am besten selbst. Hier kommt ein kurzer Film dazu …

More

Teil 8: Bearbeitungsstände für das Team sichtbar machen und Workflows zustandsabhängig automatisieren

Ein großer Schritt ist getan: Die Version 1.0 des objectiF Requirements Modellers ist jetzt verfügbar. Die grundlegenden Funktionen für das Requirements Engineering, die das neue Tool anbietet, habe ich hier in den letzten Monaten beschrieben. Dabei ging es meistens ums Modellieren – von Zielen bei der Stakeholder-Analyse, von Szenarien, Requirements etc. Aber das Tool kann viel mehr.

Allerhöchste Zeit also, Ihnen die Sahnehäubchen vorzustellen: die Funktionen für das Requirements Engineering im Team.

Die Team-Funktionen des neuen objectiF Requirements Modellers im Überblick. 

Auch das will ich wieder in mehreren Schritten tun. Heute geht es um das Sichtbarmachen von Bearbeitungszuständen und das Automatisieren von Abläufen mit Hilfe von Zustandsautomaten. (Als in-Step-Anwender kennen Sie diese Technik. Hier erleben Sie sie in neuem Gewand.) 

Dazu habe ich wieder einen kurzen Film vorbereitet.

More