theimpactsofnon-functional requirements inweb …€¦ · european and mediterranean conference on...

European and Mediterranean Conference on Information.Systems (EMCIS) 2006,

July 6-7 2006. Oosta Blanca, Alicante, Spain

THE IMPACTS OF NON-FUNCTIONAL REQUIREMENTS IN WEBSYSTEM PROJECTS

Norazlin Yusop, University of Technology Sydney, New South Wales, [email protected]

Didar Zowghi University of Technology Sydney, New South Wales, [email protected]

David Lowe, University of Technology Sydney, New South Wales, [email protected]

Abstract

In Web system development, the non-functional requirements (NFRs) are typically considered onlybriefly during the requirements elicitation stage and not rigorously articulated by either Web developersor the client. This paper reports on an investigation into this issue involving interviews with Webdevelopers who were engagetHn commercial Web development projects. The results from this qualitativeresearch highlight that Web developers commonly do not pay sufficient attention to NFRs. This arisesdue to uncertainty, lack of time, lack of knowledge in the importance of NFRs and partly because NFRsare not readily available and documented from previous similar projects. Web developers also do notelicit NFR at the same time and at the same level of details as functional requirements (FRs). This studyhighlights that a lack of rigor in articulating NFRs may significantly impact on the developmenteffectiveness and the quality of the resulting Web system.

Keywords: Web system projects, Nonfunctional requirements, Impacts, Security, Integration

1 INTRODUCTION

In order to achieve a better understanding of Web systems development, we need to urtderstandtheunique characteristics of Web systems Iand how these characteristics impact on the development process.The unique characteristics of Web systems are both technical and organisational in nature. The morefundamental of these relate to the way in whch Web systems are inter-dependant with the organisationalprocesses and contexts within which they exist. Whilst not unique to Web systems, they are typicallyheightened in Web systems (Burdman, 1999). Three of the key characteristics are: (1) uncertainty in theproject domain; (2) high volatility of the client needs; and (3) rapidly changing technology.Technological changes and frequent communication between clients and developers impact on thestability of the project requirements, thus making the requirements more volatile (Zowghi et al, 2000).

Like any system, in order for a Web system to be successful, it is critical that the Web system meetsfunctional and non-functional requirements. Non-functional aspects such as security, privacy, integrationand system performance are crucial to the development of high-quality Web systems (Kirner and Davis,1996, Mylopolous et al, 1992). Web development typically tends to focus primarily on the FRs as Webdevelopers are more inclined to scope a project through an understanding (and representation) of the

I Whilst we use the term "Web system" throughout this paper, we recognise that this terminology is still somewhat ill-defined wit bin theliterature (which includes terms such as Web applications, Web-based systems, online systems, as well as a host of domain specific terms such asB2B, B2C, e-commerce systems, etc.). In this paper when we use the term "Web system" we are referring to those systems which utilise Webtechnologies as an integral element of a functionally complex system and which typically incorporates interfaces beyond the organisationalboundaries.

1Yusopetal

The Impacts of Non-Functional Requirements in Web System Projects

mailto:[email protected]



European and Mediterranean Conference on Information Systems (EMCIS) 2006,

July 6-7 2006, Costa Blanca, Alicante, Spain

functional aspects of the Web system. NFRs have to be handled and expressed very early in the processof development (Cysneiros, 2001)

This paper represents a preliminary stage of a long term research project which overall objective is tounderstand and improve Web development processes. At this stage we report on interviews with Webdevelopers. Our data has led us to investigate the importance and impacts of NFRs on Web developmentprojects. We will report on key lessons with regard to how NFRs should be handled. In subsequent workwe will use these lessons to propose a methodology for guiding the most appropriate derivation ofNFRs.This methodology will help analysts to rigorously derive and validate the NFRs.

2 RELATED WORK: REQUIREMENTS FOR WEB SYSTEMS

Although there is a significant body of research on requirements management and requirementsengineering techniques, little of this has been related directly to the specific consideration ofrequirements in Web projects (Lowe, 2003). Zowghi and Gervasi (2001) state that unlike conventionaldevelopment, Web-based system development typically does not differentiate between requirementselicitation and analysis, and system design. Web developers use the early stages of design to elicit moredetailed feedback from clients about the requirements of the system.

In Web systems development, it appears that Web developers are more concerned with functional aspectsof the systems, such as user interfaces, the navigability of the pages, "add-on" to database design, thelayout and structure of the pages and the various functionalities that the Web systems need to provide(Atzeni et al, 1998, Baresi et al, 2000, Bonifati et al, 2000 and Rossi et al, 1999). These functionalaspects are often articulated as FRs, based on previous experience in handling similar projects within thesame domain, and also by learning from the competitors. NFRs, on the other hand, do not express anyfunctionality to be implemented in the future system directly (Cysneiros et al, 2001). To the contrary,they express behavioral conditions and constraints that must exist in systems development and operation.

Although, NFRs such as security, data and system integration, and system performance are crucial to thedevelopment of Web systems, it seems that they are not given the same emphasis as FRs. The difficultywith articulating NFRs for Web system projects lies in identifying and predicting possible causes andimpacts that NFRs have on the system and its domain. This is partially due to the uncertainty when theWeb developer does not understand the domain completely before building the Web system, leadingorganisations to make decisions without complete information.

3 NFR IMPACTS IN WEB SYSTEMS PROJECTS

One of the difficulties with articulating NFRs for Web systems projects lies in identifying and predictingpossible causes and impacts that NFRs have on the Web system and its domain. Web systems tend tofundamentally alter the interface andlor relationship with extemal stakeholders, thus having a moresubstantial and immediate impact on the problem domain (Yusop et al 2004). The functional and non-functional aspects that such systems could or should provide tend to impact highly upon theorganisational context, deeply affecting the operational processes, organisational structure, and theworking habits of the individual employee, at each organisational level (Donzelli and Setola, 2002).

With new technology such as Web systems, new forms of threats are encountered regularly. These threatsinclude security threats such as illegal access to proprietary data, virus attacks, denial of service attacks,and illegal acquisition or distribution of data that is copyrighted. Security has the potential to have a highimpact on the organisation and its systems as there is no security technology that can secure the systemcompletely (Medjahed et al, 2003 and Yang and Papazoglou, 2000). Security plays a great role as itinvolves various technologies and since the system is available on the Web, it is more exposed to securitythreats. Another vital NFR for Web system is systems integration. Organisations need to ensure thatdifferent Web applications and tools are able to integrate searnlessly with the organisation's existingsystem and the systems of its trading partners. Poor integration of the Web applications and tools leads tonegative impact for both the organisation and the system (Bohner, 2002 and Medjahed et al, 2003).

2Yusopetal




4 RESEARCH METHODOLOGY

This section covers five interviews of Web developers in Singapore about the Web system projects thatthey have recently developed. The objective of the interviews was directed towards exploring in whatway the domain knowledge was elicited and identifying how this process informed the Web developerabout constructing the domain model. The numbers of Web developers may be considered as a smallsample size. However, the Web systems that they developed are complex in nature and involved NFRissues that are critical and worth reporting. These interviews were an initial step of the research as itgathered some preliminary findings which are pertinent to the study. This is important as it serves as abasic groundwork for a more thorough search of empirical evidence in the next step of the research.

This is qualitative research in which a set of open-ended questions were used. The Web developers wereto answer the questions in reference to a particular recent Web system project. Each interview tookapproximately two hours to complete. All responses and comments were written on the questionnaireitself and queries via electronic mail were used to further clarify missing or ambiguous responses.

The five Web developers were interviewed on separate occasions at their respective workplaces. Thequestions that were asked related to: (I) the kinds of questions the Web developers asked their client/usergroups; (2) the types of issues they discovered during development; (3) the challenges that they face; (4)the solutions that they attempt; and (5) the level and nature of communications that they have with theclient/user groups. During the interviews, more questions emerged as the Web developers gave candidresponses, which were not part of the questions listed in the questionnaire. These responses are veryvaluable as they illuminated Web development and project issues that were previously not anticipated.

Content analysis was used as the research method for making valid inferences from the Web developers'responses during the informal interviews (Michael and Lewis, 1994). The primary aim was to determinein what way the domain knowledge is elicited, the issues in NFR those are identified during this process,and in what way these issues are significant to the Web project.

5 RESULTS AND ANALYSIS OF INTERVIEWS

Table 1 below illustrates the description of Web projects. The company names do not reflect actualnames so as to maintain anonymity of the organisations. In the following sub-sections, the Web projectsare analysed and discussed in terms of the way the Web developers elicited the systems requirements, thetypes of requirements they gathered, and finally the importance ofNFRs in these Web projects.

Alpha Life Insurance (ALI) Development cf an intranet (E-Staff) and exranet system (E-Cargo). The Bcargosystem needs to be connected to EStaff. The Bcargo system is for shippingcompanies to buy insurance for their cargo. ALI's staff needs to access both systemsto process documents and manage various operations.

Beta Real Estate Agency (BREA) Development of a fully function Website for a real estate company to promote theproperty sales and rental uptake.

Charlie Tour and Travels (CTT) Development of online travel website, mainly focusing on the front-end providinginformation to prospective customers

Delta Land Valuers Institute (DLVI) Reconstruction of current Website to automate workflow processes using a Web-basedapplication system.

Echo Telecommunications (ET) Development of an online ordering system for vendors to query and submittelecommunication goods orders

Tablel. Description of Web Projects

During the interviews, the developers discussed many issues relating to non-functional aspects. This wasactually not the main focus of the study; however it became clear during the interviews that NFRs playapivotal role in Web projects. Some of the developers were interviewed for the second time to providemore detailed responses from the first infonna1 interview. These projects contain several issues thathighlight the criticality ofNFRs in Web projects. Interestingly, this is in contrast to most of the existing

3Yusop eta!




literature discussing Web systems development, which focuses on the FRs and the ir importance indetermining the success of the Web systems.

5.1 Requirements elicitation and types of requirements gathered

In eliciting requirements, the Web developers used various methods which mostly were informal andtook several rounds of consultations with the clients/users. The common communication method was tointerview the relevant personnel, which was then followed by questions via email or telephone. The typesof questions posed to the client/users related to the functional and non-functional aspects of the systems.The Web developers were initially given a project brief, which contained basic descriptions about thefunctions, the budget and schedule with which the Web project needed to comply. NFRs were not~~cifie~by the client nor elicited in detail by the Web developer during the initial stage of the projects.The Web developers faced challenges in obtaining information from the clients due to the inherentuncertainty and lack of development knowledge and experiences.

The Web developer for project BREA indicated that the client initially provided him with only a two-page project description, stating the basic functionality that the systems must support. In addition to aproject description, the Web developer for the CTT project also asked about the business operations andhow the client's organisation performed their work processes with the vendors. The focus during theelicitation sessions were mostly geared towards finding functional aspects for the system. For DLVI, theWeb developer commented that though functional aspects of the system were clarified, the NFR aspectsremain unclear. The Web developer contacted the client to clarify NFR issues:

"... we asked questions about security and integration issues. The Web system should alsoprovide access control and security for all levels and integrate applications withAccounting system. We had long hours of meetings with clients after the Website is createdto discuss about linking the Webpages with the backend systems in detail"

The Web developer was able to gather such requirements after several rounds of discussions with theclient. These NFR issues were not clear from the beginning as both the Web developer and the clientwere uncertain about the systems' behavioural conditions and constraints

5.2 NFRs and their importance to Web projects

It was observed that the Web developers were not aware that the issues they had were in fact problemsrelating to NFRs' Only ALI project clearly identified the issues as aspects of NFRs. The clientsparticularly were more interested in functional aspects of the project. Non-functional issues such assecurity, system performance, data integration, data confidentiality, and privacy were not discussed indetail. The Web developers discovered that such NFRs became issues that impacted on their Websystems projects only at the later stages of the Web development. As a result, the system design waschanged frequently. These changes complicated the Web projects as in most of these projects a properdocument was not developed or maintained to record such problems and rectifications.

5.3 Alpha Life Insurance (ALI).

We describe here the interviews conducted with respect to the ALI project. This project is explained ingreater detail due to the richness and pertinency of information provided by the Web developer as ithighlights several NFR issues that are critical to the development of Web systems. Due to spacelimitation in this paper, it allows for only one project to be discussed in detail. This Web project involvedthe development of a local staff intranet site, referred to as E-Staff, and also an electronic cargo (E-cargo)extranet site where vendors can log in and enquire about and purchase cargo insurance.

Web Development Team Structure: The Web Development team was led by a Project Manager whocoordinated the development team, which consisted of a Web developer, a Business Analyst and an ITManager. The Users Group comprised various departments who provided the requirements when

4Yusopetal


European and Mediterranean Conference on Infonnation Systems (EMCIS) 2006,


contacted by their Business Analyst. The Business Analyst for the Web development team was in chargeof eliciting requirements for the Web developer. The Web developer's responsibility involved thedesigning of the Website and the overall completion of the system.

During the initial stage of the development, jroblems regarding issues not foreseen before also surfaced.Issues such as security, integration of data between departments, sensitive data that required accesscontrol and systems integration and interoperability issues became prominent. The Business Analystswere unable to resolve the issues in a timely manner as they were unaware of the complexity of theproblems. The Web developer therefore assigned an IT Manager to compile more detailed NFRs for theproject and to include them in the project document. The NFRs were re-written and involved manydiscussions with the Users Group's Business Analyst. The Web developer stated the following:

"There was one team member, the IT Manager who will specifically deal with allthe NFRs and prepare the specification documentfor this project. "

In order to have a more complete understanding of the business domain, the Web developer asked theBusiness Analyst for information relating to user requirements, functions and the kinds of businessprocesses the departments deal with. By discussing with other departments, who were direct users of thesystem, the IT Manager discovered new NFR-related issues not discussed before.

Non-Functional Requirement Impacts: There were several NFRs that impacted on ALI's project.These NFRs (relating to the security aspects of the system, data integration issues and the requirementsfor backing up of the data) only became critical at the end of the first phase of the project As shown inFigure 1, both systems (E-Staff and B-Cargo) needed to be integrated, where the staff from relevantdepartments would be able to access the e-cargo site and perform duties such as providing quotations,promoting insurance packages and managing payment related matters. The kind of functions that the B-Staff system needed to support were for staff to access and update staff details and submission ofdifferent forms such as course registration forms, course evaluation forms, leave forms, etc. Figure 1 alsoshows five types ofNFR impacts in this project:

IIII1IIII___I

Handles DIlW bUsinessdevlJlopment, fiMnl»,ouatomer ftl'¥lco.;.;:,:;:c.:;eto;.;:;,.-'----b;

8endedlt8todepanment

E'xtractI data fromOracle to AS400IBM MalnhIM

Figure 1. Alpha Life InsuranceWeb System Structure

NFR Impact 1: The systemssecurity and data safety areimpacted This was a high levelimpact as information such asstaff details; staff training andsalary were private. The Webdeveloper had to ensure thatappropriate access control wasbeing enforced. The workprocesses also involved privatedata that required restrictiveaccess.

NFR Impact 2: The timing andspeed aspects of the system.wereimpacted. The Web developer

was concemed with streamlining the work processes and business operations that were previously donewithin the information system of the Website. The integration of the current system to the Web systemhad to be seamless and should not affect the speed of the system. This was because in certain parts of theday, the traffic to such sites would be higher as it was accessed by many personnel. The Web developeralso had to ensure that all data was properly backed up so that no data would be lost if the network fail.

NFR Impact 3: Security and safety related aspects of the system impacted this part of the project. Thesystem stored information such as customer's details and details of policy coverage. This was

'"'\,:"1,j'"

Yusop et al


5



confidential and each corporate policy holder was given a unique directory where only the corporatepolicy,holder and the person they liaised within ALI could have access. As this system facilitated on-linepayments and digital signatures, proper security tools were used. This requirement was not previouslyhighlighted during the requirements elicitation sessions. The IT Manager in charge of documenting theNFRs conducted a separate meeting with the User Group to discuss details of these NFRs.

NFR Impact 4: The NFR that impacted on the Web system here was interoperability, whereby bothsystems (Oracle Database and AS400 ffiM mainframe systems) needed to interoperate seamlessly andeffectively. Information displayed in the EStaff and Bcargo system was being stored in an OracleDatabase. Whenever needed to meet the work processes and business operations, the data from theOracle database was being extracted to the AS400 ffiM mainframe system. The technical expertiserequited' at this stage was underestimated. The Project Manager, IT Manager and the Web developer hadto have numerous meetings to structure the technical infrastructure of the ALI's overall system.

NFR Impact 5: In transferring the data from the AS400 mainframe to the E-StaffWeb system, the Webdeveloper faced system performance issues which required elaboration, particularly as it related to thedata back-up issues. The departments required the data to be backed up at certain times of the day andclients needed to receive the data at specific times. These types of constraints impacted on the Websystem and such additional requirements led to numerous discussions that delayed the project completion.

6 LESSONSAND IMPLICATIONS

From the analysis of the data, we conclude that it is critical for Web developers to articulate all aspects ofNFRs. We observed that NFRs were usually articulated in certain amounts of detail only after the Webproject had commenced. The Web developers in these projects focused more on the functional aspects ofthe system. However, it did not imply that NFRs were less important at the initial stages of Web projects.Based on the results from the analysis of the interviews; the following lessons leamed are presented:

6.1 Emphasising the importance of NFRs

Paying due attention to NFRs in a timely manner improves the resulting Web systems. It also has thepotential to reduce the development time while utilizing the involved personnel's expertise to the fullest.In the projects reported, the Web developers documented the requirements but only to a limited level ofdetail. However, functional issues such processing online jayments and updating users' personal dataposed significant constraints to the project. It is therefore imperative that both the Web developers andthe client are fully aware of the importance ofNFRs at the beginning of the project.

Web developers need to update the documents after each discussion they had with the client/systemusers. Updating the document regularly was however not a common practice with these projects. Forexample in the ALI project, the chaotic communication between the Web development team and theUsers Group led to poor documentation and follow up on the outcomes of NFR discussions. TheDevelopment team was unable to refer to the project specifications document for updated NFRs. Properdocumentation of both NFRs and FRs is vital as this facilitate requirements traceability.

6.2 Good understanding of the domain

Before eliciting requirements, Web developers need to have a good understanding of the domain.Organisations (clients) on the other hand, need to have a good knowledge of their internal and externalenvironment. This refers to understanding the environment where the Web system is being developed. InBREA, and DLVI project, the Web developers worked for Web consultancy companies and wereunaware of the client organisation's business processes and operations. As the projects involvedreconstruction of the companies' Websites and migrating the employees' data to Web systems, the Webdeveloper needed to understand the client's internal and external environment. This was a difficult task inboth projects as only by having good understanding of the domain, can the NFR issues become more

6Yusopetal


European and Mediterranean Conference on Infonnation Systems (EMCIS) 2006,


obvious. In these projects NFR issues such as privacy, safety, systems integration and interoperabilitywere paramount and the Web developers were able to articulate these NFRs only after they understoodthe organisation's structure, business process and business operations.

6.3 Lack of rigor in articulating NFRs

Web developers need to elicit and understand the Web system's NFRs before the project commences. Asdiscussed in Section 5, in all the projects, the Web developers experienced great difficulty in gathering acomplete set of NFRs in the initial stage, particularly as the clients/users themselves were uncertain aboutthe potential constraints that the Web system might have. The Web developers had to rely on previousexperience in developing similar systems, albeit only a limited knowledge.

It is pertinent that Web developers have a structured way to define the generic NFRs and predict thepotential impacts that NFRs will have over the system and its domain. As the Web project progresses,more issues involving NFRs emerge. These new issues are important sources of knowledge that need tobe documented to facilitate issues traceability when developing Web systems. From the interviews, wediscovered that NFR-related impacted on the Web project, the Web system and its domain. The difficultyin documenting and following up on NFRs is due to the complex nature of the impacts

6.4 NFRs leading to discovering new FRs

Further articulation and identification of NFRs le ads to the discovery of new FRs. In one of the Webprojects discussed, the system users were concerned with NFR issues such as usability and applicationintegration. These issues were then resolved and taken into account, leading to more specific descriptionsand elaborations of the systems functionality. This subsequently helped in improving the functionalityand the design of the Web system. This made the documentation of the systems requirements morecomplete, which allowed the reusability of such knowledge in subsequent Web projects.

7 FUTURE WORK AND CONCLUSIONS

Ongoing work will attempt to address more specific Web development project issues relating to theimportance of NFRs. Given that NFRs are not easily identified, elicited or documented in Web projects,clearly, automated tools that could support this process would be beneficial. In particular, tools thatfacilitate tracking NFR issues and allow impacts to be recorded and articulated could be very useful inWeb systems development. Such automated tool will enable the tracking and resolution of NFRs issues,particularly in guiding developers in resolving issues in a systematic way.

During the interviews, the Web developers gave insightful descriptions of the ir experience in developing.the Web systems. Their experiences included highlighting some of the NFR issues. Although some ofthese NFR issues were commonly known, their impacts and implications were not. These impacts andimplications were therefore explored and evaluated. This is critical to Web systems development as thesystem is usually developed in shorter time frames and its development is usually ad hoc. In such asituation, having the ability to identify, understand and analyse NFR issues is critical in successfulimplementation of Web systems.

In this paper, we argued that it is a complex task to develop Web systems when the FRs and NFRs are notwell understood. This is made more difficult when new requirements are continually dis~overed andimplemented. The results from this study highlight that Web developers typically do nofpay sufficientattention to NFRs' This is often due to uncertainty, lack of time, lack of knowledge in the importance ofNFRs, and that NFRs are not readily available and documented from previous projects for the purpose ofreuse. The NFR impacts discussed here are indicators that should be taken as warning signs early in therequirements gathering and system analysis phase to alert practitioners regarding their developmentprocess and methodology. The data further showed that Web developers do not elicit NFRs at the sametime and at the same level as FRs. Hence, there needs to be a systematic and structured way ofdocumenting the NFRs.

7Yusopetal




Atzeni, P., Mecca, G. and Merialdo, P. 1998. 'Design and Maintenance of Data-Intensive Web Site',Proceedings of the 6th International Conference on Extending Database Technology, 436-450

Baresi, L., Garzotto, F. Paolini, P. 2000. 'From Web Sites to Web Applications: New Issues forConceptual Modeling', Proceedings of the Workshops on Conceptual Modeling Approaches for E-Business, 89-100

Bohner, S.A. 2002. 'Software change impacts-an evolving perspective', Proceedings InternationalConference on Software Maintenance (ICSM' 02), 263-272

Bonifati, A, Ceri, S., Fratemali, P. and Maurino, A. 2000. 'Building Multi-device, Content-CentricApplications Using WebML and the W3I3 Tool Suite', Proceedings of the Workshops on ConceptualModeling Approaches for E-Business, 64-75

Burdman, J. 1999. Collaborative Web Development, Addison-Wesley, 1999Cysneiros, L.M., Sampaio, J.C. and Neto, J.M.S.N. 2001. 'A Framework for Integrating Non-Functional

Requirements into Conceptual Models' .Requirements Engineering, Springer-Verlag, London 6: 97-115

Donzelli, P.and Setola, R. 2002. 'System applications and experience: Handling the knowledge acquiredduring the requirements engineering process: a case study', Proceedings of the 14th ICSE, 673-679

Kirner, T.G. and Davis, AM. 1996. 'Nonfunctional requirements of real-time systems'. Adv Computing;1-37

Kleiner, N. 2003. 'The Focus of Requirements Engineering in Workflow Application Development',International WorkshopREBPS'03, KlagenfurtlVelden, Austria.

Kotonya, G. and Sommerville, 1.2002. Requirements Engineering: Processes and Techniques, JohnWiley & Sons, USA,

Lowe, D. 2003. 'Web Requirements: An Overview', Requirements Engineering, Springer-Verlag,London, 8: 102-113,

Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, AH.H. and Elmagarmid, A.K. 2003. 'Business-to-business interactions: issues and enabling technologies', The VLDB Journal, 12(1),

Michael S. and Lewis, B. 1994. Research practice: International handbooks of quantitative applicationin social sciences, Sage

Mylopouhs, J., Chung, 1.,Yu, E. and Nixon, B. 1992. 'Representing and using non-functionalrequirements: a process-oriented approach'. IEEE Trans SE, 18(6):483-497

Rossi, G., Schwabe, D. and Lyardet, F. 1999. 'Web Application Models Are More Than ConceptualModels' .Proceedings of the Workshops on Evolution and Change in Data Management, 239-253

Sinha, G."Build a Component Architecture for E-Commerce", e-Business Advisor, March 1999Yang, J. and Papazoglou, M.P. 2000. 'Interoperation support for electronic busness', Communication of

the ACM, 43(6): 39-47Yusop, N., Lowe, D. and Zowghi, D. 2004. 'A domain framework for representation of Web system

impacts', Proceedings of the 5th International Conference on Web Information Systems Engineering,Brisbane, Australia

Zdanowicz, A.B., Kaschek, R. Schewe, K. and Thalheim, B. 2004. 'Context-aware Web InformationSystems', Proceedings of the 1st Asian-Pacific conference on Conceptual modelling, 31: 37 - 48,

Zowghi, D.,Offen, R. and Nunnuliani, N. 2000. 'The Impact of Requirements Volatility on the SoftwareDevelopment Lifecycle ',Proc. of the Int. Con! on Software, Theory and Practice (ICS2000), China

Zowghi, D. and Gervasi., V. 2001. 'Why is RE for Web-based software development easier?', inProceedings of the Seventh International Workshop on Requirements Engineering: Foundation forSoftware Quality (REFSQ'Ol), Interlaken, Switzerland

8YusopetaI


theimpactsofnon-functional requirements inweb …€¦ · european and mediterranean conference on...

Documents