Non Functional Requirements

Functional requirements of a system define how a system should behave with specific use cases. An example of a functional requirement could be “when the user clicks Submit button, the order should be placed”. Non Functional requirements, on the other hand, define the operational quality of a system. They define criteria or parameters which are used to measure the operational efficiency of an application.

The non-Functional requirements need not be explicitly defined, but an architect needs to consider these while designing the system.

Few of the common Non Functional Requirements are listed out below:

1. System Performance (considering Speed and/or memory):

This requirement concerns about how the system performs during peak loads. A few pointers on this are provided below:

  • How much memory will it consume during peak load?
  • Will the infrastructure/hardware support such peak traffic?
  • How many transactions per second can the system support?

2. System Security:

Security encompasses wide ranging concerns as below:

  • Data security (including both data in motion and data at rest)
  • Security of the web layer against various attacks
  • Security of the infrastructure components
  • Application user security (with respect to User roles)
  • Security processes like SSL certificate/Key policy, Renewal processes, maintenance of certificates/Keys.

3. Usability:

Usability, concerns about the ease of use of the system, from User Interface perspective. There could be certain tradeoffs between usability and performance or usability and security. For example a certain feature could be extremely user friendly but could impact performance or compromise security.

4. Availability:

Availability, concerns with the average up time of the system. For e.g., if the requirement mandates that the system be available ‘24X7X365’, then it implies that the system be available all the times. Also, we need to factor in the downtimes during upgrades or release times, if required. This in turn, could decide the deployment/upgrade strategies.

5. Compliance:

This requirement concerns with compliance to laws and regulations depending on local laws, State/Country specific laws. For e.g., certain country laws do not allow personal data to reside outside of the country. So if we are considering using a public cloud (which could host data in any datacenter across the world) for a system which collects personal data from citizens, then we need check the regulations for that country.

6. Fault tolerance:

Fault tolerance, concerns with the system behavior when there is a failure. The failure could be a hardware failure, or failure of an application component or a failure of installed software or even a malfunction of the application. When these failures happen, we need to understand what is the impact on the end user and how is the normal functioning of the system impacted. Also, we need to figure out ways to recover from failures, and how to complete or retry any incomplete or erroneous transactions. These factors would have a major impact on the system design. For instance, if the system is interacting with another third party system, then we need to account for failures within our system and also the possible impact on the third party system as well. We should also look out for Single point of failures within the system (This concept is explained in detail in a separate section, later in the book).

7. Scalability:

Scalability, concerns with the ability of the system to cater to varying workload. A few factors regarding scalability are listed out below:

  • Is the system capable of scaling horizontally?
  • Is every component of the system scalable?
  • Is the infrastructure scalable?
  • Will the network be able to cater to the peak workload?

8. Extensibility:

Extensibility, concerns with the flexibility of the system for future extensions. For example, there could be integrations with new systems in future or there could be certain requirements which would require building upon existing features without doing a lot of rework. It is important to understand the overall vision from business perspective and foresee what is coming, to be able to build an extensible system.

9. Maintainability:

Maintainability, concerns with the ease of maintaining and supporting the application from an operational stand point. It includes adhering to standards and using the right design patterns to ensure that the system is built in a uniform way which could be easily understood by anybody.

10. Interoperability:

Interoperability, concerns with the ability of the system to integrate with other systems. This is possible when we stick to open standards and open protocols. Conformance to open standards while designing (for example using standards like REST, SOAP), or using open exchange formats like XML, JSON etc. will help greatly in making the system interoperable. In certain situations, depending on the domain, we might need to use standard message formats, like standard XSDs (For example there are certain industry standard XML formats for Banking, Health care domains). Adhering to these standards help in the ease of integration with other systems.

results matching ""

    No results matching ""