Dokumentation von Anforderungen mit Code Based Modeling

Erstellt am 9 Juni 2015
von Schreibe einen Kommentar

Die Motivation
Kennen Sie die folgenden Situationen?

  • Wenn es auf ein Release zugeht, werden Good Practices wie das präzise Beschreiben der Anforderungen über Bord geworfen und alle Aufmerksamkeit auf das Fertigstellen der Software gelenkt.
  • Die Anforderungsdokumentation ist nach einiger Zeit nicht mehr auf dem aktuellen Stand, sie hinkt der Software hinterher.
  • Wenn die ursprünglichen Entwickler nicht mehr verfügbar sind oder viele Teams am selben Produkt arbeiten, wird es zusehends schwieriger herauszufinden, welche Teile der Software angepasst werden müssen um eine bestimmte Funktionalität zu ändern.

Diese Probleme resultieren häufig daraus, dass es kein einheitliches Konzept gibt, wie Anforderungen systematisch und möglichst direkt im Code abgebildet werden.

Kundenanforderungen vs. Systemanforderungen

Erstellt am 12 August 2014
von Schreibe einen Kommentar

Photo_Blog_Wuench_20140812In vielen Projekten wird zwischen unterschiedlichen Anforderungstypen unterschieden. Die Unterteilung nach Kundenanforderungen auf der einen und System- bzw. Komponentenanforderungen auf der anderen Seite ist besonders häufig anzutreffen. Diverse Standards nutzen solche oder ähnliche Begrifflichkeiten ebenfalls, um Anforderungen auf unterschiedlichen Detailebenen eines Systems zu klassifizieren.

Die Sprache der Anforderungsentwickler

Erstellt am 1 Juli 2014
von Schreibe einen Kommentar

Ich habe grundsätzlich die Erfahrung gemacht, dass in einem Entwicklungsprojekt häufiger die Unterschiede einzelner Abteilungen als deren Gemeinsamkeiten betont und gepflegt werden. Dabei sollte es doch eigentlich umgekehrt sein. Es müssten die Dinge in den Fokus gelangen, die alle Beteiligten gemeinsam haben. Dazu zählen ein gemeinsames Verständnis des Entwicklungsgegenstandes, aber auch die kollektiven Ziele und Probleme im Projekt.

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.