Nachhaltiges Requirements Engineering in “Brownfield” Projekten

Erstellt am 10 Juni 2014
von Schreibe einen Kommentar

Die „Motivation für RE und dessen Einführung“ ist laut aktuellen RE-Kompass [http://www.re-kompass.de/fileadmin/project/re-kompass.com/uploads/documents/Ergebnisbericht_RE-Kompass_2013.pdf] die größte Herausforderung im Requirements Engineering (RE). Doch wie können wir dies nicht nur in Greenfield sondern auch in Brownfield-Projekten erreichen?

Brownfield bedeutet, dass in einem Unternehmen schon erste Anstrengungen RE zu verbessern, stattgefunden haben und die Beteiligten damit schon arbeiten. Dagegen gibt es bei Greenfield noch kein klar definiertes RE im Unternehmen.

Informatik schafft sich selber ab – Generative Programmierung macht ganze Berufsfelder überflüssig!

Erstellt am 1 April 2014
von Schreibe einen Kommentar

Software-Entwicklern, Software-Testern, Informatik-Professoren, ja ganzen Studienzweigen in der Informatik droht das Aus – im wahrsten Sinne des Wortes. Die Emergenzforschung am Massachusetts Institute of Technology (MIT) überraschte in der aktuellen Ausgabe des renommierten „Nature Methods“ mit einem Bericht zur generativen Programmierung. Der Durchbruch gelang …

FORPS gefällig?

Erstellt am 25 Februar 2014
von Schreibe einen Kommentar

FORPS hat weder etwas mit dem Wirtschaftsmagazin FORBES noch mit FURPS, dem Ansatz SW-Qualitätsanforderungen zu finden, zu tun. Obwohl durch FORPS Projekte von FORBES besser laufen können und FORPS Sie bei der Findung von Anforderungen auch indirekt unterstützen kann.

Requirements Engineering, Mobile Computing & die Cloud – Teil 1

Erstellt am 21 Januar 2014
von Schreibe einen Kommentar
This entry is part 1 of 3 in the series Mobiles Requirements Engineering

Die Nutzung mobiler Apps stieg im vergangenen Jahr durchschnittlich um 115 Prozent (Quelle: zdnet). Einen großen Teil dazu beigetragen haben vor allem Messaging Apps wie Facebook, Twitter oder WhatsApp, aber auch die sogenannten Produktivitätsanwendungen („Utilities & Productivity Apps“ wie Evernote oder Quip). Die Anzahl und Verwendung mobiler Endgeräte, dazu zählen vorrangig Smartphones und Tablets, nimmt also rasant zu.

Kosten, Zeit und Qualität optimieren: Anforderungsmanagement für Produktlinien – Teil 13: Variabilität in UML

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

Wie im letzten Blog Nummer 12 angekündigt werden wir in diesem Teil die UML in Bezug auf Abbildung von Variabilität betrachten.

In den Teilen 10 und 11 sind wir bereits auf Use Cases eingegangen. Heute wollen wir die folgenden weiteren UML Diagramme untersuchen:

  1. Klassendiagramme
  2. Sequenzdiagramme

Konsens oder Kompromiss? Eine Entscheidungshilfe

Erstellt am 11 Dezember 2013
von Schreibe einen Kommentar

Bei meiner Arbeit mit agilen Teams erlebe ich immer wieder heftige und langwierige Diskussionen, wenn eine gemeinsame Lösung gefunden werden soll bzw. eine Entscheidung getroffen werden muss. Das kann z.B. die Einigung über eine technische Umsetzung sein oder auch eine Übereinkunft über die Zusammenarbeit im Team. Um diese Diskussionen abzuschließen, kommt es häufig zu einer Abstimmung, wobei die Mehrheit dann „Recht“ hat. Dabei besteht die Gefahr, daß ein Teil des Teams offen oder versteckt in den Widerstand geht und die Entscheidung nicht mitträgt. Um das zu vermeiden, aber auch, um diesen Konflikten möglichst aus dem Weg zu gehen, wird versucht, es allen recht zu machen. Es wird ein Kompromiss gesucht.

Stakeholder Management – More than a list

Erstellt am 26 November 2013
von Schreibe einen Kommentar
This entry is part 1 of 2 in the series Stakeholder-Management

In einer Studie, durchgeführt von Suzanne Robertson und Ian Alexander im Jahre 2004 (Understanding Project Sociology by Modeling Stakeholders)  wurden Beteiligte nach dem aus Ihrer Sicht größten Problem im Kontext der Stakeholder befragt. Die Ergebnisse reichen von unzulänglichem Budget und Zeit für die Arbeit mit Anforderungen für die Stakehoder, den nicht vorhandenen Fähigkeiten bei den Stakeholdern Anforderungen möglichst lösungsneutral zu formulieren, wie auch der Schwierigkeit die richtigen Stakeholder zu definieren. Weitere Punkte sind Kommunikationsprobleme zwischen der Entwicklung und der Tatsache, dass Stakeholder im Laufe der Entwicklung nicht durchgehend mitarbeiten.

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.

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?