Product Requirements in software engineering

In software engineering, to successfuly develope a whole systems project from the start to the end without major setbacks, the requirements should be collect from the client and the end users with extremely care.

Usually the requirements fall into two categories or types, the functional requirements, the requirements which describe what the system will do and how, that is its behavior; and nonfunctional requirements, the requirements that judge or limits the operation of a system.

Non-functional requirements are divided as follows:

This time we will describe Product Requirements:

These requirements specify some of the limit or base non-functional features of the system product itself. There are some different types of Product Requirements:

Reliability Requirements

In simple words, reliability is to have your system available in the worst possible scenario. To achieve these goals exist redundancy that provides data reliability, and fault tolerance that provides disk reliability.

Portability Requirements

These requirements ensure that a system can be easily and quickly ported to a new specified environment when necessary. It also means that the porting costs should be the lowest possible.

Usability Requirements

Well this is a really important one, without it the whole system has no meaning because no one will use it. Usability involves satisfaction and learnability, specially the second one, because if the common user can not learn intuitively what the system can and can not do then he will not use it.

Efficiency Requirements

It comprises two type: 

Space Requirements, it involves the space the system or application could fill in its life, for example the amount of disk space the database will occupy in the first year, or maybe the minimun available memory space need it to correctly perform.  

Performance Requirements, it includes the application reponse time, for example some applications would need to have a minimum response time of 0.5 seconds. If it is greater then the application would not meet its objective. With this requirement you have to consider how the system will change overtime, using maybe a lifecycle perspective.

Product Requirements describe important specifications about the non-behavioral features of the product itself. If not consider properly they could tear down any systems project very quickly. Maybe the system has all the right functionalities but, for the user is just not intuitive, or the response time is  1.0 seconds instead of 0.5. or maybe it was needed to be ported to windows environments too; then the whole project goes down.