Non Functional Requirements

Objective

Despite (or because) being widely used, the term “non functional” applied to requirements is also associated with a broad range of understandings; to cite a few: qualities of a system that can be specified independently of specific applications; any requirement with no direct impact on functionalities available to users; requirements dealing with how to solve a problem, as opposed to what is to be solved; any requirements which cannot be fully specified and tested under the authority responsible for “functional” ones.

As it appears, most of those understandings provide relative answers depending on who’s asking the question and who’s answering it. To simplify, if business analysts have nothing to say about it, it’s non functional. For instance, even if response time or confidentiality concerns can be elicited through focused discussion with users, associated requirements are usually, but not always, managed by supporting organizational units. Conversely, requirements regarding an encryption service will be seen as functional by the project in charge.

More generally, non functional requirements are best considered within a comprehensive and reasoned taxonomy based on two criteria: on one hand they do not deal with business requirements as such but with the way they are supported by system functionalities; on the other hand they are nonetheless bound to functional requirements and expressed at system boundaries. Looking at non functional requirements from an architecture perspective could provide a more consistent understanding.

Non Functionality is in the Eye of the Beholder

To begin with, non functional requirements seem to cover a wide diversity of situations, defying any consensus about an objective and straightforward understanding: depending on the business under consideration (e.g avionics vs insurance claims processing) requirements like data standards or response time may be seen as regulatory or technical, and consequently classified as functional or non functional.

What is more, the classification may be overlapping, for instance when performance requirements are simultaneously governed by specific business needs (e.g accuracy  for high-frequency trading or missile target acquisition) and computing resources.

Yet, that is not to say that the distinction is arbitrary; on the contrary, it conveys an implicit policy regarding platform dependency: defining elapse time as functional means that high-frequency traders will be supported by their own communication network and workstations, otherwise they will be dependent upon the company technical architecture, managed by a separate organizational unit, governed by its own concerns and policies.

More generally, it’s worth to remind that classifications are conceptual tools designed for a purpose. In that perspective, the functional/non functional classification is meant to put the respective expectations and commitments of business and system analysts on a common track. This distinction may be redundant when only two parties are involved (shared ownership), but it is essential when requirements cross organizational concerns and responsibilities. That is essentially what architectures are about, namely the commons of resources and mechanisms shared by all applications.

Requirements and Architectures

Except for self-contained and standalone applications, requirements are supposed to be abutted to existing systems, and be supported by their resources and mechanisms. While some requirements will be supported by architectures as they are, others may require changes, and those changes should be set along both architecture levels and layers.

Architecture layers are defined according the nature of functionalities:

• Requirements supported by non shared component with transient life-cycle (aka boundaries).
• Requirements supported by shared component with transient life-cycle (aka controls).
• Requirements supported by shared component with persistent life-cycle (entities).

Architecture levels are defined according the nature of concerns and responsibilities:

• Enterprise level : business objects and processes; that’s where requirements about regulations and standards are to be considered.
• Systems level: functionalities supporting business objects and processes; that’s where requirements about externally observable qualities are to be defined, e.g confidentiality and ergonomics.
• Technology level: components supporting systems functionalities; that’s for requirements targeting the qualities of artifacts, e.g scalability and maintainability.

Levels and layers can be combined to define basic requirements footprints.

The first discriminating criterion (shared footprint) coincides with reusable assets and could cover all levels, e.g organizational or regulatory requirements, common business or support services, and communication channels and mechanisms. While this distinction is necessary, it’s clearly not sufficient as it may include as non functional business requirements shared between applications. Introducing a second criterion, namely, non functional requirements are expressed at system boundaries, will get rid of any ambiguity and exclude business requirements. Hence, requirements could be defined as non functional if their execution and functionalities are shared and their realization checked at system boundaries. That can be illustrated with a beverage dispenser:

1. Five options are displayed simultaneously (ergonomics): local execution, no shared functionalities.
2. Intrusion attempts must be detected and recorded (security): shared execution, no shared functionalities.
3. Intrusion alarms must be sent to dispatching (security): shared execution and functionalities (communication channels).
4. Vocal command (ergonomics): local execution, no shared functionalities (assuming a COTS solution).
5. Caloric intakes must be displayed (national regulations): shared execution but specific functionalities.
6. Payment by stored-value cards are accepted (local regulations): local execution, no shared functionalities (assuming a COTS solution).

Requirement 1 will usually refer to non functional aspects regarding implementations of user interfaces; requirements 4 and 6 may entail non functional aspects regarding use of COTS; requirements 3 will probably be associated with some (non functional) constraint on delays; whereas requirements 5 and 6 concern regulations, they don’t put any constraint on shared functionalities.

Non Functional Requirements: a definition revisited

Whatever their use, software systems are computing devices dedicated to the processing of symbolic representations. Yet, their functionalities are not served in a vacuum but within actual contexts represented by human agents, physical equipments, or other systems. It is therefore logical to define functional requirements as those dealing with the symbolic contents exchanged between systems and contexts, and non functional requirements as those not directly associated with specific contents.

Applied to the example above, this definition provides clearer outcomes:

1. No reference to symbolic contents.
2. Reference to symbolic contents: events features must be examined.
3. Reference to symbolic contents: events features must be examined.
4. No reference to symbolic contents.
5. Reference to symbolic contents: specific features must be selected.
6. Reference to  symbolic contents: transactions features must be examined.

Moreover, while the outcomes of the former definition were affected by architecture options, the symbolic / non symbolic criterion can be set independently, prior any decisions.

This reasoning is to be pivotal for the definition of a comprehensive and unequivocal taxonomy of requirements supporting model based software engineering.

Compared to functional ones, and as illustrated above, QoS requirements are meant to be met at operational level, suggesting they would be best defined with regard to architecture capabilities

The alignment of non-functional requirements with architectures capabilities is a key factor for enterprise architectures as it draws the line between what can be owned and managed by business units and what must be shared at enterprise level. That approach would translate into service oriented architectures.

From Non Functional Requirements to Services

As noted above, the distinction between functional and non functional requirement has two objectives: (1) set apart  requirements best-managed as common concerns and (2) measure the benefits brought by system functionalities to business processes.

The first objective put the focus of reuse, the second on architectures, and more precisely on the definition of system perimeters. That may be compared to some kind of gerrymandering, with computing “districts” redefined in order to maximize the reuse of shared functionalities.

That approach is best illustrated by service oriented architectures which would greatly enhance the traceability of use cases combining requirements specific to business units with requirements regarding supporting services:

• First, all requirements under scrutiny must be dealt with uniformly. For instance all time response constraints are to be considered either functional or non functional.
• Second, requirements cohesion must be maintained. For instance, timing constraints should be kept with their fellow functionality.
• Third,  the putative “non functional” requirements still sitting with functional ones should be factored out as standalone service requirements.

As a concluding remark, the alignment of requirements to services would put a specific light on non-functional requirements which should not be seen as a one-fits-all category but be defined by the footprint of business requirements on system architectures.

Further Reading

• Thread
• How to Begin with Requirements
• Focus: Business Analyst Booklet
• Requirements Rounds up
• Requirements Capture
• Requirements Taxonomy
• Requirements & Architecture Capabilities
• Requirements Analysis
• Requirements Threads
• Requirements Metrics Matter
• Use Cases
• Focus: Rules & Architecture
• Requirements Platform
• From Requirements to Function Points
• Focus: Requirements Reuse

External Links

• Non-Functional Requirements – Why Do We Need Them?