• Non ci sono risultati.

Documents Analysis to Improve the Product Design Development

N/A
N/A
Protected

Academic year: 2021

Condividi "Documents Analysis to Improve the Product Design Development"

Copied!
161
0
0

Testo completo

(1)
(2)

“il tutto è più della somma delle sue parti”

[Aristotele]

(3)

D

IPARTIMENTO DI

I

NGEGNERIA DELL

’E

NERGIA DEI

S

ISTEMI

,

DEL

T

ERRITORIO E DELLE

C

OSTRUZIONI

TESI PER IL CONSEGUIMENTO DELLA

LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE

Documents Analysis to Improve the Product Design

Development

RELATORI IL CANDIDATO Prof. Ing. Gualtiero Fantoni Serafino Maria Marco Militello Dipartimento di Ingegneria Civile e Industriale ser.militello@gmail.com Ing. Filippo Chiarello Dipartimento di Ingegneria dell’Energia, dei Sistemi, del Territorio e delle Costruzioni

Sessione di Laurea del 19/07/2017 Anno Accademico 2016/2017 Consultazione consentita

(4)

1

Summary

1. INTRODUCTION ... 3

2. STATE OF THE ART ... 8

2.1 REQUIREMENTS, NEEDS AND SPECIFICATION ... 8

2.1.1 DEFINITIONS ... 8

2.1.2 USING THE TEXT INFO THROUGH R-PACKAGES ... 9

2.2 PRODUCT DEVELOPMENT AND THE FUNCTION – BEHAVIOUR – STRUCTURE MODEL ... 12

2.2.1 FOUR TYPES OF PRODUCT DEVELOPMENT PROJECTS ... 12

2.2.2 THE PRODUCT PLANNING PROCESS ... 12

2.2.3 THE GERO’S FBS MODEL ... 13

2.2.4 PROCEDURAL ERROR DURING THE FUNCTION DEFINITION IN A PRODUCT DEVELOPMENT PROJECT ... 15

2.3 QFD’s STATE OF THE ART ... 16

2.3.1 WHAT IS A “QUALITY FUNCTION DEPLOYMENT”? ... 16

2.3.2 HISTORY AND GROWTH ... 16

2.3.3 FUNCTIONAL FIELDS OF QFD ... 18

2.3.4 QFD’s STRUCTURE ... 19

2.3.5 THE PROVIDED RULES TO EXPRESS CUSTOMER NEEDS ... 21

2.3.6 THE PROVIDED RULES TO EXPRESS THE SPECIFICATIONS ... 22

2.3.7 CUSTOMER’S NEEDS IDENTIFICATION: STEPS ... 23

3. METHODOLOGY ... 23

3.1 THE “GOOGLE ADVANCED SEARCH” BASED METHODOLOGY ... 24

3.1.1 FIRST ANALYSIS ON THE REQUIREMENTS, NEEDS AND SPECIFICATION DEFINITIONS ... 24

3.1.2 WHERE THE REQUIREMENTS, NEEDS AND THE SPECIFICATIONS ARE? ... 29

3.1.3 THE REQUIREMENTS, NEEDS AND SPECIFICATIONS SEARCH ON THE SOURCES BASED ON THE FIRST DEFINITIONS ANALYSIS ... 31

3.1.3.1. QUERIES BUILDING ... 34

3.1.3.2. REQUIREMENTS ... 34

3.1.3.3. NEEDS ... 34

3.1.3.4. SPECIFICATIONS ... 36

3.2 THE R-BASED METHODOLOGY ... 40

3.2.1 ANALYSIS AND CORRECTION ON DEFINITIONS PREVIOUSLY USED ... 40

3.2.2.1 STATUTORY DOMAIN ... 44

3.2.2.2 NOT STATUTORY DOMAIN ... 44

3.2.2.3 PROVING THE ASSUMPTIONS ABOUT THE ABSOLUTE AND PARTIAL OBLIGATIONS OF THE REQUIREMENTS ... 44

3.2.3 THE METHOD BASED ON THE R-SOFTWARE TOOL ... 47

3.2.3.1 THE SOURCES ... 47

3.2.3.2 THE METHODOLOGY ... 48

3.2.3.3 DICTIONARY COSTRUPTION ... 48

3.2.3.4 QUANTEDA CODES ... 49

3.2.3.5 THE NORMALIZATION ... 51

3.3 THE QFD REVIEW METHODOLOGY ... 51

3.3.1 ANALYSIS ON THE QFD METHOD ... 51

3.3.2 EXAMPLE ABOUT NEEDS AND SPECIFICATION IN A DESIGN PROCESS ... 64

3.3.3 THE QFD REVIEW ... 66

(5)

2 4.1 CASE STUDY 1: TEST ON THE SOURCES ABOUT REQUIREMENTS, NEEDS AND

SPECIFICATIONS USING THE “GOOGLE ADVANCED SEARCH” TOOL ... 73

4.1.1 A FIRST TEST ON REQUIREMENTS ... 73

4.1.2 HOVERBOARD: TEST ON REVIEWS SOURCE ... 75

4.2 R-BASED CASE STUDY ... 87

4.2.1 YOUTUBE REVIEW ... 87

4.2.2 TENDER ... 89

4.2.3 AMAZON REVIEW ... 89

4.2.4 KICKSTARTER COMMENTS ... 91

4.2.5 BLOGS AND FORUM ... 92

4.2.6 PATENTS ... 94

4.3 CASE STUDY ON THE QFD DESIGN REVIEW ... 96

4.3.1 IDENTIFICATION OF THE IMMEDIATELY RESOLVABLE SENTENCES ... 101

4.3.2 HYPERNYM TEST ... 101

4.3.3 BABELNET TEST FOR THE CLUSTERING REVIEW ... 104

4.3.4 FURTHER ANALYSIS ... 110

4.3.5 SQC REVIEW ... 112

5. DISCUSSION ... 125

5.1 DISCUSSION ON THE “GOOGLE ADVANCED SEARCH” METHOD ... 125

5.2 DISCUSSION ON R-BASED METHOD ... 135

5.3 DISCUSSION ON THE QFD IMPLEMENTATION METHOD ... 139

5.3.1 DISCUSSION ON THE HYPERNYM TEST ... 139

5.3.2 DISCUSSION ON THE BABELNET TEST ... 140

5.3.3 THE SQC REVIEW ... 140

5.3.4 THE LAST STEPS ... 142

6. CONCLUSION, LIMITATIONS AND FUTURE IMPROVEMENTS ... 143

6.1.1 CONCLUSIONS AND LIMITATION: THE “GOOGLE ADVANCED SEARCH” METHOD ... 143

6.1.2 FUTURE IMPROVEMENT ... 144

6.2.1 CONCLUSIONS AND LIMITATION: THE R-BASED METHOD ... 145

6.2.2 FUTURE IMPROVEMENT ... 146

6.3.1 CONCLUSIONS AND LIMITATIONS: THE QFD REVIEW ... 148

6.3.2 FUTURE IMPROVEMENT ... 150

7. REFERENCES ... 152

8. FIGURE INDEX ... 154

9. TABLE INDEX ... 154

(6)

3

1. INTRODUCTION

Our study got started during the PSSP (Progettazione e Sviluppo dei Sistemi e dei Processi - FANTONI - MIRANDOLA) course at the University of Pisa.

The main activity of the course consisted in a group project implementation, which regarded to a product development using a set of problem solving tools.

During the entire course, each group challenged themselves to find quantitative indicators to maintain each planned process in control, and eventually, to measure when a process worked or not.

Another important activity has been represented by the Design Review process, in which each group reflected on the achieved results at the end of every section of the developing process.

This work has not been easy, and it requested to spent a lot of time on the review process.

During the QFD design review activity, our team tried to implement a method to collect information about the achieved results, and also provided solutions to the issues found, according to the PDCA method.

During this phase, the author of this study, that was the team leader of the abovementioned group, approached to the importance of the text information and their related difficulties to treat them in an engineering development field.

Today, less than the 1% of the available data in the world has been analyzed, and the 90% of the data which are in circulation has been generated in the last 2 years (considering the total horizon of considered time, i.e. 5000 years).

Today everyone is able to generate data and using that on the world wide web. Just think to the social network platforms and the number of times every day we search information on internet.

So, there are a lot of data online, but considering the different background of who post the information, the variance on the quality information become very high. Our study started during the QFD review, in particular during the customer needs review and the SQCs review.

(7)

4 In that field, we manipulated both the customer needs and the specifications, and we tried to "normalize" the lexical sentences, in order to measure the quality of our work.

So, generally, one of the main issues linked to the data analysis, is that the used data derive from different sources, both in term of place (we are talking about virtual places, i.e. the internet platforms) and in term of who post the information, and try to normalize the lexical data considering their semantic meaning and their future use.

Obviously, the study has needed to study in deep the problem, and we had to also what precedes the abovementioned issue.

Indeed, during our work, we had to better understand what are the customer needs, and what are their characteristic, and the same concept has been implemented on the specifications.

In order to achieve our target, we started to study the definitions about the requirements, needs and specifications, with the purpose to study their syntax structures and understand in which form we could search them.

We tried further to analyze the designer thinking, with the purpose of better understand how a sentence about customer needs and specifications could be "normalized".

In our study, we furthermore provided and test a set of sources, in which the treated elements could be extracted from.

So, in conclusion, with our work, we want to provide what, how and when the requirements, the customer needs and the specifications are.

We want further to provide a general method to implement a design review, and specifically a method to improve the QFD implementation.

In the second chapter of our study, we present the state of the art utilized for the thesis work, i.e. the mean existing knowledge that we used during the research.

(8)

5 Obviously, we tried to organize the State of the Art section in order to achieve symmetry on our entire work, and produce a good reading for the lector. But it was very difficult because, in the state of the art, are present information and concept that are referred to more than a section.

The third section regards the used "Methodology", and provides analysis and studies on our purposes.

As you can see from the third section, the thesis is structured considering 3 different section. The first section starts from the first definitions analysis and end with implementing a method that is based on a simple search engine.

The purpose of the first section is that one to provide a first test on selected sources from which we could extract information about requirements, customer needs and specifications.

The second section of the third chapter, is based on further analysis on the definitions and their corrections.

The provided method is based on the definitions corrections, and is built on a statistical tool that is r-software software, that allows to extract the searched information from selected text.

In the last section of the methodology chapter, you can see our research on the QFD implementation, the interested criticality, and what the literature provides about that method.

The chapter starts implementing a first general analysis on the QFD, focussing forward on the recognized criticalities.

In this section, we provided a framework to implement a Design Review activity and a methodology that allows to implement corrections on the lexical sentences. In fact, we provided a method based on grammatical rules to abstracting the recognized sentences. This method is based on the concept of hypernym and hyponym.

Furthermore, during the review activity about the QFD, we presented a semi-automatic method to cluster the customer needs, and to reduce the redundancy on the SQCs.

In general, during the review we provided a set of method and the related indicators with the purpose to control the process results during the implementing

(9)

6 and in a post-implementation phase, in order to identify "lesson learned" and related risks that depend to the quality of the iterations.

In the fourth chapter regards the Case Study, i.e. the application of the previously explained methods.

The first Case Study regarding the implementation of the method related to the first assumptions about requirements, needs and specifications. In particular, in this section are tested the identified sources, that derive from the internet platforms.

During the iteration of the method (based on "Google Advanced Search" search engine) the sources have been analyzed, and the characteristics about each source was provided.

The Test has been iterated on sources that treated electro-mechanic products (where possible).

In particular, we analyzed the sources that collecting information about electro-mechanic products (in particular the hoverboard), and products related to the “Iot” and the “makers” world (in particular programmable electronic boards).

Obviously, the searched info has been about requirements, needs and specifications.

In the second section of the fourth chapter, we implemented the r-based method about the information searching on the selected sources.

The implementation of the abovementioned method derives directly from that one iterated in the previous section.

The sources selection derives from the resulted information from the previous phase.

In this section, the matrices that collect the quantitative results about the searched information, have been provided.

In the last section of the fourth chapter, the explained method about the QFD implementation has been implemented on a QFD built during the PSSP project. The abovementioned project regarded the development of a wheelchair for disabled people that are designed for the sea/beach environment use.

(10)

7 As we affirmed previously, the method could be iterated both during the method implementation and during a review activity.

In the case study, we explained the use of the method on a QFD that exists already, so the case study is based on a review process.

In the fifth chapter, we presented the discussion on the results provided by the method implementation on the Cases Study, in particular on the requirements, needs and specifications and on the QFD review.

In the last chapter, we provided the conclusions and the limitation about each implemented method.

Furthermore, we suggested future applications and improvements that can be implemented on the presented methods.

(11)

8

2. STATE OF THE ART

2.1 REQUIREMENTS, NEEDS AND SPECIFICATION 2.1.1 DEFINITIONS

Definitions about the interested elements from different sources follow: REQUIREMENT:

“A requirement is a need, expectation, or obligation. It can be stated or implied by an organization, its customers, or other interested parties. A specified requirement is one that has been stated (in a document for

example), whereas an implied requirement is a need, expectation, or obligation that is common practice or customary.”

[ISO 9000, 2015] NEED:

“need is a psychological feature that arouses an organism to action toward a goal, giving purpose and direction to behaviour.”

[Maslow, 1943] NEED:

“Needs are largely independent of any particular product we might develop; they are not specific to the concept we eventually choose to pursue.”

[Ulrich, 2000] CUSTOMER NEED

“A customer need is a description, in the customer's own words, of the benefit to be fulfilled by the product or service.”

[JOHN R. HAUSER, 1988] NEED:

“needs are substantially independent from any particular technology of product and they express through the functions or through the desired product

attributes” [Ulrich, 2000]

(12)

9 SPECIFICATION (SINGULAR):

“A specification (singular) consists of a metric and a value. For example, “average time to assemble” is a metric, while “less than 75 seconds” is the

value of this metric.” [Ulrich, 2000]

VALUE:

“value may take on several forms, including a particular number, a range, or an inequality. Values are always labeled with the appropriate units (e.g., seconds,

kilograms, joules).” [Ulrich, 2000]

“a formal distinction between needs and requirements has not yet been consolidated”

[Cascini, Fantoni, Montagna, 2012]

2.1.2 USING THE TEXT INFO THROUGH R-PACKAGES

With the purpose of achieve results analysing the text info, we will use automated tools that allows to implement the analysis. In this study, we will use r-software software but that requires a period of training for the analyst.

The training will be based on r-software Manual (provided from the same source that provides the software), books and paper.

In order to provide a first tool introduction, we present the extract that follows: From “Text Mining Infrastructure in R” (Feinerer, Hornik & Meyer, 2008):

“Text mining encompasses a vast field of theoretical approaches and methods with one thing in common: text as input information. This allows various definitions, ranging from an extension of classical data mining to texts to more sophisticated formulations like “the use of large online text collections to discover new facts and trends about the world itself” (Hearst 1999). In general, text mining is an interdisciplinary field of activity amongst data mining, linguistics, computational statistics, and computer science. Standard techniques are text

(13)

10 classification, text clustering, ontology and taxonomy creation, document summarization and latent corpus analysis. In addition, a lot of techniques from related fields like information retrieval are commonly used.

Classical applications in text mining come from the data mining community, like document clustering and document classification. For both the idea is to transform the text into a structured format based on term frequencies and subsequently apply standard data mining techniques. Typical applications in document clustering include grouping news articles or in- formation service documents, whereas text categorization methods are used in, e.g., e-mail filters and automatic labeling of documents in business libraries. Especially in the context of clustering, specific distance measures, like the Cosine, play an important role. With the advent of the World Wide Web, support for information retrieval tasks (carried out by, e.g., search engines and web robots) has quickly become an issue. Here, a possibly unstructured user query is first transformed into a structured format, which is then matched against texts coming from a data base. To build the latter, again, the challenge is to normalize unstructured input data to fulfill the repositories’ requirements on information quality and structure, which often involves grammatical parsing.

During the last years, more innovative text mining methods have been used for analyses in various fields, e.g., in linguistic stylometry, where the probability that a specific author wrote a specific text is calculated by analyzing the author’s writing style, or in search engines for learning rankings of documents from search engine logs of user behavior.

Latest developments in document exchange have brought up valuable concepts for automatic handling of texts. The semantic web propagates standardized formats for document exchange to enable agents to perform semantic operations on them. This is implemented by providing metadata and by annotating the text with tags. One key format is RDF where efforts to handle this format have already been made in R with the Bioconductor project. This development offers great flexibility in document exchange. But with the growing popularity of XML based formats tools need to be able to handle XML documents and metadata.

(14)

11 The benefit of text mining comes with the large amount of valuable information latent in texts which is not available in classical structured data formats for various reasons: text has always been the default way of storing information for hundreds of years, and mainly time, personal and cost contraints prohibit us from bringing texts into well-structured formats (like data frames or tables).

Statistical contexts for text mining applications in research and business intelligence include latent semantic analysis techniques in bioinformatics, the usage of statistical methods for automatically investigating jurisdictions, plagiarism detection in universities and publishing houses, computer assisted cross-language information retrieval or adaptive spam filters learning via statistical inference. Further common scenarios are help desk inquiries, measuring customer preferences by analyzing qualitative interviews, automatic grading, fraud detection by investigating notification of claims, or parsing social network sites for specific patterns such as ideas for new products.”

Nowadays almost every major statistical computing product offers text mining capabilities, and many well-known data mining products provide solutions for text mining tasks. According to a recent review on text mining products in statistics these capabilites and features include:

• Preprocess: data preparation, importing, cleaning and general preprocessing,

• Associate: association analysis, that is finding associations for a given term based on counting co-occurrence frequencies,

• Cluster: clustering of similar documents into the same groups,

• Summarize: summarization of important concepts in a text. Typically, these are highfrequency terms,

• Categorize: classification of texts into predefined categories, and

• API: availability of application programming interfaces to extend the program with plug-ins.

(15)

12 2.2 PRODUCT DEVELOPMENT AND THE FUNCTION – BEHAVIOUR – STRUCTURE MODEL

2.2.1 FOUR TYPES OF PRODUCT DEVELOPMENT PROJECTS

Product development projects can be classified as four types [Ulrich, 2000]: New product platforms: This type of project involves a major development effort to create a new family of products based on a new, common platform. The new product family would address familiar markets and product categories. The Xerox Lakes project, aimed at the development of a new, digital copier platform, is an example of this type of project.

Derivatives of existing product platforms: These projects extend an existing product platform to better address familiar markets with one or more new products. To develop a new copier based on an existing light-lens (not digital) product platform would be an example of this type of project.

Incremental improvements to existing products: These projects may only involve adding or modifying some features of existing products in order to keep the product line current and competitive. A slight change to remedy minor flaws in an existing copier product would be an example of this type of project.

Fundamentally new products: These projects involve radically different product or production technologies and may help to address new and unfamiliar markets. Such projects inherently involve more risk; however, the long-term success of the enterprise may depend on what is learned through these important projects. The first digital copier Xerox developed is an example of this type of project.

2.2.2 THE PRODUCT PLANNING PROCESS

The steps in the product planning process follows [Ulrich, 2000]:

First, multiple opportunities are prioritized and a set of promising projects is selected. Resources are allocated to these projects and they are scheduled. These planning activities focus on a portfolio of opportunities and potential projects and are sometimes referred to as portfolio management, aggregate product planning, product line planning, or product management. Once projects have been selected and resources allocated, a mission statement is developed for each project. The formulation of a product plan and the development of a mission statement therefore precede the actual product development process. Although we show the planning process as essentially linear, the activities of selecting promising projects and allocating resources are inherently iterative. The

(16)

13 realities of schedules and budgets often force a reassessment of priorities and further refinement and culling of potential projects. The product plan is therefore re-evaluated frequently and should be modified based on the latest information from development teams, research laboratories, production, marketing, and service organizations. People involved later in the process are often the first to realize that something about the overall plan or a project’s mission is inconsistent, infeasible, or out of date.

The ability to adjust the product plan over time is vital to the long-term success of the enterprise.

2.2.3 THE GERO’S FBS MODEL

Is worth to consider the Gero's FBS model [Gero, 1990] in order to better understand the relations between needs and specification.

GERO's framework helped us to understand in which way a designer approaches to a problem and how he solves it.

The Gero's studies and their improvements are directly linked to our study, or better some of our method are based on the FBS model and its improvements. The basis for Gero’s FBS framework is formed by three classes of variables describing different aspects of a design object:

• Function (F) variables: describe the teleology of the object, i.e. what it is for.

• Behaviour (B) variables: describe the attributes that are derived or expected to be derived from the structure (S) variables of the object, i.e. what it does.

• Structure (S) variables: describe the components of the object and their relationships, i.e. what it is.

Designer constructs connections between the function, behaviour and structure of a design object through experience. Specifically, the designer ascribes function to behaviour and derives behaviour from structure. A direct connection between function and structure, however, is not established.

The FBS framework represents designing by a set of processes linking function, behaviour and structure together, which can now be seen as different states of the developing design.

(17)

14 The eight processes depicted in the FBS framework are claimed to be fundamental for all designing. They are briefly outlined below [Gero, 1990]:

Figure 1 - Fbs model

PROCESSES

• Formulation (process 1) transforms the design requirements, expressed in function (F), into behaviour (Be) that is expected to enable this function. • Synthesis (process 2) transforms the expected behaviour (Be) into a

solution structure (S) that is intended to exhibit this desired behaviour. • Analysis (process3) derives the ‘actual’ behaviour (Bs) from the

synthesized structure (S).

• Evaluation (process 4) compares the behaviour derived from structure (Bs) with the expected behaviour to prepare the decision if the design solution is to be accepted.

• Documentation (process 5) produces the design description (D) for constructing or manufacturing the product.

• Reformulation type 1 (process 6) addresses changes in the design state space in terms of structure variables or ranges of values for them if the actual behaviour is evaluated to be unsatisfactory.

(18)

15 • Reformulation type 2 (process 7) addresses changes in the design state

space in terms of behaviour variables or ranges of values for them if the actual behaviour is evaluated to be unsatisfactory.

• Reformulation type 3 (process 8) addresses changes in the design state space in terms of function variables or ranges of values for them if the actual behaviour is evaluated to be unsatisfactory.

2.2.4 PROCEDURAL ERROR DURING THE FUNCTION DEFINITION IN A PRODUCT DEVELOPMENT PROJECT

This section is based on the Mary Kathryn Thompson work, "A CLASSIFICATION OF PROCEDURAL ERRORS IN THE DEFINITION OF FUNCTIONAL REQUIREMENTS IN AXIOMATIC DESIGN THEORY" [Thompson, 2013]. In this work are highlighted 5 types of procedural errors during the definition of the functional requirements (FR) in particular during the Axiomatic Design implementation.

The errors list follows:

1. Mixing FRs with design parameters (DPs) 2. Mixing FRs with other types of requirements

3. Mixing the FRs of the various stakeholders and of the artefact 4. Mixing the FRs of the artefact and of related systems

5. Defining negative FRs

During her study Thompson explain in detailed way each point of the above presented list.

The error 1 is important for our study and is related to the concept of solution-neutral thinking, which increase the "innovation possibilities" for new artefact [Lu and Liu, 2011]. learning to distinguish between ‘what’ and ‘how’ information and to apply the different types of information appropriately can be a challenge. In the early stages of the design process, these bad mixes of ‘what’ and ‘how’ information manifest as the presence of DPs or physical information in the high-level FRs. These errors can usually be identified by the presence or emphasis on a noun (a physical means of performing a function) instead of on the verb (the function that should be performed). The verbs ‘to use’ (i.e. ‘The artifact should use [material, component, energy source, etc.]’) and ‘to have’ (i.e. ‘The artifact

(19)

16 should have [component or feature]’) are also commonly associated with these types of errors.

2.3 QFD’s STATE OF THE ART

2.3.1 WHAT IS A “QUALITY FUNCTION DEPLOYMENT”?

A Quality Function Deployment (QFD) QFD is a method by which customer requirements are translated into engineering or design requirements.

These engineering or design requirements are then translated into product or part characteristics, which are then in-turn translated into process plans. These plans are then translated into specific operations, conditions, or controls. The focus of all this activity is to assure that the customer's requirements (which are often referred to as the "Voice of the Customer" since they are expressed in their own words) are filtered through this entire process.

QFD is a method of "mapping" the elements, events, and activities that are necessary throughout the development process to achieve customer satisfaction. It is a technique oriented approach using surveys, reviews, analyses, relation- ship matrices, and robust designs all centered on the theme of translating the "Voice of the Customer" into items that are measurable, action- able, and potentially capable of improvement. [Michael A. Schubert, 1989].

2.3.2 HISTORY AND GROWTH

Compared to other methods of planning and development, QFD is relatively new. The methodology was developed in Japan by Dr. Shigeru Mizuno from the Tokyo Institute of Technology. During the late 1960's and early 1970's Dr. Mizuno had been working with Kobe Shipyards of Mitsubishi Heavy Industries, Ltd. on product planning. In 1972, he struck upon the development of "quality tables" to help support planning which later evolved into what is now called Quality Function Deployment (QFD). Toyota (Autobody Group) had taken notice of Mitsubishi's success in the middle 1970's and spent over three years studying this method and developing case studies. Toyota Autobody began using QFD in 1977 and has experienced significant benefits in the areas of:

(20)

17 • Reduced costs of new model start (down 60%);

• Reductions in new model development time (down 50%); • Production start-up essentially free from "learning curve”.

From the early 1970' the number of companies in Japan using QFD and the number of articles about QFD appearing in Japanese publications has been growing exponentially.

Export of the QFD methodology to the United States came from two sources, Ford Motor Company and the Cambridge Corporation. The exposure through Ford came as a result of a mid-1983 study mission to Japan which included a number this of their key suppliers. During this study, they were introduced to the philosophy of QFD by Dr. Kaoru Ishikawa and the Japanese Union of Scientists and Engineers. Following up on this initial exposure, Ford contracted with Dr. Don Clausing (formerly with Xerox Corporation) to introduce the operating mechanism of QFD to their engineers and key suppliers. Dr. Clausing had been a consultant at Fuji Xerox and became aware of QFD through Dr. Makabe of the Tokyo Institute of Technology.

The first recorded case study in QFD in the US was probably in 1986 when Kelsey Hayes used QFD to develop a coolant sensor, which fulfilled critical customer needs such as ‘‘easy-to-add coolant’’, ‘‘easy-to-identify unit’’, and ‘‘provide cap removal instructions’’ (King, 1987a; Prasad, 1998a).

Early adopters of QFD in the US included 3M Company, AT&T, Baxter Healthcare, Budd, Chrysler, DEC, Ford Motor, General Motors, Goodyear, Hewlett-Packard, IBM, ITT, Kodak Eastman, Motorola, NASA, NCR, Polaroid, Procter and Gamble, and Xerox.

Many other companies have used QFD and realized significant benefits, and the tool continues to grow in popularity. Griffin and Hauser (1992) believe that there are more than 100 major companies using QFD in the US.

(21)

18 2.3.3 FUNCTIONAL FIELDS OF QFD

QFD was originally proposed, through collecting and analyzing the voice of the customer, to develop products with higher quality to meet or surpass customer’s needs. Thus, the primary functions of QFD are product development, quality management, and customer needs analysis. Later, QFD’s functions had been expanded to wider fields such as design, planning, decision-making, engineering, management, teamwork, timing, and costing. Essentially, there is no definite boundary for QFD’s potential fields of applications.

(22)

19 2.3.4 QFD’s STRUCTURE

Figure 2 - House Of Quality Rooms

The present study is based on the book "Product Design and Development, Ulrich-Eppinger". In the section that follows we will explain the House of Quality structure and we will explain what represents every room.

ROOM 1: CUSTOMER NEEDS

The Room 1 is on the left section of the HOQ and is represented by a structured list of customer needs concerning the product that the entity is developing (we

(23)

20 are using the term "entity" because the design process and the related actors will discuss in the chapters that follow).

ROOM 2: PLANNING MATRIX

The Room 2 is on the right of the HOQ, and it is composed by many section that represent the modality for the information diffusion within the Organization. The Planning Matrix allows to:

• compare the product's performance (that the entity is developing) with the competitor's product performance; in this Room the performances are evaluated considering how the products meet the customer needs;

• develop a strategy that allows to optimize the Company ability in order to satisfy the customers both in the short and in the long periods;

ROOM 3: DESIGN CHARACTERISTICS (SQCs)

In the HOQ, the columns represent the characteristics that the products will have to. Room 3 is on the top of HOQ. The design characteristics represent the translation of the Customer’s Needs in the designer's language.

The term SQCs is the acronym of Substitute Quality Characteristic and represents every considered information (performance, characteristics or attributes of the product). In the chapters that follows we will call the design characteristics using a different noun: specifications. In the columns of QFD we can observe the physical domain of the product.

ROOM 4: RELATIONS MATRIX

The central section of the QFD we can see the Relations Matrix. This tool aids the entity to assure that each customer need has been deployed at least in one design characteristic. Furthermore, in the Room 4, each relation is weighted in qualitative way in order to measure the level of relation between Needs and Design Characteristics.

ROOM 5: COMPETITIVE BENCHMARKING

The Room 5 is in the lower section of the QFD. The Room 5 contains the results of the Benchmarking process.

(24)

21 The abovementioned process consisting in a comparison activity between the product that the entity is developing and similar products of other companies. The comparison is referred to the product's design characteristics.

ROOM 6: TARGET

In the lower section of the QFD the Room 6 takes place.

The targets represent a collection of evaluations, related to each SQC based on a level of importance-priority that the customer assigns to the SQC.

ROOM 7: CORRELATION MATRIX

The last section of the QFD is the roof that represent half of a quadrate matrix, cut along its diagonal and turned of 45 degree.

The roof represents a powerful tool, and through the possibility of evaluate the degree of correlation between two design characteristics both in positive manner and in negative manner, the roof allows to determine marketing leverage (+ correlation) and contradiction (- correlation) that must be solved.

2.3.5 THE PROVIDED RULES TO EXPRESS CUSTOMER NEEDS

• Express the need in terms of what the product has to do, not in terms of how it might do it. Customers often express their preferences by describing a solution concept or an implementation approach; however, the need statement should be expressed in terms independent of a particular technological solution.

• Express the need as specifically as the raw data. Needs can be expressed at many different levels of detail. To avoid loss of information, express the need at the same level of detail as the raw data.

• Use positive, not negative, phrasing. Subsequent translation of a need into a product specification is easier if the need is expressed as a positive statement. This is not a rigid guideline, because sometimes positive phrasing is difficult and awkward. For example, one of the need statements is “the screwdriver does not strip screw heads.” This need is more naturally expressed in a negative form.

(25)

22 • Express the need as an attribute of the product. Wording needs as

statements about the product ensures consistency and facilitates subsequent translation into product specifications. Not all needs can be cleanly expressed as attributes of the product, however, and in most of these cases the needs can be expressed as attributes of the user of the product (e.g., “the user can apply torque manually to the screwdriver to drive a screw”).

Avoid the words must and should. The words must and should imply a level of importance for the need.

2.3.6 THE PROVIDED RULES TO EXPRESS THE SPECIFICATIONS An example of metric follows:

“average time to assemble” A metric and the related value derive a specification.

A few guidelines should be considered when constructing the list of metrics: • Metrics should be complete. Ideally each customer need would correspond

to a single metric, and the value of that metric would correlate perfectly with satisfaction of that need. In practice, several metrics may be necessary to completely reflect a single customer need;

Metrics should be dependent, not independent, variables. As do

customer needs, specifications also indicate what the product must do, but not how the specifications will be achieved. Designers use many types of variables in product development; some are dependent, such as the mass of the fork, and some are independent, such as the material used for the fork. In other words, designers cannot control mass directly because it arises from other independent decisions the designers will make, such as dimensions and materials choices. Metrics specify the overall performance of a product and should therefore be the dependent variables (i.e., the performance measures or output variables) in the design problem. By using dependent variables for the specifications, designers are left with the freedom to achieve the specifications using the best approach possible.

Metrics should be practical. It does not serve the entity to devise a metric

(26)

23 at a cost of $100,000. Ideally, metrics will be directly observable or properties of the product that can be easily evaluated by the entity.

• Some needs cannot easily be translated into quantifiable metrics.

The metrics should include the popular criteria for comparison in the

marketplace. Many customers in various markets buy products based on independently published evaluations. Such evaluations are found, for example, in Popular Science, Consumer Reports, on various Internet sites, or, in our case, in Bicycling and Mountain Bike magazines. If the team knows that its product will be evaluated by the trade media and knows what the evaluation criteria will be, then it should include metrics corresponding to these criteria.

2.3.7 CUSTOMER’S NEEDS IDENTIFICATION: STEPS

In this section, we present what the state of the art provides if an entity has the intention to explore the customer's needs. The method that follows represents the trigger of the Quality Function Deployment. Furthermore, this analysis has been the initial step of our study, the trigger of the entire present study.

As we seen in the previous picture, the process is developed in five steps [Ulrich, 2000]:

1. COLLECT CUSTOMER INDICATION;

2. TRANSLATE INDICATION IN CUSTOMER NEED; 3. ORGANIZE CUSTOMER NEEDS;

4. IMPORTANCE ESTIMATION; 5. REVIEW

With the purpose to improve the phase comprehension, we drawn a flowchart that explain the process.

Integrating the generated document in each activity we can also explain the proposed tools, in fact, generally a tool creates at least a document in output.

3. METHODOLOGY

(27)

24 1. The Requirements, Needs and Specifications search on the sources based

on the first definitions analysis;

2. The Needs and Specifications search on the sources based on the second definitions analysis

3. The Design review method and procedure.

3.1 THE “GOOGLE ADVANCED SEARCH” BASED METHODOLOGY

3.1.1 FIRST ANALYSIS ON THE REQUIREMENTS, NEEDS AND SPECIFICATION DEFINITIONS

In this chapter we will analyse the definitions that are present in literature about REQUIREMENTS, NEEDS and SPECIFICATIONS, and we will to derive the natural form of these elements, i.e. in which form can we found the abovementioned elements? And forward, where?

All development processes are built on REQUIRIMENTS, NEEDS and SPECIFICATIONS.

REQUIREMENT

“A requirement is a need, expectation, or obligation. It can be stated or implied by an organization, its customers, or other interested parties. A specified requirement is one that has been stated (in a document for

example), whereas an implied requirement is a need, expectation, or obligation that is common practice or customary.”

[ISO 9000, 2005]

In the first phase of the analysis about the definition, we committed an error about the requirement's definition meaning, this error derive from a bad translation. Anyway, we have to consider this phase because the results of the analysis given the basis of our study.

The first meaning that we understand about the requirement definition is that the R (Requirements) represent something that has an obligation nature.

This particular kind of nature is generally linked to verbs that communicate commands. In Italian language exists the "IMPERATIVO" form that represents the verbs conjugation that identifies the commands.

So, the first question is: if we are searching for the Requirements, can we search for them utilizing in our query the imperative forms?

(28)

25 We have to focus on another important section of the definition, in particular the one that regards both the implied and the stated form of the requirement.

It's worth to explain that a Need, i.e. a Customer's need, of which we have discussed on the previous chapter, can be stated and not only implied such as is declared in definition.

3.1.1.2 HYPOTHESIS ABOUT THE NEEDS AND SPECIFICATION FORM In order to find the sources that provide Needs and Specification, we have to hypothesize their form, i.e. their clearer syntax form.

Our study starts from an Italian project, and it was very hard to adapt all the work to the English language. Another issue that derives from the language is the grammar. Italian grammar it's quite different compared to the English grammar. So, in order to better achieve our targets, we used rules or classifications which are specific of the Italian grammar.

As we seen during the definitions analysis, a need is "independent from any particular technology of product and they express through the functions or through the desired product attributes", so in order to discriminate the Needs we have immediately thought to the "Functional Verbs".

Moreover, during the Customer's Needs analysis that appears in the QFD method during both the PSSP course at the University of Pisa and the Thesis work, we had the opportunity both generate and analyse a several number of Customer's Needs.

In the majority of the cases the functional verbs appeared and moreover, the functional verbs were preceded by other verbs. The commoner verb was "to allow". So, we have been search a classification about this verb in order to find a "pre-built" cluster in which we could find verbs that have similar behaviours to the "allow" verb.

We found this cluster in the Italian grammar, so we found the "Volivi" verbs classification in the TRECCANI encyclopaedia.

A list of this verbs follows. We can see the verbs both in Italian language and their translation:

(29)

26 • Volere • comandare, • ordinare, • proibire, • esigere, • concedere, • consentire, • vietare, • proibire, • permettere, • imporre, • ingiungere, • suggerire, • intimare • want • command • order • prohibit • require • grant • allow • permit • forbid • impose • enjoin • suggest

Table 1 - Volivi Verbs and their translations

In the next table, we verify if there are any of this verbs in the Functional Verbs Table and if we can use them in the needs identification (considering also the 5 rules about the customer’s needs expression):

Verb FUNCTIONAL TAB NOTE want N command N In the functional table there is “control” that represents a synonymous allow Y permit N forbid N It represents the exact opposite of

(30)

27 allow, and it also

represents a prohibition with imperative form. We have moreover to consider its negative nature. We will not use it in

the needs recognition because probably is linked to requirements. impose N It communicates an imperative form, so for this reason we will not use it for the

needs recognition, because it goes against the 5 rules

that we presented before. enjoin N suggest N

Table 2 - Volivi Verbs presence in Functional Verbs Tab

Now we can provide a structure about the customer needs:

SUBJECT + FUNCTIONAL VERBS + LINKED DETAILS OR

SUBJECT + VOLIVO VERB + FUNCTIONAL VERB (or a noun that have the same stem of the F.V.) + LINKED DETAILS

With the purpose of provide a better comprehension, some example follows (considering the example in the chapter 1):

(31)

28 “allows easy replacement of worn parts”

• Subject: implied but is referred to the product; • Volivo verb: Allow;

• Functional Verb: Replace- ment, we have to consider just the stem of the noun "replacement", i.e "replace_" which is a functional verb;

• Linked details: To worn parts: represents linked details that give to the sentence the right meaning, in this case we can observe a specification complement.

Another example is represented by:

“reduces vibrations to the hands” • Subject: implied;

• Functional Verb: Reduce_s;

• Linked details: Vibration represents the direct object.

Talking about the specifications, as we seen before they appear like a module the metric with its value. Anyway they are a representation of the physical domain.

So, the structure follows:

METRIC + VALUE

Or, if impossible link the specification with the need, and the metric is qualitative, the state of the art suggests this structure:

NEED EXPRESSION + “SUBJ” ANNOTATION Considering the previous example:

(32)

29 A first intuition suggests that the specification has to being searched considering the physical domain.

Considering the provided rules about the specification, we can affirm that using a value we have also provide its linked unit of measure. For example, for a mass we will use the kilograms, for a length the meters, or their abbreviations.

Taking into account these considerations, we can affirm that we will search the specification exploiting a list of physical dimensions.

3.1.2 WHERE THE REQUIREMENTS, NEEDS AND THE SPECIFICATIONS ARE?

The purpose of this paragraph is to provide a first list of sources in which we could find the elements of our study: Requirements, Needs and Specifications.

In the first instance, we will analyse the most significant definitions e we will try to point the key words.

So, for the analysis we chose a collecting data tool that has the table form.

DEFINITION KEY WORD POSSIBLE SOURCES

needs are substantially independent from any particular technology of product and they

express through the functions or through the desired product attributes function attributes desire_d FUNCTIONAL ANALYSIS YOUTUBE PATENTS REVIEWS BLOGS

pertanto non sono specifici del concetto che si deciderà alla fine

di adottare

(33)

30

In psychology the need is the total or

partial lack of one or more elements that constitute the well-being of the

person

LACK

WELL-BEING specific sources that We can search in permit to the users to explain their issue, i.e. each web source in which is possible to write a comment for example.

Table 3 - Assumption based on definitions

Talking about the specification we can search for example in technical documents, or moreover on sources that allow to compare similar products, for example the e-commerce platforms. Would be interesting observe the presence of the needs and the specification in a crowdfunding platform. In a sense, a crowdfunder tries to sell his idea, so the backer must be able to does a comparison between different ideas.

In order to makes available every necessary information, the crowdfunder provides a list of function (that we have to prove that represent needs) and, according to one the 5 rules about the metrics, an easily to read list of specifications.

A first list of technical sources follows: • TENDERS;

• DATA SHEETS;

• KICKSTARTER COMMENTS; • PRODUCT DESCRIPTIONS.

In the following section, we will better explain our hypothesis and we will try to prove them. Anyway, the main topics which we faced in this chapter, will dealt better in the one that follows.

The definition analysis will allow to develop the first method that we have implemented, but due to an error in translation we will to rectify the first definition

(34)

31 3.1.3 THE REQUIREMENTS, NEEDS AND SPECIFICATIONS SEARCH ON THE SOURCES BASED ON THE FIRST DEFINITIONS ANALYSIS

This methodology is based on achievement of two different target:

1. Test the sources: we will use GOOGLE ADVANCED SEARCH tool, to take advantage from the opportunity to use the query in a targeted manner;

2. Record and quantify the results: we will build an ad hoc matrix based on that one provided by the Google’s online tool.

Which sources we will test?

The list of sources that we will search in this phase follows: SOURCE BLOGS DATA SHEETS PATENTS TENDERS REVIEWS GITHUB FILE MD YOUTUBE COMMENTS E-COMMERCES FUNCTIONAL ANALYSIS INTERVIEWS KICKSTARTER TWEETER

Proceeding this way, we should be able to measure which source is better than other and where we can find the better expressions about requirements, specifications and customer needs.

The searching/recording tab that follows is simply the copy of the provided tool by Google Advanced Search. The only differences consist in some improvements which allow to record the results and to take notes.

The method in fact isn't automatic, but semi-automatic. It consists in the queries selection for each element about that we want to test on the selected source, and then we will analyse the result using the "search command" on the found pages. The search command tool allows to view in different colours the elements that

(35)

32 we wrote in the queries. So, the analyst has to examine by his own (without a tool help) the correlation of the elements and Requirements, Needs and Specifications. The last phase is the part of recognition and is based on the analyst's skills.

Anyway, for each selected source, the process must be iterated three times, in order to recognize the presence of Requirements, Needs and Specifications.

(36)

33

SOURCE TYPE SOURCE NAME GOOGLE TAB REQUIREMENT SPECIFICATION CUSTOMER NEED

SO

U

RC

E

TY

PE

SO

U

RC

E

N

AME

ALL THESE WORDS

THIS EXACT WORD OR PHRASE

ANY ONE OF THESE WORDS

NONE OF THESE WORDS

NUMBERS FROM TO TO TO

LIMITATIONS FOR LANGUAGES GEOGRAPHIC AREA LAST UPDATE SITE OR DOMAIN TERMS APPEARING FILE TYPE USE RIGHT NUMBER OF PAGES

SIGNIFICANT? “YES” OR “NO” NOTES “YES” OR “NO” NOTES “YES” OR “NO” NOTES

(37)

34 3.1.3.1. QUERIES BUILDING

In order to test the sources, we have to know the form of the elements. The following elements (that will be used in the queries construction), derive from the analysis about the definition which we implemented in the State of the art section. 3.1.3.2. REQUIREMENTS

Considering the mandatory nature of the Requirements, we have to search the verbal forms that identify the obligations, i.e. the imperative forms. A list of used words follows:

Have to, must, should, owe, ought to, shall, shall be Or nouns:

Duty, obligation

3.1.3.3. NEEDS

In order to search the needs into the sources, we have to consider the definition that follows:

“needs are substantially independent from any particular technology of product and they express through the functions or through the desired product

attributes”

(From Product and Design Development)

The fundamental information that we can extract from the abovementioned definition it's about the functions.

We can use the functional verbs tab which contains a detailed list of functions. That functions are independent from any particular technology.

So, in order to build the queries about the needs identifications, we can use the functional verbs.

The verbs selection is based on the expected behaviour of the product that we have chosen for test the sources. In fact, using the tool that we are explaining in these sections, we can insert just few words.

(38)

35 Class

(Primary)

Secondary Tertiary Correspondents

Branch Separate Isolate, sever, disjoin

Divide Detach, isolate, release, sort, split, disconnect, subtract

Extract Refine, filter, purify, percolate, strain, clear

Remove Cut, drill, lathe, polish, sand Distribute Diffuse, dispel, disperse, dissipate,

diverge, scatter

Channel Import Form entrance, allow, input, capture Export Dispose, eject, emit, empty, remove,

destroy, eliminate

Transfer Carry, deliver

Transport Advance, lift, move Transmit Conduct, convey

Guide Direct, shift, steer, straighten, switch Translate Move, relocate

Rotate Spin, turn

Allow DOF Constrain, unfasten, unlock

Connect Couple Associate, connect

Join Assemble, fasten Link Attach

Mix Add, blend, coalesce, combine, pack Control

Magnitude

Actuate Enable, initiate, start, turn-on Regulate Control, equalize, limit, maintain

Increase Allow, open

Decrease Close, delay, interrupt

Change Adjust, modulate, clear, demodulate, invert, normalize, rectify, reset, scale, vary, modify

Increment Amplify, enhance, magnify, multiply Decrement Attenuate, dampen, reduce Shape Compact, compress, crush, pierce,

deform, form Condition Prepare, adapt, treat

Stop End, halt, pause, interrupt, restrain Prevent Disable, turn-off

Inhibit Shield, insulate, protect, resist Convert Convert Condense, create, decode, differentiate,

digitize, encode, evaporate, generate, integrate, liquefy, process, solidify, transform

Provision Store Accumulate

Contain Capture, enclose

Collect Absorb, consume, fill, reserve Supply Provide, replenish, retrieve

Signal Sense Feel, determine

Detect Discern, perceive, recognize Measure Identify, locate

(39)

36

Track Mark, time Display Emit, expose, select Process Compare, calculate, check

Support Stabilize Steady

Secure Constrain, hold, place, fix Position Align, locate, orient

Table 5 - Functional Verbs 3.1.3.4. SPECIFICATIONS

Specifications are linked with the units of measure or their linked symbols. We are affirming that considering the definitions previously analysed. In fact, we know that the specifications are linked to the physical domain about a product. This words linked to this particular element (i.e. the specifications) are easy to identify because they are regulated by the ISO.

So, it was easy to list the words and their related symbols. Anyway, we can see two clusters of words:

• The Base Unit • The Derived Unit The lists follow:

(40)

37 and the derived units:

Name Symbol Quantity Equivalents SI base unit Equivalents

hertz Hz frequency 1/s s−1

radian rad angle m/m dimensionless

steradian sr solid angle m2/m2 dimensionless newton N force, weight kg m/s2 kg m s−2

pascal Pa pressure, stress N/m2 kg m−1 s−2

joule J energy, work, heat

N m C V W s

kg m2 s−2

watt W power, radiant flux J/s

V A kg m2 s−3 coulomb C electric charge or quantity of electricity s A

F V s A volt V voltage, electrical potential difference, electromotive force W/A

J/C kg m2 s−3 A−1 farad F electrical capacitance C/V

s/Ω kg−1 m−2 s4 A2 Name Symbol Unicode Symbol Measure Dimension symbol

metre m - length L

kilogram kg kg mass M

second s - time T

ampere A - electric current I

kelvin K K thermodynamic temperature Θ

mole mol mol substance amount of N

candela cd cd luminous intensity J

(41)

38

ohm Ω electrical resistance, impedance, reactance 1/S

V/A kg m2 s−3 A−2 siemens S electrical conductance 1/Ω A/V kg−1 m−2 s3 A2

weber Wb magnetic flux J/A

T m2 kg m

2 s−2 A−1

tesla T magnetic field strength, magnetic flux density

V s/m2 Wb/m2 N/(A m)

kg s−2 A−1

henry H electrical inductance

V s/A Ω s Wb/A

kg m2 s−2 A−2 degree Celsius °C temperature relative to 273.15 K K K

lumen lm luminous flux cd sr cd

lux lx illuminance lm/m2 m−2 cd

becquerel Bq radioactivity (decays per unit time) 1/s s−1 gray Gy absorbed dose (of ionizing radiation) J/kg m2 s−2 sievert Sv equivalent dose (of ionizing radiation) J/kg m2 s−2 katal kat catalytic activity mol/s s−1 mol

(42)

39

3.1.3.5 SOME WORDS ABOUT THE FIRST METHOD

Is useful to spend some words in order to better understand the limitations of the presented method. Both the Google Advanced Search tool and the used tool about the words identification have the limitation that we can insert just few words. So, before the search phase, we have to choose the words, in particular a subset that derives from the lists that we presented above.

Obviously, the selected words depend by the considered product chosen for the search. Considering the nature of the products, and their main functions, we will able to select a set of words which (intuitively) are easier to find (for that one product) than others.

(43)

40

3.2 THE R-BASED METHODOLOGY

3.2.1 ANALYSIS AND CORRECTION ON DEFINITIONS PREVIOUSLY USED The second iteration about the definitions study starts in order to clarify some concepts.

The analysis, hypothesis and related demonstrations are described in this section. The results of this study allow to implement a different method compared to the one based on the first definitions analysis, anyway the target is the same: measure the presence of the requirements in the selected sources.

3.2.1.1 REQUIREMENT: PROBLEMS ABOUT DEFINITIONS

In literature we can find a lot of definitions about “requirement”, but sometimes these definitions can confuse who tries to understand the real meaning of abovementioned word. So we will see some definitions about requirement, and after we will try to explain the definition's meaning.

We start with ISO 9001 definition:

(1)A requirement is a need, expectation, or obligation. It can be stated or implied by an organization, its customers, or other interested parties.

[ ISO 9001, 2015]

(1) As you can see, the abovementioned definition is linked to needs, expectations and obligations, referred to each Stakeholders. It’s easy to understand that the requirements represent a cluster in which are collected aforementioned elements. In order to simplify the cluster, we can create two sub-clusters, “Statutory Requirements” and “Not Statutory Requirements”. We can start to build a tree in order to decompose the requirements.

(44)

41

The definition of requirement that we find in ISO 9001 can be further reduced, considering the definitions about Need and Expectation:

Need (N) Expectation (E)

Needs (N): an expression of a perceived undesirable situation to be avoided or a

desirable situation to be attained. This situation can

be perceived by any of the actors involved in the product

life from the purchasing phase to each stage of use

and disposal.

From – “Situating needs and requirements in the FBS

framework” – (Cascini, Fantoni, Montagna, 2012)

a belief that something should happen in a particular way, or that someone or something

should have particular qualities or behaviour [MACMILLAN DICTIONARY]

“Expectation” is included in “Need” because N is more detailed than E, indeed each definition express the same concept, but in N we can find negative form, specifically in the sentence which says “undesirable situation to be avoided”. We can interpret the obligations in key of statutory needs.

So we can keep going to build our requirements tree as follows:

so, we can include the expectations in needs cluster, and the obligations in the statutory needs cluster.

(45)

42

“Requirement: a measurable property related to one or more Needs. They ‘are structured and formalised information about a product’ and ‘consist of a metric

and a value’.”

[Cascini, Fantoni & Montagna, 2012]

We have to implement some corrections about the above cited definition, considering the ISO 9001's definition:

“There are many types of requirements. Some of these include customer requirements, quality requirements, quality management requirements, management requirements, product requirements, service requirements,

contractual requirements, statutory requirements, and regulatory requirements.”

From – ISO 9001

Figure 4 - Requirements Tree 2

Again, as you can see, the definition is referred to a big cluster that has inside a lot of elements, often very different between themselves.

So, for this case study, we will use the Cascini – Fantoni – Montagna’s definition, but not for requirements, we will use it for Specifications Definitions:

“Each specification consists of a metric, a weighting of importance, units, a marginal value, and an ideal value.”

(46)

43

That definition is quite similar to the definition of Cascini – Fantoni – Montagna about requirements. It does not mean that the abovementioned authors were wrong, but the differences are due to the context. So, every definition is referred to the model that we are creating.

Now we can identify a further decomposition, considering the Mary Kathryn Thompson’s research about the Axiomatic Design improvement, specifically “A CLASSIFICATION OF PROCEDURAL ERRORS IN THE DEFINITION OF FUNCTIONAL REQUIREMENTS IN AXIOMATIC DESIGN THEORY” [Thompson, 2013].

Axiomatic design study is important for our model, because in that tool we can clearly separate the functional domain and the physical domain, i.e. “what” and “how” information.

What in AD is a functional requirement has the characteristics to be expressed in our model as NEED, and what is DP has the characteristics to be expressed as a part of SPECIFICATION.

When a specification (S) is stated (for example in a TENDER with contractual requirements, or in the case of a costumer explain what he wants in term of specification in a particular product, or in a regulation), the abovementioned S represent a statutory requirement.

When a specification represents “how” a designer responds to a particular “what”, the S is a “not statutory requirement”.

Now we can complete our tree of requirement:

(47)

44

3.2.2.1 STATUTORY DOMAIN

When a requirement is completely stated, i.e. in form of NEED and related SPECIFICATION, the designer doesn't have degree of freedom in his creativity process. An example about this case might be represented by a requirement completely stated in a tender.

So, in this case the Statutory requirement represent an absolute obligation. Probably the most common way that we can find a Statutory requirement when it is in stated form, is in only SPECIFICATION form, i.e. in its physical domain. Also in this case the abovementioned requirement represents an absolute obligation (we will explain this concept successively, when we will identify the logic transitions in need/specification transformation).

When a statutory requirement has the form of need, i.e. linked to a functional verb preceded by a imperative verb, it not represents an absolute obligation, in fact, in this case, the designer has the ability to use his creativity in order to propose a solution in form of specification. In conclusion, a N in SR domain represents a Partial Obligation.

FORM SR DOMAIN

N+S ABSOLUTE OBLIGATION

S ABSOLUTE OBLIGATION

N PARTIAL OBLIGATION

Table 8 - Assumptions About the Absolute and Partial Obligations

3.2.2.2 NOT STATUTORY DOMAIN

In the NS domain, the requirements are completely released, in accord with their definition. Obviously, every need and every solution found, must be filter with the project environment, as we seen on the previous paragraphs.

3.2.2.3 PROVING THE ASSUMPTIONS ABOUT THE ABSOLUTE AND PARTIAL OBLIGATIONS OF THE REQUIREMENTS

in the section that follows we have to prove the assumptions that we have previously assumed. the assumptions are related to the absolute and partial obligation linked to the needs and the specifications.

In order to achieve a prove about our assumptions, we will utilize a tender that regards the construction of a metro, in particular the construction of a train.

Riferimenti

Documenti correlati

[r]

Origin of the West Nile virus responsible for an outbreak of encephalitis in the northeastern United States.. Giladi M, Metzkor-Cotter E, Martin DA,

Regardless of the legal venue, the primary responsibility of the clinical neuropsychologist participating in forensic work is to provide information based on

Effective advocacy for policy change at all levels - local, national, and global - can reduce exposure to cancer risk factors and improve access and availability of essential

Despite the higher number of improving test locations, the average sensitivity decreased more in the surgically treated group as compared to the medically treated group.. On

Sono quindi soddis- fatte le ipotesi

Corso di Laurea in Scienze Fisiche Prova finale del

ni differenziali