Misuse Cases and Negative Scenarios

Misuse cases show negative or harmful possibilities, such as someone abusing the work or attempting to defraud it. Examples include users deliberately entering incorrect data, customers using stolen credit cards, and pranksters making fictitious calls or transactions, planting a virus or time bomb, or engaging in any of the myriad other things that can be done to harm the work.

"Maybe 'abuse cases' will always sound jokey, but the idea of the Negative Scenario (e.g., Burglar impersonates householder, Alarm Call Center Operator colludes with Burglar, etc.) is important."

source:Ian Alexander

It may be helpful here to think in terms drawn from fiction writingthe protagonist and the antagonist. The protagonist is the hero or main character of the story: the good guy. Think of the protagonist as the normal actor using the product following your normal use case scenario. Winnie the Pooh is the ideal protagonisthe is well intentioned and you want him to win out in the end. But like Pooh, the protagonist might be a klutz and make an unintentional mistake, forget his password, choose the wrong option, get honey on the keys, or any of the many things klutzes can do.

Cast your protagonist as someone who is forgetful, slow, distracted, and not paying attention. (You are bound to know someone like that.) Go through the normal case scenario, and for each step, ask what can be done wrongly. It may be simpler to write a new scenario for each misuse, as the ramifications of a misstep may be complex enough to warrant its own separate story.

So much for the protagonist. The antagonist is the person who opposes the work, seeks to harm it, or wants to defraud it: the bad guy. You have to examine all the steps for the normal case and ask if there is a possibility of someone opposing or misusing that action. In this case, the ramifications upon discovering an antagonist's misuse may be to simply stop the business use case. For example:

3. Check the passport is valid and belongs to the passenger.

M3.1 The passenger produces a passport that is not his.

M3.2 Call security.

M3.3 Freeze the reservation.

Examine all the steps for the normal case and ask if there is a possibility of someone opposing or misusing that action.

Whether you annotate the normal case with the misuse steps or write a separate misuse scenario depends on the complexity of the situation and the comfort level of the stakeholders.

Some professions have always made use of what if? scenarios. For instance, chess players routinely think, "What would Black do if I moved my knight to e4?", leading to the minimize-maximize algorithms for game-play. Our governments routinely generate what if? scenarios to plan foreign policy: "What if Lichtenstein invades San Remo?" "What if Switzerland elects a communist government?" "What if Canada closes the St. Lawrence Seaway?" While these examples are obviously fanciful, most governments generate thousands of likely and unlikely scenarios to explore their reactions to possible future events.

"I don't always try to identify the predator flows. I use the same flows as other actors but ask the question, What if a hacker got here? What other precautions need to be implemented? What is the risk to the corporation if they get here? Can the corporation live with the risk of occurrence? How much are you willing to pay to avoid the risk?"

source: Patricia Ferdinandi, A Requirements Pattern

When gathering requirements, try generating several what if? scenarios to experiment with the unforeseen. The intention is to turn the unforeseen into the foreseen. After all, the more you know about eventualities before you build the product, the more robust and long-lasting it will be.