NFRs are Hurting the Delivery of Quality Software and Systems Architecture
TL;DR;
The term “Non-Functional Requirements” (NFRs) misrepresents crucial system attributes, leading to undervaluation in project discussions. A terminology shift to “Architecture Compliance” and “Acceptance Criteria” is proposed to better align with the practical essence of system design and user stories. This shift emphasizes the vital role of NFRs in achieving competitive advantage, advocates for a compartmentalized approach to system design, and promotes continuous communication and iterative testing in evolving system architecture to meet both functional and non-functional requirements, thereby delivering quality software and robust systems.
Introduction
In the intricate world of software engineering, the terminology we employ often shapes the perception and value attributed to different facets of system design. One such term, “Non-Functional Requirements” (NFRs), has been a longstanding misnomer that subtly undermines the critical essence of system attributes like security, responsiveness, and resilience. As a seasoned software engineer and systems architect, my journey through various project landscapes has led me to advocate for a paradigm shift in terminology to “Architecture Compliance” and “Acceptance Criteria.” These terms resonate more accurately with the practical essence embodied in system design and user stories, bridging a crucial semantic and conceptual gap in our industry.
Misnomer of Non-Functional Requirements
The label “non-functional” carries an inadvertent sidelining effect, often relegating crucial attributes to the sidelines of project discussions. This misrepresentation could significantly impact the overall system quality and user satisfaction, given that NFRs are frequently more challenging to address compared to functional requirements. Moreover, they play a pivotal role in carving out a unique selling proposition (USP) and competitive advantage for our products and services.
Advocating New Terminology
The transition to “Architecture Compliance” and “Acceptance Criteria” isn’t merely a semantic shift. It’s about aligning our discourse and practices with the true nature of ensuring that systems comply with necessary architectural standards. Embedding acceptance criteria within user stories ensures that each functional deliverable is not only well-understood but also meets the required quality standards, fostering a more robust and practical approach to system design.
Character and Competitive Edge
The essence of NFRs goes beyond mere checkboxes; they shape the character of our products and services. By focusing on delivering a superior quality of service to the end users, we accentuate the architectural “-ilities” like security, resilience, and scalability. These attributes form the backbone of valuable and accurate functional deliverable units, instilling a competitive edge in the marketplace.
Cross-cutting Nature of NFRs
NFRs exhibit a cross-cutting nature, affecting various parts of a system. Their implementation transcends single locations in the code, adding layers of complexity that necessitate a well-thought-out design approach. The interconnectedness of NFRs implies a holistic approach to system design, one that accommodates the multifaceted impact of these crucial attributes.
System Design Approach
An effective system design should aim to satisfy basic user needs while deferring NFR details to manage complexity. A compartmentalized approach not only aids in managing this complexity but also enables easier modifications as our understanding evolves. This flexible design strategy is pivotal in ensuring that the architecture can gracefully evolve over time, adapting to emerging requirements and technologies.
Strategic Handling of NFRs
The strategic trifecta of model, compartmentalize, and assert forms a robust approach towards handling NFRs. By understanding and managing complexity, we keep the design adaptable. Compartmentalizing concerns simplifies the system, making it easier to change. Assertive testing creates a mechanism for validation, ensuring the system evolves in the right direction.
Example of Scalability
A vivid example surfaced during a project involving message delivery in a social media system. A clear differentiation between user preference handling and message feed handling showcased the importance of separating concerns to tackle scalability challenges, embodying the essence of strategic compartmentalization.
Communication and Iteration
Engaging in continuous discussion on design and assertive testing is crucial for spotting and addressing assumption failures. This iterative approach propels the system design evolution to meet both functional and non-functional requirements, fostering a culture of continuous improvement and quality assurance.
Conclusion
The proposed shift to “Architecture Compliance” and “Acceptance Criteria” isn’t a mere play on words. It’s a call to action to realign our industry’s narrative, enriching the conversation around system architecture. This transition fosters a culture focused on delivering quality and value from the inception of a project, ensuring that our terminological precision mirrors the practical and technical intricacies of software engineering and systems architecture. Through this lens, we can better appreciate and address the intertwining nature of functional and non-functional requirements, steering our projects towards success in delivering high-quality software and robust system architectures.
Watch more about
Explore this insightful video, by Dave Farley, that dives deeper into NFRs and their significant impact on achieving architectural brilliance.
