Non-functional are used in all fields of application of software
engineering to capture the difference between design and
implementation. In an Open network management design, we want to avoid
specifying the engineering elements that are actually part of a
particular vendors design freedom.
-
Performance
A contract for a service such as a communications system, will often
state a desired and required performance levels. Hence it is
paramount to manage this aspect of the system.
-
Data volumes
The size of files, length of terminal sessions, quantity of
video/audio information, etc. etc.,
-
Throughput
The dynamics of the flow of data determine the needs of a function for
processing power. If, for some reason, that function cannot be replicated or
distributed then the total throughput may have to be handled at one point. It
is possible that a bottle-neck which limits total system performance may
result.
-
Response time
Interactive systems must have a respectable response time. Systems
that involve process control must have very timely performance.
Matching such a need to an appropriately reduced
processing capability may result in significant cost reduction of the system.
-
Error rates
Errors are inevitable. The failure of a system to
produce correct results must be matched to the importance of the result and
the impact of the error. The probabilities and sources of error must be known
so
that proper account of them may be taken in the system design.
Managing error rates is less dynamically important in modern
networks, but is still key in some critical situations.
-
Availability
The percentage of time that a system is actually available (rather
than just perceived by a manager to be available) must be managed.
Very high availability has an exponentially increasing cost. The cost
must be balanced with the requirements of the enterprise.
-
Location
It will often be a requirement that certain functions be located at specific
sites .This may be for reasons of performance, particularly if remote access
would
mean, for example, the transfer of very large volumes of data, or of security,
minimizing the risks that key information is not tampered with or accessed
without authority.
-
Autonomy
Ensuring that a sub-system which performs a specific set of functions can
stand alone if it should ever become isolated can be advantageous. Again
robustness of the total system can be improved, upgrades made simpler and
security enhanced.
The Internet, for example, owes a great deal of its success to the
relatively large degree of autonomy in its sub-systems.
-
Human Computer Interaction requirements
Different functions support different human roles. The requirements for the
interaction between the users and the function must therefore be specified
along with the function itself. This can then be translated into an
appropriate MMI design, taking into account the related functions, the skill
base of the staff and the ever present factor of cost.
-
Security of the management system
The information held within a could be misused in a number of ways.
Knowledge of the equipment configurations could be of commercial value to
competitive suppliers as well as the obvious risk of malicious changes to
customer files, for example.
Control of access to functions is one aspect of security but authentication of
users, tamper-proofing of data and physical security are others.
Where the management sub-system relates to charging, the requirement
for security is obvious.
-
Physical environment
It may often be necessary to locate sub-systems in particular sites. For
example, first line maintenance tools may best be co-located with the exchange
equipment being supported. For these reasons and many others the
environment of the equipment hosting the functions may be constrained. This
must be known to the designers.
-
Support
All sub-systems will require some degree of support. This applies to hardware,
software and data (including knowledge). Some forms of support will be
routine, others unpredictable, for example to correct a malfunction or to
update a capability. Both the general requirements for and any special
provisions to be made for support must be stated.
-
Rate of system change
It may be important to know that some functions will be updated or reviewed
frequently. Specific provision for this could significantly reduce the
lifetime of the system.
-
Legislation
It is quite possible that legislation may dictate the way in which certain
management functions are presented and made available. It may not be
permitted to combine certain functions in order to ensure the adequate
protection of data while making access available to information to meet
mandatory requirements.
-
Business constraints
The way in which the organisation which owns the network or offers the
service is structured and operated may affect the way in which functions are
presented and combined. For example, access by sales staff, where
permissible, may be needed. A help desk would require wide access to
information but the business may dictate that a support system treat
data as read-only.
-
Existing investment
New systems may be required to work with older systems or to reuse
hardware which has been released by system changes and upgrades so that
investment is preserved. This would impact the design and potential capability
of the desired management functions.
-
Migration
It is rarely feasible to install major management systems from scratch. They
have to coexist with older systems. They may have to take over some but
perhaps not all of the functionality of those existing systems in such a way
that impact on the operation of the organisation is minimized.
This will impact both the choice of equipment and also the way in which the
system is designed in order to interface more easily with older systems which
are to remain in operation.
-
Cost
The cost of implementing features and functions has been mentioned
repeatedly. Clearly cost/performance tradeoffs will always have to be made. If
any specific limits on the cost of a particular sub-system exist this is vital
information for the designer.