How Non-Functional Requirements Help Your Product Succeed

A product (long-term or small, startup, app or web, no matter) is not only about nice features. Its operation is defined by system behavior, which should be documented in non-functional requirements (NFRs). Non-functional requirements (BABOK) or quality attributes (Karl Wiegers) define the product’s capabilities under certain conditions (e.g. malicious activity), help to differentiate the conditions for a system overload and how it is handled, and the recovery process, etc.

There are about 100 NFRs that can be used in different combinations depending on the specifics of a project or situation. We will discuss 10 of them, which a software architect, BA/PO should process with the highest priority on most projects so that a project team can ensure high-quality product delivery.

1. Security is the ability of a system to reduce the likelihood of malicious or accidental activity affecting the system and to prevent disclosure or loss of information.

Here are some examples of how specific Security NFRs may look:

• password should contain 16 characters among them: 1 upper-case and 1 symbol
• personal data should be encrypted when transferred to other services
• Multi-Factor Authentication.

Security may be defined by corporative business rules or established for a specific process. Either way it should be defined and thought through.

2. Capacity defines current system “dimensions”: total number of users, maximum number of users online, number of requests per user, number of transactions (including 3^rd party solutions) per user, etc. However, remember to consider both existing conditions and forecasted, such as the ways in which the system is expected to scale up.

Examples:

• system supports 5 markets with a total of 30,000 users
• 1 request per user per second.

Several years ago we worked on improving a video-on-demand platform of one of our customers who is a provider of video-on-demand services in Sweden. On regular days they had about 100,000 users on the platform per day, but if we stopped at that number we wouldn’t have done a very good job for our customer. This is because during periods of large sport or festive events the number of users increased 10 to 20 times and it reached up into the millions. What I would like you to take from that is meticulous gathering of capacity requirements made a huge impact on this project. If we had found out in the middle of the development process that the capacity of the solution actually needed to be 10 to 20 times higher than we had planned for, that would have resulted in significant delays or problems for the customer.

3. Performance relates to the system’s capacity. But if capacity relates to the requestors measurements, performance can mean the system response time.

For example:

• 95% of all search requests get system responses in 3 seconds or less
• 100% of all payment requests (3^rd party) get responses in 10 seconds.

NB: Third-party solutions may slow down request/response time

4. Availability defines the period of time when the system is operable for the user, it can be described as a percentage range or include a downtime threshold (Service Level Agreement).

Examples:

• the system is available 98% of the day
• the system is available 24/7
• downtime threshold is 2-4 hours and is discussed in advance with customers.

5. Reliability is the ability of a system to continue operating without failure for a given period under predefined conditions.

Example:

• services are monitored and restored after downtime.

6. Backup is the frequency of computer data being copied and stored elsewhere so that it may be used to restore the original after a data loss event. Examples:

• SQL database backups on a daily basis,
• Production could be restored from the latest backup.

7. Compatibility describes operational systems, browsers, and devices on which the solution must be supported.

Examples:

• the product should be supported by Chrome, Opera on Windows, and Safari on MacOS
• the product should have mobile versions for iOS and Android.

8. Data Integrity is the maintenance of data accuracy over its lifecycle. In information security for example, it means that data should not be changed during operations (storage, transition).

Example:

• a user cannot update taxation rates for payments, only the admin has this permission.

9. Maintainability is the ability of the system to sustain changes which could potentially impact components, features, and interfaces. Example:

• the installation of a new version should leave all database contents and all personal settings unchanged.

10. Usability evaluates how easy it is to use the system by an end-user and the level of satisfaction with the user experience.

Example:

• four out of five users should be able to book a guest after reading the user’s guide.

Each NFR should be agreed on with the project team-lead and approved by the client. If you put yourself in the client’s place, you will understand how complicated it is to give a “green light” for something which is not clear. Your client should be aware of many items such as: the importance of regular refactoring as a workaround slows down the system, the necessity of regular (every 6 months) NFR reviews and performance testing, and the necessity of regular technical debt liquidation (tasks can be done in regular sprints or a separate technical sprint could be dedicated to technical debt closure).

Our mission is to explain to clients that the initial product architecture is not the final one. It needs to be changed from time to time. When business grows, system architecture should “grow” as well to meet its needs. Let’s take a simple example: imagine you got married and decided to have a child, so you move into a small apartment. After the first child you suddenly have triplets and find yourself with 4 children. Your initial plan of having a small apartment doesn’t work anymore and you start thinking about a 5-bedroom house. It’s almost the same with software. If you have built a system for 5,000 users, and then get 10,000 more users, the system cannot work without down-time and errors. You will need to change the system architecture accordingly.

Let’s anticipate the fire instead of putting it out.

• #Establishing Quality Process
• #Turnkey Project Outsourcing