 |
| [Image by Alexa from Pixabay] |
The seed for the genesis for this blog post started with a LinkedIn post by Dave Farley, with his link to his recent YouTube video: "Non-Functional Requirements" Are STUPID - and some of our subsequent LinkedIn exchanges (1, 2, 3 - as well as 4, and 5 - which I've incorporated into the initial content for this blog post)
See link to my initial comment on his post, #1:
Possible examples of counter-arguments:
1. Some NFRs are cross-cutting - and should be consistently applied enterprise-wide, across all domains, all applications.
2. Repeating the definitions, in vertical contexts - violates the DRY principle.
3. Enterprise-level NFRs provide a consistent reference - that can be reused across initiatives, products, programs, projects, applications, etc.
4. When categorizing everything as just a "requirement" (with no distinction between technical/NFR vs. functional) - increases the complexity and cognitive load - when trying to get a business stakeholder - to focus on reviewing/approving just the business requirements.
Example:
NFR: "All NPI, PII, PHI, PCI information must be encrypted at-rest, and in-transit, with encryption standards specified in INFOSEC-STANDARD-001."
See link to my follow-up reply, #4:
Oxford English Dictionary (OED):
Functional:
“of or having a special activity, purpose, or task; relating to the way in which something works or operates.“
“designed to be practical and useful, rather than attractive.“
“working or operating.”
Also see ISO 25010
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
https://en.wikipedia.org/wiki/Functional_requirement
(selected citations)
“In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary (or specification or statement) of behavior between inputs and outputs.”
“Functional requirements may involve calculations, technical details, data manipulation and processing, and other specific functionality that define what a system is supposed to accomplish”
“Functional requirements are supported by non-functional requirements (also known as ‘quality requirements’), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). Generally, functional requirements are expressed in the form ‘system must do <requirement>,’ while non-functional requirements take the form ‘system shall be <requirement>.’”
“The plan for implementing functional requirements is detailed in the system design, whereas non-functional requirements are detailed in the system architecture”
“As defined in requirements engineering, functional requirements specify particular results of a system.”
“...contrasted with non-functional requirements, which specify overall characteristics such as cost and reliability.”
“Functional requirements drive the application architecture of a system, while non-functional requirements drive the technical architecture of a system”
“Functional requirements are product features or functions that developers must implement to enable users to accomplish their tasks”
“Nonfunctional requirements, not related to the system functionality, rather define how the system should perform.”
