What is a Misuse Case, how is it created, what advantages does it offer and what examples exist?
The Idea of Misuse Cases
The application of Misuse Cases complements the idea of use cases with an additional viewing angle. A Misuse Case is an abusive use case. It describes an interaction that a system should not allow and even prevent. Abusive use cases were first described in 2001 by two Norwegian professors. Guttorm Sindre and Andreas Lothe Opdahl were active in the development of information systems and published Capturing Security Requirements through Misuse Cases. Just as a use case represents a sequence of interactions with the system by which an actor pursues a goal and creates value for it, a misuse case also describes a sequence of interactions – but one that ends with a loss for the actor, for the organisation that provides the system, or for stakeholders.
Advantages of Misuse Cases
Misuse Cases are easy to apply and offer a number of advantages:
- The quality of development increases as non-functional requirements are easier to identify.
- Project participants understand the system to be developed better and more comprehensively.
- A risk analysis is possible at an early stage and a loss of value for the organisation or stakeholders can be prevented.
- Potential points of attack and weaknesses in the system can be identified more easily.
- Misuse Cases can be tested with test cases – in the sense of: Prevention of unwanted functionality.
Visualisation and Implementation
Misuse Cases can be created in the form of use case diagrams on the flipchart or with professional software. Some tools offer the use of sub-stereotypes of the contain and extension relationship: “include” and “extend” become “attacks” and “prevents”. Ideally, these are not just “free text”, as they allow Misuse Cases and their relationships to be evaluated and quality requirements to be derived. The actor in the Misuse Case who causes a damage is called MisActor by the way.
Misuse Cases are not implemented and a description with the help of use case stories does not make sense either, but the slightly different perspective on a system makes it possible to determine additional requirements. This approach is particularly easy to understand and apply in the area of Safety & Security. It offers organisations the opportunity to discover important quality requirements for the development of safe systems. According to the Kano model, such requirements are very important for customer satisfaction.
Misuse Cases in Practice
Examples of Misuse Cases
Misuse Cases are easy to understand and apply, especially in the area of Safety & Security. They offer organisations the opportunity to discover important quality requirements for the development of safe systems. Here you will find a list of some Misuse Cases – the naming is based on the goal of the MisActor:
- Use data and identities of Internet users to …
- Order and pay for goods with third-party credit card data.
- Use the transaction data of mobile phones or cars without consent to …
- Earn money with warnings about possible copyright infringements.
- Using signal extensions to steal cars from “keyless” systems in order to …
Essentially, any misuse of a product or theft can be understood as a misuse case. In some Misuse Cases companies will try to take protective measures. The world’s first solar highway opened in China in early 2018. A short time later, the first solar panels were stolen. Organisations will certainly protect themselves against such abuses, while the state can enact rules and laws for others (spray cans can only be sold to paint shops and thus reduce damage caused by graffiti) and for some nothing can be done about it (cars are powered by petrol and in some places lit on fire).
Creating Misuse Cases
Safety requirements for a system are often formulated in very general terms. This makes them difficult to implement and check. Even the creation of use cases is so difficult, because normally use cases are only suitable for the determination of functional requirements. Here a question helps: What should the system not be able to do? Or: what should the system prevent?
The following procedure has been established:
- Define and visualise use cases and determine requirements.
- Identify potential hazards on the basis of the individual use cases, including the MisActors.
- Relate Misuse Cases with the threatened Use Cases.
- Derive requirements that prevent Misuse Cases.
- Describe test cases – it should be borne in mind that a Misuse Case is checked in such a way that unwanted functionality is successfully prevented.
Herausforderungen für Unternehmen
A complete System through Misuse Cases
Use cases are a good way to describe a system from the user’s point of view. Misuse Cases supplement conventional use cases with a valuable perspective. This perspective can be used well to think about operating and safety aspects and to determine corresponding requirements. A Misuse Case itself will not end up in a backlog either in parts or as a whole, but the requirements it determines will. The use of Misuse Cases creates a more complete picture of a system. In addition, possible weak points can be identified at an early stage. And: anyone with a little experience in the handling of use cases will quickly and easily understand the concept of Misuse Cases.
Working with use cases, use case diagrams, use case 2.0 and Misuse Cases basically offers a comprehensive concept for understanding systems not only in detail but as a whole. Companies simply need to apply the concepts consistently and appropriately to the organisation.
We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the description of use cases and the collection, structuring and administration of requirements. We pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and take stakeholders, goals and constraints into account. And we plan and control your projects with these requirements on the basis of defined processes.