"Non-Functional Requirements" Are Stupid • Dave Farley • GOTO 2025

YouTube Video

Summary

This YouTube transcript is a monologue by Dave Farley, a software development expert known for his work on continuous delivery. In this video, Farley critiques the term “non-functional requirements” (NFRs), arguing that it is a “stupid term” that fundamentally misunderstands the importance and nature of these system attributes. He contends that labeling them “non-functional” diminishes their perceived value and leads to their neglect in software development, despite them often being more critical and complex than “functional” requirements.

Farley starts by highlighting the common frustration with the term NFR, often heard in conversations about software requirements. He points out the Wikipedia definition of NFRs as criteria judging system operation rather than specific behavior and immediately challenges this distinction. Using the example of a trading system requiring millisecond latency, he argues that this is not a secondary quality but a core behavior, as crucial as placing an order itself. He extends this to security requirements, emphasizing that security, responsiveness, and resilience are not “non-functional” but are highly valued by users and can differentiate products.

He suggests that the real difference isn’t about functionality but about the nature of the requirements. “Functional” requirements are often atomic, easily compartmentalized, and individually identifiable. In contrast, “non-functional” requirements are cross-cutting, affecting the entire system or significant parts of it. They are broad properties like resilience and security that cannot be implemented in a single code location. Farley argues that calling them “non-functional” is a “code” for “difficult and cross-cutting,” and this label does a disservice, contributing to problems in teams that underestimate their importance.

Farley emphasizes the misleading nature of the term in planning and prioritization. He posits a scenario where a non-technical person might assume “non-functional” aspects are less important and can be deferred, leading to issues later. He uses the example of building a simple social media system versus the complex, robust systems of companies like Amazon or Twitter, highlighting that the immense effort lies in the “non-functional” aspects – scalability, security, resilience – not just adding new features.

He argues that using the term “non-functional requirements” is a way of avoiding the difficult realities of software development and hiding from the complexity inherent in these cross-cutting concerns.

Moving beyond the critique, Farley suggests a three-part strategy to deal with these complex requirements, which he reframes not as “non-functional” but as fundamental aspects of system design:

1. Model: Develop a model of the system and its requirements, focusing on managing complexity and designing for change. Start simple, addressing basic user needs while deferring detailed decisions on the complex, cross-cutting aspects. This involves thinking ahead about potential difficulties (“crystal ball gazing”) to insulate the system and allow for progress without immediately solving all complex problems. The goal is to gain just enough information to compartmentalize the system effectively.

2. Compartmentalize: Design the system in compartments to defer decisions about these complex qualities. This design should aim to separate concerns so that changes in one area don’t necessitate rethinking all aspects of these cross-cutting requirements. Compartmentalization helps in managing complexity and isolating potential problem areas. He uses the example of separating user account management from message feed delivery in a social media system.

3. Assert: Explicitly assert assumptions about these qualities through testing. If you expect the system to handle a certain load or maintain a specific performance level, write tests to verify these assumptions early on, even for current, smaller scales. These tests act as early warning systems as the system evolves and scales. He uses the example of performance testing for user load, anticipating future scalability needs.

Farley concludes by reiterating that by modeling, compartmentalizing, and asserting, teams can better manage the complexities of these critical system attributes, moving away from the misleading and detrimental term “non-functional requirements” and towards a more holistic and proactive approach to system design. He advocates for continuous discussion and evolution of the system design, treating it as a living model.

Accuracy

Dave Farley’s critique of the term “non-functional requirements” and his arguments about their importance are largely accurate and reflect a widely held sentiment within the software engineering community. Here’s a breakdown of the accuracy of his key points:

• The term “non-functional requirements” is misleading and undervalued: This is a valid and common criticism. Many practitioners find the term confusing and diminishing. The prefix “non-” inherently suggests secondary importance, which is often contrary to reality. As Farley argues, these requirements are often critical to the success of a system and can be far more challenging to implement than feature-based “functional” requirements.

• NFRs are often more important and complex than functional requirements: This is also generally accurate, especially for large-scale, distributed, and critical systems. Scalability, security, reliability, and performance are often the defining characteristics of successful software products in competitive markets. Achieving these qualities requires significant architectural and engineering effort, often exceeding that for implementing specific features. The examples of Amazon, Twitter, and Facebook effectively illustrate this point.

• The distinction between “functional” and “non-functional” is blurry and artificial: Farley’s argument that the distinction is not about functionality but about the nature of the requirement (atomic vs. cross-cutting) is insightful. Many requirements traditionally labeled “non-functional” directly impact the functionality experienced by the user. For example, a slow or insecure trading system functionally fails to execute trades effectively or protect user assets.

• Focusing on “non-functional” as secondary leads to neglect in planning and prioritization: This is a practical observation based on real-world project experiences. If NFRs are perceived as “non-functional” and less important, they are often deferred or underestimated during initial planning, leading to costly rework and potential failures later in the development lifecycle.

• His three-part strategy (Model, Compartmentalize, Assert) is sound software engineering practice: These recommendations align with established principles of good software design and development.

  • Modeling is crucial for managing complexity and understanding system behavior.
  • Compartmentalization (separation of concerns, modularity) is a core principle of software architecture for maintainability, evolvability, and managing complexity.
  • Assertion (testing, especially non-functional testing) is essential for verifying that the system meets its quality attributes and for early detection of issues.

Nuances and Considerations:

• While Farley’s critique is valid, the term “non-functional requirements” is still widely used and understood in the industry. It serves as a category for requirements that are not directly related to specific user actions or features but are crucial for the overall quality and operation of the system.
• The issue is not necessarily the term itself, but rather the misinterpretation and underestimation of its importance. Educating teams about the true nature and criticality of these requirements is key.
• Alternative terms are proposed (like “quality attributes,” “system qualities,” “cross-functional requirements”), but none have achieved universal adoption. The focus should be on clarifying the concept rather than just changing the label.
• While Farley emphasizes the cross-cutting nature, some NFRs can be more localized (e.g., performance of a specific module). The key is to recognize that they are not isolated features but system-wide properties that require careful design and engineering.

In conclusion, Dave Farley’s information in the transcript regarding the limitations of the term “non-functional requirements” and the importance of these system qualities is accurate and well-aligned with expert opinions and best practices in software engineering. His proposed strategies are also sound and valuable for improving software development processes.

Resources

Here are 5 resources that would be helpful to learn more about the subject of “non-functional requirements” and related concepts, building upon Dave Farley’s points:

1. Book: “Software Engineering” by Ian Sommerville (10th Edition or later): This is a comprehensive textbook covering all aspects of software engineering, including requirements engineering. It provides a solid foundation in both functional and non-functional requirements, different types of NFRs (performance, security, usability, reliability, etc.), and techniques for eliciting, specifying, and validating them. Sommerville discusses the importance of quality attributes and how they influence system design.

   • Relevance: Provides a standard, academic perspective on software requirements, including NFRs. Useful for understanding the traditional view and context before appreciating Farley’s critique.

2. Book: “Software Architecture in Practice” by Len Bass, Paul Clements, Rick Kazman (3rd Edition): This book focuses on software architecture and its relationship to quality attributes (which are essentially NFRs). It delves into how architectural decisions impact qualities like performance, security, modifiability, and usability. It also introduces the concept of Attribute-Driven Design (ADD) and architectural patterns for achieving specific quality attributes.

   • Relevance: Directly addresses the “system design” aspect that Farley emphasizes. Explores how to design systems to meet quality attributes and manage cross-cutting concerns.

3. ISO/IEC 25010:2011 - Systems and software Quality Requirements and Evaluation (SQuaRE): This international standard defines a quality model for software products. It provides a structured framework for understanding and categorizing software quality characteristics (e.g., functional suitability, performance efficiency, security, usability, reliability, maintainability, portability).

   • Relevance: Offers a formal and standardized way to think about and categorize “non-functional requirements” as quality characteristics. Useful for a more structured approach to defining and evaluating these aspects.

4. Website/Resource: SEMAT (Software Engineering Method and Theory) - Essence Language: SEMAT is a movement aiming to re-found software engineering based on a kernel of widely agreed elements. Their Essence language focuses on the essential elements of software development, including “Alpha” states related to requirements and quality. Exploring SEMAT resources can provide a more modern and principle-based understanding of software development, moving beyond rigid functional/non-functional classifications.

   • Relevance: Provides a contemporary perspective on software development that potentially moves beyond traditional classifications and focuses on essential aspects, aligning with Farley’s call to rethink the approach.

5. Blog Post/Article: Search for articles and blog posts discussing “Quality Attributes” or “System Qualities” in Software Architecture and Requirements Engineering: A targeted web search will reveal numerous articles and blog posts from practitioners and experts discussing the challenges and best practices related to “non-functional requirements” under alternative names like “quality attributes” or “system qualities.” Look for articles that discuss practical approaches to elicitation, specification, and testing of these attributes.

   • Relevance: Provides practical, real-world perspectives and advice from practitioners. Can offer diverse viewpoints and solutions to the challenges highlighted by Farley and others in the field. Look for articles on platforms like Martin Fowler’s website, InfoQ, or blogs of reputable software architects and consultants.