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.

when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects. Credit: Jamsoft

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

Copied 2022 06 from: https://github.com/freemansoft/Non-Functional-Requirements

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 Capability	NFR	Policy or Goal
Automated deployment and smoke test after every build	?	Yes
Services include health check endpoint to verify status	Yes	?
Support fully automated deployments in all environments	?	Yes
Auto restart apps on health check failure	No	Yes
Exercise APIs on regular basis to verify health	No	Yes
Health check dashboard UI	No	Yes
Distribute SLA goals and metrics on a regular basis	No	Yes
Components require a runbook that describes triage	No	Yes

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 Capability	NFR	Policy or Goal
Testable code	Yes	Yes
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

• Wikipedia
• Scaled Agile Framework

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.

Site	Category Type	Individual Category
Wikipedia	Execution	safety, security and usability
Wikipedia	Evolution	testability, maintainability, extensibility and scalability
Modern Requirements	Operational	Access/Security, Accessability, Availability, Confidentiality, Efficiency, Integrity, Survivability, Reliability, Usability
Modern Requirements	Revisional	Maintainability, Modifiability, Flexibility, Scalability, Verifiability
Modern Requirements	Transitional	Portability, Reusability, Interopability, Installability
Scaled Agile Framework	Not Grouped	Security, reliability, performance, maintainability, scalability, and usability
A Guide to NFR types and examples	Not Grouped	accessibility, 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.

Category	Sub-Category	Requirement Definition	Possible Implementation (opt)	Validation Method
Top-level Categories from a Taxonomy.	One or two word requirements name	Description of requirement	A suggested implementation or organizational standard	How 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.

Category	Sub-Category	Requirement Definition	Possible Implementation (opt)	Validation Method
Maintainability	Unit Testing	All code modules must have full unit tests coverage	X Unit for testing and Sonar results coverage	Review 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 Definition	Possible Implementation	Validation Method		(Meter)	Metric Units (Scale)	Metric (Target)	Metric Failure (Constraint)	Metric (Current)
Top Level Categories from a Taxonomy.	One or two word requirements name	Describing the requirement	A suggested implementation or organizational standard	How the NFR implementation is validated		Metric calculation	metric value type	Target value for metric	Failure value for metric	Current 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