Anforderungen

Was sind Anforderungen

Anforderungen definieren, WAS das zu bauende System letztlich leisten soll. Aus Sicht des Entwicklers sind die Anforderungen das Pflichtenheft. Die Anforderungsanalyse ist die wichtigste und oft auch die schwierigste aller Disziplinen, weil hier oft die grössten Missverständnisse produziert werden.

Siehe auch: Probleme der Softwareentwicklung

Anforderungen können unterteilt werden in funktionale und nicht funktionale Anforderungen.

Funktionale Anforderungen

In letzter Konsequenz müssen v.a. administrative Systeme im Allgemeinen Dokumente erzeugen und der Benutzer benötigt zur Eingabe oder Abfrage von Daten Dialoge. In der Vergangenheit sprach man deshalb von Funktionen, neu spricht man zunehmend von Prozessen. Der Auftraggeber bestellt ein System, um damit Prozesse (allenfalls gestützt mit einem Workflow-System) möglichst effizient abwickeln zu können.

Eines der Probleme mit Anforderungen ist deren Menge und gegenseitige Abhängigkeiten (siehe Probleme der Softwareentwicklung). Um das Projekt möglichst seriös planen, überwachen und testen zu können, bedarf es einer Grösse, die etwas grösser als Einzelfunktionen und etwas kleiner (und v.a. weniger redundant) als Prozesse sind.

Hier bieten RUP und UML den Begriff des sog. Use-Case an:

Ein Use-Case beschreibt einen zusammenhängenden Arbeitsablauf aus der Sicht seiner Akteure. Er wird stets durch einen Akteur bzw. Ereignis initiiert und führt zu einem für die Akteure wahrnehmbaren Ergebnis. Ein Use-Case beschreibt das gewünschte externe Systemverhalten aus der Sicht und in der Sprache der Anwender (d.h. in natürlicher Sprache) und somit Anforderungen, die das System zu erfüllen hat. Beschrieben wird, was es leisten muss, aber nicht wie es dies leisten soll. Je nach Projektphase kann zwischen Business Use-Case oder System Use-Case unterschieden werden. Letztere werden im Rahmen von AdeNet/VM oft nur als Use Case bezeichnet.

Mit anderen Worten: ein typischer Use-Case besteht aus einem oder weniger Dialogen sowie aus den zugehörigen Reports oder mit anderen Worten auch in etwa dem, was man in Workflow-Systemen als Aktivität bezeichnet. Die Vorzüge von Use-Cases sind:

  Sie existieren immer, auch wenn das System weder Dialoge, Reports oder Prozesse hat.

  Sie eignen sich als „Koordinationsgrösse“ über die gesamte Projektdauer.

  Sie enthalten Informationen über gegenseitige Abhängigkeiten und sind daher auch dafür geeignet, um in der Projektplanung die richtige Reihenfolge zu planen.

Use-Cases sind also die „Stückliste“ (oder auch der „Funktionskatalog“) des zu realisierenden Systems. Thematisch zusammengehörende Use-Cases werden in Use-Case Diagrammen dargestellt.

Das Use-Case Diagramm zeigt die im Rahmen des Themas (Use-Case Paket) identifizierten Use-Cases. Aus der Notation können z.B. folgenden Schlüsse gezogen werden:

  Telefonische- und Internet-Bestellung haben viele Gemeinsamkeiten, deren Anforderungen man im (abstrakten) Use-Case „Bestellung“ formulieren kann.

  Der Use-Case „Bestellung“ benötigt eine Funktionalität „Artikel abfragen“. Diesen (hie ausgelagerten Use-Case) wird vermutlich noch in anderen Use-Cases verwendet.

  Es existiert eine Schnittstelle zu einer externen Buchhaltung

  Der Internetkunde ist ein Spezialfall eines „normalen“ Kunden.

 

 

Use-Cases werden oft Missverstanden. Nachfolgend sind einige Probleme mit möglichen Lösungen aufgelistet.

Problem

Argument

Use-Cases sind nur für die Entwickler.

Falsch. Entwickler möchten am liebsten „Business-Objekte“ mit Methoden haben. Use-Cases sind „Anforderungsblöcke“, mit denen sowohl Anforderer als auch Entwickler arbeiten sollten.

Definition des Use-Case ist unklar.

Teilweise korrekt. Aber: ob man einen Use-Case etwas grösser oder kleiner versteht, ist letztlich nicht so entscheidend. Wesentlich ist, dass man die dahinter liegenden Funktionen (Verarbeitungen, Dialoge, Reports) einmal klar zuordnet und dann im Projektablauf möglichst nicht mehr ändert. Letztlich ist der Use-Case eine „Kunstgrösse“ zur Verwaltung der Anforderungen.

Use-Case ist zuwenig präzise

Teilweise korrekt. Eine Auslegeordnung von „Kreiseln“ genügt natürlich längstens nicht. Aber: Use-Cases enthalten auch Beschreibungen. In AdeNet/VM wurden zudem die Definition der Dialoge, Reports und Prozesse in autonome Ergebnisse ausgelagert.

Die Systemanforderungen bestehen nicht ausschliesslich aus Use-Cases (bzw. dem sog. Use-Case Modell) sondern zusätzlich aus folgenden Elementen:

  Prozessmodell (wo Prozesse relevant sind)

  Dialog-Design

  Report-Design

  Zusatzanforderungen (für übergreifende sog. „nichtfunktionale“ Anforderungen, siehe unten).

Nichtfunktionale Anforderungen

Nichtfunktionale Anforderungen sind Anforderungen, welche nicht direkt die Funktionalität betreffen. Das können Anforderungen über die allgemeine Benutzbarkeit (z.B. Onlinehilfe) oder solche zur Zuverlässigkeit, Performance oder Wartbarkeit sein.

Wo möglich werden nichtfunktionale Anforderungen direkt in den Use-Cases beschrieben. Beispiel: 10'000 Rechnungen müssen in weniger als einer Stunde erzeugt werden können.

Wo das nicht möglich ist, werden nichtfunktionale Anforderungen im Ergebnis „Zusatzanforderungen“ festgehalten. Dieses Dokument sollte gemäss einem Qualitätsmodell (Bsp: FURPS+, siehe Kapitel „Softwarequalität und Test) strukturiert sein.


Woher kommen Anforderungen

Anforderungen sind das schriftliche Manifest von Bedürfnissen. Ausgehend von diesen wird eine Situationsanalyse erstellt und daraus Systemziele abgeleitet. Beide Dokumente bilden die Basis für die Erarbeitung von Anforderungen.

Bevor sich das Projektteam auf Dialoge und Reports stürzt, sollten müssen vorerst die Use-Cases bzw. das Use-Case Modell definiert werden. Wo möglich kann vorerst auch eine Aufnahme der Prozesse (Prozessmodell) gemacht werden. Das Prozessmodell ist „gröber“ als das Use-Case Modell, weil es eine Art „Blackbox-Beschreibung“ ist und primär (ereignisorientiert) beschreibt, wann das System welche Outputs erzeugen muss. Sofern ein Prozessmodell vorliegt, können daraus „grobe“ Use-Cases“ ( „Business Use-Cases) definiert und anschliessend verfeinert werden.

Wenn das Use-Case Modell weitgehend stabil ist, sollte mit dem Design der Dialoge begonnen werden. Die Reports wird man in den meisten Fällen später, oft erst zu Beginn der Realisierung definieren.

Parallel zu der Erarbeitung der Anforderungen überlegen sich die Techniker, WIE das System gebaut werden könnte. In der Voranalyse wird hierzu ein Ergebnis „Lösungsidee“ erstellt, in der Konzeptphase dann die sog. Systemarchitektur. Die Systemarchitektur ist die Quelle der Machbarkeit, Risiken und oft auch der Kosten für das System. Da die meisten Projekte Rahmenbedingungen haben (Geld & Zeit), wird es dazu kommen, dass die Systemarchitektur die Anforderungen oder sogar die Systemziele beeinflussen kann. Siehe auch: Grundsatz „Architektur zentriert“.


Wer erstellt Anforderungen

Anforderungen werden von Vertretern des Auftragnehmers in enger Zusammenarbeit mit Benutzervertretern erarbeitet.

Die oben aufgezeigten Rahmen um Vertreter des Auftraggebers- bzw. Auftragnehmers zeigen auf, wer die inhaltlichen Aspekte liefern muss, aber nicht wer diese Inhalte auf Papier bringen muss. Nur wenige Manager haben ausreichend Zeit, um die griffige Projektziele zu formulieren. Dasselbe gilt für Benutzervertreter (Fachspezialisten sowie Benutzervertreter). Es ist primär Sache des Auftragnehmers, den Auftraggeber bei der Formulierung der Ziele und Anforderungen zu leiten und die "Schreibarbeit" zu erledigen. Die Vertreter der Auftraggeber müssen trotzdem immer noch viel Zeit aufwenden, um Unterlagen (z.B. über das Ist-Systeme bzw. Verfahren) aufzubereiten, an Interviews und Workshops zu partizipieren sowie um Vorschläge des Auftragnehmers zu begutachten bzw. "abzunehmen".


Der Unterschied zwischen den Anforderungen und Zielen

Oft werden Ziele und Anforderungen vermischt, weil vergessen wird, dass die beiden vermeintlich klaren Begriffe WAS und WIE vom Standpunkt des Betrachters abhängig sind: Das Management (des Kunden) will primär ein Bedürfnis decken bzw. ein Problem lösen. Das Management formuliert also, welches Bedürfnis zu lösen ist, also das WAS. Die Konzepter skizzieren nun ein Modell mit Anforderungen (Use-Cases) derart, dass diese Ziele erfüllt werden könnten. Aus Sicht des Managements ist das also die "grobe" und erste Antwort, WIE das Problem gelöst werden könnte. Aus Sicht der Entwickler stellen die Anforderungen aber das Pflichtenheft und damit das WAS dar. Anforderungen im vorliegenden Dokument beschreiben also WAS ein System leisten muss. Für die Entwickler sind die Anforderungen das eigentliche Pflichtenheft bzw. konkreten "Nahziele". Obwohl die Anforderungen das Wichtigste im Projekt sind, sollten die in der Vision skizzierten "Fernziele" (was will der Auftraggeber bzw. Manager letztlich mit dem System aus geschäftlicher Sicht erreichen), nie aus den Augen