requirements engineering VIRE

feature

requirements engineering

VIRE: Sailing a Blue Ocean with ValueInnovative Requirements Sangsoo Kim and Hoh Peter In, Korea University Jongmoon Baik, Information and Communications University Rick Kazman, University of Hawaii Kwangsin Han, K amco

Value-Innovative Requirements Engineering guides software development organizations in creating new markets based on new product values for potential customers.

M

ost requirements-engineering techniques and practices focus on eliciting requirements from existing, known customers.1 However, these techniques and practices aren’t sufficient for surviving in current highly competitive markets. In particular, small organizations typically lack sufficient resources to compete ef-

fectively with large companies.2 W. Chan Kim and Renée Mauborgne proposed the blue-ocean strategy to create new marketplace value and so make competition irrelevant.3,4 A “blue ocean” is a potential market where competition doesn’t yet exist. In contrast, a “red ocean” is a bloody market where companies compete intensely for a share of a limited market space. How can you elicit software product requirements for creating new customer value and new markets instead of refining requirements of existing products? The blue-ocean strategy provides an opportunity for small organizations by creating new market spaces without competition. However, it doesn’t provide a specific process for developing a new product. Value-Innovative Requirements Engineering is a novel requirements-engineering process that we developed to adapt the blue-ocean strategy for software organizations. The VIRE process helps investigate the potential desires and needs of existing customers as well noncustomers to create uncontested new market spaces. (See the “Related Work in ValueAdded Engineering” sidebar for other approaches.)

Blue-ocean-strategy framework The blue-ocean-strategy framework consists of 80

IEEE Soft ware

Published by the IEEE Computer Society

a strategy canvas and four practical actions to systematically innovate value.3,4 The strategy canvas is an analysis tool that reveals the current state of participants in a well-known market. It also shows what customers gain from rival products in that market. The so-called ERRC practical actions reconstruct customer value perception by answering four questions from which the acronym derives: ■ Which of the factors that the industry takes for

granted should be eliminated? ■ Which factors should be reduced well below

the industry’s standard? ■ Which factors should be raised well above the

industry’s standard? ■ Which factors should be created that the indus-

try has never offered? The blue-ocean-strategy framework also includes six principles. The first four formulate the strategy and last two execute it: 0 74 0 -74 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E

Related Work in Value-Added Engineering W. Chan Kim and Renée Mauborgne have published several methods for formulating and executing a blue-ocean strategy.1,2 But a blue ocean is just a strategy: it provides the big picture but no specific processes, analysis procedures, and design methods. In particular, it lacks a method for transforming value-added customer requirements into real systems. Several other techniques deal with this problem. Quality Function Deployment is a systemic method for tying design decisions directly to customer needs. Murat Erder and Pierre Pureur outline an approach to designing architectures that fully support QFD requirements.3 Triz is an analysis method for formulating innovative ideas and systems.4 Joseph W.K. Chan and K.M. Yu applied it in a systemic approach for developing successful information systems.5 Generally, cost-benefit analysis methods can handle cost and system quality trade-off problems.6 Ho-Won Jung provides an optimizing method that can lead to highest system quality against a given cost.7 Rick Kazman, Hoh In, and Hong-Mei Chen proposed methods to resolve conflicts among customer quality requirements,8 and Barry Boehm and Li Guo Huang have proposed a broad program of value-based software engineering.9 Several of these tools and methods provide partial solutions but lack a holistic approach ranging from the reliable

■ ■ ■ ■ ■ ■

Reconstruct market boundaries. Focus on the big picture, not on the numbers. Reach beyond existing demand. Get the strategic sequence right. Overcome key organizational hurdles. Build execution into strategy.

VIRE embodies this framework and its principles in software engineering requirements to assist in creating a new market, eliminating competition, and satisfying customers.

Value-innovative requirements VIRE offers an integrated requirements-elicitation process to identify, analyze, and validate new customer values for creating a potential market. Its usefulness applies to ■ developing a new product for creating a blue-

ocean market, ■ redefining existing requirements and eliciting a

new market space, and ■ combining more than two existing require-

ments to increase customer value. Figure 1 shows the proposed VIRE opera

elicitation of value-innovative requirements to their realization in real systems. The ERRC decision matrix we adapted for the Value-Innovative Requirements Engineering process isn’t a ground-breaking tool. Rather, it provides a novel integration of best practices such as cost-benefit analysis and the win-win spiral approach for creating a blue-ocean market of valueadded systems. References 1. W.C. Kim and R. Mauborgne, Blue Ocean Strategy, Harvard Business School Press, 2005. 2. W.C. Kim and R. Mauborgne, “Value Innovation—The Strategic Logic of High Growth,” Harvard Business Rev., July-Aug. 2004, pp. 172–180. 3. M. Erder and P. Pureur, “QFD in the Architecture Development Process,” IEEE IT Pro, Nov./Dec. 2003, pp. 44–52. 4. K. Yang and B.S. El-Haik, Design for Six Sigma, McGraw-Hill, 2003. 5. W.K. Chan and K.M. Yu, “TRIZ-Aided Technology Mapping for Information System Implementation,” Proc. 2004 IEEE Int’l Eng. Management Conf., IEEE Press, 2004, pp. 239–243. 6. M. Moore et al., “Quantifying the Value of Architecture Design Decisions: Lessons from the Field,” Proc. 25th Int’l Conf. Software Eng. (ICSE 03), IEEE CS Press, 2003, pp. 557–562. 7. H.W. Jung, “Optimizing Value and Cost in Requirements,” IEEE Software, July/Aug. 1998, pp. 67–74. 8. R. Kazman, H. In, and H. Chen, “From Requirements Negotiation to Software Architecture Decisions,” Information and Software Technology, Dec. 2004, pp. 511–520. 9. B. Boehm and L.G. Huang, “Value-Based Software Engineering: A Case Study,” Computer, Mar. 2003, pp. 33–41.

tions concept. It begins with analyzing existing system requirements using the strategy canvas and building value-innovative requirements based on collecting stakeholders’ feedback, identifying customer values and their conflicts, and analyzing existing systems and market situations. The strategy canvas is a tool for examining the current value proposition and creating new customer values. The ERRC analysis provides guidelines on which components to eliminate, reduce, raise, and create in achieving the ultimate goal of value maximization. VIRE also includes a quantitative, axiomatic validation method to check the degree of coupling among the redefined components.

VIRE process overview VIRE consists of five steps adapted from the win-win spiral model.5 All steps must iterate at least three times. The first iteration redefines requirements, the second iteration focuses on building a prototype, and the third on product development. Each step has inputs, outputs, constraints, and enablers. Some outputs from the previous step become inputs to the next step. In addition, each step can feed back to the previous step. The proJanuary/February 2008 I E E E S o f t w a r e

81

Typical software development process Requirement 1

Requirement 2

...

Value-Innovative Requirements Engineering VIRE strategy

R′n Existing system analysis with strategy canvas

System 1

...

System 2

Stakeholder feedback

Value identification

Strategy canvas

ERRC analysis

S′n Value-innovative requirements

Existing system

Value-innovative system

Red ocean

Blue ocean

Customer importance degree (CIi) Extremely important Very important Important Little importance Not important

SEs (How)

SE1

SE2

SE3

SEj

SEn

5 4 3 2 1

CI

CR1 Customer requirements (What)

CR2

Customer importance

Correlations

CR3 CRi

Rij

CIi

CRn ERRC decisions Eliminate × Reduce

–

Raise

+

Create

o

BI

BIj

RC

RCj

ERRC decisions

ED

BI Business importance CI Customer importance

EDj CR Customer requirement RC Relative cost

Correlation degree (Rij) Strong

�

9

Moderate

� •

3

Weak

�

1

SE System element

Figure 2. The ERRC decision matrix. Five matrix components harmonize new customer values with innovative product requirements: customer requirements (CR), system elements (SE), the importance customers place on a requirement (CI), the correlations between CRs and SEs (R), and ERRC decisions (ED).

82

IEEE Soft ware

Figure 1. VIRE operations concept. The strategy canvas helps examine the existing value proposition. The ERRC analysis helps determine which components to eliminate, r educe, r aise, and c reate for value innovation.

perception survey of existing systems. It uses the strategy canvas as a diagnostic tool and action framework for building a compelling blue-ocean strategy. The strategy canvas serves two purposes: it captures the known market space’s current state, and it identifies what customers receive from the existing competitive offerings. VIRE captures the strategy canvas in a graphical form, in which the horizontal axis captures the factors the industry competes on and invests in and the vertical axis captures the offering level that buyers receive across all these key competing factors. We present an example later with our case study. Step 2: Identifying new values. To identify new value

factors ignored in the past, step 2 elicits customer needs through an extended customer survey. The survey includes noncustomers who might use the product if its value proposition changed. Newly identified value factors are added to the strategy canvas developed in step 1. Step 3: Analyzing ERRC. For resolving value conflicts

cess finally outputs novel requirements for developing value-added products.

among customers and prioritizing values within the available development resources, the ERRC analysis helps stakeholders eliminate, reduce, raise, and create values based on customer requirements and importance, system elements, and their mapping relationships. An ERRC decision matrix provides systematic support for this analysis.

Step 1: Defining goals. The first step analyzes proj-

Step 4: Redefining requirements. This step redefines

ect goals, system boundaries, and system-value propositions. The analysis is based on a customer-

requirements for a value-innovative product on the basis of the newly identified and resolved values

w w w. c o m p u t e r. o rg /s o f t w a re

from steps 1, 2, and 3. The result is a new strategy canvas.

15

Step 5: Validating requirements. By comparing the old

20 Relative cost (RC)

and new strategy canvases, stakeholders can intuitively understand the value-proposition changes and validate the redefined requirements. However, VIRE employs an axiomatic approach to validate the requirements in a more formal way.

Reduce or raise SE1

30

SE4 20

40

50 Reduce

35 40

Steps 1 and 2 identify new customer values, but the values aren’t yet harmonized to define valueinnovative products. In step 3, the ERRC decision matrix that we developed for VIRE helps fine-tune customer values. Figure 2 shows the matrix’s five components:

45

SE8 SE9

SE3

Eliminate

50

SE10 60

SE5

■ System elements (SEj) realize customer

BI j = (CI1 × R 1, j ) + (CI 2 × R 2, j )

requirements.

tomer requirements identified in step 2. ■ Correlations (Rij) reflect intersections between customer requirements and system elements. ■ ERRC decisions (EDj) reflects business importance (BIj) and relative cost (RCj) of system elements as well as suggested ERRC actions to eliminate, reduce, raise, or create their values. We apply the ERRC decision matrix in three steps. Step 3.1: Prioritize customer values. We investigate

CRs, SEs, and CIs and enter the result in the ERRC decision matrix. As figure 2 shows, we rate CI on a scale from 1 (not important) to 5 (extremely important). Sorting CI yields an initial prioritization of customer values, but VIRE also considers resources such as development costs and available system elements, which temper the initial CI sort. Step 3.2: Map requirements to system elements. We val-

idate the prioritization in step 3.1 by mapping CRs to SEs and thereby derive their correlations, R. We use R to determine the business importance (BI) for each SE—that is, whether it eliminates, reduces, raises, or creates value. We assess R using the 9-31 relation-matrix strength rating, where 9 reflects a strong correlation, 3 reflects a moderate correlation, and 1 is a weak correlation.6 Step 3.3: Determine customer values. The ERRC ma-

trix suggests ERRC actions by calculating BI and

SE11

80 SE12

Business importance (BI)

■ Customer requirements (CRi) satisfy customer

■ Customer importance (CIi) prioritizes the cus-

70

SE2

relative costs (RC), according to the following equations:

needs as defined in step 1.

SE6 SE7

Raise

25

ERRC analysis

Create

10

+ ... + (CI i × R i, j ) =

n

∑ (CI i × R ij )

i, j =1

   Cost of SE  j  RC j =  × 100 n   Cost of SE ∑ j    j =1

Figure 3. Hybrid approach for selecting ERRC actions. Squares denote system elements that should remain the same; stars, SEs that should be eliminated; circles, SEs that should be created; and triangles, SEs that should be raised or reduced in importance.

No perfect algorithm exists for selecting the ERRC actions to apply for all projects. We initially considered both a return-on-investment approach and a win-win approach, but finally opted for a hybrid. The ROI approach, first sorts SEj by the ROIj value, where ROIj = BIj / RCj). Then the stakeholders decide on a threshold value for including or excluding SEj in a set of new requirements—for example, if ROIj is less than or equal to the threshold value, SEj is excluded. If a newly suggested SEk is greater than the threshold, SEk is added to the requirements; otherwise, it’s eliminated. Stakeholder discussions can increase or decrease the ROI for some important SEs. In the win-win approach, stakeholders negotiate which SEs to include or exclude on the basis of each SE’s value proposition. The win-win spiral approach includes a framework to support these group negotiations.5,7 Figure 3 illustrates the VIRE hybrid approach. First, we identify the state of SEs according to the ROI analysis. Then, from the analysis results, January/February 2008 I E E E S o f t w a r e

83

A triangular matrix design is called a decoupled design, as shown in equation 2.

High Existing systems New systems

 CR 1    CR 2  =  CR   3

Mean

Pr oc Se e Me ssi curi n ty ha mo g rd ry spe w Ha are effi ed c rd w and ien so cy So are ftw com ftw a ar e c pati re om bil pa ity tib il Ma Acc ity int ura ain cy ab i Fu Us lity a nc b tio i na lity l Sa Fa lev tis T e mi e l f ac F c l tio itne hnic iarit ss nf al y fo o le Fu r req r bu vel nc s u i i n tio r na ed f ess l le un c Ad vel tion di o Ele ng a f too Lin ctro fun ls ct ni kin g w c sa ion nc ith co tion ntr ac tor Co

st

for

 CR 1    CR 2  =  CR   3

we use the win-win approach to consider stakeholders’ values and decide on the ERRC actions. In figure 3, the ERRC actions determine the areas marked “Eliminate,” “Reduce or raise,” and “Create.”

Axiomatic requirements validation The VIRE process uses an axiomatic method to validate product design. The method maps what customers require to how to achieve it in a system domain (see figure 2). A set of CRs in the customer domain is mapped onto the system domain using a suitable set of SEs. The mapping process must satisfy design axioms,6,8–9 including the independence axiom: maintain independence in functional requirements. After defining the functional requirements and SEs, the system developers use an equation such as the following to define a map between the customer and system domains:

where [R] is a correlation matrix. To satisfy the independence axiom, [R] must be either a diagonal or a triangular matrix.6,8 A diagonal-matrix design is called uncoupled design, as presented in equation 1:

 R 11 0 0   SE1       0 R 22 0  × SE 2   0 0 R 33  SE3 

(1)

In an uncoupled design, a single SE satisfies each CR. The result is an ideal system design with no potential conflicts between CRs relative to the SE. 84

IEEE Soft ware


 R 11 R12 R 13   SE1       R 21 R 22 R 23  × SE 2   R 31 R 32 R 33  SE3 

(3)

In this case, no independent SEs exist for resolving conflicts between CRs. Coupled designs are unsatisfactory in the axiomatic approach because they can’t meet the independence axiom. The coupling originates in an inadequate mapping of CRs to SEs or in conflicts among the CRs. In this case, we suggest redefining CRs and SEs to establish a diagonal or triangular matrix that can resolve the conflicts.

A case study We’ve applied the VIRE process to several realworld projects, such as a camera phone, a Web search system, and an information system for the Korean national tax service. Here, we show how the tax-service system created significant new value beyond the project’s original demands. The project aimed to develop a public-auction system for the national tax service by adapting a public-sale-management system that the government had used since 1997. A small team (about six members) managed the VIRE process.

Step 1: Defining goals

{CRs} = [R] · {SEs}

 CR 1    CR 2  =  CR   3

(2)

In a decoupled design, some CRs affect other CRs, but we can resolve the conflict by adjusting an SE that has no relationship with another CR. A design matrix that’s neither diagonal nor triangular is a coupled design, as shown in equation 3.

Low

Figure 4. Strategy canvas. The red line shows the customer survey results regarding satisfaction and dissatisfaction with existing systems; the green line shows results for new systems.

 R 11 0 0   SE1       R 21 R 22 0  × SE 2   R 31 R 32 R 33  SE3 

The project aimed to provide new value for existing tax-service customers and attract new customers as well. To define project goals, the team first examined existing systems with respect to customer value. Team members surveyed noncustomers as well as existing customers. The red line in figure 4 shows the strategy canvas developed to identify the existing system’s status and problems. The results indicate participant dissatisfaction with the existing system’s performance, operability, work suitability, and functionality. Participants expressed mainly satisfaction, however, with its processing speed, security, and effectiveness using memory.

Table 1

Step 2: Identifying new values The team elicited all customer requirements and selected the 15 highest-priority requirements, shown in table 1. The ERRC analysis raised and created requirement values that would ensure customer satisfaction. The requirements included adding new tools and processes (CR15), an electronic approval system (CR7), and glue code (CR5). These functions are potential factors for increasing customer value. Team members analyzed the priorities and customer importance from the requirements. Analysis results showed that changing the existing (closed) systems to secure open systems was the most important factor to customers. An automatic-alarm function proved unimportant to them, so it ranked lowest among the requirements.

Priority of key customer requirements CR no.

Step 4: Redefining requirements The green line in figure 4 shows the new strat

Priority

CR1

The new system must be linked indirectly with the tax-service system (host) because of security problems.

1

CR 2

A supporting tool for communicating between the national taxservice system (host) and the new system (Unix) is required.

2

CR3

The system must allow headquarters to examine the statistical data.

13

CR4

The system must implement additional functions, such as preserving attachments prior to national tax establishment.

14

CR5

A glue code is required to increase the fitness of the relative data.

8

CR6

The database of the national tax-service system (host) must be linked to the database of the new system (Unix).

6

CR7

The system must be linked to the national tax-service system and to an electronic approval system.

4

CR8

The systems must have real-time monitoring of the progress of public auction.

9

CR9

The system must tolerate the load of 2,000 users at the same time.

3

CR10

The database (file system) must be changed to a relational database to improve speed and data management.

10

CR11

An alarm function is required to avoid missing important jobs.

15

CR12

The system must keep a stable speed while the court auction information is entered.

12

CR13

The system must be implemented with consideration given to maintainability and extendability.

CR14

The screen must be designed to make it highly usable.

CR15

The business-process-management solution must be aware of what users do in each process.

Step 3: Analyzing ERRC The project team related SEs to CRs and analyzed SE costs from the requirements. Figure 5 shows the SE hardware or software required to realize customer requirements and the relative costs to implement SEs to satisfy their correlated requirements. In the analysis of 15 SEs, system software (SE1) represented 28.9 percent of the entire system cost. Next, business software and the relational database (SE10) represented 26 percent. In contrast, SE12, SE14, SE15 represented just 1 percent of the entire cost of the system. The team calculated the importance customers placed on the 15 requirements by scoring the prioritized requirements identified in step 2. The CI value is therefore based on the CR priorities. High-priority requirements received high values. In our case study, CR1 and CR9 were degree 5, which is the highest value; CR3, CR4, and CR11 were degree 1, which is the lowest. The team calculated business importance using CI values and correlations according to the equation in step 3.3: the BI1 value of SE1 is multiplied by CIj with Rj for all CRs involving SE1, then all Rij values are summarized. Applying the ERRC hybrid approach, the project team decided to create four new system elements based on customer requests—specifically, SE5, SE10, SE13, and SE15. The team also eliminated three major system elements—SE2, SE3, and SE8—in response to stakeholder negotiations. Moreover, the ERRC analysis results supported reducing the performance of SE1 and SE4 and increasing the performance of SE9 and SE12.

Customer requirements

7 11 5

egy canvas, which reflects the ERRC analysis results and revised requirements. The project team used the data analysis in step 3 to verify the strategy canvas according to the project goal.

Step 5: Validating requirements The team used the axiomatic approach to validate requirements. The initial matrix wasn’t coupled, and some conflicts showed up among the CRs and SEs. The team solved the problems by transforming the initial matrix through recoupling, regrouping, and relocating CRs and SEs. When a conflict appeared, the team performed an ERRC analysis and changed the system architecture. The system architecture resulting from the VIRE process therefore reflects iteration and redefinition of requirements until they verifiably reflect the proper SE selections. January/February 2008 I E E E S o f t w a r e

85

Un ix Co serv mm e r Bu un and s in ic a s y Da ess tion stem ta -p s Di serv roce erve softw sk ss r ( e r -m too are Fra arra an l) me y ag em R e wo en po rk ts r t A u in olu to- g t tio o a o Co rm l n mp in Re one g so la nt- lut We tiona bas ion ed l b Te app data -dev sti lic ba elo Fil ng t atio se pme e- oo n-s nt me erv CB shar l tho er ing D m t do o s Pr i o log d o l dle ftw iva y are wa te lin re e

Figure 5. ERRC analysis results for Korean national tax service.

CR1 CR2 CR3 CR4 CR5 CR6 CR7 CR8 CR9 CR10 CR11 CR12 CR13 CR14 CR15 BI RC ED

SE SE SE SE SE SE SE SE SE SE 1 2 3 4 5 6 7 8 9 10 � • � � � � � � � � � • � • � � � � • � � � � � � � � � � • � • � • � � � 54 36 36 40 60 43 47 9 54 81 29 8 10 8 8 4 7 7 10 26 – × × – o × + o

SE SE SE SE SE 11 12 13 14 15 � • �

� � � • � • � •

�

� � � •

�

42 42 46 32 54 2 1 3 1 1 + o o

Evaluation results To determine whether VIRE-based developed systems created a new market, we adapted an observational method suggested by Alan Hevner and his colleagues.10 This method served as the theoretical base for comparing the two national tax-service systems—namely, the old, traditionally developed Asset Management System and the new, VIRE-based Public Sale System. As table 2 shows, the new PSS logs about 19,000 users for 6 hours a day compared with the AMS’s 2,000 users for 5 hours a day. The development costs weren’t dramatically greater, even though the project added new elements to create new customer value. This is because the project eliminated low-value requirements. In addition, the development time was shorter, even though the PSS requirements analysis period was one month longer than AMS’s. Eliciting requirements from not only existing customers but also noncustomers, such as senior managers and other agents, was a critical success factor. Noncustomers helped identify user interface and system functional problems to correct. These improvements helped PSS win a “best project” 86

IEEE Soft ware


CI 5 4 1 1 3 4 4 3 5 2 1 2 3 2 4

Correlation degree � =9 � • =3 � =1 BI CI CR RC SE

Business importance Customer importance Customer requirement Relative cost System element

award from the Korean government in 2006. Giving stakeholders and noncustomers incentives to become involved early in the project early—for example, by explaining benefits of the new systems to them—was another important lesson learned.

In short, VIRE added new customer values in the PSS and created a new market space. PSS was successful enough to open a new market space—a blue ocean—in the Korean government information system domain.

W

e’ve successfully applied and evaluated the VIRE approach in several case studies, but it still needs further validation. For example, we want to determine whether VIRE is appropriate for red oceans and, if so, how these environments would affect process complexity. We also plan to improve the ERRC analysis process by adapting analytical methods, such as the analytic hierarchy process, to the calculations of ERRC decision factors. Finally, as in the case study presented here, we’ve practiced ERRC analysis in terms of high-level cus-

Table 2 Comparing VIRE with the Traditional Method Category description

Traditional method

VIRE method

Project name

Asset Management System

Public Sale System

Duration

Jan. 2005–Dec. 2005 (12 mos.)

Jan. 2006–Oct. 2006 (10 mos.)

Cost

US$0.8 million

US$1 million

Increased users

2,000→2,000

2,000→19,000

Mean connecting time (existing users)

5 hrs.

6 hrs.

Leading users

Clerks in only the national tax and asset management office

Clerks and middle administrators including other agencies

User satisfaction

60% positive

80% positive

System success

Maybe

Yes

New market exploration

No

Yes

tomer requirements and system elements. Detailed requirements and subsystem elements make the ERRC matrix so complex that it’s difficult to calculate the factors manually. Scalability will therefore require an automatic ERRC analysis tool.

About the Authors Sangsoo Kim is a PhD candidate in the College of Information and Communications

at Korea University and an aircraft maintenance officer (Major) in the Republic of Korea Air Force. His research interests are software engineering economics, requirements engineering, self-adaptive software, and modeling and simulation. He received his MS in modeling and simulation from Korea National Defense University. Contact him at the Embedded Software Engineering Lab., Dept. of Computer & Communications Eng., Korea Univ., 5-ga Anam-Dong, Seongbuk-Gu, Seoul, 136-713 Korea; [email protected].

Acknowledgments

The Ministry of Information and Communication, Korea, supported this research under the Information Technology Research Center support program, supervised by the Institute of Information Technology Advancement (IITA-2006-C1090-06030032). For further information, contact Hoh P. In at [email protected].

References 1. D.P. Kelly and B. Culeton, “Process Improvement for Small Organizations,” Computer, Oct. 1999, pp. 41–47. 2. K.C. Dangle et al., “Software Process Improvement in Small Organizations: A Case Study,” IEEE Software, Nov./Dec. 2005, pp. 68–75. 3. W.C. Kim and R. Mauborgne, Blue Ocean Strategy, Harvard Business School Press, 2005. 4. W.C. Kim and R. Mauborgne, “Value Innovation—the Strategic Logic of High Growth,” Harvard Business Rev., July-Aug. 2004, pp. 172–180. 5. B. Boehm and H. In, “Identifying Quality-Requirement Conflicts,” IEEE Software, Mar. 1996, pp. 25–35. 6. B.S. El-Haik, Axiomatic Quality, John Wiley & Sons, 2005. 7. R. Kazman, H. In, and H. Chen, “From Requirements Negotiation to Software Architecture Decisions,” Information and Software Technology, Dec. 2004, pp. 511–520. 8. N.P. Suh, “Design-In of Quality through Axiomatic Design,” IEEE Trans. Reliability, vol. 44, no. 2, June 1995, pp. 256–264. 9. K. Yang, and B.S. El-Haik, Design for Six Sigma, McGraw-Hill, 2003. 10. A.R. Hevner et al., “Design Science in Information Systems Research,” Management Information Systems Quarterly, vol. 28, no. 1, 2004, pp. 75–105.

Hoh Peter In is an associate professor in the College of Information and Communica-

tions at Korea University. His primary research interests are requirements engineering, value-based software engineering, situation-aware middleware, and software security management. He received his PhD in computer science from the University of Southern California. Contact him at the Dept. of Computer & Communications Eng., Korea Univ., 5-ga Anam-Dong, Seongbuk-Gu, Seoul, 136-713 Korea; [email protected].

Jongmoon Baik is an assistant professor in the School of Engineering at Information

and Communications University. His research interests include software process modeling, the software testing process maturity model, value-based software engineering, software economics, software reliability engineering, and software six sigma. He received his PhD in computer science from the University of Southern California. He’s a member of the ACM and IEEE. Contact him at the School of Eng., Information and Communication Univ., 119 Munjiro, Yuseong-gu, Daejon, 305-732, Korea; [email protected].

Rick Kazman is a professor in the Department of Information Technology Manage-

ment at the University of Hawaii and a visiting scientist at Carnegie Mellon University’s Software Engineering Institute. His research interests include software architecture, design and analysis tools, software visualization, software engineering economics, human-computer interaction, and information retrieval. He received his PhD in computational linguistics from Carnegie Mellon University. Contact him at the Dept. of Information Technology Management, Shidler College of Business, Univ. of Hawaii at Manoa, 2404 Maile Way, Honolulu, HI 96822; [email protected]. Kwangsin Han is a project manager in information systems development at K amco (Korean Asset Management Corp.) in Seoul. His research interests are requirements engineering and software project management. He received his MS in software engineering from Korea University. Contact him at the Dept. of Information Systems, K amco, Asia-Europe Meeting Tower 28F, World Trade Center, 159-1, Samsung-Dong, Gangnam-Gu, Seoul, 135798 Korea; [email protected].

January/February 2008 I E E E S o f t w a r e

87