login Register forgot password or username?
Search:         
Cradle from 3SL, the complete Model Based Systems Engineering Toolsuite, specialising in requirements management, requirements capture, model based systems engineering and for systems engineering software, support and consultancy, the logical choice: Cradle from 3SL.

February 2010 [Cradle 6.1]

Non Functional Requirements

User requirements are statements of user need, as expressed by the groups of stakeholders concerned with the system being developed. They address many aspects of the system, some behavioural and some not.

In general, behavioural user requirements are of one of two types: those that specify what is to be accomplished (functional requirements), and those that specify how well the functions are to be accomplished (performance requirements).

Non-functional requirements (NFRs), on the other hand, are often simply a catch-all term for all user requirements that are not explicitly functional. NFRs are sometimes referred to as non-behavioural rather than non-functional to more closely suit the process (e.g. OO-UML).

NFRs occur in many forms, including contractual or commercial statements, compliance with standards, environmental factors to be considered (such as temperature ranges, radiation levels or gradients to be climbed) and perhaps the most intangible (or difficult to address of all), the ilities. The ilities are typically expressions of the emergent properties of the system, the characteristics that its users desire that the system should exhibit once it is complete but which its component parts do not necessarily exhibit, or exhibit differently. They include characteristics such as:

  • Usability
  • Reliability
  • Maintainability
  • Availability
  • Survivability (for combat systems)
  • Flexibility
  • Adaptability

Functional requirements will be the focus of the early design and development work. There are modelling techniques (notations) such as the UML Use Case and Activity Diagrams, extended Function Flow Block Diagrams (eFFBDs) or Behaviour Diagrams, which offer methods for depicting what operations are to be done in time sequence and the control logic that will control the flow of execution.

Treatment of the non-functional user requirements may not be so straightforward. We must first look at the basic types of NFRs:

  • Environment – requirements defining the physical environment (natural and induced) for system operation. In some cases, they may also address the political or economic setting in which the work is done or the system performs
  • Physical – requirements describing the form of the product or system. Examples include specifying the size, shape, paint finish, weight or other similar properties of products or systems.
  • Interface – requirements defining the data, structure and physical form of interfaces between components (hardware, software and people). There may also be a need to interface to existing systems or provide certain standard interfaces. Some requirements analysts classify interface requirements as a separate group, not as a type of NFR.
  • Constraints – requirements prescribing stipulations or limitations on how the system can be built, or how and in what context should other requirements apply. Non-technical aspects such as timeline and budget can also constrain development projects.
  • Quality Factors (Emergent Properties) – requirements that address other quality factors of the product or process, the ilities mentioned above.

A widely-used group of ilities is Reliability, Availability, and Maintainability (RAM) in real-time defence, aerospace, process control, telecommunications and transport systems where the continual correct functioning of the product is important. RAM requirements are threatened by many kinds of risk or circumstance, such as design errors, operator overload or confusion, under-sized hardware and environmental factors (wind, rain, temperature variations, dust storms). These can cause hardware failures, software crashes, and human errors in judgement.

Other NFR ilities include testability, portability/mobility, usability, scalability, flexibility and supportability. Degradation in these or other quality factors incorporated as requirements will lead to system underperformance or failure. Usability can lead to a system being compromised by an operator pushing the wrong button. Poor (or no) storability requirements lead to damage of delicate components; non-adherence to portability requirements may leave the system at the base and not in the field, and so on.

Not all quality factors are ilities in the strictest sense of the word. Requirements addressing security, system integrity and workmanship are important NFRs as well.

It is interesting to note that, while behaviour diagrams and use cases describe the desired system operation and behaviour in functional terms (that is, do this and then do that), the potential negative behaviour or misuses of the system lead to Non-Functional Requirements for protection and endurance.

Note also that NFRs at a high (entire system) level may lead to functions at the lower levels (subsystems or components). For example, a system-level safety requirement to suppress unwanted flames or burning material within a laboratory may lead to a sprinkler subsystem to protect the laboratory as a whole.

A key activity to address NFRs is the defining the physical architecture. One develops the system architecture by:

• Defining the product structure (i.e. the component parts)

• Allocating the required characteristics (e.g. colour, size, weight, MTBF, COTS equipment features) to the components

• Specifying the interfaces between the component parts

This activity ensures that you address both functional and non-functional requirements during the system modelling and design process.

The aim for all analysis of user NFRs is to produce corresponding system NFRs that can be measured and tested and allocated into the system architecture. That is, the aim is to derive a collection of non-functional system requirements that:

• Can be measured

• Can be tested

• Can be allocated to (that is, linked to) the system architecture