Download Web Engineering: Principles, Requirements, and Challenges and more Schemes and Mind Maps Web Design and Development in PDF only on Docsity!
INTRODUCTION TO WEB
ENGINEERING AND
REQUIREMENTS ENGINEERING
Motivation
1.1 Introduction
Within a decade, the World Wide Web has become ubiquitous, and it continues to grow unabated at exponential rate. Web-based systems and applications now deliver a complex array of varied content and functionality to a large number of heterogeneous users. The interaction between a Web system and its backend information systems has also become tighter and more complex.
Within a short period, the Internet and World Wide Web have become ever-present, exceeding all other technological developments in our history. They‘ve also grown rapidly in their scope and extent of use, significantly affecting all aspects of our lives. Industries such as manufacturing, travel and hospitality, banking, education, and government are Web enabled to improve and enhance their operations.
The distinguishing feature of Web applications compared with traditional software applications is the way in which the Web is used, i.e. its technologies and standards are used as a development platform and as a user platform at the same time. A Web application can therefore be defined as follows:
A Web Application is a software system based on technologies and standards of the World Wide Web Consortium (W3C) that provides Web specific resources such as content and services through a user interface, the Web browser.
1.2 Introduction to Web Engineering and Requirements Engineering
1.1.1 What is Web Engineering?
Web Engineering is the application of systematic and quantifiable approaches (concepts, methods, techniques, tools) to cost-effective requirements analysis, design, implementation, testing, operation, and maintenance of high-quality Web applications.
Web Engineering is also the scientific discipline concerned with the study of these approaches.
1.1.2 Web engineering activities:
- Web engineering deals with all aspects of Web-based systems development.
- Starting from conception and development to implementation.
- Performance evaluation.
- Continual maintenance.
- Building and deploying a Web-based system involves multiple, iterative steps.
1.1.3 The basic principles of Web Engineering
Clearly defined goals and requirements
Systematic development of a Web application in phases
Careful planning of these phases
Continuous audit of the entire development process.
1.2 Categories of Web Applications
Figure 1-1 Categories of Web application
1.4 Introduction to Web Engineering and Requirements Engineering
Radio button, string input, choice lists
Examples:
Dynamic HTML pages
Public transport schedules
Search engines
1.2.3 Transaction-Oriented
Complex interactions
Read and write actions
Usage of transaction management of database systems
Efficient and consistent data management
Structured data and queries
Examples:
online banking
e-shopping
reservation systems
1.2.4 Work-Flow based
Support business processes (―workflows‖) within resp. between different enterprises or private users
An application provides a complex service to the user, e.g. assists the user in determining the mortgage payment
Prerequisite: structured flow of activities
Examples:
Business-to-Business (B2B) Integration Frameworks
E-Government
patient workflows in health care systems
Web Engineering 1.
1.2.5 Collaborative
Support cooperation in case of unstructured flow of activities and high degree of communication (―groupware‖)
Examples:
Support of shared information- and workspaces
Wiki, http://c2.com/cgi/wiki
BSCW, http://bscw.gmd.de
Chat rooms
e-Learning platforms
1.2.6 Portal-Oriented
The application channels the user to other Web content or services outside the domain of the portal application
Single point of access
Examples:
Community portals
Dedicated user groups
Customer profiles
Enterprise portals
Intranet, extranet
1.2.7 Ubiquitous
Personalized services at every time at every location
Multi-platform delivery (PC, PDA, mobile phone)
Context-dependent information
Examples:
Display of today‗s menu on end-user devices while entering a restaurant
1.2.8 Semantic Web
Information available on the web
Web Engineering 1.
Presentation: Presentation plays an important role in product marketing and survival.
Two special features of Web applications at the presentation level, i.e. the user interface, are aesthetics and self-explanation.
Aesthetics:
Looks and feel is the first impression for the success and failure of application in this competitive market. The application must be attractive, impressive and according to fashion trend going on in market.
Self-explanation:
Web applications are self-explanatory, i.e. it should be possible to use a Web application without documentation. The navigation system or interaction behavior must be consistent within the whole application, so that users can quickly become familiar with the usage of the Web application.
Hypertext:
Hypertext is the base of web application. The basic elements of hypertext are: link, node and anchor. It implements Non linearity, cognitive overload and Disorientation features in application that makes the application highly interactive and improve the performance.
Non-linearity:
Hypertexts imply stereotypes of relatively systematic reading, and in this, Web applications differ fundamentally from traditional software applications.
Disorientation and cognitive overload:
Disorientation is the tendency to lose one‘s bearings in a non-linear document. Cognitive overload is caused by the additional concentration required to keep in mind several paths or tasks simultaneously
Content:
Content is the informational part. Content generation, integration and updating and availability is an important factor.
Important aspects are the varying degree of structure of the content and the quality demands users make on the content.
Document-centric character and multimediality:
It contains document, table, text, graphics, and multimedia. It must be of high quality, reliable, consistent and up-to-date. The documents must be properly arranged.
1.8 Introduction to Web Engineering and Requirements Engineering
Quality demands:
Depending on the application area, the content of a Web application is not only subject to differing update frequencies, but also to different quality metrics regarding its being up to date, exact, consistent and reliable.
1.3.2 Usage-related Characteristics
It is difficult to predict the usage frequency of a web application because is varies according to the user, devices used by the users etc. we can divide the user related characteristics of web application as: Natural content, Social content and Technical content.
Natural Content: It includes the geographical location and time of access. Globality and availability create a high degree of heterogeneity.
Globality: The location from which a Web application is accessed, e.g. the geographical position, is important for the internationalization of Web applications regarding regional, cultural and linguistic differences. Global availability also increases the demands on security of Web applications to prevent users from accessing – deliberately or by accident
- private or confidential areas.
Availability: The ―instant delivery mechanism‖ inherent in the very nature of the Web makes the application immediately available. The Web application becomes instantly usable, which means that the quality of the developed product must be secured. Global accessibility of web application with 24*7, availability improves the performance, stability and demand of the web application.
Social Content: It is related to user specific aspect. There are thousands of competitive web applications around the globe, the user needs spontaneous and immediate benefits. Scalability and multiculturalism are extremely essential feature required for web application.
It includes two aspects—spontaneity and multiculturality.
Spontaneity: It means that the number of users cannot be reliably predicted.
Multiculturality: It includes certain behaviors related to Web such as understanding the user contexts at the development stage of Web application only, giving special discounts to regular Web site visitors, etc.
Technical Content: It comprises properties related to network of web application concerning Quality of Service and the devices where web application is used concerning multi-platform delivery.
Quality of Service: The characteristics of the transmission medium, such as Connection bandwidth, stability, reliability etc. are some essential features that affect the performance of web application.
1.10 Introduction to Web Engineering and Requirements Engineering
services, avoiding their side effects and assuring quality of service are some of the common challenges that we face during the development of Web applications.
1.4 Evolution of web engineering
Traditional or conventional software evolution needs a well-planned series of versions while Web applications are developed continuously. This means that Web applications are in permanent maintenance phase. Web development needs a better requirements analysis in comparison to a traditional SDLC. This is because of the continuously changing nature of Web requirements. Web applications change rapidly. This constant change of requirements of a Web application is the core characteristic of Web applications. Changes may be in the product, its usage and its development.
The evolution of Web has brought together some disparate disciplines like media, information science and communication technology. Many new Web technologies have recently emerged such as XML, Web services, semantic Web, Web mining, Web intelligence and mobile technology.
Web projects require shorter development times and shorter life cycle due to several market pressures today.
The extreme pressure on the development of Web application is due to the rapid change in the Web, their shorter life spans and their frequency of updates.
The advances in the field of Web engineering have led to an avalanche of Web sites.
1.5 Requirements Engineering for Web Applications
1.5.1 Fundamentals
Where Do Requirements Come From?
The individual objectives and expectations of stakeholders are the starting point of the requirement elicitation process. Stakeholders are people or organizations that have direct or indirect influence on the requirements in system development. Important stakeholders are customers, users, and developers. Typical stakeholders for Web applications include content authors, domain experts, usability experts, or marketing professionals.
Stakeholder objectives are often represented informally and provide the foundation for deriving more detailed requirements.
A requirement describes a property to be met or a service to be provided by a system.
Requirement defines the following:
A condition or capability needed by a user to solve a problem or achieve an objective
Web Engineering 1.
A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents
A documented representation of a condition or capability as in 1 and 2.
Categories of Requirements
Functional requirements
Non-functional requirements
Domain requirements
Figure 1 - 4 Characteristics of Web application
Functional Requirements:
These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non- functional requirements.
There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.
Non-functional requirements:
Web Engineering 1.
- Software Requirement Specification
- Software Requirement Validation
- Software Requirement Management
Figure 1 - 5 Requirement Engineering Process
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is acceptable to users, flexible to change and conformable to established standards.
Types of Feasibility:
(1) Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to accomplish customer requirements within the time and budget.
(2) Operational Feasibility - Operational feasibility assesses the range in which the required software performs a series of levels to solve business problems and customer requirements.
(3) Economic Feasibility - Economic feasibility decides whether the necessary software can generate financial profits for an organization.
2. Requirement Elicitation and Analysis:
1.14 Introduction to Web Engineering and Requirements Engineering
This is also known as the gathering of requirements. Here, requirements are identified with the help of customers and existing systems processes, if available.
Analysis of requirements starts with requirement elicitation. The requirements are analyzed to identify inconsistencies, defects, omission, etc. We describe requirements in terms of relationships and also resolve conflicts if any.
Problems of Elicitation and Analysis
Getting all, and only, the right people involved.
Stakeholders often don't know what they want
Stakeholders express requirements in their terms.
Stakeholders may have conflicting requirements.
Requirement change during the analysis process.
Organizational and political factors may influence system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software analyst after the requirements collected from the various sources - the requirement received by the customer written in ordinary language. It is the job of the analyst to write the requirement in technical language so that they can be understood and beneficial by the development team.
The models used at this stage include ER diagrams, data flow diagrams (DFDs), function decomposition diagrams (FDDs), data dictionaries, etc.
Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the flow of data through a system. The system may be a company, an organization, a set of procedures, a computer hardware system, a software system, or any combination of the preceding. The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items defined in DFDs. At the requirements stage, the data dictionary should at least define customer data items, to ensure that the customer and developers use the same definition and terminologies.
Entity-Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram, often called an "E-R diagram." It is a detailed logical representation of the data for the organization and uses three main constructs i.e. data entities, relationships, and their associated attributes.
4. Software Requirement Validation:
1.16 Introduction to Web Engineering and Requirements Engineering
difficult. This is so because the people involved in Web projects have different nature, views and languages that need to be reconciled.
2. Non-availability of stakeholders:
In normal software engineering projects, during RE, stakeholders are more or less clear, but in Web engineering projects, during RE. the stakeholders are not clear. It is the job of the project manager to find out the potential stakeholders involved in Web projects and to ensure whether they can provide real type of requirements. For example, it is easy to list the stakeholders theoretically, but practically, it is difficult to get them.
3. Volatility of requirements:
Requirements and constraints of any Web project keep on changing, just as it happens for normal projects. Requirements keep on changing due to the continuous change in the users' requests. Web applications and their environments are highly dynamic. The Web requirements are highly unstable. This is so because every day newer technologies mid newer apps are being developed.
4. Dynamic operational environment:
The operational environment of a Web site or a Web application is very much dynamic and difficult to predict. It is difficult for a Web developer to find out the factors that decide what a Web user desires in his project. For example, changing bandwidths will affect the response time of mobile applications, but it may be out of the view of the development team.
5. Affect of old systems:
Legacy systems are the old existing systems. A Web application project is worked upon by integrating the existing software components like COTS or open source software. Web developers are often confronted with a challenge to integrate these old systems. This may be due to the cost factor (as imposed by the management). It is to be noted that the components that need to be integrated very strongly influence the requirements and the architectural style of the future system. In such scenarios, waterfall model is not suitable. This means that during the RE. The Web developers must be aware of the system architecture and the architectural restrictions (constraints). An iterative approach, as proposed in twin-peaks model, is much more apt here.
6. Importance of quality factors:
Quality factors for Web applications should be considered also. Web quality is not a simple and atomic term. In fact, it is a multidimensional and abstract concept. Three quality problems are very significant— incompleteness, inconsistency and semantic ambiguities. These three factors affect every field of domain of engineering. But Web applications involve many other quality factors like representational conciseness, interoperability and interpretability of the data. The factors like logical or formal consistency, trustworthiness and relevancy constitute another set of dimensions that
Web Engineering 1.
determines the quality of the Web of data. The challenge is to measure the quality factors. Bizer (2007) listed some quality factors like accuracy, timeliness, completeness, relevancy, conciseness and consistency. Flemming (2010) suggested uniformity of Web. Web versatility and Web comprehensibility. amount of Web data, Web validity, Web licensing, Web accessibility and Web performance. The quality factors related to Web apps that are still not explored much are interlinking, believability and licensing. Web application developers must be aware of I Know It When I See It (IKIWISI) phenomenon. It means that users will not be able to understand a Web application by just looking at the abstract models, but rather they need to experiment with it. Prototypes of some important scenarios may be built.
7. Quality of content:
Several RE methods for Web projects do exist. But they do not stress much on the quality of content. Both the creation of the content and its maintenance arc equally important. During the RE, it is mandatory to define the quality of the content. Some quality features include accuracy, objectivity, credibility, relevance, actuality, completeness or clarity of contents. Today many content management systems (CMSs) arc also very popular that allow us to represent the Web content more precisely and consistently by separating out the content from its layout mid offering content editing tools.
8. Lesser developer experience:
The existing Web technologies, tools, standards, languages, etc. are still in their infancy. So, this can result in wrong estimates when doing cost and time estimations for them.
9. Rigid delivery dates:
The Web projects are very much tuned to be delivered on time. They have fixed project deadline. And under such conditions, prioritization of requirements is not an easy task. There is no agreed standard for size measurement for a Web project like we have LOC or FP methods for traditional projects.
10. Vulnerability issues:
It has been found that Web applications are much more vulnerable to hacks as compared to any traditional application. This is so because Web projects are very complex and are to be available (24x7x365) days. This may be one of the reasons of easier data leakages from Web sites.
1.5.4 Principles for RE of Web Applications
Web developers should keep the following five principles while performing RE activities:
Web Engineering 1.
consistent with other artifacts of the SDLC like architecture, user interface, content, test case, etc. Initially, the project requirements are at the higher level of abstraction and these can be further used to develop cost- and time-constrained architectures, key system usage scenarios and initial project plans. As a project progresses, the development results can be slowly refined in more concrete terms, while continuously ensuring their consistency. Requirements are volatile, i.e., they may change any time. Thus, iterative approach is better. If the development time is limited, then iterative approach will list and implement the higher priority requirements first.
Principle 4: System architecture
We know that Web architecture is usually very complex due to large number of Web pages that arc intermingling with each other. A complex Web architecture makes the Web site code also complex. This makes its testing difficult. The problem space is defined by the solution space; so, it is necessary to understand the technical solutions with their Limitations. Thus, proper Web architecture must be designed. For this, expert Web designers are needed and this is a very big issue in Web engineering field. Actually, the existing technologies and old solutions have a high impact on the requirements of Web engineering. The twin-peaks model suggests the concurrent refinements of both requirements and the system architecture in an iterative fashion, with each level introducing a newer detail.
Principle 5: Risk identifications
Any unwanted act that results in some loss of the project in terms of its cost, lime or resources constitutes risk. A good project manager must identity the risks as the project starts. It is so because the late identification of a risk can leads to project failure, and hence, loss of several million dollars. Risks also arise due lo undetected problems, unsolved issues and conflicts among the requirements. As far as the Web applications are concerned, several risks have been identified like integration of the existing components into the Web application, determination of system quality aspects or less-experienced developers. Risk mitigation is one of the important activities. The earlier it is done, the belter it is!
1.5.5 Adapting RE Methods to Web Application Development
Today numerous methods, guidelines, notations, checklists, and tools are available for all activities in RE. However, in order to succeed developers should avoid a ―one-size-fits-all‖ approach, and RE methods consequently have to be adapted to the specifics of Web engineering and the situation of specific projects.
1.5.5.1 Requirement Types:
Following requirement types are available in web engineering
Functional requirements: It describes a system‘s capabilities and services (e.g., ―The user can select an icon to view articles in the shopping cart at any given time.‖).
1.20 Introduction to Web Engineering and Requirements Engineering
Non-functional requirements: It describes the properties of capabilities and the desired level of services (e.g., ―The Web application shall support at least 2500 concurrent users.‖).
Contents Requirements: Contents requirements specify the contents a Web application should represent. Contents can be described, for example, in the form of a glossary.
Quality Requirements: Quality requirements describe the level of quality of services and capabilities and specify important system properties such as security, performance, or usability.
Functionality describes the presence of functions which meet defined properties. The sub characteristics are suitability, accurateness, interoperability, compliance, and security.
Reliability describes a software product‘s ability to maintain its performance level under specific conditions over a defined period of time. The sub characteristics are maturity, fault tolerance, and recoverability
Usability describes the effort required to use a software product, and its individual evaluation by a defined or assumed group of users. The sub characteristics are understandability, learnability, and operability.
Efficiency describes the ratio between the performance level of a software product and the resources it uses under specific conditions. Sub characteristics include time behavior and resource behavior.
Maintainability describes the effort required to implement pre-determined changes in a software product. Its sub characteristics include analyzability, changeability, stability, and testability.
Portability describes the suitability of a software product to be moved from one environment to another. The sub characteristics include adaptability, installability, conformance, and replaceability.
System Environment Requirements: These requirements describe how a Web application is embedded in the target environment, and how it interacts with external components, including, for example, legacy systems, commercial off-the-shelf components, or special hardware. For example, if a Web application is supposed to be ubiquitously available, then environment requirements have to specify the details.
User Interface Requirements: As Web users are expected to use a Web application without formal training, self-explanatory and intuitive guidance of users is critical for its acceptance. Requirements concerning the user interface define how a Web application interacts with different types of user classes. Important aspects are hypertext (navigation structure) and presentation (user interface). While navigation and presentation details are normally defined in the modeling process, initial decisions
