Establishing Reuse Measurement Practices in SAP Requirements Engineering Maya Daneva Clearnet Communications Inc. 200 Consilium Place, Suite 1600 Toronto, ON M1H 3J3 Canada E-mail:
[email protected]
Abstract This paper reports on first attempts to define, apply and fully integrate some reuse measurement practices into the SAP requirements engineering activities. It addresses all the facets of the context for SAP requirements reuse measurement and indicates who reuse metrics data are collected for, where and when during the RE process reuse measurements are made, what counting standards are appropriate, and what action items can be taken based on the reuse measurements.
1. Introduction In the implementation of Enterprise Resource Planning (ERP) software packages, such as SAP R/3, a high level of reuse of pre-defined assets has been recognized to be the key for shortening the time-to-production, achieving better product quality and lowering the cost of maintaining the customer-specific ERP-based solution [12]. Many corporations who opted to the SAP R/3 business application suite took advantages of the systematic reuse approaches and the infrastructure of processes, people and tools available for customers to reuse. 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 [14]. Moreover, SAP has developed componentbased solutions to common business process and data
0-7695-0565-1/00 $10.00 ã 2000 IEEE
requirements derived from numerous branch-specific business cases. These are a kind of domain-specific frameworks with three major features [17]: 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. Presently, reusing SAP requirements is widely practiced; many process analysts 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. A significant number of authors discus the (re)use of the R/3 Reference Model, the reuse goals it helps to meet and the benefits it guarantees [14]. To the best of our knowledge, very few of them have systematically applied reuse measurement practices and actually measured the reuse goals in quantitative terms [3]. As Lim points out, reuse goals must be measurable, so that we can determine if we have met them [15]. This paper examines the context for SAP requirements reuse measurement. It addresses some issues pertinent to the definition, the application and the integration of reuse measurement practices in the SAP requirements engineering (RE) process. Establishing sound and consistent SAP requirements reuse measurement practices is important for at least three reasons: • it will provide a mechanism for measuring the reuse goals as well as tracking and comparing reuse levels achieved at the end of each stage of the R/3 implementation cycle; • it will enable the reuse process to be planned and reuse planning to be done as part of the RE process. Based on reuse metrics data, SAP project teams will be able to (i) make informed decisions on where to focus reuse efforts and (ii) set realistic
reuse expectations in terms of reuse target levels to be adhered to in the R/3 project. • it will assist teams in practicing selective reuse [17]. 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. This article consists of 6 sections: Section 2 provides a systematic approach to planning, designing and integrating the requirements reuse measurement practices into a larger process, namely the SAP RE cycle. Section 3 deals with the planning aspects of SAP requirements reuse measurement. Section 4 suggests counting and data collection practices based on a customized measure for requirements reuse. Section 5 discusses how SAP project team members could use the metrics data. Section 6 concludes the paper and comments on the applicability of our measurement practices in other ERP package implementation projects.
2. The Approach to SAP Reuse Measurement Software metrics studies at corporations and universities prove that measurement works well for project teams who have a well-done definition of the context for measurement and a set of custom measurement practices devised to their context [7,18,20,21,22]. With these recommendations in mind, we have taken the following approach to identifying, understanding and creatively evolving requirements reuse measurement practices in SAP RE. It includes 6 steps: 1. Understand the SAP reuse project organization. Identify stakeholders, i.e. team members who are most interested in requirements reuse data. Understand the team members’ objectives and their participation in the SAP implementation process. 2. Identify reuse issues and reuse measurement goals. Understand what is the purpose of measures relative to the reuse issues brought by the stakeholders. 3. Map goals and reuse measures to the RE activities. Capture reuse activities in the SAP elicitationdocumentation-negotiation cycle and come up with a concept of how requirements reuse measurement can be integrated into the RE process. 4. Set up counting standards. Select measurable aspects of the reusable assets under consideration. Provide operational definitions of the measures. 5. Specify collection procedures and instruments. Define steps for obtaining the counts. Assemble a toolset for supporting the data collection and reporting activities. 6. Define action items that could be taken based on the measurement data. Identify how the stakeholders can use the reuse measurement data.
0-7695-0565-1/00 $10.00 ã 2000 IEEE
3. Overview of the Context for SAP Requirements Reuse Measurement Defining the context for SAP requirements reuse measurement means: • analyzing the SAP RE process from reuse point of view in terms of actors, activities, deliverables and tools, • building at least three types of models: stakeholder interaction diagrams, a high level RE process model and an integration model, and • specifying the reusable assets being measured. Based on the context description in this section, we design reuse measurement practices in Section 4.
3.1. Identifying relevant process actors Adequate and timely consultation of the parties interested in SAP reuse is of great importance to the reuse measurement process. It helps us (i) make sure that the definitions of our metrics are based on our SAP team members’ goals, (ii) eliminate misunderstandings about how metrics data is expected to be used, and (iii) define relevant procedures for packaging, cataloguing, publishing and reporting reuse metrics data. To identify the stakeholders, we applied the approach developed by Sharp, Finkelstein and Golal in [26]. Based on the SAP project organization structure, the project resources, the project plan, the project management standards and procedures, and the SAP implementation standards and procedures, we developed stakeholder interaction diagrams that documented three important aspects of our team working environment: relationships between stakeholders, the relationships of each stakeholder to the system, and the priority to be given to each stakeholder’s view. The organizational knowledge represented in the diagrams is needed to manage, interpret, balance and process stakeholders’ input into the SAP requirements reuse measurement process. It was used to structure the SAP project team members in four groups: • business decision makers, who are corporate executives from the steering committee responsible for the optimization, standardization and harmonization of the business processes across multiple locations. They define the concept of ownership over the SAP R/3 system and are most interested in learning about the business benefits from SAP reuse. • business process owners, who are department managers responsible for the project in specific business areas. They contribute the necessary line
know-how, design new processes and procedures to be supported by the R/3 business application components and provide the project with the appropriate authority and resources. • technical decision makers, who are SAP project managers responsible for planning, organizing, coordinating and controlling the implementation project.
•
configurators, who are both internal IT team members and external consultants involved in various work packages, e.g. SAP process analysts, data architects, configuration specialists, ABAP/4 programmers, system testers, documentation specialists. For each group, we identified a set of relevant questions that should be answered by using the metrics data. An extraction of our list is presented in Table 1.
Table 1. A list of reuse related questions.
Stakeholders Business decision makers
Business process owners
Technical decision makers Configurators
Questions 1. 2. 3. 4. 5. 1. 2. 3. 4. 5. 1. 2. 1. 2. 3.
What level of standardization could be achieved by reusing ERP software assets? What competitive advantages does the organization get from ERP reuse? What are the implications of reusing ERP processes in a constantly changing business environment? How to align business processes across locations so that ERP reuse can yield significant cost reductions and enterprise-wide benefits? What implementation strategy fits better with the project? How ERP reuse works with volatile process requirements? How much customization effort is required to implement minor/major changes in the business application components? What reuse expectations are realistic? What processes have the greatest potential for practicing reuse? What activities in our business processes prevent us from reusing more? How much effort is required to produce the user and training documentation associated to the customized components? How much reuse the team did? Are there any rejected requirements that should be re-analyzed because of reuse concerns? What implementation alternative fits best? Which segments of the requirements are likely to cause difficulties later in the implementation process?
3.2. Capturing the ASAP RE process activities 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 [14] 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 (Fig. 1.). Its radial arms represent the increasing collection of information by three types of activities: • 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 business process 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.
0-7695-0565-1/00 $10.00 ã 2000 IEEE
The ASAP RE proceeds in four iterations. Level 0 iteration aims at developing a clear picture of the company’s organizational structure based on the predefined 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 company-specific business process architecture based on scenarios from the standard SAP process and data architecture components. Finally, level 3 iteration refers to the specification of data conversion, reporting and interfaces requirements. The major actors in these activities are business process owners who are actively supported by the SAP consultants and the internal SAP process analysts and data architects. Next, the ASAP RE process is supported by the following tools: (i) the ASAP Implementation Assistant [14] 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 [14]; (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 reusable reference process and data models. Business Blueprint
0 Le ve l
vel
vel 1 Le
Le
Le
2
Requirements Elicitation
vel 3
Requirements Negotiation
Business Scenario and Data Models
Questionnaires Requirements Modelling
Figure 1. A high-level model for the SAP RE process.
3.3. How reusable assets help in the RE process The ASAP RE process begins with reuse, ends with reuse and includes reuse in all the phases in-between. The process uses 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. Based on our project experience, we found that it supports the RE process in at least three 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 assets 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.
0-7695-0565-1/00 $10.00 ã 2000 IEEE
3.4. Mapping measures to the ASAP RE cycle 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). The process of measuring reuse of SAP business requirements is described in detail in [3]. It involves several activities and assumptions: • reuse data collection and extraction are carried out by an internal SAP process analyst or external SAP consultant on the basis of two major RE deliverables: business scenario models and business object models; • reuse metrics data analysis is based on quantitative indicators; • reuse metrics data is used to support stakeholders’ decision during the requirements negotiation and elicitation; • reuse metrics data is reused at a later stage to support decision making in planning for future releases, upgrades and major enhancements. 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 (Fig.2). Given the reuse metrics data, the SAP process analyst may decide what negotiation / elicitation activities to take place next. The use of the metrics data is discussed in more detail in Section 5. Our integration model implies that reuse measurement activities support 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. 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
Figure 2. Rrequirements reuse measurement in RE: an integration model.
3.5. The specification of the reusable assets: basic concepts In the R/3 Reference Model structures the business content of the R/3 System 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 eventdriven process chains (EPC), a modelling notation developed by Scheer [25] and accepted by SAP as a process modelling standard for R/3 implementation projects [14]. As shown in Fig. 3, it includes three types of modelling concepts: processes, events, and logical connectors. The processes represent time-consuming 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.
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
Figure 3. An example of a scenario and a business process model.
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
0-7695-0565-1/00 $10.00 ã 2000 IEEE
exclusive or) describe the logical relationships between events and processes. The connectors define alternative or parallel workflows through the process chains. 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 [23]. 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 Entity-Relationship 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 three classes of attributes that characterize an entity type: key attributes, conceptual, and inherited ones. 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 aggregation 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 [24]. 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.
4. Devising Requirements Reuse Measure to the SAP RE Process This section addresses the operational aspects of our reuse measurement practices. It uses the results of our previous research on the derivation of reuse indicators from SAP scenario process models and business object models [3].
0-7695-0565-1/00 $10.00 ã 2000 IEEE
4.1. Counting standards 4.1.1. Reuse Definition. As Pfleeger [21] points out, we must choose reuse metrics based on what is visible for the SAP project team in the requirements modelling process of level 2 iteration. Thus, we came up with 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’. The notion of “reuse percents” 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. 4.1.2. Counting rules. To obtain well-defined and valid metrics [7], we selected a consistent and reliable means for structuring and collecting data to make up metrics: (i) we applied Basili’s Goal Question Metrics [2] 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 [8,11] and its proven usage and applicability in software reuse studies [1,15]. The standard process of applying the FP metric is described in the IFPUG Counting Practice Manual [9]. It specifies five base logical component types of the software application being measured: internal logical files (ILF), external logical files (ELF), external inputs (EI), external outputs (EO) and external inquiries (EQ). Furthermore, it provides rules for obtaining FP from these components. To apply FPA to the SAP requirements, a custom version of the IFPUG counting rules needs to be developed [4]. In this process, there are two issues to be resolved: (i) the establishment of semantic equivalence between FPA components and the SAP process and data modelling concepts, and (ii) the derivation of rules that map the FPA base logical components into the SAP modelling concepts and help obtaining FP counts. We achieved the semantic equivalence 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 [14,23,24] and IFPUG [9], 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. For illustration purposes, we present the component identification rules in Table 2.
Table 2. The component identification rules.
FP concept
SAP concept
Logical File
Business Object
Mapping Rule Consider the underlined entity type of each business object from the Input/Output assignment as a candidate for a logical file.
Logical File
Data Entity
If the Input/Output assignment contains a data entity type without reference to a business object, then consider the entity type as a candidate for a logical file.
Logical File
Event
Logical File
Link Entity
Consider a link entity type as a logical file if it has at least one non-key attribute.
Consider each event in the scenario model as control information and candidate for a logical file.
Logical File
Link Entity
Consider a link entity type as an implementation technique if it has key attributes only. Do not consider this
Logical File
Specialization
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 transactional function.
Process
The steps of applying the mapping rules are described in great detail in [4] in terms of inputs, deliverables and dependencies between them. 4.1.3. Reuse levels and reuse indicators. Based on the analysis of the changes [14] 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 [13], 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
0-7695-0565-1/00 $10.00 ã 2000 IEEE
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. Currently, case studies are being carried out to validate empirically our counting models and its application procedure [5]. Respectively, this means empirically proving that (i) our measure captures the attribute under consideration [7] and (ii) the application of the reuse measurement process and the resulting data are correct [19]. The validation exercise is being done on the basis of Jaquet’s and Abran’s [10] framework for investigating measure validation issues. Reuse data collection tools. Reuse measurements are only as good as the data that is collected and analyzed [7]. To assure the quality of the reuse data, three prerequisites should be in place: • a standard FP counting form; • a reuse metrics data base, and • a SAP business process nowledge repository. We adopted an extended version of the FP counting form presented in [8]. It was tailored to include information needed for calculating the reuse indicators. Based on our FP counting model [4], we devised a counting form usage procedure that indicates at exactly what point each piece of data should be collected. To reduce the level of bias, only one SAP process analyst was involved in data collection and data processing. Next, collected information has been stored and processed in Excel spreadsheet software. Summarized and detailed reports have been extracted from Excel tables. For example, Table 3 shows summarized results from measuring reuse of five SAP business scenarios. Finally, reuse data have been packaged, catalogued and published by using standard SAP business negineering tools, such as the ASAP Implementation Assistant or LiveModel. Since reuse metrics provide knowledge about the business processes, reports on metrics data should be considered as part of the SAP process documentation. It can be stored in a corporate intranet repository and, thus, made available for review and analysis to all interested parties. In this way, users of SAP documentation can easily navigate from scenario process models to functional size and reuse metrics data.
0-7695-0565-1/00 $10.00 ã 2000 IEEE
Table 3. Reuse levels for five SAP scenarios.
Business Scenarios Fixed Asset Management Procurement of Stock Materials Procurement of Consumable Materials External Service Management Project-related Engineer-to-Order Production
Level 3 Reuse
Level 2 Reuse
Level 1 Reuse
No Reuse
73%
18%
9%
0%
19%
50%
8%
22%
31%
59%
0%
10%
68%
22%
10%
0%
36%
15%
17%
32%
5. Strategies for Using the Reuse Data Typically, two types of reuse profiles could be derived from a requirements reuse measurement table (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. Business decision-makers can use both types of profiles in at least three ways: • multiple reuse profiles of two or more different ERP products (SAP, BAAN, PeopleSoft) can be compared to determine which package best serves the needs of the company and offers the greatest opportunity for reuse; • multiple reuse profiles of different releases (SAP R/3 3.1, 4.0B, 4.5, 4.6 ) of one ERP package could be compared to determine which release brings biggest benefits to the company. • multiple reuse profiles of a single ERP package (e.g. SAP R/3) can build an assessment of the overall level of standardization of the ERP solution in the organization. Reuse profiles of a single ERP package (e.g. SAP R/3) can be used by technical decision-makers to plan and control the reuse levels in the later phases of the ASAP implementation process. Business process owners and configurators can track requirements reuse levels over time to control the changes in overall reuse during the iterations of the RE process.
5.1. Scenario-specific profiles These profiles reveal information important to those team members who are responsible for planning for reuse and assigning target reuse levels to each scenario to be achieved throughout the R/3 implementation project.
The 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. Furthermore, scenario-specific profiles are helpful in planning for deliverable that should be produced in the later phases of the ASAP implementation, for example, SAP user documentation and training materials. Based on reuse metrics data, the technical decision-makers could assess to what extent the team could rely on standard materials provided by SAP consultants. The team would need additional resources (e.g. business process owners, internal training specialists, and documentation analysts) to document the processes with high Level1Reuse or No_Reuse rates. Finally, scenario-specific profiles are very helpful in planning for SAP upgrades. They provide a sound ground for assessing the customization risks for the upgrade project. When the organization decides on the migration of the existing SAP solution to a new release, scenario-specific profiles can be used to identify the processes that are likely to cause particular difficulties to the configurators. For example, Table 3 suggests that the process of Project-related Engineering-to-Order Production should be migrated with extra caution. The technical decision makers should budget and set resources aside for extra analysis of the gaps between those scenarios and the standard scenarios provided in the new SAP release. The gap analysis often leads to reengineering the business requirements with the purpose to achieve higher level of standardization and to avoid unnecessary customization.
5.2. Level-specific profiles These 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 (see Table 3). 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 re-prioritize the requirements in order to avoid
0-7695-0565-1/00 $10.00 ã 2000 IEEE
unnecessary customization. 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 blueprint 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-to-have requirements usually go to the nice-to-have category during requirements negotiation [16]. As the process owners get better understanding of the SAP reuse and its impact on the project plan and costs, they become more conscious to the SAP customization costs in process areas of low priority. Next, level-specific reuse profiles can help both business and technical decision makers define the SAP implementation strategy. If Level 1 reuse dominates and much customization efforts are anticipated, the team is likely to adopt a step-by-step approach to a sequenced implementation of the SAP components. If Level 3 reuse rates are the highest ones, the customization risks are reduced and a big-bang approach to implementing multiple components seems to be reasonable.
6. Conclusions In this paper, we removed the uncertainty associated with undertaking the incorporation of reuse measurement practices into the ASAP RE process. We adopted standard requirements reuse definitions within the SAP project organization, applied them consistently and fully integrated the reuse measurement activities in the ASAP RE cycle. We described exactly who reuse metrics data should be presented to, why reuse indicators are collected, how reuse measurements are mapped into the RE process steps, what counting standards are considered appropriate, what tools are used, and what we do with the reuse data. This plan helped us obtain a custom reuse measure that (i) relates closely to the issues under study, (ii) has high information content, (iii) permits easy and economic collection of data, (iv) shows requirements reuse variation and (v) has diagnostic value. It helps identify not only that something unusual has happened with the SAP business requirements specifications, but also what might be causing it to happen. We found several factors that had a significant impact on the successful integration of the measurement practices into the RE process: • the application of a stakeholder identification method to the SAP project organization. This made sure that all important stakeholders have been captured, and yet that irrelevant actors have not been included.
• the use of ASAP standard processes, deliverables and tools. This significantly shortened the time needed to model the RE process and to spot where in this process measurements could be taken and used. • the use of FP to size the business requirements. Furthermore, main lessons learnt from our experience can be summarized in the following points: • Practicing requirements reuse measurement helps us understand in both qualitative and quantitative terms the role of the pre-defined models in SAP RE. • Reuse measurement data provides an excellent picture of the future-state SAP-based solution before it is implemented. It contributes to the development of more realistic plans for R/3 maintenance, upgrades and releases. The reuse measurement process suggested in this paper could be tailored to the management policies specific to project teams working on the implementation of other ERP packages. In this case, different company-specific or project-specific aspects, for example project communication [20] or level of the RE process maturity [27], might lead to shortening or eliminating of some stages in reuse metrics planning. Basically, the decision for how to handle reuse at requirements level is a riskbased one and depends on the assessment of the risk of having the customization of a standard package out of control versus the costs and the residual risk of each possible reuse handling option. We consider the work reported in this article as only the beginning of an ongoing effort to develop better requirements reuse measurement practices. Future research will include the analysis of the experiences of using the reuse metrics in order to assess the impact of requirements reuse on the ASAP implementation process and the quality of the SAP project deliverables. Our work will comprise the following steps: (i) package and validate the experience with reuse metrics by using product/process dependency models [6], (ii) build a lessons-learnt architecture based on the experience packages, and (iii) develop an approach to evaluating the added value benefits from ERP requirements reuse.
7. References [1]. Banker, R.D., Kauffman, R.: Reuse and Productivity in Integrated CASE: an Empirical Study, MIS Quarterly 15, 3, September, 1991, pp. 375-401. [2]. 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. [3]. Daneva M.: Mesuring Reuse of SAP Requirements: a Model-based Approach, Proc. of 5th Symposium on Software Reuse, ACM Press, New York, 1999.
0-7695-0565-1/00 $10.00 ã 2000 IEEE
[4]. Daneva M.: Deriving Function Points from SAP Business Processes and Business Objects, Journal of Information and Software Technologies, 1999, Accepted. [5]. Daneva M., Empirical Validation of Requirements Reuse Metrics. In preparation. [6]. ESPRIT Project Nr. 23239: PROFES, URL: http://www.ele.vtt.fi/profes, 1999. [7]. Fenton, N., Pfleeger, S.L.: Software Metrics: Rigorous and Practical Approach, PWS Publishing, Boston, MA, 1997. [8]. Garmus, D., D. Huron., Measuring the Software Process, Prentice Hall, Upper Saddle River, NJ, 1996. [9]. IFPUG, Function Point Counting Manual, Release 4.0. Westerville, Ohio, 1994. [10]. Jacquet, J.-P., Abran, A.: Metrics Validation Proposals: a Structured Analysis. In: Dumke, R. (ed.): Software Measurement, Gabler, Wiesbaden, 1999, pp. 43-60. [11]. Jones, C.: Applied Software Measurement, McGraw Hill, NY, 1996. [12]. Jones, C. Estimating and Measuring SAP Applications with Function Point Metrics, Version 2, Software Productivity Research, Burlington, MA, 1998. [13]. Karlsson, E.-A. (ed.): Software Reuse, Wiley, Chichester, 1998. [14]. Keller, G., Teufel, T.: SAP R/3 Process Oriented Implementation, Addison-Wesley Longman, Harlow, 1998. [15]. Lim, W.: Managing Software Reuse, Prentice Hall, Upper Saddle River, NJ, 1998. [16]. Lozinsky, S.: Enterprise-wide Software Solutions, Addison-Wesley, Reading, MA, 1998. [17]. McClure, C.: Reuse Engineering, Prentice-Hall, Upper Saddle River, NJ, 1997. [18]. Melton, A. (ed.): Software Measurement, Int. Thompson Comp. Press, London, 1996. [19]. Morris, P., Desharnais, J.-M.: Function Point Analysis. Validating the Results, In: Proc. of the IFPUG Sprint Conference, IFPUG, Ohio, 1996. [20]. Pfleeger, S.L.: Measuring Reuse: a Cautionary Tale, IEEE Software, April, 1999. [21]. Pfleeger, S. L., Jeffrey, R., Curtis, B., and Kitchenham, B. Status Report on Software Measurement, IEEE Software, March/April, 1997, pp. 33-43 [22]. Poulin, J. Measuring Software Reuse : Principles, Practices, and Economic Models, Addison-Wesley, Reading, MA, 1997. [23]. SAP AG, R/3 System, Business Objects, Walldorf, 1997. [24]. SAP AG, R/3 System Documentation, Walldorf, 1996. [25]. Scheer, A.-W. Business Process Engineering, Springer, Berlin, 1996. [26]. Sharp, H., A. Finkelstein, G. Galal, Shakeholder Identification in the Requirements Engineering Process, In: Proc. of the 1st Intl. Workshop on RE Processes / 10th DEXA, Florence, 1999. [27]. Sommerville, I., Sawyer, P., Requirements Engineering: a Good Practice Guide, Wiley, Chichester, 1997.
