In the Real World, web apps can get complicated. A popular web site can get hundreds of thousands of hits per hour. To handle this kind of volume, most big web sites create complex hardware architectures in which the software and data is distributed across many machines. This complexity can be handled through the non-functional parameters of the system.

The most important and fore fronted job for a web application solution is to provide the end user / clients with a reliable, useful, and correct experience. In other words, the designed solution must satisfy the functional requirements such as “select an item from the menu” or “add item to the shopping cart”. Once we have made sure that the system supports the use cases, we will most likely be faced with another set of requirements—requirements for what happens behind the scenes, i.e. the non-functional requirements.

Here we discuss some of the most important non-functional requirement we are likely to face during the software development cycle: Performance, Modularity, Flexibility, Maintainability, and Extensibility

Performance: If our website is too slow, we will (obviously) lose users. So we need to circumvent this situation which could help an individual user experience faster response time so that system support a greater number of simultaneous users (throughput).

A common architecture we are probably quite familiar with is configuring the hardware in layers or “tiers” of functionality. Adding more computers to a tier is known as horizontal scaling, and is considered one of the best ways to increase throughput.

Modularity: In order for different pieces of our application to run on different boxes at the same time, our software is going to have to be modular... and modular in just the right ways.

Flexibility: We need to change our system without going through some big development cycle. We might need to swap in the “limited time, special offer” components for a big sale. We might find a bug in a new component and need to swap in the older component temporarily. So, we need our system to be flexible.

Maintainability: Sometimes we might need to change database vendors, and update our system quickly. We might get obscure bugs and need to track them down ASAP. The admins might decide to restructure the company’s naming service, and we will have to adjust—right now! We need our system to be maintainable.

Extensibility: The guys over in marketing might need a new feature to land that big client. Our users might demand that we support a brand new feature that their browsers have. So, our system had better be extensible!