Non-Functional Requirements for COTS Software Components Ljerka Beus-Dukic School of Computing and Mathematics University of Northumbria at Newcastle Ellison Building, Newcastle upon Tyne NE1 8ST, United Kingdom +44 191 227 3974
[email protected] ABSTRACT Commercially available software components come with the built-in functionality often offering end-user more than they need. A fact that end-user has no or very little influence on component’s functionality promoted nonfunctional requirements which are getting more attention than ever before. In this paper, we identify some of the problems encountered when non-functional requirements for COTS software components need to be defined. Keywords Requirements engineering, non-functional requirements, COTS software component 1 POSITION Non-functional requirements have been neglected by the requirements engineering practice and research for a long time. However, an increasing trend to build software systems from commercial off-the-shelf (COTS) software components has highlighted the need to take non-functional requirements more seriously. Since end-user has no influence on the functionality provided by COTS software component there is little use in providing detailed functional requirements. It is more important to identify the constraints that a component must meet and the overall quality of the component. Both theory and practice of requirements engineering do not provide adequate support for non-functional requirements. This is also true for methods which are developed for purpose built software. As methods for ready-made software have just begin to emerge (OTSO [7], PORE [9]) it is early to judge them on the basis of support for non-functional requirements. We developed interest in
the problem after completing the assessment of real-time operating systems for end-users from different application domains [11]. In this paper, we identify some of the problems encountered when defining non-functional requirements for a COTS software component, and matching these requirements with available component descriptions. The paper presents end-users’ (or component integrators’) perspective rather than of organisations which are developing COTS software components (vendors). Observations presented are based on our experience with COTS software assessment for the GUARDS project [1] and a recent survey conducted in space industry [2]. COTS Software Component Commercial off-the-shelf software component is developed by a commercial vendor for commercial purposes and is sold “as is”. Note that there is no universally accepted definition of a software component. Brown and Wallnau [3] talk about two types of off-the-shelf components: 1) components developed in-house (perhaps for some other project), and 2) packages purchased from external sources (e.g., database management systems and network monitors). They also state that software components “have significant aggregate functionality and complexity”. Scyperski [12] gives precise definition of a software component stating that “software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system”. Here, we are concerned with COTS software components of coarse granularity, often termed “software packages” (e.g., operating systems, database servers) which are selfcontained and integrated with other components in a complex software system. Non-functional Requirements Non-functional requirements define the general qualities of the software product. They are usually associated with the product descriptions of type “ility” such as maintainability, usability, portability etc. Non-functional software requirements are notorious for being difficult to elicit, express, quantify and test. It is also known, that there are
many communication obstacles between requirements engineers and end-users. While software engineers are usually accused of lacking expertise in end-user domain, end-users are often criticised for being vague and ambiguous. Other issues include representation of the requirements, their prioritisation, level of detail, and relation to functional requirements. This situation is usually found when requirements are elicited from end-user for a bespoke software product being developed in-house for the same end-user. In a different situation, when requirements need to be elicited from end-user for a commercially available software component (developed by a third party for an unknown end-user), issues become more complex. The main reason for this is the introduction of a third party i.e. vendor of a software component. One could say that dealing with different vendors is not a new practice for software engineers. What is different at present, is the volume of the market of software components and the speed with which different components (or their new versions) emerge. With the introduction of the Internet market for software components, the reality of having to weed through a significant number of similar components on offer (e.g., 100 hundred real-time operating systems) will soon become a nightmare. Even if we ignore a problem of obtaining non-functional requirements from the end-user, we are still left with a number of problems to solve. How to select a component on a basis of non-functional requirements? Which component attributes we should be looking for? Can we trust vendor claims about component (e.g., performance)? Should vendors be made to describe component characteristics in a uniform way so that a valid and meaningful comparison can be performed? Why they are important for COTS software?
The role of non-functional (or qualitative) requirements becomes more important because ready-made COTS software components have their functionality already builtin. As component’s functionality is specified with the view of a generic customer, component’s capabilities are likely to exceed the ones needed for a specific end-user. Functional requirements need to be specified too, but only to a level which enables efficient survey and evaluation of the available COTS components on the market. Once a particular subset of components is identified (in our case operating systems appropriate for use in real-time systems) non-functional requirements are called in. External constraints on a component can help to eliminate a good proportion of component candidates (e.g., POSIX standard compliance was effective discriminator for real-time operating systems). Non-functional requirements often correspond to strategic or business objectives of end-user organisation as a whole, and, therefore, are likely to have higher priority if conflicting with some of the functional
requirements for the software component. It is no coincidence that non-functional requirements frequently come from managers who are ultimately responsible for taking a decision to purchase a COTS component. What are they?
In a traditional divide between functional and nonfunctional requirements the later always had a back seat. This is still reflected in the way components are being described by their vendors. Non-functional characteristics are not easy to describe and quantify even for the purpose built software and a known end-user. With a generic product and an imaginary customer the task does not become easier. COTS components bring a number of additional non-functional requirements. These include architecture, domain and organisational requirements. Architecture requirements
Acquired software components need to be integrated with other components into a system and together provide required functionality. As COTS components are already built, an issue of their integration has to be considered much earlier then with a purpose built software i.e. before their assessment. Component system architecture provides a proper structure for components to be plugged in. It consists of a set of platforms, component frameworks, and an interoperation (communication and interface) design for the component frameworks. The architecture needs to provide for both independence and cooperation of components [12]. Independence is required to enable components to be easily replaced by components from other sources. Non-functional requirements often associated with component independence include flexibility, portability, evolvability, scalability, genericity, reusability and integrity. Cooperation between components is essential in any architecture (composability, interoperability). Additional, often neglected, nonfunctional requirements on component architecture are performance, reliability and security. Domain Requirements
COTS software components are often developed with no readily identifiable end-user and by developers who have no experience in any specific application domain and have no direct contact with the customer. Consequently, enduser is left alone with a difficult task to assess a specific component on the basis of domain-specific requirements. Some of these requirements (e.g., for specific type of hardware, timing and performance constraints, security) can be found in product descriptions. However, majority is not readily offered by vendors and have to be specifically requested (e.g., compliance to a domain standard), researched (e.g., popularity of a component in a specific domain), or tested (e.g., interoperability with other COTS 2
and legacy components). In an ideal world it will be useful if end-users could compare the context in which a component was designed for, and the context in which is to be used. Unfortunately, contextual assumptions made by component designers are rarely made available to endusers. Similarly, end-users have no information about the development process used to produce and maintain a component. Hence, a requirement that a component is successfully used in organisations from the same application domain becomes more and more common amongst end-users. Apart of providing some guarantees of component reliability in a similar context of deployment, this requirement gives end-user opportunity to share knowledge of other component users about the component. When there are problems with component use and maintenance, user group from a specific application domain can have more influence on component vendor than a single user. Often a fact that a component has not been used in a particular domain signals a lack of certain component properties (e.g., component is not compliant to a specific domain standard).
• Stability of a particular component (frequency and type of updates) • Component upgrade policy (e.g., based on new features and/or bug fixes) • References for component use (customer base) • Long-term component support strategy • User support record • Vendor's software development practice (e.g., ISO 9000) • Vendor’s popularity in a particular application domain • Vendors’ vested interest in a particular domain (if sufficient it provides a scope for introducing component features relevant to that domain) • Contract practice (guarantees given, and obligations vendor is prepared to take on) Most of the non-functional requirements for a component vendor are related to component’s maintainability. As endusers have little or no influence over the maintenance and evolution of the components it is reasonable to question vendor’s record.
Organisational requirements
2 BACKGROUND Non-functional requirements for COTS software components do not always fit their existing definitions. They are usually defined as the restrictions on the software product. However, when these restrictions include the product development process [8] the distinction between bespoke products and COTS components has to be drawn. COTS software components are by definition ‘black boxes’ which means that we have no knowledge or influence on component development process.
Non-functional requirements for a COTS software component need to include constraints relevant to two types of organisations concerned: a vendor (component producer) and an end-user (component consumer). Here, we are interested in end-user’s point of view; therefore both types of organisational requirements originate from component consumer. Before embarking on acquisition of a COTS software component end-user has to have a clear picture of the constraints of its own organisation such as: • Current hardware platform characteristics • Existing software development environment • Staff expertise and culture (current knowledge and skills, need for extra training) • Type of legacy applications • Timescale for component integration • Long-term strategy for software development • Business and political factors (cost-benefit, partnership with a vendor) The non-functional requirements imposed on COTS component by end-user organisation are not easy to elicit and quantify. They can not be described with the familiar ‘ilities’. Nevertheless, their importance for component selection should not be underestimated. On the other hand requirements placed by the end-user on a component vendor are more typical of any product on the market. They are much easier to describe and quantify. These include: • Vendor’s credentials and stability on the market • Component conformance to standards (interface, framework, domain)
Both functional and non-functional requirements for COTS software components have received little attention by researchers. However, there are few exceptions. Finkelstain [5] makes a distinction between “core” and “peripheral requirements” and points out that peripheral requirements help to distinguish between software packages. He wants to see “software package requirements and procurement placed within mainstream of specification research”. Requirements for COTS software packages are part of the two ongoing research projects at London’s City University: ACRE (Acquisition of Requirements) is providing a framework for selection and use of diverse requirements acquisition techniques, and PORE is a method for Procurement-Oriented Requirements Engineering [9]. OffThe-Shelf Option (OTSO) method [7], developed for reusable component selection process, takes into account application specific and functional requirements, design and architecture constraints. Although it recognises the role of organisational characteristics (e.g., current practices, existing infrastructure in end-user organisation) OTSO method does not address vendor’s characteristics and standard compliance. Franch [6] classifies approaches to non-functionality as process-oriented and product-oriented 3
and proposes a notation NoFun to define hierarchies of non-functional attributes at the component level. There is also evidence of some research on requirements engineering from a perspective of software developers who build off-the-shelf software i.e. vendors [4] [10]. It seems that restrictions imposed on component from the vendor’s angle differ from the ones perceived by end-users. 3 RESEARCH Requirements engineering for COTS components clearly need a different approach. Many concepts which were valid for bespoke software are not valid any more and different activities have different priorities. Since end-users are not in a position to specify functional requirements or to control the process of component development, there is no need for detailed functional requirements. As we move the focus from functional to non-functional requirements a number of topics comes into light: • Which attributes of a component are critical to its use in a particular architecture/framework? • What are the requirements for the architecture/framework which are best suited for the particular component? • How to describe, measure and quantify component’s ‘ilities’? • How to verify vendor’s claims for standard compliance? • How to prioritise non-functional requirements? • Components are described using different vocabulary – how to make comparisons between different components? • How to characterise a component in a uniform way? These questions are only some of the questions that need to be answered by requirements engineering research and practice.
5.
Finkelstein, A., Spanoudakis, G., and M. Ryan, Software Package Requirements & Procurement, 8th Int. Workshop on Software Specification & Design, IEEE CS Press, 1996.
6.
Franch, X , Systematic Formulation of Non-Functional Characteristics of Software, Proc. 3rd Int. Conf. on Requirements Engineering, (Colorado Springs, Colorado, USA, Apr 1998).
7.
Kontio, J., Caldiera G., and V. R. Basili, Defining Factors, Goals and Criteria for Reusable Component Evaluation, Proc. of the CASCON'96 Conference, (Toronto, Canada, 12-14 Nov 1996).
8.
Kotonya, G., and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley&Sons, 1997.
9.
Maiden, N. A.M., Ncube C., and A. Moore, Lessons Learned During Requirements Acquisition for COTS Systems, Communications of the ACM 40, 12 (Dec 1997).
10. Potts, C., Invented Requirements and Imagined Customers: Requirements Engineering for Off-theShelf Software, Proc. 2nd IEEE Int. Symposium on Requirements Engineering (York, UK, March 27-29 1995). 11. Powell, D., Arlat J., Beus-Dukic L., Bondavalli A., Coppola P., Fantechi A., Jenn E., Rabejac C. and A. Wellings, GUARDS: A Generic Upgradable Architecture for Real-Time Dependable Systems, IEEE Trans. on Parallel and Distributed Systems 10, 6, (June 1999), 580-599.
12. Scyperski, C., Component Software Beyond ObjectREFERENCES 1. Beus-Dukic, L., and A. Wellings, The Requirements for a COTS Software Component: A Case Study, Requirements Engineering 3, 2, 1998, SpringerVerlag, 115-120. 2.
Beus-Dukic, L, Criteria for Selection of a COTS RealTime Operating System: a Survey, 2000, (submitted for publication).
3.
Brown, A. W. (Ed), Component-Based Software Engineering, IEEE Computer Society Press, 1996.
4.
Deifel, B., Requirements Engineering for Complex COTS, 4th Int. Workshop on Requirements Engineering for Software Quality (REFSQ'98) (Pisa, Italy, 8-9 Jun 1998).
Oriented Programming, ISBN 0201178885, AddisonWesley, 1998.
13. Sinclair, I. J.. The Use of Commercial Off-the-Shelf (COTS) Software in Safety-Related Applications. HSE Contract Research Report 80/195. 14. Vidger, M. R., Gentleman, W. M., and J. Dean , COTS Software Integration: State-of-the-art, Technical Report, National Research Council Canada, Jan 1996.
4
