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 18:59, 22 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 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. [1] Another study also shows that there's a split in definitions that show two different broad perspectives about what NFRs should represent.[4]

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

Types of NFRs

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

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][7] 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.[8][9] These terms fall under the "ilities", which are used to describe the desired system properties.[10] 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.[6] 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.

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 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. ^ 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.
  6. ^ 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.
  7. ^ Wiegers, Karl E. (1999). "Writing Quality Requirements" (PDF). Software Development. 7 (5): 44–48.
  8. ^ 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)
  9. ^ Offutt, J. (2002). "Quality attributes of Web software applications". IEEE Software. 19 (2): 25–32. doi:10.1109/52.991329. ISSN 0740-7459.
  10. ^ Sunday, D.A. "Software maintainability-a new 'ility'". Proceedings., Annual Reliability and Maintainability Symposium. IEEE. doi:10.1109/arms.1989.49572.