NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4986

Internet Message Format | 1992-12-15 | 9.5 KB

Path: sparky!uunet!pipex!bnr.co.uk!uknet!ieunet!vms.eurokom.ie!pthornley
From: [e-mail] (Phil Thornley, BAe)
Newsgroups: comp.software-eng
Subject: Analysis of Nonfunctional Characteristics
Message-ID: <[e-mail]>
Date: 15 Dec 92 19:38:07 GMT
Organization: EuroKom Conferencing Service
Lines: 215

Here is a summary of responses to the question I recently asked on
support for the analysis of non-functional characteristics.

The original post asked:-

     Can anyone help with information on methods, tools, techniques, etc
     for analysis of non-functional characteristics (the 'ilities').
                     ^^^^^^^^^^^^^^
     The applications to be analysed are embedded computer systems (mostly
     airborne systems).  The analysis is needed in the early stages of the
     design process and it should ideally (!) be applicable to hardware,
     software and the combined system.

There were 6 responses, as follows.  My thanks to all who responded.

Phil
[e-mail]

#########################################################################

From: [e-mail] (Andy Oram)

A journal issue that I found useful for lists of requirements is:

   IEEE Computer, Requirements Engineering Environments: Software
   Tools for Modeling User Needs.  Vol. 18, No. 4, April 1985.

In particular, if I remember right, non-functional requirements were
discussed in the article "A Taxonomy of Current Issues in
Requirements Engineering," by Gruia-Catalin Roman, pp. 14-23.

The article is probably not as sophisticated and detailed as you'd
like, but it's another summary that might be useful.

----------------------------------------------------------------------
Andy Oram    O'Reilly & Associates, Inc.                [phone]
             90 Sherman Street, Cambridge, MA 02140     [e-mail]

#########################################################################

From: [e-mail] (Mack Alford)

In your posting you write:
>
>Can anyone help with information on methods, tools, techniques, etc
>for analysis of non-functional characteristics (the 'ilities').
>
These issues are under discussion by the CBSE Task force (next meeting will be
held in a couple of weeks in London), and is also addressed by some Systems
Engineering methods and associated tools.  The RDD-100 System Designer deals
with some of these issues (e.g., the data base can be extended to keep track of
budgeted and acutal weight, size, power, reliability, etc), and some of our
customers are trying to tie RDD-100 into issues like ensuring that any 1 or 2
components can fail without failure of the system.  But it is still a
relatively open issue.

Regards,
Mack Alford
Ascent Logic Corporation
[e-mail]

#########################################################################

From: [e-mail] (James Hanlon)

Hi Phil-
        Non-behavioral aspects of systems are very difficult to express
to the satisfaction of most people, in my experience. Why I think is due
to the dependence of peoples' opinions on their personal value systems--
the old "Where you stand depends on where you sit" situation. Since few
technical types are comfortable articulating (or even recognizing the
applicability of) their own, and others' value systems, debates on the
fuzzier topics typically degenerate into unseemly affairs, where otherwise
responsible professionals openly question each others' wit and judgment.
It's much easier to count lines of code, and failed test cases per
reporting period--so that's what happens.

My own analysis along these lines was sharpened last year when I
ran across a book by Robert Flood, "Liberating Systems Theory". I recommend
it. Also, if you are fortunate enough to have access to a competent
logician, or even a garden-variety philosopher, you might try getting
advice on aesthetics.

I think it unlikely that there will be meaningful metrics defined on the
non-behavioral components of a system anytime soon.

Good luck,

Jim Hanlon
[e-mail]

#########################################################################

%From: Pat Place <[e-mail]>

Phil,
We have been looking at a slightly different problem, however, I
think that there is enough similarity to be useful.

We started with the question "How does software get structure?"
Clearly, the design and development of software requires that
the software be structured in some way.  After many discussions
we concluded that it is the non-functional ilities that determine
the software structure and in general, the ilities are all balanced
against the ility of efficiency (or performance if you prefer).

One book that provided some useful information was "Software Quality
Management" by Deutsch and Willis.  It lists various ilities and attempts
to define them in the context of systems.  However, we were really
looking at architectures and are attempting to define these terms
in the context of an architecture rather than a specific system.
One thing that we found was that many of the ilities can only be
identified in terms of a solution rather than anything more abstract.
So, for example, for the security ility, we think, architecturally,
in terms of a security kernel.  For safety, a monitor, for modifiability -
a solution of modularity, etc.

We would like to be able to examine architectures and judge them
according to some criteria, e.g., this architecture is more modifiable
than that architecture.  These statements have to be of a general nature
since it will be possible that within any architectural style that
exceptional systems may be constructed (either particularly good or bad).

Our progress to date has been limited since we have not been working
on this for very long.  However, we may have made some progress.

The problems we are trying to address are:
How can we represent architectures so that they can be analysed?
What analyses can we perform for the ilities?

It is clear that for specific systems, we can analyse for certain properties,
safety comes to mind - use some form of hazard analysis technique
such as fault tree analysis and you can determine whether or not
the system is safe with respect to a list of hazardous conditions.
However, it is not so clear that we can perform the same analysis
over the space of architectures.

We are currently thinking about the issue of modifiability, and are
starting to arrive at some statistical notions of modifiability based
on a particular representation of the system in terms of its modules.

One point that comes out of much of this is that the architecture
arises from a desire to localise information with repsect to a particular
ility - there is no need to do this from the functional viewpoint and
a non-locaslised system may be just as secure as a system where all
secure information is held in one place, however, it will be harder
to analyse the latter system than the former.

I hope that the above may be of some use - I am sure that there are
points that I have attempted to make and probably done poorly - also
points that I have omitted since they were intermediate steps in the
thinking of the group.  So, please feel free to ask me to explain
further any or all of the above.

Pat

#########################################################################

%From: Terry Rout <[e-mail]>

You ask (in comp.software-eng):

> Can anyone help with information on methods, tools, techniques, etc
> for analysis of non-functional characteristics (the 'ilities').
>                 ^^^^^^^^^^^^^^

There are two sources you should look at: first, the book "Software Quality
Engineering" by M.Deutsch and R.Willis gives a methodology for developing
quality specifications.  Secondly, there is a Standard, ISO9126, which has a
good amount on specifying and measuring quality characteristics.

There is a paper in a BCS Conference Report, SE90, which deals with this
issue, but at the moment I can't remember its title or the author!  Will
follow up if you are interested.

Regards,

Terry Rout

=====================================================================
*  Terry Rout                                [e-mail]   *
*  Software Quality Institute                                       *
*  School of Computing and                                          *
*      Information Technology                                       *
*  Griffith University                        TEL: [phone]   *
*  Queensland  4111  AUSTRALIA                FAX: [phone]   *
=====================================================================

#########################################################################

%From: [e-mail] (Andrew Blyth)
%Subject: Re: Help with non-functional characteristics?

In article <[e-mail]>,
[e-mail] writes:
> Can anyone help with information on methods, tools, techniques, etc
>for analysis of non-functional characteristics (the 'ilities').
>                ^^^^^^^^^^^^^^

You want to take a look at some of the work that has been done on the
ORDIT project. ORDIT is an espirit project. If you send me your mail
address then I will reply mail you (snail) some stuff.

Hope that the info  helps

Andrew.

________________________________________________________________________
                             Andrew Blyth
                           Research Associate
Department of Computing Science       Tel [phone]
The University                        Fax [phone]
Newcastle Upon Tyne. NE1 7RU.
England.                              Email [e-mail]
________________________________________________________________________