Non-Functional Requirements Everyone Forgets About and Fails the Project

These are items that need to be not just discussed with developers verbally. They are part of your contract with them! It is important to select and describe them specifically for your project. For example, if the project is a startup or an MVP for testing and has a development budget of around 20-30 thousand dollars, then the requirements marked "$$$" will be inappropriate for you, but there are methods for partially complying with them. Trade-offs. At the end of the article, I will also share a short list of requirements suitable for creating a prototype, a simplified version of an application that is unsuitable for use in real conditions but sufficient for analysis and further development. There everything is almost the opposite: you need to violate some requirements and use special principles.

Without further ado, I am sharing with you some of the most important non-functional requirements.

Non-Functional Requirements

(requirements for system quality)

$$$ Compliance with the Domain Language

The naming system in the program code must match the terminology of the domain language. (in the MVP version, this language will be contained in the data schema).

This is not an obvious requirement. Programmers often write a program while figuring out what is required of them along the way, and along the way they also call things familiar to the business by THEIR OWN names. And then the client's additional task will be to study these fantasies on free themes. Not to mention that any new programmers on the project will not fundamentally dig into all this and will find arguments to rewrite the entire project from scratch. How to check this unified language, or the so-called "domain core", is a topic worthy of a separate article. For now, I will only leave a link to domain-driven design and say that this is the work of a software architect (together with a business analyst in large companies).

Readability

In short, this is a requirement under which developers undertake to write code that someone other than them can read. Yes, it is that simple, but extremely important. To comply with this item, it will be enough to follow recommendations on coding style for code formatting and the chosen framework's recommendations on file system organization. Such a set of rules already exists for any programming language, for example in php there is PSR. Code readability, of course, will not affect how the software works. But a program is not a static thing; it constantly changes and is maintained. So it can be argued that such a simple requirement will determine how many bugs there will be in your system and how much it will cost to fix them. No one will want to fix, or even look at, especially unreadable code. In my experience, most projects have exactly this kind of code, and their owners overpay for laughably simple fixes, often more than the initial development cost them. This is not a very expensive requirement, but it often depends on the programmer's conscience and is therefore often violated. It must become part of the contract!

Documentation for the Server Application API

The system must contain documentation for server data models as well as documentation for all server URL resources, with the ability to make a test request, see its parameters, and also see the real response of the server API.

This item is critically important for acceptance testing. If you have a modern project with a separate frontend, then without complying with this item backend developers will be able to deliver a dummy to you or a very confusing API that you will not be able to use, which is even worse, because before this is discovered other hired employees will spend time on it!

We use the excellent Swagger web add-on, a program in which it is not only transparently visible what functions the server performs, but you can also view the database structure. And the biggest bonus is that you can independently carry out manual testing of server functions without programming knowledge! If the topic is interesting, write in the comments, and we will write a separate article about APIs with examples from real projects.

Documentation for the System's Key Algorithms

All key nodes and algorithms of the system, as well as code blocks that do not correspond to self-documenting code, must have a clear and noticeable comment (in the code) or a file named README.md in the module\application folder. The key word here is "key". Documenting every line of code will lead to a strong increase in the product cost. Therefore, especially for startups or small companies, it is important that the architect identifies the most important algorithms in the system for which documentation must be supplied. Not only programmers, but also non-technical specialists must understand it.

$$$ Distribution

The system must be divided into subsystems with a low degree of coupling. Each subsystem is a separate web application or service connected to all other services by a metadata system or an event bus.

The web interface, server API, administrative area, CDN server, and full-text search service are separate services.

In the future, subsystems can be distributed into separate repositories.

Deployment System

The system must be quickly installable (in a few steps) on Ubuntu systems that have Docker, docker-compose, git, and a package manager preinstalled.

The system must contain access settings for databases, subsystems, and external services (such as Google authorization, a video communication service, or an email client), and security settings (for example, CSRF token, salt, passwords..).

The deployment system is stored in the repository in the VCS.

The deployment system contains configurations for the database, web servers, and interpreters.

The deployment system must create configurations for other systems from a template.

$$$ Modularity

The system must support the specified modularity corresponding to the principles of LOW COUPLING and HIGH COHESION. These are principles from a not very popular (compared to SOLID) set of recommendations GRASP, a topic for a separate article.

The principles for defining modules depend on the business requirements for the modules or on the principle of "one module per aggregate".

ATTENTION: this means compliance with these principles at the level of GROUPS of classes (mini-applications, software modules). Compliance with this principle at the class level will require more implementation time, so it is not expected at the MVP stage.

Multilayer Architecture

Each module consists of several layers (levels).

A layer cannot access a layer that is above this layer (for example, a model does not make requests to a service

We use an open-layer architecture (a layer may access a lower-level layer bypassing other layers)

Here are the main layers in a multilayer architecture.

Interface

$$$ A React, Angular, or Vue application consisting primarily of web components.

*ALTERNATIVE OPTION: PJAX application, a simplified model of fast interaction with the user.

Controller Layer

This level

1. Responsible for receiving an incoming request via the protocol

2. Having a strictly defined URL address

3. Authorizes the request

4. Delegates request processing to a specific service.

Corresponds to the "Controller" pattern from GRASP and the "Thin Controller" principle.

Service Layer

A layer with classes of the "Pure Fabrication" type, which are an additional wrapper for interacting with domain models. This layer contains logic related to grouping some operations with models for reuse, or any logic that is not directly related to domain logic but is important for the optimal functioning of models. Caching may be performed at this level.

$$$ Domain Model Layer

A class containing business logic (domain logic). Following the Rich Domain Model idea, model classes must be placed in this layer in accordance with the naming of objects in the application's domain.

$$$ Repository Layer

A group of classes containing infrastructure logic: the logic of searching, filtering, and grouping objects through an ORM or directly through the database.

ORM Layer

A class that is a mapper between the database and the object model. It contains database-level validation and relational (relationship) logic. It is often provided by a framework and may be based on the ActiveRecord pattern, suitable mainly for prototyping, or on the more complex DataMapper pattern.

$$$ Security

A topic for a separate article. An expensive but critically important pleasure. Here we will only say that security requirements must be strictly formalized, especially if your project cannot allow leakage of users' personal data, cannot allow one user to impersonate another, cannot allow your users to be invisibly redirected to other sites without your knowledge, and cannot allow irreversible data loss..

The main types of vulnerabilities that are unacceptable in 99% of systems are SQL injections, CSRF attacks, file injections (for example when uploading a photo), DDOS attacks (mainly server requirements), password brute force attacks, hacking through "invisible" files (for example through the .svn folder), token substitution, MITM eavesdropping attacks, and XSS attacks with traffic redirected to another server. You can read more about each one on Wikipedia or ask in the comments