

Wie Sie als Projektleiter Anforderungen für eine Software beauftragen, haben Bettina Zastrow und Elisabeth Wagner bereits in der Artikelserie "Requirements Engineering für Projektleiter" beschrieben. In einem nächsten Schritt müssen die darin erstellten Anforderungen aber noch genau geprüft, priorisiert und Änderungen an den Anforderungen verwaltet werden. Die Autorinnen zeigen Ihnen in diesem Artikel, worauf Sie bei diesen Maßnahmen achten sollten.
Wie Sie als Projektleiter Anforderungen für eine Software beauftragen, haben Bettina Zastrow und Elisabeth Wagner bereits in der Artikelserie "Requirements Engineering für Projektleiter" beschrieben. In einem nächsten Schritt müssen die darin erstellten Anforderungen aber noch genau geprüft, priorisiert und Änderungen an den Anforderungen verwaltet werden. Die Autorinnen zeigen Ihnen in diesem Artikel, worauf Sie bei diesen Maßnahmen achten sollten.
Für Projektleiter, die für die Beauftragung von Software verantwortlich sind, ist ein professionelles Auftragsmanagement das A und O. Eindeutig formulierte und vollständige Anforderungen sorgen dafür, dass sich Stakeholder und Projektleitung ebenso verstehen wie Projektleitung und Software-Entwickler. Die Gefahr von Missverständnissen, die unnötig Zeit und Geld kosten, wird dadurch minimiert. In der Artikelserie "Requirements Engineering für Projektleiter" wurde beschrieben, wie Projektleiter Schritt für Schritt zu vollständigen Use Cases aus Sicht der künftigen Nutzer gelangen und aus diesen detaillierte technische Anforderungen (Requirements) für die Software-Entwicklung ableiten. Im vorliegenden Artikel stehen drei weitere Aufgaben eines professionellen Requirements Engineering im Mittelpunkt:
Als Projektbeispiel dient wie in den erwähnten vorangegangenen Beiträgen die Programmierung eines Online-Shops für Musikclips ("Jingleshop"), die von Komponisten hochgeladen und von Interessenten gekauft werden können. Als interner Auftraggeber fungiert der Produktmanager, als interner Auftragnehmer der Projektleiter.
Es wird vorausgesetzt, dass alle Anforderungen von den Stakeholdern abgefragt und tabellarisch (wie in der Artikelserie "Requirements Engineering für Projektleiter" beschrieben) erfasst wurden. Das heißt, die einzelnen Anforderungen haben zu diesem Zeitpunkt bereits eine Qualitätsprüfung durchlaufen: Sie sind bewertet, eindeutig, konsistent, prüfbar, verfolgbar und vollständig.
Damit ist ein wichtiger Schritt getan. Doch erst in der Gesamtsicht wird erkennbar, ob die Liste der Anforderungen vollständig und in sich konsistent ist. Es kann noch sein, dass Anforderungen
Wie kommen solche Mängel trotz Sorgfalt bei der Definition der Anforderungen zustande? Die Ursachen sind vielfältig. Erstens sind Stakeholder aus verschiedenen Bereichen mit unterschiedlichen Perspektiven involviert. Das kann zu divergierenden Wünschen und Anforderungen führen. Zweitens gibt es möglicherweise noch Begrifflichkeiten, die je nach Abteilung anders definiert sind. Drittens kann es sein, dass sich in der Zwischenzeit technische Neuerungen ergeben haben – wie z.B. eine neue Betriebssystemversion – oder es sind Ereignisse eingetreten, die sich auf die Anforderungen auswirken, etwa ein Personalwechsel beim Produktmanagement. Viertens kann es neue oder zunächst nicht bekannte technische, organisatorische oder juristische Beschränkungen geben, die verhindern, dass Anforderungen wie ursprünglich geplant umgesetzt werden können, etwa Vorgaben der Corporate Identity und der Compliance.
Am häufigsten kommt es vor, dass sich mehrere Anforderungen widersprechen: Eine Anforderung sieht eine Bestellung ohne Registrierung vor ("Anmelden als Gast"), eine andere Anforderung verlangt, dass der Nutzer sich vor der Bestellung mit Name und Adresse registrieren muss. Manchmal erkennt auch der Auftraggeber erst im Laufe der Abstimmung mit den Entwicklern, was umsetzbar ist und was nicht – bzw. nur mit einem hohen Aufwand – und ordnet eine Kurskorrektur an.
Die folgende Tabelle enthält für jeden der oben genannten möglichen Mängel jeweils ein Beispiel und dazu einen Vorschlag, wie das Problem behoben werden könnte.
Mangel / Kriterium | Anforderung | Erläuterung | Lösungsvorschlag |
---|---|---|---|
Verständ- lichkeit |
Der Benutzer mit der Rolle "Produktpflege" muss die Möglichkeit haben, Metadaten einzugeben. | Der Begriff "Metadaten" ist nicht definiert. Entweder sollte er in das Glossar aufgenommen oder wie rechts angegeben formuliert werden. | Der Benutzer mit der Rolle "Produktpflege" muss die Möglichkeit haben, folgende Produktmerkmale einzugeben: •Name des Komponisten •Name des Songs •Länge •Genre •instrumental/vokal … |
Aktualität | Das System muss das Client-Betriebssystem Windows XP unterstützen. | Dieses Betriebssystem wird von Microsoft nicht mehr unterstützt. | Das System muss das Client-Betriebssystem Windows 8.x unterstützen. |
Konsistenz | Anforderung 1: Das System muss bei einer Zahlung, die seit 2 Wochen aussteht, eine Benachrichtigungs-E-Mail an den Kunden versenden. Anforderung 2: Steht eine Zahlung länger als 10 Kalendertage aus, so hat das System die Bestellung zu stornieren. |
Es muss eine Entscheidung für eine der beiden widersprüchlichen Varianten erfolgen. | Das System muss bei einer Zahlung, die seit 2 Wochen aussteht, eine Benachrichtigungs-E-Mail an den Kunden versenden. |
Notwendig- keit |
Das System soll Benutzern mit der Rolle "Komponist" die Möglichkeit bieten, beliebig viele Produktfotos hochzuladen. |
Mehr als 2 Produktfotos sind bei Musikdateien nicht gebräuchlich. … |
1 Monat unverbindlich testen!
Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.