Requirements of technical architecture

A physical Architecture or structures technical is conceived so as to answer requirements.

These requirements are several natures:

Functional requirements

They are the functionalities of the application.

Availability/Reliability/beach of opening

The beach of opening of the service specifies the periods of time during which the application must be active: Example:

7/7j, H24
7/7j, H24, except beach of maintenance the 15 of each month between 20:00 and 6:00
5/7j, 9:00 - 20H

The availability indicates the target availability ratio of the application during the beaches of opening. Example:

availability of 99,9%

Strong requirements for availability require the implementation of architecture of High availability

Resumption of service in the event of incident

The local incident and the disaster site are distinguished: the incident is for example the loss of a waiter, while the disaster site is for example the fire of the center of exploitation.

The requirements must express in RTO and RPO. The RTO (Recovery Time Objectifies) is acceptable time to take again the service The RPO (Recovery Not Objectifies) is the maximum loss of data acceptable after Intégrité restarting The objectives of RPO and the RTO can be different according to whether it is a question from an incident or a disaster.

Safety

The requirements of safety cover several fields:

Confidentiality
Authentification/identification/Access control
Integrity
Auditability
Traceability/imputability
not repudiation

Performances

Requirements related to the following elements

many users,
processing times desired for the transaction, the batches treatments.
frequency of the treatments, compromise flow, peaks of load
filters
Response time

Scalability

The scalability is the capacity that with architecture to evolve/move in the event of rise in load so necessary.

Scalabilité horizontal: Possibility of adding waiters of a given type. Example: possible addition of WebSphere waiters with distribution of load Alteon
Scalabilité vertical: Possibility of upgrader a waiter (addition of processors, RAM, discs…)

Conservation of the data

An application cannot accumulate unbounded data. It is obligatorily necessary to envisage mechanisms of purging or filing. To fix the duration of the history preserved on line. When the old data should not be any more preserved on line, which are the requirements? Purges data? Transfer of the data in a system of filing? Filing on magnetic band? If the data are filed on tape, which is maximum time desired to be able to reach these data? To take into account the legal requirements

minimal shelf life to observe for certain data like the invoices
right to the lapse of memory: in French right, one can preserve certain personal data only during a time fixed for a former customer.
Other requirements

Modifiability

For the significant applications, one will treat the case of the requests (installation of version corrective, reparamétrage) which can have to be made without interruption of service. (installation and reparamétrage “hot”)

Utilisability

Requirements concerning of the functions intended to improve the interactions with the users. Examples:

Case of long treatments for which it is necessary to make it possible the use to visualize the progression of the treatments, to stop it, to take it again.
Case of action user which is necessary to be able to cancel (required to be able to return in a coherent former state)

Exploitability

Ability to be able to exploit and supervise the good performance of the application, to analyze the good performance (and the bad one).

Random links: