REConf®2017- Rückblick

Erstellt am 21 September 2017
von Schreibe einen Kommentar

Unsere diesjährige REConf®2017, die größte Konferenz zum Thema Requirements Engineering im deutschsprachigen Raum, fand vom 27. bis 31. März 2017 im Holiday Inn München City Center im Herzen von München statt. Wie jedes Jahr war die REConf® wieder sehr gut besucht. Neben interessanten Vorträgen und Workshops gab es für die Teilnehmer genügend Raum für Diskussionen und persönlichen Austausch mit anderen Teilnehmern, aber auch mit den Referenten.

Ping-Pong ohne Pong

Erstellt am 7 September 2017
von Schreibe einen Kommentar
This entry is part 5 of 5 in the series Textuelle Anforderungen

Tischtennis oder Tennis sind in unserer Gesellschaft beliebte Spiele bzw. Disziplinen, an denen wir uns gerne messen und Spaß haben. Das Prinzip basiert darauf, dass jeder Spieler für sich seinen Schlag vorbereitet und ausführt (Ping). Der andere bekommt den Ball und reagiert in gleicher Weise wieder durch eine selbständige Vorbereitung und Ausführung des Gegenschlages (Pong).

In der Entwicklungsrealität haben wir dieses Prinzip in vielen Bereichen auch übernommen. Um dies näher zu beleuchten, zunächst ein Beispiel dazu.

Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Anforderungen strukturieren

Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?

Heisse Anforderungen und späte Änderungen

Erstellt am 4 Juli 2017
von Schreibe einen Kommentar

Das zweite agile Prinzip handelt nicht etwa von zu warmen Anforderungen an denen man sich die Finger verbrennt (die Überschrift enthält kein „ß“), sondern stellt in der Produktentwicklung vielmehr ein ungeschriebenes Gesetz dar.

Ein Hardware Scrum Hackathon

Erstellt am 15 Juni 2017
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Hardware Scrum

Natürlich funktioniert Scrum auch für Hardware- und Systementwicklung. Dafür gibt es inzwischen genügend erfolgreiche Beispiele, viele an denen HOOD aktiv mitgearbeitet hat. Klar, es gibt ein paar Besonderheiten und einige Herausforderungen sind anders gelagert als in reinen Softwareentwicklungen, aber der Methoden-Bauchladen ist inzwischen voll genug um für unterschiedlichste Domänen passende Praktiken anbieten zu können. Einen signifikanten Unterschied gibt es aber nach wie vor in der Menge an Skepsis, die uns entgegen schlägt, wenn wir HW- und Systemingenieure in der agilen Transformation begleiten. Dabei ist der Wunsch, in kürzeren Zyklen risikoärmer auf Kundenfeedback reagieren zu können, durchaus genauso stark ausgeprägt wie bei den Softwareentwicklern.

Requirements Austausch ist Silber – Virtuelle Zusammenarbeit ist Gold

Erstellt am 14 Juni 2017
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Projektmanagement

 

Er hat der Forschung viele Rätsel aufgegeben, der um 820 entstandene sogenannte St. Galler Klosterbauplan. Heute geht man davon aus, dass es sich um einen Entwurf als Grundlage für einen weiteren eigenständigen Planungsvorgang handelt, der zwischen Auftraggebern und den Bauverantwortlichen ausgetauscht und besprochen wurde.

Das Ende des Requirements Engineerings wie wir es kennen

Erstellt am 1 April 2017
von 3 Kommentare

Nun ist es passiert ! Nach jahrhundertelangem Bemühen der Menschheit, den Weg von der Idee in die Realisierung zu verkürzen, ist der Durchbruch geschafft. Was haben sich Informatiker Gedanken über die semantische Lücke gemacht, was hat man Sprachen erfunden, um es für verschiedenste Fachdomänen praktischer zu machen, sich Hilfssysteme zu bauen. Es war immer die Hoffnung, dass wenn das Problem formuliert ist, die Lösung damit auf dem Tisch liegt.

Da hat man z.B. COBOL in die Welt gesetzt, um Wirtschaftlern  eine direkte Möglichkeit zu geben, einer Maschine sagen zu können, was man möchte. Da wurde SQL erfunden, so dass jedermann auf der Straße mal eben eine Datenbank abfragen könnte. Es ließen sich tausende weitere Beispiele und Versprechungen aufzählen, die nach einem ähnlichen Muster gestrickt sind.

Haben Sie zu viel Geld?

Erstellt am 25 Januar 2017
von Schreibe einen Kommentar

Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?

Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016

Erstellt am 8 November 2016
von Schreibe einen Kommentar

Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, abbildung05wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese „zwei Gebiete“ immer mehr zusammenwachsen und gemeinsam betrachtet werden.

TdSE 2016 – Trends im Systems Engineering

Erstellt am 2 November 2016
von Schreibe einen Kommentar

Dieses Jahr fand der Tag des Systems Engineerings (TdSE) vom 25. bis zum 27.10.2016  in Herzogenaurach statt. Die gut besuchte Veranstaltung bot den Teilnehmern in Tutorials und Vorträgen viel Abwechslung und neue Informationen rund um das Systems Engineering (SE). Unter vielen Themen kristallisierte sich das Model-Based Systems Engineering (MBSE) als eines der Hauptthemen heraus. In der Zukunft wird der Einsatz von Modellen bei der Entwicklung von komplexen Systemen mit interdisziplinären Teams die durchgängige Basis sein.