Seitdem Anforderungen an Software erhoben und spezifiziert werden, versucht man, funktionale von nicht-funktionalen Anforderungen zu unterscheiden. Lehrbücher wurden auf der Suche nach einer klaren Antwort auf die Frage nach diesem Unterschied gefüllt. Für die systematische Erfassung von Anforderungen ist die Unterscheidung von Kategorien, die nach den unterschiedlichen Zwecken der Anforderungen fragt, natürlich sinnvoll, aber fraglich ist, ob so eine viel-diskutierte und unpräzise Trennung wie die in funktionale und nicht-funktionale Anforderungen wirklich zielführend ist.

In den letzten Jahren hat sich in der Literatur die Überzeugung durchgesetzt, dass nicht-funktionale Anforderungen

1. entscheidend für die Benutzerzufriedenheit sind,
2. durch Architektur-Entscheidungen umgesetzt werden.

Das gibt uns vielleicht einen Hinweis darauf, was nicht-funktionale Anforderungen wirklich sind. Dazu ein Beispiel aus der Welt, aus der der begriff “Architektur” eigentlich stammt:

Ein Haus wird im Erdgeschoss und im Keller lange Zeit als Möbelhaus mit Lager genutzt. Nach einem kleinen Umbau dienen die gleichen Flächen als Kino mit Gastronomie. Die Architektur des Hauses hat es möglich gemacht. Welche Anforderungen wurden durch die Architektur bereits erfüllt? Es sind Basis-Anforderungen: Man braucht ausreichend Platz für große Gegenstände und für eine größere Anzahl von Personen, die sich gleichzeitig auf einer Fläche bewegen können (Verkaufsausstellung, Veranstaltung, Vortrag, Vorführung – all das sind Nutzungen dieser Art).

Analog kann man für eine Software, z.B. für ein Data Warehouse festhalten: Sie soll den schnellen Zugriff auf große Daten-Mengen für einen geschlossenen Benutzerkreis ermöglichen, Berechnungen, Zusammenfassungen, müssen sehr schnell erfolgen. Das kann man als Nicht-Funktionale Anforderungen bezeichnen, besser wäre aber, es als (abstrakte) Basis-Anforderungen zu bezeichnen. In einem objektorientierten Anforderungsmodell sind das die Basisklassen, von denen die weiteren Anforderungen (Welche Daten sollen genau für welche Benutzer auf welche Weise und wie oft) als abgeleitete Klassen aufsetzen.

Die Anforderungsanalyse beginnt dann mit diesen Basis-Anforderungen und ordnet diesen die speziellen Anforderungen zu. Und so kann dann auch der Architektur-Entwurf der Anwendung erfolgen. Wie im Bauwesen: Erst wird das Grundgerüst entworfen, welches die flexible Nutzbarkeit für die Basis-Anforderungen erfüllt, dann werden die speziellen Nutzungsformen berücksichtigt. Auf diese Weise entstehen flexible, langlebige Architekturen.

Bei kleinen Softwareprojekten kommt man mit einem einzelnen Anforderungsdokument aus, welches nicht nur die fachlichen Anforderungen beschreibt und spezifiziert sondern auch die notwendigen Vorgaben für die technische Umsetzung enthält. Wird die Anforderung komplexer, zerlegt man die Dokumente, die der Umsetzung voraus gehen, in ein Fachkonzept und ein DV-Konzept, und wenn das Projekt sehr groß ist, dann kann auf die Anforderungs-Dokumentation ein Fach-Grobkonzept und ein Fach-Feinkonzept folgen, aus dem eine technische Grobspezifikation und eine Detailspezifikation abgeleitet werden.

Welche Variante angemessen ist, wie man das entscheidet und wie man die Verantwortlichkeiten verteilt, mit diesen Fragen könnte allein ein tägliches Blog betrieben werden, heute soll es aber nur um eine einzelne Detailfrage gehen: Wie kann man, wenn man es mit vielen verschiedenen Anforderer-Gruppen zu tun hat, die Fachkonzeption in zwei Schritte zerlegen?

Nehmen wir also an, Sie wollen ein neues System entwickeln (oder ein bestehendes großes System weiter entwickeln) bei dem aus verschiedenen Richtungen (Fachbereiche, Anwendergruppen) Anforderungen eingehen. Diese Anforderungen werden im Allgemeinen sehr unterschiedlich sein. Dann ist es nicht sinnvoll, alle Anforderungen in einem einzigen Dokument zu spezifizieren.

In der ersten Stufe der Fachspezifikation werden Sie also für jede Anforderung ein gesondertes Dokument erstellen – eine Anforderung kann hier natürlich relativ komplex sein und aus mehreren abhängigen Teilanforderungen bestehen. Das hat viele Vorteile bei der Kommunikation mit den Fachseiten und der Abnahme der Anforderungen durch die fachlichen Stakeholder, wie auch bei der Erstellung der Testfälle und der Durchführung der Abnahmetests. Auch die Releasezuordung und Bündelung ist auf diese Weise einfach zu organisieren.

In der zweiten Stufe der Fachspezifikation werden dann die Einzelanforderungen konsolidiert. hier ist es sinnvoll, bereits über ein abstraktes fachlich-logisches Anforderungsmodell zu verfügen. Dieses beantwortet folgende Fragen:

Welche Komponenten und Schichten soll das System haben?

Welche Business-Objekte werden implementiert und welche Attribute haben diese?

Den Bestandteilen dieses Modells werden die fachlichen Anforderungen zugeordnet – sie werden an den Modell-Komponenten und den Entitäten des Business-Objektmodells konsolidiert. Deshalb ist diese Stufe der fachlichen Spezifikation auch sozusagen ein halber Schritt in Richtung technischer Spezifikation: Das System wird bereits beschrieben, auch hinsichtlich seines Aufbaus, aber in fachlich-logischer Sprache. Damit werden Zusammenhänge und implizite Abhängigkeiten zwischen Anforderungen gefunden und hinsichtlich ihrer Konsequenzen bewertet.

An diese zweite Phase der fachlichen Spezifikation schließt sich die eigentliche technische Spezifikation an.

Man sieht, dass diese zweistufige Fachspezifikation mit den Begriffen Fach-Grobkonzept und Fach-Feinkonzept nur unzureichend beschrieben ist. Der Detaillierungsgrad bleibt nämlich nahezu unverändert – was sich ändert, ist die Perspektive: Sie bewegt sich von der Spezifikation der (komplexen) Einzelanforderung hin zur fachlich-logischen Spezifikation des Systems. Sinnvoll ist dieses Verfahren wie gesagt immer, wenn ein System für eine relativ große Zahl sehr unterschiedlicher Anforderer erstellt werden soll.

Wenn Sie mehr als einmal im Jahr eine Anforderungsspezifikation schreiben müssen dann werden Sie sich vielleicht auch schon einmal einen Leitfaden gewünscht haben, eine kleine Handreichung die Ihnen Tipps gibt, was am besten auf welche Weise aufzuschreiben ist, damit ein gut verständliche, möglichst eindeutige Dokumentation der Anforderungen entsteht.

In jedem Fall brauchen Sie solch einen Leitfaden, wenn verschiedene Mitarbeiter immer wieder Anforderungen aufnehmen und dokumentieren sollen. Aber wie sieht ein solcher Leitfaden aus, was sollte er enthalten und wie umfangreich sollte er sein, damit er nicht zum Leid-Faden wird, einer mächtigen Liste von Anweisungen die nur zur Freude von Bürokraten dient, die gern formale Fehler nachweisen und inhaltliche Prüfungen scheuen?

Der einfachste Leitfaden ist eine Dokumentvorlage, die die notwendigen Bestandteile der Dokumentation als Überschriften enthält und (am Besten in anderer Schriftfarbe) Hinweise dazu gibt, was in dem jeweiligen Abschnitt darzustellen ist.

Diese Vorlage wird am Besten durch ein weiteres Dokument (das auch als Kapitel 0 in den Leitfaden eingefügt sein kann) ergänzt, in dem allgemeine Hinweise zu Formulierungen, Satzbau, Schüsselwörtern enthalten sind. Während die Vorlage für jeden Dokumenttyp (Lastenheft, Pflichtenheft,…) gesondert erstellt werden muss, sind diese Hinweise dokumenttyp-unabhängig.

Ein richtiger, kompletter Leitfaden besteht außerdem aus Beispielen und Hinweisen zur Vorgehensweise bei der Erstellung der Spezifikationsteile und wird durch eine Checkliste zur Prüfung er Vollständigkeit ergänzt.

Ein Leitfaden sollte unbedingt in einer Kurzschulung erläutert werden, die Autoren sollten außerdem Gelegenheit haben, sich mit ihrem Feedback an der Weiterentwicklung zu beteiligen.

Letzter Tipp: Hüten Sie sich vor Leitfäden, die im Internet zu finden sind, die sind meist zu generisch und unspezifisch. Natürlich können Sie diese als Anregung benutzen. Am Besten, Sie schauen sich ein paar davon an und machen dann aus einigen gelungenen eigenen Spezifikationen einen eigenen Leitfaden, den Sie dann mit Ihren Experten diskutieren. natürlich können Sie auch externen Rat hinzuziehen, das versteht sich ja von selbst .

Einer der ersten Schritte bei der Anforderungsanalyse ist die Spezifikation des Systemkontextes und die Abgrenzung des Systems vom Systemkontext.

In der Literatur wird dazu oft das System als derjenige Teil der Realität definiert, der durch das Projekt verändert, beeinflusst oder neu gestaltet wird. Der Kontext hingegen ist der Teil, der das System zwar beeinflusst, der aber durch das Projekt selbst nicht verändert wird. Den ganzen Beitrag lesen »

Anforderungsdokument, Fachkonzept, DV-Konzept, … wozu braucht man eigentlich mehr als ein Dokument, in dem alle Vorgaben für die Entwicklung eines Software-Systems enthalten sind?

Zunächst einmal ist eine begriffliche Klärung notwendig. Viele Projektbeteiligte bezeichnen quasi alles, was in irgendeiner Form bereitgestellt wird, damit die Entwicklungs-Firma ihre Arbeit machen kann, als Spezifikation – oft als Anforderungs-Spezifikation, bezeichnet. Das erweckt den Eindruck, als ob in all diesen Dokumenten irgendwie das Gleiche stehen würde. Aber es gibt riesige Unterschiede. Den ganzen Beitrag lesen »