Functional matching in COTS-based development ... - Semantic Scholar

Functional matching in COTS-based development context Thanh Loan LE and Colette ROLLAND University Paris 1- Sorbonne UFR27, CRI 90 rue de Tolbiac, 75013 Paris [email protected], [email protected]

Abstract: Requirements engineering in the context of off-the-shelf component-based system development is a difficult issue. Most actual approaches are not requirements-driven, which does not allow to gain a great customer acceptance. Otherwise, they have difficulties getting a natural matching between customer requirements and component features, which does not facilitate the user involvement. The paper extends our former thoughts on an approach that is requirements-driven and is featured by a systematic way-of-working for system requirements elicitation, COTS candidate products' features discovery, and last but not least, a rigorous reasoning on the matching matter. The overall process is helped with map usage, the new representation system that we believe useful for a natural reasoning. Keywords: map, intention, strategy, section, pre-condition, post-condition, matching, requirements engineering, component-based development.

1. Introduction In recent years, reuse has been claimed to be one of the most promising approaches to enhancing productivity and software quality [Tracz 88], [Frakes 93], [Lim 98], [Griss 97], [Bassett 97]. Building applications from the ground up is time consuming and non-efficient, it does not allow to widely reuse working experience. Procuring and reusing commercial off-the-shelf (COTS) components, resulted from the component-based development paradigm, offer significant improvements: reduced development effort and cost, shorter development time, increased system stability, higher number of alternative solutions (trends “open systems” required by customers) and increased level of system interoperability [Prieto-Diaz 93], [Lim 94], [Laplante 99]. Current approaches for matching requirements and components make extensive use of classified component library [Semmak 98], they start from the latter to find the best fitting ones to meet requirements, aligning thus requirements with any assumption about design and architecture choices, business processes, organisational structures, methodologies... made in these components. In fact, component libraries are usually built upon a representation model that is more or less formal. Each component is locally described by means of predefined controlled vocabulary, so the customer has to adopt the supplier's vision [Prieto-Diaz 97]. This is prevalent since customers express their needs more easily in natural language and expect their requirements to be satisfied with as few modifications as possible. They prefer to maintain the same business processes, organisational structures ... as well as their usual computer usage. Customer and supplier have to meet somewhere in the middle by combining their different visions. In reality, building software seems harder than it ought to be. It takes longer than expected, the software's functionality and performance are not as wonderful as hoped. One of the reasons for software projects crisis in mid-90s was the lack of user involvement, poorly stated or incomplete requirements among others [Johnson 95], [Gibbs 94]. Most maintenance efforts involve providing required, but actually missing functionality [McGraw 97]. The requirements engineering has been justified as predominant for the development success. It gets even more

involved in the context of COTS components based systems. First, to be reusable, components have to be generic and thus, to be built with variations in order to cope with the various specificity of problems at hand. Secondly, to understand which variation is required, it is necessary to match the features provided by the components to the customer requirements. Besides, it is rarely the case that components can be immediately operational and customer requirements get satisfied without a business process reengineering, as shown in ERP systems deployment practices [Lequeux 99], [Alvaro-Diaz 00]. Thirdly, several system requirements in COTS-based development will only become known after initial products evaluation and integration [Finkelstein et al 97], [Vigder 97], let alone the additional requirements imposed by components on system functionality and performance that are usually unforeseen. Almost all the current COTS-based systems development methods including OTSO [Kontio 95], CISD [Tran & Liu 97], IIDA [Fox et al. 97], IusWare [Moriso & Tsoukias 97] and Feature Analysis [Kitchenham 96] do not adequately deal with the problems of requirement acquisition. Those that recognise the problem of requirements do not offer or propose any solutions, but focus on the product evaluation/selection process. A comprehensive survey of these ones was done by C. Ncube [Ncube 99a]. Ncube's PORE approach [Ncube 99a][Ncube 99b] aims to overcome these shortcomings, it provides an iterative process as well as a goal-based multilayered guidance and various detailed templates to guide the requirements engineering process. Generally speaking, besides process models and systematic guidelines, these are main issues that requirements-driven methods should address to: - Representation system: How to commonly represent customer requirements and software components' features? In other words, how to combine customer's vision and product supplier's vision? Difficulties, current solutions as well as our proposition for this issue will be discussed later in the paper. - Retrieval: What is meant by saying a component matches one another? What are evaluation criteria? How to measure different matching levels in computing similarity? Can it be done automatically or semi-automatically? From the requirement point of view, a component matches one another when it satisfies the same goal whereas a designer would say that they have to exhibit compatible static models and dynamic behaviours, a programmer would say that they have compatible signatures. It has been proved that specification of dynamic behaviour more precisely characterises the semantics of a component than just its static model, though it is built upon this one, which describes the type information [Chen 93]. An abstract goal can be considered as a functional component, behaviour matching is therefore more concerned in goal-driven requirements engineering. Besides, it is rarely the case that we can procure a component that matches exactly customer requirements as shown in ERP deployment practices [Alvaro-Diaz 00][Lequeux 99]. Most deployment efforts involve adapting provided but mismatched or required but missing functionality. Software products have not been able to do as hardware products have yet. Different relaxed matches are thus needed, they capture the notions of generalisation, specialisation and substitutability of software components. A common approach for this in many organisations is an approach that can be called the weighted scoring method (WSM). In this approach, criteria are defined and each criteria is assigned a weight or a score. There are several shortcomings in this approach and it is questionable whether WSM can represent true preferences between alternatives [Kontio 95]. OTSO method relies on the use of the Analytic Hierarchy Process (AHP) for consolidating the evaluation data for decision making. - Reuse: How to reuse selected components? What changes are needed? Which constraints they impose on customer requirements and global architecture of a system?

Selected products, as stated above, are rarely immediately operational. Changes needed to adapt these products to organisational context - adding, modifying or removing types and/or functions - should be documented to facilitate design and deployment phases. This issue is usually missing in current approaches, since these pay more attention on requirements/products acquisition and matching process. PORE and OTSO consider COTS components as black boxes so they do not deal with adaptation issues. This paper is about requirement engineering for COTS component based system, and the role that a suitable specification system can play in making requirements engineering, components procurement/matching assessment easier and in gaining more customer acceptance. We lay down a foundation to representing component features as well as real world requirements, including both static and dynamic aspects, and different kinds of semantic matches for dynamic behaviour. [Jolita 00] provides a comprehensive mechanism for similarity evaluation and transformation operators applicable to elements of static model. This paper extends our thoughts presented in a previous paper [ROLLAND 99], in which we viewed the requirements engineering process for COTS-based system development as a process that iteratively fulfils four key goals: (a) Construct As-Is Map, (b) Construct To-Be Map, (c) Construct COTS Map and, (d) Integrate Maps. The iterative dimension is justified by the very nature of this paradigm of software development in that system analyst has to find out a consensus between customer requirements and multiple existing solutions. Along with emphasis on a more rigorous reasoning on (d), a systematic and methodological guideline is also provided for all the four sub-processes. To allow an easy understanding, we will recall in the next section the notions of the new representation system named map and apply it to express system requirements by means of an example. Section 3 shows how component suppliers can use map for featuring components. Process guidance for assessment and integration is also provided in section 4 with different matching variations, always illustrated by the same example. Conclusions and suggestions for further work are presented in section 5.

2. MAP for system requirements Requirements elicitation involves functional and non-functional issues (architecture, implementation, deployment, QoS- related such as external interface, performance on processing power and resource consumption, standards compliance, security...) of the system to develop. In the context of COTS based development, that concerns also the maintenance, technical support from component suppliers, upgrade and evolution issues. In the first place, we've limited ourselves to the functional aspect. In this section, reasons for a suitable representation system are given, followed by our solution which consists of a new representation system for requirements specification named map. The idea is then illustrated using a case study of an e-commerce application. The proposed solution aims to address system requirements engineering in the context of COTS based development, providing an intermediate bridge between customer's vision and software products' suppliers.

2.1. Rationale for a suitable representation system In current practices of requirements engineering, it is true that natural language is the easiest way for expressing requirements but a graphical notation is obviously more intuitive and convenient way of showing a set of statements. Given a graphical notation, there is always an equivalent text representation. It makes clear the relationships between concepts and gives a way to be precise. In fact, anyone who has had to explore voluminous textual documentation would find it rather

fastidious and confusing. For complex component or system, it may be easier to do it pictorially. Moreover, semi-formal or formal representation systems have been proven necessary to allow automatic checking and validation [D'Souza 98]. Since software development is an incremental process that starts from the most vague, incomplete perception of the future system to a precise, complete and consistent one, in which different stake-holders get involved such as end users, IT staff, corporate managers, system analysts, designers and implementers, a unique representation language will not be suitable. It would be helpful to provide various representation languages of various levels of formality and complexity at different stages of development, informal ones facilitating understanding whereas formal ones enabling automatic and systematic consistency validation. Reuse software artefacts can refer to design reuse and code reuse. In COTS-based software development, components procurement aims for the latter, selecting components that "satisfies", "meets", or "fulfils" a functional requirement. There is thus the need to characterise the dynamic behaviour of each software component. Moreover, suppliers want to show up their products' generality and added-values, so they need a representation system that allows them to flexibly specify various possible combinations of reuse contexts, in terms of static model as well as dynamic behaviour. There is not a comprehensive and consistent specification system for component features nowadays. Component suppliers specify their functions in a modular fashion either at a very high level of abstraction with somewhat proprietary representing assets: text, diagram, screen snapshot... either at a low level of abstraction that deals with deployment details using UML constructs, API listings... that does not allow to capture a global functional view and therefore is not suitable for the process of features discovery and requirements matching. Component libraries, on the other hand, organise these ones mainly for retrieval purpose in response to some queries. Components' functionality is described in terms of operations at implementation level. Current models used in these libraries such as faceted model, enumerated model, hypertext network model...[Frakes 97] appear to be poor since they do not deal with the notions of reuse alternatives and as such, not suitable for evaluation purpose. OTSO provides guidelines for searching for candidate components and encounters the same difficulties when dealing with these differently specified components that comes from various sources. Catalysis makes use of UML-syntax diagrams to specify static and dynamic features of components, but it does not take into account the notions of organisational goals [D'Souza 98]. PORE's product model deals with three parts of software products: observable interactions with external environment, articulated goals and architecture issue [Ncube 99a]. PORE makes explicit the role of abstract goals and goal decomposition into alternative combinations. Product and supplier information collected from questionnaire responses helps develop reusable spreadsheets for each component, which is the main support for matching evaluation and decision making process. Again, this representation gives only a local vision of the component, but not its vision in the reuse context. On the contrary, customers like to express high level requirements in terms of organisational tasks and strategies. They do not want to deal with too low-level features such as screens and data structures. Customers want to have a global view of the future system, in which different components co-operate to fulfil organisational goals. They are interested in setting the context in which the suitable assembly of components will be used instead of focusing on products features. When procuring a COTS software component, the main concerns are that whether it can provide an IT solution to organisational tasks with as little modification as possible and whether it is flexible and generic enough to support different and changing requirements. With current component libraries, customers are constrained to express their requirements in terms of controlled vocabulary of these libraries, which depends mainly on design features. OTSO views

requirements as a hierarchical criteria set and represents them using templates [Kontio 95]. Catalysis adopts the same representation system for component specification and real world modelling. PORE proposes the use of various current techniques to elicit and acquire customer requirements such as brainstorming, interviews, scenario analysis, and card sorting...

2.2. Solution Given the difficulties experienced from current practices and demands for a common representation system to specify both requirements and software features, we have defined these following objectives for our solution: 1. Provide a way to commonly represent customer requirements and components' features that, on one hand, allows customers to specify their requirements in terms of organisational tasks and strategies to perform them, on the other hand, permits software suppliers explicit their products' generality and adaptability. 2. Requirements should be specified in a comprehensive, coherent fashion that depicts an operational view of what a system should do in a global and strategic perspective. The global dimension allows a global view of the system in which components are integrated and seamlessly co-operate to fulfil the final goal; the strategic view aims to enable a flexible specification which facilitates components' features discovery. 3. The representation system should offer various degrees of formality: non-formal/semi-formal to ease understanding, semi-formal/formal for automatic checking and validation. 4. Provide an abstraction mechanism that enables step-by-step requirements/component features discovery and matching analysis as customers identify component features and make decision on functional satisfaction of these ones. 5. Provide guidelines to discover customer requirements using the proposed representation system, as well as validation rules. Our solution consists of: (a) a representation system for system requirements in the context of COTS based development. We have chosen to describe dynamic behaviour of functional requirements as maps. The map uses two fundamental notions, intention and strategy. An intention captures the notion of a task whereas the strategy is the manner in which the intention can be achieved. The map is a directedlabelled graph with nodes representing intentions and labelled edges expressing strategies. The directed nature of the map identifies which intention can be done after a given one. Customer requirements are therefore specified in terms of intentions - stating what the system should do and strategies, offering a strategic view of multiple implementation choices for components assessment and selection. The elements of a map are expressed on terms of a static model’s vocabulary, which comprises a set of type diagrams and surrounding documentation. The static model helps establish the business domain glossary. As largely accepted in object-oriented modelling, we make use of UML to specify the static model. (b) a process guidance for discovering requirements and specifying them using the proposed representing system.

It provides the requirement engineer with rules for two primary tools for dividing a problem: the decomposition and the abstraction. The guidance is open and far from being exhaustive, it is expected to be completed in the future as we apply our approach to more practical case studies. 2.2.a. Map for high level system requirements In the following, we go into details of the map notion and apply it in discovering and representing requirements with a case study. A map is a labelled directed graph. A map depicts a process model at an intentional level of abstraction with its nodes representing intentions and its labelled edges expressing strategies to achieve process intentions. The directed nature of the graph shows which intentions can follow which ones. The following figure 1 depicts an instance of the map: sij2 si

Ii

sij1

Ij sji sjk

ski

Start sk

Stop Ik

ss

Figure 1. A map example An intention I is a goal that can be achieved by the performance of the process. It refers to a task that is part of the process and is expressed at the intentional level. It can be considered as a functional requirement that customers expect the system to have without dealing with how it will be implemented. Each map has two special intentions, Start and Stop, to start and end the process respectively. A strategy S represents the manner to achieve an intention. A strategy links a source intention to a target intention, making up the flow between intentions. Strategies offer the possibility to flexibly vary and enrich system requirements specification in one hand; on the other hand, customers specify their requirements in giving strategies to enlarge the search scope for candidate components. A section is the key element of the map. It is a triplet and represents a way to fulfil the target intention Ij using strategy Sij, given the source intention Ii has been achieved. The result of the source intention achievement constitutes the context for applying the specified strategy to reach the target intention. Target intention achieving gives a result that is specific to the applied strategy and in turn, constitutes the execution context for subsequent sections. A section is therefore associated to an interface whose signature is in the form of where Situation includes the result of Ii achievement, and to a body that clarifies what the section is responsible to do, not how it does. As a matter of fact, when defining a section, it will be needed to determine the situation or the precondition for achieving an intention I with a given strategy S that we call (I, S)pre as well as the result of its achievement or the post-condition by applying S, (I, S)post. (I, S)pre and (I, S)post are assertions made on map product model elements. As long as requirement engineering is concerned, the product model of the map will be constructed based on problem domain terms usually manifested as problem domain objects - in which the process model specified in the map operates. Components must agree on the definition of these business objects on which they will

jointly operate. That features the vertical dimension in the context of components based development, which aims to set up a standard for problem terms used in such domains as telecommunication, insurance, finance, and medical care [D'SOUZA 98]. These business objects are specified in static models. We have: (I, S)Pre Þ (I, S)Post which means that if the situation, i.e. the precondition for intention achievement holds, (I, S)Post will hold after having achieved intention. We define: map:Intention, Intention, Strategy → Section Ii, Ij, S → Section(Ii, Ij, S) if (∃S'∈Strategy: (Ii, S')Post Þ (Ij, S)Pre AND (Ij, S)Pre Þ (Ij, S)Post) Sections feature the contextual approach of the map, making up a non-deterministic ordering of intentions and strategies when they are connected to each other, which occurs when: §

At a moment during the process execution, a given task can be performed using different strategies according to the result of the intention formerly achieved. This is presented in the map by several sections between a pair of adjacent intentions. Such a map topology is called a multi-thread.

§

At a moment during the process execution, a given task can be performed using different combinations of strategies. This is presented in the map by a pair of intentions connected by several sequences of sections. Such a map topology is called a multi-path.

A map is usually a multi-path and may contain multi-thread section combination. Map offers therefore a global, suitable and flexible way to specify customer functional requirements that satisfies the goals stated above. §

It is global in that from Start to Stop, the map is considered as an integrated unit.

§

It is suitable in that customers express organisational tasks to support and various possible ways to achieve them using map's intention and strategy notions without having to get into implementation details. Clearly the map representation system takes a teleological view that favours the expression of functional requirements at the intentional level.

§

It is flexible in that there are different alternative ways of achieving a task depending on the process current context, which results in a rich interpretation of system requirements and an enlarged choice for component selection.

It is possible to decompose a section of map at a level i into an entire map at a lower level i+1 to view a task together with its strategy as a complex graph of subtasks and their associated strategies. The resulted map is also a multi-thread/multi-path structure and as a matter of fact, any combination of sections going from Start to Stop is functionally equivalent to the refined section, giving more choices of different alternative decomposition of the aggregate structure. Thus, the more abstracted a section is, the more complex it appears. The abstraction mechanism helps to step-by-step elicit system requirements on concentrating in more crucial, essential and discriminating ones on early stages, and to refine them as more components features get discovered. Two primary tools for dividing a problem are decomposition and abstraction. A good decomposition factors a problem into sub-problems that: §

are all at the same level of detail,

§

can be solved independently,

§

have solutions that can be combined to solve the original problem.

The last criterion is the hardest to satisfy. This is where abstraction comes in. Abstraction involves ignoring details that are irrelevant for some purpose. It facilitates decomposition by making it possible to focus temporarily on simpler problems. Since the contextual approach enlarges the flexibility of the process specification and execution, as a matter of fact, the notion of a map is justified in complex process models that offer multiple alternative choices in process instantiation. As far as modelling is concerned, static models should accompany dynamic models. Strategies and intentions of a map make reference to real world objects of the business domain or to software objects that are defined in the corresponding static model. The static model therefore sets a vocabulary for the rest. Here we adopt the same approach as with dynamic model (map): real world objects are abstracted to types with attributes representing their properties. No design or implementation assumptions are given, a static model of a component merely exhibits what it knows about. The abstraction mechanism has been claimed to be a powerful technique in that it simplifies a great many aspects of a system, deferring detail but not losing accuracy, which is the case of COTS-based system development. The static model and the map together specify customer requirements of the system to develop. Concerns on static model including matching computing and transformation operators are explained in [Plihon et al. 98]. 2.2.b Guidelines for requirements elicitation using map: In this section, we've adopted the multi-process approach of [BENJAMEN 99] for map construction process and linguistic-based goal structure modelled in [PRAT 97] for intention formulation. Guidelines are provided and illustrated in parallel by a case study. The notion of map was first introduced in [BENJAMEN 99] in an attempt to enrich the specification of process models. A strategic and contextual perspective features the approach, which guides the process engineer to progress in the map according to the current situation. The meta-process is provided with guidelines for map construction those are specified in form of contexts. This approach is targeted to method modelling where a product model has been defined, which is not however the case of COTS-based development. [PRAT 97] proposed to formulate goals using intentional verbs and case grammar. Goal is structured by relating a verb to its parameters like object, result, source, destination, and beneficiary… This facilitates to explicitly specify the semantics of different parts of a goal. A case study has been chosen in a requirement engineering perspective for procurement and integration processes. The system implements an e-commerce application that allows web-based online purchasing. The business process can be roughly described as follows: Santa is a book dealer who sells books in its numerous bookstores. Santa wants to promote productivity by providing customers with a web-based selling system that will integrate to the existing corporate information system. The client connects to Santa's site, navigates the on-line catalogue to find out book offers or searches for a specific book. The on-line catalogue is built upon the existing product database; users select books, fill up orders, make choice of shipping methods, pay by credit card and receive e-mailed invoice. Customers can save the products they have chosen for use at a later time by registration. Besides, registered clients can benefit from special pricing policy. The site must support up-selling and cross-selling: Up-selling is where the customer is offered additional products or services for purchase; cross-selling identifies the products that would complement the product the customer has chosen. On-line payment must be

secure and once an order is placed, the system posts 'accounts receivable' of the sale to existing financial system. Sales information should be flowed to existing inventory module and an analysis facility for on-line transactions will be also included to the system. Santa bookstore expects to have the system brought up at an affordable price and in a short delay, with reliable performance. It is decided that the system will be constructed from existing off-the-shelf e-commerce components, given the benefits of leveraging business expertise encapsulated in these components. The case study aims to find out the requirements engineering process for this COTS components-based system development. It has been chosen because of numerous involved COTS components as well as the diverse nature of integration: components with and without source code, legacy system, etc. The case study is complex enough to investigate different issues of COTS components based system development, though the global problem can be dealt with in a modular fashion. Existing corporate information system includes inventory and financial management modules that work on top of an Access relational database. Contextual guidelines for requirements elicitation using map will be then introduced and illustrated by the case study in an interleaved manner. G1. Due to the nature of web-based development, the system to be constructed is a client-server application, since the customer and the corporate information system will have different views on the system. The system will then have two interfaces. In the following, we will explore the client interface of the system. G2. G2a. G2b. The key point here is to be able to distinguish an intention from a simple operation or manipulation taken on product parts. An intention refers to an organisational task that aims to achieve a significant goal, in contrast to operations that manipulate product parts and give a concrete result. So, an intention is more abstract and does not directly deal with operations on product parts, it only expresses the final desired features of the product parts. Typically, an intention can be fulfilled by a certain combination of operations. According to [NCUBE 99a], requirements/intentions to identify in the first stage of elicitation must be core, essential and discriminating ones: Core requirements are those requirements that are central and most important to the customer and do not change for the entire duration of the system. Essential requirements are those requirements that are necessary for the system to achieve its purpose. Discriminating requirements are those requirements that express differences between products.

Once discovered, requirements are reformulated using goal linguistic structure * where is built upon conceptual product parts abstracted from problem domain terms. As it is found in the problem statement, a system offering online sales facility is a system that allows users to achieve these following intentions: Search (books)Obj (by title)Manner Deselect (books)Obj Search (books)Obj (by author)Manner Fulfil (order)Res Search (books)Obj (by publisher)Manner , … Select (shipping methods)Obj Consult (books’ information)Obj Select (payment facilities)Obj Select (books)Obj Issue (e-mailed invoice)Res, … The above intentions are effectively core and essential ones since we can not remove any one without spoiling the required functionality of the system. G2c. G2d. Intentions in a map must be at the same level of abstraction, i.e.: R1. There is not an intention that can be considered as a subset of another one. R2. There is not an intention that appears to be a way to achieve another one. Some rules to screen related intentions: R3: R4: R5: , for example Save and Restore books intentions. Applying R3, we can group these intentions "Search (books)Obj", "Select (books)Obj", "Save (books)Obj", "Restore (books)Obj" to formulate a more abstract intention "Select (books)Obj" as they all aim to result in a book or a collection of books. On the other hand, "Fulfil (order)Res", "Select (shipping methods)Obj", "Select (payment facilities)Obj", "Issue (e-mailed invoice)Res" intentions make up a purchase transaction in the meaning that they have to be finished all together or neither of them is taken into account by the system. So they can be combined to a more abstract intention, namely "Purchase books". G2e. As intentions, strategies in a map must be at the same level of abstraction, i.e.: R6. There is not a strategy that appears to be part of one another, for example the E-mail contact strategy and the personalised strategy can not be in the same map, as it stands for reason that the former should be built upon the latter. R7. There is not a strategy that specifies the way to achieve an intention at the implementation level whereas others are at strategic level, for example Search strategy should not be placed at the same level as Hyperlink-navigation strategy. As not intentions, it is encouraged to discover strategies as many as possible, just to keep in mind that in high abstraction levels of map, one should only intentionally state strategies which involve rather the corporate business process. For the moment, we suppose that a

multi-thread topology implies the exclusion of strategies, and set aside the parallel-processing dimension. §

Intention: "Book Selection".

"Book selection" is considered achieved once the client comes out with book(s) that he expects to buy or store away for further use. Strategies have been discovered to investigate the different ways possible to allow clients to select books, based on their regular Internet usage, corporate marketing strategies, always in the view to facilitate client's selection process and promote organisational sales. Hyperlink using consists of the first fashion to permit clients to quickly access to different book categories proposed by Santa. These hyper-links can be static or dynamic and constructed based on the existing database of book catalogue that gives Catalogue-based navigation strategy. Being dynamic, they are also generated according to personalised profile and his buying habit. Moreover, the system must be able to analyse the products in the customer-shopping cart in order to increase sales through cross-selling other products. Crossselling identifies the products that would complement the product the customer has chosen. Registered customers are regularly informed of book releases of their interest and can access directly to these by email-contained hyper-link, making up the e-mailed link strategy. For all these strategies, customer profiles are automatically detected or they can explicitly sign in when they access to Santa on-line selling site, the system recalls their profile and acts properly. Another way for book selection is to use a search engine to issue search requests for books of interest. §

Intention: "Book Purchase"

After having selected his shopping cart, customer can perform ordering, choosing shipping methods and payment facilities. Different strategies can be assessed here to offer a flexible choice of payment facilities. The system is expected to support payment by credit card number input, credit card reader terminal, check, checks funds on account or money order. §

Intention "STOP":

Users can finish their session with the system when they have achieved "Books selection" intention with or without buying. In either case, the disconnection takes place having user information to be stored. G2f. - For every intention I and one of its strategies S, determine (I,S)pre and (I,S)post. - Connect sections using the following section construction predicate: map: Intention, Intention, Strategy → Section Ii, Ij, S → Section(Ii, Ij, S) if (∃S'∈Strategy: (Ii, S')Post Þ (Ij, S)Pre AND (Ij, S)Pre Þ (Ij, S)Post) G3. As said earlier, a section is featured by an interface signature that is the usage context of the section and its body that provides more details always in an intentional viewpoint. For ease of documentation, we relate each section to a reference and a name. The information of map sections is grouped into a table. Finally, the resulted map can be represented as follows:

cross-selling strategy

Start

Catalogue-based navigation strategy

Search strategy Email contact strategy Search strategy

Select book(s)

Catalogue-based navigation strategy Cross-selling strategy Credit card payment strategy Check payment strategy

Check funds on account Money order payment

Purchase

Session tracking strategy

Session tracking strategy Credit card payment strategy

Stop

Figure 2. Santa Client-side TO-BE Map The following table gives an impression of how the informal documentation of a map should look like: Reference S1

S2

S3

S4

S5

1

Section name Book selection by using navigation links.

Section interface (Initial Statement1; Select book with Catalogue-based Navigation Strategy)

Section body Customers follow hyper-links to quickly access to different book categories proposed by Santa. That could be Best Sellers, New Releases, and books of different Book selection by (Some books selected; Select areas. Customer will be informed using navigation book with Catalogue-based of book information, price, links. Navigation Strategy) reviews, and availability…When some book interests the customer, hRegistered dd it t hi h are iregularly t Book selection by (Client received a linkscustomers using linkscontaining mail; Select book informed of book releases of their containing emails. with E-mail contact Strategy)interest and can access directly to these using email-contained hyperlinks. The customer is then automatically signed in and subsequent transactions are related to that customer. Book selection by (Initial Statement; Select Customers can choose a particular using a search book with Search Strategy) book category, enter text to search engine. for some book and put some into his shopping cart Book selection by (Some books selected; Select using a search book with Search Strategy) engine.

Initial statements are existing corporate IT infrastructure

S6

Book selection by (Initial Statement; Select using personalised book with cross-selling propositions. strategy)

S7

Book selection by (Some books selected; Select using cross-selling book with Cross-selling propositions. Strategy) Book purchase (Some books selected, Allow client to pay by inputting with credit card Purchase books with Credit credit card number Card payment Strategy) Book purchase (Some books selected, Allow client to pay by check with check Purchase books with Check payment Strategy) Book purchase (Some books selected, Allow client to pay by Check with check funds Purchase books with Check funds on account on account funds on account payment Strategy) Book purchase (Some books selected, Allow client to pay by Money with credit card Purchase books with Money order order payment Strategy) End session (Books selected, end session Store selected books to facilitate without buying with Session Tracking client's further buying sessions strategy) End session with (Payment accepted, end Store selected books and payment buying session with Session details to facilitate client's further Tracking strategy) buying sessions

S8

S9

S10

S11

S12

S13

Identify the products that would complement the product the customer had or has chosen.

Table 1. Documentation for Santa Client-side Requirements Map

2.3. Summary For requirements acquisition, the map has the following advantages: §

Map intentions and strategies match themselves to customer viewpoint and the COTSbased development paradigm. Requirements are intentionally specified and different strategies are made explicit.

§

The map is a multiple assembly (through multi-path) with multiple ways of achieving intentions (through multi-thread), thus facilitating an enlarged and flexible choice of candidate products.

§

Map refinement is a mean of handling complexity and step-by-step discovering system requirements.

3. Component procurement and features discovery The gap between customer and supplier visions should be filled to gain a seamless transition from one to the other. We believe that a common representation system would be helpful for a natural matching of component features to customer requirements, enabling candidate components assessment and decision making and therefore, allowing to result in a more functional system with greater customer satisfaction.

This section is about the procurement of components that somehow respond to system requirements elicited in the previous section. We provide contextual guidelines for candidate products discovery process and explain how to use map for component functions featuring.

3.1 Component identification The first step to undertake is to find out which products are needed. For that, we have the following guideline: G4. For every section of the TO-BE map, undertake a preliminary analysis on its body to identify potentially required candidate products. Carry out then a market survey for corresponding products. The evaluation team makes use of gathering techniques to investigate component resources such as search engines, component repository sites, online advertisements, webinars or other off-line ways as word of mouth, print advertisement, tradeshow, salesperson, article mention, seminar, internal or public market analysis… to get insight of various components currently available in the market. For illustrative purpose and due to the complexity of the system, in the following section we will only explore two sections of the Requirement Map: S1(Start; Catalogue-based Navigation Strategy; Select book) S6(Start; Personalisation Strategy; Select book) The key in the first feature is to classify books in a reasonable manner and organise hyper-links in an appealing fashion. This feature does not take into account the client-specific profile and offers the same content to all that is a full online version of the existing catalogue. Displaying products in a concise and discoverable structure will help users locate an area of interest quickly. Products that are categorised and subcategorised are often displayed using data trees similar to Microsoft's file explorer. In addition to displaying the data, another factor worth considering is using XML to physically store the data locally on your servers. XML gives flexibility to document the structure of data and has the added benefit of being very compact. Self-describing XML is easily exported to disparate systems, which is particularly useful when considering content syndication with other web sites. The key point in the second is to provide clients with relevant information. When a client connects to the site, he/she will see information of his/her interest area drawn from his/her profile and purchasing historic, as well as information concerning corporate marketing policy independent from client profiles. So it will be needed (a) a component managing customer profiles, (b) a component being in charge of marketing information supply and (c) a session component, with input from (a) and (b) dealing with dynamic generation of relevant information and GUI rendering as clients put books into their shopping cart using the Catalogue-based navigation strategy during their session. A support for Shopping Carts components turns out obvious to provide customers with the ability to place items in a virtual shopping cart or shopping list. Shopping carts allow customers to choose the products or services they desire before moving on to an online checkout for subsequent payment. Furthermore, customers usually want the ability to save the products they have chosen for use at a later time. Often, customers check prices and features elsewhere before proceeding to payment,

so saving their shopping cart will help the customer come back and begin where he left off, perhaps via a shortcut to online checkout. So, a storage component will be needed. Storing information between requests is particularly useful for efficiently handling transactions. So a session component and a storage component can co-operate to automatically handle the client identity and store any other customer related data that are expected to be persistent during transaction sessions. These two sections can be refined at a lower level as follows: Start marketing policy strategy client profiling strategy

cataloguegenerated Generate contents passive selection strategy passive selection strategy

Add book to Shopping Cart select without purchase strategy

select with purchase Stop

Figure 3. The refined map The following table documents the refined map: Reference S1.1

S6.1

S6.2

Section name Section interface Section body Catalogue-based (Initial statement; Generate The system offers an access to contents generation contents with Cataloguebooks database equal to all generated strategy ) clients. Client-profile based (Initial statement; Generate The system displays relevant contents generation contents with client-profiling information that corresponds to strategy) client's interest Marketing policy (Initial statement; Generate The system keeps clients in touch based contents contents with marketing of actual marketing campaign generation policy strategy) and promotion offers

S1.2

Books selection with passive strategy

(Generated contents; Add Clients select books proposed by books to shopping cart with the achievement of the previous passive selection strategy) intention.

S1.3

Books selection with passive strategy

(Some books selected, contents generated; Add books to shopping cart with passive selection strategy)

S1.4

Books selection without purchase

S1.5

Books selection

(Some books chosen in Clients can make purchase shopping cart; Stop with decision later Select w/o purchase strategy) (Some books chosen in Clients move to order submission

with purchase

shopping cart; Stop with purchase strategy

and checkout for selected books

Table 2. Documentation for the refined sections After a market survey on Internet, we have come out with a number of candidate components: Tree Components

TreeGen Component TreeGen SpeedPack TreeGen WebAdmin Quick Tree View ASP2XML ASPointer DataPackage XML Client/Server GEMObjectSpan VTComposer Commerce Server Development Kit Internet Commerce Kit Internet Commerce Toolkit SaveForm SA-Session Pro ActiveProfile CartEasy ALSTRA E-SHOP ALSTRA E-SHOP Server Toolkit Commerce Server Development Kit

XML Components

Component Suites

User Data Storage

Shopping Carts

Table 3. Candidate products for the refined map

3.2 Component features discovery Our proposition is to adopt the same representation system for system requirements and component features to facilitate the matching process. Furthermore, maps allow describing and reasoning on complex assemblies of components that happens in case of COTS-based development. This is achieved by simply relating each map to a component. This one can be a simple one or a complex one, which is constituted of various smaller ones and related therefore to a set of maps. In conformity to our approach, component process model is specified in map using intentions and strategies generic to application domain since COTS components are developed for a whole market and therefore have to satisfy a wide range of requirements. But they can provide more added values as well due to the competitiveness of software development. Component suppliers can be guided to construct their components' process model using guidelines represented above. So we propose the context: G5. The following section explores two candidate products: the Order Processing Tools of the Internet Commerce Toolkit, and the Commerce Server Development Kit: BEA WebLogic ® Commerce Server. Since we're focusing for this moment on book selection by browsing catalogue feature and client profiling, we will not present the entire component map but just parts of interest.

Internet Commerce Toolkit : Order Processing Tools The Internet Commerce Toolkit is an integrated suite of applications and components supporting the development of commerce-enabled web sites, a product of Aldebaran Systems Ltd. The Internet Commerce Toolkit is distributed as a set of five toolkits, together with three add-on packs. The map part of the component corresponding to the requirement-refined map can be depicted as follows. The map is pretty self-contained. The product offers an online selling facility that bears on a proprietary built-in database schema. Contents are dynamically generated in function of user profiles. The component supports multi-shopping basket for each clients as well as choice for delayed or immediate order submission.

Start Built-in database scheme, user profiling strategy

Manage contents multi-shopping basket support strategy

multi-shopping basket support strategy Select books

order strategy

delayed order strategy

Stop

Figure 4. The Order Processing Tools map Commerce Server Development Kit: BEA WebLogic ® Commerce Server BEA WebLogic Commerce Server is a complete commerce solution that can be easily customised to rapidly deploy adaptable and personalised e-commerce applications that create a sustainable competitive advantage and accelerate response time to changing market conditions. Over 80 components integrate to provide an extensive breadth of pre-tested commerce functionality. The map part of the component corresponding to the requirement-refined map can be depicted as follows: Start customer profiling strategy built-in database scheme, template strategy

webflow strategy Manage contents shopping cart strategy shopping cart strategy

Select books

delayed order strategy

order strategy

Stop

Figure 5. BEA WebLogic ® Commerce Server map As the Internet Commerce Toolkit, BEA WebLogic ® Commerce Server makes assumption about the underlying database scheme. Contents can be dynamically generated based on

customer profiles, webflow rules, with or without template-driven contents rendering. On the other hand, it supports only one shopping cart for a client at a time, and the same strategies for order submission.

3.3 Summary Using map for component featuring has the following advantages: The map explicitly specifies different alternatives for functional and deployment choices of the candidate product. The component suppliers can therefore emphasises on the multiplicity of possibilities covered by the component as well as their added values. Customer requirements and component features are represented using the same notion graphic helps in the next step of the requirement engineering process: assessment and selection of candidate products. Specifying off-the-shelf products using map offers a different view of component features decomposition. Maps emphasise on expressing functional intentions able to be achieved after process performance. Each intention is therefore specified at high levels of abstraction and can be fulfilled as a result of co-ordination of several structural sub-components

4. Component-requirement matching Having the TO-BE map and the candidate components' maps, the requirement engineering team can carry out the assessment on functional matching, then make decision on products selection and rejection. In the following section, we propose an attempt at reasoning on requirements and components matching using the pre- and the post-condition of maps’ sections. In reality, it is difficult to have exact matching between candidate component features and system requirements, since the latter is application specific whereas the former is generically designed to gain broader market. So different variations are supported. Besides, it's not necessary that a component section must match a requirement section. It can be fulfilled by a sequence of component sections. The proposed solution is adapted from the specification matching approach of [ZAREMSKI 97] initially targeting function and module-size components in the domain of software engineering. We define: (RS)2pre ⇔ (CS)3pre : The preconditions of RS and CS are semantically equivalent, that means if (RS)pre holds then (CS)pre is also true and the two sections can get executed. As the pre- and post conditions of a section are predicates made on product parts of the system at hand, the relation of equivalence means that at the moment when product parts in (RS)pre that satisfy some constraints exist, corresponding product parts in (CS)pre also exist and satisfy some other constraints, and vice versa. (RS)pre ⇔ (CS)pre : The precondition of RS implies the one of CS, whenever (RS)pre holds then (CS)pre is also true and the two sections can get executed. The relation of implication means that at the moment when the product parts in (RS)pre exist, the set of product parts in (CS)pre also exist. The former is included in the latter and/or the latter imposes fewer constraints on product parts.

2 3

Requirement section Component section

(CS)post ⇔ (RS)post : The completeness of CS implies that the target intention of RC is also achieved, the fulfilment of CS results in a superset of product parts that includes the desired target intention of RS. (CSi, CSj, CSk,.., CSl) : a sequence of adjacent sections in that the completeness of CSi results in product instances that take part in the pre-condition of CSj, i.e. (CSi)post (CSj)pre or (CSi)post (CSj)pre, the completeness of CSj results in product instances that take part in the pre-condition of CSk and so on.

4.1 Exact matching Definition:

matchExact (RSi, (CSj, CSk,.., CSl)) = (RSi)pre ⇔ (CSj)pre ∧ (CSl)post ⇔ (RSi)post

Semantic: Exact match is a strict relation in a sense that the component features exactly match the system requirement. The system requirement specified in a section can be fulfilled by a sequence of sections from CSj to CSl. Example: Let's consider the section RS(Add book to shopping cart, Stop, Select without Purchase strategy> in the refined requirement map: RSpre refers to the shopping cart including selected book(s). RSpost is having the shopping cart stored away in case of registered users. On the other hand, in the component maps, the section CS(Select books for orders, Stop, Delayed order strategy) of Order Processing Tools component and BEA WebLogic® Commerce Server has the same precondition: coming out with book(s) put in a shopping basket metaphor and it offers an automatic saving for registered clients. So it is obvious that these sections are exact matched to each other.

4.2 Plug-in matching Definition:

matchPlug-in (RSi, (CSj, CSk,.., CSl)) = (RSi)pre ⇔ (CSj)pre ∧ (CSl)post ⇔ (RSi)post

Semantic: Plug-in match captures the notion of being able to "plug-in" the component to the system. If the actual situation of a requirement section is included in the one of a sequence of sections, this sequence can be performed to achieve its own intention that includes the intention of the system in that context. In this case, requirements for component use involve fewer product parts and/or are less strict than the actual situation and it achieves an intention including the desired intention. Components are generally found in this kind of matching, since component providers develop for a whole market and therefore have to satisfy a wide range of requirements. Example: Consider then the section RS(Generate contents, Add book to shopping cart, passive selection strategy), its precondition consists of some book-related information procured from the corporate database by certain strategy, and clients passively use it that is organised in web pages interrelated by hyper-links. As long as the post-condition is concerned, its target is expected to result in a shopping cart metaphor containing book(s) selected using these hyper-links. Concerning candidate components, Order Processing Tools offers section CS(Manage contents, Select books for orders, multi-shopping basket support strategy) that can be performed given a content including books information and once achieved, leads to a set of shopping baskets related to a specific client. It can be found that this component aims to fulfil an intention more important in terms of product parts resulted in a less strict execution context in comparison with the requirement section. So it can be plugged in without significant modification.

4.3 Pre-conditioned plug-in matching

Definition: matchPre-conditioned plug-in (RSi, (CSj, CSk,…, CSl)) = (CSj)pre ⇔ (RSi)pre ∧ (CSl)post ⇔ (RSi)post Semantic: In this case, this situation of the system requirement includes more cases than the one of component, that means using the component can only satisfy a subset of use cases and additional house-in components will be needed to take into account non supported use cases. Example: The section RS(Start, Generate contents, Catalogue generated strategy) is defined to generate book related information from existing corporate catalogue database that is an Access relational database. Consider then the section CS(Start, Manage contents, built-in database scheme template strategy) of BEA WebLogic Commerce Server. It is found that the target intention of the section is achieved by a strategy, which is very close to the one in RS. CS bares on a predefined database scheme and therefore constraint customers to a proprietary implementation choice, whereas the organisation already has an existing DB and DBMS. It is found that the built-in database scheme is also relational and as such, features a specific case (a subset) of all possible corporate relational database schemes. A solution to this shortcoming consists in using another suitable off-the-shelf component filling the gap or house-build a new component. The pre-conditioned plug-in matching is justified here in that there is a need for additional component(s) to deal with use cases non-supported by the candidate components in consideration. Besides, it offers more that expected. The contents are generated from the database using different built-in or user-defined templates, giving a flexible GUI rendering choice. This new feature of the candidate component addresses customer needs for displaying products in a compelling and customisable way.

4.4 Post-conditioned plug-in matching Definition: matchPost-conditioned plug-in (RSi, (CSj, CSk,…, CSl)) = (RSi)pre ⇔ (CSj)pre ∧ (RSi)post ⇔ (CSl)post Semantic: In this case, the component can be used once the system state reaches to Situation(RSi), since this is a subset of the component situation. But after having finished, it only achieves a subset of the desired intention. As pre-conditioned plug-in matching, additional house-built components will be needed to be executed in the same time with the same situation but having other intentions or other strategies to complement component-supported intentions.

4.5 Unmatched or missing sections For requirement sections that do not have their counterparts in candidate components, it will be needed to develop them house-in from the scratch. Here is the recapitulation of the match evaluation process: Components Internet Commerce Toolkit : Order Processing Tools Requirement Section matching S1.1 S6.1 S6.2

Pre-condition plug-in Plug-in -------missing

Commerce Server Development Kit: BEA WebLogic ® Commerce Server: Pre-condition plug-in Plug-in --------missing

S1.2, S1.3 S1.4 S1.5

Plug-in Plug-in Exact matching Exact matching Exact matching Exact matching (Generate contents, Add books (Start, Manage contents with Added values of components to shopping cart with multi- webflow strategy) shopping cart support) Table 4. Requirements and candidate products functional matching According to organisational priorities, we can favour added values of one component in despite of others or keep refining system requirements and product features and assessing the functional matching. Different decision-making techniques can be used at this stage, namely the MultiAttribute Utility Theory [MacCrimmon 72], the Multi-Criteria Decision Aid [Moriso & Tsoukias 97], Weighted Score Method or Weighted Average Sum [Kontio 96], the Analytical Hierarchy Process [Saaty 90], the Outranking method [Fenton 94]. A survey and comparison of these ones can be consulted in [Ncube 99a].

4.6 Summary Reasoning on pre- and post conditions of map sections is our first attempt to assess functional matching between system requirements and product features. Du to the dimension off-the-shelf of components and the specificity of the problem to resolve, different variations of relaxed matching are also considered. Map offers a visual assessment in a modular and decomposable fashion. Each requirement section is analysed and compared to its counterparts in component maps, and can be further refined to get a more insight of functional sufficiency of candidate components. On the other hand, the integration is carried out in a global way, taking into account all involved components to ensure a path from Start to Stop in the map. Matching rules are given semi-formally to illustrate the substitution, the generalisation and the specialisation dimensions in reuse. Works are on the way to formalise the matching criteria, as we argued above the need for a multi-layered representation system that provide support for an easy stakeholders’ involvement and (semi-)automatic validation.

5. Conclusion Requirements engineering for COTS components selection and assembly is an issue that has been neglected by current methods of developing systems from commercial off-the-shelf software. Extending our previous work, this paper intends to formalise the proposed approach by giving more systematic guidelines for the overall process and more reasonable reflections on matching process particularly. Using map's notions makes expressing requirements more natural and intuitive. Customers keep going with their usual vision on system functionality that is specified at an intentional level in terms of goals and strategies. Component suppliers adopting map for their products featuring will facilitate the transition between two visions and thus, allows an easy assessment and integration process. The final goal of requirements engineering is to obtain a fully functional system that satisfies all the customer requirements. It's very difficult to achieve really, especially in the context of COTS-based development. Our approach aligns component features to requirements in an attempt to fill the gap. Measuring the gap supported by different typologies of matching, built

upon map notions, and has turned out a useful technique. In the long term, we hope to formalise further the matching process, as well as provide global guidelines for the overall process. Abstracting from experience a set of generic requirements critiquing strategies and assembly strategies together with a set of generic matching patterns also features in our future work.

6. References [Alvaro-Diaz 00] “Propositions d'outils méthodologiques pour l'étude différentielle d'un projet d'intégration d'un ERP: Application au cas de l'intégration de PeopleSoft au sein du Ministère de l'Emploi et de la Solidarité”, Mémoire de DESS “Systèmes d'information”, IAE de Paris, 2000 [Bassett 97] Paul G. Bassett, “Framing Software Reuse: Lessons From the Real World”, Prentice Hall PTR, 1997 [Benjamen 99] A. Benjamen, “Une Approche Multi-démarches pour la modélisation des démarches méthodologiques”, Ph.D thesis, University Paris I - Panthéon - Sorbonne, 1999. [D'Souza 98] Desmond Francis D'Souza, Alan Cameron WILLS, “Objects, Components, and Frameworks with UML, The Catalysis Approach”, Addison-Wesley Longman, Inc. [Fenton 94] Fenton N., “Out Ranking Method for Multi-Criteria Decision Aid: with emphasis on its role in systems dependability assessment”, Centre for Software Reliability, City University, London, UK. [Finkelstein et al 1997] Finkelstein A. C. W, Spanoudakis G. and Ryan M., “Software Package Requirements and Procurement, Proceeding 8th International Workshop on Software Specification and Design, IEEE Computer Society Press, Los Alamitos, Califonia, 1996, pp 141-145 [Fox et al. 97] Fox G., Marcom S. and Lantner K., “A Software Development Process for COTS-based Information System Infrastructure”, Proceedings of the 5th International Symposium on Assessment of Software Tools and Technologies (SAST’97), pp133-143 [Frakes 93] W. B. Frakes and C. J. Fox, “Software reuse survey report”, Software Engineering Guild, Sterling, VA, 1993 [Gibbs 94] W. W. Gibbs, “Software's chronic crisis”, Scientific American (International Edition), vol. 271, Sept. 1994, pp. 72-81. [Griss 97] Martin L. Griss, “Software Reuse: Architecture, Process and Organisation for Business Success”, Addison-Wesley-Longman, 1997. [Johnson 95] J. Johnson, “Chaos : the Dollar Drain of IT project Failures", Application Development Trends, pp.41-47, January 1995. [Kitchenham 96] Kitchenham B., “DESMET: A method for evaluating Software Engineering methods and tools”, Technical Report TR96-09, Department of Computer Science, University of Keele, August 1996. [Kontio 95] Kontio J., “OTSO: A Sysmatic Process for Reusable Software Component Selection”, Technical Report Number CS-TR-3478, 1995, University of Maryland, USA. [Kontio 96] Kontio J., “A Case Study in Applying a Systematic Method for COTS Selection”, Proceedings of the 18th International Conference on Software Engineering, IEEE Computer Society Press.

[Laplante 99] Phillip A. Laplante, “Keys to Successful Software Development: Selected readings”, IEEE 1999. [Lequeux 99] Jean-Louis Lequeux, “Manager avec les ERP”, Eyrolles, Editions d'Organisation, Mar. 1999. [Lim 94] W. C. Lim, “Effects of reuse on quality, productivity and economics”, IEEE Software, vol. 11, pp. 23-30, Sept. 1994. [Lim 98] Wayne C. Lim, “Managing Software Reuse: A Comprehensive Guide to Strategically Reengineering the Organisation for Reusable Components”, Prentice Hall PTR, 1998. [MacCrimmon 72] MacCrimmon R. K., “Proceedings of Multiple Criteria Decision Making”, University of South Carolina, October 26-27, 1972. [Matsumoto 93] Y. Matsumoto, “Experiences from software reuse in industrial process control applications”, Second International Workshop on Software Reusability, Mar. 1993. [McGraw 97] Karen Mc Graw, Karan Harbison, “User Centred Requirements, The Scenario-Based Engineering Process”, Lawrence Erlbaum Associates Publishers, 1997. [Moriso & Tsoukias 97] Morisio M. and Tsoukias A., “A Methodology for the Evaluation and Selection of Software Products”, Dipartimento di Automatica e Informatica, Politicnico di Torino, Italy. [Ncube 99a] Cornelius Ncube, “A Requirements Engineering Method for COTS-Based Systems Development”, Ph.D. thesis, School Of Informatics, City University, London, 1999. [Ncube 99b] Cornelius Ncube, Maiden N., “Guiding parallel requirements acquisition and COTS software selection”, Int. IEEE Conference on Requirements Engineering, Limerick, Ireland, 1999. [Plihon et al. 98] V. Plihon, J. Ralyté, A. Benjamen, N.A.M. Maiden, A. Sutcliffe, E. Dubois, P. Heymans, “A Reuse-Oriented Approach for the Construction of Scenario Based Methods”, Proceedings of the International Software Process Association's 5th International Conference on Software Process (ICSP'98), Chicago, Illinois, US, June 14-16, 1998. [Prat 97] N. Prat, “Une approche linguistique pour la formalisation et la classification des buts en ingénierie des processus”, First International Workshop on the Many Facets of Process Engineering, Gammarth, Tunisia, Sept. 1997. [Prieto-Diaz 93] R. Prieto-Diaz, “Status report: Software reusability”, IEEE Software, vol. 10, pp. 61-6, May 1993. [Prieto-Diaz 98] R. Prieto-Diaz, “Implementing faceted classification for software reuse”, Communication of the ACM, pages 88-97, 1998. [Prieto-Diaz 99] Prieto-Diaz R., “A software classification scheme”, Ph.D. thesis, Department of Information and Computer Science, University of California at Irvine, 1999. [Rolland 99] C. Rolland, “Requirements Engineering for COTS Based Systems”, University Paris1, Sorbonne. [Rolland 00] C. Rolland, Naveen PRAKASH, “Bridging the Gap between Organisational Needs and ERP Functionality”, Requirements Engineering (2000) 5:180193, Springer-Verlag London Limited.

[Saaty 90] Saaty L.T., “The Analytic Hierarchy Process (AHP): How to make a decision”, European Journal of Operational Research, 48(1990), 9-26. [TRACZ 88] W. Tracz, “Software Reuse: Motivators and Inhibitors”, in “Tutorial: Software Reuse: Emerging Technology”, ed. W. Tracz. Washington: IEEE Computer Society, 1988, pp. 62-67. [Tran & Liu 97] Tran V. and Liu D., “A Procurement-centric Model for Engineering Component-based Software Systems”, Proceedings of the 5th International Symposium on Assessment of Software Tools and Technologies (SAST’97), pp70-80. [Vigder 1997] Vigder R. M. and Dean C. J., “Architectural Approach to Building Systems from COTS Software, Proceedings of the 1997 Center for Advanced Studies Conference (CASCON 97), Toronto, Ontario, 10-13 November 1997. [ZAREMSKI 97] Amy Moormann ZAREMSKI, Jeannette M. WING, “Specification Matching of Software Components”, Carnegie Mellon University.