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 13:30, 24 January 2023 (fix table). 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 however been significant discussions on what NFRs entail exactly and which types of requirements fall under the term. [1] According to the IREB CPRE glossary, NFRs include both quality requirements and constraints, while functional requirements refer to requirements that concern results or behaviors provided by a function of a system.[2] 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 many different definitions have been used by different researchers and groups. 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, greatly adding to the confusion [1].

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

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

The IREB (International Requirements Engineering Board), who are in charge of the internationally recognised Certified Professional for Requirements Engineering (CRPE) ceritification 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]

Types of NFRs

The sub-categories of NFRs typically consists of quality attributes and constraints.[1][2][6] Another way of dividing NFRs into constraints, security, efficiency, reliability, functionality, and usability/utility. [7]

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][8] 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. Examples of quality attributes include reliability, availability, maintainability, scalability, security, and usability.[9][10] These terms fall under the "ilities", which are used to describe the desired system properties.[11] 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, the ability to make changes to the system without introducing new errors, and the ability to 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, the ability to add new hardware to the system, and the ability to 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, the ability to authenticate users, and the ability to 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.[7] 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. Both quality attributes and constraints are not requirements that can be placed in a normal product backlog as is seen in for example 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[12]. NFRs need to be constantly considered throughout the implementation of other requirements, and they pose a serious risk since errors in NFRs are considered the most difficult and expensive to correct. [13]

There are quite a few factors that can contribute to problems in the final system related to NFRs. Quite some of these can be attributed to simplified documentation techniques which aren't always designed with the unambiguous documentation of NFRs in mind, like user stories and story cards. This is sometimes resolved by keeping a seperate 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, and therefore NFRs might be determined at a late stage in development to be infeasible. [13]

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 continuously monitor the quality of the software.
  • 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 most 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


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 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 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. ^ 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.
  7. ^ 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.
  8. ^ Wiegers, Karl E. (1999). "Writing Quality Requirements" (PDF). Software Development. 7 (5): 44–48.
  9. ^ 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)
  10. ^ Offutt, J. (2002). "Quality attributes of Web software applications". IEEE Software. 19 (2): 25–32. doi:10.1109/52.991329. ISSN 0740-7459.
  11. ^ Sunday, D.A. "Software maintainability-a new 'ility'". Proceedings., Annual Reliability and Maintainability Symposium. IEEE. doi:10.1109/arms.1989.49572.
  12. ^ "Nonfunctional Requirements". Scaled Agile Framework. Retrieved 22 January 2023.
  13. ^ 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.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=User:FunnyPocketBook/Non-functional_requirement&oldid=1135404823"