Question

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).

Was it helpful?

Solution

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top