Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there such a thing as a "Non-Functional Use Case"?

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

like image 437
Steve Chambers Avatar asked Sep 17 '13 13:09

Steve Chambers


People also ask

Can use cases be used for non-functional requirements?

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.

Is a use case a functional requirement?

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.

What is functional and non functional use case?

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?”

How can a non-functional requirement be described in a use case model *?

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.


1 Answers

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.

like image 161
sfinnie Avatar answered Oct 12 '22 10:10

sfinnie