Defining Goals in a COTS-Aware

Requirements Engineering Approach

Lawrence Chung
Dept. of Computer Science
The University of Texas at Dallas
MS EC 31 P.O. Box 830688
Richardson, TX, USA
/ Kendra Cooper
Dept. of Computer Science
The University of Texas at Dallas
MS EC 31 P.O. Box 830688
Richardson, TX, USA

Abstract. The goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and researchers to investigate software engineering methodologies. In requirements engineering, the focus has traditionally been on modeling the software engineering process and products for systems that are being built from scratch. As the size and complexity of systems continues to grow the use of commercial off the shelf (COTS) components is being viewed as a solution. Effective use of COTS components, however, requires a systematic approach that provides both a set of concepts for modeling the subject matter and a set of guidelines for using such concepts. In particular, the process needs to recognize and address the people oriented problems including the identification and resolution of conflicting goals, bridging the gaps between stated requirements and 'approximately fitting' components while still satisfying the customer. In this paper, we present a goal and agent oriented requirements engineering process model that explicitly addresses the use of COTS components. More specifically, we present (part of) our model for a COTS-Aware Requirements Engineering (CARE) process and illustrate it using a Digital Library System.

1Introduction

In Software Engineering, researchers strive to improve the tools and techniques used to deliver high quality, large-scale systems that are on time and within budget. More specifically, the benefits of improving these tools and techniques include reducing the time to market, engineering time, development cost, defects, code size, product documentation, and the impact of personnel changes through the definition of clearly defined models. In addition, as software engineering techniques are improved, the consistency of applying a technique and customer service are also improved.

The use of commercial off-the-shelf (COTS) components is perceived as a means to deliver large, complex systems, potentially with significant improvements in quality, development time, and cost. Effective use of these components, however, presents both opportunities and risks. COTS components, on the one hand, can lead to the perceived benefits, since they are pre-packaged solutions which presumably have already gone through the various time-consuming and costly phases of requirements specification, design, coding, and well tested through use over time. On the other hand, COTS components can also lead to quite the opposite of their perceived benefits. They may poorly satisfy the stakeholders’ requirements, evolve rapidly or be discontinued by a vendor, have unexpected interactions, lead to the late discovery of errors in the system and as a result lead to significant rework or perhaps even the cancellation of the project, etc. But, why?

Ideally, the components have been used by a substantial number of customers and gone through a number of development iterations, reducing the defects in the product. At the surface level, the problem of using COTS components seems straightforward: the developers need only select the components and integrate them together like “lego” blocks. At a deeper level, however, there are many inter-related technical, legal, and business issues involved in effectively using COTS components. Technical issues, stemming from the complexity of the COTS components themselves, include how to represent the COTS components, select components that provide the functional and non-functional characteristics needed, identify incompatibilities among the components, integrate the components together, utilize rapidly evolving components, and replace discontinued components in a continuously evolving system.

The evolution, or maintenance, of a COTS based system is of particular concern. If a COTS software package is procured during the early development phase of a program, then it is likely that the next generation of the component is released sooner than the next generation of the system. Invariably, when errors are discovered, greater performance is desired through an evolution of requirements or other subsystems must be accommodated, the software must be maintained many years beyond the COTS original version. The supplier of the COTS component may not be in business or may be unwilling to provide maintenance for such long periods of time.

Technical issues also arise from the complex interactions between systems and their environments [Anton, 1998], [Yu, 2001], [Wooldridge, 1999], [Wooldridge, 2001]. For example, systems are not only distributed, but the distributed components are operated by independent organizations with different business goals, strategies, etc. The systems have numerous stakeholders, or agents, each with goals that may conflict or be synergistic with other stakeholders' goals. For example, one group of stakeholders may say "the security of the system should be of the utmost concern", while at the same time another group may say “the system should be as easily changeable as possible, and that should be the top priority”. To successfully deliver these complex systems, the software engineering process needs to support identifying the agents and their goals, exploring and documenting potential alternative configurations, and negotiating the conflicts that arise from this activity.

Along with the task of defining the goals and requirements of the system, the availability of suitable COTS components must be considered throughout the requirements engineering process, as it may constrain the goals and requirements for the system. This is significantly different from a standard software development lifecycle where the requirements for the system under development are gathered, analyzed, revised, and baselined without regard to which requirements may, or may not, be delivered to the customer using COTS components. When the software development process is using COTS products, however, the process of developing the requirements must change, i.e., by considering the capabilities of available COTS products as the goals and requirements are defined and negotiated.

The use of COTS products also impacts the architecture, or high-level design, phase of the software development lifecycle. In a standard software development lifecycle, the architecture is developed to fulfill the requirements of the system without regard to the availability of COTS components. In order to use COTS components, however, the requirements and/or the architecture may need to be significantly modified (causing delays and an increase in cost) since there may be few, or even no, available components that fit within the requirements and/or the chosen architecture [Brownsword, 2000], [Brownsword, 1998]. Nonetheless, the architecture should be developed while defining the requirements and also while considering the constraints of available COTS components in such a way that the requirements specification and architecture for a system meet the customer’s needs and optimize for the use of COTS components.

From a business perspective, the issues involve the short-term and long-term costs and benefits of using COTS components. Project managers need to consider the cost of the components, quality of the vendor, lack of control over the support and evolution of the COTS components, licensing issues, and the associated risks.

Effective use of COTS components, thus, inevitably requires a well-disciplined systematic methodology that would facilitate the exploitation of the benefits of COTS components while guarding against the pitfalls of such components. The goal of this project is the provision of such a methodology, called COTS-Aware Requirements Engineering (CARE), during the Requirements Engineering phase. CARE is both goal oriented (as in [Anton, 1998], [Chung, 2000], and [van Lamsweerde, 2000]) and agent oriented (as in [Yu, 1994], [Wooldridge, 1999], and [Wooldridge, 2001]). The CARE approach, intended to assist the requirements engineer, but not to replace their intelligence and experience, is described with a process, product, and a meta-model. The process model is the focus of this work. In particular, due to space limitations, here we present only part of the process model that supports the definition of system goals and demonstrate its use with a Digital Library System (hereafter, DLS) application. A more complete description is available in the complementary technical report [Chung, 2002a].

This paper, an extended version of the work presented in [Chung, 2002b], is organized as follows. Following the introduction, we present related work in Section 2. In Section 3, we present an overview of the CARE approach followed by a more detailed description of part of the CARE process model that supports the definition of system goals. The CARE approach is illustrated with an example from a DLS in Section 4. Conclusions and future work are in Section 5.

2Related Work

The CARE approach draws upon research in a number of areas including agent- and goal-oriented paradigms, knowledge engineering, process engineering, and COTS based software engineering work. In this section, we discuss other COTS research. In the future, we are going to also draw upon recent research in bridging requirements and architecture models such as [Egyed, 2001], [In, 2001], and [Nuseibeh, 2001] as we plan to extend the CARE approach to consider the concurrent development of architecture and requirements models.

A significant body of investigative work that identifies issues and/or proposes a classification or framework for pursuing further research has been presented [Basili, 2001], [Beus-Dukic, 1998], [Braun, 1998], [Brownsword, 2000], [Brownsword, 1998], [Dean, 1999], [Maiden,2002], [Voas,1998]. The issues involved with developing a complex system with COTS components are extensive; they impact the requirements, architecture, implementation, testing, maintenance, COTS selection and evolution, project management, cost estimates, licensing, etc. These issues have been categorized as technical, legal, management, business, and strategic concerns.

As work has progressed in the area of COTS research, specific solutions have been proposed to address some of these issues. Recently, solutions to the problems of how to evaluate [Addy, 1998a],[Brenner, 2001],[Briand, 1998], [Korel , 1998], [Morisio, 1997], [Morris, 2000], describe [Addy 1998b], [Addy, 1999], [Morisio, 2002], [Yen, 2002], [Yen, 2001], select [Briand, 1998], [Hissam, 2002], [Illa,2000], [Kunda, 1999], [Morisio, 2002], [Morisio, 1997], [Seacord, 2001], and integrate [Hissam, 2002],[Seacord, 2001], [Yen, 2002], [Yen, 2001] COTS components have been proposed in the literature. Issues related to testing [Hissam, 1999], [Hissam, 1998], and maintaining [Carney, 2000], [Hybertson, 1997], [Vidger, 1998] COTS intensive systems have also been presented. From a project management perspective, an estimation model for the economic life-span of systems using COTS components is described in [Abts, 2000], the cost of using COTS components is addressed in [Erdogmus, 1999], [Hall, 2001], [Jensen, 1997], [Voas, 1998], [Voas, 2000], and an approach considering the risks associated with the use of COTS has been proposed in [Ballurio, 2002].

Here, we discuss some of the approaches that offer specific technical solutions that are applicable to the early phases of Software Engineering: Rational Unified Process (RUP), Model-Based Architecting and Software Engineering (MBASE), Procurement Oriented Requirements Engineering (PORE), and Off-The-Shelf Option (OTSO). We recognize this survey is not exhaustive.

RUP is a comprehensive, object oriented software engineering process model [Jacobson, 1999], which is based on four phases (transition, construction, elaboration, and inception) and a collection of core process disciplines (or workflows) including business modeling, requirements, analysis and design, implementation, test, deployment, etc. We include the RUP in our survey because it is an established, well accepted process. Although the RUP is not goal- or agent-oriented, it does support the use of a component based architecture. A component is defined in [Krutchen, 2001] as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture. In the unified modeling language (UML), a COTS component is represented as a component, a physical and replaceable part of the system that provides a set of interfaces and typically represents the physical packaging of classes, interfaces, and collaborations [Krutchen, 1998]. With the RUP, the use of component based architecture can proceed in several ways. In addition to supporting a more traditional approach in which a system is built from scratch, RUP also supports building a system with the intent of developing re-usable, in-house components and an assembly approach of building software from commercial off-the-shelf components. The RUP supports a component approach in a number of ways. The iterative approach allows developers to progressively identify components and choose the ones to develop, reuse, or buy. The structure of the software architecture describes the components, their interactions, how they integrate. Packages, subsystems, and layers are used during analysis and design to organize components and specify interfaces. Single components can be tested first followed by larger sets of integrated components. For our requirements engineering work, we integrate the iterative approach in our process. When CARE is extended in the future to include the architecture model, additional aspects of RUP are going to be integrated.

The Model Based Architecting and Software Engineering (MBASE) approach focuses on the early phases of software engineering. It considers four types of models: success, process, product and property [Boehm, 1998] and is consistent for use with COTS components [Boehm, 2000]. MBASE uses four guiding principles to develop value-driven, shared-vision-driven, change-driven, and risk-driven requirements. From the MBASE framework, we draw on the ideas of developing a consistent set of models that are goal (i.e., success) driven and support the use of COTS components. In addition, we also use the tabular format presented in MBASE examples for our product model.

From the Procurement Oriented Requirements Engineering (PORE) technique, we draw on its support for the iterative evaluation and selection of COTS components [Maiden, 2002], [Ncube, 1998]. The PORE process model identifies four goals in a thorough COTS selection process: a) acquiring information from the stakeholders, b) analyzing the information to determine if it is complete and correct, c) making the decision about product requirement compliance if the acquired information is sufficient, d) selecting one or more candidate COTS components. The PORE approach also defines a meta-model that is composed of the following constructs: agents, actions (these are performed by agents), events (these trigger actions), goals (these are accomplished by actions), objects in the domain, state of an object, state transitions of objects, components, and functions provided by the product.

The Off-The-Shelf-Option (OTSO) proposed by [Kontio, 1995] method provides specific techniques for defining evaluation criteria, comparing the costs and benefits of alternative products, and consolidating the evaluation results for decision making. The definition of hierarchical evaluation criteria is the core task in this method. It defines four different subprocesses: search criteria, definition of the baseline, detailed evaluation criteria, weighting of criteria. OTSO recognizes the lack of attention to requirements as a key problem in COTS selection, but does not provide a specific solution. The method assumes the requirements exist; they are used to define the evaluation criteria.

3The CARE Approach

The CARE approach draws upon the good ideas available in current RE methodologies including RUP, MBASE, and PORE. The aim is to complement and extend these methodologies in order to provide a requirements engineering methodology that is agent- and goal-oriented, and explicitly supports the use of COTS components. We realize that developing a complete methodology that supports the use of COTS is a large, complex problem. We are taking an iterative approach to systematically develop CARE. Our current focus is on developing a set of models that provide a foundation for the research; the goal is to define a methodology that supports the definition and selection of COTS components from a technical view. In practice, technical aspects cannot be used in isolation from other considerations such as risk management, maintenance, etc. to select the components. The current work addresses these related issues in a preliminary manner; in the future the CARE models are going to be extended to consider the project management aspects in greater detail. Here, we provide an overview of the CARE approach followed by a more detailed description of part of the CARE process model that supports the definition of system goals.

The CARE approach is being developed using a set of examples for a DLS. In this description of the model, the customer is contracting the development of a large-scale system and is involved in the development work. Variations of this model can be developed in the future to consider high volume, shrink-wrap product development.

3.1Overview of CARE

The CARE approach is characterized as agent-oriented, goal-oriented, knowledge based, and has a defined methodology, or process. A high level view of the CARE approach is illustrated in Figure 1. On the right side of the figure, the early artifacts for the system under development are accounted for including the agents, softgoals (non-functional goals that are achieved not absolutely but in a “good-enough” sense), hardgoals (functional goals), system requirements, software requirements, and architectural elements. The traceability relationships among the artifacts are also established and maintained (e.g., a softgoal is refined and traced to specific system requirements). On the left side of Figure 1 the descriptions of the COTS components are stored and maintained in a knowledge base, or repository. For each COTS component, the high-level goals (softgoals and hardgoals) and the chosen product specifications which meet the goals are stored and maintained. The goals provide high-level descriptions of the capabilities of a COTS component; they contain information like that found on marketing brochures for existing products. These general descriptions provide enough information, at least initially, for a RE to determine if the product appears to be potentially useful and, as a result, warrants further investigation. A product specification is the detailed description of the functional and non-functional characteristics of the projected system, including its components and relationships between the components, which, as a means/solution, meets the (potentially conflicting) goals and constraints of the various stakeholders, technical constraints, laws, etc. [Davis, 1993] [Loucopolos, 1995]; they contain information like that found on the technical product specifications or data sheets for an existing product. When using the CARE approach, the RE identifies possibly matching COTS components for the goals and subsequently, the requirements and architectural elements of the system under development; these mapping relationships are also established and maintained.