ON NEW NECESSITY-BASED METHOD FOR REQUIREMENTS LIST ELICITATION AND REQUIREMENTS CLASSIFICATION

Original scientific paper Establishing appropriate requirements is essential in early phases of product design for obtaining enough information and in order not to over-constrain the product. Consequences of failing to do so are discussed. An overview of state-of-the-art methodologies for eliciting and classifying requirements is presented. Existing elicitation methods tend not to focus on the requirements content and the classification methods overlook the missing requirements. To overcome this gap a new method for requirements elicitation and classification is proposed. It defines the universally necessary requirements, productspecific necessary requirements and optional requirements. The appropriateness of the method is verified with a case-study on air ventilation register box and expert opinions. The positive contribution of the method is confirmed through evaluation with novice design engineers.


Introduction
Requirements are usually the initiators of commercial product design.Their elicitation is a key task of early stages of the product design process [1].It is rather challenging for a design engineer at that point of the design process to define all the requirements that will be needed later on and simultaneously not to over-constrain the designed product.In this phase it is important that the product and its certain characteristics are clearly defined.However, there must be left enough undefined characteristics, which lead to creative and successful phases of conceptual design, embodiment design and other later stages of the product design process.The requirements, elicited during the early phases are gathered and documented in the so called requirements list (RL).This is the final document of these phases which is frequently referenced later on in the process [1].
The question studied in this research is which product characteristics are the ones that need to be defined in the earliest phases of the process and which of them can be defined later.More accurately, which methodology would help a design engineer find the necessary requirements to be defined in the RL?In this paper the existing methodologies are presented, which show that there exists the need for a new method for identification of necessary requirements.A proposal of such new method is presented.
Throughout this paper the term "necessary requirements" suggests requirements that mean significant additional cost and time to the product developing company, if they are not defined in the earliest phases.It is known that if requirements are poorly defined in the early phases, then the process of product design must take several iterations in order to define such requirements after the process has already moved to later phases [2].This elongates the whole product design process and causes additional costs for the company.Therefore, a necessary requirement is the one that does not overconstrain the product and on the other hand its absence from the RL causes additional costs and work to the company.
Another aspect of the problem that has been investigated is the definition of necessary requirements for different products.Nowadays design engineers are faced with the challenge of designing a great variety of products with very different characteristics -static and dynamic, very large and micro-sized, etc.Therefore, the methodology, which would enable finding all the necessary requirements to be included in the RL, should be applicable to the mentioned variety of products.This implies that the necessary requirements are to be split into universal and product-specific.
Until now only scarce research has been conducted on the identification of requirements that should be defined in the RL and connected issues.Published research is thoroughly examined and presented in Sections 2 and 3. A serious lack of guidance towards establishing an appropriate and relevant RL has been recognized through critical analysis of the literature.

Consequences of under-and over-constraining the product in early phases of product design process
It is natural for some requirements to be defined right at the outset of the product design process, for instance the constraints of the manufacturing company or the requirements explicitly stated by stakeholders.However, not all requirements can be defined in such a straightforward manner.We look into two issues with defining the initial requirements: not defining all the important requirements (under-constraining) and defining too many requirements (over-constraining).
We define under-constraining a product as not identifying and determining all the necessary requirements.If a necessary requirement is not defined in the RL, then an additional iteration incurs in the product design process with the purpose of defining the missing necessary requirement.This additional iteration causes additional costs and elongates time-to-market.According to [3], fixing errors from early phases of product design process takes about 30.% of the whole product development time.As a result, product development projects often exceed initially planned times, which is reflected in significant reductions in gross profits.In [4] authors refer to this problem as over-framing and it is recognized and discussed also in [1] and in [5].
Under-constraining the product in the earliest phases occurs because not all the requirements that are indeed present are also obvious.This issue is very well observed from the Kano method [6], which recognizes such requirements as "unspoken" (Kano method is briefly discussed also in Section 3).Another group of the necessary requirements that tend to be missing in the initial RL are the ones, which are so obvious that they will most probably not be mentioned in the RL elicitation process, but should nevertheless be fulfilled.
The reason for missing the requirements at the point of RL elicitation is often the lack of experience of the design engineer.For instance, authors of [7] recognized a problem that designer novices can misinterpret some signs and therefore can lead the design process into a suboptimal direction.In [8] authors also state that the product design problem is ill structured in its early phases, which causes some difficulties to the less experienced engineers.Authors of [9] compared design process progress of freshmen and senior students and their results supported the hypothesis that novices find it more difficult to obtain enough broad and relevant information in the early steps of the process.These results were also confirmed through our case-study, described in Section 5.
In [10] authors propose a hierarchical structure of decision-making, but do not suggest a concrete methodology of tackling the problem of underconstraining.In [4] authors discuss a transformation of "real world" design knowledge representation into a structured Design Space Framework, which is clearer and should be more useful for further use.Some propositions have been made in the form of intelligent decision support for narrower fields, such as computer-aided design [11].In requirements engineering (new software design) [12] and [13] imply that the concept of personas could potentially be used for identifying missing requirements, but in order to use this method, the whole system of personas should not only be built but also applied to the world of mechanical product design.Another method suggested by software engineering authors, is the so called Experiential Expression [14], but a question of generalization onto the field of mechanical design could again be raised.Therefore, the literature is lacking an effective approach towards avoiding under-constraining the new mechanical product.
Another problem with defining requirements early in the product design process is over-constraining the product.Authors of [4] refer to it as under-framing and it means that a design engineer defines so many requirements at the outset of the process that there is little or no room for alternative designs and solutions at later phases.Product is already almost determined in the initial phase.This either leads to a sub-optimal design, because the product was determined before brainstorming, analyses and before the use of other well-established design methods, or it suggests that the whole design process has already happened, only in an informal and unsystematic way [1].Over-constraining the product in the early phases is a sign of the start of so called fixation on initial idea, meaning that design engineer clings to his or her principal solution concept despite the fact that a competitive concept suits the requirements better.The phenomenon was observed and studied by researchers from different fields, for instance: [15] for mechanical design, [16] for electronic engineering and [17] for architecture.Fixation and determining too many too detailed requirements may disable a rich and constructive concept generation.
Hence, the need for a systematic method for classifying requirements into necessary and optional exists alongside with the need for corresponding methodology for systematic requirements elicitation.Suggestion for both is presented in Section 4.

Existing methods for requirements elicitation and classification
The elicitation of initial requirements is a collaborative process.The product must satisfy both the needs of the customer and the profitability expectations of a company's financial department.The requirements need to be elicited and negotiated at the product development outset [18].Further refining of the requirements takes place inside the company.Special care needs to be taken to avoid or at least successfully resolve all the emerging conflicts [19].The questions of collaboration during requirements elicitation are frequently raised also in the area of software development.For instance, authors of [20] propose a systematic process, similar to requirements elicitation workshops, to establish the requirements efficiently and effectively.In [21] authors even propose a system for automated requirements elicitation.
In the literature some guidance on choosing the requirements is given to design engineers in the form of sample checklists of topics that could be part of a RL for the new product.According to [1] these topics could be for example geometry, production, operation, maintenance and others.A checklist with similar items can be found in [15].Checklists are certainly not classifications but they do give a thematic layout of the most common requirements.
A classification according to product lifecycle phases is a part of EIA-632 (1999) standard [22], intended for design of greater systems.In the EIA-632 it is suggested that engineers first transform stakeholders' requirements into system technical requirements, which are latter divided into operational, performance and enabling.A bare classification of requirements by product lifecycle phases was also adopted by [23].
According to the Kano method (which originates from Kano diagram [24]) mentioned earlier, there are four classes of (customer) requirements: expecters, spokens, unspokens, and exciters.Expecters are basic parameters that customers expect a product to have.Requirements explicitly described or stated by customer belong to the group of spokens.Unspokens are those requirements which the customer does not specifically mention.They may seem obvious to the customer or he or she forgets about them at the time of requirements elicitation.The requirements that are not demanded by the customer but add some value to the product and make the customer very satisfied or even delighted belong to exciters.As stated, the Kano method discusses only the customer requirements.This means that we cannot place requirements that are not significant to customers (e.g.most of the transport properties) into its classes.
In [24] authors divide requirements into design parameters (physical properties that determine features of a design), design variables (parameters over which design engineers have a choice) and constraints ("limits on design freedom").The groups are not dependent on the content of a requirement but on the choice the design engineer has to determine the requirement's value.
Requirements were hierarchically classified into stakeholder requirements, system requirements, subsystem requirements and component requirements by [25].Subsystem requirements are fulfilled by component requirements, system requirements are fulfilled by subsystem requirements and, finally, stakeholder requirements are fulfilled by system requirements.
Another hierarchical approach that could be undertaken is prioritizing (already established) requirements using the first house of Quality Deployment Function (QFD) -"The house of quality".Via this method requirements are prioritized according to: the customer's view, whether or not a specific solution to a requirement can be obtained, comparison with competition's solutions and some other criteria [26].QFD also suggests some ways of eliciting requirements, for instance via interviews, surveys, etc.Additionally, the already mentioned Kano method is usually a part of QFD.
There also exist hierarchical structures of requirements, reused in design of a new product of a product family.In [27] authors propose a so called Definition hierarchy, consisting of Design objectives and Design decision nodes.In this hierarchy child requirements are used to define the parent requirement.Authors of [28] present two hierarchies of reusable requirements.Aggregation hierarchy is composed of subsystems with child nodes representing object types.By generalisation/specialization hierarchy one can derive a specialized object through replacing the generic object type by the target specific object.
It can be concluded that no efficient answer to the question: "Is this requirement necessary for this product?" has been given yet.They offer guidance to the design engineer towards elicitation of some requirements, regardless of their content, and after that guidance towards distributing them into groups in respect to different distinctions.But the question of relevance of the elicited and later classified requirements remains unanswered by given literature.That is why in the next section we propose a method that groups requirements into necessary and optional on the basis of a specific product definition.

A new necessity-based method for RL elicitation and requirements classification
The method proposed in this section helps eliciting requirements that form the basis of the new product design.These requirements are not yet prioritized nor fully transformed into engineering characteristics.Prioritization and transformation into engineering quantities and requirements validation can later be performed using QFD or one of similar methods.However, without previously formed basic requirements (included in the RL), it is impossible to use QFD.The herein proposed new method hence helps the design engineer elicit the initial requirements that form the RL and are then manipulated further in the next phases of product design process.

Extension of the Form, Fit and Function in Universally Necessary Requirements
Form, Fit and Function (FFF) approach enables the evaluation of mechanical parts according to its interchangeability.The part is typically a single component that is a part of a greater mechanical system (product).The effect of the part on the system is assessed from three points of view, namely form (physical properties which uniquely determine certain part, such as shape), fit (attributes that represent its ability to be integrated physically into the mechanical system) and function (action or actions that the part must perform under certain conditions).
According to such definition FFF has been used widely for identifying whether or not a new part is appropriate to be built into a system, for example in arms industry [29,30].Authors of [31] presented the geometrical interpretation of FFF in the form of manufacturing tolerances.Paper [32] described different obsolescence mitigation methodologies, where FFF was the criteria of interchangeability of elements.
In our case we redefine form, fit and function concepts so that we can use them to establish the basic definition of a product.With the word "product" we now refer to any engineering design result -a single component or a system of components.Therefore we are about to extend the current view of FFF and we name the extended approach as extended Form, Fit and Function or eFFF.
The new method for requirements elicitation is supposed to be universal, i.e. available to use in design process regardless of the product's expected shape, operational features or other attributes.We find that eFFF is a sufficiently universal and on the other hand increasingly particular approach for defining products and hence it can be used as the basis of the proposed method.
We extend the form, fit and function concepts as: To clarify the possible issues we additionally make some remarks regarding the terms, referred to in the above definitions: -components of the product: From the structural point of view it is recommended that some autonomous properties are attributed to more complex or independent components of the product -this applies especially to properties that have different values for a component than for the product.-properties: The properties are elements of eFFF that may or may not be used as requirements for a specific product.-product lifecycle: Many of the properties change with respect to the stage of product lifecycle.Therefore, it is essential to state which phase of product lifecycle they refer to in order to be useful as product requirements.
The tree structure of eFFF is shown in Fig. 1.An important advantage of the described product definition is its simplicity.Even the "flow properties" (flow of energy, flow of information, flow of materials), which are often the most complex to define, are broken into the lowest level components.That simplifies product definition and subsequently minimizes the possibility of requirements ambiguity.
Properties, listed in the above eFFF structure representation, are called Universally Necessary Requirements (UNR).It is a group of requirements that should be defined for every product.According to the problems, discussed in Section 2, not all the eFFF properties should be known in this phase (to avoid overconstraining), however, some pieces of information need to be provided for form and fit and function parts of eFFF (to avoid under-constraining).A design engineer should therefore be guided by the eFFF so that he or she would consider the properties for each component in each life cycle phase (LCP) and put down the requirements where applicable for her or his case.

Figure 1The tree structure of eFFF
In the proposed new method the eFFF properties are recognised as universally necessary in a rather straightforward manner: they can be found in most literature sources that discuss selecting requirements for the RL.They are listed in [1] as well as in [15] checklists, they can be found in EIA-632 [22], examples are mentioned in the context of QFD (for instance in the House of quality matrix [26]) and in many other sources.The eFFF properties are the result of an analysis of these sources.

Further investigation: Product-Specific Necessary Requirements
With the new method we can build a model of product requirements in a form, depicted in Fig. 2. requirements, proposed by [1].For example, we connect the "Likelihood of danger to people" eFFF property with topics of Material and Safety, which include requirements, suggested by different sources ( [1,15] and many other stated references, for instance [33] for Safety) like: • preferred material, compatible materials, material properties, lubrication, product's (component's) own weight, physical and chemical properties, auxiliary materials, prescribed materials, possibilities of production transformations according to low/high production rate, procurement possibilities, recyclability, danger to environment, waste of limited natural resources, standards, laws and patents (for Material) • direct safety principles, non-poisonous materials and coatings, protective systems, possible dangers, reduction of injury risk, indirect danger to humans through environment contamination, standards, laws and patents (for Safety), acoustics (noise, frequency, vibration) When for a specific component (or for product as a whole) in a certain LCP a topic of related requirements is encountered more than once, it is a sign that some requirements from this topic should be defined for this specific product.That is why we call these requirements Product-Specific Necessary Requirements (PSNR).We noted in Fig. 2 that LCPs themselves produce some PSNR topics.For instance LCP Design implies that topic Cost could be important.Some eFFF property -PSNR topics connections are shown in Tab. 1 (example for Fit economy eFFF properties).For practical use a full version of Tab. 1 (for all eFFF properties and all LCPs) should be given to the design engineer.The topics, related to the determined eFFF properties and LCPs should be grouped by components and LCPs.The weights of importance for the PSNR topics according to the specific product are calculated as follows: Let A be the reciprocal of the number of PSNR topics, defined for an eFFF property.Let B be the ratio between A and the sum of As for all the eFFF properties for a specific PSNR topic.Then the weight of importance for this specific PSNR topic is the sum of all the Bs for the defined eFFF properties.
At this point Optional Requirements (OR) can be defined: In some cases in early phases of product design some specific requirements are explicitly stated by the stakeholders.They are very important.However, they can hardly be fitted into the topics, corresponding to the relevant eFFF properties or LCPs.Because they nevertheless need to be included into RL, they are classified as ORs.

Use of the necessity-based method for RL elicitation and requirements classification
The support of a design engineer through the process of RL elicitation is done using three sequential steps: definition of UNR, PSNR and OR.The method helps the user avoid overlooking the requirements that could be of essential importance and hence helps the designing company avoid problems with additional unwanted iterations in the product design process.
In practice, for a design engineer the whole procedure is as follows: • for each component in each LCP work through eFFF properties one by one: -see whether the property is relevant or not -if it is irrelevant, go to the next property (until you reach a relevant one) -for every relevant property find the corresponding PSNR topics (from the full version of Table 1) -apply the procedure until all the relevant UNRs are defined and all corresponding PSNR topics are found • group PSNR topics by components and LCPs and find the most frequently encountered ones (for each component and LCP), then define some PSNRs from these topics • if until this phase any requirement is encountered that does not belong to the PSNR topics, it should be taken as an OR • write down the formally edited RL.

Case-study on industrial design of air ventilation register box
Our problem is design of an air ventilation register box for offices, bars and private houses that connects airconditioner outlet channel to ceiling diffuser (Fig. 3 shows the final product and all the requirements from original industrial RL for the product are shown in Fig. 4).It is mounted inside a ceiling and made of galvanized steel sheet.In the original RL, obtained directly from industry, some other requirements are also determined.

Method verification on the basis of a real industrial case and expert opinion
To test whether or not the proposed necessity-based method truly leads the design engineer in the direction of creating a more appropriate RL, we compared the results of our method with a real industrial case and with expert opinion.In the original RL 4 out of 7 Form eFFF properties, 3 out of 13 Fit eFFF properties and 1 out of 8 Function eFFF properties are defined (Fig. 4).The original RL hence fulfils the condition of at least one requirement from each part of eFFF being defined.This can be taken as a first sign of avoiding under-constraining.The above figures also tell that 8 out of total 28 (29 %) eFFF properties are defined.From this fact we can conclude that the product is not over-constrained until this point in the design process.The requirements that are not eFFF properties but are defined on the original RL can be classified into the PSNR topics (number of corresponding requirements is shown in brackets): Assembly (1), Production (3), Quality control (1), Schedules (1), Costs (1) and Operation (2).That shows good accordance with the calculated (Subsection 4.2) PSNR topics of the proposed method (weight of importance for the topic is in the bracket): Costs (0,73), Schedules (0,60), Quality control (0,53), Production (0,53) and Recycling (0,45).As we see, 4 topics coincide.That means that the method covers the topic selection process rather well.The requirements from topics that differ are ORs.The complete classification of requirements according to the proposed method is shown in Fig. 4. We also compare defined requirements with PSNRs, offered by the proposed method (examples are in Subsection 4.2). 3 out of 9 PSNRs and ORs are not offered by our proposed method, which means that we should include these requirements into the PSNR sets.
In general, experts from the firm that designs and produces register boxes agreed that the method is a step towards increasing quality of RLs.They did notice that some more PSNRs could be offered.This would broaden the choice for RL authors and also remind design engineers of ever more possible requirements options.However, there is some fear of over-constraining, if users of the method are not well informed that not all the offered requirements should be defined.The experts feel that the method is not too time-consuming.These conclusions were obtained through interview with experts.

Analysis of contribution of the method
We were also interested in whether or not the method indeed simplifies and properly guides requirements elicitation for novice design engineers.The observed problem was the same as with expert design engineers.It was briefly described to 32 young design engineers (students of product design engineering), while the necessity based method was not presented to them.They were then asked to answer some questions regarding the task of designing an air ventilation register box.First of all they needed to choose which eFFF properties they would define.All eFFF properties are shown in Fig. 5, together with corresponding percentages of participants that evaluated them as important (light grey areas show eFFF properties actually defined in the original industrial RL).It turned out that one participant defined no property for the Function part of eFFF.When the method is implemented into a decision support system this under-constraining issue can be avoided via suggesting defining a property for Function.Overconstraining showed as a greater issue.56.% of participants defined more than half of eFFF properties, which could impose a problem in later phases of the design process.Again, in a decision support environment, the user of the method could be alerted of the possible over-constraining.Fig. 5 also shows that novice design engineers placed some emphasis on Signal flow and Fit people eFFF properties, which is not the case with the original RL.This confirms significant distinction between novice and expert view of the product and hence confirms the need of addressing such issues.When participants were asked to write down some additional requirements that could be appropriate (PSNRs), they stated on average 1,75 requirements.However, when they were later given an extensive list of 146 PSNRs, on average 31,375 PSNRs were chosen.This clearly shows that novice engineers tend to miss many potentially significant requirements.However, offering many requirements could result in over-constraining.By integrating the method into a decision support system, additional controls and alerts can be implemented to avoid this problem.

Conclusion
In the paper we present a method for obtaining the necessary requirements in the RLs.For the purpose we extended the FFF approach into eFFF product definition.The purpose of the eFFF is to both determine UNRs and provide the basis for the next steps.Following eFFF an automatic selection of important product-specific topics is done based on predefined connections of eFFF and the PSNR topics.The PSNRs are established according to these topics.All the requirements, which belong to topics that are not recognized as important regarding eFFF product definition can be defined as ORs.
As we can see, in line with the elicitation method a new requirements classification based on requirements necessity was produced.This classification can give an insight into the significance of a particular requirement regarding universal product design or regarding the design of a specific product.If a company uses our method regularly it can also be seen, which ORs emerge for many products and the method can then be updated to include appropriate topics as part of PSNR determination.
The important emphasis was given to the actual need for the necessity-based method.It is shown that over-and under-constraining a product in the phases before the RL are indeed problems.They are especially often encountered by less experienced design engineers.The consequences of missing requirements or overconstraining appear in additional iterations of the design process, which elongates time-to-market and reduces the profits.Therefore, reaching an optimal level of defined requirements in the RL indeed helps to the success of the product design process.A method that facilitates appropriate requirements elicitation, such as the one presented in this paper, is thus certainly an improvement of the process.And it has been shown in the paper that the presented method is the first (published) of such kind.
It can be concluded that the core added value of the method is its simplicity and systematic approach.A less experienced design engineer is guided towards obtaining the necessary requirements on the basis of three very simple steps.The possible disadvantage is overconstraining the product by users, who are not properly informed that not all the offered requirements should be defined.However, this obstacle can be overcome by integrating the method into a decision support system.
The initial requirements, elicited by the proposed method, are an input for the next phases of product design process.They are prepared for later manipulation, transformation into engineering quantities and for prioritization.
The method was verified by a real industrial case of air ventilation register box design.It showed that eFFF approach and the condition that all eFFF parts should be defined hold.It also confirmed that the proposed important PSNR topics calculation is appropriate.The appropriateness and contribution of the proposed method was also confirmed through interview with industry experts.On the other hand the method was tested by novice design engineers.The results showed that a significant share of issues with under-and overconstraining the product can be overcome using the necessity-based method.However, in the part of PSNR definition, some additional alerts about over-constraining could be implemented.
The exploration of integration of our proposed method (method for guidance towards obtaining the most relevant and appropriate requirements and classification based on necessity) into an intelligent support system is definitely a prospective direction of further research on the topic.Another approach would be to focus on the eFFF properties, the corresponding requirements topics and proposed requirements (at the moment the listed items are based on literature analysis).
All things considered, it can be concluded that an important step towards helping design engineers in need of guidance is done by forming the presented method.Besides its practical usefulness, effectiveness and applicability it can also offer another view on the requirements establishment not only in mechanical design but in design in general.Therefore it is reasonable to say that further investigation on the topic is interesting from both practical and scientific perspective.

Figure 2
Figure 2 Model of product requirementsAs shown, product is decomposed into components.For each component, as well as for the product as a whole, different eFFF properties are defined for specific LCPs.Developing the methodology further, we first define LCPs.By in-depth analysis we find that we can connect each eFFF property to concrete topics of

Figure 3 Figure 4
Figure 3 Air ventilation register box

Figure 5
Figure 5 eFFF properties, evaluated as important by novice design engineers (percentages in dark grey) and properties actually defined in the original RL (light grey) form is a collection of physical properties of the designed product: shape, fit with another component/product, dimensions, materials/ material properties.The manufacturing process is a subset of form, namely: -flow of materials: properties: input material/input material properties, material transformations, output material properties, material flow rate (production rate) • fit: In the new concept we split fit into: -fit people: properties that describe the interaction of the designed product with humans: will people see/hear/touch/taste/smell the product?, target group of users, probability of danger to people, potential/most likely/worst case scenario injuries.-fit environment: properties regarding the interaction of product with the environment: natural resources at risk because of the product, potential quality and quantity reduction of the endangered sources, recyclability of the product, disposal strategy.-fit economy: properties describe the relationship between the product and the general economy and related issues: deadlines, product cost and price, sale rate, similar available/patented products.• function: Reinstated definition of function is relatively close to the original one.Properties included define the operations or intended actions of the product: -flow of energy: In many cases the expected function of a product is to transform energy from one form to another.

Table 1
PSNR topics corresponding to eFFF properties