1. Non-functional requirements as Gordian knot
By Oleg Chorny

2. Non-functional Requirements
Non-functional requirements (NFRs) describe system attributes such as security, reliability, maintainability, scalability, performance, supportability, usability, testability, etc. Alternative names: quality attributes, quality requirements, qualities, quality goals, quality of service requirements, qonstraints, non-behavioral requirements, “ilities“, “ities“. Definition and implementation of NFRs is a critical concern for the system builder. Over-specify them and the solution may be too costly to be viable; under-specify them and the solution will not be adequate for its intended use. An adaptive and incremental approach to exploring, defining and implementing NFRs is a key skill to cut the Gordian Knot.

3. Requirements: Functional vs Non-functional
A specification of behavior or function vs A specification of how well a system must function Product Features vs Product Properties Characterized by verbs vs Characterized by adjectives Describe what the system should do vs Describe how the system should behave Clear for business people vs Too difficult to explain to business people Usually, budget is not a problem vs Hard to get a budget for their implementation Work is visible for stakeholders vs Work on NFRs is often invisible

4. Non-functional requirements: Defining Objectives
Access Control, Accessibility, Accountability, Accuracy, Adaptability, Additivity, Adjustability, Affordability, Agility, Auditability, Augmentability, Autonomy, Availability, Capability, Capacity, Clarity, Cohesiveness, Commonality, Compatibility, Completeness, Comprehensibility, Conceptuality, Conciseness, Confidentiality, Configurability, Connectivity, Consistency, Controllability, Coordination Cost, Coordination Time, Correctness, Coupling, Customer Evaluation, Customer Loyalty, Customizability, Decomposability, Degradation of Service, Dependability, Development Cost, Development Time, Distributivity, Diversity, Ease of use, Efficiency, Elasticity, Enhanceability, Evolvability, Execution Cost, Extensibility, External Consistency, Fault Tolerance, Feasibility, Flexibility, Formality, Generality, Human Engineering, Independence, Informativeness, Integrity, Internal Consistency, Interoperability, Intuitiveness, Learnability, Leveragability, Main Memory, Maintainability, Maintenance Cost, Maintenance Time, Maturity, Performance, Measurability, Mobility, Modifiability, Modularity, Naturalness, Observability, Off-Peak Period, Operability, Operating Cost, Peak Period, Performability, Performance, Planning Cost, Planning Time, Portability, Precision, Predictability, Process Mgmt. Time, Productivity, Project Stability, Project Tracking Cost, Promptness, Quality, Reconfigurability, Recoverability, Recovery, Reliability, Repeatability, Replaceability, Replicability, Response Time, Responsiveness, Retirement Cost, Reusability, Risk Analysis Cost, Risk Analysis Time, Robustness, Safety, Scalability, Security, Sensitivity, Similarity, Simplicity, Space Boundedness, Space Performance, Specificity, Stability, Subjectivity, Supportability, Surety, Survivability, Susceptibility, Sustainability, Tankness, Testability, Throughput, Timeliness, Traceability, Trainability, Transferability, Transparency, Understandability, Uniform, Uniformity, Usability, User- Friendliness, Validity, Variability, Verifiability, Versatility, Visibility

5. Non-functional requirements: Defining Objectives
Access Control, Accessibility, Accountability, Accuracy, Adaptability, Additivity, Adjustability, Affordability, Agility, Auditability, Augmentability, Autonomy, Availability, Capability, Capacity, Clarity, Cohesiveness, Commonality, Compatibility, Completeness, Comprehensibility, Conceptuality, Conciseness, Confidentiality, Configurability, Connectivity, Consistency, Controllability, Coordination Cost, Coordination Time, Correctness, Coupling, Customer Evaluation, Customer Loyalty, Customizability, Decomposability, Degradation of Service, Dependability, Development Cost, Development Time, Distributivity, Diversity, Ease of use, Efficiency, Elasticity, Enhanceability, Evolvability, Execution Cost, Extensibility, External Consistency, Fault Tolerance, Feasibility, Flexibility, Formality, Generality, Human Engineering, Independence, Informativeness, Integrity, Internal Consistency, Interoperability, Intuitiveness, Learnability, Leveragability, Main Memory, Maintainability, Maintenance Cost, Maintenance Time, Maturity, Performance, Measurability, Mobility, Modifiability, Modularity, Naturalness, Observability, Off-Peak Period, Operability, Operating Cost, Peak Period, Performability, Performance, Planning Cost, Planning Time, Portability, Precision, Predictability, Process Mgmt. Time, Productivity, Project Stability, Project Tracking Cost, Promptness, Quality, Reconfigurability, Recoverability, Recovery, Reliability, Repeatability, Replaceability, Replicability, Response Time, Responsiveness, Retirement Cost, Reusability, Risk Analysis Cost, Risk Analysis Time, Robustness, Safety, Scalability, Security, Sensitivity, Similarity, Simplicity, Space Boundedness, Space Performance, Specificity, Stability, Subjectivity, Supportability, Surety, Survivability, Susceptibility, Sustainability, Tankness, Testability, Throughput, Timeliness, Traceability, Trainability, Transferability, Transparency, Understandability, Uniform, Uniformity, Usability, User-Friendliness, Validity, Variability, Verifiability, Versatility, Visibility

6. Non-functional requirements: Defining Objectives
Availability Maintainability Performance Recoverability Reliability Response Time Scalability Throughput

7. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable Maintainability The ease with which a system can be modified Performance The speed at which a system operates Recoverability How long it takes to repair a failed component Reliability The ability to function at a specified moment or interval of time Response Time How long it takes to return a response to a request Scalability The ability of a system to handle a growing amount of work Throughput The volume of requests/responses in relation to time

8. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Maintainability The ease with which a system can be modified
Performance The speed at which a system operates
Recoverability How long it takes to repair a failed component
Reliability The ability to function at a specified moment or interval of time
Response Time How long it takes to return a response to a request
Scalability The ability of a system to handle a growing amount of work
Throughput The volume of requests/responses in relation to time

9. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Performance The speed at which a system operates
Recoverability How long it takes to repair a failed component
Response Time How long it takes to return a response to a request
Scalability The ability of a system to handle a growing amount of work
Throughput The volume of requests/responses in relation to time

10. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Performance The speed at which a system operates
Recoverability How long it takes to repair a failed component
Response Time How long it takes to return a response to a request
Scalability The ability of a system to handle a growing amount of work
Throughput The volume of requests/responses in relation to time

11. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Recoverability How long it takes to repair a failed component
Performance The speed at which a system operates
Response Time How long it takes to return a response to a request
Scalability The ability of a system to handle a growing amount of work
Throughput The volume of requests/responses in relation to time

12. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Recoverability How long it takes to repair a failed component
Performance The speed at which a system operates
Response Time How long it takes to return a response to a request
Scalability The ability of a system to handle a growing amount of work
Throughput The volume of requests/responses in relation to time

13. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Recoverability How long it takes to repair a failed component
Performance The speed at which a system operates
Response Time How long it takes to return a response to a request
Throughput The volume of requests/responses in relation to time
Scalability The ability of a system to handle a growing amount of work

14. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Scalability The ability of a system to handle a growing amount of work
Maintainability The ease with which a system can be modified
Recoverability How long it takes to repair a failed component
Performance The speed at which a system operates
Response Time How long it takes to return a response to a request
Throughput The volume of requests/responses in relation to time

15. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable
Reliability The ability to function at a specified moment or interval of time
Maintainability The ease with which a system can be modified
Recoverability How long it takes to repair a failed component
Scalability The ability of a system to handle a growing amount of work
Performance The speed at which a system operates
Response Time How long it takes to return a response to a request
Throughput The volume of requests/responses in relation to time

16. Non-functional requirements: Defining Objectives
Availability The fraction of the time that a system is usable Reliability The ability to function at a specified moment or interval of time Maintainability The ease with which a system can be modified Recoverability How long it takes to repair a failed component Performance The speed at which a system operates Response Time How long it takes to return a response to a request Throughput The volume of requests/responses in relation to time Scalability The ability of a system to handle a growing amount of work

17. Non-functional requirements: Choosing Targets
Availability the number of “nines” in the availability percentage (99.99%) Reliability The ability to function at a specified moment or interval of time Maintainability The ease with which a system can be modified Recoverability How long it takes to repair a failed component Performance The speed at which a system operates Response Time How long it takes to return a response to a request Throughput The volume of requests/responses in relation to time Scalability The ability of a system to handle a growing amount of work

18. Non-functional requirements: Choosing Targets
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability The ease with which a system can be modified Recoverability How long it takes to repair a failed component Performance The speed at which a system operates Response Time How long it takes to return a response to a request Throughput The volume of requests/responses in relation to time Scalability The ability of a system to handle a growing amount of work

19. Non-functional requirements: Choosing Targets
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability The ease with which a system can be modified Recoverability mean time to repair (MTTR) Performance The speed at which a system operates Response Time How long it takes to return a response to a request Throughput The volume of requests/responses in relation to time Scalability The ability of a system to handle a growing amount of work

20. Non-functional requirements: Choosing Targets
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability The ease with which a system can be modified Recoverability mean time to repair (MTTR) Performance The speed at which a system operates Response Time milliseconds ... seconds Throughput The volume of requests/responses in relation to time Scalability The ability of a system to handle a growing amount of work

21. Non-functional requirements: Choosing Targets
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability The ease with which a system can be modified Recoverability mean time to repair (MTTR) Performance The speed at which a system operates Response Time milliseconds ... seconds Throughput requests per seconds Scalability The ability of a system to handle a growing amount of work

22. Non-functional requirements: Choosing Practices
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Performance The speed at which a system operates Response Time milliseconds ... seconds Throughput requests per seconds Scalability The ability of a system to handle a growing amount of work

23. Non-functional requirements: Choosing Practices
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Performance The speed at which a system operates Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

24. Non-functional requirements: Choosing Practices
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Performance Monitoring Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

25. Non-functional requirements: Choosing Practices
Availability the number of “nines” in the availability percentage (99.99%) Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Disaster Recovery Performance Monitoring Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

26. Non-functional requirements: Choosing Practices
Availability the number of “nines” (99.99%) Zero Downtime Deployment Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Disaster Recovery Performance Monitoring Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

27. Product Backlog: Targets as Constraints
Availability the number of “nines” (99.99%) Zero Downtime Deployment Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Disaster Recovery Performance Monitoring Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

28. Product Backlog: Targets as Constraints
Availability a system shall be available 99.99% of the time Reliability mean time between failures (MTBF) shall be more than 4 weeks Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) shall be less than 30 minutes Performance Monitoring Response Time shall be less than 200 milliseconds Throughput a system shall be able to serve 200 requests per seconds Scalability Auto Scaling

29. Product Backlog: Practices as Product Backlog Items
Availability the number of “nines” (99.99%) Zero Downtime Deployment Reliability mean time between failures (MTBF) Maintainability Infrastructure as Code Recoverability mean time to repair (MTTR) Disaster Recovery Performance Monitoring Response Time milliseconds ... seconds Throughput requests per seconds Scalability Auto Scaling

30. Product Backlog: Practices as Product Backlog Items
Availability Zero Downtime Deployment As a Release Engineer I would like deployments to go without noticeable downtime so that application could be deployed any time and as often as we want Maintainability Infrastructure as Code As an Operation Engineer I would like to negate risks associated to human errors and manage infrastructure using the source control so that we can decrease the downtime and increase the reliability of the system Scalability Auto Scaling As a Performance Engineer I would like the application to scale out and scale in automatically depending on the load so that we can cut our costs without the degradation of performance

31. Product Backlog: Practices as Product Backlog Items
Availability Zero Downtime Deployment As a Release Engineer I would like deployments to go without noticeable downtime so that application could be deployed any time and as often as we want Maintainability Infrastructure as Code As an Operation Engineer I would like to negate risks associated to human errors and manage infrastructure using the source control so that we can decrease the downtime and increase the reliability of the system Scalability Auto Scaling As a Performance Engineer I would like the application to scale out and scale in automatically depending on the load so that we can cut our costs without the degradation of performance

32. Product Backlog: Practices as Product Backlog Items
Availability Zero Downtime Deployment As a Release Engineer I would like deployments to go without noticeable downtime so that application could be deployed any time and as often as we want Maintainability Infrastructure as Code As an Operation Engineer I would like to negate risks associated to human errors and manage infrastructure using the source control so that we can decrease the downtime and increase the reliability of the system Scalability Auto Scaling As a Performance Engineer I would like the application to scale out and scale in automatically depending on the load so that we can cut our costs without the degradation of performance

33. Product Backlog: Practices as Product Backlog Items
Availability Zero Downtime Deployment As a Release Engineer I would like deployments to go without noticeable downtime so that application could be deployed any time and as often as we want Maintainability Infrastructure as Code As an Operation Engineer I would like to negate risks associated to human errors and manage infrastructure using the source control so that we can decrease the downtime and increase the reliability of the system Scalability Auto Scaling As a Performance Engineer I would like the application to scale out and scale in automatically depending on the load so that we can cut our costs without the degradation of performance

34. Product Backlog: Practices as Product Backlog Items
Availability Zero Downtime Deployment As a Release Engineer I would like deployments to go without noticeable downtime so that application could be deployed any time and as often as we want Maintainability Infrastructure as Code As an Operation Engineer I would like to negate risks associated to human errors and manage infrastructure using the source control so that we can decrease the downtime and increase the reliability of the system Scalability Auto Scaling As a Performance Engineer I would like the application to scale out and scale in automatically depending on the load so that we can cut our costs without the degradation of performance

35. Implementation Approaches: Constraints
NFRs are modeled as constraints and a part of Definition of Done Team consider NFRs as a part of acceptance criteria for affected user stories. This effectively makes work on NFRs invisible. The odd thing about doing this is that any stories which imply significant architecture work have higher estimates than others but because the architectural piece is below the surface it the estimate belongs to whichever story that gets worked on first. This can be difficult to explain to stakeholders.

36. Implementation Approaches: Technical Stories
NFRs are defined as Technical Stories A way to cover anything that needs to be built or restructured but is too difficult to explain to business people. Often it means that such stories don’t have measurable business value for stakeholders and, as a result, it can be difficult to get a budget for their implementation.

37. Implementation Approaches: User Stories
NFRs are considered as usual User Stories Lots of teams use a user story template like this: As a <user role> I want <goal> so that <business value>. The advantage of managing NFRs this way is that they are visible to stakeholders. Unfortunately, this can also become a disadvantage, if these requirements may be seen by business stakeholders as optional or "nice to have". It’s important to include the "so that" part to make it easy to see why such NFR stories are important from a business perspective to help ensure that they don’t get de-prioritized simply because they are not understood.

38. Implementation Approaches: Testing
In order to know that a system meets NFRs, it must be tested against them. Wherever possible, teams should automate NFRs testing so that these tests can be run continuously, or at least on demand, to help prevent the growth of technical debt. Over time, however, the accumulated growth of regression tests, even when automated, may consume too much resource and processing time. It can mean that NFRs testing may be practical only on occasion. In order to ensure practicality and continuous use, team often needs to create reduced test suites and test data. In all cases, efficiently testing NFRs requires some thoughts and creativity. A lack of NFRs testing, on other hand, may increase the risk of substantive technical debt or, worse, system failure.

39. Summary
Overall, there is no magical Agile practice that helps you uncover NFRs. The first step is to take responsibility. NFRs can be represented as User Stories in order to keep them visible. In order to know that a system meets NFRs, it must be tested against them.