ANSWER

There are many different ways to categorize non-functional requirements depending on the type of system, project, organization, or preference.

Here are some common ways of categorizing requirements:

1. Qualities vs. Constraints

Qualities of a System: these are characteristics or properties of a system that the stakeholders care about. These are commonly sub-categorized as: 

• Run-time Qualities: A subset of non-functional requirements, these are generally qualities which describe how well the functional requirements behave/are perceived when the system is being used:
  • usability,
  • configurability,
  • supportability,
  • correctness,
  • availability and reliability,
  • quality of service requirements: performance, response time, latency, etc.
  • security, 
  • fault tolerance, 
  • scalability

• Development-time Qualities: A subset of non-functional requirements, these are qualities of the system, architecture, documentation, and design which have an impact on the effort, ease, and cost of maintaining and changing the system over time: 
  • localizability—ability to make adaptations due to regional differences
  • modifiability or extensibility—ability to add (unspecified) future functionality
  • evolvability—ability to change over time and to integrate and use new technologies
  • composability—ability to compose systems from components
  • reusability—ability to (re)use in future systems

Constraints of a System: these are characteristics of the pre-existing environment within which the new system or solution must operate, such as: legal and regulatory constraints, available development frameworks, target hardware, knowledge and skill of the development team, time and budget, etc.

2. Execution vs. Evolution

Execution requirements: Qualities a system must have which are observable at run time: security, usability, etc.

Evolution requirements: Qualities a system must have which address the nature and structure of the system and which permit a system to be evolved in the future: scalability, extensibility, etc.

3. Many categories: most organizations simply maintain a long list of non-functional requirement categories including but not limited to:

• Accessibility
• Audit and control
• Availability
• Certification
• Dependency on other parties
• Documentation
• Efficiency (resource consumption for given load)
• Effectiveness (resulting performance in relation to effort)
• Escrow
• Extensibility (adding features, and carry-forward of customizations at next major version upgrade)
• Infrastructure
• Legal and licensing issues
• Maintainability
• Operating constraints
• Performance / Response time
• Platform compatibility
• Price
• Quality (e.g. Faults Discovered, Faults Delivered, etc.)
• Reliability (e.g. Mean Time Between Failures)
• Resilience
• Resource constraints (processor speed, memory, disk space, network bandwidth etc. )
• Robustness
• Scalability
• Software, tools, standards etc.
• Stability
• Supportability
• Usability and User Experience

How do you categorize non-functional requirements?