C Referenz Produkte

C.1 Produkte

C.1.10 Systemanalyse

C.1.10.1 Lastenheft (Anforderungen)

Das Produkt Lastenheft (Anforderungen) enthält alle an das zu entwickelnde System gestellten Anforderungen. Es ist Grundlage für Ausschreibung und Vertragsgestaltung und damit wichtigste Vorgabe für die Angebotserstellung. In der Regel bezieht sich der Vertrag zwischen Auftraggeber und Auftragnehmer auf das Lastenheft; das bedeutet aber nicht zwingend, dass die Erfüllung aller Anforderungen vertraglich zugesichert wird. Mit den vertraglich vereinbarten Anforderungen werden die Rahmenbedingungen für die Entwicklung festgelegt, die dann vom Auftragnehmer im Pflichtenheft (Gesamtsystementwurf) detailliert ausgestaltet werden.

Alle relevanten Anforderungen an das System werden vom Auftraggeber ermittelt und dokumentiert. Sie enthalten die für den Auftragnehmer notwendigen Informationen zur Entwicklung des geforderten Systems. Kern des Lastenhefts sind die funktionalen und nicht-funktionalen Anforderungen an das System, sowie eine Skizze des Gesamtsystementwurfs. Der Entwurf berücksichtigt die zukünftige Umgebung und Infrastruktur, in der das System später betrieben wird, und gibt Richtlinien für Technologieentscheidungen. Zusätzlich werden die zu unterstützenden Phasen im Lebenszyklus des Systems identifiziert und als logistische Anforderungen aufgenommen. Ebenfalls Teil der Anforderungen ist die Festlegung von Lieferbedingungen und Abnahmekriterien.

Die funktionalen und nicht-funktionalen Anforderungen dienen nicht nur als Vorgaben für die Entwicklung, sondern sind zusätzlich Grundlage der Anforderungsverfolgung und des Änderungsmanagements. Die Anforderungen sollten so aufbereitet sein, dass die Verfolgbarkeit (Traceability) sowie ein geeignetes Änderungsmanagement für den gesamten Lebenszyklus eines Systems möglich sind.

Für die Erstellung des Lastenhefts sowie für dessen Qualität ist der Auftraggeber alleine verantwortlich. Bei Bedarf kann er Dritte mit der Erstellung beauftragen. Das Lastenheft sollte im Allgemeinen keine technischen Lösungen vorgeben, um Architekten und Entwickler bei der Suche nach optimalen technischen Lösungen nicht einzuschränken.

C.1.10.1.1 Ausgangssituation und Zielsetzung

In diesem Thema werden die Ausgangssituation und der Anlass zur Durchführung des Projektes anschaulich dargestellt. Es wird beschrieben, welche Defizite bzw. Probleme existierender Systeme oder auch der aktuellen Situation zur Entscheidung geführt haben, das Projekt durchzuführen, und welche Vorteile durch den Einsatz des neuen Systems erwartet werden.

Es werden zusätzlich alle relevanten Stakeholder des Projektes benannt und die technische und fachliche Einbettung des zu entwickelnden Systems in seine Umgebung skizziert. Zusätzlich werden erste Rahmenbedingungen für die Entwicklung identifiziert und beschrieben. Rahmenbedingungen können beispielsweise technische Vorgaben oder Vorgaben zur Sicherheit sein.

C.1.10.1.2 Funktionale Anforderungen

Funktionale Anforderungen beschreiben die Fähigkeiten eines Systems, die ein Anwender erwartet, um mit Hilfe des Systems ein fachliches Problem zu lösen. Die Anforderungen werden aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.

Die Beschreibung der funktionalen Anforderungen erfolgt beispielsweise in Form von Anwendungsfällen (Use Cases). Ein Anwendungsfall beschreibt dabei einen konkreten, fachlich in sich geschlossenen Teilvorgang. Die Gesamtheit der Anwendungsfälle definiert das Systemverhalten. Ein Anwendungsfall kann in einfachem Textformat beschrieben werden, häufig stehen jedoch organisationsspezifische Muster zur Beschreibung zur Verfügung. Für datenzentrierte Systeme wird im Rahmen der funktionalen Anforderungen ein erstes fachliches Datenmodell erstellt, das als Grundlage des späteren Datenbankentwurfs dient. Das fachliche Datenmodell des Systems wird aus den Entitäten des Domänenmodells abgeleitet.

Die funktionalen Anforderungen sind die zentralen Vorgaben für die Systementwicklung. Sie werden in das Pflichtenheft (Gesamtsystementwurf) übernommen und bei Bedarf konkretisiert.

C.1.10.1.3 Nicht-Funktionale Anforderungen

Nicht-funktionale Anforderungen sind Anforderungen an das System, die nicht-fachlicher Natur sind, jedoch entscheidend zur Anwendbarkeit des Systems beitragen. Typische Beispiele sind Anforderungen an die Performance, die Benutzbarkeit oder die Skalierbarkeit des Systems.

Die in den Vorgaben zur Informationssicherheit, zum Datenschutz und zum IT-Betrieb enthaltenen Regelungen beschreiben ebenfalls nicht-funktionale Anforderungen und müssen in diesem Thema aufgeführt oder referenziert werden. Gleichermaßen hier aufgeführt oder referenziert werden muss die Schutzbedarfsfeststellung, die zusammen mit den vorgenannten Vorgaben die Grundlage der zu erstellenden Sicherheitskonzeption bildet.

Nicht-funktionale Anforderungen definieren grundlegende Eigenschaften eines Systems, die im Architekturentwurf berücksichtigt werden müssen. Sie können zur Abschätzung der Entwicklungskosten herangezogen werden und sollten, soweit möglich, messbar beschrieben sein.

Zur einfachen Strukturierung der Anforderungen werden diejenigen Anforderungen, die nicht eindeutig zu den funktionalen Anforderungen gehören, den nicht-funktionalen Anforderungen zugeordnet.

C.1.10.1.4 Skizze des Lebenszyklus und der Gesamtsystemarchitektur

Das reine Aufstellen von Anwenderanforderungen ohne Überlegungen zu möglichen Lösungsräumen birgt die große Gefahr, unrealistische Anwenderanforderungen zu definieren. Für die Einordnung, Systematisierung, Kategorisierung und auch Priorisierung von Anwenderanforderungen ist ein Koordinierungsrahmen hilfreich, um die Visualisierung der Anwenderanforderungen zu erleichtern.

Diese Aufgabe kann eine Gesamtsystemarchitektur leisten, die die Sichtweise des Anwenders repräsentiert und nicht die technische Sichtweise des Systemanalytikers beziehungsweise des Systemarchitekten. Das heißt, es ist eine funktionale Systemarchitektur mit Einbettung in die funktionalen Abläufe von Nachbarsystemen zu erstellen. Eine technische Systemarchitektur ist in dieser frühen Phase kaum möglich.

In der Gesamtsystemarchitektur sollten im Falle einer Evaluierung von Fertigprodukten im Rahmen der Nachbearbeitung des Lastenhefts die zukünftigen Systembestandteile identifiziert und festgeschrieben werden.

Des Weiteren sind die Besonderheiten der Einsatzumgebung des neuen Systems zu beschreiben, um vor allem die Anforderungen an die Sicherheit berücksichtigen zu können. Dabei sollte der Ersteller der Anwenderanforderungen bereits eine Vorstellung entwickeln, welche Lebenszyklusabschnitte im Rahmen des Projekts abzudecken sind.

C.1.10.1.5 Anforderungen an die Funktionssicherheit

Für sicherheitskritische Systeme werden in diesem Thema Vorgaben für die Behandlung der Funktionssicherheit festgelegt. Es wird aufgezeigt, welche Risiken im Rahmen des Systembetriebs bestehen, welche Schäden oder auch welche Klassen von Schäden mit welcher Wahrscheinlichkeit auftreten können und inwieweit das Eintreten eines Schadensfalls toleriert wird oder nicht mehr akzeptabel ist.

Die Risikoakzeptanz für die identifizierten möglichen Schadensfälle kann in Form einer Risikoakzeptanzmatrix dokumentiert werden. Darin legt der Auftraggeber fest, bei welcher Schadensklasse und welcher Eintrittswahrscheinlichkeit er welche Risikoklasse akzeptiert.

C.1.10.1.6 Anforderungsverfolgung zu den Anforderungen (Lastenheft Gesamtprojekt)

Im Rahmen der Anforderungsverfolgung zum Lastenheft Gesamtprojekt wird zusammenfassend die Zuordnung der funktionalen und nicht-funktionalen Anforderungen aus dem Lastenheft Gesamtprojekt zu Anforderungen im Lastenheft dargestellt. Die bidirektionale Verfolgbarkeit muss dabei sichergestellt werden. Die Darstellung kann beispielsweise anhand einer Matrix erfolgen.

C.1.10.1.7 Lieferumfang

Es sind alle Gegenstände und Dienstleistungen aufzulisten, die während des Projektverlaufs oder bei Abschluss des Projektes vom Auftragnehmer an den Auftraggeber zu liefern sind. Jede Lieferung erfordert eine Abnahmeprüfung. Der Lieferumfang kann je nach Vereinbarung ein System, Teile eines Systems, Dokumente und Dienstleistungen enthalten.

C.1.10.1.8 Abnahmekriterien und Vorgehen zur Abnahmeprüfung

Abnahmekriterien legen fest, welche Kriterien die Lieferung erfüllen muss, um den Anforderungen zu entsprechen. Sie sollten messbar dargestellt werden und können nach ihren drei wesentlichen Bestandteilen - Ausgangssituation, Aktion(en) und erwartetes Ergebnis - strukturiert werden. Aus vertraglicher Sicht beschreiben die Abnahmekriterien die Bedingungen für die Entscheidung, ob das Endprodukt die gestellten Anforderungen erfüllt oder nicht. Abnahmekriterien können sich sowohl auf einzelne Anforderungen ("Unter welchen Bedingungen gilt die Anforderung als erfüllt?") als auch auf den Lieferumfang ("Welche Bedingungen müssen erfüllt sein, damit eine konkrete Lieferung abgenommen wird?") beziehen. Die Abnahmekriterien sind Grundlage der Abnahmeprüfung und gehen als Anforderungen in die Abnahmespezifikation ein.

Vor der Auftragsvergabe können die Abnahmekriterien ggf. nur in einer allgemeinen Form (z.B. K.o.-Kriterien) angegeben werden, da beispielsweise noch nicht klar ist, wann welche (Teil-)Lieferungen erfolgen. Beispielsweise kann definiert sein, dass mindestens 90% aller Prüffälle für eine erfolgreiche Abnahme erfüllt sein müssen. Ebenfalls bietet es sich an, Abnahmekriterien in Form von konkreten Abnahmeszenarien zu beschreiben, die das System bei der Lieferung durchlaufen muss.

Nach der Auftragsvergabe sollten die Abnahmekriterien detailliert werden; dies kann - je nach vertraglicher Vereinbarung - auch durch den Auftragnehmer im Rahmen der Erstellung des Pflichtenhefts erfolgen. In jedem Fall sollten die erwarteten Ergebnisse der Abnahme und das Vorgehen bei der Abnahmeprüfung für jede Lieferung schon vor der Abnahme detailliert festgelegt und zwischen Auftraggeber und Auftragnehmer abgestimmt werden.

C.1.10.1.9 Glossar

Das Glossar ist eine Sammlung aller verwendeten Fachbegriffe und dient dazu, allen Projektbeteiligten ein gemeinsames Verständnis zu ermöglichen. Damit können unterschiedliche Interpretationen und Missverständnisse vermieden werden und das Verständnis der Anforderungen wird erhöht. Das Glossar ist für alle Projektbeteiligten verbindlich.

Es empfiehlt sich, neben der Erläuterung der Begriffe auch mögliche Abkürzungen und für eventuelle Rückfragen auch die Herkunft bzw. die Quelle der Erläuterung anzugeben.