Non-Functional Requirements Document?

[Unnsse Khan]

Hello there,

I figured that this would be the appropriate place to ask this question...

Can anyone provide me of an example / definition of a non-functional requirements document? Do "load balancing" or "stress testing" constitute as a non-functional requirement?

Many, many thanks!

[Susan]

Yes, just like security they too constitute NFRs.

[Stan James]

Most of our "supplemental requirements" doc is about RASP

Reliability - unscheduled downtime
Availability - scheduled uptime, user sites
Scalability - user counts, transaction rates, database size, etc
Performance - response times, throughput, etc

Monitoring and Control describes how to measure all those things and tune or fix a running system.

We also have some UI standards that all pages must meet. I'm scratchin my head trying to remember what else. Anybody else?

[Ulf Dittmer]

Some others may be:

Existence of certain forms of documentation

Code maintainability, possibly defined by coding standards

Existence of a test suite

[Scott Ambler]

Just wanted to point out that the term "non-functional requirement" is sort of goofy. "Non-functional" == "doesn't work", and do you really want to implement requirements that don't work?

The source of this term is the IEEE, and frankly they blew it. They wanted to divide requirements into two types, functional requirements and requirements which weren't directly related to the functional aspects of the system, but couldn't come up with a good term.

Personally, I prefer to use the term "technical requirements" and try to convince others to use this term. We should actively try to get "non-functional requirements" out of our lexicon.

- Scott

[Svend Rost]

Originally posted by Scott Ambler:

Personally, I prefer to use the term "technical requirements" and try to convince others to use this term. We should actively try to get "non-functional requirements" out of our lexicon.

or Quality Attributes.

/Svend Rost

edit: in case anyone's wondering - im pro "quality attributes", not against
[ January 02, 2006: Message edited by: Svend Rost ]

[Stan James]

Or, worse, "the -ilities". Ick.

[Frank Carver]

It's not entirely in-line with this discussion, but I often find it useful to divide requirements into two rough groups:

It must

It must not (or must only, or must always, which are logically equivalent)

The first group usually end up relatively testable, and align fairly well with traditional "functional" requirements.

The second group are often effectively untestable, and align fairly well with traditional "non functional" requirements.

Security requiements, for example, usually fall in the second group "the software must not contain any loopholes that allow unauthorized access", as do performance criteria "the software must always return data within 10 seconds".

[Scott Ambler]

I suspect that you can always reword a "must not" into a "must".

- Scott

[Rajesh Menon]

Have added few more to the list given by Stan .
The technical requirement specification may consider the following.

1.Reliability
2.Availability (Fail -over mechanisms)
3.Performance (Load balancing)
4.Security mechanisms
5.Monitoring and Control
6.Risk mitigation
7.User Interfaces ( region/domain specific standards)
8.Flexibility (Configurable features)
9.Scalability

It should clearly mention expected behavior of the system for the above factors.These in turn will be the input to the design specification.

More or less these depend on customers requirements and preferences.

[Frank Carver]

Originally posted by Scott Ambler:
I suspect that you can always reword a "must not" into a "must".

Sure, but that doesn't usually help the process of splitting requirements into functional/testable and non-functional/non-testable. I've worked with far too many "requirements" where the word "must" was wedged in to every sentence as if it was some form of required syntax.

What I'm trying to get at is that looking at the wording can be a useful tool to help clarify requirements.

A requirement such as "the system must give the answer '5' when given parameters '2' and '3'" is obviously testable - it's pretty much a test case itself. A requirement such as "the system must give the sum of its two parameters" is almost as testable (there are still potential questions about the valid range of inputs, etc.)

A requirement such as "the system must always respond within 10 seconds", or "the system must only allow authorized persons to access the data" are deceptive. They read as if they are testable, but the addition of "always" and "only" places too much stress on the infinite range of possible test cases. These slip into a grey area of not-fully-testable or semi-functional and (in my experience) are the source of the majority of in-service bugs.

All of this may, of course, be just how I choose to read this stuff. But I have found it a useful technique in the past.

[Svend Rost]

With respect to a list of quality attributes:

You might wish to take a look at ISO 9126. It contains metrics for 6
quality attributes(QA) and their sub attributes (e.g. a sub attribute
to Functionality could be suitablity or accuracy).

/Svend Rost

[Stan James]

Re quality attributes, it can be an interesting exercise to see if your team, management, customers, etc can prioritize a list of possibly conflicting qualities ...

zero defects
rapid delivery
small memory footprint
small database footprint
small deployment footprint
fast
reliable
object oriented design purity
low cost to extend
low cost to modify
contribute to reuse
consume reusable components
...

With a little time I could dig out a list of about a hundred items I used a few years ago. Everything on the list would presumably be A Good Thing. Deciding which you might sacrifice to achieve another is the juicy part.