I'm reading a System Requirements Document that was produced using Sparx Enterprise Architect. All requirements are mapped to particular Use Cases.
A few of the non-functional requirements for "high availability" are mapped to a Use Case called "Provide High Availability", marked as <<non-functional>>
. Am fairly new to all this and struggling to decide if it makes sense for a Use Case be non-functional - hence the question.
If the answer is yes then great - but if not, I'd be interested to know people's opinions on how such requirements should map to Use Cases (if at all).
Some nonfunctional requirements can be refined as nonfunctional use cases (also known as infrastructure use cases), such as persistence and encryption, which are described in this section.
Use cases describe the functional requirements of a system from the end user's perspective, creating a goal-focused sequence of events that is easy for users and developers to follow. A complete use case will include one main or basic flow and various alternate flows.
A functional requirement defines a system or its component. A non-functional requirement defines the quality attribute of a software system. It specifies “What should the software system do?” It places constraints on “How should the software system fulfill the functional requirements?”
Non-functional requirements or NFRs are a set of specifications that describe the system's operation capabilities and constraints and attempt to improve its functionality. These are basically the requirements that outline how well it will operate including things like speed, security, reliability, data integrity, etc.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With