Jump to content

User:FunnyPocketBook/Non-functional requirement

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Manouk Sirag (talk | contribs) at 21:38, 24 January 2023. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. [1] 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.[2] 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[3].

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 [1].

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

  • 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. [1][5]
The behavioral properties that the specified functions must have, such as performance, usability. [1]
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. [1]
A requirement that describes not what the software will do, but how the software will do it is called a nonfunctional requirement (NFR)[5]
Describes a restriction on the system that limits our choices for constructing a solution to the problem. [5]
Properties or qualities the product must have to facilitate its functionality. [5]

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 elicitation or compliance with regulations. [6]

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[5], or according to the IREB: "A requirement concerning a result or behavior that shall be provided by a function of a system.".[2] They capture the intended behavior of the system.

Some relations between FRs and NFRs are shown in the table below.[7][8]

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 sub-categories of NFRs typically consist of quality attributes and constraints.[1][2][9] Another way of dividing NFRs into constraints, security, efficiency, reliability, functionality, and usability/utility. [10]

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.[2][11] These attributes are characteristics that describe the system's behavior, performance, or other aspects that are not directly related to the system's functionality. Examples of quality attributes include reliability, availability, maintainability, scalability, security, and usability.[12][13] These terms fall under the "ilities", which are used to describe the desired system properties.[14] Quality attributes are critical in requirements engineering as they affect the overall performance, dependability, usability, and security of the system.

Find the references for these again :)

  • 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 (all possible ways of implementing a piece of software with all the requirements) beyond what is needed to fulfill the functional and quality requirements.[2] 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.[10] Since any requirement technically limits the solution space (and thus could feasibly be classified as a constraint), 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.

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[15]. 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. [16]

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. [16]

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

References

  1. ^ a b c d e f Glinz, Martin (October 2007). "On Non-Functional Requirements". 15th IEEE International Requirements Engineering Conference (RE 2007): 21–26. doi:10.1109/RE.2007.45. ISSN 2332-6441. Retrieved 13 January 2023.
  2. ^ a b c d e IREB, CPRE. "IREB CPRE Glossary". CPRE Glossary - CPRE - IREB – International Requirements Engineering Board. IREB. Retrieved 13 January 2023.
  3. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
  4. ^ Mairiza, Dewi; Zowghi, Didar; Nurmuliani, Nurie (22 March 2010). "An investigation into the notion of non-functional requirements". Proceedings of the 2010 ACM Symposium on Applied Computing: 311–317. doi:10.1145/1774088.1774153.
  5. ^ a b c d e Adams, Kevin MacG (2015). Nonfunctional requirements in systems analysis and design (1 ed.). Cham: Springer Cham. pp. 46–51. ISBN 978-3-319-18344-2. Retrieved 24 January 2023.
  6. ^ Franch, Xavier; Glinz, Martin; Mendez, Daniel; Seyff, Norbert (1 September 2022). "A Study About the Knowledge and Use of Requirements Engineering Standards in Industry". IEEE Transactions on Software Engineering. 48 (9): 3310–3325. doi:10.1109/TSE.2021.3087792. Retrieved 24 January 2023.
  7. ^ "Functional vs Non Functional Requirements". GeeksforGeeks. 28 April 2020. Retrieved 24 January 2023.
  8. ^ "Functional vs Non-Functional Requirements [Updated 2021]". enkonix.com. Retrieved 24 January 2023.
  9. ^ Habibullah, Khan Mohammad; Horkoff, Jennifer (September 2021). "Non-functional Requirements for Machine Learning: Understanding Current Use and Challenges in Industry". 2021 IEEE 29th International Requirements Engineering Conference (RE). IEEE. doi:10.1109/re51729.2021.00009.
  10. ^ a b Rashwan, Abderahman; Ormandjieva, Olga; Witte, Rene (July 2013). "Ontology-Based Classification of Non-functional Requirements in Software Specifications: A New Corpus and SVM-Based Classifier". 2013 IEEE 37th Annual Computer Software and Applications Conference. IEEE. doi:10.1109/compsac.2013.64.
  11. ^ Wiegers, Karl E. (1999). "Writing Quality Requirements" (PDF). Software Development. 7 (5): 44–48.
  12. ^ Barbacci, Mario; Klein, Mark H.; Longstaff, Thomas A.; Weinstock, Charles B. (1995-12-01). "Quality Attributes". Fort Belvoir, VA. {{cite journal}}: Cite journal requires |journal= (help)
  13. ^ Offutt, J. (2002). "Quality attributes of Web software applications". IEEE Software. 19 (2): 25–32. doi:10.1109/52.991329. ISSN 0740-7459.
  14. ^ Sunday, D.A. "Software maintainability-a new 'ility'". Proceedings., Annual Reliability and Maintainability Symposium. IEEE. doi:10.1109/arms.1989.49572.
  15. ^ "Nonfunctional Requirements". Scaled Agile Framework. Retrieved 22 January 2023.
  16. ^ a b Jarzębowicz, Aleksander; Weichbroth, Paweł (2021). "A Systematic Literature Review on Implementing Non-functional Requirements in Agile Software Development: Issues and Facilitating Practices". Lean and Agile Software Development. 408: 91–110. doi:10.1007/978-3-030-67084-9_6.