1 / 21

Misuse Cases

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

Audrey
Download Presentation

Misuse Cases

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Misuse Cases Use Cases with Hostile Intent Ian Alexander Independent Consultant http://www.scenarioplus.org.uk

  2. 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)

  3. 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.

  4. 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'

  5. Negative Scenarios are Not New Montignac Caves, Dordogne, France 'Suppose it turns and charges us before it falls into the pit'

  6. 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??

  7. 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

  8. (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, ...

  9. 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)

  10. 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

  11. 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)

  12. 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

  13. 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

  14. Design Trade-Offs Conflict Analysis builds upon Use/Misuse Case Modelling with additional relationships 'aggravates' and 'conflicts with'

  15. Sit Comfortably threatens Passenger threatens Cause Injury threatens Wear Out Seat threatens mitigates aggravates Accident Wear & Tear Misalign Locking Pin aggravates threatens mitigates Weaken Armrest aggravates threatens Vandal Vandal Break Armrest conflicts with Pest threatens mitigates Strengthen Armrest mitigates Design Engineer Design Engineer Design Engineer Design Engineer aggravates Fire Omit Armrest Slash Seat aggravates mitigates 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

  16. 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

  17. Applications of Misuse Cases • Eliciting Security Requirements • Eliciting Safety Requirements • Identifying Exceptions • Identifying Test Cases • Design Trade-offs

  18. 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.

  19. 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

  20. 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

  21. 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.

More Related