C Referenz Produkte
C.1 Produkte
C.1.10 Systemanalyse
C.1.10.1 Anforderungen (Lastenheft)
Das Produkt Anforderungen (Lastenheft) enthält alle an das zu entwickelnde System verbindlich gestellten Anforderungen, die vom Auftraggeber ermittelt und hier dokumentiert werden. Es ist Grundlage für die Ausschreibung und Vertragsgestaltung und damit wichtigste Vorgabe für die Angebotserstellung. Das Lastenheft ist Bestandteil des Produkts Vertrag zwischen Auftraggeber und Auftragnehmer. Mit den Teilen dieses Produkts, die im Produkt Vergabeunterlagen (Ausschreibung) im Thema Teil 1: Anforderungen an das zu erstellende (Teil-)System enthalten sind, erhält der Auftragnehmer alle notwendigen Informationen zur Entwicklung des geforderten Systems, die er dann im Produkt Gesamtsystemspezifikation (Pflichtenheft) detailliert und ausgestaltet.
Kern des Lastenhefts sind die funktionalen und nicht-funktionalen Anforderungen an das System sowie ggf. erforderliche Unterstützungssysteme, sowie eine Skizze der Gesamtsystemarchitektur. 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 verantwortlich. 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.
|
Verantwortlich |
|
Mitwirkend |
Anwender, Projektleiter, Projekteigner, Fachverantwortlicher, Geschäftsprozessmanager, IT-Service-Design-Verantwortlicher, Technikkoordinator |
|
Hilfsmittel |
Anforderungen festlegen (Aktivität), Anforderungsmanagement (Werkzeug), Anforderungen (Lastenheft)(.odt|.doc) |
|
Entscheidungsrelevant bei |
|
Sonstiges |
Initial |
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. Außerdem werden die technische und fachliche Einbettung des zu entwickelnden Systems in seine Umgebung sowie der organisatorische und technische Rahmen skizziert.
In diesem Abschnitt wird dargestellt, was der Anlass zur Durchführung des Projektes ist. Dazu gehört die Darstellung des Problems, welches durch das Projekt beseitigt werden soll. In diesem Zusammenhang soll auch darauf eingegangen werden, warum das Problem nicht mit bereits existierenden Systemen behoben werden kann.
Des Weiteren wird die Auftragsgrundlage für das neu durchzuführende Projekt benannt. Resultiert der Projektauftrag beispielsweise daraus, dass Gesetzesänderungen umzusetzen sind, dann sind diese Gesetze in diesem Kapitel angeführt.
Im Rahmen der Zielsetzung werden die Vorteile aufgezeigt, die durch den Einsatz des neuen Systems zu erwarten sind. Hierbei wird der Systemname angegeben, eine kurze Beschreibung des Systems vorgenommen sowie die Nutzer des Systems benannt.
Zudem wird in einem kurzen Abriss dargestellt, wie der Soll-Zustand zur Beseitigung des Problems, also das System, zu gestalten ist.
Mit dem Produkt Anforderungen (Lastenheft) werden die Anforderungen an das zu erstellende System erfasst, um den Weg zur Systemrealisierung vorzubereiten. Bei der Erhebung der Anforderungen sind Fachseite, IT-Seite und eventuell Betrieb beteiligt. Die Anforderungen des Fachbereichs (der Anwender) sind überwiegend fachlicher Natur. Aus den fachlichen und technischen Anforderungen kann das IT-System abgeleitet werden (siehe auch Skizze des Lebenszyklus und der Gesamtsystemarchitektur).
Dieses Thema beschreibt schwerpunktmäßig die Abgrenzung des zu entwickelnden Systems zu seinen Nachbarsystemen. Dabei sind von der Fachseite insbesondere die bereits etablierten Geschäftsprozesse zu berücksichtigen. Der IT-Betrieb steuert dazu die Informationen zu den bereits betriebenen Systemen bei. Auf Basis dieser Informationen ist der Bedarf, der durch das neue System gedeckt werden soll, zu bestimmen und gegenüber bereits existierenden Lösungen abzugrenzen. Somit dokumentiert dieses Thema die Kernaufgaben, die das neue System erfüllen soll.
Weiterhin ist in diesem Thema zu dokumentieren, in welchen Organisationskontext (z.B. Referat, Behörde) das neue System eingebettet werden soll.
Im Thema Abgrenzung des Systems werden bereits die Geschäftsprozesse und Nachbarsysteme benannt. In diesem Thema ist eine detaillierte Analyse der identifizierten, betroffenen Geschäftsprozesse zu dokumentieren. Die Analyse dieser Geschäftsprozesse dient dem Erkennen, welche Prozessschritte durch das zu entwickelnde System zu unterstützen sind. Dies ist eine wichtige Quelle für die Ermittlung der funktionalen Anforderungen (Thema Funktionale Anforderungen).
Anforderungen werden nicht nur aus Geschäftsprozessen abgeleitet, sondern können auch dazu führen, dass bereits etablierte Geschäftsprozesse angepasst werden müssen. Daher sind in diesem Thema auch die Geschäftsprozesse aufzuführen, die Abhängigkeiten zu den (neu) umzusetzenden Geschäftsprozessen aufweisen und daher ggf. angepasst werden müssen.
Somit enthält dieses Thema eine Liste von Geschäftsprozessen, die sich auch in Abgrenzung des Systems wieder finden müssen. Die hier gelisteten betroffenen Geschäftsprozesse stellen eine Teilmenge der gelisteten Geschäftsprozesse des Themas Abgrenzung des Systems dar.
Es werden alle Personen und Organisationen benannt, die im Rahmen der Anforderungserhebung zu dem zu entwickelnden System berücksichtigt werden sollten, weil sie gegebenenfalls einen direkten oder indirekten Einfluss auf die Anforderungen haben.
Bei den Personen kann es sich um konkrete Personen handeln oder auch um Rollen, während unter Organisationen im Allgemeinen konkrete Referate oder Abteilungen gesehen werden.
Während konkrete namentlich benannte Personen im Projekthandbuch erfasst werden, werden hier die Funktionen bzw. Rollen sowie die Organisationen, die Stakeholder darstellen, aufgeführt.
Zu typischen Stakeholdern zählen beispielsweise
- Fachabteilung,
- Anwender des Systems,
- IT-Abteilungen,
- Architektur,
- Betrieb,
- Management usw.
Als zusätzliche Information kann an dieser Stelle auch beschrieben werden, welches spezielle Wissen der Stakeholder zur Thematik hat, in welcher Form der Stakeholder Einfluss auf das neue zu schaffende System hat und auf welchen Bereich des Systems.
Für die Erfassung empfiehlt sich entweder eine einfache Aufzählungsliste oder für detaillierte Informationen eine tabellarische Erfassung.
Organisatorischer und technischer Rahmen
Dieses Thema dokumentiert erkennbare und vorgegebene Rahmenbedingungen. Zu diesen Rahmenbedingungen zählen beispielsweise technische Vorgaben (z.B. im Rahmen von SAGA) oder Vorgaben zur Sicherheit. Des Weiteren können die organisatorische Einbettung (wie ordnen sich die betroffene Bereiche in das Gesamtorganigramm ein) und speziell vorgegebene IT-Strategien der jeweiligen Behörde eine Rolle spielen.
Aus diesem vorgegebenen organisatorischen und technischen Rahmen lassen sich dann Randbedingungen ableiten. Randbedingungen sind nicht-funktionale Anforderungen, die bei der Erstellung des Systems zu beachten sind, auf die die Projektbeteiligten jedoch keinen Einfluss haben. Randbedingungen können sich sowohl auf das zu realisierende System als auch auf den Entwicklungsprozess beziehen. Beispiele für Randbedingungen sind dann z.B. Entwicklungsmethoden oder Programmiersprachen, die dem Projekt von extern vorgegeben werden.
C.1.10.1.2 Funktionale Anforderungen
Funktionale Anforderungen sind die zentralen Vorgaben für die Systementwicklung. Sie werden im Anschluss durch den Auftragnehmer in der Gesamtsystemspezifikation (Pflichtenheft) übernommen und bei Bedarf konkretisiert. Sie beschreiben die Fähigkeiten eines Systems, die ein Anwender erwartet, um mit Hilfe des Systems ein Problem zu lösen. Die Anforderungen werden aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.
Für die Beschreibung der funktionalen Anforderungen können verschiedene Darstellungsmittel, wie:
- Text (natürliche Sprache)
- Anwendungsfälle (Text, Tabelle)
- Modelle
verwendet werden. Welche Technik im Detail verwendet wird, ist im Thema Organisation und Vorgaben zum Anforderungsmanagement im Projekthandbuch festzulegen.
Unabhängig von der gewählten Darstellungsform sind bei der Erfassung der funktionalen Anforderungen immer die folgenden Aspekte zu berücksichtigen:
- Inhalt: Was wird gemacht?
- Akteure: Wer ist involviert/beteiligt?
- Daten: Welche Daten werden genutzt, benötigt etc.?
- Schnittstellen: Mit welchen (Nachbar-)Systemen interagiert das System? Welche Schnittstellen zu Anwendern hat das System?
Die Struktur und die Tiefe der Erfassung der funktionalen Anforderungen ist ebenfalls im Thema Organisation und Vorgaben zum Anforderungsmanagement im Projekthandbuch festzulegen.
C.1.10.1.3 Nicht-Funktionale Anforderungen
Im Gegensatz zu den funktionalen Anforderungen (Thema: Funktionale Anforderungen), die beschreiben, was das System leisten soll, geben die nicht-funktionalen Anforderungen an, wie gut das System diese Funktionen leisten soll. Nicht-funktionale Anforderungen beschreiben also Anforderungen an das System und an das Projekt, die nicht-fachlicher Natur sind, jedoch entscheidend zur Anwendbarkeit des Systems beitragen. Dies schließt insbesondere auch Anforderungen des Bereichs IT-Betrieb ein, die es ermöglichen, das System nach der Entwicklung auch den Anwendern zur Verfügung zu stellen.
Nicht-funktionale Anforderungen entstehen in der Regel parallel zu den funktionalen Anforderungen und können diesen daher zugeordnet werden. Die nicht-funktionalen Anforderungen können die funktionalen einschränken und sie konkreter beschreiben.
Nicht-funktionale Anforderungen können unterschiedlichster Art sein. Sie lassen sich generell unterscheiden in Qualitätsanforderungen (Qualitätskriterien gemäß ISO 9126) und Randbedingungen (Anforderungen, die nicht an das System direkt, jedoch an die Entwicklung des Systems gestellt werden). Zur einfachen Strukturierung der Anforderungen werden diejenigen Anforderungen, die nicht eindeutig zu den funktionalen Anforderungen gehören, den nicht-funktionalen Anforderungen zugeordnet.
Die Darstellung und Beschreibung erfolgt bei nicht-funktionalen Anforderungen überwiegend in Textform. Die nicht-funktionalen Anforderungen sollten dabei messbar, prüfbar und entscheidbar formuliert sein. Für die Messbarkeit müssen geeignete Metriken definiert werden.
Nicht-funktionale Anforderungen im Bereich Funktionalität betreffen das Vorhandensein von Funktionen mit festgelegten Eigenschaften. Beispiele hierfür sind Angaben zu Genauigkeiten von berechneten Werten oder die Erfüllung von Normen oder gesetzlichen Vorschriften.
Insbesondere werden Anforderungen bezüglich Sicherheit, d.h. der Schutz vor unberechtigten Zugriff auf Daten, hier angeführt.
Anmerkung: Wenn das Projekt kritisch bezüglich Sicherheit ist (siehe Projektmerkmal Betriebsübergabe), werden die Sicherheitsanforderungen in dem Thema IT-Sicherheitsanforderungen und Schutzbedarf behandelt.
Nicht-funktionale Anforderungen im Bereich Zuverlässigkeit betreffen die Fähigkeit des Systems, sein Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum zu bewahren. Beispiele hierfür sind Angaben zur Verfügbarkeit oder zur Wiederherstellbarkeit nach Ausfällen hinsichtlich Aufwand und Zeit.
Nicht-funktionale Anforderungen im Bereich Benutzbarkeit betreffen alle Eigenschaften, die zur Benutzung erforderlich sind bzw. eine ordnungsgemäßen Benutzung ermöglichen. Dazu gehören Anforderungen bezüglich Verständlichkeit, Erlernbarkeit und Bedienbarkeit des Systems.
Nicht-funktionale Anforderungen im Bereich Effizienz betreffen Performanceanforderungen sowie Anforderungen zum Verbrauchsverhalten beim Betrieb des Systems.
Nicht-funktionale Anforderungen im Bereich Änderbarkeit betreffen den Aufwand, der erforderlich ist, Änderungen an der Software vorzunehmen. Anlässe für Änderungen können Korrekturen, Verbesserungen oder geänderte Anforderungen sein.
Nicht-funktionale Anforderungen im Bereich Übertragbarkeit betreffen die Eignung des Systems, von einer Umgebung in eine andere übertragen zu werden. Dabei kann es sich um eine organisatorische Umgebung, eine andere Hardware- oder Softwareumgebung handeln.
Randbedingungen legen Bedingungen und Einschränkungen fest, unter denen das Projekt durchgeführt wird und die für die Entwicklung des Systems zu beachten sind. Randbedingungen sind häufig eine direkte Folge des vorgegebenen organisatorischen und technischen Rahmens (dieser ist im Thema Organisatorischer und technischer Rahmen vorgegeben). Beispiele für Randbedingungen sind
- Richtlinien,
- einzuhaltende Standards wie z.B. Referenzarchitekturen,
- Entwicklungsmethoden,
- technologische Vorgaben wie Hardware- oder Software-Plattformen und
- zwingend einzuhaltende Terminvorgaben.
C.1.10.1.4 Datenschutzanforderungen
Für den Betrieb von IT-Systemen zur Verarbeitung von personenbezogenen Daten existieren besondere gesetzliche Anforderungen zum Datenschutz (siehe BDSG). Diese dienen zum Schutz der betroffenen Personen vor dem Missbrauch der verarbeiteten Daten. Sie werden bei der Erstellung des Produkts Beitrag zum Datenschutzkonzept vollständig erhoben und umfassen beispielsweise auch Anforderungen an die Organisation.
Dieses Thema umfasst alle Datenschutzanforderungen, die für die Entwicklung des Systems von Belang sind. Dabei kann es sich sowohl um funktionale als auch nicht-funktionale Anforderungen handeln. Sie stellen im V-Modell ein eigenständiges Thema dar, um den Aspekt Datenschutz zu betonen. Die Anforderungen können dabei beispielsweise das Nicht-Speichern von Daten, das Nicht-Protokollieren oder das (regelmäßige) Löschen von Daten betreffen. Aus den im BDSG festgeschrieben Rechten der betroffenen Personen können sich ebenfalls Anforderungen zur Auskunftsfähigkeit des entwickelten Systems ableiten.
Die Anforderungen zur Gewährleistung der Informationssicherheit der personenbezogenen Daten finden sich im Thema IT-Sicherheitsanforderungen und Schutzbedarf. Aus datenschutzrechtlicher Sicht ergibt sich ein Schutzbedarf insbesondere für die Schutzziele Integrität und Vertraulichkeit.
Hinweis: Die Anforderungen zum Datenschutz und die Anforderungen zur IT-Sicherheit stehen manchmal im Widerspruch zueinander. Beispielsweise kann aus dem Blickwinkel der IT-Sicherheit eine umfassende Protokollierung zur Integrität der Daten beitragen, während die Protokollierung aus datenschutzrechtlicher Sicht nicht gewünscht ist. Ziel muss es sein, solche Widersprüche zu erkennen und aufzulösen.
C.1.10.1.5 IT-Sicherheitsanforderungen und Schutzbedarf
Für den Betrieb sicherheitskritischer Systeme (im Sinne der Informationssicherheit) existieren besondere Anforderungen. Diese dienen zum Schutz der verarbeiteten Informationen vor Verlust der Integrität, Vertraulichkeit und Verfügbarkeit und umfassen auch IT-Sicherheitsanforderungen zum Schutz der technischen Anlagen zur Informationsverarbeitung und Informationsübermittlung. Sie werden bei der Erstellung des Produkts Beitrag zum IT-Sicherheitskonzept vollständig erhoben und umfassen beispielsweise auch Anforderungen an die Organisation.
Dieses Thema umfasst alle IT-Sicherheitsanforderungen, die für die Entwicklung des Systems von Belang sind. Dabei kann es sich sowohl um funktionale als auch nicht-funktionale Anforderungen handeln. Sie stellen im V-Modell ein eigenständiges Thema dar, um den Aspekt IT-Sicherheit zu betonen. Das Thema umfasst auch den Schutzbedarf von fachlichen Systemkomponenten hinsichtlich der Schutzziele Integrität, Vertraulichkeit und Verfügbarkeit, die sich aus der Skizze des Lebenszyklus und der Gesamtsystemarchitektur ergeben.
C.1.10.1.6 Skizze des Lebenszyklus und der Gesamtsystemarchitektur
Für die Einordnung, Systematisierung, Kategorisierung und auch Priorisierung von Anforderungen ist ein Koordinierungsrahmen hilfreich, um die Visualisierung der Anwenderanforderungen zu erleichtern. Diese Aufgabe kann eine Gesamtsystemarchitektur leisten, die die Sichtweise des Anwenders und/oder des Betriebs repräsentiert. Sie ist ein nicht verbindlicher Vorschlag, der organisatorische, fachliche aber auch technische Sichten darstellen kann.
Die Gesamtsystemarchitektur muss eine Verbindung zu den im Thema Abgrenzung des Systems benannten Geschäftsprozessen, (Nachbar-)Systemen und im Weiteren zu den Anforderungen herstellen. Dieses dient Thema dazu,
- Fakten wie z.B. verbindlich einzusetzende, bereits etablierte Systeme zu benennen (etwa ein konkretes Datenbankmanagementsystem).
- Vorstellungen zu artikulieren, wie die Realisierung und die Einbettung des zu entwickelnden Systems möglich ist (etwa Zugriff über mobile Rechner).
Festlegungen werden an dieser Stelle nur insofern getroffen, als dass sie Fakten betreffen, die die Entwickler zwingend berücksichtigen müssen. Ansonsten dient dieses Thema dazu, Erwartungen an die Einbettung des Systems hinsichtlich der fachlichen Funktion und der technischen Einbettung zu formulieren.
Zur Darstellung der fachlichen Architektur eignen sich einfache Grafiken. Auch eine modellbasierte Darstellung, z.B. mittels UML-Komponentendiagrammen, kann erfolgen.
Lebenszyklus
Der Lebenszyklus des zu entwickelnden Systems endet nicht mit der Erstellung des Produkts, sondern umfasst auch noch die Zeit nach der Überführung in den Wirkbetrieb, in der Fehlerbehebungen, Anpassungen und Erweiterungen der Funktionalität vorgenommen werden. Der Lebenszyklus endet schließlich mit der Ablösung des Systems durch ein Nachfolgeprodukt. Es wird daher dargelegt,
- wie die Weiterentwicklung des Systems nach dem Projekt weitergeht,
- wie Nutzung und Betrieb verlaufen,
- ob und welche Ausbaustufen des Systems geplant sind,
- wann und wie das System stillgelegt werden soll.
Diese Punkte besitzen einen entscheidenden Einfluss auf die Entwicklung des Systems und insbesondere auf die Erstellung der Systemarchitektur.
C.1.10.1.7 Lieferumfang
Es werden alle Gegenstände und Dienstleistungen aufgelistet, die während des Projektverlaufs oder bei Abschluss des Projektes vom Auftragnehmer an den Auftraggeber zu liefern sind. Jede Lieferung (von AN) erfordert eine Abnahmeprüfung. Der Lieferumfang kann je nach Vereinbarung das System, Teile des Systems, ein Unterstützungssystem, Teile eines Unterstützungssystems, Dokumente und vereinbarte Dienstleistungen enthalten.
C.1.10.1.8 Abnahmekriterien
Abnahmekriterien legen fest, welche Kriterien die Lieferung (von AN) erfüllen muss, um den an sie gestellten Anforderungen zu entsprechen. Sie sollen prüfbar dargestellt werden. Abnahmekriterien beziehen sich sowohl auf funktionale als auch auf nicht-funktionale Anforderungen.
In der Phase bis zur Auftragsvergabe können die Abnahmekriterien nur in einer allgemeinen Form, z.B. als K.O.-Kriterien, angegeben werden. Die allgemeinen Abnahmekriterien sollten auch die Forderung nach einer Erstellung von Abnahmekriterien durch den Auftragnehmer enthalten. Dabei sind der Aufbau und die Anzahl der Abnahmekriterien durch den Auftraggeber zu skizzieren. Eine Strukturierung der Abnahmekriterien nach ihren drei wesentlichen Bestandteilen
- Ausgangssituation,
- Aktion(en) und
- erwartetes Ergebnis
ist anzustreben. In jedem Fall müssen die erwarteten Ergebnisse der Abnahme pro Abnahmekriterium festgelegt werden.
Die Abnahmekriterien sind Grundlage der Abnahmeprüfung und ggf. auch für die Prüfung zur betriebliche Freigabe und gehen als Anforderungen in die Prüfspezifikation Lieferung sowie ggf. in die Prüfspezifikation Inbetriebnahme ein.
|
Erzeugt |
Abnahme der Lieferungen: Prüfung der Lieferungen: |
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.