misuse cases l.
Skip this Video
Loading SlideShow in 5 Seconds..
Misuse Cases PowerPoint Presentation
Download Presentation
Misuse Cases

Loading in 2 Seconds...

play fullscreen
1 / 21

Misuse Cases - PowerPoint PPT Presentation

  • Uploaded on

Misuse Cases. Use Cases with Hostile Intent Ian Alexander Independent Consultant http://www.scenarioplus.org.uk. What Happens if You Always Look on the Positive Side?. At least you relax and are happy But you aren't ready for problems when they come up

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Misuse Cases' - Audrey

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
misuse cases

Misuse Cases

Use Cases with Hostile Intent

Ian Alexander

Independent Consultant


what happens if you always look on the positive side
What Happens if You Always Look on the Positive Side?
  • At least you relax and are happy
  • But you aren't ready for problems when they come up
    • In business, there are people who want you to fail
    • On projects, there are many types of cockup
    • In systems, there are threats and hazards all round
    • In software, there's a bug in every module

"If anything can go wrong, it will"

(The REAL Captain Murphy, USAAF)

so it pays to think out negative scenarios
So, It Pays to Think Out 'Negative Scenarios'

#1 Either you think out what could happen

– and what you mean to do about it

#2 Or you wait until it happens

– and you find out whether it's too late to do anything about it.

Here are some techniques for approach #1.

understanding negative scenarios
Understanding Negative Scenarios
  • A Scenario* is a sequence of actions leading to a Goal desired by a person or organisation
  • A Negative Scenario is a scenario whose Goal is
    • desired Not to occur by the organisation in question
    • desired by a hostile agent (not necessarily human)

* This is a different usage from 'four possible future business scenarios'

negative scenarios are not new
Negative Scenarios are Not New

Montignac Caves, Dordogne, France

'Suppose it turns and charges us before it falls into the pit'

use cases
Use Cases
  • Ivar Jacobson, 1992
  • Large Telecom Systems (Ericsson switches)
  • Add a little bit of functionality to please some user
  • Use Case = Design Feature???
  • Black? or White-Box??
use case diagram
Use Case Diagram
  • UML: like UK, USA, the Unified/United covers a multitude of sins
  • Use Cases predate UML and are quite unlike much of it
  • "Use Cases are fundamentally a textual form" - Alistair Cockburn
  • Bubbles and Stick-Men by themselves aren't terribly informative
unknown use case structure
(Unknown) Use Case Structure
  • Goal
    • Primary Scenario
      • list of steps (Actor, Action)
    • Alternative Paths
      • set of Scenarios branching from 1ry
    • Exceptions
      • set of Scenarios, each with a triggering Event
    • AOB
      • preconditions, trigger, results if successful, minimal guarantees (successful or not), constraints, ...
use case problems
Use Case Problems
  • Many!
    • Fragmentation of problems (not necessarily any better than a mass of Dataflow Diagrams)
    • Functional Approach tends to ignore non-functional requirements (Constraints)
    • Looking for the Primary and positive first can mean never getting around to looking for Exceptions
    • Drawing little bubbles and stickmen can mean never writing Scenarios as Stories (… the Dataflow peril, again)
misuse cases10
Misuse Cases
  • Guttorm Sindre and Andreas Opdahl, 2000
  • Actor is a Hostile Agent
  • Bubble is drawn in inverted colours
  • Goal is a Threat to Our System
  • Obvious Security Applications
a minimax approach to security
A MiniMax Approach to Security
  • White's Best Move … is to find out Black's Best Move, and counter it
  • Seems natural to me to introduce 'threatens', 'mitigates'
  • Economical use of types of relationship (UML stereotypes)
anthropomorphize for safety
Anthropomorphize … for Safety
  • UML's stick-man looks like 'human agent' but can be of any type (robot, system)
  • Anthropomorphizing Forces of Nature is useful: it enables us to use our Social/Soap Opera Brain to reason about threats to our systems
  • Misuse Case helps to Elicit Subsystem Functions
misuse cases identify nfrs
Misuse Cases Identify NFRs
  • Use Cases are weak on NFRs
  • Misuse Cases naturally focus on NFRs, e.g. Safety
  • Response is often a SubSystem Function, possibly to handle an Exception
design trade offs
Design Trade-Offs

Conflict Analysis builds upon Use/Misuse Case Modelling with additional relationships 'aggravates' and 'conflicts with'


Sit Comfortably




Cause Injury


Wear Out Seat





Wear & Tear

Misalign Locking Pin




Weaken Armrest





Break Armrest

conflicts with




Strengthen Armrest


Design Engineer

Design Engineer

Design Engineer

Design Engineer



Omit Armrest

Slash Seat



Harass Women

Reinforce Seat

Burn Seat

A Real Example – Tube Seat Trade-Offs

The seat designers in the workshop quickly came up with

3 candidate solutions, once the conflicts were understood

benefits of misuse cases
Benefits of Misuse Cases
  • Open a new avenue of exploration
  • Contribute to searching systematically for exceptions, directed by the structure of the scenarios
  • Offer immediate justification for the search and indicate the priority of the requirements discovered
  • By personifying and anthropomorphizing the threats, add the force of metaphor to requirements elicitation
  • Make the search enjoyable and provide an algorithm for the search. Obvious parallel here with Cost/Benefit analysis
  • Make the reasoning behind affected requirements immediately comprehensible
applications of misuse cases
Applications of Misuse Cases
  • Eliciting Security Requirements
  • Eliciting Safety Requirements
  • Identifying Exceptions
  • Identifying Test Cases
  • Design Trade-offs
tool support
Tool Support
  • Free Scenario Plus toolkit for DOORS
  • Graphical and Textual Output (and HTML)
  • Automatic Linking, Metrics, etc
  • Automatic Creation of Referenced Use/Misuse Cases (if user confirms)

Automatic Creation of links between Misuse and Use Cases, by searching for underlined use case names with simple fuzzy matching.

rule based linking
Rule-Based Linking
  • Links can be specified (by underlining) from any (Mis)Use Case to any other
  • Type of Link is determined by (Source, Target) Case Type, assuming you want to analyse threats/mitigations
  • Other Types of Link can be specified manually
  • Misuse Cases are a new form of an old technique
  • Planning has always been 'what-if'
  • Systems that don't plan to handle Exceptions are planning to fail at once
  • Misuse Cases greatly enhance the power of Use Cases
  • The power of visual metaphor (black) and anthropomorphism (stick-men) should not be underestimated
  • Misuse Cases are useful throughout System Life-Cycle

Ian Alexander is an independent consultant and trainer specialising in Requirements Engineering, often using DOORS. He is the author of the Elipsis 3-Day Requirements Engineering Course, and co-author of its 3-Day Systems Engineering Course. His new book 'Writing Better Requirements' will shortly be published by Addison-Wesley.

He is currently collaborating with DaimlerChrysler Research and Technology on the reuse of requirements between different series of cars. His principal research interest is in improving the requirements engineering process by modelling business goals, processes, constraints, and scenarios. This approach is supported by his Scenario Plus for Use Cases toolkit which is the subject of numerous papers.

He helps to run the BCS Requirements Engineering Specialist Group and the IEE Professional Network for Systems Engineers. He is a Chartered Engineer.