Software Quality — Non-Functional Requirements
Software Quality — Non-Functional Requirements
Making software — as with making anything — should be about providing value to real people. To do this you need to service a set of needs and wants that people actually have — whether they know it yet or not!
NFRs are frequently referred to as ‘ilities because they include many concerns which end with ility e.g testability.
Functional requirements are the main things that your software must do to solve a problem for users. Non-functional requirements must be addressed to enable function. They may sound secondary but are always very important and often more important. No distinction is perfect but one way is to think about what software must do vs. what software must be.
It is better to use examples. If we were making a video game then:
Functional requirements
Randomly made up, high level, each functional requirement would need to be more logically categories and broken down much to be worked upon.
- It will be 3D open-world.
- You will be able to customise your character.
- You will be able to crawl, crouch walk, walk, run and jump.
- You will be able to drive vehicles.
Non-functional requirements
- The user must experience a strong story.
- The game must be fun.
- The game must be atmospheric.
- The game must not crash.
- The game must be accessible for all user segments.
Some types of non-functional requirements are addressed as completely separate concerns in isolation and sometimes they are completely woven in to a products function. Avoiding crashes is do to with the internal composition of the game whereas being atmospheric needs to be expressed throughout the games user-facing design. Clearly, some NFRs are very clear and some can be harder to pin down and verify. Being atmospheric (whatever that means) could be the core guiding requirement for this project.
Core Stakeholder Groups
All of the NFR examples provided above are related to users. Obviously serving users is very important and perhaps most important (as companies like Apple and Amazon will attest) but every product and project has other stakeholders which have other interests and come with their own NFRs. This can be another great way to split up requirements so they can be organised and addressed more clearly.
For the rest of this post we will consider many of the most common NFRs organised by stakeholder groups. This can’t be exhaustive or perfect but should give you a lot more to think about NFRs and how you are dealing with them in your projects.
You can chop and change how you think about stakeholder groups and get a lot more granular but this set I feel is always relevant.
- Users — those who will actually use the products or services. They could be customers, they could be workers within an organisation, they could be citizens using public services.
- Workers — in this context I mean anyone who is involved in the development and creation of a product / service.
- Funders — those who are responsible for funding financing the project and their representatives.
- Society — the impacts of your project on the world outside of direct user service.
Non-functional Areas
Every single are and sub-area can be elaborated on much further. This is an overview.
Users
Most NFRs can be easily logically linked back to the user.
User Experience (UX)
More than what the software can do. How is it to actually use?
Does it adhere to good HCI (Human Computer Interaction) principles? Is it as simple as it can be to use? Is it intuitive? Does it conform to common user expectations? If not, do deviations add true value? Or do they just make it confusing? Is it accessible? Are you supporting access for all types of users? This can also be a legal / ethical concern. Is it localised for different geographies? Is it aesthetic?
Is there feature bloat? Do features combine to make a logical whole or are they confusing? Are you deprecating features at a sensible rate?
Are there unexpected feature gaps? Users will have default expectations based on the state of the world and other experiences. You should seek to meet or improve on these. If you let users perform an action then they should always be able to undo the action or perform the opposite action.
Is there support? Are there different ways to access support? Are there FAQs and user guides? Is the support good? Are there blogs and examples? Are there communities around the product? Is there a clear way of communicating to users? Are there ways to enable productive feedback?
Can you handle those more mystical UX NFRs which depend on the project. If you’ve decided the product should be fun? Is it fun?
Reliability
Is your product functioning as expected and available for users whenever they want to use it?
Are defects minimal? Are they being managed? Do you have good testing processes? Is it stable? Do changes cause problems?
Have you done effective capacity planning in line with usage expectations. Can the software scale above this if needed? Is it highly available? Is it redundant and resilient to failure in normal circumstances? Do you exhibit graceful failure modes? Are there elements of self-healing? Can you recover in the event of a disaster?
Operability
Is the architecture clearly documented? Are there guides to perform common operational actions? Is it clear how to make changes? Is there clear build, deploy and test automation for quality control? Is there a regular cadence of patches, upgrades and releases? Do you have the right tools to support problem investigation?
Does it exhibit good standards of evolution. Is it maintainable, extensible, modular, portable, idiomatic, debt-managed?
Observability
Are all aspects of the product visible? Is it clear how the system is being used? Do you have live feedback? Can you analyse historic data? Do you have automated monitoring and alerting of events? Are changes auditable.
Performance
Are you meeting or exceeding industry standards for performance? Can you show this quantitively? Are you making the right architecture, design, algorithm choices at each level of the stack? Are you caching across the stack. Are you considering parallelism and concurrency? Dependencies and locking? Does it work the same at scale?
Security
Are users and their data safe? Is your organisation safe? Failures here can cause user harm, reputational damage and bottom-line damage also affecting funders and causing legal, ethical and compliance issues.
Workers
We need to recognise that Humans are the most important element of the systems that we build. Nothing works without them. Organisations need to serve their key stakeholders — their workers. Take every opportunity you can to create the best environments possible.
Increase compensation, safety, flexibility, support, agency, empowerment, opportunity, learning, fun.
Decrease confusion, stress, pressure, unreasonable expectations / workload / boundaries.
See DX (Developer Experience, DevEX) and HumanOps.
Funders
Project development has costs. Someone is bearing these costs and tolerating the risk. They will obviously want the project to be successful but will need to apply various guardrails. These types of requirements are often called constraints and come in various forms.
Constraints
Time
Is there a timeline for the project? Are there deadlines and what are the consequences of needing to move the deadlines?
Cost
What budget is available? Nowadays there are often internal capabilities to help improve cost efficiency. See FinOps.
Resources
What people and resources will be needed? Are they available? Can they be obtained on time within cost?
Other
You are always constrained by physics, the current state of technology and other laws and standards. Another common constraint could be something like being required to use a certain tool or framework because the organisation has invested in it and has a lot of reusable assets.
Society
The wider society also has interests in software projects. These requirements usually regard the externalities outside of direct value to users.
Many products are designed to capture user attention leading to addictions which have negative effects on peoples lives. Media platforms expose users and minors to illegal content and misinformation because they can not effectively enforce age restrictions and can not moderate reliably in real time at scale. For any individual product what are its supply-chain ethics for the components that it depends on? All who contribute to societal ills — even accidentally — have a responsibility to contribute to solve them.
You must also be compliant with laws and industry regulations at all times in all regions in which the product operates. These are mostly meant for user service and safety. Some are truly important and some seem arbitrary but you must comply all the same.
Balance
This can be a lot to consider but like it or not every single project has a multitude of functional and non-functional concerns. It is better to make them explicit and manage them properly over time.
Balance (whatever that ends up meaning to you) should be a top level objective because it is easy to see that different stakeholders and different user groups can want things which are in conflict to different degrees.
Even when everyone wants the same thing you need to deal with opportunity cost. A team can only deal with so many things at a time. With each choice you make you are choosing to not do the other things that you believe are important.
The key is to understand what is good enough for your short and long term goals in each area and prioritise and balance accordingly.
