Ten years ago, to this day, I had an idea to redress how my team considered and approached their Non-Functional Requirements such as Performance. I got the team to start calling these Cross Functional Requirements to better express what they represented - requirements which cross all the functions we were building. Our team loved the idea and quickly adopted it, and we started to share it within ThoughtWorks.
I’m surprised, and actually really proud how quickly it spread through ThoughtWorks and then to the wider community. I went on an archeology dig to try to remember the sequencing of events, and was blown away with how quickly we switched from calling them NFRs to CFRS (NFRs) to just CFRs. I’m also pretty chuffed that my colleague Sam Newman mentioned me in his successful book Building Microservices: Designing Fine-Grained Systems.
Within this decade I have seen a shift in the priorities of the CFRs for teams. When I coined the term, the CFR that concerned teams the most was the Performance of their systems. But with the rise of cloud computing, improvements to computer hardware, Moore’s law and a change in how we architect systems towards Single Page Javascript Apps and microservices, I don’t see too many teams with the same degree of concern. These improvements to our computing resources, however, have also made systems more vulnerable to attacks, and bad actors are able to use the same computing improvements to gain unprecedented access. With the rise in the number of attacks on our systems, I am now seeing more teams shift their focus towards being concerned around the security of their systems.
Regardless of whether teams are focusing on Performance or Security, or another of the 30+ -ilities, I always think it’s pretty cool and very proud when they refer to them as Cross Functional Requirements.