Functional requirements capture the behavior of a system whereas non functional requirements capture the quality of a system that determines the level of satisfaction that the stakeholders expect from the system. Non functional requirements (NFRs) aka Quality of Service (QOS) requirements (sometimes also called technical requirements) are requirements that have no visible impact on end users but these are requirements that satisfy the stakeholders typically the business or the organization that is implementing the system. NFRs is very important from an architect’s/designer’s perspective to decide upon the environment and the design of the system to meet those requirements. NFRs are typically quantified by the stakeholders when they are defined. The following are some of the typical NFRs.

• Availability/Reliability/Fault Tolerance - System availability to the end user at any given time. Example: 99.99% availability (that translates to a system downtime of 52 minutes per year)
• Usability - System ease of use and navigability to a layman user. Example: Should not take more than 3 mouse clicks to reach any feature/screen in the system.
• Performance - Throughput, response time requirements. Example: A sub-second response time from the moment after the user triggers an action in the system and until the system responds back to the user.
• Security - How secure the system is from hackers (in case of a web application) and unauthorized users. Example: The system should be secure and the communication between the clients and the server should be encrypted and signed.
• Portability - System’s ability to adopt to different environments. Example: The system should be able to work with the following RDBMS as the data source - MySQL, Oracle, DB2, MS SQL Server.
• Scalability - The system’s ability to scale and support number of active users at a given point of time. Example: The system should support 10000 concurrent users.

Non Functional requirements are SMART requirements where SMART refers to Specific, Measurable, Attainable, Realizable and Traceable. Sometimes two NFRs might be mutually exclusive meaning if one requirement is met, it affects meeting another requirement. For example the scalability requirement will affect the performance requirement given the infrastructure supporting the system. In order to attain both of these requirements, the architect might suggest the business to invest in additional infrastructure that can help scale the system to meet the number of concurrent users and also meet the performance requirement. If the business does not want to invest more in the infrastructure then a tradeoff has to be made between scalability and the performance requirement. Tradeoff’s are typically done with the business and architects/designers meeting and working together. The stakeholders jointly decide and prioritize on the non functional requirements under the following categories.

• Must haves - These requirements are absolutely necessary and cannot be compromised.
• Should haves - These requirements are necessary but could be compromised on the margins if it conflicts with the must haves.
• Like to haves - These requirements would be good to have but would be the lowest priority compared to the must haves and should haves.

Once the NFRs are categorized as above, the architect/designer could point out conflicts and work with the business to do tradeoffs. NFRs are equally important as functional requirements because it determines the stability and quality of the system. These requirements should be attacked early on and have an huge impact on architectural decisions.