User:FunnyPocketBook/Non-functional requirement

In systems engineering and requirements engineering, non-functional requirements (NFR) make up software requirements together with functional requirements. There have been discussions on what NFRs entail, and which types of requirements fall under the term. According to the IREB CPRE glossary, NFRs include both quality requirements and constraints. In contrast, functional requirements refer to requirements that concern results or behaviors provided by a function of a system. NFRs play a vital role in software development since a system that is too slow, unsafe or unusable by certain people is more likely to be rejected. The plan for implementing NFRs is usually provided in the system architecture since both quality requirements and constraints are usually architecturally significant requirements.

Definition

There have been many disagreements on the exact definition of non-functional requirements, and different researchers and groups have used many different definitions. The main difference is in which subcategories are part of non-functional requirements and which are functional requirements; for example, some studies use the term qualities for all NFRs, while others use quality requirements as a subsection of NFRs. There can also be confusion about definitions of components of formal definitions, like quality, property, and constraint. Many different definitions use these terms, but not all of them use the same definitions for these terms, adding to the confusion .

Another study also shows that there's a split in definitions that offer two different broad perspectives about what NFRs should represent:

• NFRs are requirements that describe properties, characteristics or constraints that software must exhibit.
• NFRs are requirements that indicate quality attributes that a software product must have.

The IREB (International Requirements Engineering Board), which is in charge of the internationally recognized Certified Professional for Requirements Engineering (CRPE) certification scheme, created a glossary used in the syllabi and exams for the certificates. This glossary includes the definition mentioned at the start, where a clear distinction is made within NFRs between constraints and quality attributes.

Below is a selection of different definitions found in literature to give an impression of how diverse these can be:

NFR definition
A description of a property or characteristic that a software system must exhibit or a constraint that it must respect, other than an observable system behavior.
The behavioral properties that the specified functions must have, such as performance, usability.
A requirement on a service that does not have a bearing on its functionality, but describes attributes, constraints, performance considerations, design, quality of service, environmental considerations, failure and recovery.
A requirement that describes not what the software will do, but how the software will do it is called a nonfunctional requirement (NFR)
Describes a restriction on the system that limits our choices for constructing a solution to the problem.
Properties or qualities the product must have to facilitate its functionality.

Overall, no definition, or RE standard in general, has been widely accepted by the RE community. In a study performed with individuals with experience working in the RE field, a survey showed that a low number of people knew more than two RE-related standards (42.2%). Even fewer individuals used the standards they did know consistently (14.3%). This same study also identified that contributing factors to these low numbers include that universities don't communicate the existence of these standards and that the standards themselves don't provide adequate support for requirements eliciation or compliance with regulations.

Functional vs non-functional requirements

While NFRs deal with qualities and constraints, functional requirements instead focus on functions that the system or system components must be able to perform, or according to the IREB: "A requirement concerning a result or behavior that shall be provided by a function of a system.". They capture the intended behavior of the system.

Some relations between FRs and NFRs are shown in the table below.

Comparisons

Functional requirements	Non-functional requirements
Helps in understanding the functions in the system	Helps in understanding the performance of the system
Identify what the system must or must not do	Identify how the system should do it
System will generally still work with only these requirements	System won't work at all with only these requirements.
Ensures the system meets user requirements	Ensures the system meets user expectations
Defines the system or a component of it	Outlines quality attributes of the system
Specified what the software system should do	Places constraints on how the software system fulfills the functional requirements
Generally defined at a component level	Applied to a system as a whole

Types of NFRs

The types of NFRs typically consists of quality attributes and constraints. Quality attributes describe how well a functional requirement has to be met and constraints apply restrictions regarding the implementation of a requirement, such as by requiring to adhere to ISO standards.

Simplified example of a requirements taxonomy

Quality Attributes

Quality attributes or quality requirements are measurable properties of a system that describe how well the system meets its functional requirements and are not part of the functional requirements. These attributes are characteristics that describe the system's behavior, performance, or other aspects that are not directly related to the functionality of the system. Quality attributes are critical in requirements engineering as they can affect the overall performance, dependability, usability, and security of the entire system rather than single components within the system.

Examples of quality attributes include reliability, availability, maintainability, scalability, security and usability. These terms fall under the "-ilities", which are used to describe the desired system properties.

• Reliability refers to the ability of a system to perform its intended functions without failure. It is often measured by the system's availability, which is the percentage of time that the system is operational and able to meet its service requirements.

• Availability refers to the ability of a system to perform its intended functions when called upon to do so. It is often measured by the system's uptime, which is the percentage of time that the system is operational and able to meet its service requirements.

• Maintainability refers to the ease with which a system can be modified or maintained over time. This includes aspects such as the ability to diagnose and fix errors, make changes to the system without introducing new errors, and understand and modify the system's code.

• Scalability refers to the ability of a system to handle an increasing number of users or transactions without a decrease in performance. This includes aspects such as the ability to handle increased load without crashing, add new hardware to the system, and distribute the load across multiple servers.

• Security refers to the ability of a system to protect against unauthorized access or attack. This includes aspects such as the ability to encrypt data and communications, authenticate users, and prevent or detect and respond to attacks.

• Usability refers to the ease with which a system can be used by its intended users. This includes aspects such as the clarity of the user interface, the simplicity of the system's navigation, and the ability of the system to meet the needs of its intended users

Constraints

Constraints are limitations or restrictions that are placed on the design or implementation of a system. They are requirements that limit the solution space beyond what is needed to fulfill the functional and quality requirements. Constraints do not have an impact on the external behavior of the system. They can be used to determine the feasibility of functional or quality requirements. Since any requirement could be classified as a constraint, as they limit the solution space, making constraints the last option when classifying a requirement can be a way to distinguish them. This way constraints are limited to requirements that are neither functional nor quality requirements. Examples of constraints are industry standards, laws or organizational processes.

Managing NFRs

All system requirements should be unambiguous and clear in their wording as well as easy to understand, complete and consistent across the entire software requirements specification (SRS). NFRs can be more critical than functional requirements, as users can find a workaround for functionalities that the system has not implemented. On the other hand, unfulfilled or missing FRs can render an entire system unusable. An example of that is inadequate or absent reliability requirements, which can lead to failing necessary safety certifications.

Ideally, the elicitation of NFRs already provides the complete picture of NFRs. However, in practice, that is not always the case. During the writing of NFRs, new information, research, or insights can lead to modified requirements. It is therefore important that revisions of NFRs check for inconsistencies. The following lists provide an example of which key points need to be considered during such a revision.

Karl Wiegers describes six characteristics that individual requirements should have:

• Correctness: Each requirement must correctly describe the desired result. The correctness can be referred to the requirement's source, such as another (functional) requirement.
• Feasibility: The implementation of each requirement must be possible within the capabilities and limitations of the system's environment.
• Necessity: Each requirement should describe a necessity of a stakeholder or adherence of external requirements or standards. One viewpoint of "necessity" is that the source of each requirement should be identifiable as an authority to specify requirements.
• Priority: Each requirement should be assigned a priority to describe how important it is to be implemented for the product release. Should all requirements be identified as essential, it could lead to budget and schedule overruns and newly identified requirements during development cannot be added without complications.
• Unambiguity: Each requirement should be unambiguous in its meaning and allow for only one interpretation. Terms such as user-friendly, easy, fast or efficient should be avoided, as they do not specify a clear instruction. The used language to write the requirement should be appropriate to the reader's domain.
• Verifiability: Each requirement needs to be verifiable, which can be done by writing test cases. Failure of meeting a requirement is reflected in not being able to be verified. Additionally, requirements that are ambiguous or not feasible are also not verifiable. This also calls for each requirement statement to only include one requirement, such that each requirement can be separately verified.

Across all NFRs, there are four characteristics that should be true:

• Completeness: All requirements or necessary information should be covered by the NFRs. Completeness also applies to individual requirements, as it is difficult to find missing requirements.
• Consistency: All requirements must be consistent and may not be in conflict with each other. While disagreements between requirements have to be resolved, it can be that it is not explicitly known which requirements are correct until research has been conducted. Consistency also requires that when changed requirements affect other requirements, these will also be modified accordingly
• Modifiability: In most cases, modifications have to be made to requirements during the revision of the SRS. To facilitate this, each requirement should be labeled with a unique identifier, and a history of changes should be kept.
• Traceability: Each requirement should be linked to its source. The source could be another NFR, a functional requirement or a statement from a stakeholder.

In order to keep the above characteristics for each NFR, groups of NFRs can be created:

• Product requirements: Product requirements define the behavior of the developed system itself, such as reliability, security or usability requirements.
• Organizational requirements: Organizational requirements can be derived from policies and procedures of the client's or developer's organization. Examples include any environmental or development requirements, such as the supported operating system or how the system will be used.
• External requirements: External requirements are imposed from external factors, such as regulatory, legislative and ethical requirements. Examples include laws, industry standards and cultural aspects.

The following is an example of revising a bad requirement.

"The product shall provide status messages at regular intervals not less than every 60 seconds.”

The issues in this requirement are:

• What are status messages?
• How should the status messages be displayed to the user?
• Which part of the product should display the status message?
• "not less than every 60 seconds" could also mean two years
• The wording "not less than every" is confusing and can be improved on

One way of rewriting the requirement is to split it into multiple requirements.

1. Status Messages
   1. The Background Task Manager shall display status messages in a designated area of the user interface at intervals of 60 plus or minus 10 seconds.
   2. If background task processing is progressing normally, the percentage of the background task processing that has been completed shall be displayed.
   3. A message shall be displayed when the background task is completed.
   4. An error message shall be displayed if the background task has stalled.”

Implementing NFRs

Planning the implementation of an NFR isn't always straightforward. Quality attributes and constraints are not requirements that can be placed in a normal product backlog, as seen in agile software development. Instead, NFRs represent limits placed on parts of the system or the entire system. They, therefore, have to be considered in the implementation of one or multiple other (functional) requirements. NFRs must be constantly considered throughout the implementation of other requirements, and they pose a severe risk since errors in NFRs are considered the most complex and expensive to correct.

Quite a few factors can contribute to problems in the final system related to NFRs. Some of these can be attributed to simplified documentation techniques, which can cause misunderstandings regarding NFRs, like user stories and story cards. This is sometimes resolved by keeping a separate document with NFRs, but in practice this makes it more likely that NFRs are neglected in favor of implementing more functionalities. Finally, there's the problem of vagueness when it comes to NFRs. It can be difficult to determine exactly how expensive (in time and cost) an NFR will be; therefore NFRs might be determined at a late stage in development to be infeasible.

There are also methods to make the process of implementing NFRs easier and reduce the risks mentioned above. These include:

• A modified or additional specification technique for NFRs to ensure they don't get forgotten or lost.
• Ensuring an early start on NFRs so that finished code sections don't have to get rewritten later on to ensure NFRs are fulfilled.
• Using an automated monitoring tool like SonarQube to monitor the quality of the software continuously.
• Involve NFR specialists who will focus on ensuring the proper implementation of NFRs.

Examples

Many examples exist for NFRs, both general and domain-specific. A few of the more common and general NFRs include:

• Performance: The landing page when supporting 8.000 users per hour must provide a 4 seconds or less load time from the moment the request is made.
• Scalability: The system must be scalable enough to support 10.000 visits at the same time while mainaining all other requirements.
• Reliability: The system must have no more than 1 hour of downtime in a 3 month period.
• Usability: The system must meet Web Content Accessibility Guidelines WCAG 3.0.
• Security: The database security must meet all HIPAA requirements.

See also

• Software requirement
• Functional requirement
• Requirements engineering
• Requirements management
• Requirement analysis
• Requirements specification
• Use case diagram
• Requirements elicitation
• Software requirements specification