Erfolgreiche Projekte dank Requirements Engineering (Teil 2)

Im ersten Teil dieses Beitrages haben wir mögliche Herausforderungen aufgezeigt, mit denen das Requirements Engineering zu tun hat – alles Faktoren, die ein Projekt zum Scheitern bringen können. Gerade deshalb ist es so wichtig, Ziele und Anforderungen zu definieren und einander gegenüber zu stellen. Wie man das macht, zeigt Ihnen dieser Beitrag.

Ziele vs. Anforderungen

Ziele sind immer die Beschreibung des gewünschten Soll- oder Endzustandes. Ziele lassen sich nicht testen, Anforderungen hingegen schon. Deshalb sollte jede Anforderung dazu beitragen ein Ziel zu erfüllen. Mit anderen Worten: mit jedem Bedarf, jedem Anspruch an ein System muss klar sein, welche Ziele damit erreicht werden können. Findet man kein passendes Ziel, sollte man sich dringend überlegen, ob die Anforderung wirklich eine solche ist.

Es empfiehlt sich, Ziele nach der SMART-Formel [1] aufzustellen:

• S – Spezifisch – Ziele müssen eindeutig definiert sein (nicht vage, sondern so präzise wie möglich).
• M – Messbar – Ziele müssen messbar sein (Messbarkeitskriterien).
• A – Ansprechend – Die Ziele müssen für die Person ansprechend bzw. erstrebenswert sein
• R – Realistisch – Das gesteckte Ziel muss möglich und realisierbar sein.
• T – Terminiert – Das Ziel muss mit einem fixen Datum festgelegt werden können.

Wie werden Anforderung definiert?

Das IEEE (Institute of Electrical and Electronics Engineers) legt eine mögliche Definition von „Anforderung“ (Requirement) wie folgt fest:

„Eine Fähigkeit oder Voraussetzung, Bedingung, Eigenschaft, die ein System (Maschine, Software, Person, etc.) erfüllen oder besitzen muss, um einen Vertrag, eine Norm, oder ein anderes formell bestimmtes Dokument zu erfüllen.“ [2]

Die Disziplin Requirements Engineering kümmert sich um Systemanforderungen. Gemäss IREB (International Requirements Engineering Board) werden diese Anforderungen in drei Unterkategorien aufgeteilt [3]:

• Funktionale Anforderungen: „Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.“
• Qualitätsanforderung: „Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.“
• Randbedingung (Rahmenbedingung): „Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.“

Im dritten und letzten Teil des Beitrages geht es um die Ziel- und Anforderungshierarchie im Requirements Engineering und Sie erfahren, welchen Qualitätsanforderungen die einzelnen „Requirements“ gerecht werden müssen, um während des Projektes keine bösen Überraschungen zu erleben. Demnächst in diesem Blog.

[1] SMART (Projektmanagement), Wikipedia, abgerufen am 13.04.2017

[2] IEEE 610.12-1990

[3] Handbuch Requirements Management nach IREB Standard, V1.01, abgerufen am 13.04.2017

Hier finden Sie die anderen beiden Beiträge zum Thema aus der Reihe Glaux Soft Know-how:

Zurück zu Teil 1

Vor zu Teil 3