Re: Conference Call Today

["Marcia L. McLure Ph.D." <marcia.mclure@mmiec.com>]

Business Process Methodology Working Group members,

The candidate questions identified in Paul's write-up accurately reflect the
list we created during our initial teleconference call.  I did not receive
any additional survey items over the week-end.  But if there are any
additional items you would like to add for consideration, please email me
your recommendation and I will gladly add them to our list.  Thank you all.

In terms of the ebXML Requirements Work Group request for input, I thought
it might be helpful to our
Business Process Methodology WG effort to read the attached document
providing the definitions
being used by the Requirements Work Group for the terms functional and
non-functional.

Marcia


Marcia McLure Ph.D.
MMI
28720 Canwood Street Suite 208
Agoura Hills CA 91301
Phone: 818-706-3882
Fax: 818-706-1213
Email: marcia.mclure@mmiec.com


-----Original Message-----
From: Paul R. Levine <plevine@telcordia.com>
To: ebXML-BP@lists.oasis-open.org <ebXML-BP@lists.oasis-open.org>
Date: Monday, December 06, 1999 12:16 AM
Subject: Conference Call Today


>
>
>Business Process Methodology Working Group
>
>Our teleconference call this week is today, Monday 6 Dec. from 12:00 p.m.
to
>1:00 p.m. U.S. Eastern time.  To access the call, please dial +1 732
336-6000,
>followed by a PIN of 8327# at the prompt.  Report of last week's call is
>attached.
>
>Proposed agenda items are:
>
>     Continue work on Business and Functional Requirements as input to the
>Requirements Working Group (see short list created in last week's call);
Also
>choose an editor for this deliverable.
>
>        Discuss Unified Methodlling Methodology paper from UN/CEFACT TMWG
>
>     Continue survey of current "vertical" XML-based process methodologies
(see
>short list created in last week's call; Marcia may have additional items
for
>the survey)
>
>     Announce next  seven conference calls
>
>Best Regards,
>
>Paul Levine
>(See attached file: BPMWG_Meeting Report_30111999.doc)
>

---

• From: Mike Rawlins <rawlins@metronet.com>
• To: "List, ebXML Requirements" <ebXML-Requirements@lists.oasis-open.org>
• Date: Fri, 03 Dec 1999 13:47:30 -0600

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/

---