(Posterbeitrag zur Fachgruppentagung Requirements Engineering der Gesellschaft für Informatik (GI) am 29. und 30.11.2012 in Nürnberg)
Abstract
Die Arten von Softwareanwendungen sind vielfältig. Allerdings lassen sich im Bereich von Optimierungssystemen die Anforderung nicht in allen Bereichen genauso erheben wie bei einer Büroapplikation. Dieser Beitrag sensibilisiert für die Unterschiede und beschreibt ein Vorgehen aus der Praxis mit einem Ansatz, der Wissensträger und Operations Research (OR) schon während der Anforderungsanalyse einträglich zusammenführt.
Einleitung
Softwareanwendungen gibt es in vielerlei Art. Neben solchen mit viel Benutzerinteraktion und wenig komplexer Logik (z.B. einem Onlineshop) gibt es ebenso das komplette Gegenteil. Zu letzterem gehören auch Optimierungssysteme (z.B. eine Tourenplanung in der Logistik). Optimierungssysteme sind Anwendungssysteme, die im Kern ein Entscheidungsproblem beinhalten, welches gelöst werden muss. Diese Art von Anwendungen ist eine besondere Herausforderung im Requirements Engineering (RE), insbesondere im Bereich der Use Case Spezifikationen und den daraus abzuleitenden Systemanforderungen. Dies soll hier am Beispiel eines Navigationsgerätes knapp verdeutlicht werden.
Das Problem
Eine der Use Case Spezifikationen des Navigationsgerätes beinhaltet beispielsweise die in Abbildung 1 gezeigte Ablaufbeschreibung in Form eines UML Aktivitätsdiagramms. Trotz trivialem Aussehen gestaltet sich die Ableitung von Anforderungen in diesem Fall schwierig. Problematisch ist vor allem die Aktivität „Route berechnen“. Bekanntermaßen führen viele Wege nach Rom. Die Anforderung ist diesbezüglich unklar: Ist die schnellste, die kürzeste, die ohne Stau oder die ohne Autobahn gemeint? Wo kommt die Basis für die Berechnung her? Welche Regeln gelten bei der Berechnung? Das Prozesswort „Route berechnen“ hat es offensichtlich in sich. Jedoch sind diese Details essentiell und ebenfalls in der Anforderungsphase zu ermitteln. Erforderliche Schritte wären die Definition des Prozesswortes und/oder der Versuch, die Aktivität als Subaktivität vollständig auszumodellieren. Jeder, der einmal versucht hat, in einem Beispiel wie diesem, die funktionale Perspektive der Anforderungen als Aktivitätsdiagramm vollständig zu modellieren, wird feststellen, dass es sehr schwer zu entscheiden ist, was modelliert werden muss und was nicht, um letztendlich nicht den Dijkstra Algorithmus selbst zu Papier zu bringen. Darüber hinaus gehende Regeln hat man dann jedoch immer noch nicht erfasst.
Genau dies ist das typische Problem während der Anforderungsanalyse bei Optimierungssystemen. Dem Requirements Engineer stellen sich an dieser Stelle vor allem zwei Fragen:
- Woran erkenne ich typische Optimierungssysteme, wo dieses Problem auftritt?
- Wie sieht eine geeignete Vorgehensweise aus, um die Anforderungen vollständig erheben zu können?
Beide Fragen sollen in den folgenden Abschnitten beantwortet werden.
Die Merkmale
Zunächst zu den Erkennungsmerkmalen: Optimierungsprobleme sprechen häufig in Superlativen in den Zielbeschreibungen, z.B. über „die kürzeste Strecke“, „die minimalen Kosten“, „der maximale Gewinn“ etc. Die Use Cases fallen hingegen sehr kurz und simpel aus (vgl. Abbildung 1). Der Anteil der Benutzereingaben im Verhältnis zur Gesamtmenge an Eingangsdaten (z.B. der Straßeninformationen) zur eigentlichen Problemlösung ist gering, sie sind quasi nur die Spitze des Eisbergs. Der Großteil wird implizit verwendet und meist durch einen vorgeschalteten Datensammelprozess herangeschafft. Die Logik per se arbeitet nach dem altbekannten EVA Prinzip [1] und verhält sich zustandslos, d.h. allein die Eingabedaten bestimmen das Verhalten, insbesondere sind aufeinander folgende Aufrufe der Logik voneinander unabhängig. Das vollständige Ergebnis wird dem Benutzer meist nicht als Antwort gezeigt, denn es kann durchaus mehrere Lösungen geben (Selektionsproblem). Der Algorithmus zur Lösung ist oft bereits bekannt und kann referenziert werden. Bei Erkennen solcher Eigenschaften empfiehlt es sich, neben der Anpassung der Herangehensweise, als neuen Stakeholder einen Operations Research (OR) Spezialisten hinzuzuziehen. Dieser wird spätestens bei dem im folgenden vorgestellten Ansatz zur Prüfung und Abstimmung der Anforderungen benötigt.
Der Ansatz
Aus der Perspektive eines OR Projekts muss im Kern geklärt werden, was der Entscheidungsträger will (Zielfunktion), welche Variablen bei der Entscheidung eine Rolle spielen und welche Nebenbedingungen gelten [2]. Leider kann man die anderen Stakeholder und Wissensträger selten direkt danach fragen. Es wird also nach einer Metaebene gesucht, die sowohl die entsprechenden Wissensträger als Auftraggeber und der OR Spezialist als Auftragnehmer verstehen und mit der ein solches Problem vollständig und konsistent ermittelt und beschrieben werden kann. Für eine erste Annäherung wird das bereits genannte EVA Prinzip herangezogen. Anstelle der Detaillierung der Use Case Spezifikation durch Aktivitätsdiagramme, werden die Anforderungen explizit in den Bereichen Eingabe, Verarbeitung und Ausgabe erfasst (vgl. Tabelle 1). Wir nutzen dabei intensiv die Konstruktion von Entwicklungsartefakten [3]: logische Schnittstellen und Testfälle. Der Bereich Eingabe beinhaltet alle Parameter und legt ihre Quellen fest. Die Verarbeitung wird durch Regeln beschrieben, die dem Anforderer oft selbstverständlich sind. Damit verhalten sie sich wie Basisfaktoren nach Kano et al. [4]. Die Ausgabe beschreibt dediziert das Ergebnis der Berechnung. Die Testfälle stellen mögliche Ausgaben in Folge der Anwendung der spezifizierten Regeln auf die Eingangsparameter dar.
Das allgemeine Vorgehen ist dabei iterativ. Insbesondere die Testfälle provozieren die bei Basisfaktoren schnell auftretende Unzufriedenheit bei Nichterfüllung, mit der Konsequenz, dass bei den Eingabeparametern und Regeln nachgebessert werden muss. Dieses Vorgehen wiederholt sich solange bis der Wissensträger die Vollständigkeit und Korrektheit bescheinigt und der OR-Spezialist aus den ermittelten Daten und Regeln Zielfunktion(en), Entscheidungsvariablen und Nebenbedingungen ableiten kann.
Diskussion
In diesem Beitrag geht es um die Sensibilisierung für den Fall des Requirements Engineerings im Bereich von Optimierungssystemen. Es geht um die Flexibilität, die Erhebung der Anforderungen an das zu entwickelnde System bzw. an den entsprechenden Use Case anzupassen. Der vorgestellte Ansatz basiert dabei auf den Erfahrungen im Bereich von Optimierungssystemen für die Bargeldlogistik. Thema ist nicht die Modellierung von Optimierungsmodellen, sondern die Erhebung von Anforderungen. Der Anforderer versteht selten die Sprache des Operations Research (OR), dennoch soll er als Reviewer in der Lage sein zu beurteilen, ob seine Anforderung richtig verstanden wurde. Auf der anderen Seite steht der OR Spezialist, der für seine Arbeit die richtigen Informationen benötigt. Von Vorteil ist, dass der verwendete Algorithmus zur Lösung oft bekannt ist (z.B. der Simplex) und damit gar nicht modelliert werden muss. Viel wichtiger sind Ziele, Regel und benötigte Daten. Vom eigentlichen „Wie“ ist man an dieser Stelle allerdings weit entfernt, denn diesem entsprechen die tatsächlich zu modellierende Zielfunktion im Sinne der mathematischen Programmierung sowie deren Lösung durch geeignete Solver.
Referenzen
- Brockhaus Computer und Informationstechnologie. Fachlexikon für Hardware, Software, Multimedia, Internet, Telekommunikation (2.
Aufl.). F. A. Brockhaus 2005 - Suhl, L.; Mellouli, T.: Optimierungssysteme – Modelle, Methoden, Software, Anwendungen. 2. Aufl. Berlin et al. : Springer 2009.
- Pohl, K.: Requirements Engineering: Grundlagen, Prinzipien, Techniken. (2.Aufl.). dpunkt 2008
- Kano, N., Tsuji, S., Seraku, N., Takahashi, F.: Attractive Quality and Must-be Quality. Quality – The Journal of the Japanese Society for Quality Control, Vol. 14, Nr.2, S.39-44, 1984
- UX Designer by Default - 13. März 2023
- Zur Lage des Requirements Engineering: Der RE-Kompass - 1. Februar 2023
- Die Fahrradschlosskalkulation: Eine Analogie zur Operationalisierung des Wertes des Requirements Engineering - 28. Januar 2023