Some of the non-functional requirements for "high availability" are compared with the use of the "Ensure high availability" example, designated as <>.
As the saying goes, "if the only tool you have is a hammer, every problem looks like a nail." Use Cases exist to determine the value that the system provides to its users (users). Therefore, they are intended to describe functional things: things that the system does.
Therefore, I would not recommend capturing non-functionals in this way. However: not to say that they cannot be captured in "Use Cases". In functional cases, it can be very helpful to indicate their non-functional requirements. For instance:
Use Case: Submit Order {...functional description...} Availability: 9-5 mon-fri Volumes: 5000 peak per day ...
This links non-functional requirements directly to the function that it supports. This makes sense - since non-functionals have no purpose or context without a function.
Of course, you will find that many Use Cases use the same non-functional. You do not want to duplicate, so you need to find a way to dodge. I prefer to do this in a separate document.
But there is no law against capture in Use of the Case. Despite the fact that it violates the theory, there are reasons to do it in practice: for example, the limitations of a modeling tool (they cannot associate UC with a document) and / or the desire to keep everything in one place.
In essence, it comes down to theory and practice. In theory, there is no such thing as a non-functional use case. In practice, creating a UC to store non-functional can make sense. While everyone understands that this is a really convenient container, and not functional functionality, I would not work on it.
NTN.