ERP requirements engineering practice: lessons learned - Software ...

3 downloads 31491 Views 254KB Size Report
general.2 First, our top management was strongly committed to all the ERP projects, viewing them as business change initiatives rather than software projects.
focus

requirements engineering

ERP Requirements Engineering Practice: Lessons Learned Maya Daneva, Telus Mobility

tandard off-the-shelf requirements engineering processes have become a key to conceptualizing any integrated, corporate-wide solution based on packaged enterprise resource planning software. A generic RE model offers defined processes, suggests process stakeholders, specifies steps to accomplish tasks, indicates task dependencies, and provides standard tool support for ERP RE. Essentially, any offthe-shelf RE process is about composition and reconciliation: you start with

S

a general set of business process and data requirements, then explore standard ERP functionality to see how closely it matches your organization’s process and data needs. Despite a high adoption rate,1-4 we know little about the issues arising when organizations make the standard RE model a life process, and we know less about how to make such a process work better. Given that RE is any ERP project’s most expensive stage,2,3 this knowledge is not only needed but also vital to the field. Here, I discuss several of these typical issues and their solutions based on our work at Telus

Although organizations implementing enterprise resource planning systems have increasingly adopted generic, off-the-shelf requirements engineering process models, little information exists about the challenges involved. Among the keys to success are planning RE model use in the client’s context and installing processes to support key RE activities. 26

IEEE SOFTWARE

Published by the IEEE Computer Society

Mobility, a Canadian communications company. Between 1997 and 2002, our teams completed 13 ERP projects, including six new implementations, three enhancements, two upgrades, and two process alignment projects due to corporate mergers. We collected RE experiences in the context of developing integrated solutions based on the SAP application suite, a leading ERP software product. We used AcceleratedSAP (ASAP)4 as our RE model and the Requirements Engineering Good Practice Guide5 as the RE maturity framework to systematically assess our projects’ process instances, and thus better understand how an off-the-shelf model becomes a live process. These process assessments let us collect and document facts and observations about RE practices that worked, those that did not, and those that we’d yet to implement. We also learned which practices were most neglected, which were typically skipped and why, and how skipping RE activities affected the final 0740-7459/04/$20.00 © 2004 IEEE

business requirements’ quality.6 After analyzing this information, our lessons, and typical successes and failures, we identified workable solutions for making the generic process model work better in future projects.

Adopting a standard process Although our lessons arise from using a package-specific RE model, our experience is applicable to any RE process in which the following factors2,6 apply: ■









Multiple stakeholders concurrently engineer the requirements and the architecture design to create a solution based on preexisting ERP components. RE teams extensively reuse1 predefined requirement artifacts (such as reference models and templates). Business process modeling drives the RE cycle7 and is the key to acquiring, communicating, and validating enterprise knowledge and business requirements. The organization adopts an architecturecentric approach to manage systems and business changes and to establish and maintain a common information infrastructure across business units. RE teams emphasize consistency in analytical measures, such as systematic selection of common process and data requirements; constructive measures, such as consistent RE methods and tools use; and organizational measures, such as institutionalized quality assurance procedures.4

Because all major ERP providers share these principles,2 any generic model more or less implies this overall process. How effectively an organization adopts the process depends on team discipline, deadline pressures, and the effectiveness of both RE process mentoring and stakeholder interactions. The context in which we adopted the generic RE model is typical of ERP projects in general.2 First, our top management was strongly committed to all the ERP projects, viewing them as business change initiatives rather than software projects. Second, to manage implementation complexity, we divided each project into subprojects based on the number of components to be implemented. For example, the first project implemented six components and thus had six subprojects. We

instantiated the standard ASAP process into a total of 67 subprojects. Third, each subproject had a dedicated RE team. We assigned team members to specific subprojects, and they were responsible for running its RE cycle and delivering the business requirements document for its associated ERP component. Each team included one or two ERP consultants who provided in-depth knowledge in both the off-the-shelf process and the ERP components. Teams also included several business representatives, or process owners— department managers and domain experts who contributed the necessary line know-how, designed new operational procedures that the solution would support, and ensured that the project had the appropriate authority and resources. In addition, a process architect supported all our teams. This person built the solution’s architecture, shared process knowledge, and consulted with team members on requirements reuse, process methods, and RE tools. The architect was the only resource that the teams shared. Finally, our 67 teams worked separately and had relatively little communication, which let us consider and include 67 process instances in our experience study. (We define a process instance as the “singular instantiation of a process that is uniquely identifiable and about which information can be gathered in a repeatable manner.”8) Also as in most ERP projects, the RE schedule was an independent variable.1 We reused the standard ASAP project plan, which recommended four weeks for RE cycle completion. As Figure 1 shows, we modeled ASAP as a spiral with four iterations. In each iteration, we collected information through three main activities: ■

■ ■

How effectively an organization adopts the process depends on team discipline, deadline pressures, and the effectiveness of both RE process mentoring and stakeholder interactions.

Requirements elicitation: finding, communicating, and validating facts and rules about the business Enterprise modeling: analyzing and representing business processes and data Requirements negotiation: validating process and data architectures, resolving process and data issues, and prioritizing requirements

The actors in these iterations are business representatives who are actively supported by external consultants and internal process and data architects. The final deliverable they produce is the project’s business blueprint. March/April 2004

IEEE SOFTWARE

27

Business blueprint Negotiation Figure 1. The ASAP requirements engineering process. Iterations: (1) Map the company’s organizational structure into the SAP package’s predefined organization units. (2) Define a scope for business process standardization using standard application modules. (3) Create a companyspecific business process and data architectures based on predefined reusable reference process and data models.1 (4) Specify data conversion, reporting, and interface requirements.

Level 3

Level 2

Elicitation

Level 1 Level 0

Business scenario and data models

Questionnaires Modeling

Lessons learned Our lessons learned from this experience are easily divided into groups of issues and their solutions: the first three lessons address organizational issues, followed by three lessons related to infrastructure, three related to reuse, and, finally, five lessons related to the process aspects that must be considered when making a standard model a live process.

Organizational aspects of ERP process support Organizational issues refer to stakeholders’ participation and knowledge generation. Any healthy ERP RE team generates and uses knowledge. As stakeholders interact, they absorb information, turn it into knowledge, and take actions—as part of the RE process— based on that knowledge in combination with their experiences, corporate values, project objectives, and business rules. Lesson 1: Reduce barriers to cooperation. In our projects, the amount of process owner involvement was directly related to results: no involvement yielded no results, while passive involvement yielded poor results. In the elicitation workshops for 59 subprojects, for example, we observed that only those process owners who demonstrated interest in the integrated process architecture identified both cross-departmental conflicts and the multicomponent process and data requirements that would likely cause problems when the requirements or the design changed. The subprojects of more passive or skeptical stakeholders routinely overlooked such integration requirements. Our solution: Have RE teams blend the offthe-shelf process into the existing RE practices, analyze the client’s software development culture, and leverage the client’s RE practices. Whenever possible, we tried to use known and proven practices and to raise stakeholders’ awareness of the standard ERP

28

IEEE SOFTWARE

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

RE practices that are critical for project success. In 45 subprojects, these steps were the key to keeping owners involved and engaged in the process. If a team had a good reason for skipping a practice, we made sure that everyone knew about the decision, who made it, and why it was important. This combination of blending practices and creating awareness led to accurate and realistic process outcomes that process owners or external consultants were less likely to override. Lesson 2: Create win-win partnerships. In the first two projects, we lacked a mechanism that let us consistently maintain a win-win relationship between process owners and the external consultants. The result was frustration. In our requirements prioritization meetings, business owners were reluctant to prioritize requirements for fear that the implementers would automatically restrict the project to must-have features and never implement the nice-to-have features. At the same time, consultants were reluctant to ask for priorities because they didn’t want to admit that they couldn’t implement all requirements in the time available. Our solution: ERP RE is a consultative process and should be treated as such. You should thus ensure that stakeholders collaborate on both technical aspects and on how consultations will be carried out. In 10 projects, we found that the easiest way to build win-win partnerships was to make consultants assume collaborative roles.9 We stressed that management issues could be dealt with effectively only by joining consultants’ knowledge of the package with the process owners’ knowledge of the organization. We also established clear paths for collaborative problem solving, giving equal attention to technical issues and the human interactions involved in dealing with them. Lesson 3: Streamline knowledge transfer. Transferring experience from consultants to clients is a core transaction in the ERP RE cy-

cle. The client’s IS staff must learn which process designs the system can implement and what the implications are of changing the configuration. The process owners must design and learn how the system will be used day-today and how it will support the processes that users must carry out. Our solution: Involve individuals with a high learning potential and let them talk to one another. In 61 subprojects, teams accomplished this core transaction using several mechanisms, including ■ ■ ■ ■

Ensuring a balance of domain experts and people who can make decisions Setting learning objectives for the RE team members Using incremental learning techniques Organizing resources into mentor-supported networks

and predefined business objects that represent business-oriented ERP software descriptions and are delivered to clients along with RE tools fully integrated into the package. We suggest that RE teams use the architecture framework to deliver the first blueprint version, which reflects basic requirements and is unlikely to meet with disagreement. However, you should also keep the requirements baseline evolving along with new thinking, new technology, and competition. In all our projects, the architect followed these steps and used models and the SAP architecture concept to gradually incorporate more sophisticated requirements and to systematically address controversial ones. The architecture offered several benefits, including ■ ■

Facilitating the use of common language Serving as a tool for transferring the consultants’ knowledge to internal staff Supporting reference model reuse10 Offering guiding principles for documenting both the current and future configuration of business processes, objects, and relationships among operations and transactions

We also recommended that RE teams directly address organizational maturity, culture, and change by selecting qualified consultants with a proven record in RE process management as mentors.6



Process infrastructure aspects

Lessons 5 and 6: Understand process–tool dependencies and assess potential RE standards use. An off-the-shelf process relies on support tools, tool-specific RE techniques, process methods, and numerous RE standards. However, such tools can only succeed if RE teams use them properly and make them a routine part of the process. Our solution: Lessons 5 and 6 are intertwined and have a common solution—if most ERP RE tools and standards are new to the client’s organization, introduce them in parallel with the RE process. In all projects, we found it practical to

Process infrastructure issues include the role of architecture concepts, RE tools, and standards. With the right process and data architectures, RE tools, and standard procedures, RE teams can produce the business blueprint more effectively and predictably. Lesson 4: Use the vendor’s architecture framework. In the RE process, we had to consciously ensure that we could integrate the solution we were building with the solution we’d already built as well as with future solutions. Failing to evaluate and critique process designs before configuring and transforming them in transaction code was an expensive lesson. Our solution: When possible, stick with the ERP vendor’s architecture approach to better manage requirements complexity and support the reuse-driven requirements modeling exercise. By default, each ERP provider offers an architecture concept that defines their package’s underlying building principles, structures the business reality (in data and process views, at least), and provides conceptual modeling languages for each view’s components.2 It also typically includes reference process models





■ ■ ■

Transferring experience from consultants to clients is a core transaction in the ERP RE cycle.

Make RE teams aware of the dependencies between the process and the support tools and RE standards Select a small subset of all available tools and standards that suited our culture Gain consensus on what tools and standards to use Design scenarios of how to use tools and standards to support specific RE activities

Our scenarios incorporated documentation methods that team members knew and were March/April 2004

IEEE SOFTWARE

29

An ERP RE process begins with reuse, ends with reuse, and includes reuse in every stage.

good at, requirements cross-referencing techniques used in earlier projects, and change management and traceability policies that had proven effective in process owners’ departments. In 65 subprojects, using known practices was essential to selling process owners on the tools and standards. The project manager must, however, balance the cost of tool-consulting services against a tool’s effectiveness in helping RE teams efficiently deliver the business blueprint.

reuse objectives and ERP RE’s action items, and defined a way to measure functional size and reuse aspects of the business requirements, which we represented as business process and data models. To ensure that reuse measurement remained a vital part of the project and made an impact on the RE process, we identified target data-usage patterns. We documented three key aspects of measurement data use:

Requirements reuse aspects



These issues answer the question of how to approach reuse and manage it safely at the requirements level.



Lesson 7: Integrate a reuse measurement process. An ERP RE process begins with reuse, ends with reuse, and includes reuse in every stage. But, surprisingly, such a process lacks a standard reuse measurement approach that lets you plan reuse at all, let alone as part of the RE process.10 Because our process owners were committed to reuse, it was important that we deliver reuse numbers by systematically applying a reuse measurement instrument that was both theoretically sound and practical. We identified five areas that required quantitative support:10 ■ ■ ■ ■ ■

Defining measurable reuse goals and expectations Quantitatively analyzing process and data architecture reuse prior to solution design Assessing the requirements specification Better understanding customization risks early in the RE process Defining the scope of ERP reuse and how it fits into the business environment

Our solution: We established a reuse measurement process as part of the RE process.10 Our process let RE teams systematically adopt or adapt standard reuse counting practices in ERP RE, measure the ERP reuse goals, and indicate the reuse levels targeted at the beginning, and achieved at the end, of each ERP implementation cycle stage. For ERP clients, the main purpose of this process was to learn about their own business and technological opportunities by learning how much reuse is possible in their ERP-supported business processes. We developed a measurement plan that linked the reuse measurement needs to the 30

IEEE SOFTWARE

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



Who needs to read the measurements? What can the measurements help us understand or control? What actions are the measurements likely to inspire?10

Finally, we assessed the benefits of running a requirements reuse measurement process in parallel with the RE activities. We found that measurements contributed to a mature RE process, affected the quality of five RE deliverables (business blueprints, business process models, data models, project plans, and project estimates), focused our decision-making process, improved stakeholder communication, and enforced knowledge sharing practices as part of RE.10 Lesson 8: Assess reuse risks early. Studies suggest that, on average, for any ERP project, few process or data components are reusable at the 80 to 100 percent level.2,3,6,10 You must therefore customize processes, data flows, and components to complete the fit, but doing so without upfront analysis can lead to an overwhelmingly expensive undertaking. This was our most serious lesson. While this simple, upfront practice seems obvious, 35 out of our 67 RE teams violated it. In four projects, customization requirements were signed off without sufficient thought and impact analysis. Poorly mixing fully reused, customized, and newly created requirements resulted in poor transaction code with unexpected and unlocalized side effects. In the long run, two departments that threw away reuse options significantly raised the total cost of ERP ownership because they had to upgrade customizations whenever the vendor upgraded base functionality. Our solution: Make an informed decision about how much ERP functionality to reuse. Identify and assess those business process seg-

ments that are least likely to reuse the default embedded processes. Proceed by collecting information and assessments regarding the risks of losing control of a standard package’s customization versus the costs and residual risk of each possible reuse-handling option. Also, analyze why the RE team resists increased reuse. If reuse measurements are available, use them to focus your analysis of the reasons for low reuse levels. We checked for typical reasons, such as ■



The standard ERP functionality does not sufficiently support the company-specific business processes The target area’s business processes haven’t been standardized across locations

When process owners better understand ERP reuse and customization risks, they’re less inclined toward unnecessary adaptation and will willingly reprioritize requirements. In our case, 48 out of 67 RE teams moved up to 55 percent of the initial must-have requirements to the nice-to-have category. Lesson 9: Validate reuse assumptions. Reusing process and data requirements requires the client’s commitment to the ERP package’s default processes, integrated data flows, and datasharing mechanisms. Failing to understand this makes projects especially vulnerable to extraordinary customization. This often occurs when process owners have internally developed applications serving as bridges between systems, in which users control the access to each bridge and determine when and how systems share data. Because process integration is typically an ERP implementation’s underlying principle, the new solution absorbs the data and users lose control over its flow. In 13 subprojects, our RE teams failed to decide early enough whether to accept the assumptions about default data-flow reuse. In later project stages, the process owners requested extraordinary reprogramming to customize ERP modules because they felt uncomfortable making hasty decisions about how their management approaches fit into the default processes. This completely defeated the benefits of adopting an integrated solution in the first place. This was our second most serious lesson. Our solution: Address business process and data standardization early in requirements elicitation meetings. In 43 subprojects, standardization levels were determined, documented, and

signed off on as part of the business blueprint. We also expressed standardization levels quantitatively using reuse metrics data.10 Such measurements clarified how much reuse each business process could take. The RE teams also used the metrics to understand which process and data requirements were harmonized and rigid, which were flexible, and which were volatile.

Process aspects These issues focus on the practices that an RE team should install to support the key activities of requirements elicitation, documentation, and negotiation.

We defined requirements verification as the process that confirms that the requirements are technically implementable.

Lesson 10: Systematically validate and verify requirements. We witnessed a natural tendency among teams to improve RE speed by shortchanging validation activities. This can be a particularly unfortunate decision: In 17 subprojects, insufficient validation efforts led to the unnecessary implementation of complex functionality; in another 10, the teams did not realize conflicting business drivers early enough, which made it difficult to meet the demand for higher-quality requirements and better control in early project phases. They also overlooked critical technical issues, such as how many separate system instances or versions to install. Our solution: Make everyone aware of how validation and verification (V&V) are defined. We used an existing definition of requirements validation as the process that ensures that business requirements clearly describe the target solution.5 We defined requirements verification as the process that confirms that the requirements are technically implementable and that the resulting architecture design satisfies the business requirements. Several related solutions address V&V. First, if the process architect is an experienced ERP modeler, the most efficient V&V strategy is to bring in an ERP process-engineering tool. We invested in one package-compliant tool, which the architect used to ■ ■ ■

Rapidly customize the reusable process models Automatically map the business requirements onto the reusable physical transactions Carry out animated process walkthroughs with stakeholders

The tool also helped our process owners work March/April 2004

IEEE SOFTWARE

31

A reliable and cost-effective way to confront leakage is to use existing architecture artifacts, RE tools, and standards.

together effectively, model business rules, automatically analyze those rules for logical errors, and test the rules against business-defined scenarios. Second, organize structured process validation walkthroughs (with or without tool support). Our architect facilitated these formal meetings and process owners actively participated, confirming how the system was supposed to work in their departments. In all projects, walkthroughs assured synchronization between business requirements and architecture design. Third, document the rationale for requirements.11 Doing so let 39 out of our 67 teams eliminate as much as 43 percent of the stated requirements. Finally, use prototypes for validation only if you also do process walkthroughs. In three subprojects, we observed a tendency to rely exclusively on prototypes to negotiate requirements, which led to prototyping spirals in which the teams never built the actual solution. Lesson 11: Involve a data architect. Some offthe-shelf processes, such as ASAP, might not require conceptual data models as mandatory project deliverables. This can easily become an excuse to not use a data architect in the RE process. Three projects slowed down in the design stage due to insufficient data specification, modeling, and conversion planning in the RE stage. Our solution: Plan and budget for data analysis as part of RE. In 49 subprojects, three key RE deliverables were critical to successful conversion: an entity-relationship data model (including a data dictionary), a conversion plan, and an interface specification. All three required a qualified data architect. We also found Norbert Welti’s suggestion7 to set up a conversion and interfaces handbook useful. Our handbook used the three key deliverables as input and described the conversion steps in detail. You should have such a handbook ready by the RE cycle’s end, and ensure that the only outstanding work is the conversion run to the production system and the process owners’ data check. Lesson 12: Use a modeler with expertise in the ERP package, its modeling methods, and the client’s business processes. Seventy percent of our external consultants thought modeling was labor-intensive and considered it bureaucratic

32

IEEE SOFTWARE

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

overhead. Faced with hectic modeling, the RE teams on smaller subprojects often viewed “smallness” as an excuse for not following the reuse-driven modeling practices.6 Our solution: To get the full benefits of the RE documentation methods and tools, support the project team with a full-time requirements modeler who has experience designing business processes in the client’s cultural context. Using the architecture framework as a foundation for requirements modeling ensured that our RE teams got sufficient support. The reference models helped us clarify how data flows through business areas and how various departmental functions interact. Because the models made all process disconnects visible, the teams could effortlessly identify areas for business process optimization. Moreover, modeling and thinking with the process owners helped us manage business expectations. If architects and consultants fail to manage expectations, they lose credibility with the business representatives. Lesson 13: Devise practices to prevent requirements leakage. Each RE team witnessed requirements that originated from unofficial sources. These varied from 5 to 43 percent, and rendered the process inefficient. In 12 subprojects, creeping seriously affected the quality of the resulting requirement documents: signed-off specifications varied considerably in terms of consistency and completeness.6,10 These risks were invisible until later project stages and resulted in rework. Our solution: When a leakage problem arises, prompt actions must be taken. A reliable and cost-effective way to confront leakage is to use existing architecture artifacts, RE tools, and standards. We found that two practices often occur together and are at least strongly associated: ■



Stating some standard criteria for completing the business blueprint and getting stakeholders to accept them Using reference models to monitor scope and check traceability through the artifacts

In the latter case, our experience confirmed that reference models efficiently remove various requirement defects and reduce creeping.1 We also used the models to minimize developers’ tendency to add exotic features.

About the Author

At the project’s start, consultants also install tools for clients that can be extremely helpful in reducing creeping. For example, we took advantage of the standard questions-and-answers database to maintain links between what was asked and answered in the requirements elicitation sessions. We used the database to aid discussions about unanswered requirements and clarify which additional (usually reporting) requirements have been added directly, without a corresponding request in the blueprint. This capability increased process owners’ confidence in the approach. Lesson 14: Analyze the impact of change. Sadly, most attempts to adopt a generic RE process that end in disaster might have succeeded if their RE teams incorporated one of the most important RE activities: change impact assessment. Surprisingly, ASAP and several other off-the-shelf process models fail to include this essential practice.2 When an RE process lacks a mechanism for assessing requirements changes, process owners typically ignore the need for impact analysis and consultants often agree to suggested changes without carefully analyzing the implications. This situation occurred in 59 subprojects. In seven cases, we learned our third most serious lesson: Some changes were ultimately more complex than anticipated, and took between 80 and 140 percent longer than promised because implementing the change affected more system components than we expected. Our solution: Dealing with changes requires an explicit focus on what process owners need to accomplish their daily tasks, why they need it, how they use information, what problems they experience with the existing system, and what must be changed. Incorporate a process that lets process owners identify business and system impacts and training or retraining needs, and that lets consultants estimate configuration efforts, costs, and customization risks. The teams should also investigate how change affects integration with other ERP modules. Some basic settings cannot be changed later on, so it’s important to ensure that a change does not impede module integration and that process owners from other departments do not use information from the target modules. In 31 subprojects, mastering these simple steps helped us complete blueprints on time and within budget.

Maya Daneva is a business process analyst in the Architecture Group at Telus Mobility, Toronto, where she consults on ERP requirements engineering processes, SAP reference models, architecture reuse, and process methods and tools. Prior to this she was a research scientist at the Institute fuer Wirtschaftsinformatik, University of the Saarlandes, Saarbruecken, Germany. She received her PhD in computer science at the University of Sofia and the Bulgarian Academy of Sciences. Contact her at Telus Mobility, 200 Consilium Place, Suite 1600, Toronto, Ontario M1H 3J3, Canada; [email protected].

U

nderstanding and optimizing the mechanics behind a standard RE process on a practice-by-practice basis is what ERP RE process adoption is all about. Because it arises out of a sophisticated process model, instantiating a standard process requires planning and thinking to produce satisfactory results. The key is to plan how to use standards, process methods, tools, and procedures in the client’s organizational context, and to install explicit supporting processes to streamline the key RE activities of elicitation, modeling, and negotiation. Our experience highlights issues that are apparently common when running a standard process in a relatively immature organization that operates in a dynamic business environment. The solutions we suggest are useful and intuitive. RE practitioners who address these issues are likely to generate more effective and mature RE processes—with more predictable results and better visibility—when using a generic off-the-shelf RE model.

References 1. T. Curran and A. Ladd, SAP R/3 Business Blueprint, 2nd ed., Prentice Hall, 2000. 2. T. Davenport, Mission Critical: Realizing the Promise of Enterprise Systems, HBS Press, 2000. 3. C. Holland and B. Light, “Success Factors Model for ERP Implementation,” IEEE Software, vol. 16, no. 3, May/June 1999, pp. 30–36. 4. G. Keller and T. Teufel, SAP R/3 Process Oriented Implementation, Addison-Wesley, 1998. 5. I. Sommerville and P. Sawyer, Requirements Engineering, A Good Practice Guide, John Wiley & Sons, 1997. 6. M. Daneva, “Using Maturity Assessments to Understand the ERP Requirements Engineering Process,” Proc. Joint Int’l Requirements Eng. Conf., IEEE CS Press, 2002, pp. 255–262. 7. N. Welti, Successful SAP R/3 Implementation, AddisonWesley, 1999. 8. K. El Emam and A. Birk, “Validating the ISO/IEC 15504 Measure of Software Requirements Analysis Process Capability,” IEEE Trans. Software Eng., vol. 26, no. 6, 2000, pp. 541–566. 9. E. Gottesdiener, “Requirements by Collaboration: Getting It Right the First Time,” IEEE Software, vol. 20, no. 3, May/June 2003, pp. 52–55. 10. M. Daneva, “Practical Reuse Measurement in ERP Requirements Engineering,” Proc. Int’l Conf. Advanced Information Systems Eng. (CAISE), LNCS 1789, Springer-Verlag, 2000, pp. 309–324. 11. N. Maiden and C. Ncube, “Acquiring COTS Software Selection Requirements,” IEEE Software, vol. 15, no. 3, May/June 1998, pp. 46–56.

March/April 2004

IEEE SOFTWARE

33