Requirements are sometimes described as being part of the FURPS spectrum meaning Functional, Usability (UX), Reliability, Performance and Supportability. The latter 4 types being collectively called non-functional requirements. The spectrum is usually expanded to FURPS+ since there are several more important categories of non-functionals.

Non-Functional Requirements (NFRs) are sometimes considered to be the most important requirements from an architectural perspective, leading some to mischaracterize them as "architectural requirements". This is a misleading approach though as a Product must meet its functional and non-functional requirements to provide business value. If functional requirements are ignored, then an architecture with some impressive mechanisms for dealing with non-functional requirements that doesn't actually do anything is unlikely to be useful as a Product.

Non-functional requirements, sometimes called “-abilities” are requirements that are added on to the functional user needs to represent elements such as (non-exhaustive list):

Often non-functionals are best expressed using tests rather than positive requirements statements. Called “verification over specification” it can be easier to specify non-functional limits rather than exact requirements, for example:

User Story: “As a customer I want to be able to view all of my previous transactions so I can order again and counter fraud”

Acceptance criteria: “All user history queries must display in under 3 seconds”

In this example the non-functional performance acceptance criteria is fairly broadly defined rather than stating that the query must take exactly 2.5 seconds, it’s also written broadly enough to be used as a cross-cutting NFR.

Embedded NFR Criteria

One of the simplest ways of handling non-functionals that apply to specific functional requirements (e.g. a performance requirement on a specific feature) is to embed the non-functional requirement as part of the acceptance criteria. This can be done with any requirement type, as an extra sentence attached to a feature or a set of tests associated with an Integration Scenario or a User Story. Not every functional requirement requires a set of non-functional acceptance criteria.

Cross-Cutting NFRs

Frequently non-functionals are not related to just one requirement but to several, or even the entire system. We call these "cross-cutting NFRs" and represent them in Holistic Software Development as Integration Scenarios, or more specifically as acceptance criteria on Integration Scenarios. This allows for non-functionals to be present on backlogs and explicitly tested and marked as done during integration activities.

Sometimes projects will have significant complexity or risk impact in a non-functional area, such as security. In these cases, we recommend simply adding the high impact non-functionals as non-functional Integration Scenarios or User Stories to the Backlog.

Non-Functionals and Architecture

Non-Functionals are critical in terms of developing an architecture. A very useful tool for understanding complexity across non-functionals (and functional differentiators) is the Architectural Profile.

Architectural Profiling is a method of understanding the relative complexity of different areas of concern for an architecture.

Architecture addresses a number of concerns and so a useful early approach is to consider the profile of the architecture in terms of the relative complexity of each of these areas. This helps to give a feel for the shape of the requirements, architecture and overall solution. We can also identify possible areas in which we can reuse existing components, frameworks or maybe standard packages of requirements, components and tests. Architectural profiles may be useful at any level of architecture (Enterprise, Solution and System) and are useful to understand areas of complexity in the requirements space, especially for understanding the relative complexity of non-functionals.

Although primarily focused on architecture, the Profile can also be used to identify areas for early requirements elaboration based on the complexity of an area, especially if there is a desire to out-source part of the development effort.