When we talk about non-functional requirements we often focus on performance and response times. But there are many other types of non-functional requirements and their obscurity can lead to them being missed.
Here are some non-functional requirements that can get forgotten:
- The capability for upgrading without requiring a re-installation
- Saving of user settings such that they survive a re-installation
- The ability to roll-back a feature without impacting on other features
- Monitoring
- Support for customer services (for example an easy to find version number)
Who creates non-functional requirements?
Non-functional requirements should, as with all requirements, be driven by the Product Owner and stakeholders. This can be problematic, as non-functional requirements are often highly technical. I prefer to think of the setting of non-functional requirements as a joint responsibility between the technical team and the Product Owner.
For the technical team it is important to not only think about non-functional requirements that may have been missed, but also to explain them carefully to the Product Owner. Even the most technical of requirement can usually be translated in to a business value that is understandable by somebody from a non-technical background.
Product development
Let us imagine a product development in non-functional terms.
A product is developed that allows consumers to manage their personal savings. The basic product is built, functionally tested and performance tested at expected production loads.
The product is released and the customers are happy.
After a few weeks some new features are added and a new release is planned. But the technical team realises that it is necessary to uninstall the old version before releasing the new one. And when uninstalled it loses the customers settings. This means that the release has to be accompanied by a guide to doing the upgrade. Some customers aren't happy about the inconvenience.
A week later reports are coming in of a bug with one of the new features. The team looks to do a release with the problematic feature turned off. But they discover that the data stored from this new feature is tied together with other data and to remove the feature will break other functionality. The technical team has to leave the broken functionality in until they can come up with a fix which takes several weeks. Again, the customers are unhappy.
In hindsight the technical team should have spoken to the Product Owner in the early stages of the development.
Questions that could have been asked
- Is this product a one-off or will it likely grow in to something else?
- Do you anticipate the need for frequent upgrades?
- Should it be possible to switch off features independently?
These kinds of questions are a joint responsibility of the development team and the Product Owner. It may well be that adding a small amount to the initial development will save a lot of time and cost later on.