Unsere Beraterin Christel Sohnemann ist die weltweit erste Person, die das neue Zertifikat Advanced Level für Requirements Engineerin bekommen hat. Gestern gratulierten Mitarbeiter des iSQI Christel zu der erfolgreichen Zertifizierung, die sich aus einem Multiple-Choice Teil und einer schriftlichen Hausarbeit zusammensetzt.

Seit April 2011 ist mit dem Advanced Level endlich die Aufbaustufe für das Requirements Engineering-Zertifikat verfügbar. Neben Akteuren aus der IT ist die Ausbildung zum CPRE besonders auch für Personen geeignet, die in Managementpositionen Entwicklungen lenken und fundamentale Entscheidungen treffen müssen.

Zulassungsvoraussetzung für die Prüfung zum Certified Professional for Requirements Engineering ist der Besitz des IREB® CPRE Foundation Level.

Die bewährten oose-CPRE-Vorbereitungskurse finden Sie hier:
[CPRE-FL] Certified Professional Requirements Engineering – Foundation Level (inkl. Zertifizierung)
[CPRE-AL-EC] Certified Professional Requirements Engineering – Advanced level, Elicitation and Consolidation (inkl. Zertifizierung)
[CTFL-AL-RM] Certified Professional Requirements Engineering – Advanced Level, Requirements Modeling (inkl. Zertifizierung)

oose ist Silver Sponsor des Swiss Requirement Day am 22.6. in Zürich.

Anforderungen sind die Achillesverse der Software- und Systementwicklung. Allerdings gelten die Methoden als dokumentenlastig und stehen in scheinbarem Widerspruch zu den modernen agilen Vorgehensweisen.

oose kombiniert das klassische Requirements Engineering mit agilen Techniken. Neben kundenspezifischer Workshops und Projektunterstützung bietet oose sein Erfahrungswissen hierzu im Seminar Agiles Requirements Engineering an.

Auf dem Swiss Requirement Day stellt unser Mitarbeiter Marcus Winteroll in seinem Vortrag Produktgestaltung mit Story Maps eine agile Technik vor, um einfach und pragmatisch einen guten Überblick über die Features des Produkts zu erhalten.

Mehr zum agilen Requirements Engineering…

Mehr über Story Maps…

Unser Geschäftsführer ist von INCOSE Schweden eingeladen worden, einen Vortrag zum Thema Variantenmodellierung im Kontext „Large Scale MBSE“ zu halten.

Neben Tim Weilkiens hält Erik Herzog einen Vortrag über die Erfahrungen von Saab im Bereich MBSE und Arnold Rudorfer von Siemens über MBSE im Bereich Medizintechnik.

 Der Vortrag findet am 4. April in Linköping statt.

Als eines der führenden Beratungshäuser im Bereich Requirements Engineering ist oose auch dieses Jahr wieder auf der REConf vertreten. Sie können uns vor Ort an unserem Stand treffen und Ihr Anliegen persönlich mit uns besprechen.

Oder besuchen Sie einen unserer Vorträge:

• Axel Scheithauer oose GmbH und Bernd Mau HPC Hamburg Port Consulting:   Nur nicht versanden: Ein Hafen für die Wüste – Erfahrungen bei der Geschäftsprozess- und Anforderungsanalyse für ein Hafenbetriebssystem
• Tim Weilkiens:   Das Zickzack-Muster – Jeder Anforderung wohnt eine Annahme inne

Interesse, aber keine Gelegenheit, den Vortrag auf der REConf zu besuchen? Fragen Sie unsere Sprecher nach konkreten Punkten oder buchen Sie sie für einen exklusiven Firmenvortrag bei Ihnen im Haus: axel.scheithauer(at)oose.de / tim.weilkiens(at)oose.de.

Damit bei agilen Projekten der Überblick nicht verloren geht, arbeiten Entwickler neuerdings mit Story Maps. Unser Berater und Trainer Marcus Winteroll erklärt die Methode im Interview mit der CIO: http://www.cio.de/scrum/2263776/

Story Maps sind bei uns u.a. Thema im Seminar Agiles Requirements Engineering.

In der Elektronik-Praxis ist der Artikel “Agiles Requirements Engineering – Klassisches Requirements Engineering und agile Entwicklungsprozesse kombinieren” von Tim Weilkiens erschienen.

Abstract:
Aktuelle Frameworks, Bibliotheken, Tools und andere technische Themen dominieren die Aufmerksamkeit der Softwareentwicklung. Die eigentliche Achillesverse ist aber das Requirements Engineering (RE). Was nützt das technisch ausgefeilste System, wenn der Kunde davon nur 30% haben wollte und davon wiederum nur 20% genauso funktionieren wie gefordert? Das klassische RE gilt oft als bürokratisch und unproduktiv. Beliebter sind agile Vorgehensweisen, die aber das RE nur begrenzt adressieren. Das agile Requirements Engineering, kurz ARE genannt, integriert die Disziplin des Requirements Engineering in den agilen Entwicklungsprozess.

Agile Verfahren wie Scrum beinhalten praktisch kaum Requirements-Engineering. Scrum verwendet eine einfache priorisierte Featureliste (Product Backlog genannt) und die wesentliche RE-Techniken sind Benutzergeschichten und die kontinuierliche direkte Kommunikation der Anforderungsbeteiligten. Viel mehr braucht Scrum nicht, damit Projekte erfolgreich laufen. Dies als Requirements-Engineering zu bezeichnen wäre etwas übertrieben. Gibt es also überhaupt ein agiles RE? Und falls ja, was ist agiles RE?

Zu diesen und weiteren Fragen habe ich einen Artikel geschrieben, der jetzt in der aktuellen Ausgabe 08/2010 des ix-Magazins erschienen ist.

Bernd Oestereich

Marcus Winteroll wird am 28.6. auf der SEACON in Hamburg einen Vortrag über Agiles Requirements Engineering halten.
In agilen Vorgehensweisen wie Scrum werden Anforderungen mit Hilfe von User-Stories beschrieben. Sie rücken die Kundensicht in den Vordergrund und sind einfach zu handhaben, stoßen aber bei komplexen Anforderungen schnell an Grenzen. Dies wird teils durch die agile Vorgehensweise wettgemacht: In der iterativen inkrementellen Entwicklung wird das zu entwickelnde System selbst zum Vehikel der Anforderungsanalyse, denn die Begutachtung der Inkremente durch den Kunden trägt zur Klärung der Anforderungen bei. Das heißt aber nicht, dass dieses Instrument immer das effektivste ist. Zuweilen gibt es ökonomischere Möglichkeiten, die Vorstellungen des Kunden zu schärfen, als ein reales System zu entwickeln. In dem Vortrag werden Werkzeuge vorgestellt, die helfen, Anforderungen zu verstehen – sowohl neuere Entwicklungen aus dem agilen Umfeld, wie Story-Maps, als auch klassische Instrumente, wie Anwendungsfälle. Was stellt eine sinnvolle Ergänzung agiler Vorgehensweise dar, um Anforderungen effektiver zu erheben und noch agiler zu werden? Um diese Fragen zu beantworten, wird eine agile Requirements-Engineering-Methode skizziert.
Zielpublikum: Anforderungsingenieure, Analytiker, Product Owner, Projektleiter
Voraussetzungen: Erfahrungen in agilen Projekten oder mit klassischem Requirements Engineering
Schwierigkeitsgrad: Mittel
Mehr über ARE erfahren Sie auf unserer Themenseite zum Agilen Requirements Engineering.

In der Xing-Gruppe ARE, die von Marcus Winteroll und mir moderiert wird, findet derzeit eine spannende Diskussion zum Thema “Was ist agiles Requirements Engineering?” statt. Marcus hat den aktuellen Diskussionsstand zusammengefasst:

---

Ich möchte mal versuchen, einige wichtige Punkte der spannenden Diskussion zusammenzufassen:

• Projekte brauchen ein gewisses Maß an Planbarkeit (welches?), Requirements Engineering, auch agiles, muss die Grundlage dafür legen.
• Es ist normal, dass Anforderungen sich im Projektverlauf ändern. Agiles Requirements Engineering sollte hiermit problemlos und ohne großen Aufwand zurechtkommen, also entsprechend flexibel sein.
• Dokumentation (aller Art) sind kein Selbstzweck, sondern sollen letztlich dazu dienen, für den Kunden einen Wert zu schaffen.
• Häufig werden aber auch Dokumente produziert, die keiner liest. Auf Dokumentation kann aber nicht vollständig verzichtet werden, da sie z.B. für die Abstimmung zwischen den Beteiligten gebraucht wird.
• Direkte Kommunikation spielt für das agile Requirements-Engineering eine sehr wichtige Rolle.
• Der Requirements-Engineer hat die Aufgabe zwischen fachlichen Vertretern und Entwicklern zu vermitteln.
• Überstrukturierung des Entwicklungsprozesses ist häufig ein Problem.
• Über Teamgrenzen hinweg sind andere Abstimmungsmechanismen notwendig, als innerhalb eines Teams.

Sind diese Punkte vielleicht konsensfähig?

In jedem Fall bleibt die spannende Frage, wieviel Dokumentation ist notwendig? Vertreter leichtgewichtiger agiler Verfahren wie Scrum oder XP werden hier sicher versuchen, die Anzahl der Dokumente radikal zu reduzieren und möglichst viel über direkte Kommunikation abwickeln. Ist das ein gangbarer Weg oder gibt es hier Grenzen?

Vielleicht muss man die Sache ja auch andersherum betrachten: Was sind die Aufgaben eines Requirements-Engineers und welche Dokumente untersützen ihn hier wirkungsvoll und welche Dokumente brauchen seine Kunden (auch die internen)? Gibt es vielleicht kostengünstigere Alternativen zur Erstellung von Dokumenten? Welche?

---

Hier können Sie gleich mit diskutieren: Was ist agiles Requirements Engineering?. Weitere Informationen zum Thema finden Sie auf unserer Themenseite Agiles Requirements Engineering.

Ab dem 1.8.2009 gilt der neue Lehrplan 2.0 für den CPRE-Foundation-Level. Derzeit ist noch die Version 1.3 gültig. Der neue Lehrplan wird ab dem 1.7.2009 auf den Internetseiten des IREB veröffentlicht.
Es gibt keine grundlegenden Änderungen, d.h. die geforderten Fähigkeiten eines CPRE-2.0-Kandiaten sind nicht anders, als die eines CPRE-1.3-Kandidaten. Bisherige Zertifikate behalten natürlich ihre Gültigkeit.
Unsere Vorbereitungskurse basieren ab dem 01.08.2009 auf dem neuen Lehrplan.
Wenn Sie über das Thema diskutieren möchten, empfehlen wir Ihnen unser Diskussionsforum bei Xing: http://www.xing.de/net/cpre.