3 A Proposal: NoFun

In this section, we present the main issues of a notation called NoFun following the design principles enumerated in the last section. We classify non-functional information into three kinds:

• Non-functional attribute (short, NF-attribute ): any characteristic of software which serves as a means to describe it and, possibly, to evaluate it. Among the most widely accepted [IEEE92, ISO91] we mention: time and space efficiency, reusability, maintainability, reliability and usability. In our approach, we let arbitrary attributes to appear; so, software components are studied with respect to a particular set of NF-attributes; we say then that the component is characterised by this set.
• Non-functional behaviour of a component implementation (short, NF-behaviour ): any assignment of values to the NF-attributes that characterise the implemented component.
• Non-functional requirement on a software component (short, NF-requirement ): any constraint referred to a subset of the NF-attributes that characterise the implemented component.

The set of NF-attributes that characterise a component, together with their relationships (stated as NF-requirements), are declared in a NF-specification module , which is bound to the component specification. The NF-behaviour of an implementation is stated in a NF-behaviour module , bound to the implementation. Also, NF-behaviour modules will usually include NF-requirements for the software components imported by the implementation. Keeping non-functional information in separate modules gives full independence from the particular specification and programming languages used in the system.