By Stuart Dee
A debate that comes up frequently in technology circles is that Architects should own non-functional requirements (NFRs) as they play a pivotal role in designing and overseeing systems that need to meet both functional and non-functional aspects. While functional requirements define the specific behaviours or functions of a system—such as user interactions, data processing, and service delivery—non-functional requirements (NFRs) encompass the attributes that shape the system’s performance, security, usability, and scalability.
Defining Non-Functional Requirements
Before delving into the debate, it is important to clarify what non-functional requirements are. NFRs describe system properties or attributes that are not directly tied to specific functions but instead govern how a system performs under certain conditions. Common examples of NFRs include:
Performance: Response times, throughput, and scalability.
Security: Data protection, access control, and vulnerability management.
Reliability: System uptime, fault tolerance, and disaster recovery.
Usability: User interface intuitiveness, accessibility, and ease of use.
Maintainability: Ease of updating, debugging, and modifying the system.
Unlike functional requirements, which are often straightforward, NFRs require careful planning and alignment with the system’s architecture to ensure that the system meets broader business objectives. Given the strategic importance of these requirements, many believe architects should assume ownership of NFRs.
Arguments in Favour of Architects Owning Non-Functional Requirements
Alignment with System Design
One of the strongest arguments for architects owning NFRs is that non-functional aspects are deeply integrated into the system architecture. For example, performance metrics, scalability, and security protocols are all shaped by architectural decisions such as choice of technology stack, data flow design, and resource allocation. Since architects are responsible for making these design choices, it makes sense that they should also ensure the system meets the NFRs. When architects own NFRs, they can prioritise these elements throughout the design phase, reducing the risk of conflicts or last-minute adjustments that could compromise the system’s stability. This ownership ensures that non-functional aspects are not seen as afterthoughts but rather integral parts of the design process.
Holistic View of the System
Architects typically have a high-level, end-to-end view of the system, enabling them to understand how various components interact. This holistic perspective allows them to evaluate trade-offs and balance functional and non-functional needs without compromising the integrity of the system. For example, an architect can optimise performance without sacrificing security or usability by making informed decisions that consider all NFRs. Ownership of non-functional requirements allows architects to create a blueprint that ensures all system components work in harmony to meet performance, scalability, and security targets.
Mitigation of Risks
Non-functional requirements often have a direct impact on the system’s long-term success. Poorly designed NFRs can lead to performance bottlenecks, security vulnerabilities, and costly maintenance efforts. By taking responsibility for these requirements, architects can mitigate risks early in the design process. For instance, security and performance concerns are easier to address when architects incorporate them into the initial system design rather than retrofitting solutions later.
Arguments Against Architects Owning Non-Functional Requirements
Architects are a consumer of NFRs
One of the primary arguments against architects taking sole ownership of NFRs is that non-functional attributes are often influenced by multiple teams. For example, developers contribute to performance through efficient code, operations teams ensure reliability through monitoring and infrastructure, security teams enforce protocols, the business knows how reliable and available the system should be and understand system usage metrics. Placing the responsibility solely on architects may lead to gaps in execution, as architects cannot control all aspects of business decisions, development and deployment. You can consider that architects are consumer of NFRs in the system design but sourced from other stakeholders.
Overburdening Architects
Another concern is that architects may become overwhelmed if they are tasked with owning both functional and non-functional requirements. Given the complexity of modern systems, it can be challenging for a single person or team to balance the myriads of technical and operational concerns that arise during the design. Expecting architects to manage every aspect of NFRs may detract from their ability to focus on strategic, high-level design decisions.
Conclusion: A Balanced Approach
While architects are uniquely positioned to influence system design and ensure alignment with NFRs, full ownership may be impractical in complex, multi-disciplinary teams. Instead, a balanced approach is recommended, where architects lead the definition and integration of non-functional requirements at the design stage, but the NFRS are owned by various other stakeholders. This collaborative model allows architects to guide the system’s overall direction while leveraging the expertise of specialised teams to ensure non-functional requirements are met effectively. In this way, NFRs can be integrated seamlessly into the design process, contributing to the creation of robust, scalable, and secure systems.