Presentation on theme: "Misuse Cases Use Cases with Hostile Intent Ian Alexander Independent Consultant"— Presentation transcript:
Misuse Cases Use Cases with Hostile Intent Ian Alexander Independent Consultant
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' #1Either you think out what could happen – and what you mean to do about it #2Or 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 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 'Suppose it turns and charges us before it falls into the pit' Montignac Caves, Dordogne, France
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 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 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 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 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 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 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 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 Conflict Analysis builds upon Use/Misuse Case Modelling with additional relationships 'aggravates' and 'conflicts with'
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 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 Eliciting Security Requirements Eliciting Safety Requirements Identifying Exceptions Identifying Test Cases Design Trade-offs
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 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
Summary 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
About... 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.