Allgemeines zu SYS.2/SWE.1
Die Stakeholder-Anforderungen im letzten Beitrag haben wir im Product Backlog gesammelt. Jetzt geht es bei SYS.2 / SWE.1 um die konkret umzusetzenden Anforderungen. Nachdem diese beiden Prozesse in Automotive SPICE recht ähnlich sind, werde ich sie hier gemeinsam beschreiben. An dieser Stelle geht es für dich vermutlich mit einem in einem RM-Werkzeug weiter und nicht mehr in agilen Backlogs. Die Backlogs kannst / musst du trotzdem zur Planung der Arbeit verwenden und die Items entsprechend mit den Anforderungen in Deinem Werkzeug in Verbindung setzen.
Hierzu kannst du dir vorstellen, dass deine Backlog Items sowie die “getraceten” Anforderungen jeweils einen eigenen Lebenszyklus haben. Deine Aufgabe ist, für dich zu definieren, wie du diese Lebenszyklen synchronisieren kannst. Konkret: Welchen Zustand sollen die Requirements beim Sprint Planning haben? Der agile Weg wäre, diese erst im Sprint zu erstellen. Vielleicht erfordert Deine Umgebung aber, dass die Requirements schon vor dem Sprint eine bestimmte Reife haben. Im folgenden Bild habe ich beispielhaft die beiden Lebenszyklen notiert, sowie Möglichkeiten zur Synchronisation der Lebenszyklen.
BP1: Specify system / software requirements
Schreibe ganz klassisch deine SYS- / SWE-Anforderungen in deinem RM-Werkzeug auf, verwende dabei etabliertes Vorgehen, was Formulierungen und Inhalte angeht. Funktionale und nicht-funktionale Anforderungen musst du wie überall markieren oder in verschiedenen Kapiteln unterbringen. Hier gibt es also erst einmal keine unterschiede zum klassischen Vorgehen. OK, der Unterschied könnte sein, dass das nun in kleinen Schleifen von den Teams gemacht wird und nicht von einer entkoppelten Anforderungsabteilung.
BP2: Structure system /software requirements
In einem klassischen RM-Werkzeug erfolgt die Strukturierung über Kapitel und Unterkapitel, z.B. gegliedert nach verschiedenen Betriebsarten oder verschiedenen Funktionalitäten. Die Priorisierung hingegen kannst Du am besten über die Backlogs darstellen, mit denen du die Arbeit aussteuerst. Die Backlog Items sollten wie oben beschrieben mit den Anforderungen verlinkt sein. Eine Zuordnung von Backlog Items und Anforderungen zu Releases ist ein mögliches Mittel um die Priorisierung nicht sprintgenau darstellen zu müssen. Wenn du nur mit Backlog-Werkzeugen arbeitest, hast du zwar die Priorisierung aber keine gute Strukturierung, was im Assessment zu Problemen führen kann. In dem Fall kannst du z.B. mit deinem Wiki arbeiten, das im Idealfall auch Backlog Items als Link aufnehmen kann.
BP3: Analyze system / software requirements
Hier wieder ein klassischer Arbeitsschritt, der bei dir nun vom Scrum Team oder einzelnen Expert*innen vorgenommen wird. Die Anforderungen müssen bezüglich Machbarkeit, Testbarkeit, Abhängigkeiten analysiert werden und die Product Owner benötigen das Feedback für ihre Planung (Schätzungen, Machbarkeiten usw.). Die Ergebnisse der Analyse können gemäß den VDA-Guidelines in den entsprechenden Werkzeugen dokumentiert werden. Schön wäre, wenn hier ersichtlich ist, wann und von wem das dokumentiert wurde. Wenn du das in Kontext zu kleinen Protokollen z.B. aus den Backlog-Refinements oder Analyse-Workshops setzen kannst, ist das super, dann kann gut nachvollzogen werden, wie die Analyse zustande gekommen ist.
BP4: Analyze the impact on the system context / operating environment
Auch das ein klassischer Job, das wird in den Teams gemacht und die Dokumentation kann wie bei BP3 beschrieben erfolgen.
BP5: Ensure consistency and establish bidirectional traceability
Hier geht es um die Traceability zu von den Systemanforderungen zu den Stakeholder-Anforderunen bzw. von den Software-Anforderungen zu Systemanforderungen und Systemarchitektur. Hier hängt es nun von deinen agilen Artefakten ab, wie die Linkketten aussehen. In dem von mir beschriebenen Szenario bei SYS.2 gehen die bidirektionalen Links von den Systemanforderungen zu den Items im Product Backlog. Bei SWE.1 kommt es darauf an, ob du hier auch Backlogs zur Arbeitsverwaltung benutzt, dann musst du festlegen ob du durch die Backlog Items auf der SW-Ebene nach oben auf die System-Ebene linkst oder ob du direkt in die Systemarchitektur und in die Systemanforderungen verlinkst und die Backlog Items parallel dazu verlinkst, zur Priorisierung und Schätzung der Anforderungen.
BP6: Communicate agreed system / software requirements and impact on the system context / operating environment
Hier solltest du eine Liste haben, wer bzw. welche Rollen bei Änderungen informiert werden müssen und wie das passiert (Newsletter, Chat…) oder ob du ein Pull-System fahren willst, bei dem alle wichtigen Stellen immer im WIKI nachsehen können (was ich persönlich jedoch in der Praxis für kritisch halte). Ebenso musst du nachweisen können, wer in der Vergangenheit wann aus welchem Anlass mit welchen Informationen versorgt wurde.
Hinweise zu Level 2
Hier gilt dasselbe wie bei SYS.1: Bezüglich des Dokumentenmanagement musst du herausfinden, wie du das in deinem Werkzeug zum Backlog Management darstellen kannst. Kannst du mit dem Werkzeug einen Workflow abbilden? Konfigurationen und Baselines erstellen?
Die operative Arbeit wird hier bei den Teams liegen, damit ist die Planung und das Tracking über die agilen Backlogs abgedeckt. Da bei Backlog Items die komplette Umsetzung geschätzt wird, ist es schwierig, den Anteil der Anforderungsanalyse zu extrahieren. Hier hat sich in Assessments die Argumentation bewährt, dass a) die Anteile der jeweiligen Prozesse am Backlog Item bekannt sind und dass b) es mit diesem Ansatz noch nie Probleme durch Überlastung oder Verzögerung gab.