> For the complete documentation index, see [llms.txt](https://kdongs.gitbook.io/kdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kdongs.gitbook.io/kdocs/architectural-requirements/architectural-requirements-ras.md).

# Architectural Requirements (RAs)

## About

They are requirements that directly impacts in the Software Architecture.

#### Examples:

* Performance requirements: *The application's response cannot exceed 100ms*.
* Data storage requirements: *Like data policies and compliance for europe that enforces data to be in data centers inside Europe.*
* Scalability requirements: *How the software will scale, vertically or horizontally, etc.*
* Security requirements: *Encrypted data, encrypted communication, the need for security certifications.*
* Legal requirements: *To meet contries legal requirements and policies to avoid data leaks.*
* Audit requirements: *Providing parameters for audits in the software and data centers.*

## Architetural Characteristics

### Operational

Characteristics more tied on how the software will execute and operate.

#### Availability

How available the application must be, and how to make it.

#### Disaster Recoverability

How to recover when unavailable.

How much you may want to spend, with multi-region deployment.

#### Performance

How much performance does the system must have, and how to do this.

#### Backups and Restores

How is backup being done.

Have the backup have been tested.

#### Reliability and Security

How to make your system more secure and reliable.

#### Scalability

How easy can your system scale.

### Structural

Characteristics more tied to the process of developing the software.

#### Configurable

How easy is to configure your software, to change environment variables, libraries, API keys, etc.

#### Extensibility

How easy can the software grow, implement new features or change third-party libraries, or DBs, etc.

#### Deploy

How easy is to deploy the software.

{% hint style="success" %}
Correct use of containers to speed up deployment.
{% endhint %}

#### Reusability

Reusability of components to speed up development.

#### Internationalize

How easy can your software be usable globally.

{% hint style="success" %}
For frontend, does application supports different languages? Different cultures *(Ex.: LTR/RTL)*.
{% endhint %}

{% hint style="success" %}
For backend, does it support different payment methods, (Ex.: paypal, or stripe), different regions may accept only some types of payment methods. Does it support Local Time and Timezones? Etc.
{% endhint %}

#### Maintainability

How easy is to maintain the software. The more simple the software, the easier is to maintain.

{% hint style="success" %}
Correct use of Design Patterns, SOLID principles, etc.
{% endhint %}

{% hint style="success" %}
**Correct use of tests**.
{% endhint %}

#### Support on Software

Correct use of Logs and Debugging tools.

{% hint style="info" %}
**Focus on observability.**
{% endhint %}

### **Cross-Cutting**

Characteristics that must be used on daily basis.

#### Acessibility

Is the software usable by everyone (Blind, Deaf, other disabilities).

#### Data Retention

How long will the data be stored.

*(EX.: Data that needs to be stored for policy reasons)*

#### Authentication and Authorization

How will the software authenticate and keep the authentication, for better user expirience, but not compromizing security.

*(Ex.: Use of API Gateway for authentication instead of authentication at API)*

#### Privacy

How to minimiza data leaks, keep data private and secure.

#### Usability

Not just user usability, but also good usability for written code. (Dev to Dev usability)

Not only at frontend, but also backend.

*(Ex.: Is the API well documented, well organized, easy to use, etc)*