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.
Highlights
functional requirements (FRs) Functional requirements C Components concept variants (CV) Concept variants Design Failure Modes and Effects Analysis (DFMEA) Design failure modes and effects analysis Design Parameters (DP) Design parameters DR Design review Design Structure Matrix (DSM) Design structure matrix Design Validation Plan (DVP) Design validation plan finite element analysis (FEA) Finite element analysis
A case study by researchers at Linkoping University found this at both Ericsson, a telecommunications company, and the Swedish Meteorological and Hydrological Institute, and noted that both gave a focus on FRs despite an understanding of non-functional requirements’ (NFR) and their benefits (Borg et al 2003)
The design review, costing, and study of manufacturing process activities are associated with the NFRs domain and the information is captured as feedback in the DSM (Fig. 3)
Summary
The role of non-functional requirements (NFRs) in the success of a system is emphasized extensively in software engineering literature (Landes and Studer 1995; Cysneiros and Leite 2004; Feather 1993; Chung and Nixon 1995; Mylopoulos et al 1992; Roman 1985; Gross and Yu 2001; Glinz 2007; Burge and Brown 2002). The overarching goal to study NFRs is to explore whether they should be formally considered in the requirements modeling scheme, proposed by (Maier et al 2007; Mocko et al 2007b) that captures conceptual design information. The following are the steps in the conceptual design stage: STEP I: Identify essential problems; STEP II: Establish function structures; STEP III: Search for working principles and working structures; STEP IV: Combine and solidify into concept variants; STEP V: Evaluate against technical and economic criteria; STEP VI: Develop working concepts; STEP VII: Preliminary form design, material selection, and calculation This step falls in the embodiment design stage and determines engineering characteristics.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
