Die IT-Abteilung eines Kunden hat eine hausinterne Oracle Forms Applikation selber entwickelt. Die Implementierung der nächsten Ausbaustufe sollte wegen Mangels an Ressourcen extern vergeben werden.
Bis zu dem Zeitpunkt, zu dem wir hinzugezogen wurden, bestand das kleine Projektteam aus 2-3 Mitarbeitern aus Fachabteilungen – die die Anforderungen an die Applikation definierten – und 2 Entwicklern der IT-Abteilung, von denen einer die Projektleitung innehatte.
Die Kommunikation zwischen den Mitarbeitern der Fachabteilungen und den Entwicklern verlief auf „dem kurzen Dienstweg“; Änderungswünsche sowie Fehlermeldungen wurden quasi auf Zuruf bearbeitet.
Die Anforderungen an die nächste Ausbaustufe wurden zwar in einem Pflichtenheft dokumentiert, dieses war aber sehr informell gehalten und eher nach dem Motto „Vom Projektteam versteht sowieso jeder, was gemeint ist.“ erstellt worden.
Insgesamt also eine Projektsituation, wie man sie sehr häufig vorfindet.
Nur – ein solches Pflichtenheft ist weder als Basis für einen Vertrag mit einem externen Software-Entwickler noch als Entwicklungsgrundlage tauglich.
Eine Anforderung muss u.A. folgende qualitativen Kriterien erfüllen[1] :
- Eindeutigkeit
Eine Anforderung darf nur auf eine einzige Art und Weise verstanden werden können, d.h. es darf keine unterschiedlichen Interpretationsmöglichkeiten geben.
- Realisierbarkeit
Es muss möglich sein, eine Anforderung innerhalb der vertraglichen Randbedingungen (Kosten- und Terminbedingungen usw) umzusetzen.
- Prüfbarkeit
Eine Anforderung muss so beschrieben sein, dass sie prüfbar ist; die geforderte Funktionalität muss also nachweisbar sein.
- Abgestimmtheit
Alle Projektbeteiligten (Fachabteilungen, Anwender, Entwickler) müssen das gleich Verständnis von der Anforderung haben und dieser zustimmen.
Folgende Beispiele sind dem erwähnten Pflichtenheft entnommen – sie verdeutlichen aber generell die qualitativen Einschränkungen von Anforderungen, die nach wie vor zum Projektalltag gehören.
|
Anforderung
|
Qualitative Aspekte
|
|
“Bei Änderung des Status ist das jeweilige Datum zu speichern. Die Datumswerte sind auf Wunsch anzeigbar.”
|
· Die Anforderung ist nicht eindeutig.
Es bleibt eine Reihe von offenen Fragen:
o Wer/was ändert den Status?
o Welches ist das „jeweilige“ Datum?
o Wo sollen die Datumswerte angezeigt werden?
· Die Anforderung ist nicht prüfbar.
Aufgrund der Mehrdeutigkeit lassen sich keine Testfälle aus der Anforderung ableiten.
|
|
“Es ist eine Modellübersicht zu schaffen, die vom Look&Feel identisch zu dem Online-Katalog-System ist.”
|
· Die Anforderung ist nicht realisierbar.
Bei dem erwähnten Online-Katalog handelte es sich um eine Web-Anwendung im Corporate Design mit asynchronen dynamischen Inhalten (AJAX). Ihn „identisch“ nachzubilden, hätte den Rahmen des Projekts vollkommen gesprengt. Letztlich entsprach dies auch nicht der Forderung der Fachabteilung.
|
|
“Innerhalb der Modellübersicht soll nach dem Anlagedatum gesucht werden können.”
|
· Die Anforderung war nicht abgestimmt.
Nicht das Anlagedatum sollte als Suchkriterium dienen, sondern das Bestelldatum abhängiger Warenproben – was eine wesentlich komplexere Suchfunktionalität bedeutete.
|
Die anfängliche Schwierigkeit, den Kunden zu überzeugen, dass die Anforderungen mit den Fachabteilungen präzisiert und im Pflichtenheft neu formuliert werden müssten, konnten wir letztlich mit dem Argument aus dem Weg räumen, dass mit allen Beteiligten abgestimmte, vollständig und korrekt dokumentierte sowie nachvollziehbare Anforderungen die Basis sind für
· den Vetrag zwischen Auftraggeber und Dienstleister
(Anforderungen sind rechtlich verbindlich. Mehrdeutige Anforderungen erzeugen Konfliktpotential zwischen den Vertragspartnern.)
· eine realistische Einschätzung von Entwicklungs- und Testaufwänden
(Sicherheit der Aufwandsschätzung bedeutet auch Termin- und Kosten-Sicherheit.)
· die funktionale Spezifikation der Anwendung
(Mehrdeutige oder nicht abgestimmte Anforderungen führen zu einer falschen bzw. zu einer im Sinne der Spezifikation korrekten aber nicht brauchbaren Umsetzung.)
· die Herleitung von Testfällen
(Eine gute Testabdeckung stellt die Qualität des Produktes fest, welche für seine vertragliche Abnahme verlangt wird.)
· die spätere Wartung des Produktes
(Auswirkungen von späteren Programmänderungen auf andere Programmteile lassen sich anhand von eindeutig identifizierbaren, verfolgbaren Anforderungen analysieren.)
Der Kunde beauftragte uns letztlich, ein Verfahren zur Abstimmung und Nachverfolgung von Anforderungen im Haus zu implementieren sowie einen Firmenstandard zur Dokumentation von Anforderungen zu definieren. Die Struktur des neuen Pflichtenheftstandards basierte auf dem IEEE- Standard 830-1998 (Recommded Practice for Software Requirements Specifications).
[1] Klaus Pohl, Chris Rupp: Basiswissen Requirement Engineering
blog
