Towards the formalization of non-functional requirements in conceptual design

Abstract

This paper explores the formal roles of non-functional requirements’ (NFR) elicitation, definition, and verification in the early stages of an engineering design project. This is performed using a case study conducted at an automotive original equipment manufacturer (OEM) during the design and development of a rear bumper sub-system. The purpose of this exploration is to determine if NFRs should be formalized within requirements modeling scheme. This can capture conceptual design information to identify their impact on other requirements while conducting design changes. The modeling scheme in this paper consists of a sequence of following domains—requirements, functions, working principle, components, design parameters, test measures, and tests—that are mapped to each other using matrices. It is revealed through this case study that non-functional requirements drive much of the design decision-making process and constrain the manner in which the product functionality is realized. Hence, the inclusion of NFRs as a separate and distinct domain in the design process is critical to recognize their significance during design changes. Based on the observations made in the case study, the NFR domain is included in the requirements modeling scheme.

Analyzing Dependencies between Product Architecture and Module Drivers

“…But there are a variety of considerations for the requirements for the successful development of such systems. Often, these requirements are structured as non-functional requirements (NFR) that provide the framework for system design [33,34]. Analyzing these in terms of module drivers yields a selection of possible module driver additions.…”

“…One potential module driver supplement is interoperability. This aims in the system thought at the fact that systems can collaborate among themselves and do not hinder themselves [34,35]. If this nonfunctional requirement is transferred to the subsystem level, it results in a requirement for forming harmonized modules across different development disciplines in product system design.…”

Reducing design uncertainty through model-based collaborative design methods when introducing new technologies: A Solomon four-groups empirical design study

“…The relevance of identifying manufacturing and test related UU is highlighted, as non-functional requirements, such as manufacturability and test ability, are drivers of the design and decision-making process (Shankar et al, 2020).…”

Transcendental Logic-Based Formalism for Semantic Representation of Software Project Requirements Architecture

“…Non-functional requirements are usually considered only informally due to their complexity, high level of abstraction, and lack of methodologies and support tools. At the same time, non-functional requirements define a significant part of the design decision-making process and limit the way the product functionality is implemented by imposing additional constraints in business process models (Shankar, 2020), so they are also known as the system's quality attributes. The approach to requirements management should be sure flexible, especially with respect to non-functional requirements, but they are much more difficult to systematically model, analyze and change, in contrast to functional requirements, the satisfaction of which can be easily tested (Moradi et al, 2018;Jackson et al, 2009).…”