Anforderungen strukturieren – 3. Die Spezifikation

Erstellt am 18 Juli 2017
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Anforderungen strukturieren

Für die Strukturierung von Anforderungen hatte ich in dieser Blogserie schon die Kriterien und Techniken besprochen. Nach dem Blick auf die eher theoretischen Aspekte will ich mich heute einer konkreten Umsetzung widmen. Die Frage lautet: Wie gestaltet man die Gliederung von Anforderungen innerhalb einer Spezifikation?

UX == RE? – mit Gewinnspiel!

Erstellt am 27 Juni 2017
von Schreibe einen Kommentar

Ich möchte Ihnen heute einen Einblick in die Themen Usability und User Experience (UX) geben und aufzeigen, dass die Parallelen zum Requirements Engineering (RE) größer sind, als man auf den ersten Blick annehmen würde! Außerdem wartet ein Gewinnspiel auf Sie!

Anforderungen strukturieren – 1. Kriterien

Erstellt am 30 März 2017
von Schreibe einen Kommentar
This entry is part 1 of 3 in the series Anforderungen strukturieren

Die Teilnehmer unseres Trainingsangebotes bringen häufig ein konkretes Problem aus ihrem beruflichen Umfeld mit. Viele wollen wissen, wie man gute Anforderungen schreibt, andere wollen einfach die Grundlagen umfassend kennenlernen, die bei dem Umgang mit Anforderungen notwendig sind, sei es im klassischen oder agilen Umfeld.

Eine der häufigsten Fragen lautet: „Ich habe da eine Menge Anforderungen von verschiedenen Seiten in meinem Projekt. Wie strukturiere ich am besten diese heterogenen Anforderungen?

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.

Stakeholder Management – More than a list – Kraftfeldanalyse

Erstellt am 7 Januar 2014
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Stakeholder-Management

In der ersten Blogreihe wurde Ihnen die Notwendigkeit erläutert, wieso man das Thema SH-Management nicht nur am Anfang, sondern auch während des kompletten Lebenszykluses eines Produktes, verfolgen sollte. In diesem Blog wird Ihnen die Methode „Kraftfeldanalyse“ näher gebracht, die zur Durchführung der Stakeholderanalyse herangezogen werden kann.

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.

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.

Story-Requirements – ein Gedankenspiel

Erstellt am 2 Oktober 2012
von Schreibe einen Kommentar

Spätestens seit sich die agile Softwareentwicklung als alltagstaugliche und in einigen Entwicklungsbereichen auch als alternative Vorgehensweise durchgesetzt hat, sind die User Stories fester Bestandteil der Entwicklung. Die Requirements sind aber als Entwicklungsartefakt nicht ausgestorben. So existieren in vielen Unternehmen beide Artefakte – User Story und Requirement – nebeneinander, quasi stellvertretend für die agile und die klassische Welt. Lassen Sie sich mit dem nun folgenden Gedankenspiel auf eine mögliche Verschmelzung dieser Artefakte ein.