A few of the non-functional requirements for "high availability" are
mapped to a Use Case called "Provide High Availability", marked as
<>.
As the saying goes, "if the only tool you have is a hammer, every problem looks like a nail". Use Cases exist to identify the value a system provides for its user(s). So they're meant to describe functional things: stuff the system does.
So I wouldn't generally recommend capturing non-functionals in this way. However: that's not to say they can't be captured in Use Cases. It can be very useful within functional use cases to specify their non-functional requirements. For example:
Use Case: Submit Order
{...functional description...}
Availability: 9-5 mon-fri
Volumes: 5000 peak per day
...
That ties the non-functional requirement directly to the function it supports. Which makes sense - since non-functionals have no purpose or context without function.
Of course, you'll find that many Use Cases share the same non-functionals. You don't want to duplicate, so need to find a way to factor out. I prefer to do that in a separate document.
But there's no law against capturing in a 'Use Case'. Whilst it violates the theory there are reasons to do it in practice: e.g. limitations of the modelling tool (can't link UCs to a document) and/or desire to keep all in one place.
Fundamentally it boils down to theory and practice. In theory, there's no such thing as a non-functional Use Case. In practice creating a UC to hold non-functionals might make sense. So long as everyone understands its really just a convenient container rather than a bona-fide piece of functionality I wouldn't get worked up about it.
hth.
