Blog-Serie – Teil 3 von 8
Willkommen zurück im Teil 3 der Blog-Serie „Analysetätigkeiten für belastbare Anforderungen“. In diesem Teil geht es um das Extrahieren von notwendigen Anforderungen aus der Menge der Stakeholder Wünsche.
Worum geht es bei dieser Analysetätigkeit?
Einigen von Ihnen wird diese Situation vielleicht bekannt vorkommen. Stellen Sie sich vor, Sie werden als Stakeholder damit beauftragt, Anforderungen an ein neues Produkt Ihres Unternehmens zu entwerfen. Natürlich soll das Produkt alle vergleichbaren Produkte auf dem Markt schlagen oder bekannte Probleme in der Industrie lösen.
Diesen BLOG-Artikel gibt es auch „Vorgelesen“ als Video:-)
Ein eigens entwickeltes automotive Betriebssystem, dass autonomes Fahren bei Zwei Jahren Entwicklungszeit ermöglicht? Ein vollausgestattetes und modernes Smartphone, dass eine Akkulaufzeit von Vier Wochen garantiert?
Oftmals spiegeln die Anforderungen von Stakeholdern lediglich Wünsche wider, die nicht alle erfüllbar sind und möglicherweise nicht allein durch das betrachtete System realisiert werden können.
Deshalb besteht einer der wichtigsten Schritte in der Anforderungsanalyse und das Ziel dieser Anforderungstätigkeit darin, aus den Ursprungsanforderungen diejenigen zu extrahieren, die tatsächlich Anforderungen an das System darstellen.
Ursprungsanforderung
Bei dieser Analysetätigkeit unterscheiden wir zwischen zwei Fällen.
1. Fall: Das System erfüllt nur einen Teil der Anforderung
Oft verlangen die ursprünglichen Anforderungen mehr, als das System leisten kann oder soll. Es gibt zwei Hauptgründe dafür:
- Der Stakeholder wünscht sich etwas, das das System aufgrund von Zeit- und Kosteneinschränkungen nicht leisten kann.
- Der Wunsch muss durch Zusammenarbeit mit anderen Nachbarsystemen erfüllt werden, was nicht immer berücksichtigt wurde.
Betrachten wir für diesen Fall die vorher separierte Anforderung E3:
Die Funktion Tür öffnen muss eine Ausführungszeit von maximal 2 Sekunden aufweisen.
Es ist davon auszugehen, dass eine Türöffnung innerhalb von 2 Sekunden sehr leistungsfähige Motoren voraussetzt, die für das Projektbudget vielleicht zu teuer sind.
2. Fall: Die Anforderung bezieht sich auf eine Komponente
Häufig stellt ein Stakeholder eine Anforderung, die nicht das ganze System, sondern nur eine Systemkomponente betrifft. Man nimmt an, dass diese Komponente existiert, vergisst aber, die Begründung als Systemanforderung zu formulieren. Ihre Aufgabe ist es, diese Systemanforderung zu erstellen, da jede Anforderung an eine Komponente durch eine Systemanforderung begründet sein sollte. So finden Sie möglicherweise weitere wertvolle Systemanforderungen.
Betrachten wir für Fall 2 nun die Ursprungsanforderung U3:
Der Türsensor muss den Status einer Tür (offen/geschlossen) melden.
Diese Anforderung richtet sich an die Komponente „Türsensor“ des Systems. Folglich muss daraus eine Anforderung an das Gesamtsystem abgeleitet werden.
Hilfestellungen zur Durchführung dieser Analysetätigkeit
Auch für diese Tätigkeit können Sie sich Fragen in Bezug auf die Anforderungen stellen.
Für Fall 1 lautet die Frage:
Welchen Teil der geforderten Funktionalität soll das System realisieren?
Und für Fall 2:
Wegen welcher Systemanforderung existiert die gegebene Komponentenanforderung?
Ergebnis nach Anwendung der Analysetätigkeit
Fall1:
Eine Alternative für leistungsfähige, aber teure Motoren wäre, dass das System nur die Entriegelung der Tür und nicht die Öffnung der Tür unterstützt. Daraus ergibt sich eine geänderte Anforderung (gekennzeichnet durch ein Anführungszeichen):
Die Funktion Tür entriegeln muss eine Ausführungszeit von maximal 2 Sekunden aufweisen. (E3‘)
Durch die Änderung ergeben sich notwendige Anpassungen für die anderen, bereits bestehenden Anforderungen, die nicht vergessen werden sollten.
Fall 2:
Wie bereits erwähnt, wurde mit der Ursprungsanforderung U3 eine Komponente adressiert. Daraus extrahierte Anforderungen an das Gesamtsystem könnten lauten:
Das SHS muss das Öffnen einer Tür erkennen. (E6)
Das SHS muss das Schließen einer Tür erkennen. (E7)
Als Konsequenz dieser Tätigkeit wurden somit ein neues Set an Ergebnisanforderungen erzeugt.
Fazit
Diese Analysetätigkeit wird nicht ohne Grund als eine der wichtigsten gesehen. Nur wirklich notwendige Anforderungen sollten in den nachfolgenden Entwicklungsschritten weiter bearbeitet werden, um die Entwicklungszeiten und -kosten oder Herstellungskosten eines Systems nicht zu strapazieren oder gar zu sprengen.
Freuen Sie sich auf den nächsten Teil dieser Blogserie, in dem wir die Analysetätigkeit „Anforderungen abstrahieren“ vorstellen werden. Bleiben Sie dran, es lohnt sich.
Beste Grüße,
Ihre SOPHISTen