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.
Abbreviations
FR
Functional requirements
C
Components
CV
Concept variants
DFMEA
Design failure modes and effects analysis
DP
Design parameters
DR
Design review
DSM
Design structure matrix
DVP
Design validation plan
FEA
Finite element analysis
Fn
Functions
HOQ
House of quality
NFR
Non-functional requirements
OEM
Original equipment manufacturer
PR
Prototyping
Q1
Research question 1
Q2
Research question 2
QFD
Quality function deployment
T
Test
WC
Working concept
WP
Working principle
WS
Working structure
1 The motivation to study non-functional requirements
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). NFRs are significant in software engineering as they assist in guiding and constraining the architecture through requirements such as security and availability (Rainardi 2007). They play a role in system development and serve as filters and selection criteria for decision making (Mylopoulos et al. 1992). However, NFRs are often considered late in the system development process (Chung and Nixon 1995), where late consideration may lead to conflicts and ambiguities in requirements resulting in expensive design changes (Feather 1993). Typically, NFRs are the last requirements satisfied due to their dependence on other requirements, thereby rendering them expensive and difficult to maintain (Davis 1993; Breitman et al. 1999; Cysneiros and Sampaio do Prado Leite 1999; Ullman 2010; Cysneiros and Leite 2004). Though they are recognized as an important component in software system design, they are often neglected (Peng 2009) which can lead to software system failures (Mylopoulos et al. 1992). Hence, NFRs should be considered and addressed from the start of system development (Cysneiros and Sampaio do Prado Leite 1999). Some preliminary work has shown that requirement evolution is critical to the success of a project with the generation of NFRs appearing to be more influential than generation of functional requirements (FRs) (Summers et al. 2014). Thus, while NFRs are recognized as critical in software engineering, their specific role in mechanical engineering design is neither well understood nor articulated, yet.
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. In this scheme, different domains are captured and related to each other through a matrix based modeling approach, as shown in Fig. 1. Binary relationships between two domains are captured in the matrix using 1 s and 0 s where, ‘1’ indicates a relationship and ‘0’ otherwise. Here, information flows originate from the domain labeled across the top of the matrix to that labeled along the side. The value of this modeling scheme is threefold: (i) it assists designers identify the effects a component change has on other components through requirements; (ii) these domains can be used to explicitly link seemingly disparate domains of interest, such as requirements linked to component parameters or functions linked to test measures (Maier et al. 2007; Mocko et al. 2007a); and (iii) it assists designers capture conceptual design information in domains of interest, thereby visualizing the relationships of the captured design information both between and within a domain (Suh 2001). The authors hypothesize that this modeling scheme has limitations, one of which is not including non-functional requirements, which will limit the usefulness of the modeling scheme with respect to its objective of capturing conceptual design information.
Fig. 1
Requirements modeling scheme proposed by (Maier et al. 2007; Mocko et al. 2007b)
×
Advertisement
The systematic design process is broadly classified into three stages: (i) conceptual, (ii) embodiment, and (iii) detailed design (Pahl and Beitz 2013; Otto and Wood 2001; Ulrich and Eppinger 2008; Ullman 2010). Several steps are listed in the conceptual and embodiment design stage before the designer is able to define the engineering characteristics from the initial set of customer requirements (Ullman et al. 1988). 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.
Readers can consult (Maier et al. 2007; Mocko et al. 2007b) for an in-depth explanation of the terms mentioned from STEP I through STEP VII, as re-introducing these terms is out of scope in this research paper. The notion of mapping design domains for use in decision making is not novel. A popular tool used in design practice to map design domains is the House of Quality (HOQ) (Hauser and Clausing 1988). The HOQ is a tool within the quality function deployment (QFD) approach that supports information processing and decision making (Olewnik and Lewis 2008; Ullman 2010; Hauser and Clausing 1988). The HOQ maps the customer requirements and the engineering characteristics in the first step. However, the systematic design process requires seven intermediate steps to determine engineering characteristics from customer requirements. Therefore, under the context of capturing the conceptual design information, it is essential for a requirement-modeling scheme to capture the information found in the intermediate steps. The proposed domain mapping approach is meant to address two fundamental research questions:
Q1: How do NFRs contribute to the design process in a mechanical system?
Q2: Where in the sequence of domains, as presented in the seven-domain modeling scheme, should the NFRs domain be incorporated?
The seven-domain requirements modeling scheme presented in this paper also has limitations:
(a)
The mapping of Step IV (concept variants) to VI (working concepts) is not captured between the domains working principle and components. Note that Step V does not link between Step IV and VI as it serves as an evaluation (both technical and economical) of the concept variants developed in Step IV. If the concept variants pass evaluation, they continue to working concept, however no linking exists.
(b)
The use of ‘component’ domain extends itself into the embodiment design stage. The primary step in the embodiment design stage is to identify the embodiment determining requirements such as spatial constraints, safety, ergonomics, production, and assembly requirements (Ullman et al. 1988). The model does not consider these non-behavioral requirements.
(c)
The model assumes that components are manifested only from functional requirements. This assumption may not hold true due to the limitation stated above in (b).
Various requirements modeling approaches in (Mocko et al. 2007a) have been reviewed extensively for their performance ability in factors such as elicitation, analysis, allocation, traceability/tracking, verification/validation, taxonomy, and propagation. The seven domain requirement modeling scheme, referred to as the existing modeling scheme in the following sections, is developed to potentially overcome limitations identified with various requirements modeling approaches reviewed in (Maier et al. 2007).
Advertisement
This manuscript is segmented into six sections where the first and current section detail the research gap and motivation. The second section will provide a background on functional and nonfunctional requirements with details on their use in engineering design practices. Further, a discussion on their impact on engineering change management is presented. The third section will detail the case study method employed to address the aforementioned research questions. The results of the case study and analysis are presented for each of the two research questions in sections four and five. Section six of the paper will present the conclusions and potential future work in the nonfunctional requirements domain based on the findings and recommendation of this research.
2 Background on functional and non-functional requirement
When discussing requirements here, the authors more precisely mean desiderata. Desiderata is defined as “something desired as essential”,1 “something lacked and wanted”,2 and “something you desire or want”.3 The authors include constraints and criteria; desired goals and hopes or wishes; and objectives and filters. Thus, we broadly define a requirement as synonymous with desideratum. In the literature that addresses classification of requirements, there appears to be a broad consensus with respect to the definition of Functional Requirements (FRs). The definition for FRs is what a product must do, be able to perform, or should do. In each of these, functional requirements describe action and doing. Others have slightly refined this view by positioning that the FRs are the desired and resulting behaviors of the system (Gero and Kannengiesser 2004; Glinz 2007). This consensus does not appear when discussing Non-Functional Requirements (NFRs) (Sommerville and Kotonya 1998; van Lamsweerde 2001; Chung and Leite 2009; Glinz 2007; Davis 1993; Mylopoulos, Chung, and Nixon 1992). From various points of view, NFRs refer to system quality attributes (Gross and Yu 2001), goals (Roman 1985), and constraints (Glinz 2007; Chung and Leite 2009). In a linguistic analysis approach to requirement representation (Lash et al. 2012; Lamar 2009), another point of view is developed suggesting that non-functional requirements are defined with “being” and “possession” predicates, such as “the vehicle must have four wheels” or “the vehicle clearance must be 18 inches”. Thus, there is no consensus in NFRs’ definition.
2.1 Use of requirements in engineering design
Requirements are the backbone of all engineering design projects and are often contractually binding between designer(s) and stakeholders. The Rational Unified Process defines a requirement as “a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document” (Diev 2007). Further, The International Council on Systems Engineering (INCOSE) defines requirements as statements that identify system or product constraints deemed necessary for stakeholder acceptance (INCOSE 2015). The role of eliciting requirements is thus critical to the design process as it defines what functions a system must accomplish and the associated system characteristics it should possess (McLellan et al. 2010; Diev 2007). Typically, requirements elicitation is formed through system decomposition and determining requirements both at the subsystem level and interaction between subsystems (Worinkeng et al. 2015; Pahl and Beitz 2013). Throughout the design process, requirements continue to evolve and have an influence on several downstream design activities (conceptual development, QFD, testing, etc.). Near project completion, requirements are used significantly in the verification and testing phase to ensure the developed system meets all intended requirements.
In the model presented by Mocko et al. (2007a; b), and in most engineering design processes, requirement generation occurs early in order to drive the development of conceptual models and final designs. Properly defining requirements early can save significant time and resources later in the design process (Maier et al. 2007). In an enhanced version of this matrix driven approach developed by (Maier et al. 2007) additional matrices between indirectly related domains are also used to provide feedback on later stages of the design process. Two of these additional matrices are requirements to components, in order to confirm that the generated components fulfill all requirements, and requirements to tests to verify the consistency of the model. This addition ensures that requirements are considered and referenced through the design process. While several classifications for requirements exist, often they are classified as functional or non-functional requirements.
2.2 Functional requirements
Prior research has recognized the difference between functional and non-functional requirements (Shankar et al. 2010; Chung and Nixon 1995). FRs describe what a system must do, meaning that an action should be present in the requirement. They can also be thought of as a set of inputs, a required behavior, and a set of outputs. Common examples of FRs could be the acceleration performance of a vehicle in automotive systems or the amount of airflow outputted by a ceiling fan. FRs are often identified earlier in the design process as they are performance focused and, as a result, drive the remainder of the design. There are formal mechanisms for establishing functional requirements in design in the designing process (Pahl and Beitz 2013).
In many instances, FRs are provided explicitly by the stakeholders with minimal changes necessary. The challenges that do tend to arise are problems of understanding (Christel and Kang 1992) in which the customer has a limited understanding of capabilities of the system, or what is necessary to accomplish a task.
2.3 Non-functional requirements
Non-functional Requirements (NFRs) have varied definitions, and have received significant attention in recent years due to their importance within systems and software engineering (Zhou 2004; Borg et al. 2003). Most authors agree that, as opposed to FRs, NFRs describe how the system will accomplish its goals and objectives, rather than how it will specifically perform. Common types of requirements that are classified as NFRs include a system’s reliability, security, accuracy, cultural factors, and other descriptors that do not necessarily describe actions that must be taken by the system (Broy 2015). Some of the recent attention to NFRs has included new methods of automatic identification and classification (Dabbagh et al. 2015), as well as case studies to determine their relative value to a project compared to other requirements. Neglecting NFRs has been identified as a major threat to projects (Lawrence et al. 2001), either due to NFRs exclusion or lack of detail, which prevents their proper utilization throughout the design process.
One of the most difficult factors affecting NFRs is their elicitation. Often, NFRs are not explicitly provided by stakeholders, or are provided in ways where they may not be immediately recognized as requirements (Zhou 2004). Another problem that plagues NFRs is that they tend to be vague and nebulous, making them difficult to verify. 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 NFRs and their benefits (Borg et al. 2003).
2.4 Environment and stimuli approach to functional requirements
For this research, a different approach to distinguishing between FRs and NFRs is adopted—inspired from an approach used to describe an artifact in ‘Sciences of the Artificial’ (Simon 1998). Based on this, artifacts can be viewed as artificial things that can be characterized in terms of functions, goals, and adaptation. An artifact’s function may be to reduce hot fluid temperature, such as radiator. Its goal is to provide cold fluid to the power plant for its continued operation by adapting to various ambient conditions, such as extremely cold to extremely hot environments. This artifact is said to achieve its goal when its function adapts. Does it mean that the end user of the artifact will be satisfied if the artifact stops achieving its goal after 100 h of power plant operation? It depends upon how the goal is defined in terms of end user’s operational aspiration level. Thus, ignoring the user’s aspiration level for an artifact’s operation during the design process will lead to a product that functions but not meets the goal. The term ‘adaptation’ is not necessarily limited to operating conditions as mentioned above; it may encompass a broader meaning, which will be explored in the following paragraphs.
An artifact can be separated into inner and outer environment, to a greater or lesser degree, in all large and complex systems (Simon 1965). The action or reaction of the substance in the inner environment with or without external stimuli when an artifact is in ‘use’ can be understood as an artifact’s ‘function’. Authors attribute this term to the inner environment of an artifact, and the term non-functional refers to the outer environment. For instance, a vibration isolator absorbs externally applied forces (stimuli). The inner environment for an isolator is its substance (chemical compounds and geometry). If this isolator is subjected to loads during its assembly process, it will not be considered as a function based on the above definition. Other researchers have also considered functional requirements as the interaction between the artifact and its environment (Burge and Brown 2002; Roman 1985).
To meet the artifact’s overarching goal, the inner environment should be compatible to the outer environment or vice versa. For an isolator, its chemical compounds and geometry are selected and designed to match a type of loading (random or deterministic), humidity (use environment), and temperature (use environment), which falls in the outer environment. In another example, the use of a gravity-fed ballpoint pen in a spacecraft is not appropriate. In this case, the inner environment, which should allow flow of ink under gravity, does not match with the surroundings in which it is operated, but the pen will work satisfactorily on land. In this example, the goal to have an instrument to document in space has not been achieved as the function did not adapt to the outer environment. A different inner environment should have been selected to suit the outer environment. Thus, compatibility between inner and outer environment is critical, for it is the condition for adaptation.
Outer environment is not limited only to the surrounding in which an inner environment is operated. There exist multiple layers that an inner environment should match with before meeting its goal. After conceptually identifying the inner substance of an artifact within spatial constraints, it has to be physically realized through a set of processes (manufacturing) and evaluated to meet end user’s aspiration level (quality). In the ongoing ballpoint pen example, the spatial constraint is derived from the user. A concept may very well be functional, but if it can be achieved only at a much larger dimension than the spatial constraint, which is non-functional, then it loses compatibility with the outer environment or in other words failed to adapt.
On successful evaluation, the artifact should be made available to the end user through available transportation means (shipping). Further, when in use, it should be easy to maintain (service). Moreover, the artifact should be capable of being used in one or more geographical locations under fixed or varying user patterns (user variability). Thus, the term adaptation may refer to several layers from manufacturing to service, and clearly, a function has to adapt to these layers before the artifact has met its goal.
The concept of non-functionality has strong association with respect to a frame of reference within or between multiple artifacts of a system. For instance, a vehicle requires an artifact to withstand the load applied by another interacting artifact that provides enclosure for passengers (vehicle chassis and body). Such an artifact is termed as chassis and its inner substance (inner environment) is so designed to withstand the load applied by the interacting artifact. The chassis will be subjected to corrosive environment, so the manufacturer decides to paint the chassis with protective coating. With the chassis as a frame of reference, the action it performs is to withstand the applied load. Is it compatible with the outer environment? Yes, as a protective coating is applied to the artifact to establish compatibility between inner and outer environment. In this case, the need for a protective coating is a non-functional requirement.
Allow the frame of reference to move to protective coating. Does it perform an action or reaction with or without an external stimulus? Yes, it prevents its outer environment, which is chassis, from corroding through an external stimulus of salty atmosphere. In this case, the inner environment is the protective coating, and it has to be compatible with outer environment, which is the chassis. Therefore, a description of the chassis’ material becomes a non-functional requirement while designing a solution for protective coating. If a protective coating is designed for a material to which it cannot adhere, the coating will not work. The protective coating should be designed so that it is perfectly compatible with the chassis (outer environment) in order to meet its goal. Therefore, the frame of reference is critical and essential for defining what non-functional requirements are. With this notion of an artifact’s characterization, non-functional requirements are defined here as follows:
“A description of the outer environment to which an artifact should be compatible while performing its intended function by its intended users.”
2.5 Impact of engineering change on requirements
As this study will utilize engineering change as a mechanism for formalizing non-functional requirements, it is important to recognize the relationship between engineering change and requirements. As design is a naturally dynamic process, (Dym and Little 1999; Andreou et al. 2003; Cohen et al. 2000; Kannapan and Marshek 1992; Ottosson and Björk 2004), requirements will evolve likewise. This evolution in requirements may stem from various types of engineering changes: time, performance, cost, etc. Prior research has indicated over 50% of a design project’s requirements will change prior to completion (Kobayashi and Maekawa 2001; Ramzan and Ikram 2005). To mitigate the potential loss due to requirement changes, formal change management approaches are recommended that predict unanticipated change propagation (Morkos et al. 2012; Hein et al. 2018; Hein et al. 2015). While requirements may not always be the source of change, engineering changes are often implemented that in turn affect requirements. To study this, relevant research has yielded a strong relationship between engineering changes to requirement changes (Shankar et al. 2012).
While there are differences in what FRs and NFRs offer to the design process, there are also differences in how their requirements network typology, which impacts how traceability occurs during requirements change. Requirements are typically generated in a hierarchical manner, where requirements are linked to parents and child requirements. This is observed when a product possess system level target requirements, which necessitate child requirements necessary to meet those targets (subsystems). Likewise, those subsystem level requirements necessitate component level requirements. The result is a requirements network with requirements that possess parent/child nodes. Requirements that do possess parents and children notes may be related to specific functional requirements where a subsystem, such as Motor, may include components such as Intake, plenum, and exhaust. Each one of those components will possess at least on requirement (a child node) necessary to verify the component. However, not all requirements possess a parent/child node relationship. Consider requirements related to business (cost, profit) and regulation (safety, reliability) where the source is a standard or specific customer need. It is important to distinguish such requirements as NFRs are often rooted in requirements that do not possess parent and children nodes. This is relevant as lacking parent nodes tracing—a necessary element of change propagation—more challenging for NFRs. Further, the lack of source nodes makes NFRs difficult to negotiate as they appear as fixed requirements will limited margin for flexibility.
3 Case study
A case study is used in this research as it is an empirical research method used to investigate a contemporary phenomenon, focusing on the dynamics of the case, within its real life context (Yin 2003; Roth 1999). Specifically, the role that NFRs have in an industrial oriented development project is of interest, rather than hypothetical design situations or academic exercises. Case studies are widely deployed in design research (Flyvbjerg 2006; Sheldon 2006; George and Bennett 2005; Roth 1999). Several design methods have been developed based on the extensive observation in industry and from the result of large formal and informal case studies (Teegavarapu et al. 2008a, b; Frost 1999; Pahl and Beitz 2013; Morkos and Summers 2009; Morkos et al. 2010). Hence, a case study approach is used to address the research questions.
3.1 Industry automotive OEM bumper redesign case study
An industrial case study from an automotive Original Equipment Manufacturer (OEM) is considered. The case study is conducted as a “participant-as-observer” in which one of the authors worked as an engineer at the OEM, a school bus manufacturer in the United States. The development project was initiated as a cost reduction proposal for an existing product. This project involved a senior management team from the design department, managers in manufacturing, a validation team, production workers, and representatives from service and marketing. The project objective was to develop a rear-bumper re-enforcement at a reduced cost. The goal for this project was not to realize incremental improvements through product evolution, rather it was to realize significant gains through revolutionary product design. A de novo solution is sought for which an open-ended approach was taken. Such an approach is required as it provides an opportunity for the designer to follow the steps provided in the systematic design process. A confidentiality agreement limits the details that can be presented in this paper, but documents such as drawings, 3D sketches, discussion notes in the design review meeting, and detailed requirements lists (both qualitative and quantitative) are analyzed in the course of this case study.
3.2 Case study method approach
To address the first research question (Q1: How do NFRs contribute to the design process in a mechanical system?), the design activities in the project are identified and grouped into different domains. An activity in the design project is defined as a design activity if it is found either explicitly or implicitly in the systematic design process as it relates to a main working step (Pahl and Beitz 2013). The main working steps that assist designers develop engineering characteristics from customer requirements are identified and presented in Table 1. Note the steps presented in Table 1 present both the previously discussed seven conceptual steps and steps beyond the conceptual design phase. The steps beyond conceptual design phase were incorporated based on the design process followed by the OEM in the bumper design.
Table 1
Domain definitions
Steps
Main working steps identified in systematic design process
Search for working principle (WP) and working structures (WS)
WP and WS
IV
Elicit concept variants (CV)
CV
V
Evaluate against technical and economic criteria
Design review (DR)
VI
Develop working concept (WC)
WC
VII
Identify embodiment determining requirements
NFRs
Preliminary form design, material selection and calculation
Design Parameters (DP)
Select best preliminary layouts, refine and improve layout
Component (C)
Evaluate against technical and economic criteria
Design review (DR)
Prototype (PR)
PR
Test
T
Figure 2 illustrates the protocol used for determining the significance of the NFRs. First, the data sources involved in the case study are collected, which include: CAD files, e-mails exchanged, reports from the design reviews, meeting minutes and participant notes, and presentations. Each of these data sources are analyzed by the participant to determine three conditions: (1) does the design activity involve an engineering change or design decision, (2) which factors are involved in leading to this change or decision, and (3) which domain is associated with the influencing factors. Should a factor be identified as belonging to the NFR domain, then it is concluded that NFRs are needed for this design activity. In this manner, the design activities that led to a design change, and/or influenced the decision-making process are analyzed to identify if they are influenced by NFRs. The result of this analysis determines the involvement and the need to consider the NFRs in the existing modeling scheme.
Fig. 2
Case study protocol to determine NFR significance
×
In accomplishing the analysis on each of the data sources, the participant would first determine whether or not the item in question contained a requirement. If a requirement were found, the participant would define the requirements frame of reference and what it describes contextually. Further, the participant would answer questions about whether or not the requirement described an action or reaction when being used how it was intended and who or what the actors and reactors are. Once these have all been found, the participant must decide on if the actors, reactors, and components mentioned are in the same frame of reference. If they are, then the requirement is determined to be in the “outer environment,” and thus, an NFR. If not, then it is contained within the “inner environment,” and so, is designated a functional requirement.
Within each step of the conceptual design phase, there may exist multiple design activities for which specific domains are utilized, created, or altered. In this protocol, the design steps are realized through 40 specific design activities. The activities are realized through a sequential order of when documents were generated. If a document (or other formal deliverable) is generated, this was considered a new or existing design activity. Document analysis includes internal reports, e-mails, presentation, design reviews, and GANTT charts. The design activities realized are detailed in Table 2, where the activity # indicate the order of their occurrence (earlier numbers occurred earlier in the design process) and domain indicate which domains were utilized, created, or altered during the activity.
Table 2
List of design activities
Activity #
List of activities
Domain
1
Requirements gathering (design requirement document, etc.) (only functional requirements available from NSTSP standards)
Performance test conducted to verify strength aspect (physical test)
T
30
FEA reports received
T
31
Concept refined based on performance test and FEA test
WC
32
Release of conceptual prototype (2) drawings
PR
33
Conceptual prototype (2) received
PR
34
Fitment trials conducted in the vehicle
T
35
One out of two concepts selected after fitment trials. One of the concepts was not accepted due to manufacturing constraints
WC
36
Tests conducted as per the developed DVP
T
37
Tool dub samples requested for pilot test
T
38
Pilot test conducted
T
39
First formal drawing release issued with an engineering release note
NFR
40
Production break in
#—Functional requirement
To address the second research question (Q2: Where in the sequence of domains, as presented in the seven-domain modeling scheme, should the NFRs domain be incorporated?), the information flow between the domains is analyzed. A Design Structure Matrix (DSM) (Browning 2001; Kumar and Mocko 2007) is used to analyze the information flow between each activity within the design project and is shown in Fig. 3. The sequencing of the domain is determined based on the information flow between the domains. Since the activities are sequenced in their chronological order of occurrence, the order in which the information flows to subsequent domains is the order in which an engineering domain modeling scheme should follow. The outcome of this analysis is a general sequence of domains. This sequence of domains can be compared with an existing modeling scheme (Maier et al. 2007). The decision of where to include the NFRs will be determined based on this comparison.
Fig. 3
Design activity DSM—capturing dependency/information flow between activities (read as column to row)
×
3.3 Activity to domain mapping
Activities #1 and #2 are identified within the FR domain and pertain to gathering and clarifying requirements. The National School Transportation Specifications and Procedures (NSTSP) document (Missouri Safety Center 2010) details requirements for school bus OEMs. From these regulations, two FRs for the bumper is identified. Additional NFRs are defined for the rear bumper based on the regulation. The FRs is used to develop the concepts for the bumper re-enforcement. No additional functional requirements are defined in the course of the project. A total of 33 NFRs are generated during the project; where an abridged list is documented in Table 3.
Table 3
Abridged requirements document
Req. no.
Requirement
Type
Justification
Requirements from NSTSP document
R1.1
The bumper on Type A-1 buses shall be a minimum of 8 inches wide (high). Bumpers on Types A-2, B, C and D buses shall be a minimum of 91⁄2 inches wide (high)
NFR
Provides dimensional specifications, a non-action type of requirement
R1.2
The bumper shall wrap around the back corners of the bus
NFR
Provides interface requirements, a non-action type of requirement
R1.4
The bumper shall extend forward at least 12 inches, measured from the rear-most point of the body at the floor line
NFR
Provides dimensional requirements, a non-action type of requirement
R1.5
The bumper shall be braced to resist deformation of the bumper resulting from impact from the rear or the side
FR
Describes what the bumper should do, an action type of requirement
R1.6
The bumper shall be designed to discourage hitching of rides by an individual
NFR
Describes what the bumper should do, an action type of requirement
R1.7
The bumper shall extend at least one inch beyond the rear-most part of the body surface, measured at the floor line
NFR
Provides interface requirements and dimensional specification, a non-action type of requirement
R1.9
The bumper shall be of sufficient strength to permit being pushed by another vehicle of similar size and being lifted by the bumper without permanent distortion
FR
Describes what the bumper should do, an action type of requirement
Internally generated requirements
R1.11
The bumper should be durable for ten years
NFR
Describes the quality of the bumper, a non-action type of requirement
R1.12
The modified design should not induce change in the manufacturing process
NFR
Describes a manufacturing requirement, a non-action type
R1.13
The ease of accessibility during assembly should be maintained
NFR
Describes a manufacturing requirement, a non-action type
R1.14
Bumper should be adjustable in the assembly line to suit the body alignment
NFR
Describes a manufacturing requirement, a non-action type
R1.15
The bumper reinforcement design should not exceed assembly time of X seconds
NFR
Describes a manufacturing requirement, a non-action type
R1.16
The modified design should use only the existing assembly tool for assembly
NFR
Describes a manufacturing requirement, a non-action type
R1.19
The modified bumper reinforcement should be common across the product family
NFR
Describes a commonality constraint, a non-action type
The requirements listed in Table 3 are classified into FRs and NFRs by following a protocol, which is shown in Table 7 in Appendix A. Three raters followed this protocol to determine what type of requirement each one of them belongs. Subsequently, an inter-rater reliability using joint probability agreement method is used to measure agreement among three authors. Such measures are widely used in engineering design research to verify and test the robustness, repeatability, and stability of coding protocols (Linsey et al. 2010; Worinkeng et al. 2013; Song and Agogino 2004; Oman and Tumer 2010). The inter-rater reliability results indicated a 93% consensus among authors whether a requirement describes an action or not from the contextual standpoint. The final list of classification is presented in Table 3.
Each activity was classified within its respective domain, as tabulated in Table 4. Conventional methods for searching working principles such as studying benchmark reports (activity #3) and reviewing literature (activity #4)—which includes published journal; peer reviewed conference papers; and books—and intuitive methods are used to develop concepts (activity #5). Thus, these three activities are grouped under WP domain. The activities (#11, #16, #25, #31, and #35) involve developing preliminary layout and its refinement, design refinement, and concept selection pertaining to the development of working principle into working concept; therefore, they are grouped under WC domain. Activities such as design review with the managers and other members in the design team (activities #6, #13, #17, #19) and preparation of Design Failure Modes and Effects Analysis (DFMEA) and Design Validation Plan (DVP) (activity #20) are grouped under design review domain.
Table 4
Design activity domain association and coverage
Domain
Associated activities
FR
1, 2, 7
NFR
7, 8, 9, 10, 14,15, 18, 39
WP
3, 4, 5,
DR
6, 13, 17, 19, 20
WC
11, 16, 25, 31, 35
DP
12,
PR
21, 23, 32, 33,
T
22, 24, 26, 27, 29, 30, 34, 36, 37, 38
The material selection process and preliminary product sizing are based on the limiting stress and layout which involves identification of design parameters; thus, these activities (activity #12) are grouped under ‘design parameters’ domain. The prototype domain includes design activities, such as drawing release for prototype and receiving prototype parts; activities #21, #23, #32, #33 fall under this domain. Finally, the ‘test’ domain includes testing related design activities such as virtual testing (finite element analysis), physical testing, vehicle fitment test, and process simulation test. Nearly 25% of the activities touch this domain (#22, #24, #26, #27, #29, #30, #34, #36, #37, and #38).
4 Q1: analysis to determine the need for NFRs
The driving factors behind a design change or decision-making are analyzed and recorded in Table 5. These influencing factors are used to determine whether NFRs are involved in the specific activity. For example, selecting a working principle (activity #6) is based on the cost, project duration, and technical feasibility—all non-functional. Selecting the material (activity #12) is driven by material availability in the market, cost of the material, ease of manufacturing, and material available with the approved suppliers by the OEM. Again, while these factors constrain the available design space, they are also non-functional.
Table 5
Factors driving design decisions (partial list)
Design activity
Design change
Factors driving design decision
Associated domain
6: Concept review with manager
N.A
Cost, engineering judgment, project duration
NFR
12: Material selection
N.A
Commercially available material, cost of the material, ease of manufacturing, and locally available and approved supplier
NFR
16: Concept refined with a new introduction of part to suit new manufacturing constraints in the earlier step
A new part introduced
Manufacturing constraint
NFR
18: Additional requirements for galvanization and manufacturing accessibility was introduced
Protective coating type, change in the dimensions of the component for facilitating accessibility
Accessibility requirement and environmental constraint
NFR
25: Concept refined to meet manufacturing requirements of safety and ease of assembly
Change in dimension to increase accessibility
Vehicle fitment trials revealed space constraint for the tool accessibility
Process validation in the assembly line revealed the preferences of the line supervisors and their constraints
NFR
31: Concept refined based on performance test and FEA test
Change in dimensions such as thickness and radius
High stress concentration
DP
35: One out of two concepts selected after fitment trials. One of the concepts was not accepted due to manufacturing constraints
N.A
The concept that required the following is selected: No process change, Ease of assembly, Meets all manufacturing constraints such as adjustability, handling, and No tool change
NFR
Refining the concept (activity #16) involved a design change. The design change is to split a component into two to meet a manufacturing constraint. The original integral component was designed to reduce assembly time, number of parts, and cost. However, a requirement from manufacturing engineers to provide adjustability to the integral component necessitated a design change. Hence, a constraint from the manufacturing, which is non-functional, led to a change in the artifact and modified the way the functionality is realized.
Activity #18, the accessibility requirement from the manufacturing and a protective coating requirement from the service department introduced a design change. In this case, the protective coating did not introduce a change in the artifact, whereas the accessibility requirement did. Activity #25, a validation trial in the vehicle, introduced a design change. The assembly supervisor was not satisfied with the level of tool accessibility to the fastener. However, this requirement introduced a minor change in the size of the component. Activity #35, is a concept validation trial in the assembly line, restrained the author from selecting a concept that had potential to save higher cost per component. The concept required a change in the assembly sequence. The space constraints in the shop floor restricted the assembly line supervisors from accepting it. In activity #27, a concept is validated with the existing process. The assembly line supervisors expressed their concern in the order of assembly, the torque requirement for the fasteners for the tools they possessed, the ease of assembly by the operator, and the ergonomic factors. This introduced a design change and hence, a change in the artifact.
These design decisions are driven by the non-functional requirements. It appears that some NFRs act as constraints and some as goals. The NFRs evolved as the design progresses, both with new NFRs added and with targets changing. In addressing the first research question, Q1, the NFRs, being evolving in nature and exhibiting a significant role in the product development process, should be included in the modeling scheme unlike the existing modeling scheme.
5 Q2: placement of NFRs domain in the existing modeling scheme sequence
With the domains are explicitly identified with the activities, including their influence on the decision-making or engineering changes, the flow of information through the domains may be examined. The activities are divided into two sets for ease of analysis. The first set includes design activities #1 through #12. The ‘working principle’ domain uses requirements gathered (activity #1) and clarified (activity #2) from the ‘functional requirements’ domain. This information is used to develop working principles along with the benchmark reports (activity #3) and literature review (activity #4). The information flow between these two domains is sequential. The selection process of the working principle is through the design review (activity #6). This activity included involving senior managers and the chief engineer of the design team. Each of the proposed working principle is reviewed and selected based on the factors such as cost, engineering judgment, and project duration. The design review also supported gathering performance and legal requirements (activity #7, #8). The outcome of the design review is the selection of a working principle and elicitation of performance requirements, manufacturing constraints, and durability requirements. Each of these is classified as NFR as they are non-functional. Past records of test history are gathered to identify performance requirements (activity #9) and finalized with a design review (activity #10). The NFRs domain receives information from the DR domain and passes information to ‘working component’ domain. The concept development activity, associated with the WC domain, involved sizing the product artifact using mathematical models, stress analysis using first principles, and layout analysis using Computer Aided Design (CAD) models (activity #11). Material selection (activity #12) is driven by the factors such as commercially available material, cost of the material, ease of manufacturing, and locally accessible and approved suppliers. It uses information from the NFRs domain and this information is passed on to the ‘working component’ domain.
Therefore, the ‘working component’ domain uses information from the NFRs and ‘design parameters’ domain. Four working concepts are developed based on the selected working principle, materials selected and the elicited NFRs. In Fig. 4 the information flow between defined domains in the existing modeling scheme are shown in solid lines while information exchange between a defined and a non-defined domain in the existing modeling scheme, such as design review, is shown in dotted line.
Fig. 4
Information flow diagram
×
The second set includes design activities #13 through #40. Two of the four working concepts are evaluated in a design review meeting within a team of design managers and a chief engineer (activity #13). The working concept selection is based on the factors such as the working concept’s potential to meet the performance requirements, cost of the system, ease of manufacturability, potential to suit the existing assembly line, ease of assembly, and serviceability. The outcome of the design review included elicitation of manufacturing and serviceability constraints, and suggestions to study the existing manufacturing process. The cost of the selected working concept is estimated (activity #14) and the potential cost savings are determined. As an outcome of the design review meeting, a study is conducted to determine the manufacturing constraints of the existing assembly line (activity #15). The outcome of the study is the identification of assembly line constraints. The constraints are documented in the requirements document. Therefore, 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). The selection of the working concept is included in the domain ‘working component’. The study of manufacturing process and the determination of the manufacturing constraints necessitated a change in the design (activity #16). An integral form of design is split, and a new component is introduced. The modified design is again examined in a design review meeting and two additional requirements are elicited (Req. 17 and 18). Of the two requirements, one addressed the protective coating and the other detailed the tool accessibility during the assembly process. The two elicited requirements are again classified into the NFRs domain. A design review is conducted with senior management for program approval (activity #19). The design activity (#20) includes the DFMEA document, development of a DVP. The nature of the design activity includes gathering a team and considering their views on the design and the type of test to be conducted. Thus, it is included in the domain ‘design review’. The release of prototype drawing (activity #21) and receiving prototype from the supplier (activity #23) is grouped under ‘prototype’ domain based on the nature of design activity. A virtual validation Finite Element Analysis (FEA) is requested and this design activity (#22) is grouped under test domain.
The prototypes are fitted in the vehicle (activity #24) and qualitative opinion of the line operator is recorded for the ease of assembly and safety concerns during the assembly operation. The prototypes are also used to simulate the assembly process in the assembly line (activity #26). Fitment trial in the vehicle and assembly process simulation activity is also a form of validation and therefore it is included in the test domain. The drawbacks in the design to meet the process constraints are identified and the concept is refined with the information obtained from the prototype (activity #25, #27). The outcome of the prototype activity is also a set of NFRs and therefore included in the NFRs domain. The concept is refined (activity #31) based on the performance test (activity #29), and FEA report (activity #30). The second concept prototypes are built (activity #32, #33) and fitment trials are conducted in the vehicle (activity #34). One of two concepts is selected based on the manufacturing review (activity #35).
Testing is performed on the selected concept (activity #36). A pre-production trial is conducted (activity #39) using tooling samples (activity #38). Tooling samples are created based on the engineering drawing meant for production (activity #37). Finally, on successful completion of production trial, the introduction date of the new design in full production is decided (activity #40). The information flow pattern encompassing this group of design activities is represented in Fig. 5 where red lines indicate the information flow identified while analyzing the second set of information.
Fig. 5
Information flow diagram
×
Most design activities pass information to the next subsequent activity without feedback, the exceptions being design activities #13, #15, #18, #24, #26, #29, #30, #36 and #38. The domains which possess feedback are presented in Table 6. The other activities are sequential. Activities #15 and #18 are the requirement elicitations of manufacturing constraints, ease of assembly, and protective coating requirements. This information is included in the requirements document and therefore captured as a feedback to requirements gathering (activity #8). Activities #24 and #26 is the fitment trials conducted in the vehicle and the process simulation with the prototypes. These activities revealed manufacturing constraints such as ease of accessibility, assembly steps, alignment constraints, safety issues, and compatibility of the design with the existing manufacturing tools. The results of the performance test and FEA are used to conduct minor modifications to the design. It is observed from the analysis that NFRs domain receives information from the design activities as the design progresses.
Table 6
Domain receiving feedback information
Information from design activity #
Domain source
Information to design activity #
Domain sink
29, 30, 36, 38
T
7
NFR
13
DR
7, 8
NFR
9, 15, 18
NFR
8
NFR
24, 26, 38
T
8
NFR
6 Conclusion and dIscussion
The analysis performed has led to the development of a proposed sequence of domains that explicitly incorporates NFRs. The traditional requirements domain is split into a functional and non-functional requirement domain. Further, both the functional requirement and function domain is captured in the FR domain. The functions and function structures proposed in various engineering textbooks (Otto and Wood 2001; Pahl and Beitz 2013; Ullman 2010; Ulrich and Eppinger 2008; Suh 2001) can be considered to be functional requirements. These might be solution specific or higher-level solution independent requirements. Regardless, the functionality of a system is captured in the functional requirements domain. Finally, a prototype domain is identified in this analysis. It appears that the inclusion of this domain captures information regarding the type of prototypes built to test different components. The need to consider the ‘prototype’ domain in the modeling scheme is out of scope in this paper, but an interesting observation from this case study.
The complete information flow diagram is presented in Fig. 6 from this research. The ‘design review’ domain is not included in this modeling scheme as the information within this domain is more conversational than recordable. As ‘working principle’ receives information only from ‘functional requirement’ and ‘design review’, the NFRs cannot be sequenced between these two domains. However, ‘working component’ receives information from NFR, ‘working principle’, and ‘design parameter’. Therefore, the NFRs can be sequenced between ‘working principle’ and ‘working component’. In order to capture explicitly the effect of NFRs on ‘working component’, the ‘design parameter’ is sequenced after the ‘working component’. All information exchange between NFRs and ‘working component’ cannot be captured through ‘design parameter’. Thus, the NFRs domain can be incorporated between ‘working principle’ and ‘working component’ from a linear, sequential point of view.
Fig. 6
Overall information flow of the design project
×
The analysis of the design activities in an industrial design project reveals there is evidence that NFRs drive design decisions, acting as goals for the design and constraints on the solution. Finally, they modify the manner in which the functionality of a system is realized. Thus, it is essential to consider the NFRs domain as a distinct domain within mechanical engineering design. Of several NFRs, the most important that drive functionality realization are:
(i)
The cost of the design solution;
(ii)
The feasibility of the design solution to meet durability requirements at an acceptable cost target;
(iii)
The feasibility of the design solution to be manufactured with the materials possessed by company’s approved list of suppliers;
(iv)
The feasibility of the design solution that can be assembled using existing processes and tools; and
(v)
Spatial limits.
In the case study presented in this research paper, each of the aforementioned NFRs had significant impact in the way functionality is realized. Considering these requirements early in the design process along with FRs will enable appropriate concept generation and selection which can be developed further to meet company goals within their project budget and timeline. Other NFRs such as accessibility, serviceability, and maintainability were considered important, but the team was often willing to take a satisficing solution if the benefits of satisfying other NFRs outweigh the risk of trading off NFRs. To this point, these requirements are considered in detail after a concept takes a preliminary shape and attains a maturity level where it is worthy to invite service and manufacturing engineers to review the design. As NFRs evolve during the development process, it is essential to consider the five important NFRs listed in the beginning of this paragraph during the concept development stage while other NFRs can be evaluated and traded off at later stages of the design.
The sequence in which the NFRs should be incorporated in the modeling scheme is also identified from the analysis where the NFRs domain should be sandwiched between the ‘working principle’ and ‘working component’ domains, as illustrated in Fig. 7. This conflicts with the current best practice encoded in engineering design texts that argue for the elicitation of all requirements at the initial stages before design decisions have been made.
Fig. 7
Proposed requirements modeling scheme
×
The modeling scheme proposed in this research and the modeling scheme proposed in (Maier et al. 2007; Mocko et al. 2007a) are compared with respect to their domains in Fig. 8. Introducing NFR in the requirements modeling scheme modifies the sequence in which the conceptual design information is captured. The new sequence is shaded in gray to differentiate the difference from the modeling scheme proposed in by (Maier et al. 2007; Mocko et al. 2007b).
Fig. 8
Comparison of information domains captured in requirements modeling schemed
×
6.1 Future works in NFR research
In order to further the impact of this research, we would like to recommend that the modified requirements modeling scheme presented here, backed up by the preliminary evidence from this case study, be used in future studies on more industry applications. Using the modified scheme, we are able to see how the non-functional requirements domain is directly related to the working principle domain and the working components domain, which can model information flows both downstream and upstream through those domains. In particular, we recommend that quantitative measures be investigated in order to provide more data that either supports, or denies, how useful the model is and the influence that NFRs have on engineering design. These quantitative measures might be found by investigating how information flows between domains, whether upstream or downstream through the NFR domain, whether NFRs change over the course of the design process and, if they do, what percentage of them changed and how often they were changed over the course of the project, and even how likely NFRs are to pass design changes to other requirements, functional and non-functional alike. Implementing these quantitative measures in future research would greatly reduce the limitations of this research and would provide more incentive for industry professionals to adopt NFR analysis earlier in their design processes.
Open AccessThis article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Protocol to Determine FRs and NFRs with a Sample List
Req. no.
Requirement
Frame of reference
What does the requirement describe contextually?
Does the requirement describe an action/reaction when it is in use by the intended users?
If you answered yes in the previous column, is there an external stimulus? Who/what is it?
Who is doing the action in response to external stimulus?
Is the action 'doer' and the component mentioned in the frame of reference the same?
If you answered 'No' to the previous column or to column 'H', then write 'outer environment' in the cell or 'inner environment'
Requirements from NSTSP document
R1.1
The bumper on Type A-1 buses shall be a minimum of 8 inches wide (high). Bumpers on Types A-2, B, C and D buses shall be a minimum of 91⁄2 inches wide (high)
Bumper
Describes the size of the artifact
No
N/A
N/A
N/A
Outer environment
R1.2
The bumper shall wrap around the back corners of the bus
Bumper
Describes the shape of the artifact
No
N/A
N/A
N/A
Outer environment
R1.4
The bumper shall extend forward at least 12 inches, measured from the rear-most point of the body at the floor line
Bumper
Describes the size of the artifact
No
N/A
N/A
N/A
Outer environment
R1.5
The bumper shall be braced to resist deformation of the bumper resulting from impact from the rear or the side
Bumper
Describes the action performed by the artifact when it is in use by the intended users
Yes
Yes
External impact
Bumper
Yes
Inner environment
R1.6
The bumper shall be designed to discourage hitching of rides by an individual
Bumper
Describes the action performed by the artifact when it is in use by the intended users
Yes
Yes
Hitchers
none
No
Outer environment
R1.7
The bumper shall extend at least one inch beyond the rear-most part of the body surface, measured at the floor line
Bumper
Describes the size of the artifact
No
N/A
N/A
N/A
Outer environment
R1.9
The bumper shall be of sufficient strength to permit being pushed by another vehicle of similar size and being lifted by the bumper without permanent distortion
Bumper
Describes the action performed by the artifact when it is in use by the intended users
Yes
Yes
Another vehicle
Bumper
Yes
Inner environment
Internally generated requirements
R1.11
The bumper should be durable for 10 years
Bumper
Describes aspiration level of end user's expectation on performance
No
N/A
N/A
N/A
Outer environment
R1.12
The modified design should not induce any change in the manufacturing process
Bumper
Describes a set manufacturing process within which an artifact has to be designed
No
N/A
N/A
N/A
Outer environment
R1.13
The ease of accessibility during assembly should be maintained
Bumper
Describes shape and size of the artifact
No
N/A
N/A
N/A
Outer environment
R1.14
Bumper should be adjustable in the assembly line to suit the body alignment
Bumper
Describes the action to be performed by the artifact when it is manufactured
Yes
Yes
Operator
Bumper
Yes
Inner environment
R1.15
The bumper reinforcement design should not exceed assembly time of X seconds
Bumper
Describes a set assembly time that an artifact should adhere to
Yes
Yes
Operator
None
No
Outer environment
R1.16
The modified design should use only the existing assembly tool for assembly
Bumper
Describes the assembly tools that will be used for assembling the artifact
No
N/A
N/A
N/A
Outer environment
R1.19
The modified bumper reinforcement should be common across the product family
Bumper
Describes where the newly designed artifact will be used
