F Focused Requirements Engineering Method for Web Application ...

Category: Web Technologies

1537

Focused Requirements Engineering Method for Web Application Development Ala M. Abu-Samaha Amman University, Jordan Lana S. Al-Salem SpecTec Ltd & MEP, Greece

IntroductIon The requirements phase of the system/application development process typically involves the activities of requirements elicitation, analysis, validation, and specification. The main goal of such a process is “to develop a requirements specification document which defines the system to be procured and which can act as a basis for the system design” (Sawyer, Sommerville, & Viller, 1996). Hence the underpinning assumption of the requirements engineering (RE) process is to transform the operational needs of an organisation into complete, consistent, and unambiguous system/application specifications through an iterative process of definition and validation (Pohl ,1994). The Web engineering (WE) literature provides a limited number of methods and techniques that can be used to manage the RE process in a Web development context [e3-value framework (Gordijn, Akkermans, & van Vliet, 2000), SOARE approach (Bleistein, Aurum, Cox, & Ray, 2004), e-prototyping (Bleek, Jeenicke, & Klischewski, 2002), AWARE (Bolchini & Paolini, 2004), and SSM/ICDT (Meldrum & Rose, 2004)]. Despite the availability of such a limited number of Web requirements engineering (WRE) methods, many researchers criticised such methods for their failure to address the necessity to align the Web application’ requirements to the organisation’s business strategy. Hence, the recommendation of many researchers (Al-Salem & AbuSamaha, 2005a; Bleistein 2005; Bleistein, Cox, & Verner, 2004; Vidgen, Avison, Wood, & Wood-Harper, 2002) is to utilise a general WRE framework for the development of Web applications that can align the application’s requirements to the organisation’s business needs and its future vision. The objective of such a WRE framework is to incorporate the elicitation/analysis of business strategy as part of the application’s RE process. This chapter presents a WRE method that extends Sommerville and Kotonya’s viewpoint-oriented requirements definition (VORD) and Kaplan and Norton’s balanced scorecard (BSC) to elicit the Web application’ requirements and to plan/analyze the business strategy, respectively. In addition, eWARE (extended Web application requirements

engineering) deploys the concept of “requirements alignment” to attain business objectives during the requirements discovery, elicitation, and formalisation process to identify the services of the Web application that will achieve the business objectives in order to improve the organisation’s profitability and competitiveness. The chapter is organised into a number of sections. The second section of this chapter provides a background to Web applications in terms of definition and differentiating characteristics. The third section provides a discussion of eWARE method in terms of phases and activities. This section is divided into two subsections to cover the activities of the two prominent phases of the eWARE process in more detail. The fourth and fifth sections provide a discussion of possible future trends in WRE and a number of concluding remarks.

Background Web applications provide organisations an unprecedented chance to stretch their existence beyond the typical boundaries of an organisation to include customers, trading partners, and suppliers.Little attention has been paid to the process of RE for Web application development, in comparison to other areas of the development process [modelling, design, and coding] (Ginige & Murugesan, 2001). Hence, Web applications can be defined as “applications that tend to be used to integrate and streamline an organisation’s business processes beyond organisational (customers, agents, suppliers, others) and geographical borders; provide an organisation with competitive products and services that give it a strategic advantage over its competitors in the marketplace; promote business innovation; and/or improve operational efficiency” (Al-Salem & Abu-Samaha, 2005a). There is a pressing need in the WE discipline for RE approaches and techniques that (a) take into account the multiplicity of user profiles and the various stakeholders involved [a stakeholder is defined as “anyone who can share information about the system, its implementation constraints or the problem domain” (Potts, Takahashi, & Anton, 1994)]; (b) eliciting overall functionality and the business environ-

Copyright © 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

F

Focused Requirements Engineering Method for Web Application Development

ment of the Web application; (c) specifying technical and nontechnical requirements of the Web application, and (d) aligning the Web application’ requirements to the overall business strategy (Bleistein et al., 2005; Ceri, Fraternali, Bongio, Brambilla, Comai, & Matera, 2003; Ginige & Murugesan, 2001; Kautz & Madsen, 2003; Lowe, 2003; Meldrum & Rose, 2004; Nuseibeh & Easterbrook, 2000; Vidgen et al., 2002). More importantly, a Web application must be developed with an emphasis on how the services of such an application can achieve the business vision and strategy and fulfil the business processes (Haire, HendersonSellers, & Lowe, 2001).

The strategy articulation phase of eWARE can be best thought of as a structure of many layers. The vision of the organisation is at the top of the structure, while the strategic objectives are presented in the next layer of the structure followed by the Web application services. The next layer of the structure contains the measurements and targets for meeting the strategic objectives. The level of detail tends to increase as we move down the structure of the strategy. This articulation of the organisation’s vision, objectives, and measurements aims to translate the future vision of the organisation into detailed and prioritised Web application requirements (this will be fully covered in the coming subsections). The requirements elicitation phase of the eWARE process is used to produce a WRS document based on requirements collected during the strategy articulation phase. Requirements elicitation relies on the identification of the relevant viewpoints (VPs), their sub-VPs, and requirements for each viewpoint (VP). Kotonya and Sommerivlle (1996) define a VP as anyone who may have some direct or indirect influence on the system/application requirements. Goals and objectives of the different stakeholder groups need to be identified to define success or failure measures for each stakeholder. Moreover, nonfunctional requirements {NFR) need to be

eWare process eWARE process can be best perceived as a series of activities grouped into three phases; strategy articulation via BSC, Web application’ requirements elicitation via VORD, and prototype building; Figure (1) presents the phases and activities of eWARE. Such a process aims to develop a Web application requirements specification (WRS) document that is aligned with business strategy and detailed enough to be used for contractual purposes.

Figure 1. The eWARE process

Id e n tify V isio n & S tra te g y

A rticu la tin g S tra te g y Id e n tify O b je ctive s Id e n tify S ta ke h o ld e rs

D e te rm in e T a rg e ts & M e a su re s Id e n tify S e rvice s

W e b R e q u ire m e n ts E n g in e e rin g P ro ce ss

Id e n tify B u sin e ss P ro ce sse s

Id e n tify V P stru ctu re

E licitin g R e q u ire m e n ts B u ild se rvice /V P h ie ra rch y

E licit se rvice d e ta ils

D e fin e n o nE licit c o n te n t te ch n ica l re q u ire m e n ts re q u ire m e n ts

S p e cify re q u ire m e n ts

B u ild in g a p ro to typ e P ro to typ e

1538

Focused Requirements Engineering Method for Web Application Development

identified; these include some of the “-ilities” of the Web application, such as reliability, supportability, maintainability, affordability, and so forth. Finally, in the prototyping phase of the eWARE process, the system/application stakeholders consider the unclear set of requirements, and agree on prototyping the ambiguous requirements to verify them. Moreover, the user interface (UI) and Web site structure are presented in a throw away prototype. The mentioned WRE phases and activities are perceived to be iterative and incremental in nature where unmet targets are questioned. This cyclic view of the WRE process will trigger the strategy articulation phase to enter in a feedback loop in order to refine services and change requirements of the Web application in order to enhance the organisation’s chance to achieve its set vision and strategy.

cess of strategy analysis. eWARE delivers such alignment via eBSC (extended Balanced Score Card). According to eBSC, aligning the Web application’ requirements to the business objectives yields four perspectives to focus upon (stakeholders, strategic objectives, internal processes, and Web application services). Figure 2 provides a diagrammatic representation of the perceived relationship between the four perspectives.

strategy articulation phase

Web Application Services Perspective

As mentioned earlier, the strategy articulation phase of eWARE process aims to align the Web application’ requirements to the organisation’s business strategy through a pro-

The Web application services are the collection of functionality, quality, content, and all what the Web application must provide in order to achieve the strategic objectives of the

Strategic Objectives Perspective Objectives are statements that clarify what the strategy aims to achieve. Hence, organisations pursue strategies in the belief that, when implemented, they will enable the organisation to better achieve its strategic objectives.

Figure 2. eBSC perspectives

A re w e s a tisfyin g sta ke h o ld e r n e e d s?

stakeholders

W h a t p ro ce sse s w e n e e d to ch a n g e to ca te r fo r th e W e b A p p ?

strategic objectives

Is th e W e b A p p co n trib u tin g to th e o rg a n iza tio n O b je ctive s?

Mission

Webapp services

Internal Business processes

W h a t s e rvice s w e n e e d to o ffe r ?

1539

F

Focused Requirements Engineering Method for Web Application Development

organisation and to meet the expectations of its stakeholders. This perspective is considered as a precondition to process improvement, stakeholder satisfaction, and business objectives’ realisation. Hence, the development team, comprising of requirement engineers and end user representatives, must be empowered to select which services (functionalities) of the Web application will be included, in order to deliver the optimal business solution. Decisions and trade-offs need to be made between new services elicited through the eBSC process, and less important original functionalities that may have to be excluded, being less strategically important.

a competitor, or even a third party. Hence, if the stakeholder represents a customer, then the requirements elicitation effort will focus on new customer acquisition, customer retention, and customer profitability. The goal of using eBSC is to classify the organisation’s strategy by stakeholder, which will lead to introducing Web application services for each group to meet their strategy or objective. The organisation must determine whom it serves and how their requirements can be met.

Stakeholders1 Perspective

Organisations’ activities can be grouped into “business processes” that describe the way work is to be implemented. Some of the organisation’s activities will be affected by the introduction of a Web application, since such applications have the potential to significantly change an organisation’s work practices and procedures (Ginige & Murugesan, 2001; Pressman, 2004). The internal process perspective focuses on key processes at which the organisation must excel in order to add value to its stakeholders through the Web application.

The stakeholder perspective is arguably the most important perspective in the Web application development process. As mentioned earlier, a stakeholder is defined by Potts et al. (1994) as “anyone who can share information about the system, its implementation constraints or the problem domain.” According to Potts et al. (1994), the list of stakeholders will include end users, indirect users, other customer representatives, and developers. Since a stakeholder is, in essence, a requirements source; it can be an application user,

Internal Process Perspective

Figure 3. Web application cause and effect relationships Business Vision & strategy strategic objectives What business objectives are we pursuing to achieve our vision and strategy?

Webapp services What WebApp services are necessary to achieve the business objectives?

Internal Business processes What processes do we need to put in place to achieve these services?

stakeholders Have we satisfied our stakeholders?

1540

Focused Requirements Engineering Method for Web Application Development

When designing a score card, the starting point will be asking “what strategies do we have to put in place to satisfy the wants and needs of the key stakeholders?” The inclusion of BSC within the WRE process aims to help clarify, consolidate, and gain consensus around the business–Web application strategy of the organisation, and to translate the business strategy into Web application services (requirements) to ensure that the elicited requirements are strategy focused. Hence, a strategy can be best described as a series of cause and effect relationships that provide a translation from future vision to Web requirements, as shown in Figure (3).

eVord for eliciting Web requirements The second phase of the proposed WRE process presents the requirements elicitation phase of the Web application development process. eWARE delivers such elicitation via eVORD (extended viewpoint-oriented requirements definition). According to eVORD, templates are created to describe each viewpoint (VP), service, nonfunctional requirement (NFR), and content. As mentioned earlier, Kotonya and Sommerville (1996) define a VP as anyone who may have some direct or indirect influence on the system/application requirements. The VORD requirements engineering process includes activities concerned with VP identification, VP service description, cross-viewpoint analysis to discover inconsistencies, omissions, and conflicts, and developing an object-oriented model of the system/application from the

VP analysis. In addition, a VP diagram is used to show the relationships among VPs, while sequence diagrams illustrate the interactions among VPs.

Web Application Viewpoints (WebVPs) Identification and Structuring The construction of Web applications involves a great number of stakeholders who have different views of the Web application. These perspectives are partial or incomplete descriptions of the system/application, and reflect the environment in which the system/application will operate in. The integration of multiple views can contribute to augment the overall understanding of the Web application. The authors recommend the use of a new and amended list of VPs for developing Web applications. These WebVPs’ abstracts have been identified as a starting point that acts as a template for WebVPs classes and hierarchy. Figure (4) shows a high-level abstract of WebVPs structure. WebVPs can be classified into direct VPs that interact directly with the Web application and fall into two subclasses (receivers and providers of services), and indirect VPs that have “interest” in some or all of the services that are delivered by the system but do not interact directly with it; hence, they provide high-level organisational requirements and constraints. Indirect VPs fall into a number of subclasses: environmental WebVPs, which reflect the requirements of the business domain, that is, legalisation, localisation, taxa-

Figure 4. Abstract of WebVPs structure

W ebVP

D irect W ebVP

System operators

Operator

Receivers of services

Internal

Providers of services

External

Registered customer

Indirect W ebVP

Engineering

Initiator

Environmental

Organisational

Other systems

Competitors

Potential customer

1541

F

Focused Requirements Engineering Method for Web Application Development

tion, and competitors; engineering WebVPs, which reflect the requirements of the development team, that is, software engineers, team leaders, and creative designers; and system WebVPs, which include all existing information systems that the application being analysed needs to interface to, that is, payment systems and supplier systems.

Eliciting Requirements Details The second step of this phase is concerned with documenting the details of each WebVP (identified in the previous step) and its associated services. For every identified WebVP, a number of templates are used to elicit and specify its requirements. The authors have extended and adapted VORD templates to cater to the particularities of Web applications development (please refer to Al-Salem & Abu-Samaha, 2005a and Al-Salem & Abu-Samaha, 2005b for more details).

Documenting Requirements The objective of the requirements process is to deliver a requirements specification document that defines the system/ application to be developed (Sawyer, Viller, & Sommerville, 1997). This document is used for contractual purposes, and can be used as a basis for facilitating a competitive tendering for the system/application design and implementation (IEEE, 2004). The authors have enhanced the typical software requirements specification (SRS) document to reflect the changes introduced to eVORD and eBSC, as depicted in Figure (5).

Future Work The domain of RE, in general, and WRE, in particular, is evolving with the ever-changing contexts of software en-

Figure 5. Software requirements specification (SRS) document template

1542

Focused Requirements Engineering Method for Web Application Development

gineering and information systems development projects. Despite the availability of many requirements, engineering methods, processes, techniques, and tools, such artefacts are in need of constant extensions and enhancements to bring such artefacts to the changing contexts of the development projects. The presented eWARE method is an extension of two existent methods used to align requirements of a Web application to the organisation’s business strategy. eWARE needs to be tested further in different industrial settings to validate the applicability of the method. As well, eWARE, like many other RE methods, needs to be supported through the development of a computer aided software engineering (CASE) tool to facilitate the generation of the WRS document. Compared to similar WRE methods ( Bleek et al., 2002; Bleistein et al., 2004; Bolchini & Paolini, 2004; Gordijn et al., 2000; Meldrum & Rose, 2004), eWARE provides its users with a number of benefits: it extends the BSC approach to help with the formulation of Web application strategy as a stage in the WRE process in advance to requirements elicitation; it provides a prioritisation framework synchronised with business strategy; it extends VORD to elicit requirements for Web applications; and it creates a WRS document that specifies both the business strategy and requirements for the Web application. Such advantages proved to be valuable in Web application development projects, as Web applications are different in many aspects when compared to other applications. The differing characteristics of Web applications can be summarized as diverse and volatile requirements, vast and unknown end users, multiple stakeholders, adaptable architecture, short development life cycle, high visibility, heavy content, integration with backend databases and third party applications, Web applications’ relevance and direct effect on business, and multidisciplinary development team.

conclusIons There are two general opinions on whether current software engineering methods and techniques are applicable to face the challenges of developing a Web application. One opinion advocates the need for a new “software engineering” discipline that handles the Web application particularities (Ginige & Murugesan, 2001, Murugesan, 1999; Murugesan, Deshpande, Hansen, & Ginige, 1999). In contrast, the other opinion believes that current software engineering methods, tools, and techniques are applicable to Web application development. For example, McDonald and Welland (2001) recommended developing new methods, techniques, and approaches to address the challenges of developing Web applications in order to increase the possibility of their success. This implies the need for a new breed of WRE methods, tools,and working practices. In contrast, Pressman (2004) argues that Web applications are a natural evolution

of existing applications/systems offering a solution to classical problems exhibited by previous information systems (IS). The authors of this chapter hold a middle position in between these two opinions. The authors perceive Web applications as a natural evolution of “traditional” information systems, yet they believe that such applications possess special characteristics that need to be provided for by the “traditional” RE method(s). Hence, existing RE methods are considered valid for WRE, though they need to be enhanced and extended to cater to the distinguishing features of Web applications. The chapter has presented a WRE approach that enables businesses to develop/procure Web application(s) capable to achieve the organisations’ business strategic objectives, and to effectively harness their business processes. The combination of BSC (Kaplan & Norton 1993, 1996a & b) and VORD (Kotonya & Sommerville 1996) within eWARE process provides the development team with the ability to translate strategy into Web application requirements and to incorporate views from different complementary perspectives. Hence, eWARE is a Web-specific RE process to cope with the complex aspects of requirements elicitation, alignment, and specification for Web applications development/procurement. eWARE views Web applications as organisational initiatives and as such, it takes into account the need to address strategic objectives, business processes issues, requirements details of services, NFR, and integration with other systems.

reFerences Al-Salem, L. S., & Abu-Samaha, A. (2005a). Assessing the usability of VORD for Web applications requirements engineering - An industrial case study -. 1st International Workshop on Requirements Engineering for Business Need and IT Alignment (REBNITA 2005), Paris. Al-Salem, L. S., & Abu-Samaha, A. (2005b). Assessing the usability of VORD method for Web applications requirements elicitation. International Conference on Internet Technologies and Applications (ITA 05), Wrexham, North Wales, UK. Bleek, W.-G., Jeenicke, M., & Klischewski, R. (2002). Developing Web-based applications through e-prototyping. 26th Annual International Computer Software and Applications Conference (COMPSAC 2002), Oxford England. Bleistein, S. J. (2005). Requirements analysis framework for alignment of IT with competitive strategy of business organizations. IEEE International Conference on Requirements Engineering - Doctoral Consortium, Paris. Bleistein, S. J., Aurum, A., Cox, K., & Ray, P. (2004). Strategy-oriented alignment in requirements engineering: Linking 1543

F

Focused Requirements Engineering Method for Web Application Development

business strategy to tequirements of e-business systems using the SOARE approach. Journal of Research and Practice in Information Technology, 36, 259-276. Bleistein, S. J., Cox, K., & Verner, J. (2005). Validating strategic alignment of organizational IT requirements using goal modelling and problem diagrams. Journal of Software and Systems, 79, 362 - 378. Bolchini, D., & Paolini, P. (2004). Goal-driven requirements analysis for hypermedia-intensive Web applications. Requirements Engineering Journal Special Issue. Ceri, S. Fraternali, P., Bongio, A., Brambilla M., Comai S., & Matera M. (2003). Designing data-intensive Web applications. Morgan Kaufman. Ginige, A. (2002). Web engineering: Managing the complexity of Web systems development. In 14th International Conference on Software Engineering and Knowledge Engineering (SEKE ‘02), Ischia, Italy: ACM Press. Ginige, A., & Murugesan, S. (2001). The essence of Web engineering: Managing the diversity and complexity of Web application development. IEEE Multimedia 8(2), 22-25. Gordijn, J., Akkermans, H. & van Vliet, H. (2000). Value based requirements creation for electronic commerce applications. In 33rd Hawaii International Conference on System Sciences, IEEE, Hawaii, USA.

Lowe, D. (2003). Web system requirements: An overview. Requirements Engineering Journal, 8, 102–113. McDonald, A., & Welland, R. (2001). Agile Web engineering (AWE) process. Scotland: Department of Computing Science, University of Glasgow. Meldrum, M., & Rose, J. (2004). Activity based generation of requirements For Web-based information systems: The SSM/ICDT approach. The 12th European Conference on Information Systems (ECIS 2004), Turku Finland. Murugesan, S. (1999). Web engineering. ACM SIGWEB Newsletter, 8(3), 28 - 32. Murugesan, S., Deshpande, Y., Hansen, S., & Ginige, A. (1999). Web engineering: A new discipline for development of Web-based systems. In Proceeding of the Int’l Conf. Software Engineering (ICSE) Workshop on Web Engineering (pp: 1-9). Sydney, Australia: IEEE Multimedia. Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: A roadmap. In International Conference on Software Engineering (ICSE-2000), Limerick, Ireland, ACM Press. Pohl, K. (1994). The three dimensions of requirements engineering. Information Systems, 19(3), 243-258. Potts, C., Takahashi, K., & Anton, A. (1994). Inquiry-based requirements analysis. IEEE Software, 11(2), 21-40.

Haire, B., Henderson-Sellers, B., & Lowe, D. (2001). Supporting Web development in the open process: Additional tasks. COMPSAC’2001: International Computer Software and Applications Conference, Chicago, Illinois, USA, IEEE Computer Society.

Pressman, R. S. (2004). Software engineering: A practitioner’s approach. McGraw-Hill.

IEEE. (2004). Guide to the software engineering body of knowledge. IEEE.

Sawyer, P., Viller, S., & Sommerville, I. (1997). Requirements process improvement through the phased introduction of good practice. Software Process - Improvement and Practice, 1, 19-34.

Kaplan, R., & Norton, D. (1993). Putting the balanced scorecard to work. Harvard Business Review, (September/ October), 134-147. Kaplan, R., & Norton, D. (1996a). The balanced scorecard: Translating strategy into action. Boston: Harvard Business School Press. Kaplan, R., & Norton, D. (1996b). Using the balanced scorecard as a strategic management system. Harvard Business Review, (January/February), 75-85. Kautz, K., & Madsen, S. (2003). Web development - The differences, similarities and in-betweens. Melbourne, Australia: Information Systems Development Conference. Kotonya, G., & Sommerville, I. (1996). Requirements engineering with viewpoints. BCS/IEE Software Engineering Journal, 11(1), 5-18. 1544

Sawyer, P., Sommerville, I., & Viller, S. (1996). PREview: Tackling the real concerns of requirements engineering. Lancaster: Computing Department, Lancaster University.

Sommerville, I. (1995). Software engineering. Addison Wesley. Sommerville, I., & Sawyer, P. (1997). Requirements engineering: A good practice guide. John Wiley & Sons Lts. Vidgen, R., Avison, D., Wood, J. R. G., & Wood-Harper, A.T. (2002). Developing Web information systems. Butterworth Heinemann.

key terMs Balanced Score Card (BSC): “A multidimensional framework for describing, implementing and managing

Focused Requirements Engineering Method for Web Application Development

strategy at all levels of an enterprise by linking objectives, initiatives and measures to an organisation’s strategy” (Kaplan & Norton, 1993, 1996 a & b).

Viewpoint (VP): “Any one who may have some direct or indirect influence on the system requirements” (Kotonya & Sommerville, 1996).

eWARE (extended Web application requirements engineering): “A strategy-focused requirements engineering method used to align Web application requirements to business strategy and to elicit legal, technological, business, marketing and content requirements”.

Viewpoint Oriented Requirements Definition (VORD): “A software requirements engineering approach used to organise both the elicitation process and the requirements themselves into viewpoints” (Sommerville, 1995).

A Requirement: “A condition or capability that must be met or fulfilled by a system to satisfy a contract, standard, specification, or other formally imposed documents.” (IEEE Standard, 610,12-1990). Requirements Engineering (RE): “The process of discovering that ‘purpose’ by identifying stakeholders and their needs, and documenting them in a form that is amenable to analysis, communication, and subsequent implementation” (Nuseibeh & Easterbrook, 2000). Stakeholder: “Anyone who can share information about the system, its implementation constraints or the problem domain, including end users, indirect users, other customer representatives and developers” (Potts et al., 1994).

Web Business Application (WebApp): “An application that tends to be used to integrate and streamline an organisation’s business processes beyond organisational (customers, agents, suppliers, others) and geographical borders; to provide an organisation with competitive products and services that give it a strategic advantage over its competitors in the marketplace; to promote business innovation and/or to improve operational efficiency” (Al-Salem & Abu-Samaha, 2005a).

endnote 1

Throughout eWARE, a stakeholder /viewpoint is used interchangeably.

1545

F