When developing a new information system (or when introducing an existing one), specialists will necessarily encounter in their work the need to determine this kind of requirements. It makes sense to consider them in detail. What are non-functional requirements, what they are, how professionals define them.
Two categories of requirements
There are a lot of requirements for characteristics, quality of software products, information systems. However, they can be divided into only two large categories - these are functional and non-functional requirements. It is important at the beginning of the article to indicate the difference between them.
So:
- Functional requirements. They describe what exactly needs to be implemented in a particular system or product, what actions should be performed by users in relation to this development.
- Non-functional requirements. They describe how exactly the created system or software product works, what properties and characteristics a particular development has.
Point 1. The concept of functional and non-functional requirements we have formed. We now turn to the second point - we will consider what exactly can be attributed to the latter.
What is the category?
In fact, various attributes of product quality are primarily attributed to non-functional requirements. Namely, the requirements that determine the qualitative characteristics of development (software, information system). This, of course, reliability, scalability, product performance.
However, such non-functional requirements are of great importance:
- Limitations That is, conditions that limit the choice of any solutions for the implementation of individual requirements (or sets of requirements). They narrow the variety of choice of tools, strategies, tools in the development of both the structure (architecture) and the appearance of an information or software product.
- Business rules. This includes guidelines, policies, principles, regulations that somehow limit certain aspects of the business. For example, they can determine the composition and rules for the implementation of any business projects. What can be attributed to this category? Corporate policy, all kinds of government decrees and decrees, industry standards, computational algorithms. All the rules that somehow affect the development of the system, product, are used while working on the project.
- Proposals for implementation. The group includes specific proposals evaluating the possibility of applying certain architectural and technological solutions.
- External interfaces Description of key aspects of the product’s interaction with other systems and the operating environment. First of all, these are requirements for the API of a system or product, as well as requirements for the API of other systems with which the integration of the developed product is planned.
- Proposals for verification, testing of developed software. This is a series of additions to the requirements, indicating how a particular requirement should be tested in practice.
- Legal requirements. To product licensing, patent availability, etc.
It is important to note that non-functional requirements for the system are predefined and fixed. Only then can a specialist begin to develop a product.
Requirement Examples
In order to have a clearer idea of non-functional requirements for an information system, we will analyze a number of examples:
- Limitations "This development is conducted only on the platform of vendor X." "When authenticating a user in an information system, only biometric identification techniques should be used."
- Business rules. "When the product is shipped, the manager is obliged to request an invoice from the company’s accountant and waybills." "An order will be deemed canceled if payment to the invoice is not received by the supplier within 14 days."
- External interfaces "Provide a log entry of the developed operating system of such events: a message about the start and stop of service X". "To ensure that the data of its modules: the kernel, the scanner, the anti-virus database are recorded in the journal of the program being developed. Information should be recorded in the journal both when the application is launched and when its modules are updated."
How to define these requirements?
We examined specific examples of non-functional requirements. And now another important question: "How to define them in relation to a specific product?"
First of all, specialists draw up a template that lists the main types of non-functional requirements for the product. First of all, it is needed in order not to miss any position from this list.
Sources for creating such patterns, developers usually choose the following:
- GOST (state standard of the Russian Federation) 34th series.
- The book "Development of software requirements" (author - C. Wigers). In particular, attention should be paid to the section "Appendix D". It contains specific examples of documentation with requirements.
Let’s now consider who is specifically involved in this work.
Product Requirement Determination Activities
Functional and non-functional requirements for the system are developed by special working groups. Their members not only determine, but also verify, approve these requirements.
As for the non-functional category, it is important to determine not only users and analysts, but also key product developers, system architects, as well as a group of testers to determine it. Why is this important? An architect, say, will perceive non-functional requirements as input for the selection and design of program architecture. And the testing team will plan for them suitable load testing scenarios . It is with the help of the latter that the fulfillment of non-functional requirements will be checked. By and large, this applies to quality attributes.
Roles of the members of the working group
Let’s now consider what roles are distributed among members of a group of specialists who determine and approve non-functional requirements for a product:
- Users These participants assess the values of those parameters that determine non-functional requirements.
- Systems Analyst. This participant collects, analyzes, systematizes and documents non-functional requirements.
- Key developers and systems architect. What role does this group play? They participate both in the definition and analysis of non-functional requirements, and they are checked for their degree of implementation.
- Testing group. He is also involved in determining and analyzing the list of non-functional requirements for the program. Additionally develops test scripts for these requirements.
Scenario for defining requirements
Here we give a specific example of a scenario used to determine non-functional performance requirements of a module designed to send notifications to users of an Internet resource by e-mail:
- The system receives a signal about the event initiating the distribution of electronic notifications.
- The system distributes messages to users from list A, using template B for this. Service B is used to send messages.
- If it is not possible to complete the operation, the system makes another attempt to send messages.
Scenario product requirements
And now we will make requirements for the scenario formed in the previous subheading:
- Requirements for the time of notification of an event that triggers the distribution of notifications: the system should receive a message about the event that triggers the distribution, no later than X minutes after it occurs.
- Requirements for the time of sending messages: notifications must be sent by the system no later than X seconds after receiving a signal about the event.
- Requirements for re-sending notifications in the event of an unsuccessful attempt: the number of retries should be equal to X. Interval - X minutes from each case of unsuccessful sending messages.
Important requirements criteria
Non-functional requirements themselves must strictly comply with a number of quality criteria for their content:
- Completeness (as a separate requirement, and their complete list). What does it mean? The requirement must contain all the necessary information for its implementation.
- Unambiguity. The requirement must not contradict either itself or other items from the list. All specialists working with him should understand him the same way.
- The correctness of an individual requirement, ensuring systemic consistency.
- Necessity. The implementation of this requirement is really needed by users.
- Feasibility. To make this requirement a reality.
- Verifiability. Should provide an unambiguous verification of its implementation.
We met with such a concept as non-functional requirements for a software product, information system. Their specific examples, as opposed to the functional category, and category quality criteria, were also analyzed. You know which groups of specialists create and approve these instructions in how.