Austausch von Anforderungen, aber richtig! – Teil 1

Erstellt am 10 April 2012
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Anforderungsaustausch

In dieser zweiteiligen Blogreihe fassen wir unsere Erfahrungen mit dem Anforderungsaustausch an der Schnittstelle von OEM und Lieferanten zusammen. Im Vordergrund steht hier nicht die technischen Herausforderungen beim Datenaustausch sondern die flankierenden Maßnahmen, welche für einen erfolgreichen Datenaustausch essentiell sind. Hierunter fallen z.B. eine detaillierte Dokumentation der Ziele und Prozesse des Anforderungsaustausches.

Verfolgbarkeit ja und dann?

Erstellt am 3 April 2012
von Schreibe einen Kommentar

Das habe ich mich – und sicher auch Sie sich – schon oft gefragt.

DOORS, ein weit verbreitetes RE Werkzeug, bietet 8 verschieden Funktionen an, Links zu erstellen. Also Objekte miteinander in Beziehung zu setzen und Verfolgbar zu machen. Auch die Werkzeuge die Sie verwenden, haben sicher eine Funktion wie man solche Trace Links erzeugen kann.

Und warum brauchen wir solche Funktionen?

Wie viel Formalisierung benötigt ein Modell?

Erstellt am 27 März 2012
von Schreibe einen Kommentar

Formalisierung von Modellen

Abstraktion durch Modellierung ist im Software- und Systems-Engineering ein bewährtes Mittel. Darstellungen, die auf bestimmte Aspekte reduziert sind, helfen den Projektbeteiligten dabei, hohe Komplexität zu beherrschen. Darum wird in vielen Projekten auch großer Aufwand in das Erschaffen von Modellen investiert. Dieser Aufwand ist umso höher, je mehr formale Kriterien das Modell erfüllen muss. An dieser Stelle stellt sich die Frage, wie viel Formalisierung ein Modell denn tatsächlich benötigt, um seinen Zweck zu erfüllen.

Geglückter Start ins agile Zeitalter?

Erstellt am 20 März 2012
von Schreibe einen Kommentar

Letzte Woche hat mich ein Kunde darum gebeten, aus meiner Sicht zu beschreiben, wie ihm der Einstieg ins agile Arbeiten geglückt ist. Die Fragen waren gar nicht so leicht zu beantworten, haben mich aber zum Nachdenken gebracht. Was sind die Faktoren, für einen guten Start?

Sustainable Requirements Engineering

Erstellt am 6 März 2012
von Schreibe einen Kommentar

Sustainable Requirements Engineering (Sustainable RE) ist das nachhaltige und nutzbringende Anwenden sowie das ständige Optimieren von Requirements Engineering in einer Organisation.

Ein Unternehmen hat den Zustand des Sustainable RE erreicht, wenn

  • dessen Management vom Nutzen eines Requirements Engineering in der Software- und Systementwicklung überzeugt ist und das stetige Verbessern des Requirements Engineerings im Unternehmen für alle sichtbar unterstützt,
  • eine funktionierende RE Infrastruktur etabliert ist,
  • eine RE Kultur sich bei den Mitarbeitern und Organisationseinheiten des Unternehmens breit gemacht hat, und
  • wenn alle diese drei Elemente (Management Commitment, RE Infrastruktur und die notwendige RE Kultur) eng miteinander verzahnt sind und eine Einheit bilden.

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 2: Die Produktlinieninfrastruktur

Erstellt am 28 Februar 2012
von Schreibe einen Kommentar
This entry is part 2 of 13 in the series Produktlinien

Die Produktlinieninfrastruktur ist der Ausgangspunkt für die Entwicklung eines Produktes (Systems) innerhalb einer Produktlinie. Wesentlicher Bestandteil der Produktlinieninfrastruktur sind Komponenten, die im Entwicklungsprozess in spezifische Systeme umgesetzt und somit wiederverwendet werden können.

Wie komme ich nun aber zu einer Produktlinieninfrastruktur? Der Entwicklungsprozess einer Produktlinieninfrastruktur, auch Domain Engineering genannt, setzt sich aus den in Abbildung 1 dargestellten Phasen

Schwarz und Weiß gegen Grau – Die Verführung der Extreme und wie man wiederstehen kann!

Erstellt am 21 Februar 2012
von Schreibe einen Kommentar

Eine Analyse

Was ich in den letzten Jahren persönlich erlebt habe und was man darüber hinaus in der Geschichte der Softwareentwicklung immer wieder beobachtet, ist die „Flucht ins Extreme“. Damit meine ich, dass immer wieder gerne versucht wird, entweder schwarz oder weiß zu sein. An dieser Stelle will ich darauf hinweisen, dass es für solche Extreme durchaus notwendige Anwendungsfälle gibt. Aber die Erfahrung zeigt, eine Vielzahl von Entwicklungsprojekten liegen im „grauen“ Bereich.

Reif, reifer, aber nicht überreif – Teil 2

Erstellt am 14 Februar 2012
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series HOOD Capability Model

Dies ist der zweite Beitrag einer Blogserie, die sich dem HOOD Capability Model (HCM) widmet. Andere Modelle, wie CMMI® oder SPICE®, haben zwar unsere Fähigkeiten verbessert, Systeme aus Anforderungen zu entwickeln, nicht aber unsere Fähigkeiten, Anforderungen aus Kunden zu entwickeln (siehe Teil 1 – Informationsmodell: welche WARUM-Anforderungen gibt es und wie leite ich die WAS-Anforderungen daraus ab?). Hier setzt HCM an.

Das HCM besteht eigentlich aus zwei Reifegradmodellen, eines für die Anforderungsdefinition (HCM-RD) und eines für das Anforderungsmanagement (HCM-RM).

Agiles Spezifizieren: Just in Time für User Stories

Erstellt am 31 Januar 2012
von Schreibe einen Kommentar

Es ist mir schon fast unangenehm, das Wort agil nun auch in diesem Kontext zu verwenden. Jedoch halte ich es für notwendig, einen genaueren Blick darauf zu werfen, was bei der Spezifikation von Anforderungen in einem agilen Umfeld zu beachten ist. Zu oft sehe ich, dass nun statt umfangreichen Spezifikationen noch umfangreichere Mengen von umfangreichen User Stories entstehen.

Agiles Arbeiten bedeutet für alle Beteiligten – nicht nur für Requirements Engineers – an vielen Stellen ein Umdenken.

Formulierungstipps – Teil 3

Erstellt am 24 Januar 2012
von Schreibe einen Kommentar
This entry is part 4 of 5 in the series Textuelle Anforderungen

Alle Systemausgaben sollen in der Datenbank DB34 gespeichert werden.

Sehen wir uns heute die oben stehende Anforderung genauer an. Dem
erfahrenen Autor sollte sofort der verwendete Universalquantor “Alle” auffallen,
wodurch die Eindeutigkeit dieser Anforderung leidet. Sollen wirklich alle
Systemausgaben gespeichert werden? Oder sollen nur bestimmte Fehlerfälle
gespeichert werden?