Der destruktive Weg zu Anforderungen

von | 07.11.2019 | Prozesse & Methoden | 4 Kommentare

Sie können Stakeholder analysieren und nach Zielen, Motiven und Einstellungen fragen. Sie können den Systemkontext definieren und damit den Rahmen einer Entwicklung bestimmen. Sie können ein Apprenticing durchführen. Oder nutzen Sie Kreativitätstechniken wie Brainstorming oder Brainwriting. Und Interviews organisieren. Und alte Spezifikationen oder Chanlgelogs auswerten. Es gibt viele „klassische“ Möglichkeiten, Anforderungen zu ermitteln. Und es gibt einen alternativen, destruktiven Weg: die Arbeit mit so genannten Misuse Cases.

Wie, wo, was Misuse Case?

Vermutlich kennen Sie Use Cases, oder? Ein Use Case bzw. Anwendungsfall beschreibt eine Interaktion eines Benutzers mit einem System. Ein beliebtes Beispiel ist ein Bankkunde, der an einem Geldautomaten Geld von seinem Konto abhebt. Ein Misuse Case ist ein „missbräuchlicher Anwendungsfall“, der eine Interaktion skizziert, die ein System oder Produkt nicht zulassen oder verhindern soll. Sie ergänzt die Idee der Anwendungsfälle um eine zusätzliche, „destruktive“ Sichtweise. Um Ihnen ein Beispiel zu geben: Der Geldautomat verhindert, dass ich als Unbefugter Geld von Ihrem Konto abheben kann.

Misuse Cases wurden erstmals im Jahr 2001 von den beiden norwegischen Professoren Guttorm Sindre und Andreas Lothe Opdahl beschrieben. Sie veröffentlichten „Capturing Security Requirements through Misuse Cases“ und erläuterten, wie eine Interaktionssequenz zu einem Verlust für den Akteur oder die Organisation führt, die das Produkt oder System bereitstellt. Als Reaktion darauf identifizierten sie Sicherheitsanforderungen.

Heute begegnen uns täglich Hunderte von Hinweisen, die vor dem Missbrauch von Produkten oder Systemen warnen: Mit der Armbanduhr kann man nur 30 Meter tief tauchen; bei Medikamenten gibt es eine Packungsbeilage mit Dosierungsanweisungen und Warnhinweisen; und in jedem Aufzug ist die maximale Anzahl Personen angegeben, die den Aufzug gleichzeitig benutzen dürfen.

Gründe und Beispiele für Misuse Cases

Es gibt eine Reihe von Gründen, die zu Misuse Cases führen können:

  • Ignoranz. Der Benutzer weiß nicht genau, was er tun soll oder wie er es tun soll.
  • Absicht. Der Benutzer möchte ein Produkt verwenden, aber nicht auf die Art und Weise, wie der Hersteller es wünscht.
  • Zufall. Der Benutzer verwendet ein Produkt auf eine Weise, an einem unerwarteten Ort oder zu einer unerwarteten Zeit, die der Hersteller nicht erwartet.
  • Vandalismus. Der Vandale hat die Zerstörung eines Produkts zum Ziel.
  • Kriminelle Motive. Ein Gauner verfolgt das Ziel, ein Produkt zu stehlen oder ein System in seinem Sinne zu manipulieren.

Für jeden dieser Gründe gibt es zahlreiche Beispiele. Je mehr Sie im Alltag, in Ihrem Unternehmen oder bei Nachrichtensendungen darauf achten, desto häufiger werden Sie auf Misuse Cases stoßen. Hier ist eine kleine Auswahl:

Stellen Sie sich vor, Sie bieten auf Ihrer Website Downloads an. Der Interessent „bezahlt“ mit seiner E-Mail-Adresse, an die Sie den Download bzw. den Download-Link senden.1 Da der Nutzer in der Vergangenheit schlechte Erfahrungen mit Downloads und der darauf folgenden Flut von Werbemails gemacht hat, verwendet er statt seines tatsächlichen Namens einen fiktiven Namen. So konnten wir bei t2informatik in den letzten Wochen beispielsweise Download-Links an Robert Redford, Bart Simpson, Max Muster oder Mike Ross – eine Figur aus der US-Serie „Suits“ – versenden. Einige Benutzer verwenden sogenannte Wegwerf-E-Mail-Adressen, die nur für 5 oder 10 Minuten erreichbar sind. Kurzum: Der Interessent möchte Informationen erhalten, aber nicht unter den gegebenen Bedingungen. Er hat eine andere Absicht. Es wird manchmal „lustig“, wenn zuerst eine fiktive E-Mail-Adresse (ohne Chance auf erfolgreiche Zustellung des Downloads) und danach eine echte E-Mail-Adresse verwendet wird. 😉

Ist Ihr Mobiltelefon jemals ins Wasser gefallen? Oder sogar in die Toilette? Oder haben Sie versehentlich einen Kaffee darüber geschüttet? Das Leben ist voller Zufälle, und idealerweise halten Produkte „solche Zufälle aus“. Natürlich will niemand unter Wasser telefonieren – aber wer weiß, was die Zukunft bringt! – Dennoch könnte der Einsatz unter Wasser sinnvoll sein, z.B. für Taucher oder Schnorchler, die Fotos oder Videos aufnehmen wollen. Ein Misuse Case könnte so für eine Gruppe von Benutzern zu einer nützlichen Funktion werden.

Es gibt ein bekanntes Video, in dem ein „Kunde“ ein Smartphone auf seine Robustheit testet. Er wirft es auf den Boden mit der Absicht, das Display zu zerstören. Beim ersten Mal funktioniert es nicht, aber beim zweiten Mal. Das Display splittert. Wütend über diesen „Mangel“ trampelt er auf dem Gerät herum, tritt es mit Füßen und zerlegt es sukzessive in seine Einzelteile. Der „Beweis“ ist erbracht: Das Gerät ist nutzlos. Es ist nicht robust genug. Natürlich kann man einerseits wenig gegen Vandalismus tun, andererseits wäre ein Mobiltelefon, das einen Sturz aus „normaler“ Höhe unbeschadet übersteht, doch toll, oder?

Benutzen Sie bereits „kontaktlose Zahlung“ mit Ihrer EC-Karte oder Ihrer Kreditkarte? Kontaktloses Bezahlen nutzt eine Funktion, bei der Zahlungen mittels Near Field Communication abgewickelt werden. Klingt gut, ist einfach, schnell und ist eine willkommene Möglichkeit für Diebe, die Daten aus Ihrer Karte auszulesen. Ähnlich verhält es sich bei schlüssellosen Zentralverriegelungen in Autos: Diebe „stehlen“ das Signal und „leihen“ das Auto dann für eine Spritztour aus. Beide Misuse Cases sind überhaupt nicht schön!

Sicherlich fallen Ihnen auch andere Misuse Cases ein. Wahlcomputer werden manipuliert, Daten werden an den Meistbietenden verkauft, Adressen werden unerlaubt veröffentlicht, QR-Codes führen zu Websites mit zweifelhaftem Inhalt usw. Die Liste lässt sich leicht erweitern.

Vom Misuse Case zur Anforderung

Bei der Arbeit mit Anwendungsfällen werden verschiedene Szenarien skizziert, sprich Interaktionssequenzen, in denen der Benutzer mit dem Produkt oder System agiert. Aus den Szenarien ergeben sich später Anforderungen, die eine gewünschte Interaktion ermöglichen. Beispiel Geldautomat:

Der Geldautomat begrüßt den Benutzer mit einer Meldung auf dem Display und fordert ihn auf, seine Debit- oder Kreditkarte in das Gerät einzuführen. Halt! Die meisten Geldautomaten grüßen ihre Kunden nicht mehr, sondern zeigen Werbung an. Und sie zeigen die Liste der Karten, mit denen man am Automaten Geld abheben kann. Am Anfang steht also eine Botschaft, die für die Operation von wesentlicher Bedeutung ist. Durch Einstecken einer akzeptierten Karte wird die Interaktionssequenz gestartet und je nach Geldautomat und Bank variiert das weitere Vorgehen: Kontostand abfragen, Geld abheben usw.

Lassen Sie uns zum Fall des missbräuchlichen Gebrauchs vorspulen: Was passiert, wenn Sie dreimal eine falsche PIN eingeben, d.h. wenn Sie das System in irgendeiner Weise missbrauchen? Ihre Karte wird eingezogen und Sie werden gebeten, sich an einen Bankmitarbeiter zu wenden. Die Entnahme der Karte nach drei fehlerhaften Operationen ist ein Sicherheitsmechanismus. Es ist eine Funktion, die einem Missbrauchsfall folgt. Ob der Missbrauch auf eine falsche Bedienung oder ein kriminelles Motiv zurückzuführen ist, muss der Geldautomat nicht beantworten, dies ist Aufgabe des Mitarbeiters.

Das Beispiel führt zu der Frage: Wie können Misuse Cases identifiziert werden? Und die Antwort lautet: mit klassischem Anforderungsmanagement und einigen bewusst gestellten Fragen. Hier im Blog finden Sie eine Beschreibung, wie der beste Prozess im Anforderungsmanagement aussehen kann. Die nachfolgenden Fragen beziehen sich auf die Gründe und Verhaltensweisen, die zu Misuse Cases führen können:

Was könnte ein „Gauner“ tun, um ein Produkt zu stehlen oder es gegen seine Absicht zu verwenden?

Ein Erpresser könnte Lösegeld-Software auf einem Computer installieren und ein Lösegeld erpressen.2
Ein Hacker könnte sich Zugang zu einem Konto verschaffen und unter einem falschen Namen handeln.
Ein Mitbewerber könnte wiederholt auf die Konkurrenzanzeige in Google klicken und das Tagesbudget aufbrauchen.3

Was kann passieren, damit ein Produkt oder System nicht mehr funktioniert?

Ein Autofahrer könnte den „falschen“ Kraftstoff tanken.4
Ein Fahrrad könnte einen platten Reifen haben.5
Das Essen könnte nach einer Weile ungenießbar werden.6

Wie könnte ein Benutzer ein Produkt verwenden, obwohl es für einen anderen Einsatz bestimmt ist?

Ein Wanderer könnte mit seinem Schuh einen Kronkorken öffnen.7
Ein Verbraucher könnte in Zukunft ein Senfglas als Trinkglas verwenden.8
Ein Benutzer könnte ein Computerprogramm kopieren und die Kopie einem Freund zur Verfügung stellen.9

Was könnte der Benutzer tun, wenn er nicht weiss, wie etwas funktioniert?

Ein Computerbenutzer könnte die gleiche Aktion wiederholt ausführen, in der Hoffnung, dass es der richtige Weg ist.
Ein U-Bahn-Kunde könnte die Münze, die vom Fahrkartenautomaten nicht akzeptiert wird, durch Reibung am Automaten elektrisch aufladen.
Ein Smartphone-Benutzer könnte die App in der Hoffnung wechseln, dass „es“ besser mit der „anderen“ funktioniert.

Fazit

Auf den ersten Blick mag die Suche nach Misuse Cases destruktiv erscheinen, aber im Grunde ist sie konstruktiv. Sie wählt einfach einen anderen Weg, um Anforderungen zu ermitteln. Natürlich können nicht alle Anforderungen, die sich aus missbräuchlicher Nutzung ableiten, in der Praxis umgesetzt werden. Manchmal sprechen wirtschaftliche Gründe gegen die Umsetzung entsprechender Anforderungen, manchmal technische Gründe. Mit kugelsicherem Glas wäre ein Autofenster zwar einbruchsicher, aber die zusätzlichen Kosten und das zusätzliche Gewicht dürften die meisten Autofahrer nicht begeistern.

Apropos Freude: In gewisser Weise sind Misuse Case oder die Realisierung möglicher Anforderungen aus missbräuchlichen Verwendung ein hervorragendes Mittel, um sich von der Konkurrenz abzuheben. Das Kano-Modell erklärt die Beziehung zwischen Produkteigenschaften und der daraus resultierenden Kundenzufriedenheit. Nach Kano findet der Wettbewerb im Wesentlichen über so genannte Leistungs- und Begeisterungsmerkmale statt. Ein Leistungsmerkmal ist z.B. der Verbrauch eines Autos; ein Auto, das weniger Kraftstoff verbraucht als ein anderes Auto – z. B. weil es leichter ist und kein Panzerglas enthält – gewinnt diesen Vergleich und trägt damit zu einer höheren Kundenzufriedenheit bei.

Spannend wird es mit den Begeisterungsmerkmalen, denn nur sehr wenige Produkte haben solche Merkmale. Das Wischen auf dem Smartphone vor gut 10 Jahren war eine Funktion, die weltweit für Begeisterung sorgte. Und nun stellen Sie sich ein unzerbrechliches Smartphone vor. Ein Gerät, das einen Sturz aus 2 Metern Höhe auf eine beliebige Oberfläche ohne Schaden überstehen kann. 100%ige Robustheit. Das Produkt würde mich inspirieren. Ermöglicht wird dieses Feature vielleicht in Zukunft durch die konstruktive Bedarfsermittlung, d.h. die Verwendung von Misuse Cases.

 

Hinweise:

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

[1] Das DVSGO definiert ein sogenanntes Kopplungsverbot, nach dem z.B. das Interesse an einem Download nicht automatisch zu einem Eintrag in einen Newsletter-Verteiler führen darf. Auch wenn das OLG Frankfurt dieses Kopplungsverbot mit Beschluss vom 26. Juli 2019 aufgehoben hat (siehe https://www.e-recht24.de/artikel/datenschutz/11551-kopplungsverbot-dsgvo-newsletter-gewinnspiele.html), halten wir daran fest.
[2] Hier finden Sie Informationen über Ransomware.
[3] Google Adwords hat einen Mechanismus integriert, der verhindert, dass eine Person (oder ein Computer) wiederholt auf einen Anzeigenlink klickt, um das Budget eines Inserenten zu erschöpfen. Ohne diesen Mechanismus würde die Verwendung von Google Adwords durch Werbetreibende wahrscheinlich wenig Sinn ergeben.
[4] Der zu verwendende Treibstoff ist auf den Tankdeckeln angegeben. Dies sind sehr nützliche Informationen, insbesondere für Mietwagen.
[5] Es gibt „unkaputtbare“ Schläuche für Fahrräder.
[6] Auf verpackten Lebensmitteln werden das Mindesthaltbarkeitsdatum und auch die Inhaltsstoffe des Produkts genannt.
[7] Es gibt Wanderschuhe (und auch Flip-Flops) mit einem in die Schuhsohle integrierten Flaschenöffner.
[8] Es gibt Hersteller von Senfprodukten, die bereits in den 1980er Jahren erkannten, dass sie Senf in Gläsern verkaufen konnten, die dann als Trinkgläser verwendet wurden. Damit boten die Hersteller ihren Käufern ein zusätzliches Produktmerkmal an.
[9] Natürlich gibt es seit langem Schutzmechanismen, die verhindern, dass Programme kopiert werden. Ein sehr großer und bekannter Hersteller soll seine Schutzmechanismen so „einfach“ gestaltet haben, dass die Programme leicht kopiert werden konnten. Das wäre eine interessante Strategie, um Programme auf so viele Computer wie möglich zu verteilen, nicht wahr?

 

Michael Schenkel hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik Blog: Der beste Prozess im Anforderungsmanagement

Der beste Prozess im Anforderungsmanagement

t2informatik Blog: Anforderungen eliminieren

Anforderungen eliminieren

t2informatik Blog: Anforderungsanalyse, aber remote

Anforderungsanalyse, aber remote

Michael Schenkel
Michael Schenkel

Leiter Marketing, t2informatik GmbH

Michael Schenkel ist Diplom-Betriebswirt (BA) und macht Marketing mit Leidenschaft. Er hat eine Urkunde über hervorragende Wandereigenschaften, Odenwaldtour der Klassen 6a/6b, und seit 1984 das Seepferdchen. Gerne bloggt er über Requirements Engineering, Projektmanagement, Stakeholder und Marketing. Und er freut sich ganz sicher, wenn Sie sich mit ihm in der realen Welt auf eine Tasse Kaffee und ein Stück Kuchen treffen oder zu einem virtuellen Kennenlernen verabreden.