Requirements for software products or information systems can be divided into two large groups. These are: 

  • functional requirements (describing what needs to be implemented in a product or system, including what actions users should perform when interacting with them);
  • non-functional requirements (describing how a system or software product should work, and what properties or characteristics it should have).

In various sources and manuals, you can find many different types of non-functional requirements. In this article, we will consider the most common:

  • performance and scalability;
  • portability and compatibility;
  • reliability, availability, maintainability;
  • safety;
  • localization;
  • usability.

Performance and scalability

Performance determines the response rate of a software product to a given workload. Most often, this is the accounting of all active users and the timeout for the target operation, for example, rendering a page.

Scalability is the ability of a product to handle an increased operations volume without any restriction.

Let’s measure

Desktop and mobile speed load time

Google’s PageSpeed Insights analyzes the content of a web page and offers solutions that will speed up it’s loading. This is especially important if you are setting landing page requirements, as Google may rank your page according to its speed.

Response time

According to recommendations of PageSpeed Insights, response time should take no more than 0.2 seconds. This observation is based on a person’s ability to stay focused. When loading lasts 1 second, the user will already notice a delay. At a 10-second threshold, the user’s attention is lost with a 100% probability.

Measurement scenario

It is necessary to analyze this indicator since text, images, and videos load at different speeds.

Current workload

The loading changes depend on the number of users. For instance, the website has 3000 users during the day and 500 at night. You can evaluate these figures as 2 different scenarios or set a maximum threshold.

Third-party APIs

When calculating, exclude the time you need to load them. This is not your area of responsibility.

Architectural constraints

Sometimes performance is limited by an outdated system, so increasing it without redoing everything is almost unreal.

Portability and compatibility

Portability determines how actions performed within one system will be implemented in another. Also, this parameter determines the ease of interaction of various systems.

Compatibility ensures that, for example, software and antivirus software running on the same operating system can coexist.

Today, these parameters are a must-have for all web applications. It is quite simple to determine compatibility and portability. 

Let’s measure

Using analytics tools, you can evaluate which types of devices, browsers, and their versions are most often used. Each product has a clear description of a supported operating system and hardware. Besides, do not forget to check compatibility with third-party applications.

Reliability, Availability, Maintainability

Reliability is a requirement that describes an application or system behavior in emergencies (for instance, automatic restart, duplicate important data, or backup logic). This indicator is expressed as a percentage of probability. For example, with 90 percent reliability over a month, a product with a 90 percent probability will not face a critical failure.

Availability is an attribute of quality that determines the uptime of an application or system. To determine this parameter, the maximum allowable downtime is usually indicated. For example, a system may be available 98 percent of the time within a month.

Maintainability determines the time required to fix a product or its component, change it to increase productivity or adapt to a changing environment. Like reliability, it can be expressed as the likelihood of repairs over time. For example, if you have 75 percent maintainability within 24 hours, this means that there is a 75 percent chance that the component can be fixed in 24 hours.

Let’s measure

Finance

Analyze how much time you can afford to be unavailable. Bugs happen anyway, so determine for yourself its quantity.

Various load scenarios

Analyze product performance at different loads to understand critical points.

Product lifespan

The longer the product lifespan is the more meaningful it is to work out these aspects.

Security

Security requirements, as a rule, include three broad categories: requirements related to access control, requirements related to working with private data, and requirements aimed at reducing risks from external attacks.

Let’s measure

Specific threats

Identify the threats your product faces in the prevailing number of cases. For example, what kind of attacks took place or what data protection is a priority.

Standards

If your product must meet certain safety requirements, it is best to place them in a non-functional section.

Localization

Requirements for the ability and simplicity of localization of the application contain a list of languages into which it is supposed to localize the application or system. Besides, you need to take into account the local culture, currency, legislation, etc.

Let’s measure

To specify this requirement, you need to conduct market research. 

Be as specific as possible. If there are several options within the box, all should be considered (payment formats, language, or time).

Usability

Requirements for the usability of the system/application (from the user’s point of view) and requirements for the convenience and simplicity of the support. The consulting company Nielsen Norman Group identifies 5 parameters for evaluating usability: learnability, efficiency, memorability, errors, and satisfaction.

Let’s measure

Review the old design of your product for errors and flaws in the interface. If you do not have your final product yet, then test a rival product to identify weaknesses. Check the final version of the design first on the prototype, since usability must be installed before development begins.

General recommendations on non-functional requirements 

Your requirements must be measurable and testable. To understand the effectiveness of your quality standards, they must have a quantitative measure.

Apply these requirements not to the whole product, but to its components with which the user interacts directly. Since the limitations of other components can be useless or even harmful because your team will spend much more effort without visible benefits.

Be aware of third-party limitations when using API and the limitations of the system architecture.

Stay tuned for new posts!