Anforderungen strukturieren – 2. Techniken

Erstellt am 26 April 2017
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Anforderungen strukturieren

Im letzten Blog „Anforderungen  strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“

Das Ende des Requirements Engineerings wie wir es kennen

Erstellt am 1 April 2017
von 2 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.

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des „systematischen Umgangs mit Anforderungen“, dies ist eine moderne Übersetzung des englischen Begriffs „Requirements Engineering and Management“, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es „unmotivierter Mehraufwand“ oder „Overhead für Dokumentation“, für manche agile Teams ist es „alter Hut“ und für erfahrene, gewachsene Fachabteilungen ist es „nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht“.

Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.

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?

Ein Lifecycle sagt mehr als tausend Prozessbeschreibungen – Teil 2

Erstellt am 31 Juli 2012
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Lifecycles im ALM

Warum ist der Lifecycle (Workflow) eines Artefaktes, wie einem Requirement, denn so wichtig? Hauptsache die richtigen Attribute stehen zur Verfügung und wir können das Requirement gut verlinken – eine Traceability aufbauen. Wahrscheinlich ist Ihnen diese Fragestellung nicht unbekannt? Zunächst erst einmal unabhängig, ob Sie nun eine ähnliche Meinung haben oder die Sache völlig anders bewerten. Wenn wir uns klassische RE Werkzeuge ansehen, wie IBM Rational Doors® oder Microfocus CaliberRM®, Requirements werden nicht workflow-unterstützt verwaltet. Trifft das auch auf Ihr RE Werkzeug zu? Haben Sie auch festgestellt, oder tun dies gerade jetzt beim Lesen, dass der Umgang mit Ihren Requirements irgendwie nicht optimal ist? Klare Gründe scheinen nicht analysierbar und die Gemengelage vielfältig und unübersichtlich zu sein. Allenfalls stellen Sie grundsätzlich Kommunikationsschwächen fest, was keinen Erkenntniszugewinn bedeutet.

Mit einem Anforderungs-Template die Projekte besser meistern!

Erstellt am 24 April 2012
von 1 Komment

Elektrifizierte Automobil-Antriebe zu spezifizieren ist eine besondere Herausforderung für den Requirements Engineer. Aktuell werden diese für unterschiedliche Technologien entwickelt, z. B. Antriebe für batteriebetriebene Elektrofahrzeuge, Brennstoffzellenfahrzeuge oder Hybridfahrzeuge. Zusätzlich sollen die elektrifizierten Antriebe in verschiedenen Fahrzeugprojekten und in unterschiedlichen Leistungsklassen eingesetzt werden. Man kann sich leicht vorstellen, dass eine große Anzahl an Entwicklungsprojekten die Folge ist.

Wer plant mit welchen Backlogs? – Sichtenwechsel notwendig!

Erstellt am 6 Dezember 2011
von Schreibe einen Kommentar

Kennen Sie auch die Situation, dass Ihre Projekte nicht die optimalen Voraussetzungen für Scrum haben? Sie haben also:

  • Entwickler, die zeitgleich in mehreren Projekten arbeiten.
  • Entwicklungsteam, die auf unterschiedliche Standorte und Zeitzonen verteilt sind.
  • Nur ein auslieferbares Release, wenn die Zulieferung vieler Teams erfolgt ist.