Non Functional Requirements - NFRs - in Software Systems

NFRs are requirements that do not relate to business functionality. They relate to attributes like reliability, efficiency, and portability.




Non Functional Requirements are architecturally significant requirements because they impact the system architecture. They are properties of a system that sit outside of specific business features or functionality. NFRs are sometimes called constraints. Other times they are called Quality Attributes. Constraints generally change the shape of architecture or design.

Capturing NFRs early is part of a shift left where we surface the non-business value needs earlier in the process. Non-functional requirements impact the system as a whole and are cross-cutting across business features.

Project efforts really need to be explicit about capturing their NFRs and updating them. Everyone has been on projects where some technical requirement was forgotten which resulted in a non-supportable application or a slew of audit findings.

On Github

On youtube



NFR or Not an NFR

NFRs are defined by architecture or designers and are implemented by the delivery teams. Policies exist to meet organizational needs.

Teams need to be diligent about knowing the difference between an NFR that drives system design and organizational policies or guidelines. NFRs drive changes in system design. Policies tend to change the way people operate or maintain the systems. You can especially see this where NFRs overlap for certain parts of CI/CD like continuous testing.
Function or CapabilityNFRPolicy or Goal
Automated deployment and smoke test after every build?Yes
Services include health check endpoint to verify statusYes?
Support fully automated deployments in all environments?Yes
Auto restart apps on health check failureNoYes
Exercise APIs on regular basis to verify healthNoYes
Health check dashboard UINoYes
Distribute SLA goals and metrics on a regular basisNoYes
Components require a runbook that describes triageNoYes
Software source metrics and other design-time metrics feel like a grey area. They are part of a group's software development policies. They don't explicitly drive software architecture but can influence it. We only get unit-testable code by writing unit tests and checking coverage. At the same time, test coverage targets, code complexity targets, and other code metrics feel like development best practices and not NFRs.

Function or CapabilityNFRPolicy or Goal
Testable codeYesYes
100% unit test coverage?Yes

NFR Definitions

This document describes one way of organizing NFRs for consumption by delivery teams. This format is designed to present NFRs at a glance. Those requiring more details in their NFRs should choose a different format.

References

Various NFR Taxonomies

NFR taxonomies often group related NFRs into Categories or Qualities. Categories may have Sub-categories to help with organization. There are many different published NFR taxonomies. The following table links to a few.
SiteCategory TypeIndividual Category
WikipediaExecutionsafety, security and usability
WikipediaEvolutiontestability, maintainability, extensibility and scalability
Modern RequirementsOperationalAccess/Security, Accessability, Availability, Confidentiality, Efficiency, Integrity, Survivability, Reliability, Usability
Modern RequirementsRevisionalMaintainability, Modifiability, Flexibility, Scalability, Verifiability
Modern RequirementsTransitionalPortability, Reusability, Interopability, Installability
Scaled Agile FrameworkNot GroupedSecurity, reliability, performance, maintainability, scalability, and usability
A Guide to NFR types and examplesNot Groupedaccessibility, accountability, accuracy, adaptability, administrability, affordability, agility, auditability...

I couldn't find many Sub-Category examples so sub-categories in the sample below are ad-hoc, locally homegrown.

Generic NFR Attributes Template

Some teams create a set of NFRs in a table to make them easier browse. Each row in the table is an individual NFR. Each column is an attribute of the NFR.

This table has 5 columns. There is 
  1. The category/sub-category.
  2. The NFR definition and implementation.
  3. A method for validation that the NFR is implemented
We get something like the following when using a tabular definition format.
CategorySub-CategoryRequirement DefinitionPossible Implementation (opt)Validation Method
Top-level Categories from a Taxonomy.One or two word requirements nameDescription of requirementA suggested implementation or organizational standardHow the NFR implementation is validated

Example NFR with Generic Attributes Template

The following is a common NFR on most projects. It contains a simple 5 column structure.

CategorySub-CategoryRequirement DefinitionPossible Implementation (opt)Validation Method
MaintainabilityUnit TestingAll code modules must have full unit tests coverageX Unit for testing and Sonar results coverageReview coverage results

Scaled Agile Framework Aligned (SAFe) Template


SAFe adds metrics to the NFR attributes listed above. SAFe metrics drive or support Key Performance Indicators (PKIs). We use those metrics to determine project success beyond the app is up

SAFe additional attributes are something like:Name of the KPI.
  • The current KPI value
  • The target KPI vale
  • The failure KPI value below which its pretty bad

See the SAFe web site for the meanings of these fields. https://www.scaledagileframework.com/nonfunctional-requirements/
  • Labels in (parenthesis) are Scaled Agile Framework aligned.
Category(Sub-Category)Requirement DefinitionPossible ImplementationValidation Method(Meter)Metric Units (Scale)Metric (Target)Metric Failure (Constraint)Metric (Current)
Top Level Categories from a Taxonomy.One or two word requirements nameDescribing the requirementA suggested implementation or organizational standardHow the NFR implementation is validatedMetric calculationmetric value typeTarget value for metricFailure value for metricCurrent metric value

Current NFR list

NFRs have been captured in tab-delimited format NFRs.tsv in the Generic Template format.
They are stored in Tab Separated format .tsv which is previewable on GitHub. Open NFRs.tsv with a CSV/TSV viewer.

You can find a sample list of NFRs in the Generic Template format in a TSV file in this repository.

NFRs.tsv


Created 2022 06 

Comments

Popular posts from this blog

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

Accelerate Storage Spaces with SSDs in Windows 10 Storage Pool tiers

Java 8 development on Linux/WSL with Visual Studio Code on Windows 10