Nonfunctional Requirements

The categories presented below are detailed in Roxanne Miller’s book The Quest for Software Requirements. The 14 categories presented in the book, along with 5 additional categories, are explored in the on-demand course, Nonfunctional Requirements.
Receive a FREE Nonfunctional Requirement Category quick-reference job aid
when you share your examples! Click the button below to get started.

Yes, I have examples to share!

NONFUNCTIONAL REQUIREMENTS DEFINED

Photo Source: Technology Builders Inc (TBI)

Nonfunctional requirements are vital to the success of software systems. If they are not properly addressed, undesirable results occur such as unsatisfied users, developers, and clients, and schedule and budget overruns to correct the software that was developed without the nonfunctional requirements in mind.

Inconsistent terminology, confusing definitions, and the absence of a universally accepted classification scheme make understanding nonfunctional requirements a challenge. As presented in chapter 4 of The Quest for Software Requirements, the following simplified definition is used in the context of this site:
Nonfunctional Requirement – a specification of how well a software system must function.

In addition to alternative names such as quality attributes, quality requirements, and non-behavioral requirements, nonfunctional requirements also have been referred to by nicknames such as ILITIES and ITIES. These nicknames are derived from adjectives that end in the suffix ILITY, which are commonly used to describe the desired nonfunctional characteristics. Furthermore, nonfunctional requirements are referred to by the acronym NFR.

No doubt also stemming from inconsistent terminology and confusing definitions, we cannot agree on how to spell these important requirements. Is it non-functional or nonfunctional? This may be quite trivial to many, but it is still an indication of the lack of uniformity.

USER-FOCUSED NONFUNCTIONAL CLASSIFICATION

Nonfunctional requirements can be classified based on the user’s need for software quality. Addressing a user concern will necessitate the formulation of a number of functional requirements, but the user concerns will also act to constrain other requirements that are characteristic of nonfunctional requirements.

In order to apply a user-focused approach, it is necessary to understand who the user is. The software user is any person who comes into contact with the software system. User contact with the software system might occur in the following ways:

OPERATION, or using the functionality. This user perceives the system as an electronic tool that helps to automate what would otherwise be done manually. From this point of view, the user is concerned with how well the system operates.

REVISION, or changing source code or data that drive the system. The user perceives the system as a set of programmed language statements. These statements are treated as a problem that must be solved. The system must be analyzed, modified, and tested as problems arise, or the business changes the way it operates.

TRANSITION, or managing the upkeep of the system. From this point of view, the system carries similar characteristics as hardware. That is, the user is concerned with aspects such as packaging, transport, and compatibility with other systems.

Based on the user-focused approach, nonfunctional categories can be classified into three requirement groups:

OPERATION Requirements

Operation requirements define how well the software system performs for use by the user. While functional requirements describe what tasks the system is to perform, the operation requirements describe how well the system performs the tasks.

Nonfunctional categories included in the operation group are access security, accessibility, availability, confidentiality, efficiency, integrity, reliability, safety, survivability, and usability.

REVISION Requirements

Revision requirements define how efficiently the software system can be corrected or fixed when errors occur, and how easily new features can be added.

Nonfunctional categories included in the revision group are flexibility, maintainability, modifiability, scalability, and verifiability.

TRANSITION Requirements

Transition requirements describe the ability of the software system to adapt to its surrounding environment.  Users who come in contact with the software system by managing the upkeep of the system are generally most concerned with transition requirements.

Nonfunctional categories included in the transition group are installability, interoperability, portability, and reusability.

WANT NONFUNCTIONAL REQUIREMENT EXAMPLES?

Nonfunctional Requirement Examples

Hundreds of examples of nonfunctional requirement statements are assembled into an 8-page PDF. This compilation is included with the course downloadable materials in the on-demand course Nonfunctional Requirements.

View Course Details

LOOKING FOR A NONFUNCTIONAL REQUIREMENTS TEMPLATE?

Nonfunctional Requirements Definition

This FREE, editable MS WORD template is available in the TOOLS and TEMPLATES page under RESOURCES.

View Tools and Templates

NEED SUGGESTED ELICITATION QUESTIONS?

Software Requirements Questions

This download product is an editable, easy-to-use Microsoft Excel® file of the 2,000+ questions presented in Roxanne Miller’s book, The Quest for Software Requirements. The Requirements Quest Framework™ organizes the suggested questions into six areas of focus (Data, Roles, Purpose, Timing, Logistics, and Process) and two perspectives (Supplier and Receiver). With an editable file you can sort and filter the questions according to your needs; change the wording to suit your personal style; create customized interview guides that you can reuse from project to project!

View Product Details

WANT TO LEARN MORE?

Nonfunctional Requirements (On-Demand)

This is the ultimate nonfunctional requirements course! Upon completion you will be able to apply a user-focused approach and classify 19 common nonfunctional requirement categories into 3 groups, as well as access hundreds of written nonfunctional requirement examples.

This in-depth course is designed for anyone seeking to improve their ability to:

  • Reduce the risk of missing nonfunctional requirements
  • Collaborate with others to develop nonfunctional requirements
  • Apply a user-focused approach to eliciting nonfunctional requirements
  • Represent nonfunctional requirements in any development environment such as waterfall and agile
  • Understand factors that contribute to challenges in eliciting nonfunctional requirements
View Course Details

Operation Requirements Group

The OPERATION group describes the user needs for a system that performs or functions well. The operation group subdivides into the following nonfunctional categories:

Access Security — how well the system is safeguarded against deliberate and intrusive faults from internal and external sources.
Accessibility — how easily people with the widest range of capabilities can use the system.
Availability — how dependable the system is able to function during normal operating times.
Confidentiality — how well the system protects sensitive data and allows only authorized access to the data.
Efficiency — how well the software system handles capacity, throughput, and response time.
Integrity — how well the data are maintained by the software system in terms of accuracy, authenticity, and without corruption.
Reliability — how well the software system consistently performs the specified functions without failure.
Safety — how well the system prevents harm to people or damage to the environment.
Survivability — how well the software system continues to function and recovers in the presence of a system failure.
Usability — how easily the user is able to learn, operate, prepare inputs and interpret outputs through interaction with a software system.


Access Security

DEFINITION: Access Security is the extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.

ELICITATION: Access security requirements address the user concern for how well the system is safeguarded against unauthorized access. When eliciting access security requirements, consider needs regarding user registration, user authorization, and user authentication.

EXAMPLE: [Forgotten password] Students may request a temporary password, and shall receive a link sent to their primary email address.


Accessibility

DEFINITION: Accessibility is the extent to which the software system can be used by people with the widest range of capabilities to achieve a specified goal in a specified context of use.

ELICITATION: Accessibility requirements address the user concern for how easy the system is to use by people with varying capabilities. When eliciting accessibility requirements, consider aspects related to legislation and standards, and specific needs such as visual, hearing, cognitive, and mobility.

EXAMPLE: [Accessible by people who are hard of hearing] All course lessons will provide a text alternative to audio content.


Availability

DEFINITION: Availability is the degree to which users can depend on the system to be up (able to function) during “normal operating times.”

ELICITATION: Availability requirements address the user concern for how dependable the system is during normal operating times. Consider the following needs when eliciting availability requirements: downtime impact on the business, partial availability impact on the business, transparent unavailability, and minimizing unavailability.

EXAMPLE: [Quarterly website upgrades] Routine software upgrades shall be applied no more frequently than once every three months, and whenever possible shall be installed while the RQ Website is active.


Confidentiality

DEFINITION: Confidentiality is the degree to which the software system protects sensitive data and allows only authorized access to the data.

ELICITATION: Confidentiality requirements address the user concern for how well the system protects sensitive data and makes it available to authorized users. When eliciting confidentiality requirements, consider aspects related to access control, privacy of communication channels, input interfaces, and secure storage of sensitive data.

EXAMPLE: [No sensitive cardholder retention] The RQ Website will not retain customer credit or debit card information entered during the Checkout payment processing.


Efficiency

DEFINITION: Efficiency is the extent to which the software system handles capacity, throughput, and response time.

ELICITATION: Efficiency requirements address the user concern for how fast the system functions, how efficiently the system takes in inputs and processes outputs, and how much can be processed at a time. When eliciting efficiency requirements, consider needs regarding response time, throughput, process capacity, and storage capacity.

EXAMPLE: [Video load time] All course lesson videos should load in 2 seconds or less.


Integrity

DEFINITION: Integrity is the degree to which the data maintained by the software system are accurate, authentic, and without corruption.

ELICITATION: Integrity requirements address the user concern for the accuracy and authenticity of the data. When eliciting integrity requirements, consider needs regarding routine backups of data to prevent loss, backing up data to multiple locations, data restore procedures, and authenticity of data with respect to the original data source.

EXAMPLE: [Data backup] Customer orders shall be backed up at least once per month to prevent data loss.


Reliability

DEFINITION: Reliability is the extent to which the software system consistently performs the specified functions without failure.

ELICITATION: Reliability requirements address the user concern for the system’s immunity to failure. When eliciting reliability requirements, consider needs regarding possible causes of system failure, preventative actions or procedures necessary to avoid failure, failure classes, and reliability metrics.

EXAMPLE: [Probability of Failure on Demand] The RQ Website probability of failure on demand (POFOD) shall be 0.0001 (1 out of 10000 plays) when a student requests to play a course video.


Safety

DEFINITION: Safety is the degree to which a software system prevents harm to people or damage to the environment in the intended context of use.

ELICITATION: Safety requirements address the user concern for how well the system protects people and the environment from harm. When eliciting safety requirements, consider aspects related to hazard avoidance, hazard detection and removal, and minimizing the damage if an accident occurs.

EXAMPLE: [Operation monitoring] The Medication Monitoring System shall not dispense doses of medication that are greater than maximum amount prescribed by the physician.


Survivability

DEFINITION: Survivability is the extent to which the software system continues to function and recovers in the presence of a system failure.

ELICITATION: Survivability requirements address the user concern for the system’s resilience from failure. When eliciting survivability requirements, consider needs regarding failure detection techniques and fault recovery techniques.

EXAMPLE: [Update failure detected] When an update failure is detected all updates performed during the failed session shall be rolled back to restore the data to pre-session condition.


Usability

DEFINITION: Usability is the ease with which the user is able to learn, operate, prepare inputs and interpret outputs through interaction with a software system.

ELICITATION: Usability requirements address the user concern for ease of learning and using the system. When eliciting usability requirements, consider needs regarding ease of entry, ease of learning, ease of handling, likability, and possible metrics.

EXAMPLE: [Downloads are easy to access] Students shall have the option to download course materials when viewing a course lesson or the course overview.

REVISION REQUIREMENTS GROUP

The REVISION group describes the user need for a system that is easy to correct when errors occur, and is easy to add on new functions. The revision group comprises the following nonfunctional categories:

Flexibility — how easily the software can be modified to adapt to different environments, configurations, and user expectations.
Maintainability — how easily faults in the software system can be found and fixed.
Modifiability — how easily changes to the system can be developed and deployed in an efficient and cost effective manner.
Scalability — how well the software system is able to expand its processing capabilities upward and outward to support business growth.
Verifiability — the extent to which tests, analysis, and demonstrations are needed to prove that the software system will function as intended.


Flexibility

DEFINITION: Flexibility is the ease in which the software can be modified to adapt to different environments, configurations, or user expectations.

ELICITATION: Flexibility requirements address the user concern for how easy it is to modify the system to work in different environments. When eliciting flexibility requirements, consider aspects such as organizational differences, industry differences, country differences, and whether the software system will be used at a single site or multiple sites.

EXAMPLE: [Pre-viewable course lessons] The RQ Website shall allow multiple course lesson videos within a specific course to be pre-viewable (played prior to purchasing the course). When a new lesson video is added it shall by default be non-viewable (video cannot be played unless the course is purchased).


Maintainability

DEFINITION: Maintainability is the ease with which faults in a software system can be found and fixed.

ELICITATION: Maintainability requirements address the user concern for how easy it is to upkeep and repair the system. When eliciting maintainability requirements, consider aspects such as maintenance performance metrics, maintenance support features, system maintenance features, system complexity, development process, maintenance process cycle, and possible problems.

EXAMPLE: [Mean preventative maintenance time] The mean preventative maintenance time on applying routine plug-in updates to the RQ Website shall be less than 30 minutes every 2 weeks.


Modifiability

DEFINITION: Modifiability is the degree to which changes to a software system can be developed and deployed efficiently and cost effectively.

ELICITATION: Modifiability requirements address the user concern for how quickly and cost effectively changes can be made to a software system. When eliciting modifiability requirements, ask the following questions to understand how changes affect the system:
• What can change?
• How likely is a change?
• When is a change made?
• Who does the change?
• What is the cost of the change?

EXAMPLE: [Course page content] RQ Website course marketing pages shall be editable in Cornerstone. The rationale for this requirement is that the RQ Admin can make simple course content adjustments without developer assistance.


Scalability

DEFINITION: Scalability is the degree to which the software system is able to expand its processing capabilities upward and outward to support business growth.

ELICITATION: Scalability requirements address the user concern for how easy it is to expand or upgrade the system’s capabilities. When eliciting scalability requirements, consider aspects such as ability to cope with increasing processing load, expanding business locations, recycling hardware to minimize waste, and possible causes for degradation.

EXAMPLE: [Student scalability] The RQ Website shall be scalable to accommodate unrestricted growth in the number of students taking on-demand courses. (The roll out of corporate memberships will not restrict growth or negatively affect website performance.)


Verifiability

DEFINITION: Verifiability is the extent to which tests, analysis, and demonstrations are needed to prove that the software system will function as intended.

ELICITATION: Verifiability requirements address the user concern for how easy it is to show that the system performs its functions. When eliciting verifiability requirements, consider Verification and Validation techniques that might be used, possible inspection checks, and installability of the system.

EXAMPLE: [Parallel course launch] One or more courses shall be loaded and launched from a neutral party’s website. This parallel launch will help to verify the audio and sound quality of all course lesson videos.

Transition Requirements Group

The TRANSITION group describes the user need for ease of adaptation to changes in the technical environment. The transition group includes the following nonfunctional categories:

Installability — how easily the system can be installed, uninstalled, or reinstalled into a target environment.
Interoperability — how well the software system is able to couple or facilitate the interface with other systems.
Portability — how easily the software system can be transferred from its current hardware or software environment to another environment.
Reusability — how easily a portion of the software system can be converted for use in another.


Installability

DEFINITION: Installability is the ease with which a software system can be installed, uninstalled, or reinstalled into a target environment.

ELICITATION: Installability requirements address the user concern for how easy it is to install, reinstall, and uninstall a software system. When eliciting installability requirements consider aspects such as installation process, people who will perform the install, configuration of the target platform, and types of software.

EXAMPLE: [Plug-in upgrades] Installation of plug-in upgrades shall leave all website content and administrator settings unchanged.


Interoperability

DEFINITION: Interoperability is the extent to which the software system is able to couple or facilitate the interface with other systems.

ELICITATION: Interoperability requirements address the user concern for how easy it is to interface with another system. When eliciting interoperability requirements consider aspects such as software testing, product engineering, industry partnership, standard implementation, and common technology.

EXAMPLE: [Video interface] There shall be a clearly defined interface between the RQ Website and an external video host system. Its purpose is to stream course lesson videos.


Portability

DEFINITION: Portability is the ease with which a software system can be transferred from its current hardware or software environment to another environment.

ELICITATION: Portability requirements address the user concern for how easy it is to transport the system. When eliciting portability requirements, consider aspects of portability with regard to data, program, end-user, and developer documentation.

EXAMPLE: [Device independence] On-demand course lesson videos shall be viewed by students from multiple operating systems including Microsoft Windows, macOS, and Android.


Reusability

DEFINITION: Reusability is the extent to which a portion of the software system can be converted for use in another system.

ELICITATION: Reusability requirements address the user concern for converting the software for use in another system. When eliciting reusability requirements, consider aspects of feasibility of software reuse, possible areas for reuse, and development standards.

EXAMPLE: [Frequently Asked Questions] The functionality for frequently asked questions on the RQ Website overall may be reused on frequently asked questions related specifically to on-demand courses.

Do you have a good story to tell?

Get a FREE job aid!

Have you ever had a software development project fail or product go horribly wrong?
If so, we would love to hear your story.

Receive a FREE Nonfunctional Requirement Categories quick-reference job aid when you share your story. Click the button below to get started.

I want to tell my story!

DON’T MISS OUT

Join hundreds of other smart people who get tips, tricks,
and new-course announcements delivered right to their inboxes.

SUBSCRIBE NOW