Anforderungsschablonen – Erfahrungen beim Spezifizieren mit einem Anforderungsschablonen-Tool

Erstellt am 22 Oktober 2013
von Schreibe einen Kommentar

Beim Schreiben von Anforderungen steht ein Requirements Engineer mit jeder einzelnen immer wieder vor einer großen Herausforderung: Das Schreiben von qualitativ hochwertigen Anforderungen. Der Einsatz von Anforderungsschablonen kann das Qualitätskriterium „Eindeutigkeit“ durch eine festgelegte Syntax unterstützen.

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 11: Variabilität und Use Case Diagramme

Erstellt am 15 Oktober 2013
von Schreibe einen Kommentar
This entry is part 11 of 13 in the series Produktlinien

Wie im letzten Blog zu Use Case Beschreibungen angekündigt, widmen wir uns heute der Beschreibung von Variabilität innerhalb von Produktlinien mittels Use Case Diagrammen.

In Teil 9 dieser Blog Reihe haben wir bereits eine graphische Notation, die eines Feature Models, zur Beschreibung von Variabilität kennengelernt. Im Gegensatz eines Feature Models bietet uns die Use Case Notation von Hause aus zunächst keine Möglichkeit sogenannte Variationspunkte (Optionen, Alternativen) und deren Abhängigkeiten untereinander abzubilden. Dies legt den Schluss nahe, dass Use Case Diagramme für die Beschreibung von Variabilität innerhalb der Produktlinieninfrastruktur (Domäne) ungeeignet sind.

Wiederverwendung von Anforderungen in Projektvarianten

Erstellt am 17 September 2013
von Schreibe einen Kommentar
Wiederverwendung von Anforderungen

Wiederverwendung ist in der Softwareentwicklung seit vielen Jahren ein essentielles Thema, und auch im Requirements Engineering lohnt es sich, darüber nachzudenken. Wenn es darum geht, in kurzer Zeit mehrere Varianten eines Systems zu entwickeln, welche zu Beginn des Produktlebenszyklus vollständig spezifiziert sein müssen, kann die Wiederverwendung von Anforderungen dem Requirements Engineer bei der Erstellung von Lastenheften eine Menge Zeit ersparen.

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 10: Variabilität und Use Case Beschreibungen

Erstellt am 10 September 2013
von Schreibe einen Kommentar
This entry is part 10 of 13 in the series Produktlinien

Im letzten Teil der Blog Reihe haben wir uns mit der Abbildung von Produktvariabilität mit Hilfe eines Feature Modells beschäftigt. Heute wollen wir uns ansehen wie man mittels Use Case Beschreibungen die Variabilität innerhalb einer Produktlinie beherrschen kann.

Der Kundenflüsterer

Erstellt am 13 August 2013
von Schreibe einen Kommentar

Eine wichtige Aufgabe des Requirements Engineers ist die Erstellung und Pflege der Systemspezifikation. Er leitet dazu Kundenanforderungen ab, spezifiziert diese auf einem angemessenen Abstraktionsniveau und bietet dadurch eine solide Arbeitsgrundlage für nachfolgende Entwicklungsaktivitäten, z.B. die Softwareentwicklung. Doch woher weiß der Requirements Engineer eigentlich, was der Kunde wirklich will?

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 9: Retrospektive: Komplexität der Variabilität beherrschen

Erstellt am 2 Juli 2013
von Schreibe einen Kommentar
This entry is part 9 of 13 in the series Produktlinien

Im dritten Teil dieser Blog Reihe haben wir uns mit dem Thema der „Variabilität innerhalb der Produktlinie“ beschäftigt. Da dies, wie damals schon beschrieben, die größte Komplexität in sich birgt, möchte ich dieses Thema an dieser Stelle nochmals aufgreifen.

Wir erinnern uns, dass die Variabilität innerhalb der Produktlinieninfrastruktur beschrieben und abgebildet wird, um daraus Produkte ableiten zu können. Die Herausforderung ist es, die Variabilität einzelner Anforderungen eindeutig zu beschreiben und gleichzeitig den Entscheidungsprozess bei der Ableitung eines Produkts zu unterstützen. Da wir im dritten Teil nur eine Möglichkeit betrachtet haben, möchte ich hier gerne einige weitere Möglichkeiten mit Ihnen diskutieren.

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 8: Die Unternehmensstruktur für ein produktlinienorientiertes Anforderungsmanagement

Erstellt am 28 Mai 2013
von Schreibe einen Kommentar
This entry is part 8 of 13 in the series Produktlinien

Nachdem wir uns in den vorangegangen Teilen der Blogreihe sehr viel mit dem Aufbau einer Produktlinie (ihrer Produktlinieninfrastruktur und ihrer Produkte) beschäftigt haben, wollen wir uns heute dem Menschen, der letztendlich mit den vorgestellten Konzepten arbeiten muss und für die Entwicklung der Produkte verantwortlich ist, widmen.

Auf die folgenden Fragen möchten wir heute gerne Antworten geben:

Welche Rollen bzw. Verantwortlichkeiten muss es für das Anforderungsmanagement für Produktlinien geben? Welche Beziehungen, im Sinne von Kommunikation, bestehen zwischen diesen Rollen? Und, wie sind sie im Unternehmen oder der Organisation eingegliedert strukturiert?

„Schon wieder von vorn?“

Erstellt am 21 Mai 2013
von 1 Komment

In der Systementwicklung kommt es häufig vor, dass verschiedene Endprodukte für verschiedene Kunden beträchtliche Gleichanteile aufweisen – wäre es dann nicht sinnvoll, das gesammelte Wissen und gewonnene Erfahrungen zu konservieren und weiterzuentwickeln, sodass zukünftige Projekte davon profitieren können? In diesem Beitrag möchte ich ein einfaches ReUse-Konzept vorstellen und dessen Vorteile beleuchten, aber auch anstehende Herausforderungen aufzeigen.

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

Erstellt am 23 April 2013
von Schreibe einen Kommentar
This entry is part 7 of 13 in the series Produktlinien

Der 6 .Teil der Blogreihe befasste sich mit der Entstehung bzw. Ableitung eines Produktes aus der Produktlinieninfrastruktur. Heute stellen wir uns die folgenden  Fragen:

Was passiert nachdem ein Produkt spezifiziert wurde? Besteht noch ein Zusammenhang zwischen Produkt und Produktlinieninfrastruktur? Besteht die Notwendigkeit an einem solchen Zusammenhang? Wie lässt sich dieser pflegen und dokumentieren?

Wer liefert eigentlich Anforderungen an das System?

Erstellt am 20 November 2012
von 1 Komment

Stakeholder! Und das ist kein Synonym für Auftraggeber, sondern beinhaltet viel mehr.

Klären wir zunächst was ein Stakeholder überhaupt ist: Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat. Damit ist der Auftraggeber natürlich ein Stakeholder, aber sicher nicht der einzige.