COTS tenders and integration requirements.

Saved in:

Bibliographic Details
Title:	COTS tenders and integration requirements.
Authors:	Lauesen, Søren¹ slauesen@itu.dk
Source:	Requirements Engineering. May2006, Vol. 11 Issue 2, p111-122. 12p. 1 Diagram, 4 Charts, 1 Graph.
Subjects:	Computer interfaces, CORBA (Computer architecture), Internetworking, Computer software, Information technology, Computer systems
Abstract:	When buying COTS-based software, the customer has to choose between what is available. The supplier may add some minor parts, but rarely everything the customer wants. This means that the customer cannot write down his requirements and expect that they can all be met. A scoring system is necessary rather than traditional mandatory requirements. Requirements for integrating the new COTS system with other systems are particularly hard because suppliers may integrate in different ways and with different other systems. A related problem is that once the new COTS system is purchased, the COTS supplier may have a de facto monopoly. Only he can expand the system or integrate it with other systems. The traditional way to purchase COTS is to iteratively find the right product. However, in a tender process this is not possible, and another solution is necessary. Experience shows that customers fail to deal with these issues adequately. As an example they may believe that asking for open interfaces is sufficient to guard them against monopoly. In this paper we analyze the problems and show ways to deal with them. We illustrate the problems and solutions with real-life examples from electronic patient recording systems. [ABSTRACT FROM AUTHOR]
	Copyright of Requirements Engineering is the property of Springer Nature and its content may not be copied or emailed to multiple sites without the copyright holder's express written permission. Additionally, content may not be used with any artificial intelligence tools or machine learning technologies. However, users may print, download, or email articles for individual use. This abstract may be abridged. No warranty is given about the accuracy of the copy. Users should refer to the original published version of the material for the full abstract. (Copyright applies to all Abstracts.)
Database:	Engineering Source

Description
Abstract:	When buying COTS-based software, the customer has to choose between what is available. The supplier may add some minor parts, but rarely everything the customer wants. This means that the customer cannot write down his requirements and expect that they can all be met. A scoring system is necessary rather than traditional mandatory requirements. Requirements for integrating the new COTS system with other systems are particularly hard because suppliers may integrate in different ways and with different other systems. A related problem is that once the new COTS system is purchased, the COTS supplier may have a de facto monopoly. Only he can expand the system or integrate it with other systems. The traditional way to purchase COTS is to iteratively find the right product. However, in a tender process this is not possible, and another solution is necessary. Experience shows that customers fail to deal with these issues adequately. As an example they may believe that asking for open interfaces is sufficient to guard them against monopoly. In this paper we analyze the problems and show ways to deal with them. We illustrate the problems and solutions with real-life examples from electronic patient recording systems. [ABSTRACT FROM AUTHOR]
ISSN:	09473602
DOI:	10.1007/s00766-005-0022-5