Huiying Yang

Haijun Liu

Yan Li

Guanhua Huang

Fengxin Wang

Precision drip irrigation on hot pepper in arid Northwest China area1

Keywords: soil water potential, yield, water use efficiency, mulched drip irrigation, Northwest China

An experiment was conducted to study the effects of different soil water potential (SWP) on soil water content, hot pepper's yield, water consumption and water use efficiency (WUE) under plastic-mulched drip irrigation in the North-West China in order to find a suitable SWP to guide the pepper irrigation. Five treatments were set based on SWP, they were -10kPa (N1), -20kPa (N2), -30kPa (N3), -40kPa (N4) and -50kPa (N5). A control treatment (N6) was set based on local irrigation practice, i.e. border irrigation. SWP was measured using tensiometers at 0.2 m depth immediately under drip emitters. Pepper leaf area, plant height, soil water content, yield and total soluble solid (TSS) were measured, soil water content and WUE were calculated. Results shows that the differences in leaf area index and plant height were not significant (P>0.05) among treatments of N1, N2, N3 and N4. While the pepper yields, WUE and TSS were higher for treatments N3 and N4. Controlling SWP at -50kPa greatly decreased crop yield and WUE. Therefore, we recommend -30 ~ -40 kPa as the irrigation threshold for pepper cultivation under mulched drip irrigation in arid areas of the North-West China.

Introduction

Hot pepper is an important economic crop in China. Areas for pepper production is 35 000 ha [START_REF] Yuan | Pepper Production and Demand Situation of the World[END_REF] , mainly distributed in the North-West China and South-West China. The annual pepper production is about 215,000 t. In the North-West China, especially in Gansu Province, the hot pepper is widely cultivated with a high capsaicin and haematochrome content, mainly due to its special climatic condition [START_REF] Guo | Standardization of Pepper Cultivation Techniques for High Yield and Quality in Wuwei[END_REF] . During the long history of hot pepper cultivation in Gansu Province, the crop is generally irrigated with surface irrigation, mainly including border irrigation and furrow irrigation. Under these irrigation practices, crop water use ranges from 330 mm to 540 mm. Annual precipitation in this region is from 150 mm to 300 mm [START_REF] Peng | The Precipitation Features of Shiyang River basin[END_REF] . It can be found that precipitation cannot satisfy the water requirement of the pepper. Agricultural water use generally accounts for 92.57 % of the total water use in this region [START_REF] Kang | Study on Evolution and its Driving Forces of Water Utilization Structure of Shiyang River Basin in Northwest Arid Areas[END_REF] . With the development of economy, water allocation for agriculture will be decreased. Therefore, water-saving irrigation technology and irrigation scheduling are the ways to saving water and maintaining high crop yield and quality, especially for cash crops, for example hot pepper. Water-saving irrigation method is one of the key factors not only to save irrigation water but also increase crop yield in the arid region. Drip irrigation is one of the Water-saving irrigation methods. Hanson and May (2004) indicated that drip irrigation applies water both precisely and uniformly, in comparison with furrow and sprinkler irrigation, resulting in the potential to reduce subsurface drainage, control soil salinity, and increase yield [START_REF] Liu | Effect of Different Irrigation Methods on Plant Growth and Yield of Tomato[END_REF] . Liu et al. (2005) pointed out that plant growth and yield under drip irrigation were higher than those under flood irrigation, the soluble solid contents under drip irrigation also increased [6] . Li et al. (2007) found that drip irrigation can save irrigation water by 49.83% as compared to surface irrigation, and the crop yield increased by 9.99% [START_REF] Li | Effects of Different Irrigation Patterns on Soil Water Dynamics, Water Use and Yields in an Apple Orchard[END_REF] . Under most experiments, drip irrigation can save irrigation water by 30% to 40% [START_REF] Yang | Study on The Countermeasure to Develop WSI of Installed Agriculture[END_REF] .

Hot pepper is sensitive to water stress. Soil water deficit seriously affects the growth and yield of hot pepper. Therefore, many experiments were carried out to seek suitable soil water content for pepper. Wang et al. [START_REF] Wang | Pepper Plant Fertilizer and Water in the Role and Impact Studies[END_REF] found in a greenhouse experiment that yields of hot pepper were 53.4%, 72.3% and 79.1% of the maximum yield for irrigation amounts of 45, 67.5 and 90 mm, respectively, the highest hot pepper yield was achieved when moisture in the root-zone soil maintains between 60% and 80% of field capacity. Yang et al. [START_REF] Yang | Effects of Different Conditions of Irrigation and Fertilization on Dry Matter Accumulation, Nutrient Absorption and Yield of Hot Pepper[END_REF] found that pepper yield and dry matter accumulation increased with the increase of reasonable amount of water and fertilizer, and the highest yield was achieved when soil moisture maintain between 70% and 75% of field capacity. Huo et al. [START_REF] Huo | Influence of Irrigation Volume to Hot Pepper Growth[END_REF] also found that the highest pepper yield was achieved when soil moisture maintains 70% of field capacity, while too high or too low soil moisture greatly affects pepper production. In practice, the soil water content measurements generally require special equipments, and the measuring process is complicated, which are difficult for farmers to use in field practice.

Soil water potential is related to soil water content [START_REF] Lei | Soil Water Dynamics[END_REF] , and also used as an indicator to directly guide irrigation [START_REF] Zhang | A Study of the Effects of Different Soil Water Potentials and Optimum Water Potential Value of Irrigation on Rape[END_REF][START_REF] Li | Research on Water Saving Irrigation by Using Soil Water Potential as Irrigation Criterion[END_REF][START_REF] Marouelli | Water Tension Thresholds for Processing Tomatoes under Drip Irrigation in Central Brazil[END_REF][START_REF] Muirhead | The Influence of Soil Water Potential on the Flowering Pattern, Pod Set and Yield of Snap Beans (Phaseolus vulgaris L.)[END_REF][START_REF] Kang | Potato Evapotranspiration and Yield under Different Drip Irrigation Regimes[END_REF][START_REF] Wang | Effect of Soil Matric Potential on Tomato Yield and Water Use under Drip Irrigation Condition[END_REF][START_REF] Jiao | Effect of Soil Matric Potential on Waxy Corn Growth and Irrigation WUE under Mulch Drip Irrigation in Saline Soils of Arid Areas[END_REF][START_REF] Wang | Scheduling Drip Irrigation for Potato with Tensiometers[END_REF] . Some experiments showed that, the proper soil water potential is -25kPa for potato, -35kPa for radish, -50kPa for tomato. The objectives of this paper are to investigate the effects of different soil water potentials to soil water content, pepper's growth, yield, water consumption and water use efficiency under plastic mulched drip irrigation condition, and finally find suitable soil water potential to guide pepper irrigation in the arid region of the North-West China.

2

Materials and methods: [START_REF] Peng | The Precipitation Features of Shiyang River basin[END_REF] , and mean volumetric soil water content at field capacity is 0.243 cm 3 /cm 3 .

Experimental design

The experiment consisted of five treatments based on soil water potential (SWP), -10 kPa, -20 kPa, -30 kPa, -40 kPa and -50 kPa, they are referring to N1, N2, N3, N4 and N5, respectively. A control treatment (N6) was set according to the local irrigation. SWP for each treatment was measured using two tensiometers, which was installed at 20 cm depth immediately under the emitter. Each treatment included three replications, with a dimension of 4.6 m in width and 5 m in length for each replicated subplot. Each subplot was divided into three raised beds. The spacing between raised beds was 0.4 m; the width and height of the bed were 1.0 m and 0.2 m, respectively. All experimental subplots were following a complete randomized design, seeing Figure 1. The two tensionmeters were installed in the middle raised bed of each experimental treatment. Before the experiment, soil water content and SWP were measured simultaneously in the experimental field to determine the soil water characteristic curve. This curve was used to calculate soil water content and then to determine irrigation amount for each irrigation event using the measured SWP. The relationship between soil water content and SWP is expressed using Eq. ( 1).

θ = - • - = = ⑴
Where θ is volumetric soil water content in cm 3 /cm 3 , ψ is SWP in kPa. When the SWP was below the target SWP, irrigation begins. Each irrigation amount was determined using soil water content and field capacity with the Eq. ( 2).

( )

FC-θ M=AH p/η ⑵
Where M is irrigation amount in m 3 ; A is the plot area in m 2 ; H is irrigation depth in m and is set 0.25 m based on the root distribution; θ is the volumetric water content before irrigation, which is calculated from measured SWP; FC is the field capacity; p is the percentage of wetted area and is 0.652; η is irrigation efficiency and set 1.0 under drip irrigation. ). Therefore, there were two drip tapes in each raised bed. The raised beds and drip tapes were covered with a 1.4 -m -width black plastic sheet to reduce surface evaporation and control weed growth. Organic fertilizer (cow manure) was applied uniformly to each plot with a rate of 12000 kg/ha when the soil was plowed. Nitrogen fertilizer (urea) was applied to the peppers using the drip irrigation system by three times with a total amount of 180 kg/ha. The hot pepper (American Red) was seeded on 4 May and harvested on 25 September in 2009.

Measurements

(1)Meteorological factors Meteorological factors included temperature, humidity; solar radiation, wind speed, and precipitation were recorded by an automatic weather station in the experimental station.

(2) Soil water potential Soil water potential (SWP) was measured using tensiometers, which were installed at a depth of 0.20 m immediately below the emitter in one replicate subplot of each treatment. The tensiometers were investigated three times a day, at 8:00, 14:00 and 18:00. When the measured SWP is approaching the set values, irrigation begin.

(3) Soil moisture Soil moisture was measured every 10 cm from 0 to 60 cm soil layer by thermo-gravimetric method using augers every 15 d during the experimental period.

(4) Leaf area index Leaf area index (LAI) was measured by leaf area meter AM300 (AM300 Portable Leaf Area Meter, ADC Bioscientific Ltd., Hoddesdon, UK) at 15-day intervals during the pepper-growing season in 2009. For each event, LAI at three to five sites in each treatment were measured and the average value was used for data analysis.

(5)Total soluble solids Total soluble solid (TSS) was measured by handheld digital refractometer (PR-32α, Tokyo, Japan) during the harvest time in 2009. Three pepper fruits were random selected for each treatment and the average value was calculated.

(6) Yields

Pepper yields were determined at harvest. Twenty plants in the middle subplot of each treatment were randomly selected, and the numbers per pepper plant and weight of each pepper were investigated.

Calculations

Water consumption (ET) of hot pepper was estimated using the water balance method as:

) W W ( K P I ET 0 t e - - + + = ⑶
Where ET is the evaportranspiration, mm, I is the irrigation amount in mm; e P is the effective precipitation in the pepper growth period in mm; t W is the soil water storage at time of t in the 0-60 cm soil layer, mm; 0 W is the initial soil water storage in the 0-60 cm soil layer, mm; K is the groundwater recharge and was set 0 considering the groundwater table of 40 -50 m.

Water use efficiency (WUE) of hot pepper is expressed as the production of pepper consuming per units of water, and the calculation formula is:

ET Y WUE = ⑷
Where WUE is the water use efficiency in kg/m 3 , Y is the yield in kg/ha, ET is the evaportranspiration in m 3 /ha.

In this paper, SPSS11.5 statistical software (SPSS Inc., Chicago, IL, USA) was used for statistical analysis.

Statistical analysis

Statistical differences in leaf area index, pepper yield and pepper classifications among experimental treatments were analyzed with SPSS 11.5 software (SPSS Inc., Chicago, IL, USA). A level of 0.05 was adopted for the analysis of variance (ANOVA).

3

Results and discussion

Soil water content under different SWP treatments

Zhang (2001) reported that most of the pepper roots distributes in the upper 40 cm soil layer [START_REF] Zhang | Techniques for Raising Pepper Seedlings in Greenhouse[END_REF] . Our measurement also shows that more than 90% of root mass distributed within the 0 -40-cm soil layer. Therefore, we analyzed the soil water content in the upper 0 -40-cm soil layer (Fig. 3). It can be found that the average soil water content of N1 treatment was the highest, with the smallest variation during the whole experiment period among the six treatments. The reason maybe mainly due to the higher irrigation frequency and greater irrigation amount, i.e. everyday or once two days in vigorous growth stage for treatment N1, as compared to the other five treatments. The soil water content of treatment N5 was the lowest before August 20, which is mainly because of the least irrigation amount. The soil water content of treatment N6 was also very low before August 20 because the irrigation intervals were too long, i.e. once every 15 to 20 days. In the later period of the experiment, there is a minor difference in soil water content among treatments except N1, which maybe mainly due to more precipitation. The precipitation from June 20 to August 20 was 53.4 mm, and was 38.6mm from August 20 to harvest.

Plant height

Fig. 5 shows the changes of plant height for the six treatments during the experimental period. The figure shows that, plant height increased fast before August (generally in vegetative growth stage), afterward, it increased little or stop increasing in fruit growth stage. The plant height of N5 was the lowest and it was the highest for N6 treatment during the whole growing period. The height differences among N1, N2, N3 and N4 were insignificant (P>0.05). It can be concluded that controlling soil water potential of -50 kPa will seriously affect the growth of pepper.

Total soluble solids

Total soluble solid is an index of soluble solids concentration in fruit and always used to evaluate fruit quality. Results on TSS for the six treatments are showed in Fig 6 . The TSS content generally increased as the SWP decreased from -10 kPa to -40 kPa. The highest TSS was 9.2%, found for treatment N4. The lowest one was found for treatment N5 with a value of 7.5%. The TSS for flood irrigation treatment (N6) was similar to the treatments N1 and N2, but greatly less than those for treatment N3 and N4. It can be seen that controlling SWP of -50 kPa will greatly influence fruit quality, while controlling SWP within a relative deficit range (for example -30 to -40 kPa) maybe benefit crop quality. Findings of Ma et al ( 2006) [START_REF] Enciso | Onion Yield and Quality Response to Two Irrigation Scheduling Strategies[END_REF] is similar to our conclusion, who found that the deficit irrigation treatments enhance soluble solid matter in jujube fruits and improve the fruit quality.

Fruits classification

Sixty pepper plants were selected to determine the fruit yield for each treatment. The weight of each pepper fruit was measured individually for pepper classification. The pepper fruit was classified into four levels according to the pepper fruit weight, they were > 30 g (level 1), 20 -30 g (level 2), 10 -20 g (level 3), and < 10 g (level 4). Fig 7 shows the proportion of peppers in each level to the total yield. Except for treatment N5, the proportion was the highest in level 2 (20 -30 g), following by level 3 (10 -20 g), level 1 (> 30 g) and level 4 (< 10 g).There was little difference in pepper proportion of each yield level among treatments N1, N2, N3, N4 and N6. For treatment N5, about 50% of peppers were found in level 3, which means there were more small peppers as compared to other five treatments. This is the main reason for the lowest yield of treatment N5 among all treatments (Table 1). The greater amount of smaller fruit in treatment N5 will also influences pepper price and final incoming.

ET, Yield and WUE

Table 1 lists the irrigation amount, crop water consumption (ET), yield and WUE for the six treatments. Pepper ET was calculated using water balance equation, and WUE was calculated by Eq. (3). Pepper irrigation amount and ET decreased greatly from treatments N1 to N2, while differences of irrigation amount and ET were small for treatments N3, N4 and N5. These results are similar to the finding of Zhang et al. (2006) [START_REF] Ma | Effect of Regulated Deficit Irrigation on Water Use Efficiency and Fruit Quality of Pear--Jujube Tree in Greenhouse[END_REF] , who carried out a drip irrigation trial with SWP controlling on tomato, and found that irrigation amount decreases with the SWP decreasing first and then increases when SWP decreases to a certain level. We analyzed the relationship between the controlled SWP levels and irrigation water amount and crop ET, showing in the Fig. 8. The relationships between the irrigation amounts, total ET and SWPs can be expressed using a quadratic polynomial, as follows. Pepper yields for the six treatments were following the order: N3>N6>N1>N4>N2>N5. Statistical analysis shows that the pepper yield of treatment N3 was significantly (P<0.05) higher than Treatment N2 and N5, but the yield differences among treatments N3, N6, N1 and N4 were insignificant (P>0.05). The minimum pepper yield was obtained in treatment N5, which was lower by 16% than the maximum yield in treatment N3. This result means that the controlling SWP of -50 kPa will cause a great potential for yield reduction. This result is similar to the conclusions of the effect of different SWP to leaf area and plant height. The pepper yield of treatment N1 was less than those for treatment N3, though irrigation water amount was greater in treatment N1 as compared to N3, The lower yield for N1 may be due to excessive irrigation and high soil water content, which restrained the growth of root and thereby affected the yield. Ensico et al. (2008) studied the irrigation regimes of onion and found that higher total yields were obtained when the soil moisture was kept above -30 kPa, and total yields dropped significantly when soil water potential was below -50 kPa [START_REF] Zhang | Relationship Between Low Irrigation Limit and Yield, Water Use Efficiency of Tomato in Under--Mulching--Drip Irrigation in Greenhouse[END_REF] . Du et al. (2007) studied the irrigation regime of pepper in greenhouse in North-West China, and obtained a yield of 36.5 t / ha when the irrigation amount was 217.5 mm [START_REF] Du | A Comparative Study of Greenhouse Pepper under Several Irrigation Ways[END_REF] . Pepper yield in our experiment is similar to those of Du et al. (2007), while irrigation water in this study decreased by 38 mm. The yield of treatment N6 was the second highest among the six treatments, which show that the conventional irrigation method can also obtain a high yield. While, irrigation amount under conventional practice was about 40 -80 mm higher than the treatments of N2 to N5. Considering the minor differences in crop ET (Table 1) and soil water content (Figure 3), more irrigation water maybe lost through seepage under border irrigation for treatment N6, which therefore, decrease the irrigation water use efficiency.

Water use efficiency for the six treatments is listed in Table 1. WUEs of treatment N3 and N4 were 11.5 kg/m 3 and 11.4 kg/m 3 , respectively, which were greatly higher than those of N2 (9.8 kg/m 3 ) and N5 (9.9 kg/m 3 ). The WUE for treatment N1 was 8.3 kg/m 3 , the least one among the six treatments, which may be due to the greatest ET. Wan et al. (2007) found that high WUE of cucumber can't be obtained if the SWP threshold was too high [START_REF] Wan | Effects of Saline Water on Cucumber Yields and Irrigation WUE under Drip Irrigation[END_REF] . Kang et al. (2004) found in a drip-irrigated potato fields that the highest yield and WUE were found when SWP is -25kPa and the least for -55kPa. Metin et al. (2006) studied the effect of drip irrigation regimes on field grown pepper and concluded that WUE and IWUE values decreased with increasing irrigation intervals [START_REF] Metin | Effect of Drip Irrigation Regimes on Yield and Quality of Field Grown Bell Pepper[END_REF] , which is similar to our findings when the controlling SWP is from -10 kPa to -30 kPa.

Conclusion

From the mulched and drip irrigated pepper experiment, conducted in northwest China, we found that SWP levels greatly affected the pepper growth, fruits quality, yield and water use efficiency. The main results are summarized as follows:

Soil water content was higher and it's variation was scarce in the whole growth period when the SWP level is -10 kPa. Irrigation amount and crop water consumption decrease as the SWP threshold decrease. The relationship between crop ET and SWP can be fit as a quadratic polynomial.

Controlling SWP levels between -10kPa and -40kPa did a minor effect on leaf area index and plant height. The higher TSS, yield and water use efficiency were found when SWP levels are between -30kPa and -40kPa. SWP of -50kPa will greatly reduce crop leaf area index, height, TSS, yield and water use efficiency.

Comprehensively considering the pepper fruits quality, yield and WUE, controlling SWP levels of -30 kPa to -40 kPa at 20 cm depth immediately under drip emitter can be recommended as an indicator for pepper drip irrigation scheduling in northwest China.

Fig. 1 .

 1 Fig. 1. Schematic diagram of the treatment layout (a) and detail drawing of a replicated subplot (b), length unit in figure (b) is meter.

Fig. 2 .

 2 Fig. 2. Soil water potential (SWP) variations of different treatments in the experimental period 2.3 Agronomic practices Peppers were planted in a raised bed (Fig 1 b). In each bed, there were four pepper rows, with row spacings between the four lines of 0.3 m -0.4 m -0.3 m and plant spacing of 0.3 m. Two pepper rows was irrigated using one drip tape with emitters spacing of 0.3 m and emitter discharge of 2.7 l/h at the operating pressure of 0.1 MPa. (Lvyuan Inc, Beijing). The drip tape was deployed between the middle line of two pepper rows (Fig 1 b). Therefore, there were two drip tapes in each raised bed. The raised beds and drip tapes were covered with a 1.4 -m -width black plastic sheet to reduce surface evaporation and control weed growth. Organic fertilizer (cow manure) was applied uniformly to each plot with a rate of 12000 kg/ha when the soil was plowed. Nitrogen fertilizer (urea) was applied to the peppers using the drip irrigation system by three times with a total amount of 180 kg/ha. The hot pepper (American Red) was seeded on 4 May and harvested on 25 September in 2009.

Fig. 3 .Fig. 4

 34 Fig. 3. Average soil moisture content over 0 -40-cm soil layer in the experimental period 3.2 Pepper growth 3.2.1 Leaf area index Fig. 4 illustrates the changes of leaf area index (LAI) for the six treatments during experimental period. The figure shows a sigmoid shape for the LAI in the experimental period. The maximum LAI reached generally around 7 to 27 August. During most experimental period, LAI was the least for treatment N5, which may be due to the less irrigation amount. The differences in LAI among the other five treatments were not significantly (P>0.05) during the most experimental period.

Fig. 4 .

 4 Fig. 4. Changes of leaf area index (LAI) within the pepper growth period

Fig. 5 .

 5 Fig. 5. Changes of plant height within the pepper growth period 3.3 Fruits quality

Fig. 6 .

 6 Fig.6. Content of total soluble solid (TSS) of peppers for the six treatments

Fig. 7 .

 7 Fig.7. the proportion of pepper yield of each classification to the total yield

⑹Fig. 8 .

 8 Fig. 8. Relationships of pepper irrigation amount and ET to controlling soil water potential (SWP)

2.1 Experimental sites:

	The experiment was conducted at Shiyanghe Experimental Station for Water-saving in Agriculture and
	Ecology of China Agricultural University, located in Wuwei City, Gansu Province of northwest China (N
	37°52′, E102°50′50″, altitude 1581m) during April to October of 2009. The experimental site is in
	a typical continental temperate climate zone, mean annual temperature is 8 ℃, annual accumulated
	temperature (>0 ℃) is 3550 ℃, annual precipitation is 164.4 mm, mean annual pan evaporation is about
	2000 mm, arid index (the ratio of yearly water evaporation to year precipitation) is 15 --25, average annual
	sunshine duration is 3000 h and free frost days in a year is 150 days. The groundwater table is 40 -50 m
	below the ground surface. Soil texture is sandy loam, with a mean dry bulk density of 1.5 g/cm

Table 1 .

 1 Irrigation amount, ET, yield and WUE of pepper for different treatments : values in the yield column with the same letter are not significantly different by one-way ANOVA test at the 0.05 probability level.

	treatments	Irrigation amount(mm)	ET(mm)	Yield(ton/ha)	WUE(kg/m 3 )
	-10kPa(N1)	314	412	34.1(±4.2) abc	8.3
	-20kPa(N2)	204	321	31.5(±4.2) bc	9.8
	-30kPa(N3)	179	311	35.6(±5.0) a	11.5
	-40kPa(N4)	163	295	33.7(±5.7)abc	11.4
	-50kPa(N5)	180	312	30.7(±4.8) c	9.9
	Border irrigation(N6)	246	317	34.3(±4.2)ab	10.8

NS

Acknowledge

This research was partly supported by the Non-profit Industry Financial Program of MWR (grant number: 200801104) and the State Key Laboratory of Soil Erosion and Dryland Farming on the Loess Plateau (grant number: 10501-260). The authors greatly acknowledged the staff in Shiyanghe Experimental Station for Water-saving in Agriculture and Ecology of China Agricultural University for their supports in our field experiment.


Sabine Buckl
email: sabine.buckl@mytum.de

Florian Matthes
email: matthes@mytum.de

Christian M Schweda
email: christian.m.schweda@mytum.de

A Method Base for Enterprise Architecture Management

Responding to the increasing complexity and diversity of information systems development, method engineering provides techniques and tools for the analysis, design, and evolution of information systems. Similar challenges can be found in the research area of enterprise architecture (EA) management, whose main goal is to enhance the alignment of business and IT. While a multitude of methods and models to support EA management have been proposed over the years, situational factors as the goals pursued or the organizational context, in which the management function has to be embedded, are typically neglected. In this paper, we present a building block base for the design of situated EA management functions based on a comprehensive collection of best practice methods and models for EA management. Therefore, we discuss related work from the area of situational method engineering and pattern-based development and design. Based on these foundations, a building block base and the contained building blocks are presented and are applied alongside a case study from industry. The discussion is complemented by a prototypic tool implementation, which can be used to support the configuration process for situational methods.

Motivation

The enterprise forms a complex structure constituted of a large number of highly interdependent elements. The constant need to adapt this structure in response to changing external influences, as economic factors or new regulations, calls for an embracing approach to control and govern the necessary transformations. Enterprise architecture (EA) management is a discipline aiming to provide guidance for the enterprise transformation by taking a holistic perspective on the enterprise, covering concepts from the business to the IT infrastructure level, but also accounting for cross-cutting aspects as strategies, projects, or standards.

The embracingness of the management subject raises different implications relevant to EA management as a function. Most obvious, the holistic perspective taken requires a large amount on information about the architecture elements as well as their interdependencies. Collecting the relevant information, but also keeping the information up-to-date, communicating it to the interested parties (stakeholders) in the organization, or performing analyses are tasks, whose complexity grows with the rising amount of information to handle. This and the plurality of possible stakeholders as well as goals to pursue are two reasons that have promoted the development of the plethora of EA management approaches as found in today's literature. These approaches, e.g. The Open Group Architecture Framework (TOGAF) [START_REF]TOGAF "Enterprise Edition" Version 9[END_REF], the Archimate language [START_REF] Lankhorst | Enterprise Architecture at Work: Modelling, Communication and Analysis[END_REF], or Core Business Metamodel [START_REF] Österle | Business Engineering: Core-Business-Metamodell[END_REF], encompass general prescriptions on how to manage the EA together with conceptual meta-models, the so-called information models, for the corresponding management body. Accounting for the fact that each organization has its specific understanding of EA management and the associated goals, the general prescriptions are often complemented with statements that highlight the need to adapt to the using organization. When it nevertheless comes to concrete artifacts describing the design of both organization-specific EA management methods and EA description languages, literature becomes more scarce.

Recent publications of Leppänen et al. [START_REF] Leppänen | Towards a contingency framework for engineering and enterprise architecture planning method[END_REF] and of Riege and Aier [START_REF] Riege | A contingency approach to enterprise architecture method engineering[END_REF] emphasized the topic of adapting EA management prescriptions to the specifics of the using organization, delineating potential contingency factors of EA management. Winter et al. further analyze in [START_REF] Winter | Investigating the state-ofthe-art in enterprise architecture management method in literature and practice[END_REF] the plurality of EA management goals as pursued in practice. These publications indicate towards a more mature understanding of the field (see Section 2 for a detailed discussion). From this dedicated method engineering approaches for EA management can be considered the next research step, which is nevertheless aggravated by the typical challenges of EA management research as outline by Buckl et al. in [START_REF] Buckl | From ea management patterns towards a prescriptive theory for desinging enterprise-specific ea management functions -outline of a research stream[END_REF]: practicerelevant EA management research is usually carried out in close cooperation with the industry, such that the projects follow the industry partner's pace and have to deliver their benefits early. On the contrary, the field itself has a broad subject, is rooted in a multi-disciplinary background, and the effects of measures taken usually manifest in the long run after a couple of years. In Section 3 we describe an approach for designing situated EA management functions based on the foundation of method engineering. For the aspect of administering the knowledge base of the approach, we discuss how a pattern-based understanding of EA management, as taken by Buckl et al. in [START_REF] Buckl | A pattern based approach for constructing enterprise architecture management information models[END_REF], is called upon. Section 4 delineates the steps of applying the approach both from a theoretical perspective and along an anonymized practical example. Final Section 5 summarizes the findings of the article and gives a brief outlook.

Related work

An EA management function can be understood as a design product embedded into the context of using organization. Riege and Aier conducted in [START_REF] Riege | A contingency approach to enterprise architecture method engineering[END_REF] an exploratory analysis of the contingency factors, that result from this, and derived a contingency framework consisting of three factors:

adoption of advanced architectural design paradigms and modeling capabilities: targeting properties as the coverage of current and target states of the EA in the architectural models as well as of transformation plans deployment and monitoring of EA data sets and services: concerning the control and governance for the EA management processes via performance reviews and the availability of dedicated EA management marketeers organizational penetration of EA: aiming at the organizational perception of EA management in the IT departments and business units as well as the usage of EA management-provided services in these departments.

Based on the empiric results on these factors and the constituting items, Riege and Aier cluster the analyzed EA management functions into three different types: engineering functions, incepting functions and extended IT architecture functions. Former distinction supported from the empiric point of view nevertheless reveals a main limitation of the analysis. The analysis' results fail to support a clear distinction between the contingency factors and their effects. This may ascribe to the special nature of the interplay between the EA management function and its management body, but provides only minor support for understanding the impediments and catalysts of managing the EA.

In [START_REF] Leppänen | Towards a contingency framework for engineering and enterprise architecture planning method[END_REF] Leppänen et al. pursue a different approach in deriving the contingency factors of EA management. Based on the findings and experiences of the Finnish EA research program, they elicit their contingency framework (EACon) for EA management, providing the following categories of contingency factors:

-EA method goals reflect the stakeholder's requirements that the EA management function is meant to satisfy. These stakeholders can be located in different organizations participating in the EA management. -EA principles delineate constraints pertaining to the EA management function, such governance rules. These principles may be local to one organization or be shared in the organization network. -Roles refer to the people to be involved in both the EA management function as well as in the corresponding governance. Possible roles are the enterprise architect, as method user, and the EA method engineer. -Resources reflect manpower, monetary supplies and tool support that is available to the EA management function in the participating organizations. -Cluster describes the organizational environment into which the EA management function is to be embedded. Such cluster can be single organization or a network of enterprises cooperating to provide networked services.

Each of the above factors can according to Leppänen et al. [START_REF] Leppänen | Towards a contingency framework for engineering and enterprise architecture planning method[END_REF] be further detailed. For the cluster this reads as a more detailed understanding of the organizational culture and organizational structure, of which the latter is closely related to the factor decision rights constituting a part of the roles. Making explicit these different factors as well as the intricate relationships inbetween is the core contribution presented in [START_REF] Leppänen | Towards a contingency framework for engineering and enterprise architecture planning method[END_REF] by Leppänen et al. This clearly mirrors the focus of the article, that seeks to contribute to a contingency framework for engineering an EA planning method. It is hence not surprising that the particular factors of EACon remain decoupled from concrete solutions, guidelines, or prescriptions on how to optimally manage the EA given certain contingencies.

In [START_REF] Buckl | A pattern based approach for constructing enterprise architecture management information models[END_REF] Buckl et al. take a different perspective on the field of EA management. Experiencing the need for concrete and practice-proven solutions to recurring EA management problems, the authors translate the notion of the pattern (cf. Alexander et al [START_REF] Alexander | A Pattern Language[END_REF]) to the field of EA management research. For the field of EA management, Buckl et al. introduce three different types of pattern as follows:

method pattern define steps to be taken in order to address a given problem.

Furthermore, as a guidance for applying the method, statements about its intended usage context are provided. viewpoint pattern define the notations used by the methods, i.e. describe ways to present information necessary for performing one or more methods as stored according to one or more information model patterns.

information model pattern supply models structuring the information needed by one or more methods and visualized in one of more viewpoints.

For solving a particular EA management problem in a given organization, a user selects an appropriate set of method, viewpoint, and information model patterns. Based on these constituents, a user composes his specific EA management function, i.e. defines what would in line with Gutzwiller [START_REF] Gutzwiller | Das CC RIM-Referenzmodell für den Entwurf von betrieblichen[END_REF] be called an organization-specific EA management method. Former term sheds a light on the slightly uncommon understanding of method in the work of Buckl et al., e.g. in [START_REF] Buckl | A pattern based approach for constructing enterprise architecture management information models[END_REF]. While usually design-oriented methods are understood as constituted from roles, tasks, techniques, design results, and a corresponding meta-model, Buckl et al. separate the roles, tasks and technique (the method in their understanding) from the design results with their corresponding meta-model (views according to viewpoints and information models in their terms). This separation can be justified against the background of the stereotypic tasks employed in EA management and manifests the so-called method-language-dichotomy as alluded to e.g. by Schelp and Winter [START_REF] Schelp | Language communities in enterprise architecture research[END_REF] or by Buckl et al. in [8]. This dichotomy is utilized in Section 3 to formulate independent building-blocks for an EA management function in refinement of the EA management patterns. Helping the user in selecting the suitable EA management pattern, the EA management pattern catalog [START_REF]Chair for Informatics 19[END_REF] refines the basic idea and supplies a set of relationships between the different patterns. In particular, every method pattern references all viewpoint patterns that can be used in the method, whereas each viewpoint pattern relates to the information model pattern, covering the needed information. Pattern of all three types are described using a template resembling the so-called canonical pattern form (cf. Ernst [START_REF] Ernst | A Pattern-Based Approach to Enterprise Architecture Management[END_REF]). Each pattern states:

its usage context in which it can be applied, the problem that it has proven to solve, the solution which it applies to the given problem, the contradictory forces framing the space of observed solutions, and the consequences observed to result from the pattern's application.

With this standardized structure, the patterns can serve as valuable starting point for developing an approach for designing situated EA management functions. Such approach nevertheless has to deal with the inherent weaknesses of EA management patterns, e.g. their tendency to repeat themselves especially with respect to methods for documenting the EA, as well as terminological plurality of the pattern descriptions, resulting from the fact that patterns are observed in different practice cases without consistent overarching terminology.

Designing a situated EA management function

In line with the understanding of Harmsen that there is no method that fits all situations [15, page 6], we subsequently propose a situated approach to design an EA management function based on existing best practices. A situated approach according to Harmsen in [START_REF] Harmsen | Situational Method Engineering[END_REF] accomplishes standardization and at the same time flexibility to match the situation. A situation thereby refers to the combination of circumstances at a given point in time in a given organization [START_REF] Harmsen | Situational Method Engineering[END_REF]. In order to address these requirements, for each situation a suitable solution1 -so-called situational solution -is constructed that accounts for these circumstances. Reflecting the method-language dichotomy in EA management, two different types of solution constituents, method building blocks (MBBs) and language building blocks (LBBs), are used in the construction process and are configured as well as adapted with the help of formally defined guidelines.

Foundations

A complex and intricate research area like designing EA management functions represents a topic that is not easy to research. The heavy involvement of stakeholders, the broadness of the subject, and the delayed effects (see Section 1) call for a suitable structuring of the research subject. This structuring can be performed either using a vertical or horizontal domain decomposition strategy. In the vertical domain decomposition only a limited number of EA-related problems is addressed in an embracing manner with a comprehensive solution. In contrast, the horizontal domain decomposition addresses a variety of EA-related problems with either suitable management methods or modeling languages.

While the former type of decomposition is a frequently used one for approaching the area of EA management(cf. Johnson and Ekstedt in [START_REF] Johnson | Enterprise Architecture -Models and Analyses for Information Systems Decision Making[END_REF], which focus on EA analysis or Spewak in [START_REF] Spewak | Enterprise Architecture Planning -Developing a Blueprint for Data, Applications, and Technology[END_REF] emphasizing on EA planning aspects), we in line with Schelp and Winter in [START_REF] Schelp | Language communities in enterprise architecture research[END_REF] opt for a horizontal decomposition of the domain of EA management, which reflects the method-language dichotomy as discussed above. Such an approach is further backed by TOGAF, which contains the architecture development method -reflecting the methodical perspectiveand the content framework -representing the language part (cf. Open Group in [START_REF]TOGAF "Enterprise Edition" Version 9[END_REF]). In contrast to the approach taken by TOGAF, we advocate for making the interconnection points between the methodical and the language parts explicit. In order to do so, we introduce the variable concept in the MBBs serving as a placeholder for language aspects. Viewpoint variables for instance are used during method description to indicate placeholders for visual architecture descriptions, which must be filled during the organization-specific configuration.

The idea of interrelating best practice fragments to design an organizationspecific EA management function can only be realized against the basis of a common understanding and terminology of the topic. Although no such common understanding has yet evolved if the definition of the term EA or EA management is considered (cf. Schönherr in [START_REF] Schönherr | Towards a common terminology in the discipline of enterprise architecture[END_REF] and Schelp and Winter in [START_REF] Schelp | On the interplay of design research and behavioral research -a language community perspective[END_REF]), consensus on the fundamental activities and tasks that make up an EA management function exists (cf. [START_REF] Aier | A survival analysis of application life spans based on enterprise architecture models[END_REF]). In [START_REF] Buckl | Towards a method framework for enterprise architecture management -a literature analysis from a viable system perspective[END_REF], Buckl et al. revisit different approaches to EA management, e.g. Frank [START_REF] Frank | Multi-perspective enterprise modeling (memo) -conceptual framework and modeling languages[END_REF], Riege and Aier [START_REF] Riege | A contingency approach to enterprise architecture method engineering[END_REF], and The Open Group [START_REF]TOGAF "Enterprise Edition" Version 9[END_REF] to devise a method framework for EA management consisting of four activities as shown in Figure 1: From the perspective of architectural descriptions, the former activities are characterized as creating, using, and augmenting the EA description. The latter activity -configure & adapt -incorporates the nature of a meta-activity as it is concerned with the design of the former three activities. In terms of the situational method engineering this activity encompasses the process of situational method engineering [15, page 45], i.e. the steps characterization of the situation, selection of method fragments, and assembly of method fragments.

Similar to the method aspect, also the language aspect can be subdivided. An EA management-relevant problem can be described by a concern, i.e. an area of interest, and a goal, i.e. an abstract objective. A concern represents an organization-specific conceptualization of the management subject, while goals complement this static perspective via a time-dependence or a notion of better and worse. In that sense the achievement of a goal, e.g. increase homogenization, can be operationalized via measurements, such that a goal provides an evaluation function, which can be used to guide the EA planning process.

Structure of the building block

As motivated above, two different types of building blocks to design an EA management function exits -MBBs and LBBs, of which the latter are subdivided into building blocks concerned with the conceptualization, i.e. areas of interestinformation model building blocks (IBB) -and building blocks containing best practice visual representations -viewpoint building blocks (VBB).

Method building blocks An MBB describes the different tasks that are performed in order to achieve a certain goal in a given organizational context. The MBB further specifies the ordering of the tasks and execution alternatives. For every alternative path the MBB also describes the conditions that apply during task execution. Furthermore, a task can devise different techniques to be utilized. To perform an expertbased analysis of a planned state for example, a pattern-based technique or anindicator based technique can be utilized. Thus, each technique is linked to forces describing the benefits and drawbacks of the different techniques to be selected. Reflecting the method-language dichotomy each MBB contains a concern variable, i.e. a placeholder for the area of interest on which the tasks operate. During the configuration, the concern variable has to be replaced by the actual concern.

In order to be applied, the pre-conditions specified by an MBB need to be met. An exemplary precondition of an MBB dedicated to the analyze & evaluate activity is that the concern specified by the concern variable is already documented. Supplementary, each MBB also specifies post-conditions that are fulfilled after executing the MBB. In this vein, consistency checks can be executed ensuring a sensible configuration and ordering of MBBs. The above exemplary pre-condition illustrates the make-up of pre-and post-conditions, representing a combination of an area-of-interest, i.e. a concern, and a so-called meat-attribute, e.g. documented, acknowledged, or publicized, describing a property of the concern related to the MBB. In addition to the post-conditions, an MBB can specify consequences, which result from applying the building block. The notion consequence thereby does not only refer to negative side-effects but is also used to describe positive add-ons. In contrast to the post-conditions, consequences are described in an informal manner utilizing natural language descriptions.

Complementing each MBB contains a trigger variable, which specifies the trigger starting the execution of the tasks. In configuring the EA management function this variable is filled with an actual trigger. Each task is executed by a corresponding actor represented by an actor variable in the description of the method. The notion of actor variable similar to the notion of trigger variable is used to denote that the description of the MBB does not specify distinct actors or roles in the using organization, but merely describes a responsibility of a person or group. Further, the MBB can specify that the actor variable is bound in respect to its organizational role, e.g. might express that an escalation based enactment mechanism only works, if a superordinate actor can be called upon. Beside to the mandatory relationship to the executing, i.e. responsible actor variable, each task may relate to other actor variables as well, namely variables representing actors that are consulted or informed during task execution. The distinction between the different levels of involvement pertaining to a single task is based on the RACI model of CobiT (see e.g. [START_REF]Framework Control Objectives Management Guidelines Maturity Models[END_REF]), while a slightly different perspective is taken on the involvement level informed. For the purpose of describing MBBs, we assume that any actor involved in a task is informed, such that the responsible actor as well as consulted actors are counted as informed, too. The participation of actors in tasks is enabled via viewpoint variables, which designate that the actor takes a specific viewpoint on the information relevant during performing the given task. The notion of the variable here again describes that the MBB does not make concrete prescriptions on the viewpoint to be used, but in turn allows to select a specific viewpoint for accomplishing the task.

Language building blocks In designing the language for EA descriptions, both VBBs and IBBs are employed. Understanding a language in line with e.g. Kühn [START_REF] Kühn | Methodenintegration im Business Engineering[END_REF] as constituted of abstract syntax, semantics and notation, the two types of building blocks are used to specify notation and syntax, respectively. The semantics is specified denotationally in the glossary complementing the building block base (cf. Section 3.3 below). Each information model building block specifies the types, attributes and relationships that conceptualize the corresponding part of the EA, i.e. cover a stakeholder's concern or reflect the information necessary for assessing the attainment of a goal. For the latter purpose, the IBBs introduce a distinction between different kinds of types, most notably distinguishing between classes and mixins. As Buckl et al. outline in [START_REF] Buckl | A technique for annotating ea information models[END_REF], latter concepts can be used to formulate specialized IBBs are able to describe specific EA goals as availability regardless the actual EA concept, e.g. business application or business capability, they are attached to. A user can hence select the IBB reflecting a specific concern and combine it with a specific goal to his relevant EA problem, see Figure 2. The VBBs focus on the notational aspects of the EA description language, providing visual primitives, e.g. rectangles, and visualization rules, e.g. clustering, for defining how the information is visualized. The VBBs further relate to the information model or parts of it, specifying concepts of which type are mapped to which kind of visualization element. Thereby, an executable transformation from the syntactic concepts to their visual counterparts is defined based on the VBBs. With the focus of this article on the method and information model perspective, we abstain from going into the details of the mechanism behind the transformation. More information can be found in [START_REF] Buckl | Supporting ad hoc analyses on enterprise models[END_REF].

Structure and administration of the building block base

Critical prerequisite to the design of a situated EA management function, is the provision of standardized building blocks, which are stored and retrievable from what is typically called a method base (cf. Brinkkemper in [START_REF] Brinkkemper | Method engineering: engineering of information systems development methods and tools[END_REF]) or component base (cf. Kumar and Welke in [START_REF] Kumar | Methodology engineering: A proposal for situationspecific methodology construction[END_REF]). Due to the method-language dichotomy of our application domain, we abstain from reusing the misleading notions and introduce the term building block base for the repository. The structure of this repository is outline below and complemented by a description of the configuration and administration process. Enabling the selection of appropriate building blocks for a given situation requires the development of concepts and techniques to analyze and compare the incorporated building blocks. Following the idea of Pries-Heje and Baskerville in [START_REF] Pries-Heje | The design theory nexus[END_REF], we use the concepts of problem A problem represents the issue to be solved by applying the building block. A problem in the area of EA management typically consists of a goal representing an abstract objective, e.g. increase homogeneity, provide transparency, and a concern , i.e. area of interest in the enterprise, e.g. business support, application systems. organizational context The organizational context represents the situation in which the EA management function operates. Typical factors which are considered in the organizational context are the organizational culture, management commitment, or involved stakeholders.

Figure 3 illustrates the components and the structure of the building block base. To outline the administration of the building block base, we exemplify its development along the best practices for EA management as contained in the pattern catalog from [START_REF]Chair for Informatics 19[END_REF]. Therefore, the problems addressed by the different patterns are analyzed and the abstract goals as well as the concerns are identified. Thereby, an exemplary goal reads as follows "increase homogeneity" and the respective concern is "technology used by a business application" [START_REF] Buckl | Enterprise architecture management patterns -exemplifying the approach[END_REF]. The concerns and the respective information model patterns serves as input for the development of IBBs. Thus, also establishing a concern hierarchy, i.e. an evolution path, as introduced in [START_REF] Buckl | Conceputal models for cross-cutting aspects in enterprise architecture modeling[END_REF]. Furthermore, the usage context descriptions are investigated for descriptions of organizational contexts in which the respective pattern has been applied, e.g. "centralized IT organization", "upper management support", or "own budget for the EA management initiative". The MBBs are derived from existing method patterns, thereby, the textual description of the steps to be taken is used as input to derive tasks, responsible actors, and forces. Furthermore, the consequence section of the patterns serve as input for the preand post-conditions of the building blocks. Consequences which can be formalized in terms of a meta-attribute and a respective concern are reformulated as pre-and post-conditions. The identified goals and organizational contexts are used as input for characterizing the situation. To relate the components of the building block base, the above identified goals of and organizational contexts are the derived building blocks. The suitability of a building block for any combination of the goals and organizational conditions can then be defined utilizing a fitting matrix with the building blocks on the y-axis, the identified organizational contexts (goals) on the x-axis, and a scoring of the fitting function for the MBBs (IBBs) in the cell. The fitting function can thereby take a value form the set required, excludes, or helpful and serves as a decision-support system for the selection of building blocks. The assembly of building blocks is performed utilizing the variable concept, i.e. the IBBs are used to configure the concern variable, and the pre-and post-conditions of BBs, which determine an ordering.

Applying the building block base

The building block base is applied using three steps: characterization of the situation, selection of building blocks, and assembly of building blocks, described below along an example from a financial service provider BSM.

Characterization of the situation

In this phase the existing organizational context in the enterprise is described. Further, the specific EA management goal to be pursued and the related EA concern are delineated. For doing so, the using organization can call on the list of contexts, goals and concerns as contained in the building block base.

Resulting from previous acquisitions, BSM operates a highly heterogeneous landscape of business applications. Especially, maintenance of business applications developed a non-standard solutions for the formerly independent companies has become a costly task. Therefore, BSM seeks to increase homogeneity of the business applications hosted at the different locations. Due to the maintenance problems, the EA management can rely on high-level management support and is driven by a small EA management team located in a staff unit of the CIO's office. This team has to deal with the highly decentralized structure of the IT departments, such that the EA management process should be design to promote itself.

Selection of fragments

In this phase the building block base is searched for MBBs that match the organizational context and for IBBs that reflect the EA management problem. Figure 4 shows the results of a query against the building block base, returning IBBs containing the concept application. Similar searches are performed on the IBBs that reflect the cross-cutting aspect of standardization as well as on the MBBs starting with ones supporting the activity develop & describe. The search for the applicable methods presents two MBBs as well-suited for the organizational context: describe by interview and describe by workshop, as both these MBBs are helpful to market the EA management endeavor. For the aspect of standardization, three models for standards reflected in different IBBs are provided by the building block base: simple standardization, standardization via book of standards, and standardization by individual prescriptions. Reading through the consequences of the different building blocks BSM decides to chose an interview-based gathering of information about business applications and their hosting organizational units. For the aspect of standardization, a book of standards is to be created, marking certain technologies as standard or nonstandard, respectively. For the phase communicate & enact the MBB publish architectural descriptions is chosen.

Assembly of fragments

In this phase four sub-phases are conducted to compose the building blocks to a comprehensive EA management function:

Integrate IBBs: the different IBBs reflecting the concerns and goals are integrated into composite models covering specific sub-problems of the EA management-problem to address. Thereby, manageable information models are created which can subsequently be linked to the MBBs. Integrate and configure MBBs: the concern variable of each selected MBB is linked to the integrated information model that reflects the corresponding concern. If different concerns are to be treated by similar methods, the MBBs can be duplicated in this case. The configured MBBs are integrated into a process, and the consistency between the pre-conditions and post-conditions of consecutive MBBs is checked. Configure actors and triggers: for each sequence of MBBs the triggering event is configured. Further, the actor variables defined by the MBBs are bound to actual organizational roles of the using enterprise. Add and configure VBBs: for each actor, who participates in a task, a viewpoint variable exists. This variable is set to a composition of VBBs, expressing how certain parts of the corresponding concern (information model) are to be visualized. If the viewpoint variable is designed read-only, nearly no limitations on the type of viewpoint exist, whereas a read-write viewpoint is bound to comprise VBBs in a combination that represents an updateable view. This e.g. means that all information model elements intended to be written are represented 1:1 in the corresponding visualization.

During each of the aforementioned sub-phases, consistency checking is applied.

During the integration of the IBBs the approach analyzes, if an incompatible semantic mapping is created, i.e. if homonyms in terms of the glossary of the building block base are created by unifying types with a distinct meaning. Concerning the configuration of the VBBs, the approach analyzes whether the visualized information is available in the method's corresponding concern variable. Further, it checks whether the transformation from syntactic to visual primitives is bidirective, or not, such that the latter case is diagnosed as non-updateable view, which cannot be used for write access.

BSM integrates the IBBs covering business applications, hosting organizational units and used technologies into a single information model. In contrast the information, whether a certain technology is standard according to the book of standard, is separated into a different information model. Former model, is assigned to the concern variable of describe by interview, whereas latter model is linked to describe by workshop. The post-conditions of the two configure MBBs then read as OrgUnit-BusinessApplication-Technology.documented and as Technology.isStandard.documented. To the concern variable of the MBB publish architectural descriptions the information model subsuming both information models is assigned. Further concretizing the documentation-specific MBBs, BSM decides that the interviews on the business applications and related information are held every time, when an IT-project finishes. An enterprise architect asks the application owner of the corresponding business application. The standardization-related information is decided upon every six months during a workshop by a board comprised of enterprise architects, application owners and IT project managers. A re-publishing of the architectural description is triggered every time, when new information about business applications is available. The enterprise architects are responsible for creating the corresponding architectural description, which is made available to application owners, IT project managers, and the CIO. With the viewpoint being read-only, BSM decides to use a clustered visualization containing only organizational units and business applications, of which the latter are colored red, if they use at least one non-standard technology, or green otherwise.

Summary and outlook

In this article we motivated the need for organization-specific EA management functions, i.e. management functions that account for the specificities of the using organization with both respect to the context and the management goals.

Reflecting on the related work in Section 2, we showed what current research can already contribute to the design of such EA management functions and were able to delineate the omissions of current approaches. In Section 3 we applied the basic notions of method engineering onto the subject of EA management, describing an approach building on three types of building blocks for EA management functions, namely MBBs, VBBs, and IBBs. We further outlined how concrete building blocks look like and how they are interrelated in the EA management building block base, a EA management-specific implementation of the notion of the method base. In Section 4 we described how the building block base can be used to design an organization-specific EA management function. Thereby, we employed an example at a financial services provider. With its roots in the EA management patterns of Buckl et al. [START_REF] Buckl | A pattern based approach for constructing enterprise architecture management information models[END_REF][START_REF]Chair for Informatics 19[END_REF], the approach can rely on a sound and practice-proven basis of best-practice methods, viewpoints and information models. The rigorous mechanism for translating these patterns into building blocks further helps to ensure that the made prescriptions are applicable in practice. Notwithstanding, more in-depth evaluations of the usefulness of the approach remain to be conducted. Thereby, especially a comparison to less formal methods, e.g. TOGAF, are of interest. Such analyses are nevertheless subject for future research. In the context of the necessary

Fig. 1 .

 1 Fig. 1. Method framework of BEAMS Develop & describe a state of the EA, either a current state describing the as-is architecture, a planned state representing a medium-term future state or a target state, i.e. a vision of the EA. Communicate & enact architecture states and principles guiding the evolution of the EA to EA-relevant projects and to related management functions, e.g. project portfolio management. Analyze & evaluate the current state to identify potentials for improvement, evaluate architectural scenarios (planned states), or analyze whether a planned state helps to achieve the target state or not. Configure & adapt the EA management function itself, e.g. in response to an under achievement of the desired results or a changed situation decide on the addressed management concerns, pursued goals, and used methods.

Fig. 2 .

 2 Fig. 2. Integrated information model

Fig. 3 .

 3 Fig. 3. The components and structure of the building block base

Fig. 4 .

 4 Fig. 4. Searching the building block based for suitable IBBs

We subsequently employ the term solution instead of method in line with argumentation at the end of

Section 2.

Communicate & enact architecture states and principles guiding the evolution of the EA to EA-relevant projects and to related management functions, e.g. project portfolio management.Analyze & evaluate the current state to identify potentials for improvement, evaluate architectural scenarios (planned states), or analyze whether a planned state helps to achieve the target state or not. Configure & adapt the EA management function itself, e.g. in response to an under achievement of the desired results or a changed situation decide on the addressed management concerns, pursued goals, and used methods.

long-term analyses, it would further be interest to analyze, if the approach's prescriptions are beneficially for governing the EA management function, i.e. for evolving the function in response to organizational changes.


Dominique Mirandolle
email: d.e.mirandolle@students.uu.nli.vandeweerd

Inge Van De Weerd

Sjaak Brinkkemper
email: s.brinkkemper@cs.uu.nl

Incremental Method Engineering for Process Improvement -A Case Study

Keywords: Incremental method engineering, software product management, competence model, situational factors, maturity matrix

In order for companies to improve the maturity level of their development process, they need to design new methods or adapt the existing ones. This research aims to deliver a proof of concept of how incremental method engineering supports the maturation of methods in a product software company. We show how the adaptation of a method can lead to a higher maturity level. We assessed the method of a case company by means of the situational assessment method, resulting into the maturity level and situational factors. We also modeled eight different prioritization methods according to their maturity level and situational factors to find out which of these could be implemented into the case company's method in order to evolve to a higher maturity level. After matching the situational factors of the available methods with the company factors we find one method that is suitable to implement into the existing method at the case company. We explain how the implementation can take place and how this would evolve the method to full maturity.

Introduction

Product software companies have to be on track with the latest changes in the field of software development and product management. Naturally, their processes and methods need to be adjusted accordingly to the changes in the environment and growth of the company. Yet, many product software companies find it difficult to improve the maturity level of their methods [START_REF] Weerd | A Product Software Knowledge Infrastructure for Situational Capability Maturation: Vision and Case Studies in Product Management[END_REF]. In order for companies to improve this maturity level they need to design new methods or adapt the existing ones, while there is little education available in the software product management (SPM) area [START_REF] Van De Weerd | Towards a Reference Framework for Software Product Management[END_REF].

In this research, we use an incremental method engineering approach to improve an organization's process maturity. Method engineering (ME) is the discipline to design, construct and adapt methods, techniques and tools for the development of information systems [START_REF] Brinkkemper | Method Engineering: Engineering of Information Systems Development Methods and Tools[END_REF]. If a method is tuned to the project at hand, this is called situational ME. When only a method fragment, and not the entire method, is changed, this is called incremental ME. A method increment can be defined as "a method adaptation, in order to improve the overall performance of a method" [START_REF] Weerd | A Product Software Knowledge Infrastructure for Situational Capability Maturation: Vision and Case Studies in Product Management[END_REF]. Incremental ME can be seen as a sub type of situational ME, where incremental ME focuses more on evolving a method in time towards a higher maturity level by changing small parts of the method.

Aim of this Research

The aim of this study is to deliver a proof of concept of how incremental ME supports the maturing, and thus the improvement of processes in a product software company.

The main research question in this study is formulated accordingly: "How can incremental method engineering support process improvement in the software industry?"

By answering this question we aim to contribute to the field of incremental ME by showing how the adaptation of a method can lead to a higher maturity level of that method. We elaborate on how method increments, based on Situational Factors (situational factors) of both the method and the company, can evolve the method of our case company. This verifies the theoretical description of incremental ME.

Related Work

Several approaches have been introduced to make it easier for companies to change their development methods [START_REF] Kumar | Methodology Engineering: A Proposal for Situation-Specific Methodology Construction[END_REF][START_REF] Tolvanen | Incremental Method Engineering with Modeling Tools: Theoretical Principles and Empirical Evidence[END_REF][START_REF] Aydin | Making a Method Work for a Project Situation in the Context of CMM[END_REF]. To help companies select a proper approach to adapt an existing method, Ralyté et al. [START_REF] Ralyté | Towards a Generic Model for Situational Method Engineering[END_REF] present a generic model for situational method engineering. In their approach, the method engineer is able to combine the approaches that fit the ME project the best by setting intentions (goals) and connect these with strategies. Ågerfalk et al. [START_REF] Ågerfalk | Flexible Processes and Method Configuration: Outline of a Joint Industry-Academia Research Project[END_REF] also present a method to help method engineers with the configuration and adaptation of methods. They propose the use of pre-made reusable configurations of a base method suitable for a specific characteristic of a development situation. Rossi et al. [START_REF] Rossi | Managing Evolutionary Method Engineering by Method Rationale[END_REF] claim that method users, but especially method engineers need to be aware of the rationale of the method in order to coordinate the development and evolution of an existing method base. Van de Weerd et al. use the concept of incremental method engineering as a principle in their Product Software Knowledge Infrastructure (PSKI) [START_REF] Weerd | A Product Software Knowledge Infrastructure for Situational Capability Maturation: Vision and Case Studies in Product Management[END_REF]. Incremental method engineering is a specific type of situational method engineering, where development methods are over time incrementally adapted to the changing conditions. The principle is used in the PSKI, which enables organizations to acquire a custommade advice to improve their processes incrementally. An important part of the PSKI is the method base, which is loaded with existing method fragments. Accordingly to the Situational Factors (situational factors) of the company, method fragments are chosen out of the method base in order to create a more mature method. The domain for which the PSKI is initially proposed is Software Product Management. By developing the Software Product Management Competence Model [START_REF] Bekkers | A Framework for Process Improvement in Software Product Management[END_REF] (Fig. 1), they give an overview and structure to the software product management domain. The model divides the internal functions of software product management into four business functions: portfolio management, product planning, release planning and requirements management, which contain a total of 15 focus areas, such as 'requirements prioritization' and 'product roadmapping'. Furthermore, a maturity matrix for SPM was developed, in which for each focus area three to five capabilities were defined. The maturity matrix is depicted in Table 1. If all are implemented, full maturity is reached. The methods we analyzed in this research are all requirements prioritization methods, in the business function release planning.

Research Approach

In order to deliver the proof concept and answer the main research question, we perform a case study [START_REF] Yin | Case Study Research: Design and Methods[END_REF] at a product software company called Teezir, hereafter called 'the case company'. We focus on a small part of the release planning stage in the SPM Competence Model: requirements prioritization. We have chosen this particular process as it has not yet reached the highest maturity level within the case company, according to the assessment. Additionally, we are familiar with several methods applicable in this stage and literature about this stage. In this stage, the requirements for an information system are sorted according to importance for certain stakeholders. The literature we use for this research mainly consists on literature about requirements prioritization methods and method engineering.

Our research approach consists of two main steps:

1. Select and analyze methods. In order to deliver a proof of concept we analyze eight requirements prioritization methods. The analysis is performed by measuring their maturity according to the Competence Model, developed by Bekkers & van de Weerd [START_REF] Bekkers | A Framework for Process Improvement in Software Product Management[END_REF]. Additionally, we describe the situational factors per method, based on work by Bekkers et al. [START_REF] Bekkers | The Influence of Situational Factors in Software Product Management: An Empirical Study[END_REF].

2. Case study. We analyze the prioritization method that is used by the case company, as well as its maturity levels and situational factors. Based on this information, we map the method fragments found in the previous step to the case company and select the best one. Finally, we propose how to implement this method fragment.

Selection and Analysis of Methods

The methods that are selected for this research are from the SPM domain, in particular focusing on requirements prioritization. Different ways exist to prioritize requirements. Some existing methods are very complex and involve many stakeholders, while others are simple. In this section, first the requirements prioritization focus area is further analyzed. Then, an overview of the selected prioritization method is presented. Finally, the situational factors of each method are listed.

Requirements Prioritization

Table 1 presents the SPM maturity matrix, consisting of the 15 focus areas, each with its own number of specific maturity levels. The focus area specific maturity levels are represented by the letters A-F in Table 1 and range from maturity level 1 to 10 (the topmost row in Table 1). In this research we focus on requirements prioritization. This focus area contains five capabilities (denoted with letters A-E) [START_REF] Bekkers | A Framework for Process Improvement in Software Product Management[END_REF].

The five requirements prioritization capabilities and their goals are: A. Internal stakeholder involvement Goal: Improved product quality & increased involvement of internal stakeholders in the product management process. Action: All relevant internal stakeholders indicate the requirements that should be incorporated in future releases by assigning priorities to the requirements.

B. Prioritization method

Goal: Structure the requirement prioritization process and therewith provide a solid prioritization which is balanced and clear to all parties involved. Action: A structured technique is used.

C. Customer involvement

Goal: Incorporation of customer needs and wishes in the product. Action: Customers and prospects indicate the requirements that should be incorporated in future releases by assigning priorities to the requirements from their point of view. Customers can also be represented by delegates.

D. Cost revenue consideration

Goal: Create a financial basis for the prioritization. Action: Information about costs and revenues of each (group of) requirement(s) is taken into account during the requirements prioritization (costs can be expressed in other means than money).

E. Partner involvement

Goal: Improved product quality & increased involvement of external stakeholders in the product management process.

Action: Partner companies indicate requirements that should be incorporated in future releases by assigning priorities to the requirements.

Requirements Prioritization Methods

The eight requirements prioritization methods were selected based on the availability of literature of each method. The methods are shown in Table 2, along with the capabilities that are implemented in them. When combining the information available in Table 1 and Table 2, we can see that for example the Binary Priority List method has a maturity level of 4. We can conclude this, since Table 2 shows that capability A and B are implemented in this method. According to Table 1, an implementation up to capability B has a maturity level score of 4.

Table 2. Requirements Prioritization Methods

Method

Implemented capabilities Binary Priority List [START_REF] Bebensee | Binary Priority List for Prioritizing Software Requirements[END_REF] A B WinWin requirements negotiation model [START_REF] Boehm | A Spiral Model of Software Development and Enhancement[END_REF] A B C Integer linear programming approach [START_REF] Van Den Akker | Software Product Release Planning Through Optimization and What-if Analysis[END_REF] A

B C D E Requirements Triage [17] A B C E MOSCOW [18] A B C D Cost Value Approach [19] A B C D Quality Function Deployment [20] A B C Features Prioritization Matrix [21] A B C D E
When methods miss a capability, the maturity level only scores up to the capability before the first missing capability. For the Requirements Triage method [START_REF] Bebensee | Binary Priority List for Prioritizing Software Requirements[END_REF] this means that we measure the maturity level only up to capability C. This results in a maturity level of 5.

We modeled all the selected methods in Process Deliverable Diagrams (PDD). A PDD is a diagram that integrates an activity diagram on the left-hand side and a deliverable view on the right-hand side [START_REF] Van De Weerd | Meta-modeling for Situational Analysis and Design Methods[END_REF]. To illustrate our research method, Fig. 2 shows the activities and deliverables of the Requirements Triage method [START_REF] Davis | The Art of Requirements Triage[END_REF]. For all eight requirements prioritization methods such a PDD and a corresponding concept table and activity table were created.

Fig. 2. PDD of the Requirements Triage method

Situational Factors

Bekkers [START_REF] Bekkers | The Influence of Situational Factors in Software Product Management: An Empirical Study[END_REF] presents, in a case study among 14 software product companies, a list of 31 situational factors which need to be kept in mind when configuring or choosing a development method. For each of the selected methods we have marked whether the value of the situational factor is of any importance and if so, what value would suit the method best. As an example, we show the results of this analysis for Requirements Triage in

Case Study Design

The in-depth investigation in this case study takes place a product software company called Teezir, a 'search solutions' company (hereafter called 'the case company'. Their main product is a web based dashboard that integrates various widgets containing representations of the online reputation of a specific brand name (for example term clouds, sentiment analysis, volume of mentions etc.). The dashboard is a standard product which can be customized by the client himself. By dragging and dropping the preferred widgets on the dashboard, a suitable application for the situation or customer at hand can be generated. By carrying out interviews at the case company, we create a complete overview of the used prioritization method, situational factors and maturity level. This overview enables us to select the best fitting candidate method that, once implemented, will bring the case company to a higher maturity Fig. 3 illustrates how the process of fitting methods works. The process of comparing the situational factors of the candidate method to the case company's method can be seen as trying to fit a key on a keyhole. In a way we have created a keyhole by defining the situational factors of the case company. The different values of the situational factors are the holes in the keyhole's cylinder. All the candidate methods are keys, of which the situational factors are pins that need to match into the holes of the keyhole's cylinder. The situational factors of the candidate methods need to be as equal as possible to those of the case company (however, not all situational factors are relevant in this case). All we need to do is find the key that matches the keyhole.

Conduction of Case Study

In a semi-structured interview with the case company's software engineer, we analyzed the requirements prioritization method that is used at this company. We described their method and visualized it in a Process Deliverable Diagram (PDD): a diagram that integrates an activity diagram on the left-hand side and a deliverable view on the right-hand side [START_REF] Van De Weerd | Meta-modeling for Situational Analysis and Design Methods[END_REF]. With this information we were able to define the maturity level of the case company nowadays. Additionally, we elaborated on the case company's situational factors. Once we knew at which maturity level the case company was operating and which situational factors influence the company, we could suggest them to adopt (one of the) method fragments we analyzed in order for them to grow and develop their method towards a higher maturity level. Finally, the method fragment which suited the case company best is implemented in the original method. We elaborated on how this can take place and visualized the matured method in a PDD.

Analysis of Case Study Evidence

The case company uses the Dynamic Systems Development Method (DSDM) [START_REF] Stapleton | Dynamic Systems Development Method[END_REF]. The requirements prioritization method that is used in DSDM (and by the case company) is the MOSCOW method, as depicted in Fig. 4.

Fig. 4. PDD of the MOSCOW method

The MOSCOW requirements prioritization method contains maturity levels A to D, since it contains internal stakeholder involvement, a requirements prioritization method, customer involvement and a cost revenue consideration (measured in time). In addition, we have analyzed the situational factors for the case company, as is presented in Table 4.

The requirement prioritization method used at the case company nowadays is MOSCOW. This method contains the maturity levels A to D. If the case company's method would evolve, activities that contain level E should be added to the method. Level E contains partner involvement, and its goal is to improve product quality and to increase involvement of external stakeholders in the product management process.

bottom of the table we sum up how many matches and mismatches each method contains. In Table 5 it can be seen that Wiegers' Features Prioritization Matrix is not dependent on a lot of factors. The method is known to be applicable on almost every kind of project. Requirements Triage is on the other hand suitable for projects with eleven specific situational factors. Requirements Triage focuses on projects in which large amounts of requirements are involved. The method is designed specifically to deal with a 'chaos' of requirements, since it originates from the medical domain, where patients need to be 'sorted' or 'triaged' as quickly as possible. Additionally, it tries to involve as many stakeholders as possible (e.g. customers, developers, financial and legal representatives, etc.), which explains why company policy, customer involvement, legislation and partner involvement all have a high influence on the method. This suggests that the method deals with large projects, in which a large number of end-users are involved.

On the other hand, the Integer Linear Programming approach and Requirements Triage have six and nine mismatching situational factors respectively. They are both suitable for large projects, with a large amount of products involved. Therefore, it seems obvious to choose the Features Prioritization Matrix method to expand the case company's current method to maturity level E.

The case company could evolve its requirements prioritization method by applying the multiple stakeholder sheet in the MOSCOW method. This would mean that all stakeholders, including partners, would be involved in the requirements prioritization method. If the multiple stakeholder sheet would be used, all requirements first get a value based on the opinion of all stakeholders. The requirements that have the highest calculated value will be implemented. Fig. 5 illustrates how the additional activities would be added to the PDD of the MOSCOW method and how the deliverables change. Changes are marked in grey. As can be seen in Fig. 5, in Wiegers' Features Prioritization Matrix, the value of a requirement is calculated by estimating the benefits, penalties, costs and risks per requirement on a scale from 0-9 [START_REF] Wiegers | First Things First: Prioritizing Requirements[END_REF]. All requirements and corresponding values are stored in a spreadsheet. Wiegers developed the 'multiple stakeholder sheet', which is very useful in case there are multiple stakeholders that have different visions when it comes to the variables that result in the value of a requirement. In this case, those multiple stakeholders are the product manager and the developers. After assigning the values, the priorities are calculated and used as a basis for selecting the requirements for the next release.

Discussion

Using the multiple stakeholder sheet and thus the Features Prioritization Matrix seems be a useful way of integrating the opinion of all stakeholders, including partners, into the requirements prioritization method. The main advantage of adapting the method this way is that all involved stakeholders get an opportunity to influence the requirements prioritization. Additionally, the classification of requirements is turned into a calculated result out of estimating variables instead of an estimation of the importance of the overall requirement. This results most likely into a more accurate and realistic requirement prioritization. The case study carried out is a first evaluation of the idea of incremental method engineering, through marching situational factors. Although often described in literature, not many practical examples have been presented. Therefore, we believe that although this is just a single case study, it is an important contribution to the method engineering field. However, in order to strengthen our argument, we should carry our more case studies [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. Also, the method base in this research contained eight requirements prioritization methods. Further research can be done with a larger method base, in order to fine tune a method more specifically to the situational factors of a case company.

Furthermore, instead of using the current situational factors of the case company, it might also be interesting to use situational factors that the company predicts or aims to reach in the near future. For example, if a company wishes to expand its number employees this could be registered in the list of situational factors while matching them to a suitable method. By doing this the company might be less likely to outgrow its method in a short time.

A last important issue for further research is the evaluation of the method fragment implementation at the case company. Currently, we link this implementation to an increase in maturity. However, more interesting is whether the increment also leads to an increase in performance. Indicators that could be used for this are duration of the decision process, customer satisfaction or time-to-market.

Conclusion

In this research we have analyzed the requirement prioritization method of a case company according to maturity level and situational factors. We have also analyzed eight requirement prioritization methods on maturity level and situational factors to find out which of these could be implemented into the case company's method in order to let this method evolve to a higher maturity level. We used a comparison with keys (candidate methods) and a keyhole (case company's method) to visualize how a suitable method can be chosen out of all candidate methods. By doing this we have answered our main research question and illustrated how incremental ME can support the maturing of an information systems development method in a product software company.

We have found that the case company implemented the MOSCOW requirement prioritization method, which contains maturity levels A-D. In order to mature the method, level E would need to be added. Three out of the eight methods we analyzed contained maturity level E. By comparing the situational factors of these three methods with the situational factors of the case company, we have found that one method (Wiegers' Features Prioritization Matrix) is suitable to add to the existing method in order to let it mature.

For further research, we plan to carry out more case studies and extend the method base with more method fragments. Furthermore, we aim to verify whether the proposed method increments actually improve performance.

Fig. 1 .

 1 Fig. 1. SPM Competence Model

Fig 3 .

 3 Fig 3. Fitting the candidate methods to the case company's method

Fig. 5 .

 5 Fig. 5. Method increment with prioritization using Wiegers' matrix

Table 1 .

 1 SPM Maturity Matrix

	0	1	2	3	4	5	6	7	8	9 10
	Requirements management
	Requirements gathering	A		B	C		D	E	F
	Requirements identification		A			B		C		D
	Requirements organizing			A		B		C
	Release planning
	Requirements prioritization		A		B	C	D			E
	Release definition		A B	C				D	E
	Release definition validation				A			B		C
	Scope change management			A		B		C		D
	Build validation				A			B		C
	Launch preparation	A		B		C	D		E	F
	Product planning
	Roadmap intelligence			A		B	C		D	E
	Core asset roadmapping				A		B		C	D
	Product roadmapping		A	B			C	D		E
	Portfolio management
	Market analysis				A		B	C	D	E
	Partnering & contracting					A	B		C	D E
	Product lifecycle management				A	B			C	D E

Table 3 .

 3 Out of the 31 situational factors, 11 are of importance in this method. This is because Requirements Triage focuses on cooperation between business and development departments. The situational factors of which the value does not affect that functionality of the method, which can contain any value, are left out in this table.

Table 3 .

 3 Situational Factors of the Requirements Triage method

		Situational factor	Value
		Size of business unit team	Large
		Size of development team	Small to Medium
		Number of customers	High
		Number of end-users	High
		Release frequency	High
		Variability of feature requests	Large
		Product size	Large
		Company policy	High
		Customer involvement	High
		Legislation	Strict
		Partner involvement	High
	4	Case Study

Table 5 .

 5 Situational Factors of the three A-E methods

	Situational factor	Requirements Triage	Integer linear programming	Features Prioritization
	Development philosophy
	Size of business unit team	Large
	Size of development team	Small to medium		Small to medium
	Customer loyalty
	Customer satisfaction
	Customer variability
	Number of customers	High
	Number of end-users	High
	Type of customers
	Hosting demands
	Localization demand
	Market growth
	Market size
	Release frequency	High
	Sector
	Standard dominance
	Variability of feature requests	Large	Large
	Application age
	Defects per year: total
	Defects per year: serious
	Development platform maturity		High
	New requirement rate	High	High	Low to medium
	Number of products		High
	Product lifetime
	Product size	Large	Large	Small to medium
	Product tolerance
	Software Platform
	Company policy	High
	Customer involvement	High	High	High
	Legislation	Strict
	Partner involvement	High	High	High
	Matches	22	25	30
	Mismatches	9	6	1

Of the eight methods we analyzed in this research, three contain activities that implement maturity level E. These are Requirements Triage [START_REF] Davis | The Art of Requirements Triage[END_REF], Integer linear programming approach [START_REF] Van Den Akker | Software Product Release Planning Through Optimization and What-if Analysis[END_REF], and Features Prioritization Matrix [START_REF] Wiegers | First Things First: Prioritizing Requirements[END_REF]. Based on the situational factors of these three methods and those of the case company, we can now define which of these would suit the case company's method best (which key fits in the keyhole). Table 5 shows the values of the situational factors (the pins of the keys) of the three mature methods. We already defined the situational factors of the case company (the keyhole) in Table 4. The bottom rows of Table 5 show how many pins of the candidate methods' keys fit into the keyhole, and thus how many situational factors match to the situational factors of the case company.

The situational factors of which the value does not affect the functionality of the method and can contain any value, are left blank in this table. Additionally, we printed the situational factors that do not match the case company in italic. The cells that contain plain text do match the situational factors of the case company. At the