Non-functional requirements

 Non-functional requirements

Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific functions delivered by the system. They may relate to emergent system properties such as reliability, response time, and store occupancy. Alternatively, they may define constraints on the system such as the capabilities of VO devices and the data representations used in system interfaces.

Non-functional requirements are rarely associated with individual system features. Rather, these requirements specify or constrain the emergent properties of the system. Therefore, they may specify system performance. security, availability, and other emergent properties.

This means that they are often more critical than individual functional requirements. System users can usually find ways to work around a system function that doesn't really meet their needs.

However, failing to meet a non-functional requirement can mean that the whole system is unusable. For example, if an aircraft system does not meet its reliability requirements it will not be certified as safe for operation; if a real-time control system fails to meet its performance requirements, the control functions will not operate correctly.

Non-functional requirements are not just concerned with the software system to be developed. Some non-functional requirements may constrain the process that should be used to develop the system. Examples of process requirements include a specification of the quality standards that should be used in the process, a specification that the design must be produced with a particular CASE toolset, and a description of the process that should be followed.

Non-functional requirements arise through user needs, because of budget constraints, because of organizational policies, because of the need for interoperability with other software or hardware systems. or because of external factors such as safety regulations or privacy legislation, Figure 6.3 is a classification of non-functional requirements, You can see from this diagram that the non-functional requirements may come from required characteristics of the software (product requirements), the organization developing the software (organizational requirements) or from caterwaul course.

The types of non-functional requirements are:

1. Product requirements: These requirements specify product behavior. Examples include performance requirements on how fast the system must execute and how much memory it requires; reliability requirements that set out the acceptable failure rate; portability requirements; and usability requirements.

1. Organizational requirements: These requirements are derived from policies and procedures in the customer's and the developer's organization. Examples include process standards that must be used; implementation requirements such as the programming language or design method used; and delivery requirements that specify when the product and its documentation are to be delivered.

1. External requirements: This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include interoperability requirements that define how the system interacts with systems in other organizations; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements. Ethical requirements are requirements placed on a system to ensure that it will be acceptable to its users and the general public.