The destructive path to requirements
You can analyse stakeholders and ask for goals, motives and attitudes. You can define the system context and thus determine the framework of a development. You can perform an apprenticing. Or use creativity techniques such as brainstorming or brainwriting. And organise interviews. And evaluate old specifications or change logs. There are many “classic” ways to identify requirements. And there is an alternative, destructive way: working with so-called misuse cases.
What is a misuse case?
Presumably you know use cases, right? A use case is an interaction of a user with a system. A popular example is a bank customer who withdraws money from his account at an ATM. A misuse case is an “abusive use case” that outlines an interaction that a system or product should not allow or prevent. It supplements the idea of use cases with an additional, “destructive” point of view. To give you an example: the ATM prevents me as an unauthorized person from withdrawing money from your account.
Misuse cases were first described in 2001 by the two Norwegian professors Guttorm Sindre and Andreas Lothe Opdahl. They published “Capturing Security Requirements through Misuse Cases” and explained how an interaction sequence leads to a loss for the actor or organisation providing the product or system. In response, they identified security requirements.
Today, we encounter hundreds of indications every day that warn against the misuse of products or systems: with your wristwatch, you can dive only 30 meters deep; with medications, there is a package insert with dosage instructions and warnings; and in each elevator, the maximum number of people allowed to use the elevator at the same time is stated.
Reasons and examples for misuse cases
There are a number of reasons that can lead to abusive use cases:
- Ignorance. The user does not know exactly what to do or how to do it.
- Intention. The user wants to use a product, but not in the way the vendor wants.
- Coincidence. The user uses a product in a way that is unexpected to the vendor, in an unexpected place, or at an unexpected time.
- Vandalism. The vandal aims to destroy a product.
- Criminal motives. A crook pursues the goal of stealing a product or manipulating a system in his sense.
For each of these reasons there are numerous examples. The more you pay attention to it in everyday life, in your company or during news broadcasts, the more frequently you will encounter misuse cases. Here is a small selection:
Imagine you offer downloads on your website. The prospective customer “pays” with his e-mail address to which you send the download or the download link.1 Since the user has had bad experiences in the past with downloads and the subsequent flood of advertising mails, he uses a fictitious name instead of his actual name. For example, we at t2informatik have been able to send download links to Robert Redford, Bart Simpson, Max Muster or Mike Ross – a character from the US series “Suits” – in recent weeks. Some users use so-called disposable e-mail addresses, which can only be reached for 5 or 10 minutes. In short: The interested party would like to receive information, but not under the given conditions. He has another intention. It becomes “funny” sometimes, if first a fictitious e-mail address (without chance of successful delivery of the download) and afterwards a real e-mail address is used. 😉
Has your mobile phone ever fallen into the water? Or even in the toilet? Or did you accidentally pour a coffee over it? Life is full of coincidences and ideally products “endure such coincidences”. Of course, nobody wants to talk on the phone under water – but who knows what the future holds! – nevertheless the use under water could make sense, e.g. for divers or snorkelers who want to take photos or videos. A misuse case becomes a useful feature for a group of users.
There is a well-known video in which a “customer” tests a smartphone for robustness. He throws it on the floor with the intention of destroying the display. It doesn’t work the first time, but it does work the second time. The display splinters. Angry at this “lack”, he tramples on the device, kicks it around and successively dismantles it into its individual parts. The “proof” is given: The device is useless. It is not robust enough. Of course, on the one hand little can be done against vandalism, on the other hand a mobile phone that survives a fall from a “normal” height of use undamaged would be great, wouldn’t it?
Do you already use “contactless payment” with your ATM or credit card? Contactless payment refers to a function in which payments are processed using Near Field Communication. Sounds good, is simple, quick and is a welcome option for thieves to read the data on your card. The situation is similar with keyless central locking in cars: thieves “steal” the signal and then “borrow” the car for a spin. Both misuse cases are not nice at all!
Surely you can think of other misuse cases as well. Voting computers are manipulated, data is sold to the highest bidder, addresses are published without permission, QR codes lead to websites with dubious content, etc. The list can be easily completed.
From misuse case to requirement
When working with use cases, various scenarios are outlined, i.e. interaction sequences in which the user acts with the product or system. The scenarios later result in requirements that enable a desired interaction. Example ATM:
The ATM greets the user with a message on the display and prompts him to insert his debit or credit card into the device. Stop. Most ATMs no longer greet their customers but display advertising. And they show the list of cards that can be used to withdraw money from the machine. So there is a message at the beginning, which is essential for the operation. By inserting an accepted card, the interaction sequence is started and, depending on the ATM and bank, the further procedure varies: checking the account balance, withdrawing money, etc.
Let’s fast-forward to the misuse case: What happens if you enter a wrong PIN three times, i.e. if you misuse the system in some way? Your card will be withdrawn and you will be asked to contact a bank employee. The withdrawal of the card after three incorrect operations is a security mechanism. It is a feature that follows a misuse case. Whether the misuse is due to incorrect operation or a criminal motive, the ATM does not have to answer, this is the employee’s job.
The example leads to the question: How can misuse cases be identified? And the answer is: with classic requirements management and some consciously asked questions. Here in the blog you will find a description of what the best process in requirements management can look like. The questions address the reasons and behaviors that can lead to misuse cases:
What could a “crook” do to steal the product or use it against his intention?
A blackmailer could install ransomware on a computer and extort a ransom.2
A hacker could gain access to an account and act under a false name.
A competitor could repeatedly click on the competition advertisement in Google and use up the day’s budget.3
What could happen to stop a product or system from working?
A motorist could fill up on the “wrong” fuel.4
A bicycle could have a flat tire.5
The food could become unpalatable after a while.6
How could a user use a product when it is not intended to be used?
A hiker could use his shoe to open a bottle of crown cork.7
A consumer could use a mustard jar as a drinking glass in the future.8
A user could copy a computer program and make the copy available to a friend.9
What could the user do if he does not know how something works?
A computer user could repeatedly perform the same action in the hope that it is the right way.
An metro customer could electrically charge the coin, which is not accepted by the ticket vending machine, by friction on the vending machine.
A smartphone user could change the app in the hope that “it” will work better with the “other” one.
Conclusion
At first glance, the search for misuse cases may seem destructive, but basically it is constructive. It simply chooses another way to identify requirements. Of course, not all requirements derived from abusive uses can be realised in practice. Sometimes economic reasons speak against the implementation of corresponding requirements, sometimes technical reasons. With bulletproof glass a car window would be burglar-proof, but the additional costs and the additional weight should not delight most drivers.
Apropos delight: In a way, misuse cases or the realisation of possible requirements arising from abusive applications are an excellent means of setting oneself apart from the competition. The Kano Model explains the relationship between product characteristics and the resulting customer satisfaction. According to Kano, competition essentially takes place with so-called performance features and excitement features. A performance feature is, for example, the consumption of a car; a car that consumes less fuel than another car – for example, because it is lighter and does not incorporate bulletproof glass – wins this comparison and thus contributes to higher customer satisfaction.
It gets exciting with the excitement features, because very few products have real delighters. Wiping on the smartphone a good 10 years ago was a feature that caused worldwide delight. And now imagine an unbreakable smartphone. A device that can withstand a fall from a height of 2 meters onto any surface without damage. 100% robustness. The product would inspire me. The feature is made possible by the constructive determination of requirements, i.e. the use of misuse cases.
Notes:
[1] The GDPR defines a so-called coupling prohibition according to which, for example, the interest in a download may not automatically lead to an entry in a newsletter distribution list. Even though the OLG Frankfurt revoked this prohibition of tying in a ruling of 26 July 2019 (see in German https://www.e-recht24.de/artikel/datenschutz/11551-kopplungsverbot-dsgvo-newsletter-gewinnspiele.html), we continue to adhere to it.
[2] Here you can find information about ransomware.
[3] Google Adwords has integrated a mechanism that prevents a person (or computer) from repeatedly clicking on an ad link to deplete an advertiser’s budget. Without this mechanism, the use of Google Adwords by advertisers would probably make little sense.
[4] The fuel to be used is stated on fuel caps. This is very useful information, especially for rental cars.
[5] There are “unbreakable” hoses for bicycles.
[6] On packaged food, the best-before date and also the ingredients of the product are mentioned.
[7] There are hiking shoes (and also flip-flops) with a bottle opener integrated in the sole of the shoe.
[8] There are manufacturers of mustard products who recognised as early as the 1980s that they could sell mustard in jars which were then used as drinking glasses. The manufacturers thus offered their buyers an additional product feature.
[9] Of course, there have long been protective mechanisms that prevent programs from being copied. A very large and well-known manufacturer is said to have designed its protection mechanisms so “simple” that the programs could be copied easily. That would be an interesting strategy for distributing programs to as many computers as possible, wouldn’t it?
Michael Schenkel has published additional posts in the t2informatik Blog, including
Best practices for requirements workshops
Requirement analysis, but remote
The customer behind the IP address
Michael Schenkel
Head of Marketing, t2informatik GmbH
Michael Schenkel has a heart for marketing - so it is fitting that he is responsible for marketing at t2informatik. He likes to blog, likes a change of perspective and tries to offer useful information - e.g. here in the blog - at a time when there is a lot of talk about people's decreasing attention span. If you feel like it, arrange to meet him for a coffee and a piece of cake; he will certainly look forward to it!