Functional vs. Non-Functional Requirements

[Mike Rawlins <rawlins@metronet.com>]

I have found that folks are frequently confused regarding what
differentiates non-functional requirements from functional
requirements.  This doesn't surprise me - I'm doing my master's research
on non-functional requirements and I still have trouble sometimes.  In
order to assist you with the distinctions and help frame our
discussions, I offer the following definitions and illustrations:

Functional requirements are typically phrased with subject/predicate
constructions, or noun/verb.  "The system prints invoices."
Non-functional requirements may be found in adverbs or modifying
clauses, such as "The system prints invoices *quickly*" or "The system
prints invoices *with confidentiality*".

>From a mathematical point of view, a "function" takes an input(s) and
yields an output(s). "Functional" refers to the set of functions the
system it to offer, while "non-functional" refers to the manner in which
such functions are performed.

Following are IEEE-ish definitions:

functional requirement --- A system/software requirement that
specifies a function that a system/software system or system/software
component must be capable of performing. These are software requirements
that
define behavior of the system, that is, the fundamental process or
transformation that software and hardware components of the system
perform
on inputs to produce outputs.

nonfunctional requirement  --- in software system engineering,
a software requirement that describes not what the software will do,
but how the software will do it, for example, software performance
requirements, software external interface requirements,
software design constraints, and software quality attributes.
Nonfunctional requirements are difficult to test;
therefore, they are usually evaluated subjectively.

>From a software engineering text, regarding non-functional requirements:

"... have been recognized as a vital determinant to the success
of just about any software project, and led to proliferation of terms,
be they organizational, managerial or technical.
While also referred to as
``desirable attributes", ``non-behavioural requirements",
``design constraints",
``system interface requirements", ``user interface requirements",
``hardware characteristics", ``software quality", etc.,
or more colloquially known as ``--ilities and --ities",
such issues are termed {\it non-functional requirements} in this book
with the intent to distinguish them from functional requirements.

--------------------------------
I expect that most of the requirements we will be concerned with for an
ebXML compliant application will be non-functional in nature.  The ebXML
guidelines will specify many functional features to satisfy those
non-functional requirements.

Hope this helps.

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/