A Problem-Oriented Analysis Method Capable of Identify and Derive the Best-Suited Conceptua

Best-Suited Conceptual Model for the User Need

†

1

Oscar Dieste1, Marcela Genero2, Ana M. Moreno3

Departamento de Sistemas Informáticos y Programación

Facultad de Informática

Universidad Complutense de Madrid

E-mail: odiestet@fdi.ucm.es

Departamento de Informática Escuela Superior de Informática Universidad de Castilla-La Mancha E-mail: Marcela.Genero@uclm.es

2

3

Departamento de Lenguajes y Sistemas Informáticos e Ingeniería del Software

Facultad de Informática

Universidad Politécnica de Madrid E-mail: ammoreno@fi.upm.es

Abstract

This paper proposes new analysis method, called POAM (Problem-Oriented Analysis Method). POAM has been developed to solve several shortcomings of existing conceptual models (solution orientation and dependence of concrete development approaches). Those shortcomings have adverse effects on software development, since practitioners are encouraged to think in terms of a solution before the problem is well understood, thus anticipating perhaps bad design decisions.

POAM has several features that overpass those adverse characteristics of conceptual models. First, POAM uses a kind of conceptual model unbiased towards any development approach, thus supporting developers to understand the problem and its constraints before any solution is identified. Second, POAM is able to identify and derive the best classical conceptual model for a given situation, allowing developers to use in design those notations, as data flow diagrams or class diagrams, universally used for software development.

1. INTRODUCTION

Analysis is one of the most critical tasks in Requirements Engineering, due to the huge importance of its objectives: understand the problem or user need, and define accordingly all the features that the future software system must comply with, so that several alternative solutions may be proposed and evaluated before proceeding software construction [Davis, 1993].

There are a wide diversity of methods and techniques to perform the analysis task. They range from informal approaches, like checklists or interaction matrices [Kotonya and Sommerville, 1998] to more formal techniques, for example, scenarios [Haumer et al., 1998], viewpoints [Kotonya and Sommerville, 1996] or conceptual models (CMs). The later, CMs, play a very important role in almost every development project, because CMs are a key component of the vast majority of currently used development approaches (object oriented, structured, etc.). These approaches use CMs from the very early stages to record, manipulate and validate all the information gathered from †

Corresponding author

1

customers and users and, eventually, to define the requirements for the future software system [Beringer, 1994] [Loucopoulos and Karakostas, 1995] [Kaindl, 1999].

CMs are, thus, crucial, since they help to structure the problem prior to define software requirements and start software construction. Nevertheless, several authors have pointed out that current CMs sometimes fail to do their jobs of description and understanding during analysis. Criticisms can be divided into two major groups:

•

The orientation of the conceptualisation methods, stressing the fact that most CMs are oriented to get a computational solution to the problem or need raised, and not to ease the understanding of the user need [Høydalsvik and Sindre, 1993] [Bonfatti and Monari, 1994] [McGinnes, 1992].

The association between CMs and specific approaches to software development. Here, the use of a given CM during the early phases of development limits the number of possible implementation alternatives, so that only those options that are compatible with the CM used originally are feasible. If computational characteristics are included in CMs, they become linked to a particular implementation approach, that is, once a given conceptualisation method has been selected to describe the problem domain, it is practically impossible to change the above method a posteriori without having to reanalyse the problem [Davis et al., 1997] [Northrop, 1997] [Juristo and Moreno, 2000].

•

In short, any software system development approach can be said to be preconditioned from the very start, as soon as their CMs are built. The problem raised when computational considerations are included within the CM is that developers are forced to make a solution-oriented decision during the early development phases, when the problem or user need is still not well understood. Developers thus run the risk of making the wrong decision, because they are not in possession of all the information relevant to the problem. Even worse, very often the CMs selected are those models with which developers are familiar, models called for by individual standards or even, as specified by [Mylopoulos et al., 1999], the models that are “in fashion”. So, in the era when the structured approach was in vogue, techniques such as DFDs were used for conceptual modelling, whereas today, with the rise of object-oriented programming and design, techniques like object diagrams, interaction diagrams, etc., are employed for problem analysis.

Moreover, if data flow diagrams have been used to model the problem domain, for example, it will almost certainly be necessary to use the structured method in later development phases; whereas a method of object-oriented development will have to be used following upon an object-oriented analysis. Therefore, if we intended to switch development paradigms, that is, for example, pass from a data flow diagram to an object-oriented design, this transformation would lead to an information gap that is very difficult to fill. This phenomenon appears because each CM acts like a pair of glasses used by the developer to observe the domain and user reality. These glasses highlight certain features, tone down others and hide others. Once the real world has been filtered through the CM, it is difficult to retrieve anything that has been lost or condensed, even if the later development process requires this information. The only way of recovering the features lost in the CM filter is to reanalyse reality using a different pair of glasses; that is, to repeat the operation using another CM

All this means that the CMs used nowadays are not appropriate to perform the analysis tasks in Requirements Engineering. In this paper, we propose an alternative approach that aims to remove the above constraints. The paper is structured as follows: section 2 describes our approach for a conceptual modelling process independent of any development paradigm. Section 3 shows an example of analysis carried out using our proposal, in order to illustrate the advantages of using a paradigm-independent method. Finally, the preliminary results of applying the proposed approach are discussed in section 4.

2. PROPOSED APPROACH: AN ANALYSIS METHOD INDEPENDENT OF THE DEVELOPMENT

PARADIGM As it was said above, the development approaches used nowadays have several shortcomings, induced by the development orientation of their related CMs. In order to avoid these problems, it is needed that CMs allow to include, independently of any design issue, all the information required about the problem to solve, for developers to later address the software system construction. Indeed, it is needed that a development-independent CM allows to:

2

• Understand the problem or need before considering an approach for developing a software system that meets this need. The understanding of the need must be independent of the chosen problem-solving approach, that is, it must not precondition the use of any development approach

• Decide which is the best development approach once the problem or need has been understood.

There are two basic paths to fulfil the above criteria: (1) modify existing CMs, including new components with stronger representation capabilities, or (2) define new CM provided with such capabilities. Several reasons seem to support the second alternative: on the one hand, existing CMs are well defined, known and understood, so that it is hard to propose extensive modifications to them and, in the other hand, they have interesting properties (for example, the ease of translation from analysis to design) that is worth preserving.

Thus, the proposed approach, called “Problem-Oriented Analysis Method” (POAM), relies on the definition of a new class of CM, which we call Generic Conceptual Model (GCM). The GCM allows the conceptualisation of unstructured, real-world problems independently of any development approach. That model, introduced in section 2.1, is used according a detailed analysis process, introduced in section 2.2, whose final result is the best-suited CM (that is, a CM now used in development approaches like Structured Analysis -data flow diagrams- or Object-Oriented Analysis -class diagrams, use cases, etc.-) to continue the development process, as shown in Figure 1. The connection made between POAM and the classical development methods, like object orientation, was designed to help the adoption of POAM in any development project with nearly no changes in the working environment.

Real-WorldProblemPOAMStructuredapproachesObject OrientedapproachesReal TimeapproachesOther model-baseddevelopmentapproachesSoftwareSystem Figure 1. Relationship between POAM and the typical development approaches

2.1. Generic Conceptual Model

The GCM is a set of interrelated representation schemas, either graphical, tabular or textual, used to record and manipulate all information gathered during problem analysis. The salient characteristic of these representation schemas is their independence of any computing feature that could bias the GCM towards a given implementation paradigm, for example, towards a process-centred or object-centred perspective of the problem at hand. The proposed GCM components are as follows:

•

Concept Maps: are graphical representation structures. Concept maps are variations on the conceptual maps, derived from the work of Ausubel on Learning Theory and Psychology and later formalised by [Novak and Gowin, 1984]. Concept maps, because its simplicity (they only use two builders, concepts and associations, with which it is possible to construct propositions) are able to represent almost any thing or situation of the real world, having an expression power close to natural language.

Dictionaries: are tabulated information representation schemas. Dictionaries have a set of predefined fields that define what sort of information they record. There are two types of dictionaries:

•

3

o Identificative Dictionary (or Glossary): This dictionary merely records the information required

to recognise a concept or association identified while investigating a problem, and to distinguish one element or association from another. o Descriptive Dictionary: Its goal is to record refined information, that is, all the concepts and

associations which represent all the important aspects of the problem at hand.

•

Narrative Description: is natural language text, derived from the concept map and dictionaries. The narrative description can be use to validate the GCM, because it is very understandable for end users (although it is not a literary masterpiece) and, as there is a direct relationship between the narrative description and the other representation schemas, the comments and corrections suggested by the users can be fed back into those schemas.

The three representation schemas (map, dictionaries and text) are complementary, that is, no one representation schema dominates the modelling process, but any schema supports the others, satisfactorily recording information that they do not represent adequately, and thus providing a different viewpoint for the same information. Complementariness is important, because the way the information is expressed benefits or impairs its understanding [Vessey, 1991]. The different components of the GCM can represent the same information, but each analyst can select and use the best suited expression in each moment (for example, depending on the involved stakeholders, representation preferences or available software tools).

The four above-mentioned representation schemas are used during the POAM process activities and steps, as described in next section.

2.2. Generic Conceptual Model Development Process

The proposed process is composed of two activities, as shown in Figure 2(a). The goal of the first activity, called User-Problem Oriented Analysis, is to understand the problem or need and ends when the GCM, which represents the acquired knowledge, has been developed. This GCM is the input for the second activity, called Software-Oriented Analysis, whose goal is to identify which typically-used CM (for example, data flow diagram, class diagram, etc.) is best suited for representing the problem, as well as to transform the GCM into that CM.

This first level of decomposition is too general to guide a developer as how to perform analysis. Therefore, both activities are divided into two steps, as shown in Figure 2(b), which are further broken down into detailed tasks. Thus, the User-Problem Oriented Analysis task is decomposed as follows:

•

Preliminary Analysis: In this step, the problem or need raised by the user is examined superficially with the aim of defining a User Problem Preliminary Model. The preliminary model is a simplified version of the GCM, which is composed of: (1) a concept map; (2) an identificative dictionary; and (3) a narrative description. The goals of this step are to: (1) identify the most important elements of the problem domain; (2) describe these elements; and (3) organise all the elements of the problem domain into a structure, by means of which to define the associations there are among these elements.

Comprehensive Analysis: In this step, the problem or need is studied in as much detail as required to develop the User Problem Comprehensive Model. Comprehensive model is the name assigned to the complete GCM, although in this task the descriptive dictionary is used instead of the identificative dictionary, and the narrative description is often excluded. The goals of this step are to: (1) check that the important problem elements have been identified; (2) describe the above elements exhaustively; and (3) clearly determine the associations among elements.

•

Having completed the User-Problem Oriented Analysis, an exhaustive description of all the important problem elements has been obtained. Using the proposed approach, however, we can go even further to derive, from the information contained in the GCM, a CM by means of which to continue software system development using any of the development approaches now available, such as structured, object-oriented or real-time approaches. The CM is derived in the Software-Oriented Analysis activity.

4

ProblemPreliminaryAnalysis-Non-consolidated elements map-Identification dictionary-Narrative descriptionUser Problem Preliminary ModelUser-Problem-OrientedAnalysisComprehensive Analysis-Consolidated elements map-Description dictionary-Narrative description (optional)Generic ConceptualModelUser Problem Comprehensive ModelIdentification of theSuitableConceptualModelSoftware-Oriented AnalysisRequirements Canonical ModelSelected Conceptual ModelDerivation of the Selected Conceptual ModelConceptual ModelConceptual Model(a)(b)

Figure 2. Proposed process

This activity is decomposed into two steps:

•

Identification of the Suitable Conceptual Model: In this step, the suitable conceptual model (SCM) is identified. The SCM is the CM that better represents all the information gathered in the GCM for a given problem.

An interpretation procedure has to be applied to the GCM in order to identify the SCM. This procedure identifies which combinations of concepts and associations of the GCM can be related to constructors of classical CMs (for example, a process, class or attribute). A requirements representation formalism proposed by Davis [Davis et al., 1997], although strongly modified, has been used as intermediate language for the interpretation procedure. This formalism, termed “Canonical Model”, in accordance with its author’s intent, provides a set of building blocks that can be used to represent the information contained in a range of CMs.

Interpretation is totally formalised and nearly engineer-independent. Such independence may, anyway, be partially lost when many ambiguities arise during the Canonical Model-GCM correlation. Ambiguity is the possibility of assigning two or more elements of the Canonical Model to any given GCM element. In this case, it is the engineer who has to decide, depending on the semantics of the GCM and the Canonical Model, which particular interpretation is the best suited.

After interpretation, the GCM is called the Requirements Canonical Model (RCM), as the GCM can now be read in classical CMs terms. When the RCM has been obtained, it is possible to identify the Suitable Conceptual Model (SCM). The SCM will be the CM with the highest fitness value, where fitness is the ratio between the propositions a given CM can represent and the total number of RCM propositions. To

5

identify which prepositions of the RCM can be expressed in a given CM, a set of Identification Tables, not included in the paper because length restrictions, are used. •

Derivation of the Selected Conceptual Model: In this step, the RCM is translated into the SCM using a derivation procedure. This procedure basically involves using a set of Derivation Tables and Rules. Each Derivation Table contains all the possible combinations of Canonical Model elements that can be expressed in the target CM (that is, the SCM), along with the expression of that combinations in the particular format used by the CM in question (graphs, text, tables, etc.). The Derivation Rules modulate the use of each Derivation Table, altering the RCM in a controlled manner, so that the target CM finally obtained resembles as closely as possible a target CM developed independently for the same problem.

The target CM obtained in the above step can be refined by entering more information. However, this refinement is neither direct, nor can it be formalised, owing to the fact that the GCM cannot be interpreted directly in computational terms. Therefore, the developer will have to select what other knowledge should be recorded in the target CM and what should be discarded. Once completed, the target CM will have the same drawbacks than a CM developed directly, that is, some knowledge about the problem will have been lost and the target CM will be linked to a given development approach. Nevertheless, there is a strong difference between filtering problem elements using the current and the proposed conceptual modelling processes. With the processes now in use, developers do not take into account the problem elements that are not compatible with the CM used (class diagrams, use cases, etc.) before the problem is understood. Using the proposed approach, developers are encouraged to study and record all the possible problem perspectives in the GCM. Therefore, the loss of knowledge occurs when the problem has been understood, thus avoiding early decisions on how to solve the problem at hand.

3. ANALYING USING OUR PROPOSAL

In this section, an example showing the steps of the proposed process, as well as the use of the components of the GCM, will be provided, in order to illustrate all the theory explained in previous sections. In the following discussion, several tasks of POAM are summarized by reasons of space, but it is needed to say that there is not any subjective transformation in the model sequence, that is, all steps are based on objective transformation rules. Suppose we have the problem shown in Box 1, set out in natural language. At first glance, this problem could apparently be modelled in several different ways. For example, given the problem characteristics (objects, transformation processes that seem to exist, etc.), a data flow diagram would appear to be a suitable representation, as would an entity/relationship or a class diagram.

Hospital 123 has two patient admission procedures. The first is the admission of patients on a waiting list. The second is the admission of patients who visit the emergency department.

When a patient on a waiting list is admitted, the patient is assigned a room on a ward depending on the complaint that is to be treated. For example, if a patient is to undergo coronary by-pass surgery, the patient would be assigned to a room on the cardiology ward.

The patients admitted from the waiting list are assigned a reference physician. This physician can be any doctor belonging to the speciality related to the complaint that is to be treated.

On the other hand, patients who are admitted from the emergency deparment are immediately treated prior to any administrative procedure. Once treated, they are assigned a room no later than three hours after admission, according to the same rules as patients admitted from the waiting list. The only difference is that their reference physician will be the doctor who treated them in the emergency department rather than a physician of any particular speciality.

Box 1. Problem set out in natural language

6

However, the use of POAM makes it unnecessary to hypothesize, in this moment, which is the best-suited diagram type. During analysis, the problem is modelled using the GCM and, only later, before passing on to design, we will decide which is the best-suited CM and, depending on this decision, which development approach will be most effective for buidling the future software product. Once the problem is modeled using the GCM (after the preliminary and comprehensive analysis tasks have been carried on), a concept map like that shown in Figure 3 is obtained.

{Wards}{Patients}belsubsWard{Doctors}{Complaints}{Waiting list}belsubsComplaintsuffersPatientPatientarespecialisedin is assigned to3hours{Doctors}is reference physician ofRoomnolater thanis assigned toadmits{Energency Department}has{Rooms}subsbelbelHospital 123belis assigned tobelis reference physician ofDoctorsubs{Emergency Doctors}suffersbelDoctortreatsinemergencydepartment Figure 3. Concept map

Note that, at the same time, it is very easy to read and understand the concept map of Figure 3, but it is very difficult to interpret it in terms of any particular implementation. That map takes the form of “spaghetti”, where structural, logical and dynamic aspects are mixed coherently. That means that a variety of different information can be expressed at the same time and, therefore, the concept map does not predetermine any particular implementation. Rather, it can be used to rewrite the problem in a variety of different ways, each suited to a particular development approach.

Once the GCM has been obtained, the interpretation procedure has to be applied to identify the SCM. This procedure uses a set of tables, not shown due to length restrictions. These tables are built using the framework proposed by [Davis et al., 1997], although it has been deeply modified to allow an easy correlation with the GCM. The final result of the interpretation procedure, that is, the RCM, would be as shown in Table 1. In the RCM, all propositions of the GCM are labeled with a plausible interpretation, that is, each element of the RCM has been related to the builder (like entity, constraint or operand) that best fit the intended meaning of the proposition in the user domain.

Using the identification tables, which make it possible to relate RCM expressions to CMs, the number of propositions supported by each CM can be calculated. As there are many identification tables, they are also not included by reasons of space. Considering only the most popular conceptual models, such as the data flow diagram (DFD), the entity-relationship diagram (ER), the class diagram (CD), the state transition diagram (STD), the statechart (SCT) and use cases (UC), the fitness calculation is shown in the rigth side of Table 1.

7

Models DFD ER DC STD STCUC

Entity[repl]: Rooms √ √ √ √ Entity[repl]: Wards √ √ √ √ Entity[repl]: Complaints √ √ √ √ Entity[repl]: Patients √ √ √ √ Entity[repl]: Doctors_1 √ √ √ √ Entity[repl]: Doctors_2 √ √ √ √ Entity[repl]: Doctors √ √ √ √ Entity[repl]: Waiting list Subs: subs Entity[repl]: Patient √ Entity[repl]: Emergeny dept. Subs: subs Entity[repl]: Patients √ Entity[repl]: Doctors_2 Subs: subs Entity[repl]: Doctors_1 √ Entity[repl]: Emergency doctors Subs: subs Entity[repl]: Doctors_1 √ Entity[notrepl]: Complaint Bel: bel Entity[repl]: Complaints Entity[notrepl]: Room Bel: bel Entity[repl]: Rooms Entity[notrepl]: Patient_1 Bel: bel Entity[repl]: Waiting list Entity[notrepl]: Patient_2 Bel: bel Entity[repl]: Emergency dept. Entity[notrepl]: Ward Bel: bel Entity[repl]: Wards Entity[notrepl]: Doctor_1 Bel: bel Entity[repl]: Doctors Entity[notrepl]: Doctor_2 Bel: bel Entity[repl]: Emergency doctors p1 Entity[notrepl]: Hospital 123 Rel: admits Entity[repl]: Patients √ √ p2 Entity[repl]: Doctors_2 Rel: are specialised in Entity[notrepl]: Complaint √ √ p3 Entity[notrepl]: Patient_1 Rel: suffers Entity[notrepl]: Complaint √ √ p4 Entity[notrepl]: Patient_1 Rel: is assigned Entity[notrepl]: Room √ √ p5 Entity[notrepl]: Ward -Pof: has Entity[repl]: Rooms √ p6 Entity[notrepl]: Ward Rel: is assigned to Entity[notrepl]: Complaint √ √ p7 Entity[notrepl]: Doctor_1 Rel: is reference physician of Entity[notrepl]: Patient_1 √ √ p8 Entity[notrepl]: Doctor_2 Rel: treats in emergency dept. Entity[notrepl]: Patient_2 √ √ p9 Entity[notrepl]: Doctor_2 Rel: is reference physician of Entity[notrepl]: Patient_2 √ √ P10 Entity[notrepl]: Patient_2 Rel: is assigned Entity[notrepl]: Room √ √ P11 Entity[notrepl]: Patient_2 Rel: suffers Entity[notrepl]: Complaint √ √ P12-1 Constraint: no later than P10 Operand: P12-2 Constraint: no later than Value: 3 hours Operand: Fitness .23 .55 .71 .0 .0 .23

Table 1. RCM and calculus of model fitness. SCM is the class diagram

Fitness calculation produces a fan of values, each one representing the relative suitability of each model. The best-suited model, that is, the SCM, is the class diagram, as its fitness is the greatest (0,71 or, alternatively, 71%) of all

models considered in the SCM calculation. Note that the existence of a SCM does not mean that this model is the only possible model applicable to the problem. It only means that the SCM is the best of all the considered CMs, but the ongoing development process may be carried on using any other model belonging to the considered set of CMs, although their representation capability will be lower.

Having identified the SCM, all that has to be done is to use the Derivation Tables and Rules to obtain the target CM. These tables and rules can be used to build fragments of the target CM from the propositions of the RCM. For example, Table 2 shows part of the Derivation Table and Derivation Rules for the Class Diagram (the SCM for the example introduced in this section). The different fragments can be assembled, unambiguously, to get the desired class diagram. That diagram is not necessarily the best possible class diagram, but it is the class diagram that can be derived from the GCM. This model can be later modified to improve or complete diagram aspects, in order to make the resultant class diagram clearer and simpler.

4. DISCUSSION

The proposed approach has been validated and refined after running several case studies using POAM and using the CMs prescribed by other development approaches (structured, object-oriented and real-time approaches).

8

A total of seven test cases were designed. These test cases were solved by a series of subjects with differing software development experience levels, which were divided into four different groups. For every test case, we evaluated the effectiveness (that is, whether the CMs fit the test case design), correctness (the degree of coincidence between the CMs and the best CM for the test case), and effort (time spent to produce each CM). The results obtained so far appear to support the following findings:

•

The effectiveness of conceptual modelling using POAM was 100%, where the best-suited CM was selected in all 7 test cases. When the experimental subjects were allowed to use the development approach they think more adequate, the effectiveness was clearly lower (about 20% and higher values, depending on the experimental subject). It was also observed that subjects tend to use, in many cases, the same development approach, giving the same CM, independently of the problem at hand. This phenomenon was more frequent as the experience of the subjects in software development increase, that is, more experienced developers showed a stronger tendentiousness when selecting the more adequate development approach for a given problem.

Element (A) Link (B) Element (C) Element (A) Link (B) Element (C)

Derives to :CDerives to: :CEntity[repl] Spec Entity[repl] Process pof Entity [repl] A:A :C :CEntity[repl] Pof Entity[repl] :AStatespace pof Entity[repl] A 1. 2. 3. Rules: If an element of type Entity[notrepl] also belongs (Bel) to an element of type Entity[repl], then replace it with latter. If an element of type Entity[repl] is a subset of (Subs) an element of type Entity[repl], then replace it with the latter. If an element Entity[notrepl] satisfies neither rule (2) or (3), consider whether it can be considered coherently as Entity[repl]. Table 2. Derivation Table and Rules for the class diagram (only part of the whole table is shown)

•

The correctness of the CM obtained using POAM is greater than the CMs constructed using classical approaches. The reason appears to be that subjects gain a better understanding of the problem by performing the Preliminary Analysis and Comprehensive Analysis sub-activities. Having a better understanding, they are able to create not only a syntactically correct, but also a semantically coherent CMs. Using structured, object-oriented or real-time approaches, subjects tend to subordinate understanding to representation, outputting semantically ambiguous, albeit syntactically correct, conceptual models.

It takes longer to develop a CM using POAM. This was a foreseeable point in view of the increased workload involved in subdividing analysis. However, many of the POAM steps can be automated, either fully or partially, which means that a suitable automated support could help to compensate for the additional workload caused by the proposed approach.

•

From the above results, we can state that POAM seems to be an effective approach to conceptual modelling. POAM allows analysts to understand the problem independently of any development approach and, moreover, it is possible to identify, on the basis of the data recorded in the model, which CM, used by the classical development approaches (structured, object-oriented and real-time approaches), is best-suited to go the development project on. That CM is

9

also derivable, so that POAM can be adopted in any development project without making any changes in the project development environment.

The validation carried out to check POAM effectiveness has shown that it is effective and it even performs better than practitioners experienced in conceptual modelling under controlled conditions. In particular, POAM avoids subjective selection based on the preferences and opinions of the conceptual model developers, making an objective selection of the best-suited conceptual model to represent a given problem.

The only shortcomings of POAM appear to be related to the time it takes to build the generic conceptual model and identify and derive the classical conceptual models. However, this shortcoming refers to the efficiency and not to the effectiveness of the proposed approach. With the aim of improving POAM efficiency, we are now testing a software tool to support the proposed process, as many of the steps can, for the most part, be automated. This tool should improve POAM efficiency so that it can be used in real development projects, where efficiency considerations are often just as or more important than questions of effectiveness.

5. REFERENCES

Beringer, D., 1994. Limits of seamless in object oriented software development. In: Proceedings of the 13th International Conference on Technology of Object Oriented Languages and Systems (TOOLS), Versailles, France. Bonfatti, F., Monari, P.D., 1994. Towards a general-purpose approach to object-oriented analysis. In: Proceedings of the International Symposium of Object Oriented Methodologies and Systems, Palermo, Italy.

Davis, A., Jordan, K., Nakajima, T., 1997. Elements underlying the specification of requirements. Annals of Software Engineering, Balzer Engineering Publishers.

Davis, A.M., 1993. Software requirements: Objects, functions and states. Prentice-Hall International.

Haumer, P., Pohl,K., Weidenhaupt, K., 1998. Requirements Elicitation and Validation with Real World Scenes. IEEE Transactions on Software Engineering, vol. 24, no. 12.

Henderson-Sellers, B., Edwards, J., 1990. The object oriented systems life cycle. Communications of the ACM, vol. 33, no. 9.

Høydalsvik, G.M., Sindre, G., 1993. On the purpose of object oriented analysis. in: Proceedings of the Conference on Object Oriented Programming, Systems, Languages and Applications, New York, USA.

Juristo, N., Moreno, A.M., 2000. Introductory paper: Reflections on conceptual modelling. Data and Knowledge Engineering, no. 33.

Kaindl, H., 1999. Difficulties in the transition from OO analysis to design. IEEE Software, vol. 16, no. 5.

Kotonya, G., Sommerville, I.; 1996. Requirements engineering with viewpoints. Software Engineering Journal, vol. 11, no. 1.

Kotonya, G., Sommerville, I.; 1998. Requirements Engineering: Processes and Techniques. John Wiley and Sons. Loucopoulos, P., Karakostas, V., 1995. Systems requirements engineering. McGraw-Hill, Berkshire.

McGinnes, S., 1992. How objective is object-oriented analysis? In: Proceedings of the CAISE’92 Advanced Information Systems Engineering.

Mylopoulos, J., Borgida, A., Yu, E., 1997. Representing software engineering knowledge. Automated Software Engineering, no. 4.

Mylopoulos, J., Chung, L., Yu, E., 1999. From object-oriented to goal-oriented requirements analysis. Communications of the ACM, vol. 42, no. 1.

Northrop, L.M., 1997. Object-oriented development. In: Software Engineering, IEEE Computer Soc. Press, Los Alamitos, USA.

Novak, D., Gowin, D. B., 1984. Learning to learn. Cambridge University Press.

Vessey, I., 1991. A Theory-Based Analysis of the Graph versus Tables Literature. Decision Sciences, Vol 22.

10