Non Functional Requirements
Home / Requirements / Non Functional Requirements
Here you can find information about the Non Functional Requirements.
Non Functional Requirements (NFR) cut across the software functionality, spanning across all the modules and features. These requirements go deep in to the Architecture.
Data Dissemination is an on-demand business model where it's extremely difficult to predict the load on the system. PxStat is designed to work also on Virtual Environments (self or cloud hosted), taking advantage of the on-demand resource consumption model, in order to scale up and down resources efficiently and quickly.
The system is also based on Modular Components. It is possible to enable/disable modules according to business needs as well as integrate new modules easily to future proof and extend the life-cycle of the system.
PxStat keeps up with the constant increase of internet speed and variety of devices available by offering a full responsive and lightweight interface based on the popular Bootstrap framework.
Performance is consciously taken in to considerations and features like asynchronous processing, delegation of services and caching are all implemented to avoid or minimize potential bottlenecks.
The system is optimized for low-bandwidth connections and to run on any current mobile/desktop device. Response time are also kept as low as possible, below the second for all requests with the exception of data-set downloads where performance is dictated by the size of the data-set.
The Cache tier plays also the important role to ility there is a general tendency to expect speedy response from internet based applications. Software users are going to expect the same, regardless of the type of application or the volume of processing that happens behind the screens. Therefore, architects will have to the potential performance bottlenecks and implement designs that can help leverage concepts like , micro services architecture, multi-data availability, etc.
This is where software architects will have to leverage the cloud model to
The core-system is based on a Four-Tier architecture:
- Client
- Server
- Cache
- DB
The Client tier provides the user's interface based on the Bootstrap 4 and JQuery 3.x frameworks (HTML5/Javascript/CSS).
The Server tier powers the Web-Services (API) through public (anonymous) and private (authenticated) interfaces.
The coding language adopted is C# (aka C Sharp / .NET 4.7.2)
If you look for running C# on Linux, then you can check out the Mono-Project
The Cache tier enables the server-side caching, to speed up Web-Service requests against the Server tier, reduce the network traffic between the Server / DB tiers and scale down the workload on the DB tier. The technology behind is MemCacheD, available for both Linux and Windows.
The Database tier is based on SQL Server 2016 (Standard Edition) or higher. This version (or higher) come shipped with the Always Encrypted feature to enable Confidential Computing.
If you look for running SQL Server on Linux, then you can check out the Installation guidance for SQL Server on Linux
The nature of the Tiers can be based on either physical or virtual Servers. They can also work in single-mode or as part of a Cluster or attached to a Load-Balancer for redundancy and performance:
- Single Server
- Cluster of Servers
- Servers attached to a Load-Balancer
It is possible to configure the infrastructure to optimize performance, redundancy and cost according to requirements and budget: from the most simple Option (E) where all tiers are hosted on the same infrastructure component, to the most complex Option (A) where each tier has a dedicated infrastructure component.
The Option (B) is probably the best solution performance-wise, where the Server and Cache tiers are sharing the same infrastructure to reduce the internal network traffic and speed up the the response time of the API calls.
