• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

Non-Functional Requirements Document?

 
Ranch Hand
Posts: 511
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, just like security they too constitute NFRs.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Rancher
Posts: 43024
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some others may be:
  • Existence of certain forms of documentation
  • Code maintainability, possibly defined by coding standards
  • Existence of a test suite

  •  
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Ranch Hand
    Posts: 904
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Or, worse, "the -ilities". Ick.
     
    Sheriff
    Posts: 6920
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I suspect that you can always reword a "must not" into a "must".

    - Scott
     
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 6920
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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
    Ranch Hand
    Posts: 904
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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 ...

    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.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic