NFRs and why Kate Bush fans might want to care about them

The example product

To explain this, we’ll need an example product.

What the world needs right now is a social network and microblogging service specifically for Kate Bush fans.

Let’s call it “BigSky”.

Functional requirements

To explain non-functional requirements, we first need to explain functional requirements.

Functional requirements are what your product does - the reason your product exists.

You might see them written in the Connextra format of user stories, like this:

As a Kate Bush fan, I want to be able to post about my favourite songs where other Kate Bush fans exist, so that we can build community around the world’s favourite musician

A user story contains three parts - a user (who is telling this story), a requirement (what do they need or want) and an outcome (what will change meaningfully for them as a consequence of this requirement being met).

User stories are often written from the perspective of the end user - the primary audience of your product, but many other people and systems have stories to tell too, and they might also be functional requirements. For example:

As a shareholder in this company, I need the product to generate more in sales than it costs to run, so that I can get dividends on the company’s profits

This requirement is still a functional requirement because it describes the intended behaviour or functionality of the product.

Non-functional requirements

A non-functional requirement is a requirement for how you achieve the functional requirements, or a condition of success for those requirements that must be maintained.

For example, someone wants to be able to post about their favourite Kate songs, sure. But is it still a good product if they can only do this between 3 and 3.15am on a Tuesday? Probably not. That’s an example of an availability requirement, which is an NFR. It could be written something like:

As a Kate Bush fan, I want to be able to post content on this platform 24/7, because I worry that I will forget my amazing Kate-related content if I have to wait

You might have heard of some of the other NFR categories like observability or cybersecurity. Many of them have names that are long words ending with “ity”, but also some of them don’t… which irks me.

NFRs are important because if they’re not considered early, you may find that you cannot actually deliver the product you wanted at the quality you wanted, because you haven’t budgeted for the NFRs either in time or money.

This is especially true in the era of “vibe coding”. If you ask an AI to help you design some tech, it is rarely going to consider any of the NFRs in its design, as it seeks only to fulfil your request, nothing more.

1. Accessibility

Accessibility - often shortened to a11y because it’s such a long word that there are 11 letters between the a and the y - is the ability for your tech to be accessed by the maximum amount of people. It covers access by disabled people, situationally impaired people, non-native English speakers and more.

BigSky’s accessibility NFRs might include things like:

As a blind or partially sighted Kate Bush fan, I want to be able to use all BigSky’s main features with a screen reader, so that I can be fully included in this community where I belong

or

As a Kate Bush fan who cannot use a mouse, I want to be able to navigate BigSky’s user interface with a keyboard, so that I can still access all the features available to other users

Thankfully, for accessibility we don’t have to write out all the requirements as user stories, because we have WCAG - the Web Content Accessibility Guidelines, which is a standard template set of NFRs that can apply to all web-based applications.

No matter what people selling overlay tools tell you, accessibility is not something you can add to an application after you’ve built it - it has to be designed that way. The good news is, there’s something of a cheat code to designing tech that is easier to make accessible and that’s progressive enhancement. Something that would make a good video or blog post in its own right.

2. Cybersecurity

If you’re in a large organisation, you’ve probably got someone breathing down your neck about this one already.

But cybersecurity is a serious NFR for all web applications, even the smallest and most niche ones. People aren’t necessarily hacking you to get access to your data or your user’s data, they may be intending to use your weak security as a way to get to your service provider or to, for example, send more spam emails. Good security benefits everyone, not just you.

You can write your cybersecurity user stories from the perspective of the attacker, if you like:

As someone who hates Kate Bush because I find her first four albums divisive, I want to gain access to BigSky’s servers, so I can send loads of spam to its users and damage Kate’s reputation

Cybersecurity is tricky because of course you don’t know what you don’t know, which is why it’s important to have people on your team familiar with the OWASP Top 10 security vulnerabilities, and to occasionally get external penetration testers to attempt to hack your tech and report on how successful they were.

As the business owner, I need BigSky to pass an external penetration test every 6 months, so that I know our customers’ data is safe from attackers

3. Information governance

Information governance, or infogov, is ensuring that you are protecting the data involved in your tech - both user data and your own proprietary data - and only revealing it to people who need it.

Designing your application without considering infogov doesn’t just mean you are failing to comply with the law, such as GDPR, but also risks causing serious problems for your users or your business.

As a Kate Bush fan, I want to be able to post about my love of the song There Goes a Tenner safe in the knowledge that non-fans will not find out, so that I can protect my reputation as someone who loves good music

As the creator of BigSky, I want to keep data about the number of users and how much they are paying a secret, so that I can maintain my competitive advantage against BiebNet and other musician-based social networks

Like most of the NFRs on this list, you can’t add this as an afterthought - it has to be considered as part of the design of the application and constantly reviewed through a data protection or information governance policy. Even small-time technology carries great risks if personal data is leaked, so it’s a good idea to take the time to consider carefully how much data you need and how you are going to protect it.

4. Trust & safety

This one often gets sidelined when talking about protecting users, but for many applications it’s actually essential.

Trust & safety is about making as sure as you can that interactions between users on your platform are safe and inclusive. For example:

As someone posting about Kate Bush songs on BigSky, I want to be able to report any messages that respond to my content in a creepy or sexual way and know that my reports are taken seriously, so that I can feel like a safe and welcomed member of the Kate community

Chances are, your proof-of-concept isn’t going to contain any trust & safety features and they may well be an afterthought, but they’re absolutely necessary for any app that contains users interacting with each other, and they can take a long time to build.

Also important to consider is how your application interacts with other people’s trust & safety features: for example, if your application sends emails, your service provider may require you to properly handle people reporting your emails as abusive or spam in their email clients.

5. Reliability & availability

We mentioned availability in the intro, and here I’m going to lump it together with reliability as these are closely related. They refer to making sure your application works reliably and is available when people want to use it.

The NFR we mentioned earlier was:

As a Kate Bush fan, I want to be able to post content on this platform 24/7, because I worry that I will forget my amazing Kate-related content if I have to wait

but these are often worded from a business perspective using “nines” (“four nines” means 99.99% availability, or a maximum downtime of 52 minutes per year).

As the business owner, I want the application to be available 99.99% of any given year, to ensure we do not lose any users who might have paid for this service

As the business owner, I want to make it as easy as possible for users to report bugs, so that we can prioritise fixing them and maximise the chance of users joining or continuing to use our paid services

This might seem obvious from a business perspective, but it’s surprising how often I don’t see people planning for what’s needed to make something available all the time, like it’s somehow too obvious to include in the list of requirements.

What happens if the site goes down on the weekend? Would you even know? Who would bring it back up?

6. Disaster recovery

What would you do if you lost all your data in a fire at the data centre? Restore it from backup? You have backups, right?

Those of us who’ve been in the industry a long time all have a story to tell about the time they entered an SQL DELETE without a WHERE clause or hit enter partway through an rm command and accidentally deleted huge swathes of users’ valuable data. And those of us who were lucky enough to work somewhere with the right guardrails were able to restore that data from a backup.

As a creator of Kate Bush fan art, I want to know my creations are safe when I post them to BigSky, so that I can always find them online when I want to show my friends

And no, don’t ask me for my Kate Bush fan art, although I can point you at some amazing art by other creators!

Having a really well designed backup strategy is key to any product that handles user data. Or any kind of data!

As well as considering what you are backing up and how often you are backing it up, you also need to consider where the copies are kept and - most crucially - how often you do a drill exercise to practise restoring the data. So many organisations back up in the kind of blind faith that it can be restored, without ever actually checking that restoration from the backups is possible!

7. Performance

People with fast internet connections and modern devices expect the products they’re interacting with to be snappy. They don’t often vocalise this need, but people get frustrated if they have to wait more than 0.3-0.5 seconds for something to load. They might even try reloading the page, causing even more traffic to your endpoints.

As a fan browsing the Kate song feed, I want to be always able to see new content within 0.5 seconds of reloading the page, so that I can be sure that the site hasn’t crashed when I am desperate to find out what Kate songs my friends are listening to today

Performance is often overlooked in development, because it isn’t noticeable on fast development machines with small amounts of data and only one end user. But if you have NFRs for performance, you can retrospectively prioritise work to improve this when performance starts to drop below tolerance levels.

It’s also important to consider this NFR when designing system architectures right at the beginning. If your product is going to have many concurrent users, have you considered how you can scale it horizontally? If it’s going to have lots of relational data stored, have you considered how you will be able to scale it vertically in the future?

8. Documentation

Do you know how your application works? Do you understand the class structures, data models and system architectures? Awesome. Now, what about a new person joining the team tomorrow? You’ll explain it to them? Cool. But what happens when you leave the company? What happens when you want to open your API to external developers? How are your support team going to know what the expected behaviour is when a customer reports something unexpected?

As a new engineer at BigSky Inc, I want to be able to get started on designing new features without having to bother the senior engineers all the time, so that the senior engineers can be paid to do more valuable work

The answer, of course, is documentation. Documentation can feel like a massive burden and something no one wants to do, especially if it’s left too late in the process. But without it, you will likely end up wasting huge amounts of valuable time and resources repeating yourselves or digging around for clues in the future, when a decision or specification has been forgotten.

There are a number of shortcuts I like to take to make documentation easier, and I’ll explore them more on my blog or in a future video: they include behaviour-driven development or BDD, and architecture decision records or ADRs, as well as the concept of a “natural team librarian”. If you want to hear more about these, let me know and maybe I’ll prioritise writing about them!

9. Observability

Observability is all about knowing how people are using your product and when things are going wrong. It’s not about spying on your users (well, it can be) but more about ensuring you have all the information about things like crashes and performance issues from people actually using your product.

Normally it requires you to integrate one or more observability tools into your backend (where the logs are) and maybe your frontend too, depending on the scenario. Sometimes the installation of these tools can be quite a small exercise, but it could also require deep integration if you want to collect more useful data or make it easier to search.

Some example observability NFRs:

As a support engineer for BigSky, I want to know if reported customer bugs are one-off occurrences or something affecting multiple people, so that the business can make appropriate prioritisation decisions about fixing them

As an engineer working on a BigSky bug report, I want to know the exact error message experienced by the user and any errors in the logs at the time, so that I can quickly reproduce the issue in my development environment

10. Maintainability

I’ve saved this one for last because, well, you’re not going to like it.

When you think of a product, you might imagine building it and then setting it loose on the world, only returning to fix bugs or add new features.

But the reality is that the various components it is built out of - its dependencies - are constantly being updated too. If you don’t devote energy and resources to keeping up to date with those changes, eventually it will become very hard to maintain as you start getting incompatibilities between older and newer dependencies, or older dependencies fall out of support or get turned off.

A product’s development life is the same as its actual life. If you want to be able to maintain a product, you also have to invest it its maintainability for the duration of its life, and this means having engineers assigned to it at all times, or at least at regular intervals, in order to ensure that it is kept up to date with all of its dependencies.

You might write this requirement as something like:

As the business owner, I want BigSky to always upgrade dependencies within a year of their updates being released, so that I can ensure that it has a sustainable future and does not need to be rebuilt at great cost