Importance of Non Functional Requirements

The functional requirements are day-to-day requirements which business users and stakeholders needs in the product.

It is important to consider the other requirements also; these are called “Non-Functional Requirements” and fits into the organization's operational environment. This is the obvious requirements that your business users may not think about it.

The quality of an application depends on more than how well it satisfies user-functional requirements (fit for purpose). Even an application that successfully makes it through development and deployment can encounter issues from users and system operators if it is hard to use (fit for use), keeps failing, is difficult to diagnose.

Functional requirements define what a system is supposed to do whereas Non-Functional Requirements define how a system is supposed to be.

I have learnt in hard way in my experience on the security related features, response time, usage of the free third party software and it went to some extend to address the legal level agreement for each country.

For example in the financial transaction application one countries transactions should not be visible for other country users.

Usually the SOW (Statement of Work) or the BRD (Business Requirement Document) will be available for the technical lead/business analyst to start analyzing and come up with the FSD (Functional Specification Document). This document should include the non functional requirements as well and ensure this is sign-off by the client.

Let’s say you want to buy the car the functional requirements are:

·        Brand Name

·        Interior/Exterior Design

·        Price Range

·        Body Colored Mirrors

·        Leather Seat Covers

·        Air Conditioners

·        Advanced Audio Systems

·        Access to Phone/Charger

·        Power Windows

·        Deluxe Flooring

The non functional requirements are:

·        Seat Belts

·        Air Bags

·        Head Injury Protections

·        Intelligent Central Locking

·        Break System (ABS)

·        Electronic Stability Control

·        Traction Control

·        Side Impact Door Beams

·        Theft Alarm

·        Weight

All the parameters mentioned above are the Non-functional characteristics of a car and they are ones that influence our decision of going with a particular product.

The success or failure of a product today is determined by the fact as to how closely the product meets the non- functional expectations or requirements of the user.

The list of some non performance requirements are listed below:

Performance:

Performance covers areas like responsiveness, throughput and speed of operation. What is the minimum performance that will satisfy your client?

Usability:

How “easy-to-use” will the finished product? For example do you cater for disabled or handicapped users?

Reliability:

Reliability requirements deal with the continuous availability of the product to users. They should state what availability is necessary and desirable.

Security:

In products which deal with confidential or sensitive information, security considerations should be taken into account. Requirements for different levels of access, encryption and protection should be gathered.

Financial:

Financial considerations which will determine the success or failure of the project, for example a bank or investor might specify certain financial constraints or agreement which must be satisfied during the project.

Legal:

There may be legal requirements that must be met due to the environment in which your product will operate. Consult a legal expert for these.

Operational:

There may be a number of day-to-day operational issues that need to be considered.

Specialist:

There might be special requirements that are dependent upon the nature of the project or the nature of the business. You should considered these separately and state them explicitly in design docs.

The non functional requirements should be addressed during the architecture, design, planning and testing.

It’s important to explicitly cover non-functional requirements during the project initiation, release plan design and planning to avoid the bottle necks during the testing and implementation. I will come up with another article soon on “How to manage the Non-Functional Requirements”.