Anforderungen (Lastenheft)

Beschreibung V-Modell: Anforderungen (Lastenheft)

Das Produkt Anforderungen (Lastenheft) enthält alle an das zu entwickelnde System identifizierten Anforderungen. Es ist Grundlage für Ausschreibung und Vertragsgestaltung und damit wichtigste Vorgabe für die Angebotserstellung. Das Lastenheft ist Bestandteil des Vertrags zwischen Auftraggeber und Auftragnehmer. Mit den Anforderungen werden die Rahmenbedingungen für die Entwicklung festgelegt, die dann vom Auftragnehmer in der Gesamtsystemspezifikation (Pflichtenheft) detailliert ausgestaltet werden.

Für die Erstellung der Anforderungen (Lastenheft) berücksichtigt der Anforderungsanalytiker Herr Sokrates sowohl die Vorgaben aus dem Projektvorschlag als auch aus der vorangegangenen Projektfortschrittsentscheidung. Dazu nimmt er das bereits erstellte Kapitel Projektziele und Systemvorstellungen des Projektvorschlags als Basis und passt es spezifisch für die Projektstufe InfoMaPa I an.

Bei weiteren Recherchen findet Herr Sokrates heraus, dass die MaPaTUM über ein über das Internet zugängliches Auskunftssystem namens MaPaForum verfügt. Vorhandene Akten werden über dieses System der Öffentlichkeit präsentiert. Es liegt also nahe, für InfoMaPa I eine Schnittstelle zu dem bereits bestehenden System MaPaForum zu konzipieren.

Anforderungen (Lastenheft): Ausgangssituation und Zielsetzung

Die Verwaltung und Bearbeitung der Akten der MaPaTUM soll durch das neu zu entwickelnde Informationssystem Marken- und Patentverwaltung (InfoMaPa) elektronisch unterstützt werden.

Die erste Projektstufe von InfoMaPa, InfoMaPa I, wird nur die Beantragung von Marken unterstützen.

Im Einzelnen wird InfoMaPa I

die Erstellung von Markenanträgen,
die Prüfung von Markenanträgen durch die MaPaTUM,
die Zurückweisung von Markenanträgen durch die MaPaTUM,
die Beantragung von Marken beim Deutschen Patent- und Markenamt (DPMA) durch die MaPaTUM und
die Veröffentlichung der vorhandenen Akten im bestehenden Auskunftssystem MaPaForum für die Öffentlichkeit

unterstützen. Für jede anzumeldende Marke wird eine Akte mit Daten angelegt, geprüft und gegebenenfalls per Fax an das DPMA weitergeleitet.

Als ersten Schritt zur Erstellung des Kapitels Funktionale Anforderungen identifiziert der Anforderungsanalytiker Herr Sokrates die Akteure, die mit dem System InfoMaPa interagieren. Zu den Anforderungen selbst gelangt er über die Frage, welche Aufgaben das System für diese Akteure im Einzelnen erfüllen soll. Diese Anwendungsfälle – auch Use Cases genannt – skizziert er in einer Überblicksgrafik.

Wie diese Use Cases genau aussehen, beschreibt der Anforderungsanalytiker Herr Sokrates im Anschluss an die Überblicksgrafik. Dafür verwendet er eine einheitliche Beschreibungsmethodik, die nicht vom V-Modell vorgegeben wird, deren Anwendung sich aber schon in früheren Projekten bewährt hat. Alle Use Cases werden damit gleichartig beschrieben (siehe Abbildung 5 ). Die Erstellung von eindeutigen, nachvollziehbaren, überprüfbaren und vollständigen Anforderungen wird dadurch erleichtert (Quelle: RD02).

Abbildung 5: Use Case-Formular

Das folgende Beispiel zeigt die Anwendung dieser Schablone anhand des Use Case <<Eintrag bearbeiten>>.

Anforderungen (Lastenheft): Funktionale Anforderungen (fortgesetzt)

Use Case 4.3: <<Eintrag bearbeiten>>

Ansprechpartner:

Anforderungsingenieur, Herr Sokrates, MaPaTUM

Kurzbeschreibung:

Das System muss dem Antragsteller die Möglichkeit geben, seinen Eintrag zu bearbeiten.

Priorität:

hoch

Anmerkungen:

Die Aktenzeichennummer (AZN) wird automatisch vergeben und macht den Eintrag eindeutig identifizierbar.

Offene Punkte:

keine

Einordnung und Überblick:

Eintrag verwalten

Vorbedingungen:

Alle beizufügenden Unterlagen sind in elektronischer Form vorhanden.

Auslöser:

Der Antragsteller will einen Antrag zur Eintragung seiner Marke stellen.

Nachbedingungen:

Der Antragsteller und der Prüfer bekommen eine Benachrichtigung, die die AZN enthält.

Normalablauf:

Der Antragsteller wählt die Funktionalität zum Erstellen eines neuen Antrags.
Das System zeigt eine Eingabemaske.
Der Antragsteller kann seine persönlichen Daten eingeben (Name, Adresse, Tel., E-Mail, Matrikelnummer).
Der Antragsteller kann Dateien hinzufügen oder löschen.
Der Antragsteller übermittelt den Eintrag.
Das System vergibt eine Aktenzeichennummer (AZN).
Das System speichert den Eintrag ab.
Verwende Use Case 6 <<Benachrichtigen>>
Das System zeigt die AZN an.

Alternativablauf:

Bevor der Eintrag übermittelt wird, kann der Vorgang jederzeit abgebrochen werden. Der Eintrag wird nicht gespeichert und der Anwendungsfall ist beendet.
Der Antragsteller lädt keine Datei hoch. Das System macht ihn darauf aufmerksam, dass jedem Antrag eine Markendatei beiliegen muss. Der Fehler muss behoben werden, sonst kann nicht übermittelt werden.
Der Antragsteller gibt unvollständige oder falsche persönliche Informationen ein. Das System leitet zur Berichtigung an, sonst kann nicht übermittelt werden.

...

Anforderungen an weitere Qualitätseigenschaften des Systems – beispielsweise Benutzerfreundlichkeit und Zuverlässigkeit – oder an den Erstellungsprozess des Systems arbeitet der Anforderungsanalytiker Herr Sokrates im Kapitel Nicht-Funktionale Anforderungen aus.

Anforderungen (Lastenheft): Nicht-funktionale Anforderungen

Das spezifizierte System hat dem aktuellen Stand der Technik sowie den arbeitsorganisatorischen und gesetzlichen Rahmenbedingungen an der TUM zu entsprechen. Es muss sich nahtlos in die bestehende DV-Umgebung einpassen. Es werden die folgenden spezifischen Anforderungen gestellt:

Qualitätsanforderungen

Benutzerfreundlichkeit

NF 1: Der Anwender muss zeitnah (Antwortzeit < 0,5s) auf Fehler und falsche Eingaben hingewiesen werden. Er muss durch eine Hilfefunktion bei der Anwendung unterstützt werden.
NF 2: Die graphischen Oberflächen müssen übersichtlich, einheitlich strukturiert und robust sein und die geforderte Funktionalität anbieten. Sie müssen intuitiv bedienbar sein, das heißt, der Anwender muss ohne Schulung, also nur mit der angebotenen Hilfefunktion, fähig sein, mit dem System umzugehen.
NF 3: Die Benutzeroberfläche für die Eingabe sollte an die webbasierte Oberfläche des DPMA angelehnt sein.

Zuverlässigkeit & Schutz

NF 4: Das System muss jederzeit – auch unter Last – zuverlässig reagieren. Es darf nicht zu unkontrollierten Systemabstürzen oder Datenverlust kommen. Bei einem Ausfall ist sicherzustellen, dass zumindest auf den Daten des Vortages wieder aufgesetzt werden kann.
NF 5: Programme und Daten müssen gegen zufällige und unabsichtliche Veränderungen geschützt werden.

Systemerstellungsanforderungen

Technische Anforderungen

NF 7: Die Implementierungssprache ist Java.
NF 8: Das Zielsystem ist Windows XP.
NF 9: Das System soll komponentenbasiert entwickelt werden, um leichtere Wartbarkeit und Erweiterbarkeit zu erreichen.

Anforderungen an die Logistik

NF 10: Das System muss einschließlich seiner Entwicklungsumgebung in geeigneter Weise dokumentiert und damit wartbar sein.
NF 11: Die Architektur des Systems soll, soweit möglich, mit der Unified Modeling Language (UML) dokumentiert werden.
...

...

Um die aufgestellten Anforderungen plastischer zu machen und zudem der Gefahr technisch nicht umsetzbarer Anforderungen zu entgehen, überlegt sich der Anforderungsanalytiker Herr Sokrates mit einem Kollegen zusammen eine erste grobe Architektur des Systems. Diese legt er im Kapitel Skizze des Lebenszyklus und der Gesamtsystemarchitektur nieder.

Für die Architektur von InfoMaPa I ist ein webbasiertes Client-Server-Modell vorgesehen. Dieses besteht aus Datenbank, Systemkern und einer webbasierten Benutzeroberfläche. Markenanträge verschickt InfoMaPa I per Email an das DPMA.

Diese Version der Anforderungen legt der Anforderungsanalytiker Herr Sokrates nun einer Gruppe von zukünftigen Anwendern zur Bewertung vor.

Wir haben den Weg des Projektes anhand der Darstellung der Projektergebnisse – nämlich der Produkte – und ihrer Zusammenhänge in ihrem Entstehungsprozess verfolgt, um den Ablauf eines Projektes nach V-Modell zu illustrieren. Der weitere Ablauf erstreckt sich über die Ausschreibung, Beauftragung und schließlich die Abnahme des Systems. Die Bewältigung dieser Projektabschnitte in einem realen Projekt sowie die Bewältigung eines Auftragnehmer-Projektes bleibt dem Leser selbst überlassen.