arch:recommendedpracticeforcapturingnonfunctionalrequirements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
arch:recommendedpracticeforcapturingnonfunctionalrequirements [2021/10/17 17:50] – created vebelaventsevarch:recommendedpracticeforcapturingnonfunctionalrequirements [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 14: Line 14:
  
 In other words, non-functional requirements describe how the system does, while functional requirements describe what. Also, they are called system qualities [3]. The main types of non-functional requirements are performance, availability, security, data retention, usability, stability, compliance, reliability, recoverability, serviceability, data integrity, scalability, capacity, accessibility, and so on [5]. In other words, non-functional requirements describe how the system does, while functional requirements describe what. Also, they are called system qualities [3]. The main types of non-functional requirements are performance, availability, security, data retention, usability, stability, compliance, reliability, recoverability, serviceability, data integrity, scalability, capacity, accessibility, and so on [5].
 +
 ===== How to elicit non-functional requirements? ===== ===== How to elicit non-functional requirements? =====
 +
 First of all, for both functional and non-functional requirements, it is important to identify all the stakeholders. Then analyst should ask all of them to elicit requirements. Some non-functional requirements are implicit by nature, meaning that people assume them to exist without being asked [5]. This is the main difficulty of this process, so it is crucially important to ask all the aspects explicitly because stakeholders may assume that some requirements are obvious. Usually, companies use a list of trigger questions to ensure that important aspects are not forgotten. List of example questions [4]: First of all, for both functional and non-functional requirements, it is important to identify all the stakeholders. Then analyst should ask all of them to elicit requirements. Some non-functional requirements are implicit by nature, meaning that people assume them to exist without being asked [5]. This is the main difficulty of this process, so it is crucially important to ask all the aspects explicitly because stakeholders may assume that some requirements are obvious. Usually, companies use a list of trigger questions to ensure that important aspects are not forgotten. List of example questions [4]:
  
Line 26: Line 28:
   * What data must be saved in case of a disaster?   * What data must be saved in case of a disaster?
   * How quickly after a major disaster must the system be up and running?   * How quickly after a major disaster must the system be up and running?
-  * What is the acceptable system downtime per 24-hour period? +  * What is the acceptable system downtime per 24-hour period?
   * What national, state, or local laws apply to this system, if any?   * What national, state, or local laws apply to this system, if any?
   * What are the projected user growth numbers for the application in the lifetime of the application?   * What are the projected user growth numbers for the application in the lifetime of the application?
Line 53: Line 55:
 [1] Chen Lianping, Ali Babar, Muhammad, Nuseibeh, Bashar, Characterizing Architecturally Significant Requirements, IEEE Software, 2013, pp. 38–45 [1] Chen Lianping, Ali Babar, Muhammad, Nuseibeh, Bashar, Characterizing Architecturally Significant Requirements, IEEE Software, 2013, pp. 38–45
  
-[2] Lightning Cast: Non-Functional Requirements in Agile, Dave Saboe, 2019, https://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/ +[2] Lightning Cast: Non-Functional Requirements in Agile, Dave Saboe, 2019, [[https://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/|https://masteringbusinessanalysis.com/lightning-cast-non-functional-requirements-in-agile/]]
- +
-[3] Nonfunctional Requirements, Scale Agile, 2021, https://www.scaledagileframework.com/nonfunctional-requirements/ +
- +
-[4] Nonfunctional Requirements, UNIVERSITY OF MARYLAND, BALTIMORE COUNTY, https://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html +
- +
-[5] Non-Functional Requirements, KnowledgeHut, 2021, https://www.knowledgehut.com/blog/agile/non-functional-requirements+
  
 +[3] Nonfunctional Requirements, Scale Agile, 2021, [[https://www.scaledagileframework.com/nonfunctional-requirements/|https://www.scaledagileframework.com/nonfunctional-requirements/]]
  
 +[4] Nonfunctional Requirements, UNIVERSITY OF MARYLAND, BALTIMORE COUNTY, [[https://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html|https://www.csee.umbc.edu/courses/undergraduate/345/spring04/mitchell/nfr.html]]
  
 +[5] Non-Functional Requirements, KnowledgeHut, 2021, [[https://www.knowledgehut.com/blog/agile/non-functional-requirements|https://www.knowledgehut.com/blog/agile/non-functional-requirements]]
  • arch/recommendedpracticeforcapturingnonfunctionalrequirements.1634493055.txt.gz
  • Last modified: 2026/08/29 07:59
  • (external edit)