Identifying and Quantifying Reuse in the SAP Requirements ...

Identifying and Quantifying Reuse in the SAP Requirements Engineering Process Maya Daneva Clearnet Communications Inc, 200 Consilium Place, Suite 1600 Toronto, ON M1H 3J3 Canada [email protected]

Abstract. This research is a first step towards the introduction of reuse measurement activities into the SAP requirements engineering process. We present why reuse metrics data are collected, where and when during this process reuse measurements are made, what to count as reuse and how to count it, what to do with the reuse data and how the reuse indicators fit into the large picture of SAP requirements engineering. We demonstrate the feasibility and the utility of applying our approach to an experimental case study. Some counting model validation issues are discussed at the end.

1 Introduction The implementation of Enterprise Resource Planning (ERP) software has been recognized as a very important component of a business process optimization project [12]. Today, many companies opting to process redesign choose the SAP R/3 ERP package to implement their reengineered processes. Most of the immediate benefits the R/3 System brings to these companies result from the full software reuse SAP has achieved. Since its foundation, SAP has institutionalized systematic reuse approaches and developed and successfully maintained the infrastructure of processes, people and tools for customers to reuse. SAP has made the reuse practice an integral part of the R/3 Configure-to-Order cycle and started reusing larger and bigger. Most recently, under the growing impact of architectures for integrated information systems (IS) and business engineering tools, SAP requirements reuse became the main stream. To achieve these high levels of reuse, SAP has developed the R/3 Reference Model, a comprehensive architectural description of the R/3 System including four views: business process view, function view, data view and organizational view. Specifically, the R/3 Reference Process Models represent integrated and function-spanning collections of business processes that occur often in practice and can be handled to the greatest extend possible automatically if a corporation implements the complete R/3 System [12]. Moreover, SAP has developed component-based solutions to common business process and data requirements derived from numerous branch-specific business cases. These are a kind of domain-specific frameworks with three major features [15]: an architecture defining the structure of integrated IS within the business problem domain, a set of business application components engineered to fit the

architecture, and a set of tools that assist the consultant in building component-based solutions using the domain knowledge within the architecture. Today, SAP requirements reuse is very common, and any consultant/process analyst will use SAP business engineering tools to routinely copy and reuse as many fragments from the R/3 Reference Model as possible in the blueprint stage of the project. There exists much literature dealing with the (re)use of the R/3 Reference Model, the reuse goals it helps to meet and the benefits it guarantees [12]. To the best of our knowledge, very little research has been done to quantify and estimate the results from requirement reuse the customers have achieved [10]. As Lim points out, reuse goals should be measurable, so that we can determine if we have met them [13]. The present paper is focused on this issue and contributes to the integration of reuse data collection and analysis activities into the SAP requirements engineering (RE) process. We introduce a reuse measurement practice and investigate its use in the requirements elicitation-documentation-negotiation cycle. The objectives of our reuse measurement model are as follows: (i) it should assist SAP project teams in practicing selective reuse [15]. Suitable requirements reuse measures could be used to identify business processes with the greatest potential for practicing reuse and define the extent to which reuse should be practiced; (ii) it is aimed at enabling the reuse process to be planned and reuse planning to be done as part of the RE process. This supports the teams in making informed decisions on where to focus reuse efforts and setting realistic reuse expectations in terms of reuse target levels to be adhered to in the R/3 project; (iii) it is intended to be a mechanism for tracking and comparing reuse levels achieved at the end of each stage of the R/3 implementation cycle. This article is structured as follows: Section 2 places the reuse measurement activities in the context of SAP RE and shows how to integrate them into the RE process. Section 3 presents the reuse measurement model. Section 4 reports on the experiences of applying our reuse counting method to five SAP scenarios, discusses how the metrics data can be useful and summarizes our plan for reuse measure validation. Section 5 concludes the paper and indicates areas of future research.

2 The Context for SAP Requirements Reuse Measurement Pfleefer states: ‘You can not do useful measurement without understanding process issues, and you can not do effective reuse without proper measurement and planning’ [19]. With this in mind, many software metrics practitioners recommend a software process model be used as a starting point for a measurement study [6,17]. In this research, the context for reuse measurement is provided by using a SAP RE process model. It allows to capture the reuse activities during the RE process and to define a reuse metrics plan that states when, what and how to measure. The next section analyzes the SAP RE process from reuse point of view in terms of activities, actors, deliverables and tools. Based on this analysis, a reuse measurement practice in introduced in Section 2.2.

2.1 Analysis of the SAP Requirements Engineering Process The standard methodology for rapid R/3 implementation, called AcceleratedSAP (ASAP), provides a disciplined process for coordination, controlling, configuring and managing changes of the R/3 business application components [12] with an explicit emphasis on the where, when and how of practicing reuse as part of the implementation cycle. To investigate the ASAP RE process, we modelled it as a spiral in which the radial arms represent the increasing collection of information by three types of activities (Fig. 1.): • requirements elicitation activities which are concerned with finding, communication and validation of facts and rules about the business, • enterprise modelling activities which are concerned with the business processes and data analysis and representation, and • requirements negotiation activities which are concerned with the resolution of business process and data issues, the validation of process and data architectures and the prioritization of the requirements. Business Blueprint

Requirements Elicitation

l0 Le ve

l2

l1 Le ve

Le ve

Le vel 3

Requirements Negotiation

Business Scenario and Data Models

Questionnaires Requirements Modelling

Fig.1. The SAP requirements engineering process

The ASAP methodology suggests four iterations of the spiral. Level 0 iteration aims at developing a clear picture of the company’s organizational structure based on the pre-defined organization units in the R/3 System. Next, the main objective of level 1 iteration is to define aims and scope for business process standardization based on the R/3 application components. Level 2 iteration aims at deriving business process architecture based on scenarios from the R/3 Reference Model. Finally, level 3 iteration refers to the specification of data conversion, reporting and interfaces requirements. The actors in these activities are business process owners and key users who are responsible for the business processes to be covered by the SAP solution.

Next, the ASAP RE process is supported by the following tools: (i) the ASAP Implementation Assistant which provides reusable questionnaires, project plans, cost estimates, blueprint presentations, blueprint templates, project reports and checklists, as well as manages the documentation base; (ii) the SAP Business Engineer, a platform including a wide range of business engineering tools fully integrated into the R/3 System [12]; (iii) enterprise modelling tools (ARIS-Toolset, LiveModel and Visio) which have rich model management capabilities and assist in analyzing, building and validating customer-specific process and data architectures based on the R/3 Reference Model. The ASAP RE process begins with reuse, ends with reuse and includes reuse in all the phases in-between. The process is based on proven reuse practices and techniques and it ensures that the requirements are correct, consistent, complete, realistic, well prioritized, verifiable, traceable and testable. This is achieved by using the R/3 Reference Model. Instead of building an integrated information system from scratch, with the R/3 Reference Model we build a solution from reusable process and data architectures based on SAP’s business experience collected on a large scale. Our analysis shows that the R/3 Reference Model supports the RE process in multiple ways: • in requirements elicitation, it provides a way for business process owners and SAP consultants to agree on what the SAP business application components are to do. • in requirements modelling, it serves two separate but related purposes. It helps to quickly develop a requirement definition document that shows to the business owners the process flow the solution is expected to support. Beyond that, it can be seen as a design specification document that restates the business specification in terms of R/3 transactions to be implemented. • in requirements negotiation, the R/3 Reference Model serves as a validation tool. It makes sure that the solution will meet the owners’ needs, it is technically implementable and it is maintainable in future releases. Reusing architectural components in the RE process is saving both time and money. As the business process requirement analysis is the most expensive consulting service in a business engineering exercise, the reuse of the R/3 Reference Model definitely provides the greatest savings. 2.2. How Requirements Reuse Measurement Fits with RE This section explicates the reuse measurement activities and presents exactly how reuse measurement can be integrated with the RE activities and where in the RE process reuse measurement data will be taken (Fig. 2). In this research, reuse measurement involves several activities and assumptions: • reuse data collection and extraction are based on two major RE deliverables: business scenario models and business object models; • reuse metrics data analysis is based on quantitative indicators; • reuse metrics data are used by SAP analysts during the requirements negotiation and elicitation. We suggest reuse measurement be applied once the modelling activities of level 2 iteration are completed and the customer-specific process and data architectures are

built. Based on the reuse metrics data analysis, the SAP process analyst may decide what negotiation / elicitation activities to take place next. The use of the reuse metrics data is discussed in more detail in Section 4. Requirements Negotiation








Make reuse recommendations Set reuse goals and expectations Define scope for practicing reuse Rethink rejected requirements Prioritize requirements







Identify reuse constraints Clarify motivation for customization Analyze options for process standardization Collect input to modify models

Requirements Elicitation

Reuse Data

Requirements Reuse Measurement

Business Object Models Scenario Models / Process Models

Requirements Modelling

Fig. 2. Integration of requirements reuse measurement in RE

As per Fig. 2, a reuse measurement practice supports the RE process in four areas: (i) quantitative analysis of process and data architecture reuse prior to solution design; (ii) strict separation of the requirements reuse from reuse at design/code level; (iii) definition of measurable reuse goals and expectations; (iv) better understanding of the reuse constraints and needs for customization. In the next section, we narrow down the discussion to the requirements modelling activities to provide more insight into the deliverables subjected to measurement. 2.3 SAP Requirements Modelling In the R/3 Reference Model structures the business content of the R/3 business application components in business scenarios and business objects. These represent building blocks for the development of the customer-specific business process and data architecture at the early stage of the SAP project. The reuse-driven requirements modelling exercise is supported by using standard process and data description languages together with the Business Engineer. This tool is based on the Business Object Repository which allows the SAP process analyst to get access to 900 pre-defined processes and 180 pre-defined business objects that structure the R/3 system in a business-oriented way. The SAP business requirement documents specify business scenarios that are represented in terms of event-driven process chains (EPC), a modelling notation developed by Scheer [24] and accepted by SAP as a process modelling standard for R/3 implementation projects [12]. As shown in Fig. 3, it includes three types of modelling concepts: processes, events, and logical connectors. The processes represent timeconsuming business transactions that use, update or create business objects. Within a company, a process describes what an organizational unit does. In the SAP R/3 System, a process means a transaction. Furthermore, the events describe both conditions

for the execution of processes, and results. The events refer to points in time and are defined as data items that should be available at the start and at the end of process` execution. Events trigger or drive the process flows that follow. For example, if a client places a service order to a service center representative, the event `Service Order Arrived` is triggered. Next, the logical connectors (and, or, and exclusive or) describe the logical relationships between events and processes. The connectors define alternative or parallel workflows through the process chains. Business Process Model

Requirement for services has arisen

Requirement occurred

PReq with contract number is created

Requirement for services has arisen

Requirement occurred

Business Scenario

XOR

XOR

Select PReq item category

Purchase requisition processing for service

Purchase req. item category service is selected

XOR

Determine PReq account category

PReq with vendor is created

PReq w/o source of supply is created

XOR

PReq account category known is selected

PReq account category unknown is selected

Fig. 3. An example of a scenario and a business process model.

The processes included in the scenario model have business objects, business object models and data entity types assigned to them. To simplify the presentation, these components are omitted in Fig. 3. Business objects define: (i) logical structures of the business like plants, warehouses, storage locations, (ii) business documents like purchase requisition, quotation, purchase order, and (iii) resources like materials, equipment, vendors. A business object is considered as a set of entity types that share a common external interface [22]. A business object usually consists of a source entity type and all those entity types that are hierarchically dependent on it [23]. The internal structure of a business object is described by means of the Structured EntityRelationship Model (SERM), a data modelling language anchored on four concepts: entity types, attributes, relationship categories and specialization categories. Entity types serve to model items needed to carry out a business process. Attributes represent properties the business users wish to attach to an entity type. There are five classes of attributes that may characterize an entity type: key attributes, conceptual, inherited, organizational, country-specific ones. Among these attribute classes, the first three ones are of relevance to our research. Next, relationship categories specify dependencies between entity types. The relationships are oriented from a source entity type to a target entity type and serve to model aggregations, classifications (hierarchies) and links. For example, the entity type `Purchase Order` has as an attribute the aggre-

gation entity type `Purchase Order Item’. The specialization categories are used to build supertypes and subtypes (generalization and specialization entity types). For example, the generalization entity type `Order` is related to the specialization types `Sales Order` and `Purchase Order`. Furthermore, business objects and data entity types assigned to a process are grouped in input/output lists which specify what business objects are needed as input to this process and what objects are created / updated as output [23]. For each business object from the list, the entity type acting as input/output is given underlined. In the SAP Business Engineer, the input/output lists are called input/output assignments and allow to navigate from scenarios to business processes, business objects, entity types, physical tables and table fields.

3 The Reuse Measurement Model This section defines our reuse measurement practice in terms of what to count as reuse and how to count it. It presents a reuse measurement model we developed on the basis of three major sources: (i) IBM’s reuse metrics starter kit [21] and the reuse models in [13,15] which led us in the process of building the reuse indicators, (ii) Jones’ framework to applied software measurement [9] and the existing FP counting practices [7] standardized by the International Function Points User Group (IFPUG), and (iii) our previous research on the use of functional size metrics in SAP RE [4,5] which obtained a set of measurable complexity attributes for business process models and business objects specified by means of the SAP modelling standards. 3.1 The Definition of SAP Requirements Reuse Our model is based on the notion of “reuse percents”. It was selected because it is easy-to-understand and easy-to-use, and it represents the de-facto standard measure of reuse level [21] in the software business. We derived a reuse indicator that includes reused requirements as a percentage of total requirements delivered: SAP_Reuse = ( RR / TR ) * 100%

(1)

where RR represents reused requirements, and TR represents total requirements delivered. In this paper, requirement borrowed from the R/3 Reference Model can be classified as reusable if it does not require modification. If borrowed requirement does require minor or major enhancement before use, we term it ‘customized requirement’. To build well-defined and valid metrics [6], we selected a consistent and reliable means for structuring and collecting data to make up metrics: (i) we applied Basili’s Goal Question Metrics [3] analysis to define the indirect measures we want to know: the size of the reusable requirements and the size of the total requirements in a project; (ii) we selected to use a standard functional size measurement methodology, namely FPA because of its appropriateness to the software artifact being measured [9,10] and its proven usage and applicability in software reuse studies [2,13].

3.2 Applying FPA to SAP Requirements The IFPUG Counting Practice Manual [7] describes the standard process of applying the FP metric and specifies which base logical component types of the software application are analyzed and how FP counts are derived from these components. The initial step in counting FP is to identify the application boundary, that is, to separate the application being measured from the business user domain and/or other independent applications [7]. Next, one has to identify two data component types, internal logical files (ILF) and external interface files (EIF), as well as three transactional types, external inputs (EI), external outputs (EO) and external inquiries (EQ). Then, the types are classified based on complexity levels and the unadjusted FP counts are calculated using the IFPUG predefined weights [7]. The final step is to holistically assess of the operational environment and the processing complexity of the application based on 14 general system characteristics (GSC). There are two prerequisites for the successful application of FPA to the SAP requirements [4]: the establishment of semantic equivalence between FPA components and the SAP process and data modelling concepts, and the derivation of rules that map the FPA base logical components into the SAP modelling concepts and help deriving FP counts. Semantic equivalence was achieved by: • re-considering the FPA methodology as a business requirement specification language anchored on five modelling concepts: ILF, EIF, EI, EO and EQ; • reviewing the meaning of each SAP and FPA modelling concept based on standard definitions provided by SAP [12,22,23] and IFPUG [7], its purpose and why it was introduced. Next, mapping rules were derived by applying a standard framework to each SAP modelling concept [4] and formulating what it means in FPA terms, how to interpret it in the context of FPA and why we think that the rule and its interpretation are valid. As a result, four sets of rules were obtained: (i) boundary identification rules, which refer to the scope of the business area being measured; (ii) component identification rules, which help identifying items subjected to FP counting; (iii) component classification rules, which suggest how to classify the components being counted; (iv) complexity assessment rules, which refer to the assignment of complexity factors to the components. Due to the space limitation, we do not include all the rules in this paper. For illustration purposes, we present the component identification rules in Table 1. The mapping rules are applied according to the following process: 1. Define the counting boundary. Apply the boundary identification rules to the scenarios discussed in the company’s blueprint document. Use the SAP Business Engineer to check which scenario pertains to which R/3 component. 2. Calculate the FP by business processes. For each business scenario, list processes that can be mapped into transactional types based on the component identification rules. Apply the component classification rules to these business processes to group them in three classes: EI, EO and EQ. Determine the complexity level of each process by applying the complexity assessment rules and the IFPUG complexity assessment table [7]. 3. Calculate the FP by data entity types. For each business process within a scenario, review the input/output assignments, company-specific SAP data models

and/or the SAP Business Object Repository to list relevant business objects and data entity types. Then, apply the component identification rules to them. Use the component classification rules to group the items in two classes: ILF and EIF. For each data entity type, identify key, conceptual and inherited attributes. Determine the complexity level of each entity type by applying the complexity assessment rules and the IFPUG table [7]. 4. Calculate the Unadjusted FP. Add all the FP from processes and data entity types. The inputs and the deliverables of each step of this process are described in more detail in [4]. Table 1. The component identification rules FP concept Logical File

SAP concept Business Object

Logical File

Mapping Rule Consider the underlined entity type of each business object from the Input/Output assignment as a candidate for a logical file.

Data

If the Input/Output assignment contains a data entity type without

Entity

reference to a business object, then consider the entity type as a candidate for a logical file.

Logical File

Event

Consider each event in the business scenario model as control information and candidate for a logical file.

Logical File

Link Entity

Consider a link entity type as a logical file if it has at least one nonkey attribute.

Logical File

Link Entity

Logical File

Specialization

Consider a link entity type as an implementation technique if it has key attributes only. Do not consider this type as a logical file. Consider a specialization entity type as a logical file if all the processes from the scenario model reference that type and there exists no reference to the super type of this entity type.

Trans. Type

Business

Consider each business process in the scenario model as a transac-

Process

tional function.

3.3 Reuse Levels and Reuse Indicators Based on the analysis of the changes [12] that could be applied to the R/3 Reference Model throughout the reuse-based process modelling exercise, the measurement data collected throughout the FP sizing procedure, and he modes of component reuse investigated by Karllson [11], we have defined three levels of SAP requirements reuse: • Level 3: It refers to processes and data entities that were reused without any changes. This category of reuse would bring the greatest benefits to the SAP customer’s organization. Scenarios with higher reuse rate at this level have greater potential of practicing reuse.

•

Level 2: It refers to minor enhancements applied to reference processes and data entities. A minor enhancement is defined as a change of certain parameter of a business process or a data entity that does not result in a change of the process logic. This category of reuse refers to those processes and data entities of the R/3 Reference Model that logically match the business requirements but their parameters need to be changed at code level to achieve their business purpose. Level 2 reuse is as desirable as level 3 reuse. • Level 1: It refers to major enhancements applied to reference processes and data entities. A major enhancement is any considerable modification in the definition of a process or a data entity that affects the process logic from business user’s point of view. This category of reuse refers to those processes and data entities that do not match the business requirements and require changes at conceptual level, as well as at design and code level to achieve their business purpose. Level 1 reuse is at least desirable. Furthermore, we introduce a level of new requirements, No_Reuse, to acknowledge the fact that reuse is not practiced at all. It refers to newly introduced processes and data entities. This does not mean a reuse category; it just helps us to partition the overall requirements and to get understanding of how much requirements are not covered by the standard scenario processes and business objects. Given our definition of what to count as reuse and how to count it, we have derived three reuse indicators: Level i SAP_Reuse = ( RR i / TR )*100%

(2)

where i = {1, 2, 3}, RR i represents reused requirements at Level i , and TR represents total requirements delivered. The indicator No_Reuse = ( NR / TR )*100% , where NR represents the new requirements, and TR has the above meaning, reports the percentage of requirements that can not be met by the R/3 application package unless some customer-specific extensions are not developed.

4 Experimental Application and Validation The objective of this experimental case study is to show the feasibility and the utility of applying the reuse measurement model. The study is based on two assumptions [4]: (i) the great impact of the SAP requirements reuse on the R/3 implementation projects explicates the necessity to make a distinction between FP asked and received by the business user and FP actually developed by SAP ABAP/4 programmers. The size numbers reported here reflect what the business process owners asked at the requirements stage of the project; (ii) the standard GSC are excluded from our consideration and discussion. Since we deal with a pure functional measure based on internal attributes of the business requirements, we adopt R. Meli`s point of view [16] which disregards the GSC as a capability to influence the final FP counts.

4.1. Results Five customer-specific scenarios were selected representing three R/3 application components. Each scenario was sized using four types of documents: the business blueprint document, the customer-specific scenario models, the business process questionnaires filled out by the business process owners, and the customer-specific business object model. The analytical tasks of identifying business processes, business objects and data entity types were supported by using the SAP Business Engineer which made it possible to get FP counts very quickly. The reuse indicators LeveliSAP_Reuse, i={1,2,3} and No_Reuse were computed based on the FP counting results RR 1, RR 2, RR3 and NR as summarized in Table 2. Table 2. FP counts and quantified reuse indicators for 5 customer-specific scenarios. Business Scenarios

RR3

RR2

RR1

NR

Level 3 Reuse

Level 2 Reuse

Fixed Asset Management

102

25

12

0

73%

18%

9%

0%

Procurement of Stock Materials

74

198

32

127

19%

50%

8%

22%

Procurement of Consumable Materials

86

165

0

30

31%

59%

0%

10%

Level 1 No Reuse Reuse

External Service Management

96

31

14

0

68%

22%

10%

0%

Project-related Engineer-toOrder Production

141

57

68

128

36%

15%

17%

32%

4.2. Analysis: What to Do with the Reuse Data? Two types of reuse profiles were derived from Table 2: scenario-specific profiles which present the levels of reuse pertinent to a given scenario, and level-specific profiles which show how the requirements are reused at a specific level within a project. Both types of profiles can be used in at least two ways: • multiple reuse profiles of two or more different ERP packages (SAP, BAAN, PeopleSoft) can be compared to determine which package best serves the needs of the company and offers the greatest opprtunity for reuse; • multiple reuse profiles of a single ERP package (e.g. SAP R/3) can be tracked over time to control the changes in overall reuse during the RE process. Furthermore, scenario-specific profiles are useful in planning for reuse and assigning target reuse levels to each scenario to be achieved throughout the R/3 implementation project. These profiles can be used in level 3 requirements elicitation to understand reuse constraints, for example, if a low level of reuse is indication that the R/3 Reference Model does not match the requirements of the project or there are some impediments to reusing standard R/3 functionality. The team can elaborate alternative process flows that eliminate the need of modifying the R/3 components. For these new process models, reuse levels can be determined and compared to select the best alternative.

Next, level-specific profiles are useful in the determination of how much reuse the team did, as well as, in the identification of business scenarios in which reusing SAP application components potentially would bring the greatest benefits to the company. According to the Level 3 reuse profile, the Fixed Asset Management scenario is the one which practices most reuse. These profiles are important to requirements negotiation activities. Specifically, in level 2 requirements negotiation, the profiles help understand where to put more negotiation efforts. As the R/3 customization is one of the most risky matters to deal with in the package implementation, it is likely to reprioritize the requirements so that to maximize the benefits from reuse. The business process owners can concentrate on those scenarios that have the lowest Level 3 and Level 2 reuse ratings. The team can review these scenarios on a function-by-function basis to justify why customization is necessary. In this validation process, the requirements usually get structured in three categories: must-to-have, nice-to-have, and possible-but-could-be-eliminated. Recent study reports that 50% of the initial must-tohave requirements usually go to the nice-to-have category during requirements negotiation [14]. As the process owners get better understanding of the SAP reuse, they become more conscious to the avoidance of unnecessary customization. 4.3. Validation Issues This section outlines our plan for validating (i) the design of the counting model and (ii) its application procedure. Respectively, this means empirically proving that (i) the measure captures the attribute under consideration and (ii) the application of the reuse measurement process and the resulting data are correct. The plan is based on Jacquet’s and Abran’s [8] framework for investigating measure validation issues. The counting model design issue has been treated from measurement theory perspective as suggested in [6,17,20]: a valid counting model should satisfy the representation condition. Our reuse indicators are indirect measures that make visible the interactions between functional size measurements. Here, ‘business requirement’ is the software artifact under consideration, and reuse is the attribute. FPA serves as the formal model that describes this artifact, and the reuse indicators are the measures. The internal structure of the standard FP measurement process is studied in detail and validated in [1]. However, recent FP studies point out that the representation condition is not sufficient [8]. Therefore, our plan is to apply Melton’s model-ordermapping approach [17] to formally prove five properties of our reuse measure: intuitiveness, specificity, order-preservation, monotonicity and scale type. An appropriate mathematical model of our counting method is planned to be developed for this purpose. To cope with the second issue, we turn to Morris and Desharnais’ [18] strategies for validating FP counting results. These cover four aspects of validation: collection of valid deliverables (models and blueprint documentation) that provide input information to the counting model, application of the mapping rules, application of the numerical assignment rules, and counting result analysis. As the work on the SAP R/3 implementation progresses, we plan to count FP and compute reuse indicators at the later implementation stages when more detailed deliverables are available.

5 Conslusions This work was motivated by the need for reuse mesurement practices in SAP RE. It has observed that most of the reuse metrics in the literature refer to the design/code level and no systematic investigation exists at requirements level. Our research is a first step towards the definition of a powerful measurement model in the context of the SAP RE cycle. This undertaking has been approached by analyzing the SAP RE process, developing reuse metrics plan and performing experiments to check its applicability and practicallity. Our major contribution is in the definition of a consistent requirements reuse measurement process and its integration into a larger process, namely the SAP RE cycle. We described exactly why reuse indicators are collected, what and how is counted as reuse, where and when during the RE process reuse measurements are taken, what we do with the reuse data and how the reuse indicators fit into the larger picture of SAP RE. The experience with the reuse measurement model has demonstrated its feasibility and practical usefulness. It shows that it is a powerful RE process-controlling tool. Moreover, reuse studies based on our counting model help us understand in both qualitative and quantitative terms the role of the pre-defined process models in ERP requirements engineering. However, we consider the work reported in this article as only the beginning of an ongoing effort to develop better requirements reuse measurement practices. Some areas we plan to address in the immediate future include: • validation of the reuse indicators. To this end, our reuse counting model can only be considered partially validated. Current efforts are therefore focused on the formal specification of the indicators to set properties that could formally be proved. • experimentation with the model in multiple SAP projects. To refine the mapping rules and the reuse level definitions we need to gather and analyze reuse metrics data in a large-scale experimental study.

References 1. Abran, A., Robillard, P.: Function Points Analysis: an Empirical Study of its Measurement Processes. IEEE Transactions on Software Engineering, 22 (1996), 895-909 2. Banker, R.D., Kauffman, R.: Reuse and Productivity in Integrated CASE: an Empirical Study, MIS Quarterly 15, 3, September, 1991, 375-401 3. Basili,V., Rombach, H.: The TAME Project: towards Improvement-oriented Software Environments. In: Oman P., Pfleeger, S.L. (eds.): Applying Software Metrics, IEEE Computer Society Press, Los Alamitos (1997) 4. Daneva M.: Deriving Function Points from SAP Business Processes and Business Objects, Journal of Information and Software Technologies (1999) Accepted. 5. Daneva M., Heib, R., Scheer, A.-W.: Benchmarking Business Process Models, Technical Report -Veroeffentlichungen des Instituts für Wirtschaftsinformatik der Universität des Saarlandes, Vol. 136, Saarbrücken (1996) 6. Fenton, N., Pfleeger, S.L.: Software Metrics: Rigorous and Practical Approach, PWS Publishing, Boston Massachusetts (1997) 7. IFPUG, Function Point Counting Manual, Release 4.0. Westerville, Ohio (1994)

8. Jacquet, J.-P., Abran, A.: Metrics Validation Proposals: a Structured Analysis. In: Dumke, R., Abran, A. (eds.): Software Measurement, Gabler, Wiesbaden (1999), 43-60. 9. Jones, C.: Applied Software Measurement, McGraw Hill, New York (1996) 10. Jones, C. Estimating and Measuring SAP Applications with Function Point Metrics, Version 2, Software Productivity Research, Burlington, MA (1998). 11. Karlsson, E.-A. (ed.): Software Reuse, John Wiley & Sons, Chichester (1998) 12. Keller, G., Teufel, T.: SAP R/3 Process Oriented Implementation, Addison-Wesley Longman, Harlow (1998) 13. Lim, W.: Managing Software Reuse, A Comprehensive Guide to Strategically Reengineering the Organization for Reusable Components, Prentice Hall, Upper Saddle River, NJ (1998) 14. Lozinsky, S.: Enterprise-wide Software Solutions, Addison-Wesley, Reading MA (1998) 15. McClure, C.: Reuse Engineering: Adding Reuse to the Software Development Process, Prentice-Hall, Upper Saddle River, NJ (1997) 16. Meli, R. Early and extended function point: a new method for function points estimation, in Proceedings of the IFPUG Fall Conference, IFUG, Ohio (1997) 17. Melton, A. (ed.): Software Measurement, Int. Thompson Comp. Press, London, UK (1996) 18. Morris, P., Desharnais, J.-M.: Function Point Analysis. Validating the Results, In: Proc. of the IFPUG Sprint Conference, IFUG, Ohio (1996). 19. Pfleeger, S.L.: Measuring Reuse: a Cautionary Tale, IEEE Software, April (1999) 20. Pfleeger, S. L., Jeffrey, R., Curtis, B., and Kitchenham, B. Status Report on Software Measurement, IEEE Software, March/April (1997), 33-43 21. Poulin, J. Measuring Software Reuse: Principles, Practices, and Economic Models, Addison-Wesley, Reading, Massachusetts (1997) 22. SAP AG, R/3 System, SAP Business Objects, Walldorf (1997) 23. SAP AG, R/3 System Documentation, Walldorf (1996) 24. Scheer, A.-W. Business Process Engineering, Springer, Berlin (1996)