What does the software have to be able to do? Which features should it provide? These are typical questions that requirements engineering attempts to clarify. For this, use cases are created and normally the use case diagram is used to visualize it. But what about about stakeholders’ goals and desires that don’t fit into that? “The system must be completely secure!” is an example of something your customers might say. Good, you think, and create a security requirement that should increase the quality of the system. But this is rather broadly described and difficult to examine. Could a use case be formed from this? Unfortunately, the answer to this is: no, use cases are only recommended for functional requirements – so, descriptions of implementable features. To be able to derive quality requirements (non-functional requirements), you have to think the other way around – what should the system NOT be able to do? Or in this case: what should the system hinder so that it is secure? And then misuse cases come into play.
What is a misuse case?
Misuse cases were described for the first time in 2001 by Guttorm Sindre and Andreas Opdahl, two Norwegian professors in the area of information system development, for requirements in the area of system security. They explained the known requirements process with use cases and use cases diagrams. A misuse case can be imagined as an inside-out use case – so, a feature that should not be implementable in a system. It offers another viewpoint of the system to manage security requirements. Above all, these requirements are very meaningful according to the Kano model of stakeholder satisfaction.