Anforderungsanalyse

Marcel Lüthi
Departement Mathematik und Informatik

Übersicht

Problem vs. Lösung

Abbildung nach: Helmut Balzert. Lehrbuch der Softwaretechnik, Abbildung 12.0-1

Dieses Zusammenspiel zwischen Was/Wie oder anders gesagt zwischen Problem und Lösung ist in dieser Grafik illustriert. Wir haben verschiedene Sichten auf das Problem der Softwareentwicklung. Der Kunde weiss, oder sollte wissen, was zu entwickeln ist. Der Auftragnehmer, das heisst eine Softwareentwicklungsfirma oder Team, hat das Problem herauszufinden, wie man diese Anforderungen in eine Fachliche Lösung umsetzt, also die Anforderungen so spezifiziert, dass sie umgesetzt werden können. Auf der nächsten Stufe geht es wo weiter. Die Softwarearchitektin hat nun das Problem aus der fachlichen Lösung ein Design. Die Fachliche Lösung ist was umgesetzt werden muss, und das Design ist wie es umgesetzt wird. Schlussendlich muss vom Programmierer das Problem gelöst werden, wie denn das design in Code umgesetzt werden soll. Die Lösung auf einer Ebene wird also immer zum Problem auf der nächst tieferen Ebene.

Lösungsraum

Abbildung nach: Helmut Balzert. Lehrbuch der Softwaretechnik, Abbildung 12.0-2

Wechselwirkungen

Wechselwirkung zwischen Problem/Lösungsraum
Fehlender technische Lösung → Problem muss angepasst werden

Abbildung nach: Helmut Balzert. Lehrbuch der Softwaretechnik, Abbildung 12.0-3

Softwareentwicklung (karikiert)

Quelle: https://www.lorienpratt.com/decision-models-are-the-requirements-language-for-di-apps/

Was passiert, wenn diese Wechselwirkung fehlt, ist in diesem Cartoon dargestellt. Es ist eine Prozess der dem bekannten Kinderspiel der "stillen Post ähnelt". Auf jeder Stufe weicht das Resultat etwas von dem ab, was der Kunde überhaupt wollte. Der Kunde kann am Anfang eines Projekts seine Anforderungen häufig nur vage und unpräzise formulieren. Der Projektmanager, der ja meistens nicht denselben Background und viel weniger Ahnung vom Geschäftsfeld als der Kunde hat, wird häufig Aspekte von den formulierten Anforderungen falsch interpretieren. Anhand von dieser Lösung wird dann die Software designed und am Ende von nochmals einer anderen Person mit eigenen Vorstellungen, implementiert. Durch die fehlende Wechselwirkung sind nicht nur Fehler durch den Prozess entstanden, der Auftraggeber hatte auch nie die Möglichkeit seine eigenen Anforderungen zu präzisieren. Auch hatte er nie die Gelegenheit durch Reflektion im Prozess herauszufinden, dass er in wirklichkeit etwas ganz anderes wollte. Leider illustriert dieser lustige Cartoon ein ganz reales Problem.

Warum scheitern Projekte

Survey von 8000 Softwareprojekten bei 350 Firmen im Jahre 1994.
31% der Projekte sind gescheitert!

Unvollständige Anforderungen (13.1%)
Benutzer zuwenig involviert (12.4%)
Zuwenig Resourcen (10.6%)
Unrealistische Erwartungen (9.9%)
Zuwenig Unterstützung vom Management (9.3%)
Neue oder veränderte Anforderungen (8.7%)
Zuwenig Planung (8.1%)
System wird nicht mehr gebraucht (7.5%)

Aufgabe von der Anforderungsanalyse

Anforderungen an zu entwickelndes System

ermitteln

spezifizieren

analysieren

validieren

und daraus Lösung ableiten.

Ergebnis:

Anforderungsspezifikation

Die Aufgabe von der Anforderungsanalyse ist es also, die Anforderungen an ein System möglichst genau zu ermitteln und klar zu spezifizieren, so dass diese von allen involvierten Personen verstanden werden können. Auch müssen die Anforderungen analysiert und validiert werden. Sind die Anforderungen konsistent oder wiedersprechen sie sich gegenseitig? Können Sie mit den gesetzlichen Grundlagen und dem Systemumfeld vereinbart werden? Entsprechen auch die vom Analysten spezifizierten Anforderungen noch den Anforderungen vom Kunden? Das Ergebnis von einer solchen Analyse ist ein Dokument, nämlich die Anforderungsspezifikation. Anhand diesem Dokument wir dann die Fachliche Lösung abgeleitet.

Anforderungsspezifikation

Abbildung nach: Helmut Balzert. Lehrbuch der Softwaretechnik, Abbildung 14.0-3

Aufteilung Lastenheft/Pflichtenheft:
Auftragnehmer != Auftraggeber

Wir sehen den Prozess hier nochmals grafisch dargestellt. Auf der linken Seite sehen wir den Prozess wie wir in bisher besprochen haben. Dieser Ablauf gilt immer dann, wenn eine Software inhouse entwickelt wird, also der Auftraggeber auch dem Auftragnehmer entspricht. Wenn eine Firma nun ein Projekt öffentlich ausschreibt, muss die Firma ja bereits spezifizieren, was die Anforderungen an ein System sind. In diesem Fall werden zwei Anforderungsdokumente geschrieben: Das Lastenheft und das Pflichtenheft. Das Lastenheft enthält die Anforderungen, wie sie der Auftraggeber sieht. Nach vergabe eines Auftrags, werden diese dann in einem Pflichtenheft so ausgearbeitet, dass daraus eine fachliche Lösung abgeleitet werden kann.

Lastenheft

Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags.

Immer dann notwendig wenn Auftraggeber das Projekt ausschreibt
Dient als Vertragsgrundlage

Pflichtenheft

Vom Auftragnehmer erarbeite Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes

Enthält das Lastenheft
Anwendervorgaben werden detailliert und Realisierungsforderungen beschrieben.
Definiert wie und womit die Anforderungen zu realisieren sind.