Hey—You know that spreadsheet you have been keeping for the last 15 years about Non Functional Requirements?  You know the one—With references to uptime, Recovery Objectives, and user counts?

In a cloud environment, many of these NFRs are just plain irrelevant.   For example, Point in time Restore (PITR) makes older discussions about Recovery Point Objective and Recovery Time Objective seem like we might be talking about reading the TV Guide to learn when the Ed Sullivan show is on.   It just dates us.  Elasticity and Scalability can more or less handle changes in user loads instantaneously, (as long as the budget is there, and the options are selected).

However, now that we have solved these problems, there are new considerations that we need to manage for in NFRs.   Not surprisingly, not all cloud providers will tell you about some things that you need to ask for or check on.   Whether you are moving an enterprise application to the cloud or considering a SaaS application, NFRs still matter.

In no particular order, you probably want to consider these points in your updated, cloud hosted NFR document.

• Performance and reliability metrics and testing still matter, and should be tested with analogous loads and user scenarios. If you are doing this now, keep doing it, adjusting the tools needed.  For the record, we happily use Locust as one of our go-to tools.

• Data Residency. Where is your cloud (processing, storage, and anything else) physically going to reside?  Will it be located in the same country you are in, and applicable to the regulations you expect?  Or will it be hosted somewhere that doesn’t respect GDPR, California CCPA, FedRAMP or other applicable regulations?

• Can you “exit” your data to a different cloud storage environment as you wish? Let’s call this factor  “Data Portability”.    Along these lines, how do you access your data, whether you exit or not?  (Note—You really, really want to test this out, prior to fully committing to a vendor)

• How much notice will the cloud hosting company provide you with before planned outages or maintenance? Not naming names here, but in our experience some providers show little concern about announcing outages or dealing well with cleaning up the mess they can leave behind after maintenance.   Some cloud providers even fail to count “scheduled maintenance” against downtime, even if their data center is on fire.

• Highly related—Most cloud providers offer some sort of security as a service add on, and you will probably want it. But, it would be good to know exactly what their “Armor” actually covers—and what it doesn’t.

• You will likely be asked by somebody about cost predictability in your NFRs. This may or may not be a big deal, but nobody likes surprises.  You want to at least ask the question about how stable your pricing will be, even with potential elastic changes in loads or users.

Bottom line—We all actually need to think about NFRs more now.  At the very least, we need to update our spreadsheets, but perhaps more importantly, we need to creatively think about how to avoid treating this as just a rote piece of busywork.