Chapter 14 AN ONTOLOGICAL APPROACH TO ... - Springer Link

Chapter 14 AN ONTOLOGICAL APPROACH TO REQUIREMENTS ELICITATION TECHNIQUE SELECTION Ann M. Hickey and Alan M. Davis University of Colorado at Colorado Spring, 1420 Austin Bluffs Parkway, P.O. Box 7150, Colorado Springs, CO 80933-7150

Abstract:

Too many systems constructed by the software industry fail to meet users’ needs. Requirements elicitation is the set of activities performed to understand users’ needs for a system. Although most texts focus on a few elicitation techniques, there are numerous variations of these basic techniques. So, the question arises, how can an analyst understand all these techniques and their variations? Moreover, most experts today agree that the selection of an appropriate technique must be a function of the situation. But, a seemingly infinite number of situational characteristics exist. So, how can an analyst know which of these many situational characteristics should be taken into account when trying to select elicitation techniques? And, how does an analyst select a technique that makes sense given those situational characteristics? The overarching goal of this research is to construct an information system to aid novice analysts in selecting the most effective requirements elicitation techniques for their project situation. Fundamental to the success of this endeavor is the creation of an ontology which: (1) sets the context for requirements elicitation and elicitation technique selection; (2) defines key characteristics of elicitation techniques that highlight their essential similarities and differences; and (3) identifies the important characteristics of a situation that should be considered when selecting an elicitation technique. This chapter describes the iterative ontology engineering approach used, summarizes the proposed requirements elicitation ontology, and demonstrates how the ontology will be used as a basis for an information system to assist analysts in selecting an appropriate elicitation technique. As a result, this chapter, rather than focusing on ontology research per se, focuses on the application of ontologies to improve the state of research and practice in one specific information systems discipline – requirements elicitation.

Key words:

Requirements engineering; Elicitation; Systems analysis; Ontology

404

1.

Raj Sharman, Rajiv Kishore and Ram Ramesh

INTRODUCTION

More than half the systems constructed by the software industry fail to meet users’ expectations (Standish, 1995), often because developers do not understand users’ needs (Hofmann and Lehner, 2001). Requirements elicitation (aka systems analysis1) is the set of activities performed with the primary goal of understanding users’ needs, i.e., the requirements for a system (Thayer and Dorfman, 1994). The ultimate quality of a product is driven by the quality of the requirements gathered by the analysts during elicitation which in turn is directly impacted by effectiveness of the elicitation process and the appropriateness of the techniques used during that process (Hickey and Davis, 2002). Although most recent requirements books (Davis, 2005; Gottesdiener, 2002; Leffingwell and Widrig, 2000; Macaulay, 1996; Wiegers, 2003) describe a dozen or so primary approaches, there are actually hundreds, and perhaps thousands, of variations of alternative elicitation techniques. But many analysts seem to know and use just a few of these techniques (Hickey et al., 2003). So, the question arises, how can an analyst understand all these techniques and their variations? Moreover, while proponents of many elicitation techniques claim that their techniques are universally applicable in all situations; most experts today agree that the selection of an appropriate technique must be a function of the situation (Glass, 2002; Kotonya, 1998; Maiden and Rugg, 1996). But, a seemingly infinite number of situational characteristics exist. So, how can an analyst know which of these many situational characteristics should be taken into account when trying to decide which elicitation technique would make the most sense? And, how does an analyst select a technique that makes sense given those situational characteristics? The primary goal of this research is to construct an information system to aid novice analysts in selecting the most effective requirements elicitation techniques for their project situation. While often thought to just focus on more traditional, structural (e.g., data modeling) issues, the emerging field of ontology-driven information systems also offers potential in “the temporal (i.e., development and operation processes) dimensions of IS” which can form the basis of more “effective and efficient conceptual analysis and design processes” (Kishore et al., 2004c, p69). Therefore, the goal of the research reported in this chapter is to develop an ontology and explore how well it supports requirements elicitation and elicitation technique selection. 1

There is much agreement in the industry concerning the need to better understand user needs, but little uniformity concerning what to call the activity. The IS industry calls it systems analysis, problem analysis, business analysis, or just plain analysis. The engineering community calls it requirements analysis, elicitation, knowledge engineering, or requirements engineering. In this chapter, we use the word elicitation.

Ontology Handbook

2.

405

BACKGROUND

The application domain of this research is requirements elicitation. Before exploring the development of ontology to support requirements elicitation, it is important to ensure that all readers have at least a basic understanding of the domain. Therefore, this section provides a brief introduction to requirements management in general and the role of requirements elicitation in that management process. If requirements are the externally observable characteristics of a desired system, then requirements management (aka requirements engineering) is the set of activities of determining the requirements (i.e., performing elicitation), deciding which are the “right” ones to satisfy (i.e., performing triage), and documenting them (i.e., performing specification) (Davis, 2005). These three components are not sequential, but instead are symbiotic and performed iteratively and concurrently, with the results of each component feeding subsequent iterations of that component and the others as shown in Figure 14-1.

Requirements Elicitation Requirements Triage Requirements Specification time Figure 14-1. Concurrency of requirements activities

Myriad techniques are available to support each of the three activities, for example, • Elicitation techniques include interviewing, questionnaires, observation, and collaborative workshops, to name but a few. • Triage techniques include WinWin, prioritization, balancing candidate requirements against schedules and cost, and so on. • Specification techniques include natural language, standards-adherence, finite state machines, use cases, and data flow diagrams, to name a few. And yet, few of the above listed techniques can be characterized as solely for just one activity. It is easy to imagine how an analyst could use any of the so called specification techniques for elicitation, e.g., an analyst could ask a potential customer, “does this model describe your needs?” In the current research, we consider most techniques suitable for any requirements activity

406


as a candidate technique for requirements elicitation if it can aid in the discovery of requirements. However, not all techniques may be appropriate in all situations. In particular, every situation demands an elicitation technique that is appropriate for that situation, as shown in Figure 14-2. More specifically, it is the match between the situation and the specific attributes of an elicitation technique which makes that technique appropriate for that situation, as shown in Figure 14-3.

Figure 14-2. Elicitation technique selection

Figure 14-3. Selection based on technique characteristics

Therefore, to select an appropriate elicitation technique, an analyst must first understand what techniques are available, and how they are different or similar. To this end, we created an ontology that defines key characteristics of elicitation techniques, so they can be understood, compared and contrasted. This ontology can then be used to assign clear semantics to the

Ontology Handbook

407

wide range of current elicitation techniques and help all analysts understand, for example, if there are or are not any significant differences between Joint Application Design (JAD) sessions (Wood and Silver, 1995) and the other collaborative or facilitated requirements workshops described by many authors (e.g., (Gottesdiener, 2002; Macaulay, 1996; Robertson and Robertson, 1999)). Given the explosion of possible elicitation techniques, some of which may vary in name only, this ability will be extremely valuable for even the most experienced analysts by increasing awareness and aiding comparison of new techniques. It will also help reduce the “information overload” of less experienced analysts when presented with extensive lists of techniques. To know which technique to select, one needs to understand what characteristics of a situation are important. While experienced analysts seem to intuitively sense which characteristics are critical in a given situation, less experienced analysts need assistance in identifying key situational characteristics. These situational characteristics were represented in a second ontology, one of characteristics of the domain (Liebowitz, 2001). The situational characteristics used in this ontology are those that are relevant to selection of elicitation techniques. The two ontologies were later integrated into a single, requirements elicitation ontology to enhance understanding of the requirements elicitation process and facilitate development of an information system to help inexperienced or novice analysts select elicitation techniques for their projects. This chapter reports the iterative development and evaluation of the usefulness of these ontologies for the selection of appropriate elicitation techniques.

3.

RESEARCH APPROACH & METHOD

3.1

Research Overview

As stated in the introduction, the overarching goal of this research is to construct an information system to aid analysts, especially novice and other less-experienced analysts, in selecting the most effective requirements elicitation techniques for their project situation. Fundamental to the success of this research is the development of requirements elicitation ontology focused on elicitation technique selection. The purpose of this chapter is to continue the research begun in Hickey and Davis (2003a) and address the following research questions: • Does the proposed ontology assign clear semantics to currently available requirements elicitation techniques and identify those characteristics of

408


the techniques that are important for effective elicitation technique selection? • Does the proposed ontology identify those characteristics of a situation that are most important for effective elicitation technique selection? • Does the proposed ontology support identification of how the characteristics of the situation interact with the characteristics of the techniques to drive effective elicitation technique selection, and ultimately, more effective elicitation? Numerous authors broadly characterize elicitation techniques. For example, Lauesen (2002) characterizes elicitation techniques with an ontology based on outputs the techniques produce. Gottesdiener (2002) organizes elicitation techniques in terms of top-down/bottom-up, and the underlying models produced as a result of applying the technique. Macauley (1996) provides a long list of elicitation techniques and describes each in terms of its characteristics, but falls short of defining an ontological basis. Byrd et al. (1992) characterize elicitation techniques based on communications obstacles, facilities, and the controller of the process. Similarly, a few authors have studied characteristics of situations that drive elicitation technique selection. For example, Bento (1994) defines a simple three-dimensional ontology consisting of the need to understand the broadness of the problem, wickedness of the problem, and relative task vs. decision emphasis in the problem domain. Maciaszek (2001) presents a model of the influences that affect the success of requirements elicitation. Maiden and Rugg (1996) provide a framework for elicitation technique selection consisting of six facets. Our research stands on the shoulders of the above research efforts to create a more complete ontology necessary for elicitation technique selection. We are following the research approach shown in Figure 14-4. (Note: The emphasized (bold) research tasks and links are directly related to the development of the requirements elicitation ontology – the focus of this chapter.) We have completed tasks 1-4, creating a unified model of requirements elicitation (Hickey and Davis, 2004) and draft versions of separate ontologies for technique and situational characteristics and their interrelationships (Hickey and Davis, 2003a). This chapter summarizes the results of those tasks as well as those of task 5, where we have integrated our model and the two draft ontologies into a single ontology focused on elicitation technique selection. We are currently in the process of interviewing expert elicitors (task 6), and thus far have completed interviews with Grady Booch, Alistair Cockburn, Larry Constantine, Tom DeMarco, Donald Gause, Soren Lausen, Tim Lister, Lucy Lockwood, Shari Lawrence Pfleeger, Neil Maiden, Reifer, James Robertson, Suzanne Robertson, Karl

Ontology Handbook

409

Wiegers, Edward Yourdon, and Didar Zowghi (see (Hickey and Davis, 2003b) for preliminary interview results). As we complete interviews with these experts, we continue to revise our integrated ontology (task 7) and the mapping between the elicitation technique and situational characteristics included in that ontology (task 8). During task 9, we will validate our findings and implement our results in a tool that can be used by less experienced analysts to assist them in selecting the ‘right’ elicitation technique for their situation. 1. Model Requirements Elicitation 2. Draft Ontology of Elicitation Techniques

5. Integrate Ontologies & Model

7. Revise/Formalize Integrated Ontology

3. Draft Ontology of Situational Characteristics 4. Draft Mapping: Situation to Technique

Conceptual Phase

9. Implement & Validate

6. Interview Expert Elicitors

Elaboration Phase

8. Revise Mapping: Situation to Technique

Definition Phase

Figure 14-4. Research approach

This overall research approach directly aligns with the conceptual (tasks 1-4), elaboration (tasks 5-6), and definition (tasks 7-9) phases of the Helix-Spindle Model for ontological engineering (Kishore et al., 2004c) as shown in Figure 14-4 and described in more detail in the next section.

3.2

Ontological Engineering

Ontological engineering “refers to the set of activities that concern the ontology development process, the ontology life cycle, and the methodologies, tools and languages for building ontologies” (Gomez-Perez et al., 2004, p5). Kishore et al. (2004a) define some fundamental questions that must be answered as the first step in ontological engineering. These questions and our answers are as follows: 1. What is the purpose for which ontology is needed? The primary purpose of the ontology is to improve understanding of requirements elicitation and elicitation technique selection. More specifically, the ontology will

410


provide a language for capturing and providing guidance on elicitation technique selection to novice analysts. Additionally, it will enable requirements researchers and practitioners to more crisply define and understand the subtle differences between alternative elicitation techniques. As such, the proposed ontology would generally be classified as a domain ontology, or, more specifically, as a task ontology providing “terms specific for particular tasks” and a “reasoning point of view on domain knowledge” (Fensel, 2004, pp. 5-6). 2. What skills are needed in conceptualizing and building the ontology? Kishore et al. (2004a) identify three key skills: conceptual modeling skills, domain-specific expertise, and systems engineering skills. The authors have over 25 years each of academic and professional expertise in all three of these skill areas and are therefore well-prepared to take the lead in developing the proposed ontology. 3. What constitutes the proposed methodology? Kishore et al. (2004a) use Gruber’s (1993) definition of ontology as the basis for identifying the three main components of ontology: concepts, relationships, and behaviors. Our early ontology work (Hickey and Davis, 2003a) focused primarily on concepts. This chapter extends that work by elaborating on our ontology to include relationships and behaviors. 4. What methodology is to be used in ontology development? There is no standard methodology for building ontology. Holsapple and Joshi (2002) describe five different approaches and then focus on the benefits of using a collaborative approach. In (Kishore et al., 2004a), the authors discuss a Cue-N-Anchor guided strategy for constructing ontology. However, their Helix-Spindle Model (Kishore et al., 2004c) seems a better fit for this research, as described below. Just like software development today, successful development of ontology is an iterative and incremental process. In fact, many authors (e.g., (Kishore et al., 2004a)) recognize that ontology is never complete or final. As a result, the ontological engineering methodology chosen should reflect this sort of iterative development process, which interleaves ontology building and testing phases, each of which increases the maturity/completeness (and formality) of the ontology. The Helix-Spindle Model for ontological engineering (Kishore et al., 2004c) provides such an approach and was used to guide development of our Requirements Elicitation Ontology. The Helix-Spindle Model has three phases: 1. Conceptual Phase. In this phase, the initial ontology is built based on existing content and foundation theories, represented informally (e.g., natural language), and then tested for adequacy by actually using the ontology within its application domain. For our research, the initial conceptual ontology of elicitation techniques (task 2) was derived from

Ontology Handbook

411

the aforementioned works of Lauesen (2002), Gottesdiener (2002), Macauley (1996), and Byrd et al. (1992), selected textbooks (e.g., Conger, 1994; Dennis and Haley Wixom, 2000; Hoffer et al., 2002), as well as our own personal experience. The initial conceptual ontology of situational characteristics (task 3) was derived from the aforementioned works of Bento (1994), Maciaszek (2001), and Maiden and Rugg (1996) as well as criteria influencing life-cycle model selection from Alexander and Davis (1991), multipliers influencing cost estimation from Boehm et al. (2000), factors influencing requirements approaches from Davis (1993), factors influencing software engineering experimental design from Juristo and Moreno (2001), characteristics influencing the definability of a system from Scharer (1981), problems in deriving needs from Yeh and Ng (1990), as well as our own personal experience. The ontologies were represented using a faceted classification described using natural language. They were tested by representing sample elicitation techniques using the technique ontology. We also constructed the initial mappings from the situational characteristic ontology to the elicitation technique ontology (task 4) based on our own experiences and the limited guidance available from the above references. Results of the Conceptual Phase were first reported in (Hickey and Davis, 2003a) and are summarized in Section 4 of this chapter. 2. Elaboration Phase. During this phase, the ontology is refined based on the testing results from the previous phase and/or additional content theories/information; represented using a semi-formal notation (e.g., UML or Ontolingua); and then retested. For our research, the ontology was refined based on testing results from the first phase and initial results of interviews with experts (task 6). We also integrated the elicitation technique and situational characteristic ontologies into a single, integrated ontology representing both the requirements elicitation and elicitation technique selection processes. Results of previous research to create a mathematical model of these processes (Hickey and Davis, 2004) provided the foundational theory for these portions of the ontology. UML was chosen as the representation notation because of its recognition and acceptability as a semi-formal notation by the ontology community (Kishore et al., 2004b; Gomez-Perez, 2004) and as the standard objectoriented modeling notation by the software development community. The refined ontology was tested using the results of additional expert interviews and by a more detailed mapping between elicitation technique and situational characteristics. Results of the Elaboration Phase are reported in Section 5 of this chapter. 3. Definition Phase. It is during this phase that the complete ontology is formally defined using a rigorous, formal notation (e.g., predicate logic).

412


For our research, formal definition of the complete ontology will be addressed as part of tasks 7-9. The final representation will be chosen to match the implementation environment. Testing and refinement will continue as we validate the implementation. See section 6.2 for an overview of future research related to this phase.

4.

CONCEPTUAL PHASE RESULTS

During the conceptual phase, existing foundational knowledge and theories were used to develop two separate ontologies. The first, described in detail in section 4.1, was designed to help analysts understand what elicitation techniques are available, their key characteristics, and how they are different/similar. This ontology is a multi-faceted classification represented as a vector that can then be used to assign clear semantics to the wide range of current elicitation techniques and is designed such that if two techniques are suitable in similar situations, they will be located close to each other within the ontology vector space. To know which vector to select from the technique ontology’s vector space, the analyst needs to understand what characteristics of a situation are important. These situational characteristics are represented in a second ontology, one of characteristics of the domain (Liebowitz, 2001). The situational characteristics used in this ontology are those that are relevant to the selection of elicitation techniques. This situational ontology is described in section 4.3. Testing results are reported in sections 4.2 and 4.4.

4.1

Building the Conceptual Elicitation Technique Ontology

The conceptual foundations for the initial elicitation technique ontology are described in the previous section. The ontology developed from these foundations is driven by an attribute vector that locates each technique in a multi-dimensional vector space. The techniques are organized so that any two techniques that are equally applicable in all situations are clustered very closely together in the overall vector space. The vector space includes the following ten dimensions: • Physical Co-Location. This attribute has two possible values: “same place” and “different place.” It captures whether or not the technique demands that participating parties be located at the same physical location, e.g., in the same room. We call the value of this attribute PHYS. • Temporal Co-Location. This attribute has two possible values: “same time” and “different time.” It captures whether or not the technique

Ontology Handbook

•

•

•

•

•

• •

•

413

demands that participants collaborate at the same time. We call the value of this attribute TEMP. Record-Keeper. This attribute has three possible values: “individuals,” “analyst,” and “no record.” It captures whether the results of the elicitation event are recorded for the future by every individual contributor, or by the analyst, or by no one. We call the value of this attribute RECO. Analyst Role. This attribute has three possible values: “passive,” “facilitate,” and “lead/direct.” Passive indicates that the analyst is observing the elicitation event, but is not participating directly in it. Facilitate indicates that the analyst is aiding the event, helping to ensure that it has positive results. Lead/direct indicates that the analyst drives the activity. We call the value of this attribute ANAL. Convergence/Divergence. This attribute has two possible values: “convergent” and “divergent.” Divergent techniques create new ideas; convergent techniques group, filter, or rank ideas. We call the value of this attribute CONV. Anonymity. This attribute has two possible values: “anonymous” and “public.” Techniques that are anonymous protect each participant from other participants knowing which ideas they generated. Public techniques allow participants to know who generates which ideas. We call the value of this attribute ANON. Stakeholder Count. This attribute has four possible values: “many,” “few,” “one,” and “none.” It captures the number of stakeholder classes involved. A stakeholder class is one or more stakeholders representing identical opinions. We call the value of this attribute STAK. Tool Based. This attribute has two possible values: “tool” and “no tool.” It captures whether the technique requires the use of a software tool. We call the value of this attribute TOOL. Product/Human Focus. This attribute has two possible values: “product” and “human.” It captures the fact that some techniques focus on identifying the requirements for the “product” that solve the users’ problems, while other, socio-technical approaches assume that requirements emerge as a result of the interactions between humans (stakeholders and analysts) in a situational context (Coughlan and Macredie, 2002). We call the value of this attribute FOCU. Direct/Indirect. This attribute has two possible values: “direct” and “indirect.” It captures the fact that some elicitation techniques are performed to directly elicit needs (direct), whereas other techniques (e.g., team-building exercises) are performed to alter the situation to make it more conducive to elicit needs. We call the value of the attribute DIRE.

414


Any attribute may also have a value of “don’t care,” represented by a “— ” in the following examples, indicating that the attribute is not significant or can take on any of the possible attribute values. We can thus represent any elicitation technique by its attribute vector: (PHYS, TEMP, RECO, ANAL, CONV, ANON, STAK, TOOL, FOCU, DIRE).

4.2

Testing the Conceptual Elicitation Technique Ontology

The elicitation technique ontology was tested by evaluating its ability to accurately represent existing elicitation techniques. Let’s look at how these attributes map for some representative techniques. • Interview a Single Customer Face-to-Face (Gause and Weinberg, 1989). The values for the attribute vector are (same place, same time, analyst, lead/direct, —, public, one, no tool, —, direct). • Conduct a Distributed Brainstorming Session Where Nobody Knows Who Else Is Involved (Romano et al., 1999). The values are (different place, same time, individuals, facilitate, divergent, anonymous, many, tool, product, direct). • Perform a Demographical Market Analysis (Higgins, 2003; Schewe and Hiam, 1998). The values are (different place, different time, individuals, passive, divergent, anonymous, many, no tool, product, direct). • Observe a Few Stakeholders (Goguen and Linde, 1993). The values are (same place, same time, analyst, passive, divergent, —, few, no tool, human, direct). • Do a Group-Voting Session in One Room Where Voting is Anonymous (Nunamaker et al., 1991). The values are (same place, same time, individuals, facilitate, convergent, anonymous, —, tool, product, direct). • Use Soft Systems Methodology (Checkland and Scholes, 1991). The values are (same place, same time, individuals, facilitate, —, public, many, no tool, human, direct). • Do a Team-Building Exercise. The values are (same place, same time, — , —, —, public, —, —, human, indirect). • Use a Bulletin Board. The values are (different place, different time, individuals, —, divergent, —, many, tool, product, direct). Theoretically, the vector space contains 3,456 discrete vectors, and thus could be used to categorize that many techniques. However, there are two observations that make this incorrect: First, many techniques are incredibly similar, often with just different names being applied to the same approach. In these cases, the techniques coexist in the same vector space. Second, we have found some vectors to be meaningless. For example, (same place,

Ontology Handbook

415

different time, —, —, —, —, —, —, —, —) could represent a message board physically located in one location, but does not correspond to any known elicitation techniques. Similarly, (same place, same time, analyst, —, —, anonymous, many, no tool, —, —) makes no sense because if the stakeholders are all co-located and the analyst is recording everybody’s ideas without a tool, then obviously the stakeholders are stating their ideas aloud, and there is no way to preserve anonymity. Finally, as shown in Figure 14-4, this ontology will be revised, integrated with the situational characteristic ontology, and validated as we continue our interviews with experts to ensure that we include all dimensions in the ontology that differentiate techniques based on their appropriateness in various situations. Therefore, we do not claim that the taxonomy created during the Conceptual Phase is complete. However, we can claim that it does identify ten of the key dimensions that differentiate the large number of available elicitation techniques and that are critical in selecting techniques for specific situations, as discussed next.

4.3

Building the Conceptual Ontology of Situational Characteristics

The characteristics of the immediate situation determine which values for which elicitation technique attributes are applicable for that situation. Relevant situational characteristics were derived from the literature as described in the previous sections and fall into five broad categories. Techniques should be selected based on: • Characteristics of the Problem Domain. Inherent characteristics of the problem, including the fuzziness of its definition (FUZZ), its complexity (CPLX), the existence of conflicting needs (CNFL), the maturity of the application (MATU), and the importance of non-functional requirements such as security (SECU), response time (RESP), safety (SAFE) and reliability (RELI), have a major impact on the techniques that should be used. Thus, for example, a totally new, unprecedented application may require more extensive use of divergent techniques, but an upgrade of a well-established legacy application would not. A problem for which a fast response time becomes life-critical may necessitate different, possibly more formal, elicitation techniques than one that has no deleterious effect. • Characteristics of the Solution Domain. Similarly, the type of solution anticipated (e.g., application vs. system vs. embedded software (TYPE), custom development vs. customizing vs. commercial-off-the-shelf software (COTS)) may also impact the selection of elicitation techniques. An embedded system may demand different elicitation approaches than a

416


software-only system. Planning to purchase (OUTS) vs. build in-house may also make a difference. • Characteristics of the Stakeholders. Inherent characteristics of all the people involved in a software development project, especially the stakeholders (e.g., customer, users, other sources of needs), are major drivers of the selection of appropriate elicitation techniques. The number of different stakeholders and stakeholder roles (#STK) directly impacts whether individual techniques such as interviews can be used virtually exclusively or various collaborative meeting or mass contact (e.g., questionnaires) should be considered. If the stakeholders are novices (STEX) in the application domain or in the use of similar applications they may have a hard time articulating their requirements, so techniques that facilitate that process such as prototyping may be appropriate. If the situation is such that your customers are major competitors of each other (STCM), then only a technique that enforces anonymity is appropriate. Other key questions that may impact the selection of an elicitation technique include: Do the key stakeholders get along with each other (STCP)? Can the stakeholders travel to a common location (STTV)? Are they accessible (STAC)? Do the stakeholders speak with one voice, or do they represent many different roles with quite different needs (STDV)? • Characteristics of the Solution Builders. The knowledge and expertise of the system builders may also impact the selection of elicitation techniques. For example, if the system builders are experts in the problem and solution domains (SOEX), then elicitation techniques that record requirements using problem domain terminology may be appropriate. Their communication skills (SOCO), software development experience (SOSW) and knowledge of specific tools (SOTO) and techniques may also be factors that should be considered. • Characteristics of the Bridge-Builders. Bridge-builders are the individuals who serve as the communication conduit (or bridge) between stakeholders and solution builders. Bridge-builders may be systems analysts, requirements engineers or any individual from the user or developer side of the project assigned to perform this role. Experience has shown that quality bridge-builders are critical to the success of requirements elicitation. Therefore, the match between the characteristics of the bridge-builders and the elicitation techniques used is essential. These characteristics include experience in the problem domain and application type (BBEX), knowledge and experience with specific elicitation techniques (BBTE), and communication/facilitation negotiation skills (BBCO). For example, if bridge-builders have limited experience in a domain, they should initially focus on techniques such as interviews with key stakeholders and/or document reviews that enable

Ontology Handbook

417

them to develop their domain knowledge. If they have little or no experience facilitating a group meeting, then a group meeting may not be appropriate. One very interesting observation from the expert interviews we have conducted so far is the importance of the bridge-builders experience with a specific technique. We had assumed that inherent characteristics of the technique were the primary driver in its appropriateness for a specific situation. However, our interviews showed us that a moderately good technique for a specific situation in the hands of an experienced “master” can become an ideal technique for that situation, because of the expert’s ability to mold the technique to the situation. Thus, masters in specific techniques tend to rely on their favorite technique except under special situational circumstances. However, for less experienced analysts, this approach may lead to disaster because they simply do not have the skills required to adapt the technique to those situations for which it is not a “good fit.” We have isolated over fifty situational characteristics that could influence the decision to select one or more elicitation techniques. As mentioned before, many of these have been adapted from situational characteristics specified for other purposes. We are using our expert interviews (Figure 14-4, task 6) to identify which of those characteristics are the primary drivers for technique selection. We are 75% done with the process of interviewing many of the world’s experts in systems analysis to improve our understanding of how situations affect the elicitation techniques they chose to utilize. Without exception to date, we have found that these experts are not consciously analyzing situational characteristics to select the technique. However, when we ask questions like “what would you have done if” the situation was slightly different; the experts invariably say they would have selected an alternative approach. Thus, we are receiving consistent evidence that the selection process is in fact situational.

4.4

Testing the Conceptual Ontologies: Mapping from Situational Characteristics to Elicitation Techniques

Testing of the ontologies developed during the conceptual phase primarily focused on the ontologies’ ability to support the mapping of characteristics of the situation to appropriate characteristics of the elicitation techniques. The initial mapping was created as part of task 4 of our overall research approach (see Figure 14-4). In general, it is the complete set of situational characteristics that imply the suitability of a set of elicitation techniques. However, some values for some characteristics may be sufficient by themselves to imply such suitability. We captured the initial mapping in a series of cascading tables. Entries in these tables can be any of the following:

418


• NO. The techniques that possess these characteristics are incompatible with situations that possess those characteristics. • OK. The techniques that possess these characteristics are compatible with situations that possess those characteristics. • HI. The techniques that possess these characteristics are strongly suggested in cases where those situational characteristics exist. There are so many possible combinations of situational characteristics that it is impossible to describe how they map to specific elicitation techniques. Therefore, this section will present a few representative examples, some where multiple characteristics are relevant to the decision, and some where just a few of the characteristics are sufficient. Example I: The stakeholders are many (#STK=many) and diverse (STDV=high), but are easily accessible (STAC=easy) and available for travel (STTV=yes). They have never worked together before, but we have no reason to believe they would be combative (STCP=high). The application is an unprecedented (MATU=low) decision support system (TYPE=dss). In this situation, the analyst should first seek a technique that supports the many stakeholders. Since the stakeholders have not worked together before and are accessible, techniques that support a same time, same place meeting (PHYS=same, TEMP=same) that can be used to build a sense of team would be preferred in the early stages of the project. The diversity of the stakeholders could also indicate a need to start with team-building exercises (FOCU=human, DIRE=indirect). Because of the unprecedented nature of the application, divergent techniques (CONV=divergent) should also be considered early in the process. With either of the latter two types of techniques, the presence of a large group of stakeholders indicates the need for strong facilitation (ANAL= facilitate). With larger groups of stakeholders it may also be more efficient to have the individual stakeholders record their own ideas (RECO=individual). Optionally, efficiency could also be increased through the use of a tool (TOOL=tool) if an appropriate tool was available. Example II: We are a company with a customizable base product. We sell a highly modified version of the base to each of our customers (COTS=customize, OUTS=in). These customers are strong competitors of each other (STCM=yes). Critical to our business strategy is to never allow our customers to know who our other customers are. In this situation, techniques that preserve stakeholder anonymity (ANON=anonymous) are critical to the company’s business strategy. Therefore, techniques that require same time, same place interaction (TEMP=same time, PHYS=same place) of all stakeholders would not be appropriate (although they could work if applied separately to each company’s stakeholders). This need for anonymity and separation, when combined with the existence of the current

Ontology Handbook

419

product, would be a strong indicator for product-focused techniques (FOCU=product). Example III: We are part of an internal IT organization with a very vocal set of stakeholders within the operating divisions of the company located around the world. These stakeholders have worked together well many times in face-to-face meetings (STCP=high). In this situation, because the stakeholders know each other and have worked together, team-building is not required so they can immediately working on the problem (DIRE=direct, FOCU=product). That prior experience when combined with the geographical dispersion of the stakeholders would be strong indicators for the use of distributed techniques (PHYS=different place), which generally require tool support (TOOL=tool) and would benefit from strong facilitation (ANAL=facilitate) to ensure the team stays on task. Example IV: We are working as a new analyst (BBEX=low) at a small company developing software (OUTS=in) for a 5-person accounting office. Since the analyst’s knowledge of the problem domain is low and the number of stakeholders is few, passive techniques such as observation of a few stakeholders (ANAL=passive, STAK=few) would allow the analyst to gain the required problem domain knowledge rapidly. The above examples clearly show the relationship between the two ontologies we have created for techniques and situations and the interdependent nature of those ontologies. We feel that these ontologies by themselves represent a significant contribution to the elicitation and ontology literature bases. However, the next section of this chapter reports on our efforts to revise, enhance, and integrate the two ontologies during the Elaboration Phase.

5.

ELABORATION PHASE RESULTS

The elicitation and situational characteristic ontologies from the Conceptual Phase were refined and integrated with our model of requirements elicitation (Hickey and Davis, 2004) to create our proposed requirements elicitation ontology. The Unified Modeling Language (UML) was used to represent the concepts, relationships, and behaviors of this ontology. An overview of the complete ontology, showing the role of requirements elicitation in the overall requirements process, is shown in Figure 14-5 and described in the following section. Then, in section 5.2, we focus on those elements of the ontology directly related to elicitation technique selection (the primary purpose of the ontology). Figure 14-6 shows detailed attributes, relationships, and critical behaviors for the selected elements.

420


5.1

Requirements Elicitation Ontology Overview

The requirements elicitation ontology shown in Figure 14-5 expands on the discussion of the requirements process begun in Section 2. The ontology is specifically designed to be general enough to cover the wide variety of requirements processes used in the software development industry. The key elements of the ontology are as follows: • A Requirements Process is initiated by an organization to create or update (i.e., manage) an SRS (system or software requirements specification) for a project/system. • An SRS is an aggregation of the Requirements identified for that project/system. The specific content, format, and even the formality of the SRS and information about the Requirements are dictated by the

Requirements Process

manages

SRS description status

Requirement Type type status

Requirement manages Requirements Activity Generic Method

perform() : Requirement

identifier description status

description characteristics uses

Method Triage

Specification

Elicitation Method uses Elicitation

identifes

elicit() : Requirement influenced by

Situation characteristics

Figure 14-5. Overview of Requirements Elicitation Ontology

Ontology Handbook

•

•

•

•

421

organization. Each Requirement may also be classified as a specific Requirement Type (e.g., functional vs. non-functional requirement, data vs. process requirement). This classification, as well as the status (e.g., incomplete, complete, approved) of the SRS, the various Requirement Types, and the individual Requirements are important considerations during elicitation and when selecting elicitation techniques. A Requirements Process is made up of one or more Requirements Activities which analysts perform (using one to many Methods) to identify, select, document, or otherwise update/maintain (i.e., manage) one or more Requirements. Although there is no standard name or number of requirements activities, at the most basic level, a Requirements Activity can be classified as: (1) Elicitation if it seeks to identify requirements, (2) Triage if it seeks to prioritize/select requirements or (3) Specification if it seeks to document requirements. Other classifications of requirements activities easily fit in this same framework. Focusing in on requirements elicitation, analysts elicit requirements using an Elicitation Method, which is any type of Method that helps identify, discover, uncover, create, or otherwise determine Requirements. Moreover, it became clear during the Conceptual Phase testing and the interviews with experts (Task 6, Figure 14-4), that many Methods have very similar characteristics and are often considered together as a single Generic Method. For example, an interview could be face-to-face or via phone or video-conference, with one or a few users, formal or informal – but all these variations are generically considered an interview. There are similar variations for collaborative workshops and many other Methods, therefore the super-class Generic Method was added to the ontology during this phase. To effectively elicit requirements, the analyst must take into account the context within which elicitation occurs. Therefore, the ontology recognizes that Elicitation is influenced by (and also influences) the Situation. The next section explores the specific characteristics of the Situation that most directly influence Elicitation.

5.2

Focusing on the Elicitation Technique and Situational Components of the Ontology

Once the overall requirements elicitation context was set for the ontology (see Figure 14-5), the next step in the Elaboration Phase was to add detailed concepts, relationships, and behaviors to those elements of the ontology specifically related to requirements elicitation and elicitation technique selection. Specific elements of concern include: Elicitation, Elicitation

422


Method, Requirement, Requirement Type, and Situation. Figure 14-6 provides the detailed ontology for these elements as follows: • When evaluating the ontologies created during the Conceptual Phase and discussing elicitation techniques during the expert interviews (Task 6, Figure 14-4), it become very clear that there was a great deal of confusion on the differences between an elicitation technique and method, the notation used to document information learned while utilizing a technique, and any automated software tools that may be used to support a technique. Many in the software development industry use these terms interchangeably, often leading to confusion or incomplete understanding of how elicitation is actually being performed. Therefore, one of the first enhancements made during the Elaboration Phase was to explicitly define an Elicitation Method as a combination of an Elicitation Technique which specifics of how to elicit requirements (e.g., interview users, conduct a collaborative workshop); the Notation(s) which may be used to record requirements elicited using that technique (e.g., natural language, a modeling language like UML); and Tool(s) which may be used with that technique (e.g., a word processor, CASE or diagramming tool, group support system). • The next step was to elaborate on the detailed characteristics of an Elicitation Technique. First, an attribute for the basic description of the technique was added. The ten dimensions of the elicitation technique ontology developed during the Conceptual Phase (described in section 4.1) were expanded into twelve attributes to increase accuracy, clarity, and flexibility. This flexibility was essential since some techniques could take on multiple values for a given dimension, making an either/or choice unacceptable. For example, the Convergence/Divergence (CONV) dimension was split into two separate Boolean attributes, converges and diverges, since the Conceptual Phase evaluation and interview results indicated a technique could support both. Product/Human Focus (FOCU) was similarly split into separate product-focus and human-focus attributes. The other eight dimensions of the initial elicitation technique ontology are directly represented as individual attributes of an Elicitation Technique. The remaining attributes were added during the Elaboration Phase testing, and are described in conjunction with the discussion of testing results in section 5.3. • An overview of the initial situational ontology created during the Conceptual Phase is provided in section 4.2. During the Elaboration Phase, this ontology was formalized and documented as part of the detailed elicitation ontology shown in Figure 14-6. The Situation was divided into three main classes representing situational characteristics

Ontology Handbook

423 Elicitation

elicit (inout R : Requirement, inout S : Situation, in t : Elicitation Technique ) : Requirement uses

identifes

Elicitation Method

Requirement

Elicitation Technique description physical-colocation temporal- colocation record-keeper analyst-role converges diverges anonymity stakeholder-count tool-based product-focus human-focus direct/indirect match-to-rqmts-type communication-media reality-gap agility quality-of-info productivity ... select () : Elicitation Technique Notation known/ preferred by

identifier description status ... influenced by

Requirement Type constrained by type status ...

constrained by

Situation characteristics ...

Tool

Participant

Domain

Environment

identification communication-skills availability distributedness ...

Analyst

Developer

analysis-experience domain-experience facilitation-skills negotiation-skills #analysts ...

SE-experience SE-process-exp domain-experience solution-consensus #developers ...

Stakeholder domain-experience rqmts-definition-ability computer-expertise #users #roles problem-consensus solution-consensus co-operation ...

Problem Domain

Organization

Project

application-domain application-maturity application-emphasis problem-complexity problem-fuzziness deterministic increments current-system conflicting-needs NFR-importance interface-importance temporal- rqmts change-frequency change-magnitude ...

identification process-maturity process-mandates quality-commitment management ...

description primary-rqmts-source other-rqmts-sources funding schedule turnover distributedness ...

Solution Domain solution-type acquisition-method complexity size ...

External competition market ...

Figure 14-6. Detailed Elicitation Technique Selection Ontology

relating to the Participants in the requirements process, the Domain for which requirements are being elicited, and the Environment in which that elicitation occurs. Participants are further classified as: Stakeholders (i.e., all customers or users who may be involved in the requirements process or serve as the source of requirements), Analysts (originally called Bridge-Builders), Developers (originally, Solution Builders). The

424


names of the latter two participant groups were modified from the original terms used during the Conceptual Phase to more closely align with the terms used in the software development industry. Similar to the original situation ontology, Domain was divided into: Problem Domain and Solution Domain. The definition of the Environment was expanded to include characteristics of the: Project, Organization, and External environment. Detailed characteristics/attributes for each of type of situational factor are shown in Figure 14-6. (Note: Underlined attributes are class attributes used to capture a single value for the entire class, e.g., the total number of analysts participating.) • Ontology behaviors are also shown in Figure 14-6 using two methods: (1) specification of the elicit and select methods for the Elicitation and Elicitation Technique classes and (2) relationships between concepts (classes) in the ontology. These behaviors are based on the mathematical model of elicitation defined by Hickey and Davis (2004). Specification of the behaviors also led to additional elaboration of the characteristics of Elicitation Technique. Specifically, the selection of an Elicitation Technique is constrained by the Requirement Type the analyst is trying to elicit since some techniques are better suited to capturing some types better than others. The attribute match-to-rqmts-type was added to capture this inherent characteristic of Elicitation Techniques. Selection of an Elicitation Technique is also constrained by the Situation. This relationship formed the primary basis for testing during the Elaboration Phase, as described next.

5.3

Testing the Requirements Elicitation Ontology

Detailed testing of the ontology during the Elaboration Phase focused on ensuring that for every characteristic of the Situation that constrained selection of an Elicitation Technique, there was one or more characteristics of Elicitation Techniques that would identify an Elicitation Technique as appropriate in that Situation. To verify the completeness of this matching, the authors created a matrix of Situation vs. Elicitation Technique characteristics and analyzed each characteristic pair to determine if that Situation characteristic drove the need for that Elicitation Technique characteristic. This analysis identified the need for several additional Elicitation Technique characteristics. • Participants in a project may vary significantly in the history and degree of co-operation, but the original ontology did not include a specific Elicitation Technique characteristic that directly related to this situation. Media richness theory (Daft and Lengel, 1986) indicates that communication media inherently vary in their ability to communicate

Ontology Handbook

425

information. However, many researchers hypothesize that this communication richness is a function of both the media and a variety of situational factors such as the history of the group communication (Burke and Aytes, 1998; Dennis and Valacich, 1999; Te’eni et al., 2001). In situations with little-to-no history of cooperation or when co-operation problems are anticipated, an Elicitation Technique using a richer communication media would generally be preferred. In contrast, when Participants have an excellent history of co-operation, leaner communication media may be sufficient. To capture these relationships, the communication-medium characteristic was added to Elicitation Technique. • Stakeholders also vary in their ability to define requirements (rqmtsdefinition-ability). Prototyping and other elicitation techniques like scenarios that provide more concrete representations of reality can be very useful when individuals have difficulty defining requirements. Other techniques use more abstract representations of requirements (e.g., many of the modeling techniques commonly used by analysts). These techniques may work well with those with greater experience and expertise in defining requirements. The reality-gap characteristic was added capture the gap between reality and a specific Elicitation Technique. • Analysis of the Environment and Domain characteristics drove the addition of the agility, quality-of-info, and productivity characteristics of Elicitation Techniques.

6.

DISCUSSION

Building ontologies is a difficult process (Gruninger and Lee, 2002) that is never fully complete (Kishore et al., 2004a). Therefore, it should not be surprising that there are limitations to the current research and many future research opportunities. These limitations and opportunities are discussed in the following sections. However, regardless of the on-going nature of this research, this research currently provides significant contributions for researchers and practitioners. A few of these contributions are highlighted in section 6.3.

6.1

Limitations

The major limitation of this research is that the proposed ontology has not been explicitly agreed to by the requirements elicitation community. Virtually all ontology researchers emphasize the need for such agreement. For example, Gruber (1993) defines ontology as a “shared

426


conceptualization.” Fensel (2004) refers to ontology as a “communitymediated and accepted description.” This lack of agreement may be less of a problem for this research for the following reasons: • As described in the earlier sections of this chapter, the ontology was built from commonly-used requirements resources and information from experts in the field. Therefore, as a minimum, it should be understood by members of the requirements elicitation community. • The ontology will be used to build a single information system for use by analysts in selecting elicitation techniques. At the current time, we do not anticipate information exchange between information systems or broader automated use of the ontology. Therefore, common understanding may be sufficient at this stage of research in the relatively new field of requirements elicitation technique selection. • Given the diversity of the requirements elicitation community, reaching consensus will be extremely difficult. As mentioned earlier, the two major arms of the community, information systems (IS) and requirements engineering (RE), do not even agree what to call elicitation or those who perform that activity. However, even with their differences, IS and RE have been able to co-exist and communicate, indicating at least a basic understanding of both sets of terms. Regardless of these mitigating circumstances, the need for consensus will be addressed during the Definition Phase of this research, as discussed next.

6.2

Future Research

As described in Section 3, the primary focus of future research will be the Definition Phase. After we complete interviewing experts (Figure 14-4, task 6), we will revise and finalize the ontology (task 7) and mapping between technique and situation characteristics (task 8). As occurred during the earlier research phases we anticipate that the mapping will identify additional characteristics which should be included in the revised ontology. The final task (task 9) of this research effort will be to implement and validate the ontology-based mapping in a tool to aid novice analysts in selecting an appropriate elicitation technique. We have implemented a prototype tool called CoStar (Colorado Selector of Techniques for Acquiring Requirements). CoStar presents analysts with a list of questions. The responses to these queries identify the characteristics present in the current situation. These characteristics are then mapped to a vector in the elicitation technique attributes vector space. Finally, the tool presents to the analyst a list of techniques corresponding to that vector. Much more work is necessary before this tool is ready for widespread use. Elicitation technique and situational characteristics will be updated to reflect

Ontology Handbook

427

the final, integrated ontology resulting from the Elaboration and Definition Phases. Then, relationships between situational characteristics and between situational and technique characteristics (missing from the initial tabular/faceted ontologies, but captured in the final ontology) will be analyzed to streamline the questions that the analyst must answer. Research to date indicates that while all characteristics are important for some possible situation, a much smaller set will be critical to any given situation (Hickey and Davis, 2003b). So, the goal will be leverage the power of the comprehensive ontology and sequence the questions that the analyst must answer (1) to rapidly focus on that situation, (2) eliminate unnecessary questions, but (3) continue to ask questions until a workable set of recommended techniques are identified from which the analyst may choose based on personal preference (Hickey and Davis, 2004). Technique recommendations will be updated to reflect the final results of the expert interviews and to fully implement our iterative model of requirements elicitation (Hickey and Davis, 2004) which requires a series of technique recommendations to parallel each of the steps of the elicitation process. Validation will need to address evaluation of the tool as well as the ontology itself. The tool will be extensively tested to ensure that practical recommendations are generated for the majority of common situations. Validation of the ontology will take place in two stages: (1) initial evaluation as required to complete the proposed analyst information system and (2) a broader evaluation and refinement to attempt to reach consensus on the ontology across the requirements elicitation community. If this effort proves successful, the community may also want to pursue expanding the ontology beyond elicitation to the entire requirements management process.

6.3

Contributions

The research presented in this chapter directly contributes to both elicitation research and practice. It demonstrates how ontologies can be used to compare the many, often similar, available requirements elicitation techniques and help choose between them for a given situation. The ontology defined herein is solidly based in the existing literature and on more than 25 years of the researchers’ experience in elicitation. Even though the proposed ontology has not yet been validated, the testing we have completed so far and feedback from our expert interviewees indicates that only limited enhancements may be required. As a result, the ontology and technique selection process presented in this chapter can be used now in research and practice as follows: • Researchers and practitioners can use the elicitation technique characteristics included in the ontology to sort through the hundreds of

428


existing and proposed techniques to understand techniques’ essential similarities and differences. • Researchers can use the situational characteristics identified in the ontology to explicitly describe the situations their new techniques are designed to support, thereby aiding practitioners in identifying the ‘right’ techniques for their situation. • Practicing analysts can use the situational portion of the ontology to alert them to the factors that may impact the effectiveness of their elicitation process. Analysts with some experience should also be able to use the ontology and technique selection examples to improve their current technique selection process, thereby improving the current state of the practice of requirements elicitation.

7.

SUMMARY

This chapter has walked the reader through the iterative development of an integrated, requirements elicitation ontology, created to assist inexperienced analysts in selecting elicitation techniques that are applicable to a situation. During the Conceptual Phase of the ontological engineering process, two ontologies were created. The first ontology identified 10 key characteristics of elicitation techniques that highlight the similarity and differences between the seemingly endless variations of elicitation techniques. The second ontology highlighted situational characteristics relevant to the selection of elicitation techniques. The technique ontology also took into account this situational ontology so that the closeness of two elicitation techniques is proportional to their relative applicability in similar situations. The proposed mapping between these ontologies was explored for selected examples and provides the basis for the evaluation of the effectiveness of elicitation techniques for specific situations. In the Elaboration Phase, the two ontologies were revised and integrated with the authors’ model of requirements elicitation to create a single, integrated, requirements elicitation ontology. This ontology was represented using the Unified Modeling Language and included concepts, relationships, and behaviors critical for requirements elicitation and elicitation technique selection. The ontology was tested for completeness by comparing individual situational characteristics to elicitation technique characteristics with additional technique characteristics added as necessary. Finally, the chapter discusses the limitations and contributions of this research and explores areas for future research. Future research will focus on the Definition Phase to formalize the ontology and implement it into an

Ontology Handbook

429

effective tool for the selection of elicitation techniques by inexperienced analysts. Current research results can be used by analysts to improve the state of requirements elicitation practice, with even more wide-spread improvements anticipated when that tool is implemented and validated.

REFERENCES Alexander, L., and Davis, A., 1991, Criteria for the selection of a software process model, 15th IEEE COMPSAC, IEEE Computer Society, Los Alamitos, CA, pp. 521-528. Bento, A., 1994, Systems analysis: A decision approach, Info. & Mgmt 27(8):185-193. Boehm, B., Abts, C., Brown, A., Chulani, S., Clark, B., Horowitz, E., Madachy, R., Reifer, D., and Steece, B., 2000, Software Cost Estimation with COCOMO II, Prentice Hall, Upper Saddle River, NJ. Burke, K., and Aytes, K., 1998, A longitudinal analysis of the effects of media richness on cohesive development and process satisfaction in computer-supported work, 31st Hawaii Int. Conf. on the System Sciences 1, IEEE Computer Society, Los Alamitos, CA,, pp. 135144. Byrd, T., Cossick, K., and Zmud, R., 1992, A synthesis of research on requirements analysis and knowledge acquisition techniques, MIS Quarterly 16(1):117-138. Checkland, P., and Scholes, J., 1991, Soft Systems Methodology in Action, Wiley, Chichester, UK. Conger, S., 1994, New Software Engineering, Wadsworth, Belmont, CA. Coughlan, J., and Macredie, R., 2002, Effective communication in requirements elicitation: A comparison of methodologies, Req. Eng. 7(2):47-60. Daft, R., and Lengel, R., 1986, Organizational information requirements, media richness and structural design, Mgmt Science 32(5):554-571. Davis, A., 1993, Software Requirements: Objects, Functions and States, Prentice Hall, Upper Saddle River, NJ. Davis, A., 2005, Just Enough Requirements Management, Dorset House, New York. Dennis, A., and Haley Wixom, B., 2000, Systems Analysis and Design: An Applied Approach, Wiley, New York. Dennis, A., and Valacich, J., 1999, Rethinking media richness: Towards a theory of media synchronicity, 32nd Hawaii Int. Conf. on System Sciences, IEEE Computer Society, Los Alamitos, CA. Fensel, D., 2004, Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce, Springer, Berlin. Gause, D., and Weinberg, J., 1989, Exploring Requirements: Quality Before Design, Dorset House, New York. Glass, R., 2002, Searching for the holy grail of software engineering, Comm. of the ACM 45(5):15-16. Goguen, J., and Linde, C., 1993, Software requirements analysis and specification in Europe: An overview, 1st Int. Symp. on Req. Eng., IEEE Computer Society, Los Alamitos, CA, pp. 152-164. Gomez-Perez, A., Fernandez-Lopez, M., and Corcho, O., 2004, Ontological Engineering: With Examples from the Areas of Knowledge Management, e-Commerce, and the Semantic Web, Springer, London. Gottesdiener, E., 2002, Requirements by Collaboration, Addison-Wesley, Reading, PA.

430


Gruber, T., 1993, A translational approach to portable ontologies, Knowledge Acq. 5(2):199220. Gruninger, M., and Lee, J., 2002, Ontology: Applications and design, Comm, of the ACM 45(2):39-41. Hickey, A., and Davis, A., 2002, The role of requirements elicitation techniques in achieving software quality, Req. Eng.: Foundations for Software Quality WS, Essen, Germany. Hickey, A., and Davis, A., 2003a, A tale of two ontologies: The basis for systems analysis technique selection, Americas Conf. on Info. Sys., Association for Information Systems, Atlanta. Hickey, A., and Davis, A., 2003b, Elicitation technique selection: How do experts do it? 11th IEEE Int. Req. Eng. Conf., IEEE Computer Society, Los Alamitos, CA. Hickey, A., and Davis, A., 2004, A Unified Model of Requirements Elicitation, J. of Mgmt Info. Sys. 20(4):65-84. Hickey, A., Davis, A., and Kaiser, D., 2003, Requirements Elicitation Techniques: Analyzing the Gap Between Technology Availability and Technology Use, Comparative Tech. Transfer & Society 1(3):279-302. Higgins, L., 2003, Principles of Marketing, www.principlesofmarketing.com. Hoffer, J., George, J., and Valacich, J., 2002, Modern Systems Analysis and Design, 3rd ed., Prentice Hall, Upper Saddle River, NJ. Hofmann, H., and Lehner, F., 2001, Requirements engineering as a success factor in software projects, IEEE Software 18(4):58-66. Holsapple, C., and Joshi, K., 2002, A collaborative approach to ontology design, Comm. of the ACM 45(2):42-47 Juristo, N., and Moreno, A., 2001, Basics of Software Engineering Experimentation, Kluwer Academic, Boston. Kishore, R., Sharman, R., and Ramesh, R., 2004a, Computational ontologies and information systems: I. Foundations, Comm. of the Assoc. for Info. Sys. 14:158-183. Kishore, R., Sharman, R., and Ramesh, R., 2004b, Computational ontologies and information systems: II. Formal specification, Comm. of the Assoc. for Info. Sys. 14:184-205. Kishore, R., Zhang, H., and Ramesh, R., 2004c, A helix-spindle model for ontological engineering, Comm. of the ACM 47(2):69-75. Kotonya, G., and Sommerville, I., 1998, Requirements Engineering: Processes and Techniques, Wiley, Chichester, UK. Lauesen, S., 2002, Software Requirements: Styles and Techniques, Addison-Wesley, Harlow, UK. Leffingwell, D., and Widrig, D., 2000, Managing Software Requirements, Addison-Wesley, Reading, PA. Liebowitz, J., 2001, Knowledge Management: Learning from Knowledge Engineering, CRC Press, Boca Raton, FL. Macaulay, L., 1996, Requirements Engineering, Springer, London. Maciaszek, L., 2001, Requirements Analysis and System Design, Addison-Wesley, Harlow, UK. Maiden, N., and Rugg, G. 1996, ACRE: Selecting methods for requirements acquisition, Software Eng. J. 11(5):183-192. Nunamaker, J., Dennis, A., Valacich, J., Vogel, D., and George, J., 1991, Electronic meeting systems to support group work, Comm. of the ACM 34(7):40-61. Robertson, S., and Robertson, J., 1999, Mastering the Requirements Process, AddisonWesley, Harlow, UK.

Ontology Handbook

431

Romano, N., Nunamaker, J., Briggs, R., and Mittleman, D., 1999, Distributed GSS facilitation and participation: Field action research, 32nd Hawaii Int. Conf. on Sys. Sciences, IEEE Computer Society, Los Alamitos, CA. Scharer, S., 1981, Pinpointing Requirements, Datamation (April):139-154. Schewe, C., and Hiam, A., 1998, Portable MBA in Marketing, 2nd ed., Wiley, New York. Standish Group, 1995, The Chaos Report, www.standishgroup.com. Te’eni, D., Sagie, A., Schwartz, D., Zaidman, N., and Amichai, Y., 2001, The process of organizational communication: A model and field study, IEEE Trans. on Prof. Comm. 44(1):6-20. Thayer, R., and Dorfman, M., 1994, Standards, Guidelines, and Examples on System and Software Requirements Engineering, IEEE Computer Society, Los Alamitos, CA. Wiegers, K., 2003, Software Requirements, Microsoft, Redmond, WA. Wood, J., and Silver, D., 1995, Joint Application Development, Wiley, New York. Yeh, R., and Ng, P., 1990, Software requirements – A management perspective, in: Systems and Software Requirements Engineering, R. Thayer and M. Dorfman, eds., IEEE Computer Society, Los Alamitos, CA, pp. 450-461.