Non-functional software requirements. Part 1

Introduction

When developing a new information system or introducing an existing one, you inevitably encounter the need to identify non-functional requirements for your system.

In this article I will talk about the following:

what are the non-functional requirements
how to define non-functional requirements
where do the numerical values for non-functional requirements come from.

Non-functional requirements: what are they?

To begin with, the 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) and non-functional requirements (describing how a system or software should work, and what properties or characteristics it should have).
')
As a rule, when speaking of non-functional requirements, it is often said that quality attributes (i.e., requirements that determine the quality characteristics of the software or system being developed, such as performance, reliability, scalability), do not pay attention to other types of non-functional requirements, namely :

Restrictions - conditions that limit the choice of possible solutions for the implementation of individual requirements or their sets. They significantly limit the choice of tools, tools and strategies in the development of the appearance and structure (including architecture) of a product or system.

Examples of restrictions : “Development should be carried out on a vendor's platform X ”, “When authenticating a user, biometric identification methods should be used”.

Business rules are policies, guidelines or regulations that define or limit certain aspects of a business, incl. rules that determine the composition and rules for the implementation of certain business processes. Business rules include corporate policies, government regulations, industry standards, and computational algorithms that are used to develop a product or system, or directly influence development.

Examples of business rules : “When the order is shipped, the manager must ask the accountant for a waybill and an invoice”, “If the payment on the invoice has not been received within 15 days, the order is considered canceled.”

External interfaces - a description of aspects of interaction with other systems and operating environment. These include requirements for a product or system API, as well as requirements for APIs of other systems with which integration is performed.

Examples of external interfaces : “Ensure the following events are recorded in the operating system log: messages about starting and stopping service XX ”; “Ensure that the parameters of the program modules are recorded in the log: the scanner, the kernel, the anti-virus databases (information must be logged when the program is started and when the modules are updated)”

Proposals for implementation - proposals that evaluate the possibility of using certain technological and architectural solutions.

Suggestions for testing the software being developed are additions to the requirements that indicate how a particular requirement should be tested.

Legal requirements - requirements for licensing, patent clearance, etc.

All these requirements must be defined and recorded before you proceed with the implementation of your system or product.

Non-functional requirements: how to determine them

Now that we have met with various types of non-functional requirements, it is a good idea to understand what needs to be done next.

First you need to create a template in which you need to list the main types of non-functional requirements. This template is necessary mainly in order not to forget any of the specified types of requirements. To compile this template you can use the following sources:

Karl Wigers' book " Developing Software Requirements " - in the "Appendix D" section of this book are examples of documentation requirements.
Materials GOST 34 series

Non-functional requirements: work on definition

Both to determine functional and non-functional requirements, working groups are used, the members of which determine, verify and approve requirements. For non-functional requirements definition groups, it is especially important to involve not only analysts and users, but also architects and key product or system developers, as well as a testing team. The architect perceives non-functional requirements as input to the selection and design of the application architecture, and the testing team plans those load testing scenarios that will be used to verify non-functional requirements (mainly for quality attributes).

The roles played by the members of the non-functional requirements working group are described below.

Users - provide estimates of the values of parameters that are used to determine non-functional requirements. Parameters, as a rule, are tied to scripts — user scenarios in which certain actions must be performed with certain restrictions for a certain time.
System analyst - collects, analyzes and documents and systematizes non-functional requirements.
System architect, key developers - participate in defining and analyzing non-functional requirements and test them for feasibility.
Testing team - participates in the definition and analysis of non-functional requirements and develops test scenarios to verify non-functional requirements.

An example of a script used to determine the performance requirements of a system module that sends notifications to site users by email:

1. The system receives a notification of the event initiating the distribution of notifications.
2. The system sends out alerts to addresses on the X distribution list using the Y template. The Z service is used to send messages.
3. In case of failure to complete the mailing, the system makes repeated attempts to mail.

Requirements for notification of the event initiating the distribution of notifications: the system should receive an alert no later than XX seconds after the occurrence of the event.
Requirements for sending notifications: all notifications must be sent no later than YY minutes after receiving notification of an event
Requirements for re-sending mailings after a failed attempt: the number of retries should be equal to 10, with an interval of 10 minutes after each unsuccessful attempt to send.

What questions need to be asked to the customer? In essence, there is only one thing: after how much time after the occurrence of the event, all users of the site should be guaranteed a notification.

Criteria for quality non-functional requirements

Both the functional and non-functional requirements are subject to the quality criteria of the requirements - i.e. a description of the qualities that quality requirements must meet.

The following are the main characteristics of the quality requirements.

Completeness (of a separate requirement and system of requirements) - the requirement must contain all the necessary information for its implementation. It includes all the information about the described parameter, known at the time of the description. The requirements system also should not contain undetected and undefined requirements. The reasons for the incompleteness of the description should be explicitly announced.
Unambiguity - the requirement must be internally consistent and everyone working with it must understand it the same way. Requirements should be expressed simply, briefly and accurately, using well-known terms. Typically, basic reader knowledge of the software requirements specifications vary. Therefore, it should include a section with the definition of the applied field concepts used in determining the requirements. An example, ambiguous requirement. "The screen refresh period must be at least 20 seconds."
The correctness of the individual requirements and consistency (consistency) of the system of requirements - the requirement must not contain in itself incorrect, inaccurate information, and the individual requirements in the system of requirements must not contradict each other.
Necessity - the requirement should reflect the ability or characteristics of the software, really needed by users, or arising from other requirements.
Feasibility - the requirement to be included in the specification must be fulfilled given the constraints of the operating environment. The feasibility of the requirements is verified during the feasibility study by the developer. In particular, for non-functional requirements, the possibility of achieving the specified numerical values under the existing restrictions is checked.
Verifiability — Verification of a requirement means that there is a finite and cost-reasonable process for manual or machine verification that the software meets this requirement. Each requirement (especially non-functional) should contain enough information to uniquely verify its implementation. Otherwise, the fact of implementation will be based on the opinion, and not on the analysis, which will lead to problems when passing the finished software. For quality attributes (as we remember, a separate type of non-functional requirements), the availability of the quality characteristics of a product or system

The quality of non-functional requirements directly determines the quality of the product or system being developed and is achieved through an iterative process of determining and analyzing non-functional requirements with the coordinated work of the whole group involved in their development.

Quality attributes

This section will focus on the quality characteristics of a product or system.

Quality characteristics and software quality model

The definition of quality attributes is closely related to the quality model chosen for your product. The development of a quality model is carried out by a quality assurance team (which includes testers and which, of course, is not limited to them).

In the software industry there are several quality models adopted as standard. These models were developed in the 70s-80s of the last century and continue to be improved.

Among them are the following:

ISO 9126
GOST 34
McCall's Quality Model
Boehm's Quality Model

You can also call two more standards that can serve as a source for determining your quality model:

1061-1998 IEEE Standard for Software Quality Metrics Methodology
ISO 8402: 1994 Quality management and quality assurance

Quality characteristics in terms of impact on system architecture

All attributes of quality from the point of view of the system architecture can be divided into two large groups: the first group (runtime) are attributes related to the time of the application or system; The second group (design time) defines the key aspects of designing an application or system. Many of these attributes are interdependent.

Let us consider in more detail each of these groups.

Runtime group

This group includes the following quality attributes:

Availability is an attribute of quality that determines the time of continuous operation of an application or system. To determine this parameter, the maximum allowable system downtime is usually indicated.
Reliability is a requirement that describes the behavior of an application or system in emergency situations (examples: automatic restart, restoration of work, data storage, duplication of important data, reservation of logic)
Requirements for data storage time (for example, using the database as a permanent data storage, data retention period )
Scalability - requirements for horizontal and / or vertical scaling of an application or system. Speaking of vertical scalability, we define the requirements for the vertical architecture of a system or application. Vertical scalability requirements may include, for example, the ability to transfer applications to more powerful SMP systems, support for large amounts of memory and files. Speaking of horizontal scalability, we define the requirements for a horizontal system or application architecture. The requirements of horizontal scalability may include, for example, the possibility of using clustering technologies. It should be noted that vertical scaling is usually aimed at improving system performance. Horizontal scaling, in addition to performance, allows to increase the fault tolerance of the system. You can read more about vertical and horizontal scaling, for example, here .
Requirements for the usability of the system / application (from the user's point of view) and requirements for the convenience and ease of support (Usability)
Security requirements typically include three broad categories: requirements related to access control, requirements related to working with private data, and requirements aimed at reducing the risks from external attacks.
Requirements for the configurability of the application, interaction and location of components can be divided into four levels:
1. configurability based on a predefined set of parameters (predefined configurability), when the required level of modification is achieved by changing the values of parameters from a predefined set;
2. configurability based on a predefined set of basic objects (framework constrained configurability), when the required level of modification is achieved by rearranging a predefined set of processes, entities and utility procedures;
3. configurability by implementing new base objects (basis reimplementation), when the set of processes and entities is expanded;
4. configurability through a new system implementation (system reimplementation), when the system should be installed and configured from scratch.
Performance requirements of the solution, defined in terms of the number of concurrent users, serviced transactions, response time, duration of calculations, as well as the speed and capacity of communication channels
Limitations imposed on the amount of available memory, processor time, disk space, network bandwidth, in which the application must effectively perform the tasks assigned to it

Design time group