Es gibt die verschiedensten Fachbereiche. Wenn sie z.B. im Bereich embedded Software Entwicklung engagiert sind, dann ist bereits bei der Festlegung der Hardware- und Software Architektur und bei der Testfall Entwicklung die detaillierte Kenntnis der Anforderungen der entscheidende Projekterfolgsfaktor.
Warum?
Nun, neuerdings reden viele von Scrum, der agilen Projektmanagement Methode. Aber auch, wenn man iteratives Projektmanagement anwendet, ist es wichtig und nicht nur dann, bereits bei Projektbeginn das Endprodukt, die vereinbarte Leistung im Detail zu kennen. Denn durch den iterativen Prozess ist man unter Umständen nur auf den ersten Iterationsschritt fixiert und vernachlässigt wichtige Erkenntnisse für das Gesamtprodukt. Nicht wer sofort anfängt erreicht sein Ziel schneller, nein, wer genau weiß was zu leisten ist, ist klar im Vorteil.
Nebenher gesagt, es scheint so, dass das V-Modell und/oder Wasserfallmodell bereits aus der Mode sind und man vergisst dabei, dass die Requirements auch bei SCRUM die Basis zum Erfolg sind.
Die Anforderungen zu spezifizieren ist nicht immer einfach. Der Kunde schreibt ein Lastenheft, grob ausgedrückt eine Wunschliste an das Produkt, und dass womöglich aufgeteilt in unterschiedliche Funktionen, welche noch dazu von unterschiedlichen Funktions-Verantwortlichen geschrieben wurden. Mit anderen Worten die Anforderungen sind nicht konsolidiert.
Aus diesem Grund sind die Anforderungen des Kunden oftmals sehr unterschiedlich innerhalb eines Produktes und es kann sein, dass so manch ein Wunsch mit unterschiedlichen Worten, in mehreren Funktionen beschrieben ist. Um diese aufzulösen, bedarf es Requirement Engineers welche diese gleichgearteten Wünsche erkennen und in einem Tool bewerten und zueinander verlinken. Zudem ist es dabei wichtig, dass jedes Requirement eindeutig als umsetzbar ist. Dazu empfiehlt es sich die Requirement zu bewerten und mit dem Auftraggeber abzustimmen. Requirement , welche nicht umsetzbar sind, sind ebenfalls mit dem Auftraggeber zu besprechen und zu begründen.
Man kann die Requirements Bewertung wie folgt ausführen:
- Wird umgesetzt
- Bedarf zusätzlicher Informationen
- Kann technisch nicht realisiert werden
Noch ein Hinweis. Mit dem Kunden abgestimmte Requirement helfen zu einem späteren Zeitpunkt, wenn der Kunde Änderungen möchte, denn dann können sie als Auftragnehmer einen Change Request einfordern, welcher sich Monetär zum Vorteil für ihr Unternehmen auswirken kann. Das Thema Change Request folgt in einem weiteren Kapitel.
Über welche Requirement reden wir im Generellen?
Da sind die Funktionalen Anforderungen und die nicht funktionalen Anforderungen.
Die funktionalen Anforderungen sind diejenigen, welche sehr leicht zu identifizieren sind. Sie beschreiben einen Funktionszustand. Dazu ein Beispiel: Kundenforderung ist, mit dem Lichtschalter neben der Tür muss das Deckenlicht über dem Esstisch eingeschaltet werden können. Diese Aussage ist an und für sich eindeutig, oder doch nicht?
Das funktionale Requirement beschreibt eine Funktion, um jedoch dem Kunden die konkret geforderte Leistung zu erbringen, stellen sich bei dieser Kundenanforderung jedoch viele Fragen.
Offene Fragen sind, welche Spannung soll geschaltet werden? Wo soll der Schalter exakt montiert werden, daher in welcher Höhe und mit welchem Abstand zum Türrahmen. Welcher Schalter Typ, welches Design, wer liefert den Schalter. Und so weiter. Sie sehen, mit der einfachen Aussage des Auftraggebers entwickeln sich viele Fragen, welche es zu klären gibt um den Kundenauftrag erfolgreich umzusetzen.
Hier noch ein wichtiger Hinweis, Anforderungen beschreiben was gefordert ist, jedoch nicht das wie. Daher ein gutes Requirement beschreibt nicht wie eine Funktion umzusetzen ist, sondern welche Forderungen durch die Teams umzusetzen sind.
Der zweite große Block sind die nicht funktionalen Anforderungen. Was verbirgt sich dahinter?
Kurz ausgedrückt, nicht funktionalen Anforderungen beschreiben was ein System, ein Produkt leisten soll.
Daher, nichtfunktionalen Anforderungen an ein System können unterschiedlichster Art sein. Man hat versucht im Rahmen des ISO Standards 9126 unter anderem folgende Typen von nichtfunktionalen Anforderungen (Qualitätsattribute) zu identifiziert:
System Performanz: z.B. wie performant ist ein IT-System, wie lange läuft ein IT-System ohne Absturz etc.
Nutzbarkeit ist ein weiteres Thema. Ein großes Feld, denn bei Produkten schließt es die Funktionalität, die Handhabbarkeit, daher Einfachheit der Nutzung mit ein.
Denkt man an IT-Systeme, dann geht es auch um Portabilität
Und zuletzt, egal bei welchem Produkt oder System geht es auch um die Sicherheit der Menschen, welche mit dem Produkt arbeiten oder in irgendeiner Art in Berührung kommen.
Die Kunst liegt nun darin, dass die Requirement Engineers die nichtfunktionalen Anforderungen erkennen, diese abstrakten Attribute als messbare Qualitätsattribute festschreiben und mit dem Auftraggeber abstimmen.
Das Ziel ist, für nicht funktionale Anforderungen verlässliche messbare Qualitätsvorgaben zu definieren.
Ein Beispiel für eine nicht funktionale Anforderung. Das System ist leicht zu bedienen. Nun, wie kann man das sicherstellen. Dies ist eine häufig anzutreffende Formulierung, die in Lastenheften festgeschrieben ist. Was bedeutet jedoch leicht zu bedienen?
Sie sehen, funktionale und nicht funktionale Anforderungen sind wichtig und aus meiner Sicht bilden diese das Rückgrat für ein erfolgreiches Projekt.
Gruß
Kurt Jelinek (MSc, Beng.)
Wanderreiten-Kurt Jelinek-Blog 