Software requirements - Functional requirements

Most of the software requirement specifications given today have functional requirements. Functional requirements are the descriptions of the behaviors expected from the software in the given conditions. Functional requirements may include calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to achieve. It is pretty easy to deduce why emphasis is given to these specifications but nonfunctional software requirements are also equally important. The functional requirements are supported by the nonfunctional requirements which impose constraints on the design or implementation. Nonfunctional requirements specify overall characteristics such as cost and reliability.
Nonfunctional requirements are sometimes interchangeably called as quality requirements. These quality requirements add quality attributes, quality factors and quality of the service in the software requirements. Some of the nonfunctional requirements include usability, portability, reliability, availability, efficiency, Integrity, security, safety, robustness and performance. These include both the internal and external quality aspects which are important to users and developers respectively.
The most difficult part of the nonfunctional requirements is specifying the quality attributes but once specified they provide an edge from the other available products. The nonfunctional requirements turn an ordinary product that serves the purpose to a delightful product. One cannot expect customers to like the product unless the quality attributes are explicitly specified. It is important to outline these specifications because sometimes these specifications propel significant architectural and design decisions and there would be a lot of wastage of resources in case re-designing is required.
A low point of these attributes is that they have a seesaw effect. The most prominent conflict is between the efficiency and most other attributes. For example addition of more layers of security cause a decline in the efficiency and similarly improvement in efficiency might affect the maintainability features. Hence it is extremely critical that user and developers decide on which attributes are more important for the product.
While giving the quality requirements the most common mistake that is made is giving abstract specifications which are in relative terms and are not verifiable. If a specification is given that the product should be user friendly then there is no way to enforce quality on the user friendliness of the software unless explicitly specified. One of the specifications that can be given is that the availability standard at the minimum should be 90% and the desired availability standard is 95%. Although it is more tempting and less time consuming to demand 24 hours availability but its serves as the best recipe to make all the project stakeholders to move towards a common objective.