G Referenz Arbeitshilfen
G.2 Methoden und Werkzeuge
G.2.1 Methodenreferenzen
G.2.1.16 Vom Lastenheft zum Kriterienkatalog
Hinweis: Die vorliegende Methodenreferenz bezieht sich insbesondere auf Projekte, bei denen der Auftragnehmer mit einer (öffentlichen oder nicht-öffentlichen) Ausschreibung oder einem (offenen oder nicht-offenen) Verfahren ermittelt wird.
Für die Entwicklung eines IT-Systems ergeben sich für den Auftraggeber bereits vor Vertragsschluss zwei wichtige Aufgaben:
- Er muss die Anforderungen (Lastenheft) an das System möglichst genau spezifizieren, um selbst zu wissen, was das System leisten muss und um dieses Wissen auch für die Entwickler (beim Auftragnehmer) festzuschreiben.
- Er muss einen Kriterienkatalog (als Teil der Bewertungsmatrix) erstellen, auf Basis dessen die Bieter ihre Angebote erstellen. Da sich der Vertrag als Zuschlag auf ein Angebot ergibt, muss der Auftraggeber also sicher stellen, dass sich die definierten Anforderungen auch in den Angeboten der Bieter wiederfinden.
Während die erste Aufgabe zum Software und Systems Engineering gehört und einen erfahrenen Anforderungsanalytiker (AG) benötigt, ist die zweite Aufgabe Teil des Vergabeprozesses und benötigt einen erfahrenen Ausschreibungs- und Vertragsverantwortlichen. Im Folgenden wird eine Methode beschrieben, die den Weg von den definierten Anforderungen über eine Anforderungsbewertung hin zum Kriterienkatalog aufzeigt. Die Methode eignet sich für alle Arten von Anforderungen und Lastenhefte, also sowohl funktionale als auch nicht-funktionale, textbasierte und modellbasierte, präzise und schwammige. Die Methode gliedert sich in die Anforderungsbewertung, die anschließende Überarbeitung, die Strukturierung eines Kriterienkatalogs und die Ableitung von einzelnen Kriterien.
Bewertung der Anforderungen
Ausgangspunkt ist eine fertig gestellte Version der Anforderungen (Lastenheft). Die Bewertung der Anforderungen besitzt zwei Aspekte: Einerseits ist sie eine zusätzliche Qualitätssicherung für die definierten Anforderungen, andererseits werden dabei die Anforderungen durch die Brille des zukünftigen Auftragnehmers betrachtet.
Um dieses zu bewerten muss zunächst klar sein, welche Bewertungskriterien dafür herangezogen werden:
Die Priorität (Prio) beschreibt, wie wichtig die Umsetzung der Anforderung für die Gesamtfunktionalität des Systems bzw. für den Erfolg des Projekts ist. Idealerweise sollte sie bereits im Lastenheft definiert sein und hier nur übernommen werden müssen. Mögliche Werte sind hier:
|
Muss (m) |
Eine solche Anforderung muss vom System umgesetzt werden, um den Projekterfolg (z.B. gesetzlichen Auftrag) nicht zu gefährden. |
|
Soll (s) |
Eine solche Anforderung sollte wenn möglich (finanzierbar, realisierbar) umgesetzt werden. Für die Umsetzung gilt aber das Gebot der Wirtschaftlichkeit. |
|
Könnte (k) |
Eine solche Anforderung beschreibt einen Zusatznutzen, der beispielsweise die Akzeptanz der Benutzer erhöht. Eine solche Anforderung sollte umgesetzt werden, sofern dies möglich und kostengünstig oder kostenneutral erfolgen kann. |
|
Unnötig (u) |
Eine unnötige Anforderung sollte überhaupt nicht umgesetzt werden, in keinem Fall sollte für die Umsetzung einer solchen Anforderung Geld aufgewendet werden. |
Die Genauigkeit (Gen) beschreibt, wie präzise die Anforderung beschrieben ist. Mögliche Werte sind hier:
|
Sehr präzise (sp) |
Eine solche Anforderung ist vollständig beschrieben und lässt keinen Interpretationsspielraum. Dies bedeutet insbesondere, dass das Systemverhalten unter allen Umständen beschrieben ist (z.B. auch Ausnahmen, Fehlerfälle, Alternativwege), dass die handelnden Akteure klar sind und dass die verwendeten und verarbeiteten Daten(-strukturen) klar beschrieben sind. Sehr präzise Anforderungsbeschreibungen lassen sich insbesondere durch die Verbindung von Modellen (z.B. UML), strukturierten Texten (siehe Rupp) und mathematischen Ausdrücken (z.B. OCL) erreichen. |
|
weitgehend klar (wk) |
Eine solche Anforderung erfüllt nicht die oben genannten Anforderungen einer sehr präzisen Anforderung, dennoch ist mit gesundem Menschenverstand klar, wie die Anforderung verstanden werden soll. Es sind nicht alle Fehler- oder Ausnahmefälle beschrieben. |
|
schwammig/ offen (so) |
Eine solche Anforderung ist unklar, besitzt offene Punkte oder hohen Interpretationsspielraum, z.B. "Das System muss ergonomisch sein", "Das System muss performant arbeiten", etc. Manchmal können Anforderungen nur sehr schwammig beschrieben werden, denn eine präzise Beschreibung benötigt zu viel Aufwand. |
Die Verbindlichkeit (Verb) der Beschreibung legt fest, in welchem Verhältnis die Realisierung einer Anforderung zu ihrer Beschreibung steht. Diese Information ist als Ergänzung zur Genauigkeit wichtig: Beispielsweise kann das Systemverhalten in den Anforderungen (Lastenheft) zwar sehr präzise beschrieben sein, es stellt sich jedoch heraus, dass die Umsetzung davon auch abweichen darf. Wie die Priorität sollte sich auch die Verbindlichkeit aus dem Lastenheft ableiten lassen. Mögliche Werte sind hier:
|
Genau so (gs) |
Diese Verbindlichkeit bedeutet, dass das Verhalten des entwickelten Systems exakt dem in den Anforderungen spezifizierten Systemverhalten entsprechen muss. Diese Verbindlichkeit ist nur sinnvoll, sofern die Anforderung sehr präzise oder weitgehend klar ist. |
|
so oder ähnlich (soä) |
Diese Verbindlichkeit bedeutet, dass das Verhalten des entwickelten Systems von der definierten Anforderung abweichen darf. Dies ist sinnvoll, sofern eine Anforderung schwammig oder (wie eingangs beschrieben) "überpräzise" beschrieben ist. |
Die Realisierbarkeit (Real) beschreibt die grundsätzliche theoretische und technische Möglichkeit, die Anforderung umzusetzen. Mögliche Werte sind hier:
|
realisierbar (r) |
Die Anforderung ist sowohl theoretisch als auch mit den Mitteln der aktuellen Technik umsetzbar. |
|
unrealisierbar (ur) |
Die Anforderung ist nicht umsetzbar. Insbesondere die Grenzen der Physik und der Berechenbarkeit können dazu führen, dass eine Anforderung in diese Kategorie fällt. Beispiele hierfür sind die Definition von Reaktionsgeschwindigkeiten innerhalb eines global verteilten Systems oder auch die Suche nach optimalen Lösungen zu NP-harten Problem (z.B. Problem des Handlungsreisenden). |
|
unklar (uk) |
Es ist nicht klar, ob eine solche Anforderung realisierbar ist. |
Die Finanzierbarkeit (Fin) beschreibt, ob die Umsetzung der Anforderung unverhältnismäßig teuer ist, oder gar das kalkulierte Projektbudget sprengt. Mögliche Werte sind hier:
|
finanzierbar (f) |
Die Anforderung ist im Rahmen des Projektbudgets finanzierbar und erzeugt im Vergleich zu den anderen Anforderungen keine unverhältnismäßigen Mehrkosten. |
|
unfinanzierbar (uf) |
Die Anforderung sprengt das Projektbudget oder stellt eine unverhältnismäßige Verteuerung der Entwicklungskosten dar. Gerade überzogene nicht-funktionale Anforderungen (sehr kleine Reaktionszeit, sehr hohe Ausfallsicherheit, etc.) können die Entwicklungskosten enorm verteuern. |
|
unklar (uk) |
Es ist nicht schätzbar, wie viel die Umsetzung der Anforderung kosten wird. |
Hinweis: Die Finanzierbarkeit lässt sich in der Regel nicht anhand einer Anforderung ausdrücken, sondern ergibt sich aus den wechselseitigen Abhängigkeiten aller Anforderungen. Die hier getroffenen Aussagen sind deshalb sehr vereinfachend. Eine präzisere Beschreibung würde aber den Rahmen sprengen.
Auf Basis der vorgestellten Kriterien bewertet der Anforderungsanalytiker (AG) die einzelnen Bestandteile des Produkts Anforderungen (Lastenheft), was beispielhaft in der folgenden Tabelle dargestellt wird. Je nachdem, ob die Anforderungen als Prosa, strukturierter Text oder Modell verfasst sind, eignen sich als Bewertungseinheit Textabschnitte, Kapitel, einzelne Anforderungen oder Modelldiagramme. Die Untergliederung (vertikal) soll zumindest so feingranular erfolgen, dass sich für die einzelnen Kriterien eindeutige Werte ergeben: Besitzt also beispielsweise ein beschreibender Text teilweise die Priorität Muss und teilweise die Priorität Soll, so wird er nach diesem Kriterium aufgeteilt und benötigt somit zwei Tabellenzeilen.
Überarbeitung der Anforderungen
Auf Basis der Bewertungsergebnisse überarbeitet der Anforderungsanalytiker (AG) zunächst die Anforderungen. Dabei beachtet er insbesondere die in der folgenden Tabelle gegebenen Hinweise. Die zweite Spalte ist beispielweise folgendermaßen zu verstehen:
Anforderungen mit der Priorität Muss oder Soll, die schwammig/offen formuliert sind, bergen das Risiko, dass wichtige Bestandteile der Systemfunktionalität falsch verstanden werden und sollten daher überarbeitet und präzisiert werden.
|
Prio |
Gen |
Verb |
Real |
Fin |
Risiko |
Empfehlung |
|
u |
* |
* |
* |
* |
Dokument wird unnötig aufgebläht. |
entfernen |
|
m, s |
so |
* |
* |
* |
Wichtige Bestandteile werden falsch verstanden. |
überarbeiten und präzisieren |
|
m |
* |
* |
uk |
* |
Niemand kann das System realisieren. |
entweder so ändern, dass die Anforderung realisierbar ist, oder Priorität herabstufen |
|
m |
* |
* |
* |
uk |
Die Angebote übersteigen den Finanzrahmen. |
entweder so ändern, dass die Anforderung finanzierbar ist, oder Priorität herabstufen |
|
* |
* |
* |
ur |
* |
Unnötige Aufwände werden zur Realisierung investiert. |
realisierbar umformulieren oder streichen |
|
* |
* |
* |
* |
uf |
Die Angebote übersteigen den Finanzrahmen. |
finanzierbar umformulieren oder streichen |
Struktur des Kriterienkatalogs
Die Struktur des Kriterienkatalogs ist prinzipiell frei wählbar. Je mehr sich die Struktur jedoch an der Themenstruktur der Produkte Anforderungen (Lastenheft), Projekthandbuch und QS-Handbuch orientiert, desto leichter gelingt die Zuordnung zwischen den dort definierten Inhalten und dem Kriterienkatalog. Folgende Tabelle zeigt ein Beispiel, wie der Kriterienkatalog in Kriterienhauptgruppen (teilweise mit Untergruppen) untergliedert werden kann:
|
Kriterienhauptgruppe |
Kriteriengruppe |
Kriterium |
|
Verständnis von Ausgangssituation und Zielsetzung |
||
|
Funktionale Anforderungen |
||
|
Schnittstellen und Akteure |
||
|
Funktionalität |
||
|
Datenmodell |
||
|
Nicht-Funktionale Anforderungen |
||
|
Funktionalität |
||
|
Zuverlässigkeit |
||
|
Benutzbarkeit |
||
|
Effizienz |
||
|
Änderbarkeit |
||
|
Übertragbarkeit |
||
|
Randbedingungen |
||
|
Gesamtsystemarchitektur und Lebenszyklus |
||
|
Lieferung und Abnahme |
||
|
Projektmanagement (Vorgaben für das Projekthandbuch) |
||
|
Qualitätssicherung (Vorgaben für das QS-Handbuch) |
Ableitung von Kriterien
Unabhängig davon, ob die Anforderungen wie im vorangegangenen Abschnitt überarbeitet wurden, muss der Ausschreibungs- und Vertragsverantwortliche aus den Anforderungen (Lastenheft) einen Kriterienkatalog ableiten und die einzelnen Kriterien, die Kriteriengruppen und Kriterienhauptgruppen gewichten. Dabei kann er sich ebenfalls auf die Ergebnisse der Anforderungsbewertung stützen, die sich ggf. durch die Überarbeitung der Anforderungen verändert haben. Grundsätzlich sollte der Ausschreibungs- und Vertragsverantwortliche dabei folgende Regeln beachten:
- Genau die Anforderungen, die finanzierbar, realisierbar und nicht unnötig sind, sollten im Kriterienkatalog durch entsprechende Kriterien (Fragen an den Bieter) abgedeckt werden.
- Die Zuordnung von Anforderungen und Kriterien ist dabei flexibel: Beispielsweise kann sich ein B-Kriterium auf mehrere Anforderungen beziehen oder eine Anforderung kann durch ein B- und ein A-Kriterium umgesetzt werden.
- Die Gewichtung eines B-Kriteriums sollte sich daran orientieren, wie viele Anforderungen durch dieses B-Kriterium abgedeckt werden, und welche Priorität diese besitzen.
Die nachfolgende Tabelle dient als Hilfestellung für die Ableitung von Kriterien und die Überprüfung des Kriterienkatalog. Die letzte Zeile ist beispielsweise wie folgt zu verstehen:
Eine realisierbare und finanzierbare Anforderung mit Könnte-Priorität sollte keinesfalls Gegenstand eines A-Kriteriums sein. Dagegen ist es sinnvoll, die Umsetzung vom Bieter durch ein niedrig gewichtetes B-Kriterium zu erfragen.
|
Prio |
Gen |
Verb |
Real |
Fin |
Hinweise für Aufstellung von Kriterien |
|
u |
* |
* |
* |
* |
Keine Berücksichtigung im Kriterienkatalog |
|
* |
* |
* |
ur |
* |
Keine Berücksichtigung im Kriterienkatalog |
|
* |
* |
* |
* |
uf |
Keine Berücksichtigung im Kriterienkatalog |
|
* |
* |
* |
uk |
* |
Keinesfalls durch A-Kriterium abdecken; ggf. als optionales Kriterium; Hinweis in Kriterien, dass Realisierbarkeit unklar ist |
|
* |
* |
* |
* |
uk |
Keinesfalls durch A-Kriterium abdecken; ggf. als optionales Kriterium; Hinweis in Kriterien, dass Finanzierbarkeit unklar ist |
|
m |
sp, wk |
gs |
r |
f |
A-Kriterium, das die Umsetzung der Anforderung wie beschrieben zusichert * (siehe unten) |
|
m |
sp, wk |
soä |
r |
f |
A-Kriterium (siehe oben); zusätzlich hoch gewichtetes B-Kriterium |
|
m, s |
s |
* |
r |
f |
Kein A-Kriterium; hoch gewichtetes B-Kriterium; Frage nach der genauen Umsetzung stellen; Erwartungshaltung möglichst flexibel gestalten |
|
s |
sp, wk |
* |
r |
f |
Kein A-Kriterium; hoch gewichtetes B-Kriterium |
|
k |
* |
* |
r |
f |
Keinesfalls als A-Kriterium abdecken; niedrig gewichtetes B-Kriterium |
* = Theoretisch ist damit sichergestellt, dass die Anforderung wie beschrieben umgesetzt wird. Allerdings können sich durch die alleinige Umsetzung als A-Kriterium Verzerrungen in der Ermittlung des Leistungsumfangs ergeben, da das Erfüllen eines A-Kriterium nicht in die Leistungsbewertung mit eingeht.
|
Aktivitäten |
|
Quellen |