In der ersten spezifischen Praktik heißt es:

Zusammen mit den Anforderungsgebern ein gemeinsames Verständnis der Bedeutung von Anforderungen entwickeln. (Spezifische Praktik “Anforderungen verstehen” SP 1.1)

Begriffe wie “zusammen” und “gemeinsam” lassen mich an Teamwork denken. Bei Dir vielleicht auch? Dann lass uns mal gemeinsam daran arbeiten, was das zu bedeuten hat. In Bezug auf die QuoMod Software kann ich schon mal sagen: Der Kern ist als Mehrplatz System ausgelegt. Und natürlich können auch verschiedene Anwender parallel die einzelnen Einträge in der Datenbank bearbeiten; im REQM Kontext somit “verwalten”.

Das Tun Wort in der Kurzbeschreibung, das “Entwickeln”, hat hier schon einen Kontext mit der Zeit. Es darf dauern. Muss ggf. auch reifen. Im Kopf. In den Gliedern. Allen Enden des Körpers. Es darf gespürt werden. In die Tiefe gegangen werden. Genau geschaut, dann Schritt für Schritt erforscht und ein Konsens gefunden werden.

Aus der Überschrift entnehmen wir: Es existieren mehrere Geber von Anforderungen. In kleinen Projekten sicherlich mindestens einen. Das klingt doch auch nach einem Objekt mit einzeiligem Textfeld. Und der Möglichkeit der Zuweisung seitens einer Anforderung.

Bei dem Textfragment “Verständnis der Bedeutung” sträuben sich bei mir noch etwas die Haare. Das ist mir doch nun wirklich zu unspezifisch! Und darf sich “entwickeln”. Gut dass wir schon erkannt haben, dass es auch dauern darf. Und hoffen wir mal, dass in den Subpraktiken dieser Aspekt etwas ausgebaut wird. Und wir dann an mögliche Realisierungen herangeführt werden.

Lass uns starten!

Kriterien für die Unterscheidung zugelassener Geber von Anforderungen aufstellen (Subpraktik SP 1.1.1 zu “Anforderungen verstehen”)

Das fängt ja schon gut an: Bei dem Verb “aufstellen” denke ich immer daran eine Checkliste aufzubauen. Gerne kann das als Microsoft Excel Dokument mit in die Software aufgenommen werden. In der ersten Version wird das nicht unbedingt notwendig sein. Also schnell weiter zur nächsten Subpraktik.

Dein Veto steht Dir ins Gesicht geschrieben. Du schaust mich grimmig an, gibst mir zu verstehen: „Lieber Stefan, so nicht!“. Du bist definitiv anderer Meinung. Auch weil das Arbeitsergebnis “Liste der Kriterien für die Unterscheidung zugelassener Anforderungsgeber” als erstes Beispiel in der CMMI Vorlage genannt wird.

Oh je, das würde aber nun bedeuten, dass wir nun schon am Anfang sehr tief in die Materie einsteigen müssen.

Ich probiere Dich zu überzeugen, dass es aktuell nicht notwendig ist, bis ins kleinste Detail bei den Anforderungen zu gehen. Und vor allem auch, dass eine direkte Verbindung zum großen Prozessgebiet “Projektplanung” besteht. Dieses CMMI Prozessgebiet wird uns noch häufig über den Weg laufen. Und uns immer wieder zuflüstern: “Hallo, denke auch an mich.” Daher finde ich es gut, dass Du Dich dafür einsetzt, es nicht zu vergessen. Und wir werden es auch auch nicht vergessen. Okay?

Anforderungen verstehen: Subpraktik 2

Du schaust noch etwas grimmig. Deine Stimmung scheint sich aber so langsam wieder zu erhellen. Wir holen uns gemeinsam einen Kaffee aus der Küche und betrachten die zweite Subpraktik.

Objektive Kriterien für die Bewertung und Annahme von Anforderungen aufstellen (Subpraktik SP 1.1.2 zu “Anforderungen verstehen”)

Das Verb “aufstellen” hatten wir ja gerade als Thema. Diesmal finde ich es spannend und wichtig genauer hinzuschauen. Ich werde fündig: Und die offiziellen Beispiele aus dem CMMI 1.3 Buch finde ich persönlich etwas schwierig. Nach kurzer Absprache mit Dir einigen wir uns darauf, dass fürs Erste auch die allseits bekannten SMART Kriterien aus dem Projektmanagement genügen. Ich setze die einzelnen Kriterien

• Spezifisch
• Messbar
• Akzeptiert
• Realistisch
• Terminiert

als einzeilige Textfelder unter das mehrzeilige Textfeld der Anforderung. So ist es möglich hier Anmerkungen zu hinterlegen, die dann später bearbeitet werden können. Zur Abgrenzung eine einzeilige “SMART Kriterien” Überschrift. Fertig!

Und Konfuzius spricht:

Nenne keinen weise, ehe er nicht bewiesen hat, dass er eine Sache von wenigstens acht Seiten her beurteilen kann. (Konfuzius)

Nun haben wir definitiv ein Problem. Mit den smarten Kriterien haben wir erst 5 Seiten einer möglichen Anforderung beurteilt. Und das würde unseren gemeinsamen Freund Konfuzius nicht genügen. Was machen wir nun?

Nach einer kurzen Denkpause sind wir überein gekommen: Da kommen ganz sicherlich noch weitere Kriterien dazu. Wir sind ja erst bei der ersten spezifischen Praktik zu “Anforderungen verwalten” angelangt. Und da kommt ganz sicherlich noch mehr!

Wir haben aber auch einen Plan B entwickelt. Wenn es bei den 5 Kriterien bleibt, dann schauen wir uns doch nochmals die Beispiele für die Bewertung und Abnahme von Kriterien aus der CMMI Vorlage genauer an. Eigentlich wollen wir das nicht, aber… hier schon mal vorab die ggf. noch zu betrachtenden Kriterien:

• eindeutig und richtig formuliert
• vollständig
• konsistent zueinander
• eindeutig identifiziert
• konsistent zwischen dem Ansatz der Architektur und den Prioritäten der Qualitätsattribute
• zur Umsetzung geeignet
• verifizierbar (d.h. prüfbar)
• nachverfolgbar
• erreichbar
• an Geschäftswerte geknüpft
• als Kundenpriorität identifiziert

Wir entscheiden uns dann doch die “smarten” Kriterien direkt neben dem Textfeld zur Anforderung zu setzen. Schon in eine mögliche Zukunft gedacht, sollte eine andere Überschrift “Kriterien für Bewertung und Annahme” darüber gesetzt sein.

Wir schauen uns an. Und sind uns einig: Das sieht schon etwas merkwürdig aus. So direkt neben dem großen Textfeld die Kriterien zu setzen. Und das Eingabefeld für den Text der Anforderung wirkt nun auch so klein. Das ist schon sehr herausfordernd für den Anwender der neuen Software. Aber schauen wir doch erst einmal weiter, was uns die nächste Subpraktik bringt:

Anforderungen verstehen: Subpraktik 3

Anforderungen analysieren, um sicherzustellen , dass die etablierten Kriterien erfüllt werden (Subpraktik SP 1.1.3 zu “Anforderungen verstehen”)

Gleicht fällt uns auf: Das Hilfsverb “werden” ist hier genauer zu betrachten. Denn das Verb “erfüllen” bedeutet ggf. etwas mehr Arbeit für die von den Anforderungen betroffenen Individuen. Wir entscheiden uns für eine Option mit der Bezeichnung “Kriterien erfüllt”. Damit es sich etwas abgrenzt von den anderen Eingabe Möglichkeiten, erstelle ich noch die Überschrift “Analyse” und setze es nach rechts in die zweite Spalte der Eingabe.

Wenn wir nun auch diese Option neben das große Eingabefeld der Anforderung setzen; das wird langsam zu viel des Guten. Die Analyse scheint ein eigener wichtiger Schritt zu sein und so sehen wir hier vielleicht doch eher einen eigenen Reiter, der die Kriterien plus der neuen Option “Kriterien erfüllt” enthält. Wir nennen den neuen Reiter analog zur vorherigen Überschrift “Kriterien für Bewertung und Annahme”.

Zufrieden schauen wir auf unser aktuelles Ergebnis. Klopfen uns gegenseitig auf die Schulter. Nicken uns zu. Das haben wir gut gemacht. Das aktuelle Ergebnis kann sich schon jetzt sehen lassen. Die nächste Subpraktik darf betrachtet werden:

Mit dem Geber von Anforderungen ein Verständnis der Anforderungen erarbeiten, damit die Projekt Teilnehmer zusagen können (Subpraktik SP 1.1.4 zu “Anforderungen verstehen”)

Das Verb “erarbeiten” hat es in sich. Hier ist eindeutig die Zeit im Spiel. Das kann dauern. Und ist auch sicherlich abhängig von den Projekt Teilnehmern. Oh, welch Wunder: ein neues Objekt!

Das Verb “zusagen” plus Hilfsverb “können” scheint mir wieder eine Option zu sein, vielleicht ein weiterer Status der Anforderung. Wir einigen uns auf die Option “Vorstufe Zusage erreicht” mit Überschrift “Projekt Teilnehmer”. In Ordnung? Du nickst.

In der vierten Subpraktik erkennen wir wieder die Verbindung zum CMMI Prozessgebiet “Projektplanung”. Es gibt Projekt Teilnehmer, deren Zusagen eingeholt werden sollen. Je nach Komplexität des entsprechenden Projekts genügt sicherlich nicht “nur” die Angabe Projekt Teilnehmer. Lange diskutieren wir, ob wir wirklich diese unspezifische Rolle aufnehmen sollen. Und doch machen wir es, schließlich haben wir ja auch die Geber der Anforderung schon mit aufgenommen.

Aus der Subpraktik entnehmen wir: Es existieren mehrere Projekt Teilnehmer von Anforderungen. In kleinen Projekten sicherlich mindestens einen. Das klingt doch auch nach einem Objekt mit einzeiligem Textfeld. Und der Möglichkeit der Zuweisung seitens einer Anforderung.

Klatschend sitzen wir beide vor dem Monitor. Freuen uns, dass mit solch wenigen Schritten schon die Version 2 der Software zum CMMI Prozessgebiet “Anforderungsmanagement REQM” entstanden ist. Bis vor kurzem hätten wir beide nie gedacht, dass sich mit den CMMI Beschreibungen und den QuoMod Grund Software Komponenten so einfach Software entwickeln lässt.

Wir freuen uns auch schon auf Version 3 der neuen Software. Dann geht es um die spezifische Praktik “Zusagen zu Anforderungen einholen”. Doch davor wird gebührend gefeiert. Definitiv!