Non Functional Requirements Component Type Applicability

Non Functional Requirements (NFR) define the constraints or the way Functional Requirements are implemented. NFRs are categorized as different types of constraints.  Those categories are great for the enterprise but don't really help determine which NFRs apply in any given Business Feature. One way to remedy this is to create a second type of categorization that identifies which NFRs apply for a given component type, The individual NFRs in a category may only apply to certain deployable types.


Blog (Related):

Classic NFR Categorization

NFRs are generally grouped with related constraints.  You can find a variety of categorization taxonomies with a quick internet search.  From Wikipedia:

Non-functional requirements are often mistakenly called the "quality attributes" of a system. There is a distinction between the two. Non-functional requirements are the criteria for evaluating how a software system should perform and a software system must have certain quality attributes in order to meet non-functional requirements. 
  1. Execution qualities, such as safety, security, and usability, are observable during operation (at run time).
  2. Evolution qualities, such as testability, maintainability, extensibility, and scalability, are embodied in the static structure of the system.

Example: A team may have a set of security NFRs and a set of governance NFRs.  
  • Encryption at rest, encryption in flight and authenticated endpoints are all security NFRs. 
  • Functional Test Coverage and Automated Deployments might all be categorized as Maintainability NFRs.

Component Type Applicability

The standard NFR categories provide a way of grouping related NFRs by type.  They don't provide any simple guide to determining which NFRs apply for any specific Feature.  This means we need to scan the entire list of NFRs whenever we refine a business feature.  We can simplify this by providing a guide as to which NFRs apply in various situations.  We can create a second categorization that groups disparate NFRs by software and control type applicability.  Individual NFRs can be applied to multiple component types or control types. 

Component / Business Feature Applicability

Business Features, in the backlog, typically will be implemented using one or a few technical components and thus component types.  We know the likely constructs at the time of Feature Refinement.  This means we can simplify our NFR Acceptance Criteria in a feature by listing the Component Categories rather than all of the individual applicable NFRs.  We can at least use these Component Categories as the first cut of applicability.


Created 2022 09


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs