Anforderungsentwicklung nach CMMI

Eine der Process Areas, die einem auf dem Weg zu Maturity Level 3 begegnet, ist Requirements Developement (RD) oder Anforderungsentwicklung, wie es die deutsche Übersetzung des CMMI-Buches nennt.

In der chronologischen Kette der Engineering-Aktivitäten steht die Anforderungsentwicklung zunächst ganz vorne. Allerdings verstehen sich die Engineering-Prozessgebiete des CMMI  in der Regel als eine iterative Abfolge, die während des Projektes immer wieder durchlaufen wird, wobei sich der Schwerpunkt verlagert. Zu Beginn des Projektes liegt dieser gewiss auf der Anforderungsentwicklung, welche selbst wieder iterativen oder gar rekursiven Charakter hat, da die einzelnen Aktivitäten für immer detailliertere Anforderungsebenen durchlaufen werden.

Worum geht es nun in RD? Es geht um die Entwicklung und Analyse von Kundenanforderungen und Anforderungen an das Produkt und die Produktbestandteile. So lauten auch die Überschriften der drei Ziele des Prozessgebietes:

• Kundenanforderungen entwickeln
• Produktanforderungen entwickeln
• Anforderungen analysieren und validieren

Bereits der erste Punkt ist spannend. Wie oft erhalten wir von unserem Kunden nur ein unzureichend beschriebenes Lastenheft? CMMI verlangt, sich nicht darauf auszuruhen, sondern fordert explizit, die Kundenanforderungen zu entwickeln. Dabei sollen zunächst die Bedürfnisse und Erwartungen, Einschränkungen und Schnittstellen der Kunden und Endanwender herausgefunden werden. Dazu muss man sich also wirklich mit seinem Kunden zusammensetzen und proaktiv versuchen zu verstehen, was der Kunde will. Da er das oft selbst nicht weiß, ist es Aufgabe des Auftragnehmers, dies durch Anwendung verschiedenster Techniken heraus zu finden.

Die identifizierten Kundenanforderungen schreibe ich dann auf, zunächst in der Kundensprache. Daraus entwickelt man dann die Produktanforderungen und Anforderungen an einzelne Produktbestandteile, also etwa Subsyteme, Komponenten oder Module. Diese werden dann nicht mehr mit der kundeneigenen Terminologie beschrieben, sondern mit technischen Begriffen, so dass sich später daraus ein Design ableiten lässt. Anforderungen an funktionale Schnittstellen werden in einer eigenen Practice erwähnt; CMMI legt besonderen Wert auf die Behandlung von Schnittstellen.

Für die Analyse der Anforderungen verlangt das Modell verschiedene Konzepte. Anwendungsszenarien verdeutlichen den Einsatz und die Funktionalität des gewünschten Produktes, indem bestimmte Abläufe beschrieben werden. Ein Betriebskonzept sollte erstellt werden, um sich ein Bild zu machen von dem Produkt und dessen Umgebung. Beide Konzepte versuchen zu verdeutlichen, was die textuellen Anforderungen erfassen wollen.

Die geforderte Funktionalität sollte mit einer Funktionalen Architektur beschrieben werden. Dabei versucht man, sich allein auf die Features des Systems zu fokusieren (was kann das System?). Design-Entscheidungen jeglicher Art (bspw. was wird in Hardware, was in Software realisiert) sind noch außen vor. Meist werden Diagramme und Anwendungsfälle verwendet, um die Funktionalität zu beschreiben.

Zur Analyse der Anforderungen gehört dann meist ein Peer Review an einer Checkliste, aber auch die Abschätzung von Risiken, bspw. in Form von Machbarkeitsanalysen. Bei der Anforderungs-Validierung versucht man schließlich, dem Kunden in Form von Produktpräsentationen (etwa Simulationen oder Prototypen) zu zeigen, wie man die Anforderungen verstanden hat. Dies sollte in einer frühen Projektphase stattfinden, um das Risiko zu minimieren, dass das resultierende Produkt nicht den Erwartungen entspricht.

Nicht gerade ohne, was das Modell hier fordert. Das proaktive Herausfinden der Anforderungen ist bestimmt auch eine Richtungsänderung in der Denkweise. Die Entwicklung der benannten Konzepte zur Analyse der Funktionalität erfordert evtl. auch Training und Übung im Umgang entsprechender Techniken wie UML oder SysML. Insgesamt versucht das Prozessgebiet aber abzusichern, was in vielen Projekten vernachlässigt wird, aber doch so entscheidend ist für den Projekterfolg: eine solider, validierter und abgestimmter Satz von Anforderungen, den Kunde und Auftragnehmer verstanden und gedanklich hinreichend durchdrungen haben.

Interessant wäre mal zu beleuchten, wie die einzelnen Practices in verschiedenen Firmen umgesetzt werden. Wie läuft bei Ihnen Anforderungsentwicklung?