A Structured Approach for Classifying and Prioritizing Product Requirements

(1)

ABSTRACT

JACKSON, HAROLD VAUGHN JR. A Structured Approach for Classifying and Prioritizing Product Requirements. (Under the Direction of Dr. William A. Smith Jr. and Dr. Wilbur L. Meier Jr.)

New product development involves making a series of decisions that transform vaguely defined customer needs and desires into a final product. Two important, but often overlooked, product development decisions are (1) the classification of requirements as

mandatory or optional, and (2) the prioritization of requirements. This research effort addresses the current lack of theoretically sound and practical methods for classifying and prioritizing product requirements by focusing on three primary objectives. The first objective is to develop a structured approach for classifying and prioritizing product requirements. The second objective is to use the structured approach to gather, analyze, and aggregate stakeholder input. The third objective is to use the structured approach to support both group and individual learning.

(2)

SRAM uses MADM as a solution framework for classifying and prioritizing product requirements. Requirements are evaluated using market orientation based (market priority, risk, customer value, and performance) qualitative (fuzzy linguistic) and quantitative decision criteria. Within this MADM framework, the Analytical Hierarchy Process (AHP) and entropy weighting are used to derive attribute importance weights and define stakeholder preference structures. Where pairwise comparison inconsistencies are passively corrected using a geometric averaging procedure for constructing supertransitive approximation to binary matrices. Each stakeholder’s requirement classifications and priorities are derived via the hierarchical application of the Technique for Order Preference By Similarity to the Ideal Solution (TOPSIS). While the results for an aggregated group of stakeholders are determined using weighted Borda Scoring and heuristic decision rules.

Through the first and second case studies, it was discovered that resolving real-world problems requires understanding both how decision-makers should ideally behave and how they actually behave. Accordingly, quantitative results generated using traditional decision analysis methods were qualitatively analyzed using the essential elements of good decision-making (framing, gathering intelligence, coming to conclusions, and

(3)

A STRUCTURED APPROACH FOR CLASSIFYING AND PRIORITIZING PRODUCT REQUIREMENTS

BY

HAROLD VAUGHN JACKSON JR.

A dissertation submitted to the Graduate Faculty of North Carolina State University in partial fulfillment

of the requirements for the degree of Doctor of Philosophy

Industrial Engineering

1999

Approved by __________________________________________________ Dr. William A. Smith, Jr.: Co-Chairperson of Advisory Committee

_________________________________________________ Dr. Wilbur L. Meier, Jr.: Co-Chairperson of Advisory Committee

_________________________________________________ Dr. Jaime Trevino: Member of Advisory Committee

(4)

DEDICATION

(5)

BIOGRAPHY

(6)

ACKNOWLEDGEMENTS

I want to express the utmost appreciation and respect to my advisor Dr. William A. Smith Jr. for his guidance and support throughout my academic experience at NCSU. His input regarding the importance of simplicity and focus made the completion of this thesis possible.

I would also like to thank Dr. Wilber L. Meier Jr. for his participation as the co-chair of my graduate committee. His assistance and guidance has been invaluable. In addition, I would like to thank Dr. Jaime Trevino for serving as a committee member and for presenting me with the challenge of completing my thesis while working full-time as a consultant. Finally, I would like to thank Dr. Thomas Johnson, for serving as a committee member, and for always being a source of encouragement and insightful ideas.

I would like to thank my parents. My father, Mr. Harold Vaughn Jackson Sr., for instilling in me the academic and personal discipline needed to complete this thesis. My mother, Mrs. Barbara Reese Jackson, for a lifetime of encouragement, and for ensuring that I had access to the best educational opportunities as a child.

(7)

TABLE OF CONTENTS

LIST OF TABLES ... VII LIST OF FIGURES ...IX

CHAPTER 1: INTRODUCTION... 10

1.1 BACKGROUND ... 10

1.2PROBLEM STATEMENT ... 13

1.3 IMPORTANCE OF RESEARCH... 15

1.4 RESEARCH OBJECTIVES & SCOPE... 18

1.5 BENEFITS OF RESEARCH ... 21

1.6 ORGANIZATION OF THE DISSERTATION ... 23

CHAPTER 2: LITERATURE REVIEW... 25

2.1 INTRODUCTION ... 25

2.2. REQUIREMENT ANALYSIS ... 26

2.21 Defining Requirements ... 26

2.22 Defining Requirement Analysis ... 27

2.23 Importance of Early Requirement Classification and Prioritization... 28

2.24 Defining Software Requirements... 29

2.25 Software Lifecycle Models... 31

2.26 Importance of Early Software Requirement Classification and Prioritization ... 34

2.3 MARKET ORIENTATION... 35

2.31 Defining Market Orientation... 35

2.32 Customer Value Analysis ... 38

2.33 Balanced Scorecard Performance Measurement ... 40

2.34 Performance Objectives ... 42

2.35 Risk Analysis ... 43

2.4 REVIEW OF EXISTING METHODS FOR EVALUATING PRODUCT REQUIREMENTS... 45

2.41 Quality Function Deployment (QFD) ... 45

2.42 Hill’s Order Qualifying and Order Winning Model... 48

2.43 Multivariate Data Analysis ... 50

2.5 ORGANIZATIONAL LEARNING... 52

2.51 Defining Organizational Learning ... 52

2.52 The Importance of Organizational Learning ... 53

2.53 Organization Learning and Structured Decision-Making... 54

2.6 MULTI-CRITERIA DECISION-MAKING (MCDM)... 59

2.61Defining Problem Solving & Decision-Making ... 59

2.62 Defining MCDM... 60

2.63 Group MCDM ... 63

2.64 MCDM Research Issues ... 64

2.7 MULTIPLE ATTRIBUTE DECISION-MAKING (MADM) METHODS ... 67

2.71 Defining MADM... 67

2.72 Simple Additive Weighting (SAW) ... 69

2.73 Analytical Hierarchy Process (AHP) ... 70

2.74 Entropy Weighting ... 72

2.75 Fuzzy MADM ... 74

2.76 Technique for Order Preference By Similarity to the Ideal Solution (TOPSIS)... 76

(8)

CHAPTER 3: SOLUTION APPROACH ... 80

3.2 SOLUTION APPROACH OUTLINE ... 81

3.3 SOLUTION APPROACH DEFINITION... 88

3.31 Framing... 88

3.32 Gathering Intelligence... 93

3.33 Coming To Conclusions ... 100

3.34 Learning From Feedback... 108

3.4 LIMITATIONS & KEY ASSUMPTIONS ... 110

3.5 SUMMARY... 112

CHAPTER 4: SOLUTION APPROACH IMPLEMENTATION ... 113

4.2 CASE STUDY NO.1 ... 114

4.21 Background ... 114

4.22 Implementation... 115

4.23 Summary... 170

4.3 CASE STUDY NO.2 ... 172

4.31 Background ... 172

4.32 Implementation... 173

4.33 Summary... 179

CHAPTER 5: SOLUTION APPROACH EVALUATION ... 181

5.2 EVALUATION OBJECTIVES AND SCOPE ... 181

5.3 EVALUATION APPROACH ... 184

5.4 EVALUATION RESULTS ... 190

5.5 SUMMARY... 191

CHAPTER 6: CONCLUSIONS AND RECOMMENDATIONS FOR FUTURE RESEARCH ... 192

6.2 SUMMARY OF WORK PERFORMED... 193

6.3 FINDINGS... 194

6.4 CONCLUSIONS... 195

6.5 CONTRIBUTIONS TO THE EXISTING BODY OF KNOWLEDGE ... 196

6.6 RECOMMENDATIONS FOR FUTURE RESEARCH ... 198

BIBLIOGRAPHY... 200

APPENDIX A: CASE STUDY NO.1 GRAPHICAL ANALYSIS ... 220

APPENDIX B: STRATEGIC PLANNING METHODOLOGIES ... 231

(9)

LIST OF TABLES

Table 1: Relative Cost to Fix an Error ... 17

Table 2: Software Quality Requirement Taxonomy ... 31

Table 3: Software Lifecycle Activities... 32

Table 4: Pairwise Comparison Evaluation Scale ... 94

Table 5: Qualitative Evaluation Scale No.1 ... 98

Table 8: Defuzzification of Qualitative Evaluation Scales ... 100

Table 9: Functional Requirement Definitions... 116

Table 10: Requirement Dependencies... 117

Table 11: Dependency Summary ... 118

Table 12: Evaluation Criteria Summary... 124

Table 13: Evaluation Scales ... 125

Table 14: Stakeholder Profiles ... 126

Table 15: Stakeholder Background ... 127

Table 16: Evaluation Relevancy ... 128

Table 17: Weighting Relevancy... 129

Table 18: Feasibility Evaluations ... 131

Table 19: Risk Attribute Weightings ... 132

Table 20: Inconsistent Vs. Consistent Weightings... 132

Table 21: Risk Evaluations ... 133

Table 22: Perceived Functionality... 135

Table 23: Cost Attribute Weightings ... 136

Table 24: Requirement Cost Summary ... 137

Table 25: Market Priority Attribute Weightings ... 138

Table 26: Customer Value Attribute Weightings... 139

Table 27: Benefit Attribute Weightings ... 139

Table 30: Performance Attribute Weightings ... 140

Table 35: Relative Overall Value Attribute Weightings ... 142

Table 36: Market Priority Attribute Weighting Comparisons ... 144

Table 37: Risk Attribute Weighting Comparisons ... 144

Table 38: Cost Attribute Weighting Comparisons ... 145

Table 39: Benefit Attribute Weighting Comparisons ... 145

Table 40: Customer Value Attribute Weighting Comparisons ... 146

Table 41: Performance Attribute Weighting Comparisons... 147

(10)

Table 43: Requirement Rankings ... 153

Table 50: Relative Overall Value Rankings... 158

Table 54: Relative Overall Value Rankings:... 160

Table 55: Comparison of Relative Overall Value Scores ... 160

Table 56: Comparison of Stakeholder Preference Rankings ... 161

Table 57: Decision Maker Importance Weightings ... 162

Table 58: Aggregation of Preference Rankings ... 163

Table 59: Mandatory Status Comparison... 164

Table 60: Aggregation of Mandatory Status ... 165

Table 61: Selection of Requirements ... 166

Table 62: Vision Criteria Pairwise Comparisons ... 176

Table 63: Vision Criteria Importance Weightings ... 176

Table 64: Vision Statement Evaluations ... 178

Table 65: Vision Evaluation Criteria Weighting Comparisons ... 178

Table 66: Vision Statement TOPSIS Scores ... 179

Table 67: Evaluator Profiles... 183

Table 68: Evaluator Profiles... 183

Table.69: Evaluator Profiles... 183

Table 70: Evaluation Criteria Importance Weightings ... 185

Table 73: Evaluation Results... 186

(11)

LIST OF FIGURES

Figure 1: SRAM Major Activities... 85

Figure 2: SRAM Research Contributions ... 86

Figure 3: SRAM IDEF0 Perspective... 87

Figure 4: SRAM Decision Criteria Hierarchy... 91

Figure 6: Decision Criteria Hierarchy - Case Study No.1... 122

Figure 7: Case Study No.1 - Critical Activities ... 130

Figure 8: Cumulative Requirement Value Vs. Cumulative Requirement Cost ... 167

(12)

CHAPTER 1 INTRODUCTION

“Your idea needs only to be original in its adaptation to the problem you are currently working on.”

Thomas Edison

1.1 BACKGROUND

The long-term prosperity and growth of an organization are determined by the successful introduction of new products. New products not only replace existing products, but they can also shift the entire basis of competition in previously stable markets. Without the capability to create well-designed products that are eagerly embraced by targeted customers, opportunities for prosperity are limited and will eventually evaporate in the heat of fierce competition. Furthermore, focusing heavily on incrementally improving existing products at the expense of creating new products will also eventually lead to an organization’s downfall (45). Hence, in today’s increasingly competitive and chaotic markets, many organizations are focusing on mastering the important and challenging process of developing new products.

Although there is no standard model for defining how new products are developed, the product development process is generally described as a five-stage process (1, 4, 9, 27, 28, 43, 45, 52). These fives phases may be summarized as follows:

1. Concept Development – The main objective of concept development is to identify and refine a new product idea. Key activities include; concept generation, concept screening, concept refinement, customer definition, market potential assessment, technology assessment, feasibility analysis, and preliminary business plan development (45, 9).

(13)

is understood by all stakeholders (35, 21, 48). Developing a formal set of product requirements involves three main activities (21, 50, 52, 31): requirement capture,

requirement analysis, and requirement specification. Other key conceptual design related activities include; development team selection, technology selection, identification of critical success factors, revaluation of the preliminary business plan, and project plan development.

3. Design Specification – The main objective of design specification is to translate requirement specifications into detailed product and process technical specifications. Formally stated stakeholder requirements are translated into technical specifications that can be produced or manufactured, given identified business plan objectives and product constraints.

4. Prototyping – The main objective of prototyping is the early testing, detection, and prevention of any potential design or production defects before a new product goes into full production. Thus, new product prototype testing is usually conducted under rigorous conditions that exceed expected stakeholder needs (9). Prototyping allows designers to both validate and modify product and process design specifications in a low cost environment before actual production begins.

5. Production – Often called either manufacturing ramp-up or commercialization, the main objectives of production are initial production of the new product, implementation of the business plan, and transferring product responsibility from the development team to marketing and manufacturing (45). The focus is on meeting key project objectives such as time to market, projected sales volumes, target product unit cost, and conformance to performance specifications (43, 45).

(14)

designers solve the ill-defined problem of translating vaguely defined needs, desires, and expectations of customers and users into a formal set of product requirements (35). Thus, it is of critical importance that each stage of the requirement development process (requirement capture, requirement analysis, and requirement specification) is well understood before tackling the arduous task of bringing a new product to market. A brief description of each phase of the requirement development process is as follows:

• Requirement Capture – Requirement capture involves gathering an initial set of candidate product requirements for analysis. The purpose is to gain as much knowledge as possible about the new product offering before selecting a final set of requirements for implementation. Possible sources of information for capturing product requirements include; potential customers and users, other product stakeholders besides customers and users, domain experts, literature, and existing products. Although all of the mentioned information sources are viewed as being important, communicating with potential customers and users is generally accepted as the most important source of information for successfully capturing requirements (1, 4, 15, 21, 23, 43). Successfully capturing product requirements is a challenging activity for designers because there is no standard method for defining requirements other than following generally accepted conformance guidelines such as completeness, correctness, unambiguity, understandability, modifiability, and consistency (3, 12, 13, 21, 35).

(15)

further compounded by the fact it involves the delicate social process of trying to build a consensus amongst stakeholders (35). Hence, both individual and group stakeholder perspectives must be simultaneously considered in order to derive a final solution. Requirement analysis can be broken down into two main decisions:

validation and choice. Validation is the continuous process of deciding whether both individual requirements and the final product are consistent with customer’s needs and intentions. Validation is not a discrete activity but instead involves continuously asking the question “Are we building the right product?” each time designers receive new information about the proposed product (3, 6, 35). Choice involves three key decision areas: classification, prioritization, and selection. First designers must

classify candidate requirements as mandatory or optional, then prioritize the classified requirements, and finally select specific requirements for implementation. Consequently, classification, prioritization, and selection decisions determine not only which requirements will be satisfied in the final product, but also what specific activities and organizational resources will be necessary to transform selected requirements into a successful product.

• Requirement Specification – Once requirements have been selected for inclusion in the final product, requirement specification involves providing formal documentation for each selected requirement as well as documenting critical requirement capture and analysis activities (12, 13, 25, 35). Requirement specifications are then translated into technical product and process specifications for are used for production purposes. Requirement specification is a critical product development success factor since designers must be able to review, modify, and update product requirements throughout the product lifecycle (2, 6, 12,13, 46, 54).

1.2 PROBLEM STATEMENT

(16)

34, 38, 42). This is in contrast to the fact that requirement classification and prioritization is becoming increasingly more important as companies are forced by competitive pressures to reduce time to market, reduce product cost, and increase product performance (9, 25, 43, 51). One potential reason for the lack of focus on the issue of requirement classification and prioritization is that there is no optimum solution to this ill-defined problem, only degrees of satisficing (81). Many feasible solutions exist and ending the decision making process is a matter of practical necessity (35). Moreover, since the success of any potential solution depends on unpredictable factors such as changing customer needs, desires, and perceptions, only the appropriateness of the process used to classify and prioritize requirements may be objectively assessed, not the derived solution. Hence, the classification and prioritization of requirements can not be adequately addressed through the strict application of traditional optimization or heuristic problem-solving methods. The inherent difficulty of classifying and prioritizing requirements often leads designers to “shoot from the hip” or inappropriately apply established methods without understanding that irrational decision-making will produce long-term failure (35, 51). This problem is compounded by existing requirement evaluation methods such as Quality Function Deployment (QFD) that address requirement classification and prioritization in an adhoc and confusing manner (1, 15, 38, 42, 178, 212, 213). Regardless of the underlying reasons why this issue has not been addressed, the fact remains that there currently is a noticeable absence of research regarding the classification and prioritization of product requirements early in the product development process. Thus, this research effort will address the following research problem:

The lack of structured, theoretically valid, and practical methods for classifying and

(17)

1.3 IMPORTANCE OF RESEARCH

New product development can be viewed as a series of key decisions that transform an initial conceptual design into a marketable product (45). Thus, the ability of product developers to systematically make rational decisions will ultimately determine the long-term success or failure of an organization’s product development process. Requirement classification and prioritization are critical product development decisions that effect a new product throughout its lifecycle. Requirement classification and prioritization decisions determine not only which requirements will be implemented in the final product, but also how organizational resources will be utilized throughout the product development process. This implies that product requirement classification and prioritization decisions directly effect three widely accepted product development performance measures: time to market, product lifecycle cost, and product performance

(2, 4, 9, 10, 20, 27, 28, 40, 41, 43, 44, 54). The importance of this research effort can be defined in relation to each of these critical performance measures:

Time to Market Issues: In order to reduce time to market, organizations often must limit the scope of product releases. This situation forces developers to classify requirements as mandatory or optional as well as prioritize requirements for implementation. However, this process is often done haphazardly with little regard for either correctness or consistency (51). Some benefits of reducing the time it takes to get a product to market are as follows:

Extended Sales Life: Each month cut from the product development process can add up to a month to a product’s sales life (43).

Increased Market Share: The first product to market has a 100 percent share of the market and the earlier a product appears, the greater the prospect for obtaining and retaining a large share of the market (43, 124, 142).

(18)

making pricing decisions. Thus, the longer it takes a product to reach the market the more its price will be dictated by the existing competition (43, 124, 142). In fact, a 50% overrun in product development cost may only lead to a 4% reduction in profit during a product’s lifecycle. In contrast, a 6 month delay in time to market can lead up to a 33% reduction in a product’s profit during its lifecycle (40, 44).

Product Lifecycle Cost Issues: The cost of identifying critical requirement related design issues escalates dramatically as a product goes from the early specification stage to its actual market release. Failure to classify and prioritize requirements early in the development process can lead to both increased development and product unit costs since both limited time and resources may be wasted on satisfying requirements customers view as worthless (27, 51). Some examples of the potential high cost of not classifying and prioritizing product requirements early in the product development process are as follows:

Ford Motor Company failed to identify rear impact collisions as a high priority

requirement for its 1970’s Pinto which directly resulted in the loss of lives and an estimated $100 million in litigation and recalls (21).

(19)

Table 1: Relative Cost to Fix an Error

Development Phase in Which Error Was Found Cost Ratio

• Requirements 1

• Design 3-6

• Coding 10

• Development Testing 15-40

• Acceptance Testing 30-70

• Operation 40-1000

These numbers do not consider the cost impact for projects that were not completed as a result of requirements related errors.

Approximately one third of large-scale software projects are not completed, and failure to properly classify and prioritize requirements is often sighted as the major reason for these failures (21).

In the electronics industry the empirical ‘Rule of 10s’ is generally accepted, which states that for every step in the product development process where an error goes undetected the cost ($C) increases by a factor of 10. Thus, a high priority

requirement related error which reaches the customer can cost as much as $1000*C when it would only have cost $C if it were discovered at the initial stages of the product development process (40).

Product Performance Issues: The majority of new products are considered to be failures once they reach the market (27). Where product failure is defined as a product failing to meet its company’s market expectations (18). Product failure and poor product performance can often be directly related to failure to classify and prioritize requirements early in the product development process (27, 51). Some potential consequences of failing to classify and prioritize product requirements early in the product development process are as follows:

(20)

generally attributed to correct identification of requirements to meet an existing demand. Consequently, requirement classification and prioritization may be considered as critical factor for successful product development.

Turner (54) found that two thirds of products identified as technical successes are commercial failures. This suggests that commercial failure may be due to improper requirement capture and failure to properly classify and prioritize requirements. Where poor requirement classification and prioritization leads to inadequate marketing and sales efforts that focus on requirements which are incorrectly perceived to be important to the customer.

Hollins and Pugh (27) point out that increased emphasis must be placed on up front analysis so that requirements that lead to eventual product failure can be screened out (prioritization) during the low cost end of the development process. Spending thousands during the conceptual design phase of the product development process is quite cost effective in contrast to spending millions developing a product that is a commercial failure (27).

1.4 RESEARCH OBJECTIVES & SCOPE

The primary objectives of this research effort are as follows:

(21)

Framing, Gathering Intelligence, Coming to Conclusions, and Learning From Feedback. SRAM utilizes the four essential elements of good decision-making to serve as the conceptual basis for integrating concepts and methods from the following diverse knowledge domains: Requirement Analysis, Market Orientation,

Organizational Learning, Multi-Criteria Decision-Making (MCDM), and Multi-Attribute Decision-Making. Specifically, SRAM defines candidate product requirements as possible alternatives of a MADM problem, where candidate requirements are evaluated using market orientation based (market priority, risk, customer value & performance) quantitative and qualitative (fuzzy) decision criteria. SRAM will be verified and validated through the successful classification and prioritization of candidate functional software requirements for a proposed large-scale knowledge-based engineering system. Classifying and prioritizing software requirements is quite significant given that: (1) large-scale software systems are often more difficult to develop than non-software products; (2) software cost is steadily escalating; and (3) software is becoming increasingly important to society (6, 16). The significance of classifying and prioritizing software requirements is further buttressed by the fact the proliferation of software has in some cases grown to the point that “hardware” is often only considered as a kind of packaging for software (6). In addition to the primary case study, SRAM will be utilized to prioritize strategic alternatives for a consulting group, thus demonstrating the flexibility of SRAM to be utilized for a variety of applications.

(22)

aggregate, and analyze input from diverse stakeholders in order to build group consensus and support product development decision making (35). Hence, represents a significant contribution to the existing body of knowledge (78).

(23)

1.5 BENEFITS OF RESEARCH

SRAM represents a potential solution to the current lack of structured, theoretically valid, and practical methods for classifying and prioritizing product requirements early in the product development process. Consequentially, the use of SRAM provides the following key benefits:

SRAM provides a means to gather, aggregate, and analyze stakeholder input. The eventual market success or failure of a new product depends on how well developers are able to gather, aggregate, and analyze input from diverse product stakeholders. SRAM provides developers with a means to build group consensus and resolve conflict. Likewise, both stakeholder communication and understanding is improved through the clear and concise representation of individual and aggregated stakeholder preferences.

SRAM supports both individual and group learning. In today’s continuously changing and often unpredictable business environment, it is learning, not knowledge that will determine an organization’s long-term success. Any specific knowledge or solution derived as a result of utilizing SRAM is transient and must be continually revised and updated. However, the process of both individual and group stakeholder learning actually increases in value during times of turbulence and unpredictability. To quote James Thurber; “In times of change learners shall inherit the earth, while the learned are beautifully equipped for a world that no longer exists.”

(24)

may be used to support continuous product and process improvement efforts.

Using SRAM can help reduce the overall time it takes to bring a new product to market. Minimizing time to market is a critical issue since every day the release of a new product is delayed represents a potential lost in overall product lifecycle profit (43, 51, 124, 142). SRAM tackles this critical issue by helping focus the product development process on satisfying high priority requirements and quickly eliminating low priority requirements from consideration.

Using SRAM can help reduce the product lifecycle cost of a new product. Time and resources wasted on satisfying low priority or essentially useless requirements represent an unnecessary and avoidable cost that can negatively effect a new product’s overall lifecycle cost (27, 51). Furthermore, failure to identify high priority requirements can result in costs that are a thousand times more expensive to repair once a product is operation than during the initial stages of the product development process (6, 27, 51, 40). Even more disturbing is the fact that failing to identify high priority requirements early in the development process can lead to the production of products which may result in the immeasurable cost of lost human lives (21). SRAM provides a potential solution to this serious problem by forcing product developers to identify high priority requirements long before a new product actually goes to market.

(25)

requirements positively, then customers will most likely not be enthusiastic about purchasing the final product once it actually reaches the market. Thus, SRAM also provides designers with a way to assess the potential market success of a new product before the formal commitment of organizational resources occurs.

1.6 ORGANIZATION OF THE DISSERTATION

This dissertation is divided into six chapters. Following this introductory chapter, Chapter 2 provides a review of relevant literature. This review includes material concerning (1) Requirement Analysis; (2) Market Orientation; (3) Existing Product Requirement Evaluation Approaches; (4) Organizational Learning; (5) Multi-Criteria Decision-Making (MCDM); and (6) Multiple Attribute Decision-Making (MADM).

Chapter 3 presents the proposed solution approach - SRAM. A detailed review will be provided in regard to the unique way that SRAM integrates concepts and methods related to requirement analysis, market orientation, organizational learning, MCDM, and MADM. Specifically, SRAM involves the integration of MADM methods such as the Technique for Order Preference by Similarity to the Ideal Solution (TOPSIS), the Analytical Hierarchy Process (AHP), entropy weighting, fuzzy linguistic evaluation, and borda scoring. SRAM will be presented in a structured step-wise manner that is congruent with the essential elements of good decision-making in order to facilitate both understanding and practical application.

(26)

In Chapter 5, both actual and potential SRAM users will objectively evaluate the approach in regard to effectiveness, practicality, learning, and validity related evaluation criteria. The primary objective of the evaluation process is to further validate SRAM as a practical and theoretically sound approach for classifying and prioritizing requirements. In addition, participants will be have the opportunity to learn more about the essential elements of SRAM which are integrated into the evaluation process.

(27)

CHAPTER 2 LITERATURE REVIEW

“(1) Out of clutter, find simplicity; (2) From discord, find harmony; and (3) In the middle of difficulty lies opportunity. ”

Albert Einstein, Three Rules of Work

2.1 INTRODUCTION

Successful new product development is the cornerstone of long-term organizational survival and prosperity. Without the continuous flow of innovative and most importantly market successful products, an organization can not survive, let alone achieve market dominance and competitive advantage. Furthermore, in today’s chaotic and increasingly competitive global marketplace, fixation on simply maintaining currently successful products can quickly obliterate any competitive advantage gained through previous years of market dominance. Thus, the continuous introduction of successful new products is increasingly considered as a fundamental business process as opposed to a unique source of competitive advantage.

New product development can be conceptually defined as a series of decisions that transform an initial concept into a marketable product. Requirement analysis is the stage of the product development process that involves translating vaguely defined stakeholder, needs, and desires into a complete, precise, and consistent set of requirements for formal specification. Two key decisions that must be made during the requirement analysis process are (1) the classification of requirements as mandatory or optional, and (2) the

(28)

In this chapter, the literature related to the classification and prioritization of product requirement is presented. First, an introduction is provided in section 2.1. Section 2.2 then provides a review of the requirement analysis process that emphasizes the importance requirement classification and prioritization for both traditional and software products. Afterwards, section 2.3 provides a review of the market orientation concept as a means to evaluate product requirements. Section 2.4 presents a critical review of QFD, Hill’s Order Winning and Order Qualifying Model, and Multivariate Data Analysis in regard to being alternative approaches for classifying and prioritizing requirements. In section 2.5, the topic of organizational learning is reviewed as it relates to use of structured decision-making to support both individual and group learning. Next, in section 2.6 Multi-Criteria Decision-Making (MCDM) is reviewed as a possible solution framework for addressing early requirement classification and prioritization. In section 2.7, Multiple Attribute Decision-Making (MADM) methods are reviewed as a specific solution framework addressing the defined research problem. Finally, in section 2.8 the summary will be presented.

2.2. REQUIREMENT ANALYSIS

2.21 Defining Requirements

Before discussing the details of requirement analysis process, and more specifically the early classification and prioritization of product requirements, it is important that the concept of product requirements is first defined. IEEE Standard 610 (1994) defines a requirement as (35):

1. A condition or capacity needed by a user and/or customer to solve a problem or

achieve an objective.

2. A condition or capacity that must be met or possessed by a system or system

component to satisfy a contract, standard, specification, or other formally imposed

document.

(29)

Requirements are a statement of what stakeholders expect a product will do without explicitly referring to how it will do it (21, 52). Stakeholders are defined as any group, individual, or organization that is affected by, or can effect a product. Customers are stakeholders who purchase a product, while users are any stakeholders who will use a product in some capacity (13). Requirements represent what customers expected to receive, as a result of using a product as opposed to product attributes, which define how specific requirements, will be satisfied. Customers expect requirements whereas products possess attributes (132, 135). A new product’s success is directly determined by: (1) how well identified product requirements define the actual needs and expectations of potential customers and users, and (2) the extent to which these needs and expectations are actually satisfied. Thus, requirements and the requirement analysis process can be viewed as the bricks and subsequent foundation upon which successful products are built (1, 12, 13, 15, 21, 43, 46).

2.22 Defining Requirement Analysis

(30)

requirements for implementation. Requirements are first classified as mandatory or optional, next prioritized in terms of overall importance, and then selected for inclusion in the final product (1, 3, 21, 35, 52). Hence, although selection is the visible blossom of the requirement analysis process, classification and prioritization are the seeds from which successful new products are grown.

2.23 Importance of Early Requirement Classification and Prioritization

The decision to select specific requirements for inclusion in a product may be explicitly assessed once a new product has reached the market. Either a requirement does or it does not satisfy distinct stakeholder needs and desires. On the other hand, classification and prioritization decisions are transparent to customers and users because all they receive is the final product gestalt as opposed to the individual classified and prioritized pieces of the new product development puzzle. Requirement selection involves the relatively straightforward process of choosing requirements that have been identified as having the highest level of importance within the bounds of identified resource and technical constraints. In contrast, requirement classification and prioritization decisions are ill-structured without an optimal solution, only satisficing solutions exist. Furthermore, since classification and prioritization decisions should occur early in the product development process it is difficult to directly measure the effect these decisions have in regard to market success or failure. Consequently, requirement classification and prioritization is usually only briefly mentioned in the literature as being a critical component of the product development process (1, 4, 7,12, 13, 21, 23, 27, 33, 34, 35, 43).

(31)

• Early agreement amongst developers, customers, users, and other key stakeholders on the job to be done and the acceptance criteria for the delivered product (reducingtime to market and increasingproduct performance).

• A sound basis for resource estimation and allocation (reducing product cost).

• Improved product performance in key quality dimensions such as usability, reliability, serviceability, and/or conformance (increasingproduct performance).

• Achievement of product development objectives with minimum resources (reducing product cost).

A significant benefit of associated with the classification and prioritization of product requirements is the elimination of low priority requirements early in the product development process. Requirement classification and prioritization creates the opportunity to eliminate low priority requirements and focus development efforts on satisfying requirements customer perceive to be vital (27, 52). Thus, requirement classification and prioritization increases the overall likelihood for successful new product development. In addition, classification and prioritization allows potential problem areas to be identified during the low cost front end of the product development process before organizational resources are fully committed.

2.24 Defining Software Requirements

(32)

throughout its lifecycle (7, 12, 13, 22, 32). Requirements engineering is the specialized branch of software engineering focused entirely on the management of software requirements.

There are certain characteristics that are unique to the domain of software engineering (3, 6, 7, 12, 13, 14, 22, 25, 32, 35, 46, 48). Software requirements may be classified using two distinct categories (12, 13, 32, 35):

Functional Requirements – Functional requirements describe what functions a software system must carry out without specifying how the system will accomplish these functions. Hence, functional requirements should present a clear explanation of the desired service that a proposed software system will provide.

Non-Functional Requirements – Non-Functional requirements describe all requirements that can not be categorized as functional requirements. There are two sub-categories of non-functional requirements:

Quality - Quality requirements define specific performance expectations that customers and users have for identified functional requirements. Thus, quality requirements provide the context for determining how well functional requirements satisfy the needs and desires of targeted customers and users.

Constraints – Constraints are the rules, relations, and conventions that determine the boundaries and limitations that all other requirements must be realized within. Thus, constraints confine both the software development process and human imagination to the limited realm of feasible solutions.

Just as with traditional product requirements, the development of software requirements involves the requirement capture, requirement analysis, and requirement specification

(33)

Table 2: Software Quality Requirement Taxonomy Primary Characteristic Secondary Characteristic Description

Operation • Suitability

• Operability

• Performance

Software meets the particular needs of the user

Software is easy to learn

Computer has enough processing capability Functionality • Reliability

• Availability

• Security

Operates without faults

Recovers quickly from faults - minimum downtime

Denying access to unauthorized users

Convenience • Maintainability

• Compatibility

• Expandability

Defects easy to identify and repair

Can be used on existing platform without changes

Functions can easily be changed or expanded

Versatility • Portability

• Modifiability

• Connectivity

Can easily run on other machines and operating systems

Can easily be reconfigured to other systems

Can be easily reconfigured for other systems

Productivity • Speed

• Capacity

• Efficiency

• Resource

Utilization

Rapid response to input

Can process high volume of data simultaneously

Conserves system resources

Gets the most out of system resources

User-Friendliness

• Learnability

• Interactivity

• Comprehensibility

Easy to understand

Interacts with user to resolve problems/answer questions

Operating concepts easy to learn

2.25 Software Lifecycle Models

(34)

Table 3: Software Lifecycle Activities

Software Lifecycle Activity Purpose Deliverable

User Requirements Problem Definition User Requirements

Software Requirements Problem Analysis Software and Support Service

Requirements

Architectural Design High-Level Solution High-Level Software Design &

Support Service Design

Production Implementation Detailed Design

Testing of Software

Establish Software Support Service

Transfer Delivery

Installation

Installed Software

Maintenance Software Operations

Software Support

Maintained and Supported Software

There are three main software lifecycle models (11, 12, 13, 31, 32, 35); (1) the waterfall model, (2) the incremental model, and (3) the evolutionary model. In addition, there are two main derivations of the evolutionary model; (1) the spiral model and (2) the

prototype model. The waterfall model is the software lifecycle model upon which all the other lifecycle models are based. This model is based on a “single shot” step-wise approach to software development, starting with user requirements and ending with maintenance. The waterfall model takes a static viewpoint of requirement analysis by ignoring the dynamic and volatile nature of requirements and the impact that requirements have throughout the development process. Although feedback is possible, the focus of this model is the minimization of feedback between phases and thus a minimization of overall development time. Criticisms of the waterfall model include (11, 35):

• Lack of user involvement after the requirement specification phase.

• Inflexibility to accommodate prototypes.

• Unrealistic separation of specification from design.

• Inability to accommodate reused software.

• Maintainability problems.

• Complicated systems integration.

(35)

(11, 35). This models exactly follows the waterfall model until the completion of architectural design, and then the focus shifts to implementing the software system in incremental pieces rather than in a single pass. The main benefit of this approach is that it provides early feedback to the developer and helps shorten the time between requirement definition and implementation. Shortcomings of this approach include:

• Demands detailed organization.

• Selection of incremental pieces may place added constraints on the software design.

• It is not always possible to deliver parts that are useful without the entire system.

• If increments are too small the cost of the project will increase.

The evolutionary model differs from the incremental model in that all six phases of the software lifecycle are repeated (11). This model is extremely useful in cases where requirements are poorly understood or very unstable. The evolution model gives users early operational capability, thus helping ensure users will be satisfied with the complete software system. The major drawback of this approach is that detailed planning is necessary to ensure that each evolution can accommodate any requirement changes and long-ranging usage considerations. Furthermore, careful considerations must be made in order to avoid developing evolving code that is difficult to change (11).

The spiral model is a variation of the evolutionary model that incorporates detailed planning as well as risk analysis and management (35). Each cycle of the model begins with the identification of; (1) objectives for the portion of the system being developed, (2) alternative means of implementation, and (3) the constraints imposed on the alternative means of implementation. Alternatives are then evaluated relative to the stated objectives. Afterwards, project risks are then identified and evaluated which in turn determines the subsequent steps of the model that will be executed.

(36)

understanding of customer needs, developers determine the objectives and scope of the prototype. Thus, a prototype is utilized as a type of requirement specification. This method is often criticized because it can hamper later stages of the development cycle when users incorrectly assume a prototype is the final system solution (12, 13, 35).

2.26 Importance of Early Software Requirement Classification and Prioritization Although software products are becoming increasingly important in all aspects of society, software engineering is a relatively new and evolving knowledge domain with very few established methods and techniques (12, 13, 32, 35). Many of the well-established practices and approaches for ensuring successful traditional product development have yet to be modified for the challenging software development environment. This problem is compounded by the fact software systems are often more complex, and thus more sensitive to the overall quality of their requirements than traditional products (16). Hence, levels of failure that would be completely unacceptable in traditional product development projects are everyday realities of large-scale software development. For instance, in a recent survey many large scale software systems had to have up to 95% of their code changed due to requirement errors and over two-thirds of all requirement errors where detected after product release (3).

Poor software development is a serious problem that can often be linked directly to faulty requirements engineering. In fact, poor requirements engineering is often the principle source of project cost and schedule overruns as well as being a direct cause of overall project failure (3, 6, 7, 8, 11, 12, 13, 21, 32, 35, 51, 52). Improperly classifying and prioritizing requirements is an especially serious software development problem that is frequently mentioned in the literature, but rarely addressed beyond anecdotal advice and vague presentations of adhoc approaches (6, 14, 22, 25, 32, 39, 25, 49, 51). Some dramatic examples of the devastating effect that poor requirement classification and prioritization can have on a software system are as follows (6, 32, 50, 52):

• 31% of all software projects are cancelled (Estimated 81 billion US-$/yr.).

(37)

• 9% of all software systems developed by large companies will be delivered on time.

• 16% of all software systems developed by small companies will be delivered on time.

• 55% of all software errors are requirement related.

• 48% of software errors can be attributed to incorrect or misinterpreted requirements.

As with traditional product development, the importance of proper requirement classification and prioritization early in the software development process can not be overestimated. In some ways classifying and prioritizing requirements is even more important for successful software development because of the higher level of criticality and complexity that often exists for large-scale software systems in comparison to non-software products (6, 16). Consequently, significant classification and prioritization benefits such as reducing time to market, reducing cost, increasing performance, and identifying critical development issues are all mandatory for long-term survival and prosperity in today’s competitive software markets.

2.3 MARKET ORIENTATION

2.31 Defining Market Orientation

Market orientation is a concept based on the fundamental belief that creating satisfied customers is the only valid definition of business purpose (126, 142). Organizations that adopt the market orientation concept focus on being able to anticipate and quickly respond to rapidly changing market conditions in order to gain superior competitive advantage and profitability. From this perspective market orientation may be viewed as a type of organizational culture that creates the necessary behaviors for the creation of superior customer value, which in turn results in superior organizational performance (142). Although there has been some controversy surrounding the expected benefits of market orientation, research has repeatedly shown that market orientation is positively associated with superior organizational performance and profitability (120, 122, 126, 130, 134, 145). Some key market orientation principles are as follows (126):

(38)

The ability to generate, disseminate, and utilize superior information about customers and competitors.

The coordinated application of cross-functional resources for the creation of superior customer value.

In regards to product development, market orientation is considered by many sources to be critical for the successful creation of new products (27, 126, 132, 142). Market orientation can be integrated into an organization’s product development process by adopting one of three distinct development strategies (126):

Operational Excellence - The primary objectives of this approach are: (1) Focusing on price and convenience leadership; (2) Developing business processes that minimize overhead and internal transaction costs; and (3) Maintaining close links to customers and channel partners.

Customer Intimacy - The primary objectives of this approach are: (1) Tailoring products to fit customer needs; (2) Understanding how products create customer value; (3) Quickly identifying shifts in customer preferences; and (4) Developing long-term customer loyalty.

Product Leadership - The primary objectives of this approach are: (1) Providing a continuous stream of innovative products and services; (2) Quickly recognizing emerging customer needs; (3) Rapidly entering new markets; and (4) Emphasizing creativity.

(39)

categories. These categories are as follows (85, 126, 142):

Customer Orientation – Customer orientation involves developing an in-depth understanding of targeted customers’ needs and desires in order to develop products that create superior customer value. This in-depth understanding involves understanding both the immediate preferences and long-term strategic objectives of key customers.

Competitor Orientation – Competitor orientation involves identifying key market issues and competitor characteristics for the distinct purpose of gaining long-term competitive advantage. Hence, in order for the creation of superior customer value (customer orientation) to have practical meaning, customer needs and desires must be understood within the context of market realities and competitive pressures.

Interfunctional (Internal) Orientation – Interfunctional orientation involves understanding critical internal organizational issues that must be addressed as a necessary prerequisite for providing superior customer value (customer orientation)

and achieving sustainable competitive advantage (competitor orientation).

Viewed both individually as well as a unified whole, these three orientations (customer,

(40)

orientation), and (4) risk analysis (interfunctional orientation).

2.32 Customer Value Analysis

A value is an enduring belief that a specific end-state of existence is preferable to an alternative end-state of existence (135, 137). The value of an object is not inherent in the object itself. To the contrary, an object’s value stems from the ability to help an individual achieve desired ends or goals. Thus, values are special types of relativistic

(personal, comparative, situational) preferences for desired ends or goals that help characterize a subject’s experience of interacting with an object (137). This definition of value raises five key points that require further elaboration (137). First, value is neither wholly subjective nor objective but instead involves a subject-object interaction. Second, value pertains to the experience of using or appreciating an object. Third, value is

personal in that the value of an object differs based on individual preference. Fourth, value is comparative in that the value of an object depends on it being rated or ranked against another object. Fifth, value is situational in that the value of an object hinges on the context within which an individual evaluates it.

In regard to customer value, the subject of interest is a customer and the relevant object is a product. Value is created when customers use (consume) a product within a particular situation. The consumption of products produces both desirable (benefits) and undesirable (costs or sacrifices) consequences. A consequence is any outcome experienced directly or indirectly by a customer. Hence, customer value may be defined as customers’ perceptions of the consequences they want to have happen as a result of using a product, in a specific situation (135, 137, 131, 138, 145). There are three main elements of this definition (132):

• Customers select products as a means of facilitating the achievement of desired ends

(values) or goals.

• Products create value through the delivery of consequences (requirements) rather than through their inherent characteristics (attributes)

(41)

Products serve as a means by which customers achieve desired ends. Accordingly,

means-ends theory provides a hierarchical structure for representing why customers select certain products and services (135). At the lowest level of the means-ends hierarchy, customers define a product or service in terms of its attributes (product attributes). At the middle level of the hierarchy are customers’ perceptions of both the desirable (product requirements) and undesirable consequences (product costs) of consuming a product. Consequences differ from attributes in that customers receive consequences whereas products possess attributes. The ability of customers to attain their desired purposes or goals is determined by the consequences of using a product (135, 137). At the highest level of the customer value hierarchy are customers’ desired end states, core values, purposes, or goals. Desired ends give consequences importance, to the extent that consequences leading to important values are more important to customers than those leading to less important values (135).

(42)

2.33 Balanced Scorecard Performance Measurement

An inherent limitation on the use of customer value as an evaluation measure to support classifying and prioritizing requirements is the fact that there is no standard framework for defining the benefits provided by product requirements. This problem is especially obvious in the case of industrial product development where the benefits provided by individual requirements must be defined in a manner such that the needs and desires of diverse corporate customers are practically and comprehensively represented. A potential solution to this problem can be found by using the concept of organizational performance measures to define the benefits that an organization desires. Performance measures define the desired consequences that an organization wants to achieve in order to both survive and prosper. Thus, the concept of performance measurement is excellently aligned with the concept of customer value creation (146, 148, 153). However, once the decision has been made to utilize performance metrics as a basis for defining requirement benefits, then a robust performance measurement framework must be identified that comprehensively describes a variety of possible benefits.

The balanced scorecard is a proven performance measurement framework that can be used to comprehensively define organizational benefits from four key perspectives: (1)

financial, (2) customer, (3) process, and (4) learning (146, 148, 149, 150, 151, 152, 153, 154). These four perspectives both rationally and intuitively define the realm of possible benefits that an organization can seek to obtain. Furthermore, the fact that the balanced scorecard makes both rational and intuitive sense is buttressed by significant empirical evidence that indicates its use is positively associated with organizational success (149, 150, 151, 152, 154). Taken as a unified whole, the four perspectives of the balanced scorecard provide product developers with a robust template for assessing the benefits that organizations desire to receive as a consequence of utilizing a proposed product. A brief summary of each of the four perspectives of the balanced scorecard is as follows (152):

(43)

used to evaluate the potential financial benefits provided by a requirement (Does a requirement contribute to an organization’s financial bottom-line?).

Customer Perspective – This perspective is utilized to assess how well an

organization is satisfying the needs of its key customers. Consequently, the customer perspective can be used to evaluate the potential customer benefits provided by a requirement (Does a requirement create benefits for an organization’s external customers?).

Internal / Business Process Perspective – This perspective is utilized to assess the overall status of an organization’s key internal processes. Consequently, the internal perspective can be used to evaluate the potential process improvement benefits provided by a requirement (Does a requirement help improve an organization’s processes?).

Learning and Growth Perspective – This perspective is utilized to assess how well an organization is doing in regard to promoting learning and employee development. Consequently, the learning perspective can be used to evaluate potential

(44)

2.34 Performance Objectives

An objective is something to be pursued to the fullest (81). From a market orientation perspective, industrial product requirements must be understood in the larger context of relevant performance objectives that corporate customers are seeking to achieve by purchasing a proposed product (126, 128, 142). Thus, an integral aspect of the industrial product requirement classification and prioritization process should be evaluating candidate requirements in relation to the performance objectives corporate customers desire to achieve. A comprehensive review of the strategic planning literature indicates that a framework for evaluating industrial product requirements can be derived using the concept of manufacturing strategy (172, 173, 177, 179, 180, 185, 187, 188, 191).

Strategic planning, from a high-level business perspective may be defined as a dynamic decision-making framework for developing and deploying policies, performance measures, and values aligned with an organization’s vision, mission, and long-term objectives (175, 176, 182, 183, 189, 190, 192). However, from a manufacturing strategy viewpoint, strategy can be defined specifically as the strategic positioning of an organization’s operational capabilities and resources for the purpose of gaining competitive advantage (172, 173, 177, 180, 185, 187, 188, 191). The core element of manufacturing strategy is a statement of the operational objectives that an organization must accomplish in order to achieve both competitive advantage and long-term organizational success. This statement, referred to as the manufacturing task, is defined in terms of the unique capabilities a firm must have in order to compete and prosper (191). Within this conceptual framework, the possible performance objectives of perspective customers can be categorized using four comprehensive dimensions (172, 173, 177, 178, 180, 181, 186, 187, 188, 191):

• Cost/Efficiency Objectives – Objectives that focus on minimizing total cost and maximizing overall profitability.

• Quality Objectives – Objectives that focus on maximizing organizational quality.

(45)

• Delivery Objectives – Objectives that focus on an organization’s ability to minimize delivery speed and/or maximize delivery reliability.

The four dimensions of cost, quality, flexibility, and delivery comprehensively define the potential performance objectives desired by industrial customers. Each dimension places limits on what an organization can do, forces compromises, and demands an explicit recognition of the potential tradeoffs and choices that are necessary to achieve primary performance objectives for a proposed product (180, 184, 187, 191). Consequently, these dimensions also provide a means to classify and prioritize requirements in regard to the specific performance objectives of a proposed product offering.

2.35 Risk Analysis

Risk can be generically defined as the possibility of loss or injury (160). This loss can be either a potential loss or an opportunity loss (162). A potential loss occurs when a resulting outcome is worse off than the status quo or some outcome is produced that is not as desirable as another possible outcome. An opportunity loss occurs whenever a resource is sacrificed to achieve a specific objective and this resource can not be used to achieve an alternative objective. However, from a decision theory perspective, risk may be more specifically defined as having the following characteristics (160, 163, 164):

• A property of alternatives that has a direct effect upon the decision maker’s choices amongst the alternatives.

• A possibility of loss as a result of selecting an alternative.

• A measurable property such that a set of alternatives can be meaningfully ordered.

• A function of certain measurable properties of an alternative.

• A multidimensional construct that depends on individual perspective.

(46)

minimized, not eliminated. Likewise, product developers can not control risk, they can only control their response to risk. Risk analysis is the process of identifying potential problem areas, quantifying the risks associated with these problem areas, assessing the effects of these risks, and generating alternative courses of action to reduce identified risks (162). In regard to product requirements, risk analysis involves identifying requirements that are likely to cause either product development difficulties or eventual product failure (48, 165).

The longer risk is ignored, unnoticed, or unmanaged during the product development process, the greater the chance for overall product failure (162). However, conducting risk analysis during the product development process is often difficult. This difficulty is compounded by the fact that there is no universally accepted approach that is applicable for every situation (160, 162, 163, 164, 165, 167, 168). Hence, risk analysis will not guarantee that the product development process will be successful. Nevertheless, risk analysis does go a long way towards avoiding product development failure. Some potential benefits of making risk analysis an integral part of the product development process are as follows (156, 157, 158, 160, 162, 170):

• Reduced product development risk.

• A common definition and perception of risk amongst product stakeholders.

• Increased stakeholder confidence in the product development process.

• Provides a basis for contingency planning.

• Identification of key improvement opportunities.

• Compatibility of decisions throughout the product development process.

• Creation of stakeholder, insight, knowledge, and learning.

(47)

identifying and resolving high-risk issues (160). Some common types of requirement related software development risks are as follows (48, 160):

• Performance Risk –The possibility that implementing a requirement may adversely affect the overall performance of a proposed system.

• Safety & Security Risk – The possibility that implementing a requirement may cause problems in meeting overall system requirements for safety and security.

• Process Risk – The possibility that implementing a requirement may require the use of unfamiliar implementation technology.

• Database Risk – The possibility that implementing a requirement may require the use of non-standard data that is not available in an existing database.

• Schedule Risk – The possibility that implementing a requirement may threaten the planned development schedule.

• External Risk – The possibility that implementing a requirement may involve external contractors.

• Stability Risks – The possibility that a requirement may be volatile or subject to evolution throughout the development process.

Given the critical importance of identifying requirement risk early in the product development process, risk analysis should be an integral part of classifying and prioritizing product requirements. In addition, from a market orientation perspective, evaluating requirement risk provides product developers with an excellent way to assess an organization’s ability (interfunctional orientation) to create superior customer value (customer orientation) and sustained competitive advantage(competitive orientation).

2.4 REVIEW OF EXISTING METHODS FOR EVALUATING PRODUCT REQUIREMENTS

2.41 Quality Function Deployment (QFD)