Towards a Requirements-Aware Common Web Engineering Metamodel

Fernando Molina, Ambrosio TovalDepartment of Informatics and Systems

University of Murcia{fmolina, atoval}@um.es

Jesus Pardillo, Cristina CacheroDepartment of Software and Computing Systems

University of Alicante{jesuspv, ccachero}@dlsi.ua.es

Abstract

In recent years, Web Engineering development projectshave grown increasingly complex and critical for thesmooth running of the organizations. However, recent stud-ies reveal that, due to an incorrect requirements manage-ment, a high percentage of these projects miss the qualityparameters required by stakeholders. Despite this, currentWeb Engineering methodologies continue focusing on webdesign features, thus limiting the Requirements Engineer-ing tasks to the elicitation of high-level functional require-ments. This fact has caused a requirements-support gapin the recently proposed Common Web Engineering Meta-model. This paper tries to cover this gap and proposesa requirements extension for this Common Web Engineer-ing metamodel that supports measurable requirements. Thereinforcement of the role that requirements play in currentWeb Engineering methodologies, and their explicit connec-tion with quantitative measures that contribute to their ful-filment, is a necessary step in order to reduce some of thequality failures detected in Web Engineering developmentprojects, thus increasing the satisfaction of their users.

1 Introduction

The development of Web Information Systems (WIS)has lived an exponential growth in the last decade. Ini-tially, these systems were used only as a means to dissemi-nate information. However, nowadays their complexity hasincreased, they are present in numerous domains and theyhave become critical systems for the business strategy ofmany organizations [26]. For these reasons, organizationshave adapted their software development processes to dealwith the idiosyncrasy of web applications [24] and the re-search community is developing numerous methodologieswithin the scope of the Web Engineering (WE) discipline[12], with the aim of helping in the development of suc-cessful WIS.

However, as different research publications [19, 26] re-

veal, the development of this kind of systems is not exemptfrom errors, and the WIS finally developed do not alwayssatisfy the quality requirements demanded by their users.Namely, these studies highlight that the top five problem ar-eas of large-scale WE projects are (1) failure to meet busi-ness needs (84%), (2) project schedule delays (79%), (3)budget overrun (63%), (4) lack of required functionality(53%) and (5) poor quality of deliverables (52%). Anothersurvey carried out by [24] over 160 organizations that de-velop web-based software reveals that, with regard to re-quirements, the 60% of the organizations consider that oneof the main problems in their projects is related to the clar-ity and stability of requirements. In fact all these problems,far from being new, are quite similar to those encountered intraditional Software Engineering, where it has already beenargued [13, 17] that they are often a symptom of an inade-quate management of the tasks related to the requirementsworkflow of the project, tasks which the Requirements En-gineering (RE) discipline is devoted to. Corroborating thisclaim, a set of interviews with organizations that developweb-based systems reported in [26] indicated that, for 76%of the respondents, gathering the right requirements was acritical factor for the success of their projects.

In spite of these percentages, the problems relatedto requirements management in web-based developmentprojects do not seem to be solved neither in the organiza-tions that carry out these projects nor in the WE methodolo-gies proposed for WIS development. WE methodologiesare still mostly focused on the design workflow of web ap-plications, while the requirements workflow is, in the bestof cases, just tangentially tackled [9, 10]. Specially signif-icant in this sense is the lack of requirements-related con-cepts in the Common WE Metamodel recently developed asa joint effort among different European WE research groups[27, 29].

This lack of support is even more evident if we focuson non-functional requirements, that is, those traditionallyrelated to software quality. As [3] remarks, the elicitation ofquality requirements in WE is usually implicitly understoodby the stakeholders. This fact, together with a validation

Latin American Web Conference

978-0-7695-3397-1/08 $25.00 © 2008 IEEE

DOI 10.1109/LA-WEB.2008.10

75

that is harder to achieve than that of functional ones [3],is likely to lead to problems with their satisfaction on thedelivered products.

In view of this situation, and since empirical data demon-strates that efforts invested in an adequate requirementsmanagement considerably reduce drawbacks in later phasesof development and improve the productivity and qualityof the processes and software products [8], this paper pro-poses a reinforcement of WIS development support for ac-tivities related to both requirements management and re-quirements validation. In order to achieve this goal, wepresent a Requirements Metamodel extension to the Com-mon WE Metamodel (WE-RMExt). This extension aimsat increasing the importance that RE plays in WE, and itis made up of two packages that are clearly differentiated.The first package includes a set of concepts related to tradi-tional Requirements Engineering. This package, far frombeing ’yet another requirements metamodel’, syntethizesand simplifies the, from our point of view, more relevantconcepts included in well-known RE proposals. Such sim-plification was needed to avoid the burden of work usu-ally added by more exhaustive RE methodologies, on thepremises that, in the WE community, baselines must be gen-erated very quickly, and therefore straightforward ways togather requirements and connect them with validation meth-ods are needed. The second package supports the linkageof requirements with quantitative measures that contributeto the requirements validation. The concepts included inthis package are an adaptation of the well-known SoftwareMeasurement Metamodel (SMM) [11], which is based on ahomonym ontology. Although we are conscious that not allrequirements are quantifiable, both (1) recent proposals forrequirements quantification [14] and (2) the practice in theweb field (with a myriad of heuristics and guidelines, manytimes implemented in tools that automatically detect designflaws, see e.g. [34, 1]) suggest that such quantification is avaluable concept in web development, and therefore exist-ing measures/heuristics/guidelines and how they contributeto fulfill more abstract requirements should be taken intoaccount from the very beginning of the project.

The integration of our WE-RMExt –that includes mea-surement constructs– with the existing Common WE Meta-model contributes to tying up coherently requirements withconceptual design, while keeping the requirements work-flow lightweight. Furthermore the fact that our extensionexplicitly includes the concepts of goal and stakeholder (andnot only web user), in the tradition of goal-oriented ap-proaches, further contributes to bridging the gap betweenearly requirements (organizational goals) and late require-ments (system functionalities) [4]. This integration mayhelp to reduce the number of failures detected in WIS devel-opment projects, with the final aim of increasing the qualityof the WIS developed and the satisfaction of their stake-

holders.The rest of the paper is organized as follows. In Section

2 the main advantages of requirements metamodelling andan overview of the work related to this topic are provided.Section 3 describes our WE Requirements Metamodel Ex-tension (WE-RMExt). Section 4 shows a case study thatfurther illustrates our proposal. Finally, in Section 5, themain conclusions are drawn and further lines of researchare outlined.

2 Requirements metamodeling: need, advan-tages and related work

A requirements metamodel that defines in a formal waythe concepts and relationships involved in RE has been along-sought aim by both researchers and organizations inSoftware Engineering, and now also in WE. The advan-tages that a metamodel offers are numerous [20]. First, themetamodel defines both the elements that participate in therequirements management process and the relationships be-tween them in an unambiguous way. Moreover, it offersa formal basis on which tools for (1) the management ofthe metamodel elements and (2) the definition of transfor-mation rules from requirements to other elements can beconstructed [23]. Last, since most WE methodologies havealready been aligned with the MDA proposal [7, 21, 15],providing a WE Requirements Metamodel Extension (WE-RMExt) that integrates with the recently proposed CommonWE Metamodel [27] is a needed step if we aim at com-plementing the WE methodologies with requirements man-agement activities, thus emphasizing the paper that require-ments should pay in WE.

To our knowledge extent, this topic of requirementsmetamodelling in WE has only been tackled in [9, 4]. Withregard to [9], following the design-oriented approach usedby most WE approaches, the concepts that appear in thismetamodel are very near to WIS design; for instance, itincludes navigation nodes, search activities or navigationstructures as main constructs in the requirements elicitationactivities. The main problem of this lack of high-level ex-pressivity is that it is a generally avowed fact that designrequirements are difficult to understand by stakeholders notdirectly related to design. Such stakeholders require a moreabstract way to express their own requirements, that is, away that is closer to the domain under which the applica-tion is being developed.

This necessity of capturing higher-level communicationgoals and user requirements in a stable manner is remarkedin [4], where a goal-oriented approach to model web re-quirements is used. The concept of goal was defined in thei* framework [36] and it models a high-level objective ofone or more stakeholders. The concepts in the i* frame-work are very useful to model user goals, although their

76

generality suggests the necessity of tailoring them to spe-cific domains. Following this trend, [4] uses i* as basis,but specializes it to design a new requirements metamodelthat collects particular WE concepts as, for instance, a webrequirements taxonomy. This metamodel contemplates therefinement from goals through tasks through requirements,in a i*-like manner. The problem with this refinement is thatthe slight nuances in meaning between some of the conceptsinvolved require a training period that, as the same authorsoutline, should be avoided when possible in the web field,where web analysts and project stakeholders often have lit-tle or no technical background. Additionally, similarly tothe proposal from Escalona et al. [9], the proposed require-ments taxonomy is closely related to the way WE devisedthe application design at the time of the proposal, and there-fore subject to changes: for example, the recent inclusion ofbusiness process views in many WE proposals [22] immedi-ately arises the question of whether ‘process requirements’should become subtypes of the requirement concept.As a further example, with this metamodel it is very dif-ficult to specify and refine (e.g. according to the ISO 9126classification [18]) usability requirements.

With regard to requirements metamodelling not specif-ically focused on web-based systems, two proposals havebeen specially influential in our approach. The first oneis COMET [2], a requirements modelling method that in-cludes a requirement metamodel. However, this metamodeldoes not pay attention to non-functional requirements and,moreover, it does not cover any method for requirementsvalidation. The second approach we would like to stressout is REMM [33], which presents a RE metamodel that in-cludes the elements that usually appear in a requirementsmodel. However, this generic metamodel does not con-sider the possibility of capturing the aforementioned high-level communication goals, nor does it cover methods forrequirements validation. Despite this fact, the concept ofrequirements reuse presented in [33] is very useful and itcan be adapted to the WIS scope.

Summarizing, any requirements metamodel included inthe Common WE Metamodel should be independent fromparticular WE views, quality models or implementationtechnologies. Additionally, requirements concepts shouldbe related not only with goals from specific stakeholders,but also, when possible, with validation methods. Fromthem, measures that reflect guidelines and heuristics arecommonly used in web development [6], and therefore sup-port for them should be provided. Following the philoso-phy of the Common WE Metamodel as an intersection ofconcepts managed in WE methodologies, other particularaspects, such as e.g. the different techniques used by WEmethodologies to refine requirements descriptions or par-ticular validation methods have been aspects left out of ourproposal.

Next section presents the WE-RMExt.

3 The Web Engineering Requirements Meta-model Extension

The Common WE Metamodel [27, 29] is an effort toreach an agreement, inside the WE community, on the coreconcepts of the discipline. Although it is still soon to as-sess the actual impact that such metamodel is going to havein the evolution of the discipline, we believe that it pro-vides a good overview of the state of the art in WE. Aswe can observe in Figure 1, the original Common WEMetamodel consists of five packages: CoreConcepts,DataView, NavigationView, PresentationViewand BusinessProcessView, where the last four pack-ages import concepts from the first. Following this philoso-phy, our extension has been encapsulated in a new package,the MeasurableRequirementsView package. Thispackage has two subpackages: the RequirementsViewand the MeasurementView. The concepts and relation-ships involved in these two views are presented in Figure 2and Figure 4 respectively.

Figure 1. The Requirements-aware CommonWE Metamodel Structure

Let’s now dive into the concepts presented in Fig-ure 2. This Figure shows the Requirements View,which is an improved evolution of an initial contribu-tion to requirements metamodelling for WIS projects [28].The key element in this view is that of requirementwhich can be described using a set of attributes (hid-den in the Figure) such as an identifier, the typeand priority and its textual description. Inorder to avoid as much as possible the ambiguity in-herent to natural language, the description of require-ments can use terms included in a glossary. Inthe WE-RMExt, requirements can be classified as eitherfunctional requirements (what the system mustdo) and non-functional requirements (how the

77

Figure 2. The Requirements View Package

system must do it). This classification is useful be-cause, while functional requirements usually rely on testcases to be validated, non-functional requirements are re-lated to quality scenarios. More complex require-ments classifications have been avoided, as the possibilitiesare countless, and greatly depend on the preferences of thedesigner. Requirements organization into tree-like struc-tures (see e.g. quality models such as the ISO 9126 [18]),as well as relationships between functional and non func-tional requirements, can be defined in a simple manner bymeans of the unary relationship decomposedInto that isdefined over the requirement concept.

Each requirement has a set of relationships with otherelements. First, the metamodel includes the goal concept,borrowed from the goal-oriented RE, as a means to modelhigh-level objectives of one or more stakeholders. Eachgoal is related to the stakeholder (one or more) thatproposes it, and it is satisfied through the fulfilment of a setof requirements.

Figure 2 also contemplates requirement reuse by intro-ducing the catalog concept, which represents a set of re-lated requirements. In a nutshell, a catalog puts togethera set of requirements extracted from one or more sources(i.e., a law, an organization policy, a guideline, . . . ) andcan be reused in all the projects where these sources areapplicable. This concept has been applied successfully intraditional RE methods [32, 31] and its adaptation can beuseful in the context of web-based projects, where numer-ous concepts, such as standard quality models [18], webaccessibility guidelines and laws [35, 16], experts usabilityrecommendations [30], etc. must receive attention. Theserequirements sources have been formalized in our proposalusing the source element.

Figure 3 shows, in a simplified way, how theRequirementsView has been adapted as a newview of the Common Web Engineering Metamodel. Thisview reuses the concepts defined in the CoreConceptspackage, following the strategy used for the existing

Common WE Metamodel packages. In this Figure,the new CM ReqModel, which is made up of a setof CM ReqElement, extends from the CM Model,which exists in the CoreConcept package. The mainconcepts in Figure 2 (Goal, Requirement,...)extend the CM ReqUnit concept, while the new re-lationships (satisfiedBy, measuredThrough,validatedThrough,...) are CM ReqAssoc thatdirectly extend from the CM Relationship coreconcept. For space constraints, some elements of theRequirementsView have been omitted of Figure3. Interested readers in the whole structure of theCoreConcept package and how the other packagesextend it are referred to [27].

Figure 3. Common Metamodel Extensionfrom the Requirements View

As mentioned previously, the RequirementsViewprovides the requirements that can be validated through theuse of measures. The definition of these measures is sup-ported in the MeasurementView (see Figure 1) follow-ing an extension philosophy similar to the one presentedwith the RequirementsView.

The MeasurementView presented in Figure 4 sup-ports the ‘quantifiable requirement’ concept [3]. Quantifi-able requirements are regarded as the ideal form of require-ment, as they can be assessed objectively. As the readermay already have inferred, quantification can be achievedthrough the definition of measures [14]. The idea of defin-ing measures together with requirements, far from beinganew, is a practice that, included in many software devel-opment processes (see e.g. [25]), has proved to contributeto the success of projects. The MeasurementView pre-sented in Figure 4 is in fact a simplified adaptation of the‘software measurement metamodel’ (SMM) [11], whichhas been used with success in model driven approaches forthe automation of the measurement process [5]. During thissimplification, some adjustments to the original SMM havebeen carried out. Some of the concepts in SMM were de-fined at different levels of abstraction, not suitable for ourpurpose. Others simply overlapped with the concepts gath-

78

ered in the Requirements View. More precisely:

• The SMM includes Measurable Conceptsthat make up a Quality Model. In theMeasurableRequirementView this conceptis equivalent to that of Requirement, which can beextracted from a given Source. Therefore, we have leftout of our approach both SMM concepts.

• Due to its ontology-based inception, the SMM in-cludes a number of concepts that refer to concrete ar-tifacts or activities such as Entity (concrete artifact onwhich the measure is being applied) or Measurement(the action of applying a measure on a given entity).Given the fact that our approach is aimed at definingrequirements and associated measures (and not tracingactual measurements or artifacts), these concepts havebeen left out of our approach.

• The Measurement Result, on the other hand, althoughalso concrete in nature, is a useful modelling element,as it represents the input received by other conceptssuch as Decision Criteria. In our approach this concepthas been directly linked with the Measure concept.

• Indicators in the SMM are related to an InformationNeed concept, generally defined as “insight necessaryto manage objectives, goals, risks, and problems” [11].However this definition suggests much more than amere textual description: goals, risks, quality scenar-ios, etc. have constituted the traditional scope of REmetamodels. Therefore in our approach the wholeRequirementsView plays the role of the SMM In-formation Need concept.

Figure 4. The Measurement View Package

The way in which the MeasurementView has beenredefined as a new package of the Common WE Engineer-ing Metamodel is similar to that presented in Figure 3: anew CM MeasModel has been defined and the different

CM MeasElement and CM MeasAssoc have been estab-lished. Due to space constraints further details have beenomitted.

Back to Figures 2 and 4 we can observe howthe MeasurementView imports the Require-mentsView::Validation Method metaclass in order toestablish the traceability between requirements and themeasures that help to validate them. We would like tonote that, although ideally all requirements should bemeasurable, in practice time and cost constraints makethis alternative inviable [14]. For this reason, our proposalpermits the definition of requirements that are not linked toany measure, in the thought that, in order not to overburdenthe modelling process, only measures that are actuallybeing carried out during the testing workflow should bemodelled [25].

It is also important to note how theMeasurableRequirementsView supersedes notonly traditional requirements metamodels, which now candefine measurable requirements, but also the SMM itselfwhich, with the linking to RE concepts, can now soundlyexpress not only the measure but also the context andpurpose of the measure in a much more systematic way.In the MeasurableRequirementsView this contextnot only involves specific goals or specific requirements,but also specific quality scenarios with specific conditionsunder which the measures are to be applied. All thisinformation is of paramount importance for the definitionof measures, as they affect the acceptability of the measureresult. For example, it is different to apply a performancemeasure with a system load of 10 simultaneous users(quality scenario 1) than to apply the same measure with5000 simultaneous users (quality scenario 2).

In order to illustrates how the proposed approach can beused for the elicitation and measurement of requirements,next we present a case study.

4 Modeling Example

The chosen case study corresponds to a simplified on-line ticket sale system. First, a description about the instan-tiation of the requirements view is shown. Next, how therequirements are linked with measures that can be appliedover the models in the context of WE methodologies, suchas navigational models, is also detailed.

4.1 Case Study Description

For the sake of simplicity, let’s assume that the salesmanager of a certain cinema chain wants to increase thesales profit of the company. With this aim, let’s also sup-pose that this goal can be achieved through two differentsub-goals. On one hand the company wants to increase the

79

sales net profit by implementing a web-based on-line ticketsale system that decreases the costs associated with the salesprocess. On the other hand, the company also wants toincrease the number of sales by reaching a broader rangeof customers. The sales manager believes that offering thetickets through Internet may positively influence both sub-goals, so s/he has embarked into a web ticket sales systemdevelopment process.

As for the web customer that is going to interact withthe application, s/he has as the main functional requirementthat of buy ticket. This requirement can be decomposedinto two functional requirements: browse available filmsand purchase ticket. In addition, several non-functional re-quirements that the web based system must fulfil have beenidentified. Firstly, the buy ticket functionality should fol-low accessibility guidelines to allow web customers withdisabilities to access the system. Additionally, the sys-tem should provide information accuracy while browsingthrough the available films: synopsis, sessions, prices andso forth should be reliable. Also, the application learnabil-ity should be high, that is, the application should be simpleenough for novel users to easily learn its operation. Last, thepurchase process should be performed assuring the securityof the customer data.

4.2 Instantiating the Extended WE Meta-model

If we first check the involved RequirementsViewmetaclasses (see Figure 2), we can observe how (i) the salesmanager and web customer both instantiate the Stakeholdermetaclass, (ii) all goals related to increasing sales profit in-stantiate the Goal metaclass, (iii) buy tickets, browse avail-able films, purchase tickets are all Functional Requirementoccurrences and (iv) accessibility, learnability, security andinformation accuracy are all Non Functional Requirementinstances (see Figure 5). With the systematic identificationof these requirements, web modelers have at their disposala good baseline to start the WIS modelling.

These identified requirements drive the design WE mod-els, such as content, navigation or presentation models. Ad-ditionally, through the definition of suitable measures, it ispossible to define measures to validate those requirementsover any of the WE models. Let’s show how this valida-tion can be established through the learnability with whichthe web customer is able to browse the films we are offer-ing on our site. For this purpose, let’s turn this requirementinto a measurable requirement. Let’s suppose that we havedefined a quality scenario – instantiated from the QualityScenario metaclass (see Figure 2) – that states that it is nec-essary to check whether a novel user is able to find the links/he expected to find based on her mental domain model.

If we now check the Figure 4, we can observe how re-

quirements and measures are connected by defining an In-dicator occurrence, that we have named ‘navigability level’.Indicators are made up of measures. In our example, let’simagine there is a single Derived Measure instance that con-tributes to the indicator, which is called ‘domain coveragenavigation measure’ (DCNM). This measure is based ontwo Base Measure occurrences: the ‘number of relevant re-lationships’ (NRR) and the ‘number of navigated domainrelationships’ (NNDR). Briefly speaking, the DCNM cal-culates how many of the domain relationships that may berelevant for fulfilling the requirement are actually naviga-tion links available through the application interface. Let’salso assume that, in this context, the Decision Criteria andthe Analysis Model associated with the indicator establishthat a DCNM > 0.80 makes the web design acceptable withrespect to its learnability. Assuming that the system is be-ing deployed with a WE proposal such as OO-H [15], thismeasure can be calculated early in the lifecycle, based onthe Entity Class ‘web conceptual model’ (an abstract modelthat represents an entire web application). This concept cor-responds with the CM Model metaclass, contained in theCoreConcepts package (see Figure 1). More particu-larly, the NRR is calculated over the ‘domain model’ En-tity Class, which is an extension of the same CM Modelmetaclass that is contained in the DomainModel package,while the NNDR is calculated over the ‘navigational model’Entity Class, which is also an extension of the same meta-class, but this time contained in the NavigationModelpackage. Both measures are related to the structural com-plexity Attribute of the models associated. The Measure-ment Function that serves to calculate the DCNM uses thetwo Base Measures in order to calculate the MeasurementResults. The higher this value is, the more domain relation-ships are covered in the application interface by means oflinks (see Figure 5). For simplicity reasons, some measure-ment concepts (presented in Figure 4) have been left out ofthis instantiation.

We would like to stress out the fact that the explicit con-nection provided by the WE-RMExt between measures andrequirements not only fosters the definition of measurablerequirements, but also is the basis on which it is possibleto automatically assess requirements. In [5] it was shownhow this automation of the validation process was possiblein the context of an MDD development process, which istypical of WE. For space reasons, readers interested in thisautomation, or in a more detailed explanation of the ratio-nale behind the defined measure, are referred to [5].

5 Conclusions and Further Work

The adequate management of requirements is a key fac-tor to guarantee stakeholders satisfaction. In this manage-ment process, the definition of measures that are associated

80

Figure 5. Instantiation of the proposal for the Online Ticket Sale System

with these requirements may help in the automation of thesystem validation. However, neither organizations propri-etary development processes nor WE methodologies haveso far succeeded in tackling this issue. This paper tries to fillthis gap proposing an extension of the Common WE Meta-model that is made up of a RequirementsView, whichgathers a simplified concepts structure to manage goal-based requirements, and a MeasurementView, whichsupports the concept of measurable requirements. TheRequirementsView can help stakeholders in the elici-tation and management of the project requirements. More-over, with its integration with the MeasurementView, itis possible to trace measures to the requirements that orig-inated them, and to apply measures over the artifacts in-volved in WE development processes. Figure 6 sketchesthe elements that participate in the proposed approach overthe case study presented in Section 4.

However, we are conscious that this is just a first step.As further work, an empirical evaluation of the suitabilityof our extension for the requirement elicitation in practicemust be carried out. Additionally, transformations to andfrom these WE-RMExt to particular approaches to deal withrequirements in the different WE methodologies must beprovided. Last but not least, due to the low scalability ofobject models (illustrated in the complexity of Figure 5 de-spite the simplicity of the case study) we are working onthe provision of a more suitable notation for the definitionof measurable requirements models.

Figure 6. Reinforcing RE practices with theMeasurable Requirements View

6 Acknowledgements

Partially supported by the projects DEDALO (TIN2006-15175-C05-03) and ESPIA (TIN2007-67078), from theSpanish Ministry of Science and Technology, QUASI-MODO (PAC08-0157-0668) and MELISA-GREIS(PAC08-0142-335). Fernando Molina is funded by theFundacion Seneca (Region de Murcia) under an FPI grantand Jesus Pardillo is funded by the Spanish Ministry ofEducation and Science under FPU grant AP2006-00332.

81

References

[1] J. Abascal, M. Arrue, N. Garay, and J. Toms. Evaliris: Aweb service for web accessibility evaluation. 12th Interna-tional WWW Conference, Budapest, Hungary, 2003.

[2] A. J. Berre. Comet (component and model based develop-ment methodology). http://modelbased.net/comet/, 2006.

[3] J. D. Blaine and J. Cleland-Huang. Software quality require-ments: How to balance competing priorities. IEEE Software,pages 22–24, 2008.

[4] D. Bolchini and P. Paolini. Goal-driven requirements anal-ysis for hypermedia-intensive web applications. Require-ments Engineering Journal, 9(2):85–103, 2004.

[5] C. Cachero, S. Melia, M. Genero, G. Poels, and C. Calero.Towards improving the navigability of web applications: amodel-driven approach. European Journal of InformationSystems, 16:420–447, 2007.

[6] C. Calero, J. Ruiz, and M. Piattini. A web metrics surveyusing wqm. In ICWE, pages 147–160, 2004.

[7] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai,and M. Matera. Designing Data-Intensive Web Applica-tions. Morgan Kaufmann Publishers Inc., San Francisco,CA, USA, 2002.

[8] D. Damian and J. Chisan. An empirical study of the com-plex relationships between requirements engineering pro-cesses and other processes that lead to payoffs in produc-tivity, quality, and risk management. IEEE Trans. SoftwareEng., 32(7):433–453, 2006.

[9] M. J. Escalona and G. Aragon. Ndt. a model-driven ap-proach for web requirements. IEEE Trans. Software Eng.,34(3):377–390, 2008.

[10] M. J. Escalona and N. Koch. Requirements engineering forweb applications: A comparative study. Journal of Web En-gineering, N 3:193–212, 2004.

[11] F. Garcıa, M. F. Bertoa, C. Calero, A. Vallecillo, F. Ruiz,M. Piattini, and M. Genero. Towards a consistent termi-nology for software measurement. Information & SoftwareTechnology, 48(8):631–644, 2006.

[12] A. Ginige. Web engineering: Managing the complexity ofweb systems development. 14th Int. Conference on SoftwareEngineering and Knowledge Engineering, July 2002.

[13] R. L. Glass. Software Engineering: Facts and Fallacies.Addison-Wesley, 2002.

[14] M. Glinz. A risk-based, value-oriented approach to qualityrequirements. IEEE Software, pages 34–41, 2008.

[15] J. Gomez and C. Cachero. OO-H: Extending UML to ModelWeb Interfaces. Information Modelling for Internet Appli-cations. IDEA Group Publishing, 2002.

[16] U. Government. Section 508: The road to accessibility.http://www.section508.gov/, 2007.

[17] T. Group. The chaos report.http://www.standishgroup.com/, 2002.

[18] I.S.O. Iso/iec 9126-1. software engineering-product quality- part 1: Quality model. 2000.

[19] G. Kappel, E. Michlmayr, B. Proll, S. Reich, and W. Rets-chitzegger. Web engineering - old wine in new bottles? InICWE, pages 6–12, 2004.

[20] A. G. Kleppe, J. Warmer, and W. Bast. MDA Explained:The Model Driven Architecture: Practice and Promise.Addison-Wesley Longman Publishing Co., Inc., 2003.

[21] N. Koch and A. Kraus. The expressive power of uml-basedweb engineering. 2nd Int. Worskhop on Web-oriented Soft-ware Technology (IWWOST), 2002.

[22] N. Koch, A. Kraus, C. Cachero, and S. Melia. Integrationof business processes in web application models. Journal ofWeb Engineering, 3(1):22–49, 2004.

[23] N. Koch, G. Zhang, and M. J. E. Cuaresma. Model transfor-mations from requirements to web system design. In ICWE,pages 281–288, 2006.

[24] M. Lang and B. Fitzgerald. Web-based systems design: astudy of contemporary practices and an explanatory frame-work based on method-in-action. Requirements EngineeringJournal, 12(4):203–220, 2007.

[25] C. Larman. Applying UML and Patterns. 2005.[26] D. Lowe. Web system requirements: an overview. Require-

ments Engineering Journal, 8(2):102–113, 2003.[27] MDWEnet-Initiative. Web Engineering Metamodel.

http://www.pst.ifi.lmu.de/projekte/mdwenet/index, 2008.[28] F. Molina, J. Pardillo, and A. Toval. Modelling Web-based

Systems Requirements using WRM. In WISE Workshops.LNCS 5176, pages 122–131, 2008.

[29] N. Moreno and A. Vallecillo. Towards interoperable web en-gineering methods. Journal of the American Society for In-formation Science and Technology, 59(7):1073–1092, 2008.

[30] J. Nielsen. Designing Web Usability: The practice of Sim-plicity. New Riders Publishing, 2000.

[31] A. Toval and et al. Eight key issues for an effective reuse. In-ternational Journal of Computer Systems Science. Acceptedfor publication, 2007.

[32] A. Toval, J. Nicolas, B. Moros, and F. Garcıa. Require-ments Reuse for Improving Information System Security: Apracticioner’s Approach. Requirements Engineering Jour-nal, Springer Vol 6(4):205–219, 2002.

[33] C. Vicente-Chicote, B. Moros, and A. Toval. Remm-studio: an integrated model-driven environment for require-ments specification, validation and formatting. Journal ofObject Technology, Special Issue TOOLS EUROPE 2007,6(9):437–454, 2007.

[34] W. W. W. C. (W3C). Techniques for accessibility evaluationand repair tools. http://www.w3.org/tr/aert.

[35] W. W. W. C. (W3C). Web accessibility initiative (wai),http://www.w3.org/ wai/.

[36] E. S. Yu. Modeling organizations for information sys-tems requirements engineering. In Proc. 1st IEEE Interna-tional Symposium on Requirements Engineering, pages 34–41, 1993.

82