Mit Misuse Cases zu sicheren Systemen

von | 18.07.2019 | Requirements Engineering

“Das System muss 7 Tage 24 Stunden lang verfügbar sein.” Oder: “Das System muss immer eine Antwort nach maximal 5 Sekunden liefern.”  Solche Anforderungen beschreiben Qualitäts- bzw. Leistungsmerkmale, die ein System aus Sicht der Anwender erfüllen muss. Im ersten Beispiel ist es die Systemverfügbarkeit, im zweiten die Performance. Diese Art von Anforderungen, die sich auf ein Qualitäts- bzw. Leistungsmerkmal beziehen, die nicht durch funktionale Anforderungen abgedeckt werden, werden als Qualitätsanforderungen bezeichnet.

Neben der Verfügbarkeit und der Performance gibt es weitere Qualitäts- bzw. Leistungsmerkmale wie die Zuverlässigkeit, Skalierbarkeit, Portabilität, Datenmengen, Durchsatzraten und Ressourcenverbrauch des zu entwickelnden Systems. Gelegentlich wird auch die Gebrauchstauglichkeit, also die Usability, zu den Qualitätsmerkmalen gerechnet. Und auch die Sicherheit gehört dazu – also alle Teile eines Systems, die dessen Missbrauch verhindern sollen.

Doch Qualitätsanforderungen aus dem Bereich Safety & Security zu finden, ist schwierig – aber nicht unmöglich. Wir zeigen Ihnen, wie es geht.

Schwierigkeiten bei nicht-funktionalen Anforderungen

„Das System muss spätestens im Herbst dieses Jahres verfügbar sein, um es auf den wichtigen Branchen-Events im Oktober und November präsentieren zu können.“ oder: „Das System wird zunächst nur mobile Geräte unter iOS unterstützen.“? Anforderungen dieser Art beziehen sich wie das erste Beispiel auf den Entwicklungsprozess bzw. schränken, wie das zweite Beispiel, den Lösungsraum ein. Sie betreffen aber weder funktionale Anforderungen noch Qualitätsanforderungen. Sie werden als Randbedingungen oder Constraints bezeichnet. Qualitätsanforderungen und Constraints gehören zu der Kategorie der nicht-funktionalen Anforderungen [1].

Da nicht-funktionale Anforderungen oft keinen direkt sichtbaren Wert für den Anwender schaffen, tun sich agile Teams gelegentlich schwer damit. Manche versuchen, nicht-funktionale Anforderungen als technische Aufgaben (Tasks) zu interpretieren, die erledigt werden müssen, um die technische Infrastruktur zu schaffen, damit eine Story abgenommen werden kann. Sie machen aus nicht-funktionalen Anforderungen also Akzeptanzkriterien von User Stories. Dem steht allerdings entgegen, dass es technische Aufgaben gibt, die in keiner direkten Beziehung mit einer speziellen User Story stehen. Was soll damit geschehen? Andere Teams versuchen technische Notwendigkeiten in Business Wert zu “übersetzen”, um eine einheitliche Basis für die Priorisierung der User Stories zu gewinnen – ein schwieriges Unterfangen. Wieder andere diskutieren heftig, ob es spezielle Technical Stories geben sollte, und wenn ja, ob sie zusammen mit den User Stories ins Backlog gehören.

Häufige Ursache dieser Irrungen und Wirrungen ist das eingesetzte Rollenmodell. Die Verantwortung für die Priorisierung der Anforderungen liegt danach in den Händen des fachlich ausgerichteten Product Owners (PO). Fehlt ihm das notwendige technische Know-how, sollte er einen technischen PO an seiner Seite haben, der die nicht-funktionalen Anforderungen bewerten kann, die zwar keinen direkten funktionalen Wert für den Anwender schaffen, aber ohne die die funktionalen Anforderungen nicht zufriedenstellend realisiert werden können – und dann erst recht keinen optimalen Wert liefern. Je komplexer die Infrastruktur und die Architektur des zu entwickelnden Systems bzw. Produkts sind, umso wichtiger ist diese Rolle.

Nicht-funktionale Anforderungen ermitteln

Constraints und Leistungsmerkmale eines Systems bzw. Produkts können zusammen mit den funktionalen Anforderungen in Kommunikation mit den Stakeholdern erarbeitet werden. Oft leiten sich nicht-funktionale Anforderungen direkt aus funktionalen Anforderungen ab. Sie werden von den Stakeholdern relativ leicht verstanden. Nehmen wir zum Beispiel eine Anfrage an ein System. Wie lange ist ein Anwender bereit, auf die Antwort zu warten? Muss der Datenzugriff in einer Millisekunde erfolgen und die Antwort sofort da sein? Oder sind für die Antwort im speziellen Bearbeitungsablauf auch 2, 3 oder maximal 4 Sekunden akzeptabel?

Schwieriger wird es bei Qualitätsanforderungen, die sich auf spezifische Qualitäts­merkmale des Systems bzw. Produkts beziehen. Die Bedeutung der Qualitätsmerk­male ist für die befragten Stakeholder oft nur schwer zu verstehen. Welchem Stakeholder sagen die Qualitätsmerkmale Interoperabilität oder Ange­messenheit schon etwas? Auf die Ermittlung von Qualitätsanforderungen sollten Sie deswegen jedoch nicht verzichten, sondern sich im Team besonders darauf vorbereiten.

Zunächst brauchen Sie ein gemeinsames Verständnis davon, welche Qualitätsmerk­male für das zu entwickelnde System überhaupt relevant sind. Bei fast allen Systemen ist das Zeitverhalten wichtig, genauso wie die Sicherheit. Aber sind Qualitätsattribute wie Interoperabilität und Ange­messenheit oder auch Modifizierbarkeit und Austauschbarkeit im selben Maße von Bedeutung?

Qualitätsanforderungen mit Misuse Cases ermitteln

Wenn Sie einen Stakeholder fragen “Wie sicher soll das System sein?” werden Sie nur selten eine andere Antwort als “Total sicher!” erhalten. Es empfiehlt sich also Fragen nach Qualitätsmerkmalen wie der Sicherheit eines Systems in beispielhafte Geschichten “aus dem Leben” zu verpacken. So können Sie leichter veranschaulichen, was passiert, wenn ein Qualitätsmerkmal gering ausgeprägt ist, und was es bedeutet, wenn es stark ausge­prägt wird. Was machen Sie aber, wenn Sie kein großer “Storyteller” sind? Dann haben wir hier noch einen anderen Tipp für Sie: Wenn es um Qualitätsanforderungen im Bereich Safety & Security geht, helfen Use Cases weiter – das heißt, nein: eigentlich sind es Misuse Cases, die Sie auf die Spur von Qualitäts­anforderungen bringen.

Ein Misuse Case ist ein missbräuchlicher Anwendungsfall. Er beschreibt eine Funktion, die ein System nicht zulassen und mit allen Mitteln verhindern sollte. Genau wie ein Use Case eine Interaktionsfolge mit dem System darstellt, die einen Wert für die Organisation schafft, ist auch ein Misuse Case eine ent­sprechende Interaktionsfolge – allerdings eine, die mit einem Verlust für die Organisation oder einen speziellen Stakeholder endet. Mit einem Misuse Case interagiert ein MisActor, d.h. ein Akteur, der Schaden verursacht [2].

Misuse Cases: ein Beispiel

Werfen wir einen Blick auf ein Beispiel mit einem Use Case und zwei Misuse Cases: Ein Autobesitzer möchte sein Fahrzeug ohne Schlüssel verriegeln. Ein Dieb hingegen möchte das Fahrzeug stehlen. Dies gelingt dem Dieb, sofern er das Schloss des Fahrzeugs aufbrechen oder das Funksignal des Keyless Go Systems des Fahrzeugs abfangen kann.

Modellierung eines Misues Cases

Der MisActor möchte das Fahrzeug stehlen

Wenn Sie regelmäßig mit Use Case Diagrammen arbeiten, erkennen Sie, dass die Enthält-Beziehung und Erweiterungsbeziehung, wie sie in der UML für Use Cases definiert sind, hier zweckentfremdet werden. Sie werden benutzt, um die Bedrohung durch einen Misuse Case und die Abwehr eines Misuse Case abzubilden. Natürlich können Sie Use Case Diagramme am Flipchart oder Whiteboard erstellen, als Softwarehersteller empfehlen wir Ihnen aber die Verwendung entsprechender Software. Dort erhalten die Beziehungen eine neue Semantik: Statt «include» und «extend» steht an den Pfeilen «attacks» und «prevents». Dabei handelt es sich um Sub-Stereotypen der Enthält- und Erweiterungsbeziehung, nicht um freien Text. Die Sub-Stereotypen ermöglichen es unter anderem, Auswertungen von Misuse Cases und ihren Beziehungen zu definieren und so Qualitätsanforderungen abzuleiten.

Fazit

Die Verwendung von Misuse Cases ergänzen die Idee der Use Cases um einen anderen Blickwinkel.  Misuse Cases werden zwar nicht implementiert und eine Beschreibung mit Hilfe von Flows ist auch nicht sinnvoll, aber der zusätzliche Blickwinkel auf ein System ermöglicht es, weitere Qualitätsanforderungen zu entdecken. Zwar gewichten Stakeholder Qualitätsmerkmale eines Systems oft sehr unterschiedlich. Für die einen ist zum Beispiel die Performance besonders wichtig, weil davon die Nutzerakzeptanz abhängt. Andere gewichten Sicherheitsmaßnahmen höher, selbst wenn sie die Performance beeinträchtigen. Misuse Cases bieten gerade für Safety & Security eine Herangehensweise, die leicht zu verstehen und anzuwenden ist, und zusätzlich wichtige Qualitätsanforderungen für die Entwicklung von Systemen liefern können. Und eine höhere Qualität gefällt bestimmt jedem Stakeholder.

 

Quellen:

[1] Dieser Begriffsbildung ist orientiert am Standard des International Requirements Engineering Board IREB zur Ausbildung zum Certified Professional for Requirements Engineering (CPRE)
[2] vgl. Sindre, G., & Opdahl, A. L. (2001). Capturing Security Requirements through Misuse Cases. Von Capturing Security Requirements through Misuse Cases sowie
Johnstone, M. N. (5th-7th. December 2011). Modelling misuse cases as a means of capturing. Von Modelling misuse cases as a means of capturing