Tom Gilb and Kai Gilb's blog
Are non-functional requirements functional?
Published
by Tom Gilb
on Sun 18 of Jan., 2009
At Mike Cohn's website
http://blog.mountaingoatsoftware.com/?p=62&cpage=1#comment-30462
There is a discussion on 'non-functional' requirements.
Here is my contribution.
January 18th, 2009 at 2:52 pm
I think you will find that ‘constraints’ is an unfortunate categorization for ‘non-functional’ requirements.
We have some agreement that the term non-functional requirement is not a good one. I seriously suggest that the many people who use it have not yet thought very deeply about requirements. I detest it and its use.
My books, that Mike refers to above go into some depth on this matter for those who wish to go deeper than this reply can do. (Competitive Engineering and PoSEM88)
I used to be confused myself, before I began to work out the terminology deeply. One way to go deep is to access the many requirements concepts in my Concept Glossary http://www.gilb.com/tiki-download_file.php?fileId=25
I used to think that ‘all requirements constrained’ (even function requirements). All requirements constrain our other choices (design, architecture, timing and more) but it is still not useful to call all non-function requirements ‘constraints’.
I got the necessary insight in a flash once, when I realized that some requirements are ‘primarily intended’ to constrain. And some requirements are not primarily intended to constrain.
They might just do so incidentally. They might incidentally inspire, seem stupid, waste resources, be unnecessary, and they might incidentally have many secondary unintended side effects. But I would not classify all non-function requirements as ‘inspirers’, ’stupid’, or ‘unnecessary’ because of these side effects. By the way non-functional (the -al) is bad grammar!
There are many interesting types of requirements that are not function requirements. See the Concept Glossary, under ‘Requirement’ for a chart of them.
The most interesting requirement type, from my viewpoint, is what I call ‘quality’ requirements. Quality requirements describe ‘how well’ a function needs to be done (as Mike points out, mostly ‘ilities’).
But, and this is true of all scalar requirements, there are two basic scalar levels of requirement, and both can be applied simultaneously. I call these two classes ‘targets’ (levels of quality we might value reaching), and ‘constraints’ (levels of quality we would value not falling below).
A simple example in my Planguage:
Maintainability:
Type: Quality Requirement.
Scope: All software in products, or their support systems, that we provide to customers.
Scale: Mean Time to Completely Fix a Bug from its Existence is ascertainable.
——– Here are 2 different constraint requirements —-
Fail 2010, UK 24 hours
Catastrophe 2009, Europe 1 week
——— Here are 2 different Target Requirements
Goal 2011, Worldwide, Games Sector Products 1 hour
Stretch 2013, Worldwide 20 minutes.
The above concepts are explained in the Concept Glossary, but most of you can guess their basic meanings. Concepts like ‘Goal’ have a defined set of attributes such as: must be technically feasible, within budget, prioritized etc. ‘Stretch’, for example, does not have such requirements!
‘Fail’ and ‘Catastrophe’ level requirements are primarily intended to set clear lower limits. But ‘Fail’ simply means that ‘below that constraint level things are unpleasant’ (like ‘difficult to breathe’) but recoverable. ‘Catastrophe’ is a constraint that signals disaster, possibly irrecoverable (suffocation).
This is enough to hint at the potential, useful, distinctions in requirements.
Hopefully the astute reader is beginning to see what we cannot simple declare all non-functions to be ‘constraints’. It is not logically true or useful!
more at the website gilb.com
Tom
http://blog.mountaingoatsoftware.com/?p=62&cpage=1#comment-30462
There is a discussion on 'non-functional' requirements.
Here is my contribution.
January 18th, 2009 at 2:52 pm
I think you will find that ‘constraints’ is an unfortunate categorization for ‘non-functional’ requirements.
We have some agreement that the term non-functional requirement is not a good one. I seriously suggest that the many people who use it have not yet thought very deeply about requirements. I detest it and its use.
My books, that Mike refers to above go into some depth on this matter for those who wish to go deeper than this reply can do. (Competitive Engineering and PoSEM88)
I used to be confused myself, before I began to work out the terminology deeply. One way to go deep is to access the many requirements concepts in my Concept Glossary http://www.gilb.com/tiki-download_file.php?fileId=25
I used to think that ‘all requirements constrained’ (even function requirements). All requirements constrain our other choices (design, architecture, timing and more) but it is still not useful to call all non-function requirements ‘constraints’.
I got the necessary insight in a flash once, when I realized that some requirements are ‘primarily intended’ to constrain. And some requirements are not primarily intended to constrain.
They might just do so incidentally. They might incidentally inspire, seem stupid, waste resources, be unnecessary, and they might incidentally have many secondary unintended side effects. But I would not classify all non-function requirements as ‘inspirers’, ’stupid’, or ‘unnecessary’ because of these side effects. By the way non-functional (the -al) is bad grammar!
There are many interesting types of requirements that are not function requirements. See the Concept Glossary, under ‘Requirement’ for a chart of them.
The most interesting requirement type, from my viewpoint, is what I call ‘quality’ requirements. Quality requirements describe ‘how well’ a function needs to be done (as Mike points out, mostly ‘ilities’).
But, and this is true of all scalar requirements, there are two basic scalar levels of requirement, and both can be applied simultaneously. I call these two classes ‘targets’ (levels of quality we might value reaching), and ‘constraints’ (levels of quality we would value not falling below).
A simple example in my Planguage:
Maintainability:
Type: Quality Requirement.
Scope: All software in products, or their support systems, that we provide to customers.
Scale: Mean Time to Completely Fix a Bug from its Existence is ascertainable.
——– Here are 2 different constraint requirements —-
Fail 2010, UK 24 hours
Catastrophe 2009, Europe 1 week
——— Here are 2 different Target Requirements
Goal 2011, Worldwide, Games Sector Products 1 hour
Stretch 2013, Worldwide 20 minutes.
The above concepts are explained in the Concept Glossary, but most of you can guess their basic meanings. Concepts like ‘Goal’ have a defined set of attributes such as: must be technically feasible, within budget, prioritized etc. ‘Stretch’, for example, does not have such requirements!
‘Fail’ and ‘Catastrophe’ level requirements are primarily intended to set clear lower limits. But ‘Fail’ simply means that ‘below that constraint level things are unpleasant’ (like ‘difficult to breathe’) but recoverable. ‘Catastrophe’ is a constraint that signals disaster, possibly irrecoverable (suffocation).
This is enough to hint at the potential, useful, distinctions in requirements.
Hopefully the astute reader is beginning to see what we cannot simple declare all non-functions to be ‘constraints’. It is not logically true or useful!
more at the website gilb.com
Tom
