Defining Goals in a COTS-Aware Requirements Engineering Approach
Lawrence Chung Kendra Cooper Dept. of Computer Science Dept. of Computer Science The University of Texas at Dallas The University of Texas at Dallas MS EC 31 P.O. Box 830688 MS EC 31 P.O. Box 830688 Richardson, TX, USA Richardson, TX, USA [email protected] [email protected]
Abstract. The goals of developing systems better, faster, and cheaper continue to drive software engineering practitioners and researchers to investigate software engineering methodologies. In requirements engineering, the focus has traditionally been on modeling the software engineering process and products for systems that are being built from scratch. As the size and complexity of systems continues to grow the use of commercial off the shelf
(COTS) components is being viewed as a solution. Effective use of COTS components, however, requires a systematic approach that provides both a set of concepts for modeling the subject matter and a set of guidelines for using such concepts. In particular, the process needs to recognize and address the people oriented problems including the identification and resolution of conflicting goals, bridging the gaps between stated requirements and
'approximately fitting' components while still satisfying the customer. In this paper, we present a goal and agent oriented requirements engineering process model that explicitly addresses the use of COTS components. More specifically, we present (part of) our model for a COTS-Aware Requirements Engineering (CARE) process and illustrate it using a Digital Library System.
1 Introduction
In Software Engineering, researchers strive to improve the tools and techniques used to deliver high quality, large-scale systems that are on time and within budget. More specifically, the benefits of improving these tools and techniques include reducing the time to market, engineering time, development cost, defects, code size, product documentation, and the impact of personnel changes through the definition of clearly defined models. In addition, as software engineering techniques are improved, the consistency of applying a technique and customer service are also improved.
The use of commercial off-the-shelf (COTS) components is perceived as a means to deliver large, complex systems, potentially with significant improvements in quality, development time, and cost. Effective use of these components, however, presents both opportunities and risks. COTS components, on the one hand, can lead to the perceived benefits, since they are pre-packaged solutions which presumably have already gone through the various time-consuming and costly phases of requirements specification, design, coding, and well tested through use over time. On the other hand, COTS components can also lead to quite the opposite of their perceived benefits. They may poorly satisfy the stakeholders’ requirements, evolve rapidly or be discontinued by a vendor, have unexpected interactions, lead to the late discovery of errors in the system and as a result lead to significant rework or perhaps even the cancellation of the project, etc. But, why?
Ideally, the components have been used by a substantial number of customers and gone through a number of development iterations, reducing the defects in the product. At the surface level, the problem of using COTS components seems straightforward: the developers need only select the components and integrate them together like
“lego” blocks. At a deeper level, however, there are many inter-related technical, legal, and business issues involved in effectively using COTS components. Technical issues, stemming from the complexity of the COTS components themselves, include how to represent the COTS components, select components that provide the functional and non- functional characteristics needed, identify incompatibilities among the components, integrate the components together, utilize rapidly evolving components, and replace discontinued components in a continuously evolving system.
The evolution, or maintenance, of a COTS based system is of particular concern. If a COTS software package is procured during the early development phase of a program, then it is likely that the next generation of the component is released sooner than the next generation of the system. Invariably, when errors are discovered, greater performance is desired through an evolution of requirements or other subsystems must be accommodated, the software must be maintained many years beyond the COTS original version. The supplier of the COTS component may not be in business or may be unwilling to provide maintenance for such long periods of time.
Technical issues also arise from the complex interactions between systems and their environments [Anton,
1998], [Yu, 2001], [Wooldridge, 1999], [Wooldridge, 2001]. For example, systems are not only distributed, but the distributed components are operated by independent organizations with different business goals, strategies, etc. The systems have numerous stakeholders, or agents, each with goals that may conflict or be synergistic with other stakeholders' goals. For example, one group of stakeholders may say "the security of the system should be of the utmost concern", while at the same time another group may say “the system should be as easily changeable as possible, and that should be the top priority”. To successfully deliver these complex systems, the software engineering process needs to support identifying the agents and their goals, exploring and documenting potential alternative configurations, and negotiating the conflicts that arise from this activity.
Along with the task of defining the goals and requirements of the system, the availability of suitable COTS components must be considered throughout the requirements engineering process, as it may constrain the goals and requirements for the system. This is significantly different from a standard software development lifecycle where the requirements for the system under development are gathered, analyzed, revised, and baselined without regard to which requirements may, or may not, be delivered to the customer using COTS components. When the software development process is using COTS products, however, the process of developing the requirements must change, i.e., by considering the capabilities of available COTS products as the goals and requirements are defined and negotiated.
The use of COTS products also impacts the architecture, or high-level design, phase of the software development lifecycle. In a standard software development lifecycle, the architecture is developed to fulfill the requirements of the system without regard to the availability of COTS components. In order to use COTS components, however, the requirements and/or the architecture may need to be significantly modified (causing delays and an increase in cost) since there may be few, or even no, available components that fit within the requirements and/or the chosen architecture [Brownsword, 2000], [Brownsword, 1998]. Nonetheless, the architecture should be developed while defining the requirements and also while considering the constraints of available COTS components in such a way that the requirements specification and architecture for a system meet the customer’s needs and optimize for the use of COTS components.
From a business perspective, the issues involve the short-term and long-term costs and benefits of using COTS components. Project managers need to consider the cost of the components, quality of the vendor, lack of control over the support and evolution of the COTS components, licensing issues, and the associated risks.
Effective use of COTS components, thus, inevitably requires a well-disciplined systematic methodology that would facilitate the exploitation of the benefits of COTS components while guarding against the pitfalls of such components. The goal of this project is the provision of such a methodology, called COTS-Aware Requirements
Engineering (CARE), during the Requirements Engineering phase. CARE is both goal oriented (as in [Anton, 1998], [Chung, 2000], and [van Lamsweerde, 2000]) and agent oriented (as in [Yu, 1994], [Wooldridge, 1999], and
[Wooldridge, 2001]). The CARE approach, intended to assist the requirements engineer, but not to replace their intelligence and experience, is described with a process, product, and a meta-model. The process model is the focus of this work. In particular, due to space limitations, here we present only part of the process model that supports the definition of system goals and demonstrate its use with a Digital Library System (hereafter, DLS) application. A more complete description is available in the complementary technical report [Chung, 2002a].
This paper, an extended version of the work presented in [Chung, 2002b], is organized as follows. Following the introduction, we present related work in Section 2. In Section 3, we present an overview of the CARE approach followed by a more detailed description of part of the CARE process model that supports the definition of system goals. The CARE approach is illustrated with an example from a DLS in Section 4. Conclusions and future work are in Section 5.
2 Related Work
The CARE approach draws upon research in a number of areas including agent- and goal-oriented paradigms, knowledge engineering, process engineering, and COTS based software engineering work. In this section, we discuss other COTS research. In the future, we are going to also draw upon recent research in bridging requirements and architecture models such as [Egyed, 2001], [In, 2001], and [Nuseibeh, 2001] as we plan to extend the CARE approach to consider the concurrent development of architecture and requirements models.
A significant body of investigative work that identifies issues and/or proposes a classification or framework for pursuing further research has been presented [Basili, 2001], [Beus-Dukic, 1998], [Braun, 1998], [Brownsword,
2000], [Brownsword, 1998], [Dean, 1999], [Maiden,2002], [Voas,1998]. The issues involved with developing a complex system with COTS components are extensive; they impact the requirements, architecture, implementation, testing, maintenance, COTS selection and evolution, project management, cost estimates, licensing, etc. These issues have been categorized as technical, legal, management, business, and strategic concerns.
As work has progressed in the area of COTS research, specific solutions have been proposed to address some of these issues. Recently, solutions to the problems of how to evaluate [Addy, 1998a],[Brenner, 2001],[Briand, 1998],
[Korel , 1998], [Morisio, 1997], [Morris, 2000], describe [Addy 1998b], [Addy, 1999], [Morisio, 2002], [Yen,
2002], [Yen, 2001], select [Briand, 1998], [Hissam, 2002], [Illa,2000], [Kunda, 1999], [Morisio, 2002], [Morisio, 1997], [Seacord, 2001], and integrate [Hissam, 2002],[Seacord, 2001], [Yen, 2002], [Yen, 2001] COTS components have been proposed in the literature. Issues related to testing [Hissam, 1999], [Hissam, 1998], and maintaining
[Carney, 2000], [Hybertson, 1997], [Vidger, 1998] COTS intensive systems have also been presented. From a project management perspective, an estimation model for the economic life-span of systems using COTS components is described in [Abts, 2000], the cost of using COTS components is addressed in [Erdogmus, 1999],
[Hall, 2001], [Jensen, 1997], [Voas, 1998], [Voas, 2000], and an approach considering the risks associated with the use of COTS has been proposed in [Ballurio, 2002].
Here, we discuss some of the approaches that offer specific technical solutions that are applicable to the early phases of Software Engineering: Rational Unified Process (RUP), Model-Based Architecting and Software
Engineering (MBASE), Procurement Oriented Requirements Engineering (PORE), and Off-The-Shelf Option
(OTSO). We recognize this survey is not exhaustive.
RUP is a comprehensive, object oriented software engineering process model [Jacobson, 1999], which is based on four phases (transition, construction, elaboration, and inception) and a collection of core process disciplines (or workflows) including business modeling, requirements, analysis and design, implementation, test, deployment, etc.
We include the RUP in our survey because it is an established, well accepted process. Although the RUP is not goal- or agent-oriented, it does support the use of a component based architecture. A component is defined in [Krutchen,
2001] as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture. In the unified modeling language (UML), a COTS component is represented as a component, a physical and replaceable part of the system that provides a set of interfaces and typically represents the physical packaging of classes, interfaces, and collaborations [Krutchen, 1998].
With the RUP, the use of component based architecture can proceed in several ways. In addition to supporting a more traditional approach in which a system is built from scratch, RUP also supports building a system with the intent of developing re-usable, in-house components and an assembly approach of building software from commercial off-the-shelf components. The RUP supports a component approach in a number of ways. The iterative approach allows developers to progressively identify components and choose the ones to develop, reuse, or buy. The structure of the software architecture describes the components, their interactions, how they integrate. Packages, subsystems, and layers are used during analysis and design to organize components and specify interfaces. Single components can be tested first followed by larger sets of integrated components. For our requirements engineering work, we integrate the iterative approach in our process. When CARE is extended in the future to include the architecture model, additional aspects of RUP are going to be integrated.
The Model Based Architecting and Software Engineering (MBASE) approach focuses on the early phases of software engineering. It considers four types of models: success, process, product and property [Boehm, 1998] and is consistent for use with COTS components [Boehm, 2000]. MBASE uses four guiding principles to develop value- driven, shared-vision-driven, change-driven, and risk-driven requirements. From the MBASE framework, we draw on the ideas of developing a consistent set of models that are goal (i.e., success) driven and support the use of COTS components. In addition, we also use the tabular format presented in MBASE examples for our product model.
From the Procurement Oriented Requirements Engineering (PORE) technique, we draw on its support for the iterative evaluation and selection of COTS components [Maiden, 2002], [Ncube, 1998]. The PORE process model identifies four goals in a thorough COTS selection process: a) acquiring information from the stakeholders, b) analyzing the information to determine if it is complete and correct, c) making the decision about product requirement compliance if the acquired information is sufficient, d) selecting one or more candidate COTS components. The PORE approach also defines a meta-model that is composed of the following constructs: agents, actions (these are performed by agents), events (these trigger actions), goals (these are accomplished by actions), objects in the domain, state of an object, state transitions of objects, components, and functions provided by the product.
The Off-The-Shelf-Option (OTSO) proposed by [Kontio, 1995] method provides specific techniques for defining evaluation criteria, comparing the costs and benefits of alternative products, and consolidating the evaluation results for decision making. The definition of hierarchical evaluation criteria is the core task in this method. It defines four different subprocesses: search criteria, definition of the baseline, detailed evaluation criteria, weighting of criteria. OTSO recognizes the lack of attention to requirements as a key problem in COTS selection, but does not provide a specific solution. The method assumes the requirements exist; they are used to define the evaluation criteria.
3 The CARE Approach
The CARE approach draws upon the good ideas available in current RE methodologies including RUP, MBASE, and PORE. The aim is to complement and extend these methodologies in order to provide a requirements engineering methodology that is agent- and goal-oriented, and explicitly supports the use of COTS components. We realize that developing a complete methodology that supports the use of COTS is a large, complex problem. We are taking an iterative approach to systematically develop CARE. Our current focus is on developing a set of models that provide a foundation for the research; the goal is to define a methodology that supports the definition and selection of COTS components from a technical view. In practice, technical aspects cannot be used in isolation from other considerations such as risk management, maintenance, etc. to select the components. The current work addresses these related issues in a preliminary manner; in the future the CARE models are going to be extended to consider the project management aspects in greater detail. Here, we provide an overview of the CARE approach followed by a more detailed description of part of the CARE process model that supports the definition of system goals.
The CARE approach is being developed using a set of examples for a DLS. In this description of the model, the customer is contracting the development of a large-scale system and is involved in the development work.
Variations of this model can be developed in the future to consider high volume, shrink-wrap product development.
3.1 Overview of CARE The CARE approach is characterized as agent-oriented, goal-oriented, knowledge based, and has a defined methodology, or process. A high level view of the CARE approach is illustrated in Figure 1. On the right side of the figure, the early artifacts for the system under development are accounted for including the agents, softgoals (non- functional goals that are achieved not absolutely but in a “good-enough” sense), hardgoals (functional goals), system requirements, software requirements, and architectural elements. The traceability relationships among the artifacts are also established and maintained (e.g., a softgoal is refined and traced to specific system requirements). On the left side of Figure 1 the descriptions of the COTS components are stored and maintained in a knowledge base, or repository. For each COTS component, the high-level goals (softgoals and hardgoals) and the chosen product specifications which meet the goals are stored and maintained. The goals provide high-level descriptions of the capabilities of a COTS component; they contain information like that found on marketing brochures for existing products. These general descriptions provide enough information, at least initially, for a RE to determine if the product appears to be potentially useful and, as a result, warrants further investigation. A product specification is the detailed description of the functional and non-functional characteristics of the projected system, including its components and relationships between the components, which, as a means/solution, meets the (potentially conflicting) goals and constraints of the various stakeholders, technical constraints, laws, etc. [Davis, 1993] [Loucopolos, 1995]; they contain information like that found on the technical product specifications or data sheets for an existing product. When using the CARE approach, the RE identifies possibly matching COTS components for the goals and subsequently, the requirements and architectural elements of the system under development; these mapping relationships are also established and maintained.
CARE is Agent-oriented. The CARE approach is agent-oriented, as it considers the identification, definition, and interactions among agents, or stakeholders, for a system. An agent is intentional and possesses intentional properties including goals, beliefs, abilities, and commitments. An agent is also autonomous and makes decisions, choices, and depends on other agents to accomplish goals, complete tasks, or furnish resources. An agent can analyze its opportunities and risks in the various proposals and configurations for a system.
The notation used to support this aspect of the CARE approach is drawn from the i* framework [Yu, 1994], which describes agents, hardgoal and softgoal dependencies among agents, and how agents accomplish a goal in terms of subgoals, tasks, and resources. These concepts are embedded into the conceptual modeling language Telos
[Mylopolous, 1990], a descendent of RML [Greenspan, 1994]- an object-oriented requirements modeling language for functional requirements. As a result, i* provides an extensible, object-oriented representational framework with classification, generalization, aggregation, attribution, and time.
An overview of CARE is presented with an agent-oriented perspective using the i* Framework in Figure 2.
There are two models in the i* Framework: the strategic dependency and the strategic rational model. In the strategic dependency model agents are represented with a circle, hardgoals are represented with ovals, softgoals are presented with melted oval shapes, and the dependency of one agent upon another to accomplish a goal are represented with a
"D" shaped symbol on an edge. A hardgoal, or functional goal, describes a desired capability of the system. For example, a hardgoal in a DLS may be "the system should provide a variety of searching techniques". A softgoal, or non-functional goal, describes a desired property of the system such as ease of use, performance, maintainability, security, etc. For example, in Figure 2, a development house agent depends upon a customer agent to validate the system as it is being developed and provide (ideally) complete and correct information. A customer agent depends upon the development house to deliver a system (e.g., goals, system and software requirements, etc.) that is on schedule, within budget, and has high quality.
The strategic rationale model describes how an agent accomplishes a goal and is represented with a dotted line oval that intersects an agent. Within the strategic rational model the entities an agent uses to accomplish a goal are represented. These include tasks, represented with hexagons, and resources, represented with rectangles. In Figure 2, the development house accomplishes the goals of creating the baselined system agents, goals, system requirements, etc. using corresponding tasks.
CARE is Goal-oriented. Once the agents are identified, their goals for the system under development need to be defined. Here, we define a system goal as a high level objective for the system. The goals are characterized as hardgoals or softgoals. Examples of system goals for a DLS are the softgoal "the system should be easy to use" and the hardgoal "the system should provide searching techniques". As seen by these examples, a goal is a statement that may be ambiguous and unverifiable, especially softgoals, at least until they become concrete enough and turned into part of the system specification. In other words, a set of system level test cases cannot be defined to test the implementation with respect to a high-level goal.
Goal-orientation means treating high-level requirements as goals, then considering a variety of alternative ways to (help) achieve the goals, carrying out tradeoff analyses among the alternatives, and selecting among the potentially competing alternatives. A goal-orientation, thus, helps rationalize the whole process of development, here, the CARE process. When defining the system goals, the RE would usually go through successive refinements of a goal (called a parent) into one or more subgoals (called children). Such refinements can take the form of decomposition of goals into subgoals, identification of the conflicting and synergistic relationships among goals, and negotiation of the conflicts discovered. Such refinements can also involve operationalization of the goals, namely, determination of what kind of tasks are needed to achieve the goals, and who or what may carry them out – typically a human (agent), a hardware (agent), or a software system (agent) including the projected software system., Here, if the choice is the projected software system, then the particular goal becomes part of the system specification.
To address the complex problem of identifying, analyzing, and negotiating the numerous goals of diverse stakeholders, the NFR Framework (the Non-Functional Requirements Framework) [Chung, 2000], [Mylopolous,
1992] is integrated into the CARE process model. The NFR Framework provides a systematic approach for dealing with non-functional requirements. The NFR Framework uses a graphical representation called a softgoal interdependency graph (SIG), in which NFRs are treated as softgoals, along with operationalizations of NFRs and claims supporting or denying anything judgemental about such softgoals, and interdependency between softgoals is represented in terms of various types of contributions (such as make, help, hurt and break) which a softgoal can make towards another. Using this framework, functional alternatives can be explored and represented through AND and OR goal dependencies. An example of a SIG is illustrated in Figure 3. Here, the two highest level goals (NFR softgoals) shown are that the system should be easy to use and have a moderate cost. The relationship between these two goals is negative, which means that making the system easy to use hurts developing the system at a moderate cost. Also illustrated in this example is the decomposition of goals. The goal that the system should be easy to use is decomposed into three children: the system should have a configurable interface, have a graphical user interface, and support a variety of interface options. The configurable interface goal is further decomposed into the goals that the system should have an interface available for both expert and novice users. A variety of interface options goal is
AND-decomposed into architectural design components such as touch screen, voice recognition, etc.
(operationalized softgoals in ovals). Section 4 describes a more refined version of Figure 3, illustrating the use of several other important concepts of the NFR Framework.
The relationship between goals and requirements is as follows. As describe previously, a goal is a high level statement that may be ambiguous and unverifiable. The goals are used to define both the requirements and the initial system architecture. The goals are refined into system level requirements that have the traditional characteristics of a
"good" requirement: they are unambiguous, verifiable, correct, concise, traceable, etc. In turn, system requirements may be refined into software requirements.
CARE has a Defined Process. An overview of the CARE process is described from an activity-oriented perspective using the IDEF0 notation (refer to Figure 4). At a high level, the CARE process has activities to define the agents, goals (with COTS), system requirements (with COTS), software requirements (with COTS), and architecture (with COTS). Each of the activities corresponds to developing a product artifact for the system.
Activities in the IDEF0 notation have inputs, mechanisms, control, and outputs. An activity is used to transform inputs into outputs. Mechanisms are the people or tools that perform the activity. Controls are used to constrain when or how the activity can be done. The mechanisms in CARE are the requirements engineer (RE), system architect (SA), and component engineer (CE). In the future, alternative notations for documenting the process are going to be investigated including IDEF3 and the activity diagram from the Unified Modeling Language (UML).
CARE is Knowledge Based. The CARE approach uses a knowledge base (repository) that is populated with descriptions of components. The descriptions of the COTS components are stored and maintained at two levels of abstraction: their goals (softgoals and hardgoals) and their detailed specifications (functional and non-functional).
The goals provide high-level descriptions of the functional and non-functional capabilities of a component; they contain information like that found on marketing brochures for products. The description provides enough information for a reader to determine if the product appears to have the potential for use and warrants further investigation. The product specifications are the detailed descriptions of the functional and non-functional characteristics of a component; they contain information like that found on the technical product specifications or data sheets for a product. The attributes stored and maintained for a product specification include: unique identifier; type; name; list of keywords and weights (used for keyword and case based searching); functional overview; domain; vendor; vendor evaluation; version number; operating system requirements; standards compliance; interface; performance; security; availability; reliability; processor requirements; primary memory requirements; disk space requirements; bandwidth requirements; related subcomponents; history; lessons learned; assumptions; and notes. Examples of component are presented in Appendix A. Currently, information about the interactions among components (incompatibilities, emergent behavior, etc.) may be captured as lessons learned or notes. As the
CARE approach matures, additional attributes may be included to define interactions among COTS components.
To be useful, the repository must be maintained. In CARE, the Component Engineers are responsible for a wide range of tasks including finding and evaluating new components, evaluating vendors, tracking the release of new versions, evaluating new versions, tracking the retirement of existing versions, selectively adding new components to the repository and deleting those that are no longer needed, as well as providing technical expertise to the development personnel (RE, architect, etc.). With a thorough understanding of the components (capabilities, maturity, vendor, etc.), the CE helps to reduce the risk of using them in a system under development.
In the CARE approach both kinds of descriptions, the goals and the product specifications, are used. As the goals are defined, analyzed, and negotiated, the RE searches the repository for COTS components that appear to be
(possible) matches. As the system develops, goals are refined into requirements and the RE determines if the identified components still seem suitable or if other components seem to be a better fit.
3.2 Defining baselined system goals with the CARE process
The process to define the baselined system goals is illustrated in Figure 5 and Figure 6. Additional parts of the process model (e.g., the process to define system agents, requirements, software requirements) are available in
[Chung 2002a]. Here, we use the term baselined to indicate a set of goals have been agreed to and are suitable for use as a working model. The task of creating the baselined system goal model can be decomposed into a set of subtasks including elicit, analyze, correct, validate, define COTS goals, and baseline a set of system goals. The first step in the process is to elicit a set of initial goals. A variety of elicitation techniques are available including interviews, checklists, reviewing the existing documentation of a system, etc. Since goals may be very abstract, the RE may need to decompose them. For example, a softgoal "the system should be scaleable" leads the
RE to ask the question "scaleable in what way?" When interviewed, one stakeholder may intend this goal to mean the system should be scaleable to support a higher number of concurrent users. Another may intend this goal to mean supporting additional data in the database. In addition to decomposing the goals, the RE also needs to document the relationships among the goals. To characterize the relationships between goals, the NFR Framework is used. It provides a set of rankings of the relationships between two softgoals, including: very positive (++), positive
(+), neutral (no line, label), negative (-), and very negative (--). The relationships are defined informally as follows:
Softgoal 1 is very positively related to Softgoal 2: Softgoal 1 significantly helps to accomplish Softgoal 2.
Softgoal 1 is positively related to Softgoal 2: Softgoal 1 helps to accomplish Softgoal 2.
Softgoal 1 is negatively related to Softgoal 2: Softgoal 1 hurts the accomplishment of Softgoal 2.
Softgoal 1 is very negatively related to Softgoal 2: Softgoal 1 significantly hurts accomplishing Softgoal 2.
Once an initial set of goals is defined, the RE analyzes them to identify errors of commission (conflicting, incorrect, and redundant goals) and omission (missing goals). The RE corrects goals, removes redundant goals, adds missing goals, and negotiates conflicting goals. The stakeholders validate the goals to ensure the RE understands their needs and wants.
The process of eliciting, analyzing, correcting, and validating goals may be iterative. When the stakeholders have no major issues with the goals defined, the RE begins the process to identify hardgoals that may be candidates for implementing with one or more COTS components. For each candidate, the RE performs a search on the repository that returns functional goal descriptions of the components that match the search criteria. The repository supports a keyword and case based search. The keywords used in the COTS component definitions are used to build a glossary of terms that is made available to the RE; the RE selects keywords from this glossary of terms. The RE evaluates the results of the preliminary search and determines which of the components (if any) may be a possible match to a hardgoal. The RE performs a search on the repository for the components that appear to satisfy the preliminary match; detailed descriptions of the functional and non-functional descriptions of these components are returned (refer to Appendix A for an example). The RE evaluates the results of the detailed search and determines which of the components is a close or exact match to the goals. Due to the early stage of development, the RE is not likely to have enough information to evaluate the component completely for its use in the system under development. For example, a component may support MPEG 3 but not MPEG 4; the RE may not know at this point if the earlier standard is suitable.
The RE evaluation of a component is performed with the assistance of the CE and the SA. The CE may assist the RE by responding to requests for additional information about the components, or requests for new or modified components. The SA may assist by providing additional information of the impact of components on the system architecture. Based on the evaluation results, (e.g., a COTS component is available that provides similar capabilities), the RE may need to iteratively bridge the gap between the currently available components in the repository and the stakeholder's goals for the system under development (refer to Figure 7). The RE's options include making a request to search for additional COTS components available in the marketplace, change a COTS component, or change a goal for the system under development. The RE may ask the CE to either search for additional COTS components that may be added to the repository or request a change to a component (where the change is made by the vendor). For example, if a COTS component that provides the necessary functional capabilities is described as high performance and high cost, the development house may negotiate with a vendor to provide a modified component with moderate performance and moderate cost. Negotiations with the stakeholders to modify a goal for the system under development may be possible.
If a COTS component cannot be identified at this point to provide the capabilities needed, then the RE documents these results. When the goals are refined into system level requirements, the RE can search for suitable
COTS components again.
After the goals have been elicited, analyzed, corrected, validated, and potential COTS components identified, then they are baselined and placed under configuration management.
4 Defining System Goals: Illustration
The CARE approach is being developed iteratively by working through a set of examples in a DLS. The initial
CARE process is based on the examples used to develop the system requirements (with COTS) using a database, communication, and audio video components [Chung, 2001] and [Chung, 2002a]. In this work, we present another example in order to validate and refine the step in the process in which the system goals are defined. This example addresses the conflicting goals of ease of use, scalability, performance, and cost for the system.
Here, the digital library (DL) refers to the digital library organization as a whole. It may consist of people, software, hardware, and interfaces to external agents. The DLS refers to the goals that need to be met by the software system. The DLS stakeholders identified include the librarians (junior and senior), the system administrator, the borrowers, and the managers that authorize the contract for the system to be built. For this example, the preliminary goal data considered includes that the system should be easy to use, fast, scalable, and moderately priced. The list of preliminary goal data is available in Appendix B. Our DLS is an academic example and we do not have real stakeholders to interview. The data has been obtained from existing products on the market, experts in the digital library community, and a system level specification of our DLS.
The RE may iteratively elicit, analyze, and correct the system goals by asking what, how, and who questions about the preliminary goal data. For example, the RE asks "what makes a system easy to use?", "for whom should the system be easy to use?", "in what way should the system be scaleable?", "what is an approximate range for a moderately priced system?", etc. Some of the results are summarized below.
Easy to Use. The initial goal that the system should be easy to use is decomposed into the following: the system should provide a graphical user interface (hardgoal), the system interface should be configurable (hardgoal), and the system should provide a variety of interface options such as touch screen, voice recognition software, audio and video players, etc. (hardgoal). The subgoal that the system interface should be configurable is further decomposed into the system should provide at least one interface that is suitable for a novice user (softgoal) and at least one interface for an expert user (softgoal).
Scaleable. The initial goal that the system should be scaleable is decomposed into the following hardgoals: the system should offer a functionality for the addition of new collections (i.e., new kinds of library objects) and the system should offer a functionality for additions to the current collections.
Moderate Cost. The initial goal that the system should be moderately priced is clarified to mean that the system is neither very cheap (with few features) nor very expensive (with a large number of features). The stakeholders' perception of "moderate cost" (with input from their procurement personnel), is captured by updating the softgoal: the system should be moderately priced, with a budget of $100,000.
Fast Performance. The initial goal that the system should have fast performance is clarified to mean that the system is perceived by the end users to be fast even when the system is loaded with the maximum number of users. The conditions under which the stakeholders expect the system to be "fast" are captured by updating the softgoal: the system should have low response time even when the system is loaded with the maximum number of users.
Easy to Maintain. The intitial goal that the system should be easy to maintain is clarified to mean that the system is well-modularized and the components are easy to maintain. The goal that the components are easy to maintain is further refined to mean that vendor-supplied components are easy to maintain and in-house components are easy to maintain.
Minimum Risk. The initial goal that the system should be developed with minimum risk is clarified to mean that the system is developed in an environment where the technical, people, development platform risks, etc. are managed. As part of the risk management the technical risks associated with the use of COTS components need to be reduced by their early and systematic identification, evaluation, and selection.
Now that the goals in the example are decomposed and clarified, the RE identifies and characterizes the NFR
Framework relationships among them. Figure 8 shows some of the refinements. In this figure, the ease of use, performance, and scalability softgoals are characterized as hurting the softgoal moderately priced. The availability of an interface that is suitable for experts is characterized as helping performance.
After the goals are elicited, analyzed, and corrected, domain experts are asked to validate the interpretation and refinement of the goals. In this example, a request for comments is sent to the Digital Library community for feedback. The experts do not return any comments that apply to the goals of the system.
At this point, the RE evaluates each hardgoal and determines if it is a candidate for implementing with one or more COTS components. Currently, this evaluation and selection is based on the RE’s experience. For example, the
RE selects the following hardgoal as a candidate: the system should provide a variety of CHI options that include touch screen, voice recognition, traditional mouse and keyboard, audio and video players.
The RE performs a search on the repository that returns the high level descriptions (i.e., the goals) of the COTS components. Here, the RE performs a preliminary search in the repository using the keywords “touch screen”,
“voice recognition”, “audio”, or “video”.
We continue in this example with the results of the search for “audio” or “video”. The goals for the following components are returned:
1. RealSystem Server 8, RealPlayer 8 and SDK by RealNetworks, Inc. should support
1.a) streaming and playback of audio and video, 1.b) multiple file formats. 2. Java Media Framework (JMF) by Sun Microsystems, Inc should support 2.a) adding
audio and video to Java applications and applets, 2.b) streaming and playback of audio
and video, 2.c) capturing audio and video, 2.d) multiple file formats, 2.e) transcoding
multiple file formats, 2.f) extending the multimedia capabilities on the J2SETM platform.
3. Java MFastView Plus, web browser plug-in by RealNetworks, Inc. should support 3.a)
compatibility with a variety of web browsers, 3.b) opening and printing audio and video
on a Web page, view files and e-mail attachments, 3.c) multiple file formats.
The RE evaluates the results of the preliminary search and determines which of the components may be a possible match to the stakeholder’s goal. Based on the preliminary results, the RE determines that either of the first two components may be matches. The plug-in (Java MFastView Plus) is rejected by the RE as a possible match because the initial concept of the system is to deliver an application, not a browser applet.
The RE performs a search on the repository for the components that satisfy the preliminary match. The detailed descriptions of these components are returned (refer to Appendix A).
When evaluating the components, the RE asks questions such as (refer to Table I):
What are the project management impacts of using the RealNetwork Server
(schedule, cost, quality concerns, new risks, training, etc.)?
What are the technical impacts of using the RealNetwork Server as a component
(maintenance, performance, security, administration, etc.)?
Based on the component descriptions, the goals of the system under development appear to partially match the goals of two components in the repository. For example, the system under development needs to support a variety of interface options including audio and video. The JMF supports a wide variety of audio and video formats (as described in its standards compliance attribute). The RealNetwork Server also provides capabilities to support a wide variety of formats on a server. Both components are mature in their development and are offered by well- known vendors, reducing the risk of selecting either.
Although it initially appears that the RealNetwork Server matches the functionality needed, the vendor’s expected use of the component does not fit with the current understanding of the architecture of the system. The current view of the architecture is that there is a separate commercial database used to store the library items and their meta-data. Discussions with the RealNetwork Server vendor reveal that this is not the standard deployment of their component, but it is possible to do. Normally, their server is used to store and send multimedia files.
With this information, the RE considers three options.
Option 1. Use the RealNetwork Server and retain the current design view of architecture. To make this decision, the RE needs to go through the documentation for the component to determine how this can be accomplished with the component. If this option is selected, a prototype of the solution with the assistance of the CE is highly recommended. The results of the prototyping effort can be used to demonstrate the feasibility of this option.
Option 2. Use the RealNetwork Server and change the design view of architecture. To make this decision, the
RE needs to consult with the system architect to identify and estimate the technical impacts of changing the architecture and with the project manager to identify and estimate the project management impacts.
Option 3. Use the JMF and retain the current design view of the architecture. While investigating this component, the RE determines that the JMF does not support a well known compression standard, MPEG-4.
Although this does not yet exist as a system requirement (we are only working on the goals at this point in the development), the lack of support for MPEG-4 is documented.
Discussions with the system architect lead to the selection of Option 3. The RE and SA determine the current view of the architecture, using a separate commercial database has a number of advantages including scalability, administration support, and security features. Since the client side needs to be developed (the RealNetwork Server component does not provide this functionality), the decision is made to develop both the client and the server with the JMF.
In addition, when reviewing the results of the detailed search the RE determines that the non-functional goals of the components do not map to the softgoals of the system under development. More specifically, the non-functional descriptions of the COTS components consider the quality of the audio and video to be important capabiltities. After investigating the mismatch the RE determines that a “quality” softgoal for the system under development is missing and needs to be added. The new softgoal is that the interface should present high quality audio and video to the user.
The RE documents the rationale for the decisions; the goal model is baselined.
5 Conclusions and Future Work
We have presented an overview of our process model for an agent- and goal-oriented requirements engineering approach that explicitly supports the use of COTS components, called the COTS-Aware requirements engineering
(CARE) approach. At a high level, the process model includes activities to define the baselined agents, goals, and requirements (system and software). The agents involved include the development house, customer, and component vendor. After the overview, we present and validate the activity to define the system goals (with COTS). This activity is refined into steps to elicit, analyze, correct, validate, identify (possible) COTS components, and baseline the defined goals. An example is given to demonstrate the applicability of this part of the model to a DLS. The example describes some of our own experiences using the approach while more details can be found elsewhere
[Chung 2002a]. For example, it highlights some of the complexities involved in selecting COTS components, especially when the specifications available from vendors are not complete, hence an RE being unable to select a component without contacting the vendor for additional information.
There are a number of important aspects of the research to investigate. Our next step is to more fully use the process to develop the DLS and also develop other applications in order to validate, improve, and extend the model.
The extensions are planned for several directions including the definition of additional kinds of requirements (e.g., hardware – memory, processor, etc.; interface; etc.), the concurrent development of the architecture with the requirements, and the maintenance of a COTS based system. In addition, negotiation techniques [Bussman, 1993] are going to be investigated and integrated into the CARE approach.
As the process model is validated, refined, and extended, the product model for the CARE approach also needs to be developed. Defining a product model which would allow the consistent use of a “mixed bag” of the various
OO, AO, and GO ontologies and methodologies for CARE is expected to be challenging. Among the challenges would be, for example, use of a particular notation such as JSD [Jackson, 1983] together with such a mixed bag of conventions. We also plan to investigate the use of multi-criteria decision making techniques (such as the analytic hierarchy process, outranking methods, etc.) to better assist the requirements engineer in the task of selecting COTS components.
References
Abts, C., A Perspective on the Economic Life Span of COTS-based Software Systems: the COTS-LIMO Model, TR USC-CSE-2000-503, USC Center for Software Engineering, 2000. Addy, E., "A Framework for Performing verification and validation in Reuse-Based Software Engineering", Annals of Software Engineering, vol 5, 1998, pp. 279-292. Addy, E. and Sitaraman, M., Bridging the Gap Between COTS Product Reuse and Formal Methods: A Case Study, Technical Report NASA-IVV-98-016, NASA/WVU Software Research Lab, Fairmont, WV, USA, 1998. Addy, E. and Sitaraman, M., "Formal specification of COTS-based software: a case study", Proceedings, 5th Symposium on Software Reusability, 1999, pp. 83-91. Antón, A.I. and Potts, C., “The Use of Goals to Surface Requirements for Evolving Systems”, Int. Conf. on Software Engineering, Kyoto, Japan, pp. 157-166, 19-25 April 1998. Ballurio, K., Scalzo, B., and Rose, L., "Risk Reduction in COTS Software Selection with BASIS", Lecture Notes in Computer Science 2255, 2002, pp. 31-43. Basili, V.R. and Boehm, B., “COTS-based systems top 10 list”, Computer, Vol. 34 Issue: 5, May 2001, pp. 91-95. Beus-Dukic, L. and Wellings, A., "Requirements for a COTS software component: a case study", Requirements Engineering, 3(2), 1998, pp. 115-20. Boehm, B. “Requirements that handle IKIWISI, COTS, and Rapid Change", IEEE Computer, Volume: 33 Issue: 7, July 2000, pp. 99 –102. Boehm, B., Port, D., Abi-Antoun, M., and Egyed, A. Guidelines for the Life Cycle Objectives (LCO) and the Life Cycle Architecture (LCA) deliverables for Model-Based Architecting and Software Engineering (MBASE), TR USC-CSE-98-519, USC-Center for Software Engineering, 1998. Braun, C., "Organizing for the effective reuse of commercial off-the-shelf (COTS) software", Proceedings, 6th International Conference on Fuzzy Theory and Technology, 1998, vol. 3, pp. 503-506. Brenner, E. and Derado, I., "Specifying a certification process for COTS software components using UML", Proceedings, 4th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 2001), pp. 291-297. Briand, L.C., "COTS evaluation and selection", Proceedings, International Conference on Software Maintenance, 1998, pp. 222-223. Brownsword, L., Oberndorf, T., and Sledge. C.A., "Developing new processes for COTS-based systems", IEEE Software, vol. 17 Issue:4, July-Aug. 2000 pp. 48 –55. Brownsword, L., Carney, D. and Oberndorf, T., “The Opportunities and Complexities of Applying Commercial- Off-the-Shelf Components”, CrossTalk , April, 1998. Bussman, S. and Muller, J., "A Negotiation Framework for Co-operating Agents", In Deen S M (Ed): Proc. CKBS- SIG, Dake Centre, University of Keele, 1992, pp. 1-17. Carney, D., Hissam, SA.., and Plakosh, D., “Complex COTS-based software systems: practical steps for their maintenance”, J. of Software Maint.: Research and Practice, Nov.-Dec. 2000, vol. 12, no.6, pp. 357-76. Chung, L., Nixon, B., Yu, E., and Mylopoulos, J., Non-Functional Requirements in Software Engineering, Kluwer Academic Publishing, 2000. Chung, L. and Cooper, K., A COTS-Aware Requirements Engineering (CARE) Process: Defining System Level Agents, Goals and Requirements, version 2, TR UTDCS-11-02, Department of Computer Science, The University of Texas at Dallas, 2002. Chung, L. and Cooper, K., “A COTS-aware Requirements Engineering Process”, Proceedings, INCOSE ’02 Symposium, July, 2002, paper number 3.5.4, pp. 1-8. Chung, L. and Cooper, K., “Towards a Model-based COTS-aware Requirements Engineering Process”, Proceedings, MBRE '01 Workshop, November, 2001, pp. 52-61. Davis, A. M., Software Requirements: Objects, Functions, States. Prentice Hall: Englewood Cliffs, 1993. Dean, J.C., “Ensuring the capability of COTS products”, Proceeding, 23rd Annual International Computer Software and Applications Conference, 1999, pp. 96-97. Egyed, A., Grunbacher, P., and Medvidovic, N., “Refinement and Evolution Issues in Bridging Requirements and Architecture - The CBSP Approach”, 1st Int. Workshop From Software Requirements to Architectures 2001 (STRAW'01). Erdogmus, H. and Vandergraaf, J., "Quantitative approaches for assessing the value of COTS-centric development", Proceedings, 6th International Symposium on Software Metrics, 1999, pp. 279-90. Federal Information Processing Standard (FIPS) Publication 183, Integration Definition for Function Modeling (IDEF0), December 21, 1993. Greenspan, S., Mylopolous, J., and Borgida, A., “On formal requirements modeling languages: RML revisited”, Proceedings, 16th International Conference on Software Engineering, 1994, pp. 135-147. Hall, J. and Naff, R., "The cost of COTS", IEEE Aerospace and Electronic Systems Magazine, 16(8), Aug. 2001, pp. 20-24. Hissam, S., "Experience report: correcting system failure in a COTS information system", Proceedings, International Conference on Software Maintenance, 1998, pp. 170-176. Hissam, S. and Carney, D., "Isolating faults in complex COTS-based systems", Journal of Software Maintenance: Research and Practice, 11(3), 1999, pp. 183-99. Hissam, S., Moreno, G., Stafford, J., and Wallnau, K., "Packaging Predictable Assembly", Proceedings, IFIP/ACM Working Conference, Component Deployment 2002, Lecture Notes in Computer Science 2370, editor J. Bishop, pp. 108-124. Hybertson, D., Ta, A., and Thomas, W., "Maintenance of COTS-Intensive Software Systems", Journal of Software Maintenance, 9(4), 1997, pp. 203-216. Illa, X, Franch, X., and Pastor, J., "Formalising ERP Selection Criteria", Proceedings, 10th International Workshop on Software Specification and Design, 2000, pp. 115-122. In, H., Kazman, R., Olson, D., “From Requirements Negotiation to Software Architectural Decisions”, 1st Int. Workshop From Software Requirements to Architectures 2001 (STRAW'01). Jackson, M., System Development, Prentice-Hall, 1983. Jacobson, I., Booch, G., and Rumbaugh, J., The Unified Software Development Process, Addison Wesley Longman, Inc., USA, 1999. Jensen, R., "Estimating the Cost of Reuse", Crosstalk, vol. 10, no. 5, 1997, pp. 17-21. Korel, K., “Black-Box Understanding of COTS Components”, 7th Int. Workshop on Program Comprehension, 1998, pp. 92-99. Kruchten, P., “Modeling Component Systems with the Unified Modeling Language”, International Workshop on Component-Based Software Engineering, 1998. Krutchen, P., “What is the Rational Unified Process?”, Rational Edge e-zine, http://www.therationaledge.com/content/jan_01/f_rup_pk.html, January, 2001. Kunda D. and Brooks L., "Applying social-technical approach for COTS selection" Proceedings, 4th UKAIS Conference, University of York, McGraw Hill. April 1999, pp 552 –565. Loucopoulos, P. and Karakostas, P., System Requirements Engineering, McGraw-Hill, 1995. Maiden, N., Kim, H. and Ncube, C. “Rethinking Process Guidance for Software Component Selection", Lecture Notes in Computer Science 2255, 2002, pp. 151-164. Morisio, M. and Tsoukias, A., "IusWare: A methodology for the evaluation and selection of software products", IEE Proceedings Software Engineering, 1997, pp. 162-174. Morisio, M., Seaman, C.B., Parra, A., Basili, V., Kraft, S., and Condon, S., "Investigating and Improving a COTS- Based Software Development Process", Proceedings, International Conference on Software Engineering, 2000, pp. 32-41. Morris, A., "COTS Score: an acceptance methodology for COTS software", Proceedings, 19th Digital Avionics System Conference, 2000, vol. 1, 4B2/1-8. Mylopoulos, J., Chung, L., and Nixon, B., “Representing and using nonfunctional requirements: a process-oriented approach” IEEE Transactions on Software Engineering, Vol. 18, Issue 6, June 1992, pp. 483-497. Mylopoulos, J., Borgida, A., Jarke, M., Koubarakis, M., “Telos: Representing Knowledge about Information Systems”, ACM Trans. Info. Sys., 8 (4), pp. 325-362, October 1990. Ncube C. and Maiden N, “Guiding parallel requirements acquisition and COTS software selection”, Proceedings, IEEE International Symposium on Requirements Engineering 1999, pp. 133-140. Nuseibeh, B. “Weaving the Software Development Process Between Requirements and Architectures”, 1st Int. Workshop From Software Requirements to Architectures 2001 (STRAW'01). Seacord, R., Mundie, D., & Boonsiri, S. "K-BACEE: Knowledge-Based Automated Component Ensemble Evaluation," Proceedings, Workshop on Component-Based Software Engineering, 2001. van Lamsweerde, A. and Letier, E., “Handling Obstacles in Goal-Oriented Requirements Engineering”, IEEE Transactions on Software Engineering, Special Issue on Exception Handling, Vol. 26, Sept. 2000. Vidger, M. and Dean, J.C., “Building Maintainable COTS Based Systems”, Proceedings, ICSM, 1998, pp. 132-138. Voas, J., “COTS Software: The Economical Choice?”, IEEE Software, March/April 1998, pp. 16-19. Voas, J., “The Challenges of Using COTS Software in Component Based Development”, IEEE Computer, June 1998, pp. 44-45. Wooldridge, M. and Ciancarini, P., "Agent-Oriented Software Engineering: The State of the Art," Handbook of Software Engineering and Knowledge Engineering, World Scientific Publishing Co., 2001, pp 1-28. Wooldridge, M., Jennings, N.R., and Kinny, D., "A Methodology for Agent-Oriented Analysis and Design" Proc. 3rd Int. Conf. on Autonomous Agents, 1999, pp. 69-76. Yen, I., Goluguri, J., Bastani, F., Khan, L., and Linn, J. , “A component-based approach for embedded software development”, Proceedings, 5th International Symposium on Object-Oriented Real-Time Distributed Computing, 2002, pp. 402 –410. Yen, I., Khan, L., Prabhakaran, B.,Bastani, F.B. ,and Linn,J. , “An on-line repository for embedded software”, Proceedings, 13th International Conferences on Tools with Artificial Intelligence, 2001, pp. 314 –321. Yu, E., "Agent Orientation as a Modelling Paradigm", Wirtschaftsinformatik. 43(2), April 2001, pp.123-132. Yu, E., Modelling Strategic Relationships For Process Reengineering, DKBS-TR-94-6, The University of Toronto, Canada, December 1994. Appendix A. Example Component Descriptions
Two example component descriptions are included in this Appendix. The first component is the Java Media
Framework (JMF); it is described in Table II. The second example is the RealNetwork Server component described in Table III.
Appendix B. The Initial System Goals
1. The DLS should be delivered with high quality, on time, and within budget
2. The DL should comply with current standards
3. The DL should be easy to use
4. The DL should have high availability
5. The DL should have fast performance
6. The users should be able to access a large number of diverse objects
7. The users should be able to search, browse, and retrieve objects quickly and efficiently
8. The librarians should be able to maintain the library quickly and efficiently
9. The librarians should be able to provide reference support quickly and efficiently
10. The administrators should be able to maintain users’ accounts quickly and efficiently
11. The DL should be scaleable
12. The DL should be secure
13. The DL should be inexpensive to operate
14. The DLS should be moderately priced Customer End User Development Requirements Manager Engineer Manager … Component ++ (NFR) External Repository Softgoal System 2 Softgoal HardGoal 3 1 Softgoals Hardgoals … System … Nonfunctional Requirement Functional Specification System System Specification Requirement Component 2 Artifacts
Softgoals Software … Hardgoals Requirement Nonfunctional Functional Software Specification Specification Requirement Component 1
Legend
Mapping System Goals to Component Goals Mapping System, Software Requirements to Component Specification Figure 1. An Overview of CARE Manage Risks Component Use Define Deliver System Agents Artifacts Define System Requirements Define Goals (with COTS) Deliver High Quality (with COTS) System …
Deliver Within Budget Customer Deliver Within Schedule Development Component System House Deliver On Time Component Deliver Within Budget Deliver High Quality System Component
Deliver Validate System Component Artifacts Artifacts Component Sales Legend Component Vendor Agent Hardgoal Dependency Relationship Task Softgoal
Figure 2. High-level Strategic Dependency and Rationale Models of CARE
Moderately Easy to Use … - Priced
Variety of Interface Graphical User Configurable Options Interface Interface
Configuration Configuration for Expert for Novice
Legend
softgoal and decomposition
Figure 3. NFR Framework Softgoal Interdependency Graph SA and RE Expertise Preliminary Agent Data Define System Agents Agent Model 1 A11 RE COTS Decision Making Technique WIP Agent Model SA and RE Expertise
Define System Preliminary Goal Data Goals (with COTS) Goal Model 2 A12 RE Goal Corrections WIP Goal Model COTS Decision Making Technique SA and RE Expertise
Define System Preliminary System Req. Data Requirements (with COTS) System Req. Model 3 System RE A13 Requirement COTS Decision Making Technique Corections WIP System Req. Model SA and RE Expertise
Define Software Preliminary Software Req. Data Requirements Software Req. Model (with COTS) 4 Software RE A14 Requirement Corrections WIP Software Req. Model
Component Request RE and SA Expertise Changes to Maintain Component Data System Models Component Repository RE and CE Expertise 6 Preliminary Architecture Data Define CE A16 Architecture Component Data Architecture (with COTS) Component 5 Repository Data A15 Where SA WIP is Work in Progress, SA is System Architect CE is Component Engineer, RE is Requirements Engineer, System Models are Agent, Goal, System and Software Requirement Models A1
Figure 4. A High Level Activity-oriented View of CARE WIP Agent Model WIP Goal Model (with COTS) Agent Model COTS Decision Preliminary WIP Goal Model Making Technique (initial) Goal Data Elicit SA and CE System Expertise Goals 1 WIP Agent Model
RE Agent Model WIP Goal Model Define Component Data WIP Goal Model COTS Component Data Analyze (analyzed) Goals Component System 6 Request Goals A126 2 RE
RE WIP Agent Model WIP Goal Model Agent Model Analysis Data WIP Goal Model Stakeholder Validation Data Validate (validated) Component Data System Goals 3 WIP Agent Model RE Agent Model Validation Data WIP Goal Model WIP Goal Model (ready for COTS) Component Data Correct System Goal Corrections Goals WIP Goal Model 4 (ready for baselining) RE Corrections Data WIP Goal Model
Baseline Goal Model System Goals 5
Where RE WIP is Work in Progress, SA is System Architect CE is Component Engineer, RE is Requirements Engineer
A12
Figure 5. Process to Define System Goals (with COTS) Nonexistant or Partial Matches
Goal Model Select Hardgoals Candidate Keywords Hardgoals Nonexisting or Partial Matches 1
RE Preliminary Component Data Component Component Request Matching 2 Preliminary Matches
RE SA, CE Expertise
Detailed Component Data Component Component Matching Request 3 Possible Component RE Matches
Bridge Component Request Component Data Component:Goal Gaps Using NFR Goal Request Where 4 Possible Component WIP is Work in Progress, SA is System Architect Matches RE CE is Component Engineer, RE is Requirements Engineer
A126
Figure 6. Process to Define COTS Goals Components Transformed Transformed SUD Components Components SUD Components
G-i G-i1’ G-j1’ G-j
G-i1’’ G-j1’’ G-i1’’’ G-j2’
G-k
G-k1’
G-k1’’ where SUD is the system under development G-i is a stakeholder's goal G-k2’
Figure 7. Bridging the Gaps Between SUD and COTS Component Goals fast - easy to moderate minimum easy to performance - scalable … use - cost risk maintain maintain
low resp. configurable time add items add new interface to existing graphical user collection … collection + interface high quality interface variety of expert interface options configuration … + novice audio/video voice configuration + - option recognition option Architecture? Technical Impacts? ? ? Capabiltities? … Co mponent is in use at development house Project Management Impacts? Experience with Risk? component reduces risk … Schedule?
Java MfastView JMF RealNetwork Oracle DB2 Plus Server
Rejected Considered for Option 3 Considered for Option 1,2
Questions for Softgoal Claim What are the technical impacts? JMF RealNetwork Server What is the impact on the No impact identified 1. interface with commerical db: no impact on architecture, possible architecture? impact on performance 2. Replace commerical db with capabilities in product: significant impact on architecture, possible impact on maintenance and security What capabilities are not Compliance with None identified supported? MPEG-4 standard …
Legend
Hardgoal Question for AND Decomposition Relationship + Positive Contribution Softgoal Claim - Negative Contribution Softgoal OR Decomposition Relationship Claim Softgoal ? Unknown Contribution Component Softgoal Operationalization Figure 8. Relationships Among Goals and COTS Components Questions for Softgoal Claim
What are the technical impacts?
JMF RealNetwork Server What is the impact on the No impact identified Option 1. Interface component with architecture? commerical db: no impact on architecture, possible impact on performance Option 2 Replace commerical db with capabilities in product: significant impact on administration, architecture, possible impact on maintenance and security What is the impact on the limited (component has API) limited (component has API) design? What is the impact on No impact identified Architecture Option 1. no impact identified; maintenance? assuming new releases of commerical db are backwards compatible with earlier releases Architecture Option 2. long term scalability of component needs to be investigated; assuming new releases of component are backwards compatible with earlier releases What capabilities are not MPEG-4 None identified supported? …
What are the project management impacts?
What is the impact on schedule? training training prototyping architecture Option 1 What is the impact on cost? TBD TBD obtain current price obtain current price What are new risks? no experience with component no experience with component architecture Option 1: possible impact on administration, maintenance, security … Table I. Questions Used for Claiming a Softgoal Component Unique Identifier C_006 Type Software Name Java Media Framework (JMF) Keyword1 Multimedia Weight1 4 Keyword2 Audio Weight2 2 Keyword3 Video Weight3 2 Functional Overview The Java (TM) Media Framework API (JMF) enables audio, video and other time-based media to be added to Java applications and applets. This package can capture, playback, stream and transcode multiple media formats. It extends the multimedia capabilities on the J2SETM platform. Nonfunctional Overview Java Media Framework (JMF) supports the high quality presentation of audio and video. Domain Multimedia, distributed Vendor Sun Microsystems Inc. VendorEvaluation Sun Microsystems, Inc. is a leader in the Java language specification and tool support Version Number 2.1.1 OS Cross Platform Version Standards Compliance Protocols: RTP, ftp, http
File Formats: D indicates the format can be decoded and presented. E indicates the media stream can be encoded in the format. - indicates the format is not supported read indicates the media type can be used as input (read from a file) write indicates the media type can be generated as output (written to a file) AIFF (.aiff) read/write 8-bit mono/stereo linear D,E 16-bit mono/stereo linear D,E G.711 (U-law) D,E A-law D IMA4 ADPCM D,E AVI (.avi) read/write Audio: 8-bit mono/stereo linear D,E Audio: 16-bit mono/stereo linear D,E Audio: DVI ADPCM compressed D,E Audio: G.711 (U-law) D,E Audio: A-law D Audio: GSM mono D,E Audio: ACM - Video: Cinepak D Video: JPEG (411, 422, 111) D Video: RGB D,E Video: YUV D,E Video: VCM - Flash (.swf, .spl) read only Macromedia Flash 2 D GSM (.gsm) read/write GSM mono audio D,E HotMedia (.mvr) read only IBM HotMedia D MIDI (.mid) read only Type 1 & 2 MIDI - MPEG-1 Video (.mpg) - Multiplexed System stream - Video-only stream - MPEG Layer II Audio (.mp2) read only MPEG layer 1, 2 audio D MPEG Layer III Audio (.mp3) read only MPEG layer 1, 2 or 3 audio D QuickTime (.mov) read/write Audio: 8 bits mono/stereo linear D,E Audio: 16 bits mono/stereo linear D ,E Audio: G.711 (U-law) D,E Audio: A-law D Audio: GSM mono D,E Audio: IMA4 ADPCM D,E Video: Cinepak D Video: H.261 - Video: H.263 D Video: JPEG (411, 422, 111) D Video: RGB D,E Sun Audio (.au) read/write 8 bits mono/stereo linear D,E 16 bits mono/stereo linear D,E G.711 (U-law) D,E A-law D Wave (.wav) read/write 8-bit mono/stereo linear D,E 16-bit mono/stereo linear D,E G.711 (U-law) D,E A-law D GSM mono D,E DVI ADPCM D,E MS ADPCM D ACM - Interface Type API Performance Audio sample rates supported:8, 11.025, 11.127, 16, 22.05, 22.254, 32, 44.1, and 48 KHz Notes This is a software development kit for JAVA. The API is documented on-line at http://www.informatik.uni-siegen.de/psystuff/docu/#jmf Table II. JMF Component Component Unique Identifier C_008 Type Software Name RealNetwork Server Keyword1 Multimedia Weight1 4 Keyword2 Audio Weight2 3 Keyword3 Video Weight3 3 Keyword4 Server Weight4 4 Functional Overview RealNetwork server allows you to create and send streamed video and audio files. RealNetwork servers can handle the large media files and many users accessing the files simultaneously. Nonfunctional Overview RealNetwork server supports high quality audio and video formats. The server is available for PC or UNIX platforms. Domain distributed, real-time Vendor RealNetworks Inc. VendorEvaluation Leader in tools for audio and video file generation and players. Version Number 8.0 OS Intel Pentium: Windows NT 4.0 or 2000 Workstation or Server, Linux 2.2 (glib c6), Free BSD 3.0 Sun SPARC: Solaris 2.6, 2.7, 2.8 IBM RS/6000 PowerPC: AIX 4.3 HP PA-RISC 2.0: HP-UX 11.x R4000 running MIPS3 instruction set: IRIX 6.5 Alpha: Compaq Tru64 UNIX 5.1 Standards Compliance MPEG-3, MPEG-4 Other standards: TBD Interface Type API Memory RealSystem Server Basic and RealSystem Server Plus require a minimum of 256 MB of RAM to run optimally. For RealSystem Server Professional, 512 MB of memory is recommended. Adding more RAM to a RealSystem Server may increase the number of clients the machine can serve simultaneously.
Sites that plan to serve 1000 or more simultaneous clients should consider using 768 MB of RAM or more.
Adding memory enables RealSystem Server to handle more information at any given time, whereas adding processors enables RealSystem Server to process information faster. Thus, if you add processing power to a system, additional memory will help the processors perform at their optimal level. Disk Space The RealSystem Server 8 application requires about 14MB of storage plus storage for your media content. Single rate media storage requirements can be calculated with the following equation: ("bit rate of clip in kbps 'X' length of clip in seconds") divided by 8 = KB required disk space. SureStream clips are more difficult to calculate as each clip has multiple embedded data rates. To figure out the storage requirements the above equation is used for every data rate in the file. The data rates in the file can be found at encode time in RealProducer's view statistics panel. Example Data Rate of the Clip Length in Seconds Storage Required 20kbps (single rate) 180 450KB 20kbps (SureStream) 180 900KB Bandwidth Requirements Bandwidth required for serving content can be calculated using the following equation: ("data rate of clip in kbps 'X' max number of simultaneous streams"). Example
Stream Data Example Rate Audience Bandwidth Required Connection 20kbps 60 1.2Mbps T1 60% 20kbps, 40% 80kbps 100 4.4Mbps Fractional T3 80kbps 100 8Mbps 10Mbps Fractional T3 20kbps 2000 40Mbps T3 Lessons Learned, Experience Typical deployment: Real Server used to store objects, not an external database. Notes O/S Notes: Upgrade to the latest stable Linux 2.2.x kernel, which is available at kernel.org. Linux 2.3 or 2.4 kernels are not recommended, as RealSystem Proxy has not been thoroughly tested with these newer kernels. On Solaris 2.6 and 2.7, be sure to download and apply the latest patches, which are available at sunsolve.sun.com. On Windows, be sure to download and apply the latest patches, which are available at microsoft.com/ntserver Web Server Interoperability To make the best use of MIME types served by RealSystem Server 8, you must have a Web site and a registered domain. RealSystem Server 8 is compatible with any Web Server which supports configurable MIME types, and has been tested with the following Web servers: Apache 1.1.1 CERN HTTPD version 3.0 EMWC HTTPS version 0.96 HTTPD4 Mac Mac HTTP Microsoft Internet Information Server NCSA HTTPD versions 1.3 or 1.4 Netscape Netsite and Netscape Enterprise Server O'Reilly Website NT Spinner version 1.0b12 through 1.0b15 Webstar and Webstar PS see also: RealNetwork Player Table III. RealNetwork Server Component