“The system needs to be available 24/7.” Or: “The system must be capable of delivering an answer within 5 seconds.” These kinds of requirements are associated with quality or performance criteria that the system needs to be able to fulfill in order for the users to be satisfied. The first example refers to system availability and the second to performance. Requirements that refer to a quality or performance criterion, and that are not considered functional requirements, are called qualitative requirements.
Beyond availability and performance there are other important criteria that need to be considered such as reliability, scalability, portability, data volumes, transfer rates and resource utility of the system under development. Sometimes usability is mentioned on that list, as is security. They refer to criteria that are meant to prevent abuse.
Finding qualitative requirements in the field of safety and security is difficult – but not impossible. We’re going to show you how.
The problem with non-functional requirements
“The system needs to be available by autumn at the latest in order for us to present it at the industry events in October and November.” Or: “The system will only run on iOS devices.”? These kinds of requirements refer, as in the first example, to the development process. That is, they limit the possible number of solutions, as in the second example. But they do not refer to functional requirements or qualitative requirements. They are known as ancillary conditions or constraints. Qualitative requirements and constraints belong to the category known as non-functional requirements. ¹
A lot of agile teams have some difficulty with identifying non-functional requirements because their value is not immediately visible. Some try to interpret non-functional requirements as technical tasks that need to be completed in order for the technical infrastructure to be created. In so doing they turn non-functional requirements into user stories acceptance criteria. The only problem is that there are technical tasks that do not have a direct relationship with a specific user story. What needs to happen then? Other teams try to translate the technical necessities into business value in order to gain a shared basis for prioritizing user stories – a difficult endeavor. Others spend a lot of time discussing whether there are special technical stories and if so, whether they belong in the backlog along with the user stories.
The cause of this confusion is the role model. The product owner (PO) is responsible for prioritizing requirements. If he does not have the necessary know-how he should have a technical product owner at his side who knows how to deal with non-functional requirements that do not have a direct functional value but without which the functional requirements cannot be fulfilled. The more complex the infrastructure and architecture under development is, the more important this role is.
Eliciting non-functional requirements
Constraints and performance criteria in a system or product can be worked out with functional requirements in communication with stakeholders. Non-functional requirements can often be derived from functional ones. Stakeholders understand them relatively easily. Let’s take the example of a query in a system. How long is a user prepared to wait for an answer? Does the data need to be accessed within milliseconds? Should the answer be available immediately? Or is the answer in the specific workflow also acceptable in 2, 3 or 4 seconds?
Things become more difficult if the quality requirements refer to specific quality criteria of the system or product. The meaning of the quality criteria is hard for the stakeholders to understand. After all, what do stakeholders know about quality criteria like interoperability or appropriateness? That does not mean that you should skip the step of eliciting quality requirements. You should prepare yourself for them in your team.
Then you need a unified understanding of which quality criteria are even relevant to the system under development. Time and security are important features in almost any system. But are quality attributes like interoperability, appropriateness or even modifiability and replicability of equal importance?
Eliciting requirements with misuse cases
If you were to ask a stakeholder: “How secure should the system be?” you will almost always get the answer: “Totally secure”. So it’s best if you package the questions about quality criteria like the security of a system in illustrative stories from your life. This makes it easier to understand what could happen if a quality criteria is either under- or adequately developed. But what do you do if you are not a very good storyteller? Then we have one more tip for you: use cases can help in the area of safety and security when it comes to quality requirements. In other words, it is the misuses cases that put us on the scent of quality requirements.
A misuse case is a failed or faulty use case. It describes a function that obstructs the creation of a system. Just as a use case depicts an interaction consequence that creates value for the organization, then a misuse case can be an interaction consequence. That is to say, one that results in a loss for the organization or a specific stakeholder. A mis-actor is someone who causes damage, someone who interacts with a misuse case. ²
Misuse cases: an example
Let’s take a look at an example of a use case and two misuse cases. A car owner would like to start his car without a key. A thief, on the other hand, would like to steal his car. This could be possible if the thief is able to break open the lock or to hack Go system’s radio signal.
If you work with use case diagrams often you will see that the “contains relationship” and the “expansion relationship”, as defined in the UML for the use cases, often get estranged from their original purpose. They are used to depict the threat posed by and defense against a misuse case. Sure, you could create use case diagrams on a flipchart or whiteboard, but as software producers we would recommend using appropriate software instead. With the right software the relationships develop a new logic. Instead of “include” and “extend” the arrow points depict the verbs “attacks” and “prevents”. They refer to sub-stereotypes of the “includes” and “extends” relationship. The sub stereotypes make it possible to define evaluations of misuse cases and their relationships as a means of deriving quality requirements.
The use of misuse cases can complement the idea of use cases by offering a new perspective. Misuse cases are not implemented and a description using flows would not make sense, but the additional perspective on the system makes it possible to discover other quality requirements. Granted, stakeholders assign different levels of importance to a systems various quality criteria. Some consider performance to be very important because user acceptance is dependent on it. Others value security measures more highly, even if they negatively influence the performance. Misuse cases offer safety and security and an approach that is easy to understand and apply. It also provides important quality requirements for the development of the system. All of your stakeholders will appreciate the higher quality.
 This terms image is based on the standards of the International Requirements Engineering Board IREB for the training of Certified Professionals for Requirements Engineers (CPRE)
 From Sindre, G., Opdahl, A.L. (2001) Capturing Security Requirements through Misuse Cases. From Capturing Security Requirements through Misuse Cases: http://folk.uio.no/nik/2001/21-sindre.pdf as well as Johnstone, M. N. (5th-7th. December 2011). Modelling misuse cases as a means of capturing. From Modelling misuse cases as a means of capturing: http://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1119&context=ism