Non-functional requirement

Non-functional requirements (e.g., development standards, program-naming convention standards). 

SPINLINE3 architectures are designed using two kinds of basic components Processing Units (PU) and data links. Theses basic components are combined to implement multi channel architectures with distribution of treatments and redundancy of data links where relevant in order to meet the functional and non-functional requirements. The properties of the processing units and data links ensure a deterministic system behavior with bounded response time for the functions under any load conditions. 

Non-functional requirements (also known as quality requirements) are generally more difficult to express in a measurable way, making them more difficult to analyze. In particular, NFRs tend to be properties of a system as a whole, and hence cannot be verified for individual components. Recent work by both researchers and practitioners has investigated how to model NFRs and to express them in a form that is measurable or testable. There also is a growing body of research concerned with particular kinds of NFRs, such as safety, security, reliability, and usability. 

Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. (2000). Non-Functional Requirements in Software Engineering. Kluwer Academic, Boston. 

Adams, Kevin, Non-Functional Requirements in Systems Analysis and Design (Topics in Safety, Risk, Reliability and Quality), Springer, New York, 2015. 

Non-functional requirements define how well the functional requirements must perform by describing the characteristics of the system independently of its functional goals. Thus, they are also called quality attributes, and comprise aspects like usability, likability, performance, reliability or safety e.g. the time required to execute a function can be a non-functional requirement [32]. During RE, nonfunctional requirements will be interactively developed across all identified functions based on system s life cycle factors and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements [30]. 

Without an adequate structure in the documentation of requirements, it is not possible to provide the developers with the information they need for creating a complex system. A requirements specification provides a complete description of the functionality of the system to be developed. It also includes non-functional requirements describing constraints. The documentation will typically be structured in a hierarchical way, providing sections and subsections for different levels of requirements [9]. The hierarchy can be based on a modeling approach used for the system development, e.g. usage scenarios or data flow diagrams. 

Glinz M (2007) On non-functional requirements. In 15th TKKF. International conference on the requirements engineering conference (RE 07), pp 21-26... 

Each requirement and each design feature should be expressed in such a manner that a test can be done to determine whether that feature has been implemented correctly. Both functional and non-functional requirements should be testable. Test results should be traceable back to the associated requirements. 

For safety systems, all the safety functional and non-functional requirements should be shown to be the result of the plant safety analysis and to be determined by it. 

The test specifications should cover the entire functionality of the system and its interface with the plant and should be shown to be derived from the above functional and non-functional requirements. 

The means by which it is to be demonstrated that non-functional requirements are met should be documented in the verification plan. Performance testing should cover, for example, all timing reqrrirements relating to speed of response to inputs, time to detect and recover from farrlts, and capabihty to accept all specified input rates. 

Note that this specification format is restricted to the purposes of algorithm design, as no non-functional requirements are given. 

A graphical representation of the workflow is depicted in Figure 1. We start from the specification of a system. The system is described by its functional and non-functional requirements. Once the system has been modelled, a threat analysis of the system is performed in order to evaluate possible risks, point of failures, and so on. 

For meaningful safety-related product development not any quality characteristics could apply their own process. Therefor also even if there are other means of analysis or methods for verification or validation necessary, it is a matter of tailoring of the product lie-cycle to apply activities to as necessary for all non-functional requirements also such as securily. Similar to challenges with the safety lifecycle for safety-related active safety functions and other passive safety functions the tailoring and even the entry into the safely lifecycle is dilferent. The intended safety function for an active safety function should be made safe by adequate measures during the Item Definition, and for typical passive safety functions it should be done during entire safely lifecycle. 

Both HCI [24] and SE [17] deal with usability as a non-functional requirement. Usability requirements specify user effectiveness, efficiency or satisfaction levels that the system should achieve. These specifications are then used by the usability people at the evaluation stage Task A should be performed by a novice user in less than X minutes , or End user satisfaction with the application should be higher than Z on a l-to-5 scale . Dealing with usability as a non-functional requirement is useful for evaluation purposes, but it is not appropriate for developing usable software. 

Test Cases. To ensure that a certain requirement is fulfilled, test cases are defined for a given set of requirements. These test cases can either be specified manually (e.g., for non-functional requirements) or generated automatically (e.g., from formaliza-... 

Upon identification of the compromise a CertPack issue will have on the (effectiveness) of the safety case, analysts will need to identify recovery action. For example, in the case of non functional requirements, one recovery action could include contracting the COTS provider for further testing. 

Question. Is there evidence about non-functional requirements [sic] ... 

Non functional requirements [sic] is a term given to describe requirements that usually focus on attributes such as performance, reliability and safety, as opposed to requirements that entirely on functionality. Such system properties are related to... 

The term is eonsidered by the authors as not representing all cases of requirements described by it. There can be cases when in order to achieve a non functional requirement, design and implementation of functionality is required (e.g. voting for reliability). 

---